In cryptography, X.509 is an ITU-T standard for a public key infrastructure (PKI) for single sign-on (SSO) and Privilege Management Infrastructure (PMI). X.509 specifies, amongst other things, standard formats for public key certificates, certificate revocation lists, attribute certificates, and a certification path validation algorithm.

Contents 1 History and usage 2 Certificates 2.1 Structure of a certificate 2.2 Certificate filename extensions 3 Sample X.509 certificates 4 Security 5 PKI Standards for X.509 6 Certificate authority 7 Public-Key Infrastructure (X.509) Working Group 8 See also 9 Protocols and Standards supporting X.509 certificates 10 References 11 External links

[edit] History and usage

X.509 was initially issued on July 3, 1988 and was begun in association with the X.500 standard. It assumes a strict hierarchical system of certificate authorities (CAs) for issuing the certificates. This contrasts with web of trust models, like PGP, where anyone (not just special CAs) may sign and thus attest to the validity of others' key certificates. Version 3 of X.509 includes the flexibility to support other topologies like bridges and meshes (RFC 4158). It can be used in a peer-to-peer, OpenPGP-like web of trust, but was rarely used that way as of 2004. The X.500 system has never been fully implemented, and the IETF's Public-Key Infrastructure (X.509), or PKIX, working group has adapted the standard to the more flexible organization of the Internet. In fact, the term X.509 certificate usually refers to the IETF's PKIX Certificate and CRL Profile of the X.509 v3 certificate standard, as specified in RFC 5280, commonly referred to as PKIX for Public Key Infrastructure (X.509).

[edit] Certificates

In the X.509 system, a CA issues a certificate binding a public key to a particular Distinguished Name in the X.500 tradition, or to an Alternative Name such as an e-mail address or a DNS-entry.

An organization's trusted root certificates can be distributed to all employees so that they can use the company PKI system. Browsers such as Internet Explorer, Netscape/Mozilla, Opera and Safari come with root certificates pre-installed, so SSL certificates from larger vendors will work instantly; in effect the browsers' developers determine which CAs are trusted third parties for the browsers' users. Although these root certificates can be removed or disabled, users rarely do so. If pre-installed root certificates are removed on the Microsoft-platform, the operating-system re-installs them as soon as a web-site using the certificate is visited^{[citation needed]}. As this mechanism relies on hash-values, pre-installed with the operating system, it is not even possible to determine which certificates are permanently trusted.

X.509 also includes standards for certificate revocation list (CRL) implementations, an often neglected aspect of PKI systems. The IETF-approved way of checking a certificate's validity is the Online Certificate Status Protocol (OCSP). Firefox 3 enables OCSP checking by default.

[edit] Structure of a certificate

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

Issuer and subject unique identifiers were introduced in Version 2, Extensions in Version 3. Nevertheless, the Serial number must be unique for each certificate issued by a specific CA (as mentioned in RFC 2459).

[edit] Certificate filename extensions

Common filename extensions for X.509 certificates are:

• .pem - (Privacy Enhanced Mail) Base64 encoded DER certificate, enclosed between "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----"

• .cer, .crt, .der - usually in binary DER form, but Base64-encoded certificates are common too (see .pem above)

• .p7b, .p7c - PKCS#7 SignedData structure without data, just certificate(s) or CRL(s)

• .p12 - PKCS#12, may contain certificate(s) (public) and private keys (password protected)

• .pfx - PFX, predecessor of PKCS#12 (but most of the time the actual data is PKCS#12, only the extension is kept)

PKCS#7 is a standard for signing or encrypting (officially called "enveloping") data. Since the certificate is needed to verify signed data, it is possible to include them in the SignedData structure. A .P7C file is just a degenerated SignedData structure, without any data to sign.

PKCS#12 evolved from the PFX (Personal inFormation eXchange) standard and is used to exchange public and private objects in a single file.

A .PEM-file may contain certificate(s) or private key(s), enclosed between the appropriate BEGIN/END-lines (CERTIFICATE or RSA PRIVATE KEY).

[edit] Sample X.509 certificates

