Security Technologies for the World Wide Web, Second Edition

7.3    IETF PKIX WG

In 1995, the IETF recognized the importance of public key certificates, and chartered an IETF Public-Key Infrastructure X.509 (PKIX ^[9] ) WG with the intent of developing Internet Standards needed to support an X.509-based PKI for the Internet community. ^[10] In the past, the IETF PKIX WG has initiated and stimulated a lot of standardization and profiling activities within the IETF. It is closely aligned with the activities within the ITU-T.

The operational model of the IETF PKIX WG consists of end entities, ^[11] CAs, and registration authorities (RAs). ^[12] The functions that the RA may carry out will vary from case to case but may include personal authentication, token distribution, certificate revocation reporting, name assignment, key generation, and key archival. In fact, a CA can delegate some of its authorities (apart from certificate signing) to an RA. Consequently, RAs are optional components that are transparent to the end entities. Finally, the certificates generated by the CAs may be made available in on-line directories and certificate repositories. ^[13]

According to this operational model, several informational, experimental, and standards track RFC documents in support of the original goals of the IETF PKIX WG have been approved by the IESG:

• Standards track RFC 2459 [15] profiles the format and semantics of X.509v3 certificates and X.509v2 certificate revocation lists (CRLs ^[14] ) for use on the Internet. As such, it describes in detail the X.509v3 certificate format and its standard and Internet-specific extension fields, as well as the X.509v2 CRL format and a required extension set. Finally, the RFC also describes an algorithm for X.509 certificate path validation and provides ASN.1 specifications for all data structures that are used in the profiles.

• Standards track RFC 2510 [16] describes the various certificate management protocols that are supposed to be used in an X.509-based PKI for the Internet.

• More specifically , standards track RFC 2511 [17] specifies the syntax and semantics of the Internet X.509 certificate request message format (CRMF) that is used to convey a request for a certificate to a CA (possibly via an RA) for the purpose of X.509 certificate production. The request typically includes a public key and some related registration information.

• Informational RFC 2527 [18] presents a framework to assist writers of certificate policies and certificate practice statements (CPS) for CAs and PKIs. More specifically, the framework provides a comprehensive list of topics that potentially need to be covered in a certificate policy definition or CPS. Note that the framework needs to be customized in a particular operational environment.

• Informational RFC 2528 [19] profiles the format and semantics of the field in X.509v3 certificates containing cryptographic keys for the Key Exchange Algorithm (KEA). ^[15]

• Standards track RFC 2559 [20] addresses requirements to provide access to certificate repositories for the purpose of retrieving PKI information and managing that information. The mechanism is based on the Lightweight Directory Access Protocol (LDAP) as specified in RFC 1777 [21], defining a profile of LDAP for use within the X.509-based PKI for the Internet. In addition, RFC 2587 [22] defines a minimal schema to support PKIX in an LDAPv2 environment, as defined in RFC 2559.

• Standards track RFC 2585 [23] specifies the conventions for using FTP and HTTP to obtain certificates and CRLs from certificate repositories.

• Standards track RFC 2560 [24] specifies an Online Certificate Status Protocol (OCSP) that is useful in determining the current status of a digital certificate.

• Standards track RFC 2797 [25] specifies a certificate management protocol using the cryptographic message syntax (CMS). The resulting protocol has the acronym CMC.

• Standards track RFC 2875 [26] specifies two methods for producing an integrity check value from a Diffie-Hellman key pair. ^[16]

• Standards track RFC 3039 [27] forms a certificate profile for qualified certificates, ^[17] based on RFC 2459, for Internet use.

• The experimental RFC 3029 [28] describes a general data validation and certification server (DVCS) and the protocols to be used when communicating with it. In short, the DVCS is a TTP that can be used as one component in building reliable nonrepudiation services. It is designed to provide data validation services, asserting correctness of digitally signed documents, validity of public key certificates, and possession or existence of data. As a result of a validation process, the DVCS generates a data validation certificate (DVC).

• Finally, standards track RFC 3039 [29] elaborates on a Time-Stamp Protocol that can be used to provide a time stamping service. More specifically, it specifies the format of a request sent to a Time Stamping Authority (TSA) and of the response that is eventually returned.

In summary, the RFC documents itemized above specify an X.509-based PKI for the Internet community. This evolving PKI is sometimes also referred to as Internet X.509 Public Key Infrastructure (IPKI). As of this writing, the RFC documents that specify the IPKI refer to Proposed Standards.

The number of RFC documents that specify various aspects of the IPKI will certainly grow in the future, since a lot of work is done to further refine the IPKI and its operational protocols and procedures. In fact, the number of RFC documents specifying the IPKI will certainly have increased by the time you read this book. Refer to the IETF PKIXWG home page to get a complete and more comprehensive overview about the RFC and Internet-Draft documents that are currently available. The current trend in the industry is to make commercial PKI products ˜ ˜PKIX compliant, and this trend is likely to continue in the future.

^[9] Note, however, that ITU-T X.509 does not embody a hierarchic trust model. The existence of cross-certificates, as well as forward and reverse certificates, makes the X.509 model a mesh, analogous in some ways to PGP s web of trust. The X.509 model is often erroneously characterized as a hierarchic trust model because it is usually mapped to the directory information tree (DIT), which is hierarchic , more like name schemes.

^[10] http://www.ietf.org/html. charters /pkix-charter.html

^[11] In addition to the PKIX WG, the IETF also chartered another WG to address PKI issues. As mentioned above, this WG was called IETF Simple Public Key Infrastructure (SPKI) WG and was abandoned in 2001.

^[12] In the specifications of the IETF PKIX WG, the term end entity is used rather than the term subject to avoid confusion with the X.509v3 certificate field of the same name.

^[13] Other terms are used elsewhere for the functionality of an RA. For example, the term local registration agent (LRA) is used in ANSI X9 standards, local registration authority (also with the acronym LRA) is used in [3], organizational registration agent (ORA) is used in certain U.S. government specifications, and registration agent (RA) has also been used elsewhere.

^[14] The term certificate repositories is often used in the RFC documents of the IETF PKIX WG. Therefore, it is also used in this book.

^[15] The notion of a CRL will be introduced and discussed in Section 7.4.1.

^[16] The KEA is a key exchange algorithm that was originally proposed by NIST for use together with the Skipjack encryption algorithm in Clipper and Fortezza chips. Refer to http://csrc.nist.gov/encryption/skipjackkea.html for specification of the Skipjack and KEA algorithms.

^[17] This behavior is needed for such operations as creating the signature of a PKCS #10 certification request. These algorithms are designed to provide proof of possession rather than general-purpose signing.