X.509

From Wikipedia, the free encyclopedia

In cryptography, X.509 is an ITU-T standard for a public key infrastructure (PKI) 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.

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[citation needed], but was rarely used that way as of 2004. The X.500 system has only ever been implemented by sovereign nations for state identity information sharing treaty fulfillment purposes, 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).[citation needed]

Certificates

In the X.509 system, a certification authority 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.[citation needed]

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, Firefox, Opera, Safari and Chrome come with a predetermined set of 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.[citation needed]

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 along with versions of Windows including Vista and later.[citation needed]

Structure of a 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

Each extension has its own id, expressed as Object identifier, which is a set of values, together with either a critical or non-critical indication. A certificate-using system MUST reject the certificate if it encounters a critical extension that it does not recognize, or a critical extension that contains information that it cannot process. A non-critical extension MAY be ignored if it is not recognized, but MUST be processed if it is recognized.[1]

The structure of Version 1 is given in RFC 1422.

ITU-T introduced issuer and subject unique identifiers in version 2 to permit the reuse of issuer or subject name after some time. An example of reuse will be when a CA goes bankrupt and its name is deleted from the country's public list. After some time another CA with the same name may register itself, even though it is unrelated to the first one. However, IETF recommends that no issuer and subject names be reused. Therefore, version 2 is not widely deployed in the Internet.[citation needed]

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.[citation needed]

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

Extensions informing a specific usage of a certificate

RFC 5280 (and its predecessors) defines a number of certificate extensions which indicate how the certificate should be used. Most of them are arcs from the joint-iso-ccitt(2) ds(5) id-ce(29) OID. Some of the most common, defined in section 4.2.1, are:

  • Basic Constraints, { id-ce 19 },[2] are used to indicate whether the certificate belongs to a CA.
  • Key Usage, { id-ce 15 },[3] 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 },[4] 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.[5]

Certificate filename extensions