This is an example of a decoded X.509 certificate for www.freesoft.org, generated with OpenSSL -- the actual certificate is about 1KB in size. It was issued by Thawte (since acquired by VeriSign), as stated in the Issuer field. Its subject contains many personal details, but the most important part is usually the common name (CN), as this is the part that must match the host being authenticated. Also included is an RSA public key (modulus and public exponent), followed by the signature, computed by taking a MD5 hash of the first part of the certificate and encrypting it with Thawte's RSA private key.

 Certificate:    Data:        Version: 1 (0x0)        Serial Number: 7829 (0x1e95)        Signature Algorithm: md5WithRSAEncryption        Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc,                OU=Certification Services Division,                CN=Thawte Server CA/emailAddress=server-certs@thawte.com        Validity            Not Before: Jul  9 16:04:02 1998 GMT            Not After : Jul  9 16:04:02 1999 GMT        Subject: C=US, ST=Maryland, L=Pasadena, O=Brent Baccala,                 OU=FreeSoft, CN=www.freesoft.org/emailAddress=baccala@freesoft.org        Subject Public Key Info:            Public Key Algorithm: rsaEncryption            RSA Public Key: (1024 bit)                Modulus (1024 bit):                    00:b4:31:98:0a:c4:bc:62:c1:88:aa:dc:b0:c8:bb:                    33:35:19:d5:0c:64:b9:3d:41:b2:96:fc:f3:31:e1:                    66:36:d0:8e:56:12:44:ba:75:eb:e8:1c:9c:5b:66:                    70:33:52:14:c9:ec:4f:91:51:70:39:de:53:85:17:                    16:94:6e:ee:f4:d5:6f:d5:ca:b3:47:5e:1b:0c:7b:                    c5:cc:2b:6b:c1:90:c3:16:31:0d:bf:7a:c7:47:77:                    8f:a0:21:c7:4c:d0:16:65:00:c1:0f:d7:b8:80:e3:                    d2:75:6b:c1:ea:9e:5c:5c:ea:7d:c1:a1:10:bc:b8:                    e8:35:1c:9e:27:52:7e:41:8f                Exponent: 65537 (0x10001)    Signature Algorithm: md5WithRSAEncryption        93:5f:8f:5f:c5:af:bf:0a:ab:a5:6d:fb:24:5f:b6:59:5d:9d:        92:2e:4a:1b:8b:ac:7d:99:17:5d:cd:19:f6:ad:ef:63:2f:92:        ab:2f:4b:cf:0a:13:90:ee:2c:0e:43:03:be:f6:ea:8e:9c:67:        d0:a2:40:03:f7:ef:6a:15:09:79:a9:46:ed:b7:16:1b:41:72:        0d:19:aa:ad:dd:9a:df:ab:97:50:65:f5:5e:85:a6:ef:19:d1:        5a:de:9d:ea:63:cd:cb:cc:6d:5d:01:85:b5:6d:c8:f3:d9:f7:        8f:0e:fc:ba:1f:34:e9:96:6e:6c:cf:f2:ef:9b:bf:de:b5:22:        68:9f 

To validate this certificate, one needs a second certificate that matches the Issuer (Thawte Server CA) of the first certificate. First, one verifies that the second certificate is of a CA kind; that is, that it can be used to issue other certificates. This is done by inspecting a value of the CA attribute in the X509v3 extension section. Then the RSA public key from the CA certificate is used to decode the signature on the first certificate to obtain a MD5 hash, which must match an actual MD5 hash computed over the rest of the certificate. An example CA certificate follows:

 Certificate:    Data:        Version: 3 (0x2)        Serial Number: 1 (0x1)        Signature Algorithm: md5WithRSAEncryption        Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc,                OU=Certification Services Division,                CN=Thawte Server CA/emailAddress=server-certs@thawte.com        Validity            Not Before: Aug  1 00:00:00 1996 GMT            Not After : Dec 31 23:59:59 2020 GMT        Subject: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc,                 OU=Certification Services Division,                 CN=Thawte Server CA/emailAddress=server-certs@thawte.com        Subject Public Key Info:            Public Key Algorithm: rsaEncryption            RSA Public Key: (1024 bit)                Modulus (1024 bit):                    00:d3:a4:50:6e:c8:ff:56:6b:e6:cf:5d:b6:ea:0c:                    68:75:47:a2:aa:c2:da:84:25:fc:a8:f4:47:51:da:                    85:b5:20:74:94:86:1e:0f:75:c9:e9:08:61:f5:06:                    6d:30:6e:15:19:02:e9:52:c0:62:db:4d:99:9e:e2:                    6a:0c:44:38:cd:fe:be:e3:64:09:70:c5:fe:b1:6b:                    29:b6:2f:49:c8:3b:d4:27:04:25:10:97:2f:e7:90:                    6d:c0:28:42:99:d7:4c:43:de:c3:f5:21:6d:54:9f:                    5d:c3:58:e1:c0:e4:d9:5b:b0:b8:dc:b4:7b:df:36:                    3a:c2:b5:66:22:12:d6:87:0d                Exponent: 65537 (0x10001)        X509v3 extensions:            X509v3 Basic Constraints: critical                CA:TRUE    Signature Algorithm: md5WithRSAEncryption        07:fa:4c:69:5c:fb:95:cc:46:ee:85:83:4d:21:30:8e:ca:d9:        a8:6f:49:1a:e6:da:51:e3:60:70:6c:84:61:11:a1:1a:c8:48:        3e:59:43:7d:4f:95:3d:a1:8b:b7:0b:62:98:7a:75:8a:dd:88:        4e:4e:9e:40:db:a8:cc:32:74:b9:6f:0d:c6:e3:b3:44:0b:d9:        8a:6f:9a:29:9b:99:18:28:3b:d1:e3:40:28:9a:5a:3c:d5:b5:        e7:20:1b:8b:ca:a4:ab:8d:e9:51:d9:e2:4c:2c:59:a9:da:b9:        b2:75:1b:f6:42:f2:ef:c7:f2:18:f9:89:bc:a3:ff:8a:23:2e:        70:47 

