Internet & Intranet Security

19.4 IETF PKIX WG

In 1995, the IETF recognized the importance of public key certificates, and chartered an IETF Public-Key Infrastructure X.509 (PKIX^[6]) WG with the intent of developing Internet Standards needed to support an X.509-based PKI for the Internet community. In the past, the 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 subjects and end entities,^[7] CAs, and registration authorities (RAs).^[8] 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 any PKI architecture, RAs are optional components that are transparent to the end entities (when they are not present, the CA is assumed to be able to carry out the RAs' functions so that the PKI management protocols are the same from the end entities' point of view). Finally, the certificates generated by the CAs may be made publicly available in certificate repositories (e.g., network services that are available on-line).

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 [17] profiles the format and semantics of X.509v3 certificates and X.509v2 certificate revocation lists (CRLs^[9]) 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 [18] 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 [19] 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 [20] presents a framework to assist the 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 [21] profiles the format and semantics of the field in X.509v3 certificates containing cryptographic keys for the KEA.^[10]

• Standards track RFC 2559 [22] 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 [23], defining a profile of LDAP for use within the X.509-based PKI for the Internet. In addition, RFC 2587 [24] defines a minimal schema to support PKIX in an LDAPv2 environment, as defined in RFC 2559.

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

• Standards track RFC 2560 [26] specifies an Online Certificate Status Protocol (OCSP) that is useful in determining the current status of a digital certificate. The OCSP will be briefly addressed in Section 19.5.2.

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

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

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

• Finally, the experimental RFC 3029 [30] 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 non-repudiation 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).

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 PKIX WG 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 industry is to make commercial PKI products "PKIX compliant," and this trend is likely to continue in the future.

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

^[7]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.

^[8]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.

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

^[10]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/skipjack-kea.htm for a specification of the Skipjack and KEA algorithms.

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

^[12]The term qualified certificate is used to describe a certificate with a certain qualified status within applicable governing law.