Common filename extensions for X.509 certificates are:[citation needed]

  • .pem – (Privacy-enhanced Electronic 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 (usually contains data in PKCS#12 format, e.g., with PFX files generated in IIS)

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 a degenerated SignedData structure, without any data to sign.[citation needed]

PKCS#12 evolved from the personal information exchange (PFX) standard and is used to exchange public and private objects in a single file.[citation needed]

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 1 kB in size. It was issued by Thawte (since acquired by VeriSign and now owned by Symantec), 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 signing it (applying the encryption operation) using Thawte's RSA private key.

$ openssl x509 -in freesoft-certificate.pem -noout -text
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:

$ openssl x509 -in thawte-ca-certificate.pem -noout -text
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.

Security

There are a number of publications about PKI problems by Bruce Schneier, Peter Gutmann and other security experts.[6][7][8]

Certificate complexity

A majority of Internet users, either business or social, currently lack the basic ability, knowledge and willingness to effectively use cryptographic applications in a way that can successfully deter imminent threats[citation needed]. The complexity of this task is one of the weaknesses of public key cryptography. A lack of user friendliness and overall usability thus affects solution efficiency.[9] To deal with such issues, software companies have included a bundle of root certificates, which have been audited for security purposes, into user browsers and operating systems. For the sake of user friendliness and interoperability, all web browsers and operating systems currently contain this audited Trusted Root Store of certificate issuing authorities. Certificates issued by these organizations, or their subordinate authorities, are transparently trusted by relying entities. These certificates are automatically deemed as secure and trustworthy, as opposed to those issued by “unknown” issuers, which a relying party is warned not to trust. This interprets into certificates published by all authorities that have not been included in the root store. This approach attempts to make the provision of system security automatic and transparent, and essentially removes from the end user the decision making process about the trustworthiness of web entities.[9]

The X.509 standard was primarily designed to support the X.500 structure, but today's use cases center around the web. Many features are of little or no relevance today. The X.509 specification suffers from being over-functional and underspecified and the normative information is spread across many documents from different standardization bodies. Several profiles were developed to solve this, but these introduce interoperability issues and did not fix the problem.

Architectural weaknesses

  • Use of blacklisting invalid certificates (using CRLs and OCSP) instead of whitelisting,
  • CRLs are notably a poor choice because of large sizes and convoluted distribution patterns,
  • Ambiguous OCSP semantics and lack of historical revocation status,
  • Revocation of root certificates is not addressed,
  • Aggregation problem: Identity claims (authenticate with an identifier), attribute claims (submit a bag of vetted attributes), and policy claims are combined in a single container. This raises privacy, policy mapping, and maintenance issues,
  • Delegation problem: CAs cannot technically restrict subordinate CAs from issuing certificates outside a limited namespaces or attribute set; this feature of X.509 is not in use. Therefore a large number of CAs exist on the Internet, and classifying them and their policies is an insurmountable task. Delegation of authority within an organization cannot be handled at all, as in common business practice.
  • Federation problem: Certificate chains that are the result of subordinate CAs, bridge CAs, and cross-signing make validation complex and expensive in terms of processing time. Path validation semantics may be ambiguous. The hierarchy with a third-party trusted party is the only model. This is inconvenient when a bilateral trust relationship is already in place.

Problems with certificate authorities

  • The subject, not the relying party, purchases certificates. The subject will often utilize the cheapest issuer, so quality is not being paid for in the competing market. This is partly addressed by Extended Validation certificates.
  • Certification authorities deny almost all warranties to the user (including subject or even relying parties).
  • The expiration date should be used to limit the time the key strength is deemed sufficient. This parameter is abused by certification authorities to charge the client an extension fee. This places an unnecessary burden on the user with key roll-over.
  • "Users use an undefined certification request protocol to obtain a certificate which is published in an unclear location in a nonexistent directory with no real means to revoke it." [8]
  • Like all businesses, CAs are subject to the legal jurisdiction(s) of their site(s) of operation, and may be legally compelled to compromise the interests of their customers and their users. Intelligence agencies have also made use of false certificates issued through extralegal compromise of CAs, such as DigiNotar, to carry out Man-In-The-Middle attacks.

Implementation issues

Implementations suffer from design flaws, bugs, different interpretations of standards and lack of interoperability of different standards. Some problems are:[citation needed]

  • Many implementations turn off revocation check:
    • Seen as obstacle, policies are not enforced
    • If it was turned on in all browsers by default, including code signing, it would probably crash the infrastructure.
  • DNs are complex and little understood (lack of canonicalization, internationalization problems, ..)
  • rfc822Name has two notations
  • Name and policy constraints hardly supported
  • Key usage ignored, first certificate in a list being used
  • Enforcement of custom OIDs is difficult
  • Attributes should not be made critical because it makes clients crash.
  • Unspecified length of attributes lead to product-specific limits

Exploits

  • MD2-based certificates were used for a long time and were vulnerable to preimage attacks. Since the root certificate already had a self-signature, attackers could use this signature and use it for an intermediate certificate.
  • 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.[10]
  • 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.[11]
  • X.509 certificates based on SHA-1 had been deemed to be secure up until very recent times. In April 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.[12]
  • EV-certificates are of very limited help, because Browsers do not have policies that disallow EV-certificates, Zusman and Sotirov Blackhat 2009
  • There are implementation errors with X.509 that allow e.g. falsified subject names using null-terminated strings Marlinspike Blackhat 2009 or code injections attacks in certificates.
  • By using illegal[13] 0x80 padded subidentifiers of Object Identifiers, wrong implementations or by using integer-overflows of the client's browsers, an attacker can include an unknown attribute in the CSR, which the CA will sign, which the client wrongly interprets as "CN" (OID=2.5.4.3). Dan Kaminsky at the 26th Chaos Communication Congress "Black OPs of PKI"[14]

PKI standards for X.509

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

Certification authority

Main article: Certificate authority

A 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.[citation needed]

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

Public-Key Infrastructure (X.509) Working Group

The The Public-Key Infrastructure (X.509) working group (PKIX) was a working group of the Internet Engineering Task Force dedicated to creating RFCs and other standard documentation on issues related to public key infrastructure based on X.509 certificates. PKIX was established in Autumn 1995 in conjunction with the National Institute of Standards and Technology.[15] The Working Group was closed in November 2013.

Protocols and standards supporting X.509 certificates

See also

References

  1. ↑ [http://tools.ietf.org/html/rfc5280#section-4.2, retrieved 12 February 2013]
  2. ↑ "RFC 5280, Section "Basic Constraints"". 
  3. ↑ "RFC 5280, Section "Key Usage"". 
  4. ↑ "RFC 5280, Section "Extended Key Usage"". 
  5. ↑ All About Certificate Extensions
  6. ↑ Carl Ellison and Bruce Schneier. "Top 10 PKI risks". Computer Security Journal (Volume XVI, Number 1, 2000). 
  7. ↑ Peter Gutmann. "PKI: it's not dead, just resting". IEEE Computer (Volume:35, Issue: 8). 
  8. ↑ 8.0 8.1 Gutmann, Peter. "Everything you Never Wanted to Know about PKI but were Forced to Find Out". Retrieved 14 November 2011. 
  9. ↑ 9.0 9.1 Zissis, D. & Lekkas, D., “Trust coercion in the name of usable Public Key Infrastructure”, Security And Communication Networks, John Wiley & Sons, (2013)
  10. ↑ Lenstra, Arjen; de Weger, Benne (2005-05-19). On the possibility of constructing meaningful hash collisions for public keys (Technical report). Murray Hill, NJ, USA & Eindhoven, The Netherlands: Lucent Technologies, Bell Laboratories & Technische Universiteit Eindhoven. Archived from the original on 2013-05-01. Retrieved 2013-09-28. 
  11. ↑ "MD5 considered harmful today". Win.tue.nl. Retrieved 2013-09-29. 
  12. ↑ SHA-1 Collision Attacks Now 252
  13. ↑ Rec. ITU-T X.690, clause 8.19.2
  14. ↑ "26C3: Black Ops Of PKI". Events.ccc.de. Retrieved 2013-09-29. 
  15. ↑ "Public-Key Infrastructure (X.509) (pkix) - Charter". datatracker.ietf.org. Fremont, CA, USA: Internet Engineering Task Force. Retrieved 2013-10-01. 0
General
  • ITU-T Recommendation X.509 (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 (see also ).

External links

This article is issued from Wikipedia. The text is available under the Creative Commons Attribution/Share Alike; additional terms may apply for the media files.