This is an example of a self-signed certificate, as the issuer and subject are the same. There's no way to verify this certificate except by checking it against itself; instead, these top-level certificates are manually stored by web browsers. Thawte is one of the root certificate authorities recognized by both Microsoft and Netscape. This certificate comes with the web browser and is trusted by default. As a long-lived, globally trusted certificate that can sign anything (as there are no constraints in the X509v3 Basic Constraints section), its matching private key has to be closely guarded.

[edit] Security

In 2005, Arjen Lenstra and Benne de Weger demonstrated "how to use hash collisions to construct two X.509 certificates that contain identical signatures and that differ only in the public keys," achieved using a collision attack on the MD5 hash function. [1]

In 2008, Alexander Sotirov and Marc Stevens presented at the Chaos Communication Congress a practical attack that allowed them to create a rogue Certificate Authority, accepted by all common browsers, by exploiting the fact that RapidSSL was still issuing X.509 certificates based on MD5 [2].

X.509 certificates based on SHA-1 had been deemed to be secure up until very recent times. In April of 2009 at the Eurocrypt Conference, Australian Researchers of Macquarie University presented "Automatic Differential Path Searching for SHA-1". The researchers were able to deduce a method which increases the likelihood of a collision by several orders of magnitude. ^[1]

[edit] PKI Standards for X.509

• PKCS#7 (Cryptographic Message Syntax Standard - public keys with proof of identity for signed and/or encrypted message for PKI)
• Secure Sockets Layer (SSL) - cryptographic protocols for internet secure communications ^[2]
• Online Certificate Status Protocol (OCSP) / Certificate Revocation List (CRL) - this is for validating proof of identity
• PKCS#12 (Personal Information Exchange Syntax Standard) - used to store a private key with the appropriate public key certificate

[edit] Certificate authority

A certificate authority or certification authority (CA) is an entity which issues digital certificates for use by other parties. It is an example of a trusted third party. CAs are characteristic of many public key infrastructure (PKI) schemes.

There are many commercial CAs that charge for their services. Institutions and governments may have their own CAs, and there are free CAs.

[edit] Public-Key Infrastructure (X.509) Working Group

The Public-Key Infrastructure (X.509) working group (PKIX) is a working group of the Internet Engineering Task Force dedicated to creating RFCs and other standards documentation on issues related to public key infrastructure based on X.509 certificates. PKIX was established in Autumn 1995.

This section requires expansion.

[edit] See also

• Digital Certificate
• Digital Signature
• Trusted timestamping
• Public Key
• Public Key Infrastructure (PKI)
• Certificate Authority
• Certificate server
• Pretty Good Privacy (PGP)
• Certificate Policy
• Online Certificate Status Protocol (OCSP)
• Certificate Revocation List (CRL)
• ISO/IEC
• Computer security
• Information security
• Communications security
• Code access security
• Time stamp protocol

[edit] Protocols and Standards supporting X.509 certificates

• Transport Layer Security (TLS/SSL)
• Secure Multipurpose Internet Mail Extensions (S/MIME)
• IPsec
• SSH
• Smartcard
• HTTPS
• Extensible Authentication Protocol
• Lightweight Directory Access Protocol
• Trusted Computing Group (TNC TPM NGSCB)
• CableLabs (North American Cable Industry Technology Forum)
• WS-Security
• XMPP

This section requires expansion.

[edit] References

• [ITU-T Recommendation X.509] [3] (2005): Information Technology - Open Systems Interconnection - The Directory: Authentication Framework, 08/05.
• C. Adams, S. Farrell, "Internet X.509 Public Key Infrastructure: Certificate Management Protocols", RFC 2510, March 1999
• Housley, R., W. Ford, W. Polk and D. Solo, "Internet X.509 Public Key Infrastructure: Certificate and CRL Profile", RFC 3280, April 2002. Obsoleted by RFC 5280, Obsoletes RFC 2459/ updated by RFC 4325, RFC 4630.
• Housley, R., W. Ford, W. Polk and D. Solo, "Internet X.509 Public Key Infrastructure: Certificate and CRL Profile", RFC 2459, January 1999. Obsoleted by RFC 3280.
• Arjen Lenstra, Xiaoyun Wang and Benne de Weger, On the possibility of constructing meaningful hash collisions for public keys, full version, with an appendix on colliding X.509 certificates, 2005 [4] (see also [5]).

[edit] External links

• ITU-X Recommendation X.509 : Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks
• Peter Gutmann's articles, an overview of PKI [6], X.509 implementation notes X.509 Style Guide
• PKIX website
• PEM decoder Online tool, based on OpenSSL, to decode PEM-formatted X.509 certificates
• Enterprise Trust Integration and Web Services Security standards and demos
• FAQ from RSA Labs
• Sun Inc. - Secure code guidelines
• RFC 4158 - Internet X.509 Public Key Infrastructure: Certification Path Building