SEND Certificate Profile

1
SEND Certificate Profile

• draft-krishnan-cgaext-send-cert-eku-01
• Suresh Krishnan
• Ana Kukec
• Khaja Ahmed

2
Scope of the document

• SEND uses X.509v3 certificates defined in RFC3280
• RFC3280 is generic and hence does not define any
  SEND specific information
• We need additional specification to nail down
  SEND specific certificate information
• This document covers three major areas
• Extended Key Usage definitions
• Certificate Revocation
• Certificate extensions

3
Extended Key Usage

• The Internet PKI document RFC3280 specifies the
  extended key usage X.509 certificate extension.
• The extension indicates one or more purposes for
  which the certified public key may be used.
• The extended key usage extension can be used in
  conjunction with key usage extension, which
  indicates the intended purpose of the certified
  public key.

4
Three new key purposes

• Router
• Node owning this certificate is allowed to
  advertise the prefix
• Proxy
• Node owning this certificate is allowed to modify
  MAC addresses in ND mesages
• Client
• Node owning this certificate owns the address
  specified.

5
Certificate Revocation

• In-band or out-of-band?
• CRL vs OCSP (RFC2560)
• CRL size is unbounded
• May not fit in a single ND message
• This makes CRL (IOHO) unsuitable for SEND
  certificate revocation
• OCSP response, on the other hand, is small and
  bounded

6
Modifications to SEND

• To CPS
• Trust Anchor TA which the client is willing to
  accept
• OCSP Responder The hash of the OCSP Responders
  public key trusted by the client, or the
  concatenated list of hashes of more OCSP
  Responders' public keys.
• To CPA
• Certificate
• Trust Anchor to help the client to find out
  which advertisement is useful
• OCSP response A definitive OCSP response message
  containing the response for each of the
  certificates from the request as specified in
  Section 2.2 of RFC2560.
• OCSP responder to help the client to find out
  which advertisement is useful.

7
Certificate extensions

• Lists the certificate extensions required by SEND
  and define required level of support
• MUST implement
• Subject Alternative Name
• Extended Key Usage
• Key Usage
• Basic Constraints
• Authority Information Access (mark non-critical)

8
Thanks

• Questions?

9
Extension definitions

• The Subject Alternative Name extension (type
  iPAddress) contains the subnet prefix that the
  router is authorized to advertize. It is
  described in RFC3971. It SHOULD be marked as
  critical, as it is possible that some
  certificates in the beginning does not contain
  this extension. In such scenarios the validation
  of subjectAltName iPAddress delegation extension
  MAY be relaxed.
• The Extended Key Usage extension defines the
  application or protocol specific purposes for
  which the certificate key pair may be used. It is
  described in Section 3. It MUST be marked as
  critical.
• The Key Usage extension defines the basic
  purposes for which the key pair may be used. The
  Router Authorization Certificate MUST have at
  least the digitalSignature and nonRepudiation
  bits set, since it's key pair is used for the CGA
  generation and Router Advertisement signing.
  Other certificates would usually have set the
  keyCertSign bit set. This extension MUST be
  marked as critical and MUST be processed
  independently of the Extended Key Usage
  extension. The certificate purpose must be
  consistent with both the Extended Key Usage
  extension and the Key Usage extension.
• The Basic Constraints extension defines specifies
  whether the subject of the certificates is a CA
  or an end entity, as well as the maximum depth of
  valid certification path. In accordance with
  RFC3280, it MUST be marked as critical.
• The Authority Information Access extension
  specifies how to retrieve additional CA
  information, e.g. the information about the OCSP
  responder. It MUST be marked as non-critical and
  usually the host will learn the OCSP responder
  from the configuration file.