X509 Certificate

Reference

X509 Wiki

http://en.wikipedia.org/wiki/X.509

RFC 5280 - X509v3

http://tools.ietf.org/html/rfc5280

X509 Certificate

The structure foreseen by the standards is expressed in a formal language, namely Abstract Syntax Notation One.

The structure of an X.509 v3 digital certificate is as follows:

Certificate

Version

Serial Number

Algorithm ID

Issuer

Validity

Not Before

Not After

Subject

Subject Public Key Info

Public Key Algorithm

Subject Public Key

Issuer Unique Identifier (optional)

Subject Unique Identifier (optional)

Extensions (optional)

...

Certificate Signature Algorithm

Certificate Signature

Extensions were introduced in version 3. A CA can use extensions to issue a certificate only for a specific purpose (e.g. only for signing digital object). Each extension can be critical or non-critical. If an extension is critical and the system processing the certificate does not recognize the extension or cannot process it, the system MUST reject the entire certificate. A non-critical extension, on the other hand, can be ignored while the system processes the rest of the certificate.

In all versions, the serial number MUST be unique for each certificate issued by a specific CA (as mentioned in RFC 2459).

RFC 5280 (and its predecessors) defines a number of certificate extensions which indicate how the certificate should be used. (http://tools.ietf.org/html/rfc5280)

Some of the most common, defined in section 4.2.1, are:

• Basic Constraints, { id-ce 19 }, are used to indicate whether the certificate belongs to a CA.
• Key Usage, { id-ce 15 }, provides a bitmap specifying the cryptographic operations which may be performed using the public key contained in the certificate; for example, it could indicate that the key should be used for signatures but not for encipherment.
• Extended Key Usage, { id-ce 37 }, is used, typically on a leaf certificate, to indicate the purpose of the public key contained in the certificate. It contains a list of OIDs, each of which indicates an allowed use. For example, { id-pkix 3 1 } indicates that the key may be used on the server end of a TLS or SSL connection; { id-pkix 3 4 } indicates that the key may be used to secure email.

In general, if a certificate has several extensions restricting its use, all restrictions must be satisfied for a given use to be appropriate. RFC 5280 gives the specific example of a certificate containing both keyUsage and extendedKeyUsage: in this case, both must be processed and the certificate can only be used if both extensions are coherent in specifying the usage of a certificate. For example, NSS uses both extensions to specify certificate usage.