NOTE: This charter is a snapshot of that in effect at the time of the 38th IETF Meeting in Memphis, Tennessee. It may now be out-of-date.
Steve Kent <kent@bbn.com>
Warwick Ford <wford@verisign.com>
Jeffrey Schiller <jis@mit.edu>
General Discussion:ietf-pkix@tandem.com
To Subscribe: listserv@tandem.com
In Body: subscribe <email address> ietf-pkix
Archive: ftp://ftp.tandem.com/ietf/mailing-lists/current
Many Internet protocols and applications which use the Internet employ public-key technology for security purposes and require a public-key infrastructure (PKI) to securely manage public keys for widely-distributed users or systems. The X.509 standard constitutes a widely-accepted basis for such an infrastructure, defining data formats and procedures related to distribution of public keys via certificates digitally signed by certification authorities (CAs). RFC 1422 specified the basis of an X.509-based PKI, targeted primarily at satisfying the needs of Internet Privacy Enhanced Mail (PEM). Since RFC 1422 was issued, application requirements for an Internet PKI have broadened tremendously, and the capabilities of X.509 have advanced with the development of standards defining the X.509 version 3 certificate and version 2 certificate revocation list (CRL).
The task of the working group will be to develop Internet standards needed to support an X.509-based PKI. The goal of this PKI will be to facilitate the use of X.509 certificates in multiple applications that make use of the Internet and to promote interoperability between different implementations choosing to make use of X.509 certificates. The resulting PKI is intended to provide a framework which will support a range of trust/hierarchy environments and a range of usage environments (RFC1422 is an example of one such model).
Candidate applications to be served by this PKI include, but are not limited to, PEM, MOSS, GSS-API mechanisms (e.g., SPKM), ipsec protocols, Internet payment protocols, and www protocols. This project will not preclude use of non-infrastructural public-key distribution techniques nor of non-X.509 PKIs by such applications. Efforts will be made to coordinate with the IETF White Pages (X.500/WHOIS++) project.
The group will focus on tailoring and profiling the features available in the v3 X.509 certificate to best match the requirements and characteristics of the Internet environment. Other topics to be addressed potentially include:
· Alternatives for CA-to-CA certification links and structures, including guidelines for constraints · Revocation alternatives, including profiling of X.509 v2 CRL extensions · Certificate and CRL distribution options (X.500-based, non-X.500-based) · Guidelines for policy definition and registration · Administrative protocols and procedures, including certificate generation, revocation notification, cross-certification, and key-pair updating · Naming and name forms (how entities are identified, e.g., email address, URN, DN, misc.) · Generation of client key pairs by the PKIGoals and Milestones:
· Internet Public Key Infrastructure Part I: X.509 Certificate and CRL Profile
· Internet Public Key Infrastructure Part III: Certificate Management Protocols
· Architecture for Public-Key Infrastructure
· Internet Public Key Infrastructure Part 2: Operational Protocols
· Internet Public Key Infrastructure Part IV: Certificate Policy and Certification Practices Framework
Minutes of the Public-Key Infrastructure (PKIX) Working Group
Reported by: Michael Myers, VeriSignSummaryThe PKIX Working Group met in two sessions at the April 1997 IETF meeting in Memphis. The main agenda topics were status briefings on Parts 1, 3 and 4 of the PKIX document set and an initial briefing Part 2. In the follow-up session, several technical amendments were proposed, discussed and moved forward.
There was an informational presentation drawing attention to an alternative certificate management protocol based on HTTP and HTML technology. This information was presented for the Working Group's consideration in the development of the IETF Standard Certificate Management Protocol.
Parts 1 and 3 will transition to Working Group last call following this IETF. Part 2 will take longer, but is also targeted for standards track. Part 4 provides guidance for authors of certificate policies and certification practice statements, and is targeted for an Informational RFC. Additional work is expected in the areas of Attribute Certificates and their relationship to access control, Timestamping and Notarial services, and the evolution of PKCS #10.
Part 1: Certificate and CRL Profiles
Tim Polk presented the changes to Part 1 between the December 1996 draft and the current draft. These were:
· Reduced private extensions from three to two, both non-critical
· Eliminated sliding window for time encoding, instead a fixed date.
· URIs in alt name fields point to certificates in repositories
· URI in authority InfoAccess points to on-line validation service
· Cylink patent statement added
· ASN.1 is believed complete
· ASN.1 EXPLICIT/IMPLICIT problems corrected
Open Issues:
· RSA patent statement still outstanding, should be resolved soon.
· ASN.1 checking (check '88 versus '93 constructs)
It is the intent of the Working Group that Part 1 will go to Working Group Last Call following this IETF.
KEA is an unpublished algorithm. References to it in Part 1 should be removed.
Resolution: References to KEA will be removed from Part 1. Parties interested in such a specification may publish an Informational Draft addressing the issue.
The RSA patent statement is still an outstanding issue, but it should be resolved soon.
Resolution: Tim Polk will take action to move this issue to closure.
The current draft indicates 1996 date, should be changed to indicate a 1997 date.
Resolution: The document will be changed to reflect the correct expiration date. The title of the Part 1 document correctly indicates version 4.
Sharon Boeyen presented the work to date on Part 2 regarding the use of
LDAP and FTP for retrieval of certificates and CRLs and the requirements
for and specification of an Online Certificate Status Protocol (OCSP).
Should we consider splitting the document into two separate ones, since the OCSP is a new protocol definition that may require significantly more review and discussion than the LDAP and FTP profiles?
Resolution: Although we agree that OCSP may require additional review, the document will remain a single draft and we will re-address this issue, if the OCSP discussion is such that it will require a longer review period and impede progression of the remainder of the document.
A question was raised about privacy when searching directories via LDAP (e.g., email addresses may not be made public).
Resolution: The intent of PKIX Part 2 is NOT to suggest that any attributes need to be made public. If some attributes, such as email addresses, happen to be public information, then the LDAP profile defined in PKIX Part 2 will support searching on such attributes.
A question raised regarding the requirement of a public key operation on each OCSP validation operation and had there been any consideration given to ways to reduce that requirement.
Resolution: Some support for reducing the load on the server can be provided by caching signed responses for frequently requested certificates.
A question was raised on the specific contents of a ".cer" file.
Resolution: Each .cer file contains exactly one certificate, encoded in DER format.
LDAP profile for adding, modifying, deleting PKI information was raised as an issue - should these operations be added to PKIX Part 3 (since they are data management operations) or should they be added to PKIX Part 2 (keeping the complete LDAP profile together).
Resolution: The LDAP operations will be profiled in PKIX Part 2 and appropriate references added to PKIX Part 3.
Resolution: The progress of LDAP v3 will be tracked and when stable, consideration will be given to moving this profile from v2 to v3. V3 support for strong authentication will probably help satisfy some concerns raised over the ability of someone to masquerade as a repository.
Carlisle Adams presented the current state of Part 3. The current draft currently resides on Entrust's web server at www.entrust.com. It will be moved to the Internet Drafts directory after the IETF.
Substantive changes from the previous draft:
· Addition of PKCS 10 as a valid certification request message.
· Recognition of PKCS 7 as an alternate security protocol.
· Text regarding Proof of Possession (POP) of a private key.
· Added a challenge-response mechanism in support of Registration Authorities.
It is the intent of the Working Group that Part 3 will go to Working Group Last Call following this IETF.
It was pointed out that the current statement regarding PKCS 10 usage is overly specific as to the allowable context of its use.Resolution: The text will be amended to generally accommodate PKCS 10 requests.At the San Jose meeting, a general consensus was established within the Working Group that evolutionary support for PKCS 7 & PKCS 10 is desirable as an alternative to PKIX Part 3. A question was raised regarding the current status of this issue.
Resolution: It should be expected that work will be performed to advance PKCS 10 forward to address requirements met by Part 3.
More flexibility in the statements regarding requirements on POP is desired.
Resolution: The editor will amend the text to express more fully the intended flexibility.
A question was raised concerning the exact definition of "operational protocols."
Resolution: The term "operational protocols" within PKIX refers to those relevant to delivering PKI services. Application protocols, e.g., S/MIME or TLS, are out of scope.
It was noted that there is no means to indicate a type of CA in the certification request.
Resolution: Type of CA is defined by policy OID or by reading the CPS.
The challenge-response protocol appears to be predicated upon state information established during prior message exchanges. Is it possible to reduce a registration process using this protocol to a single exchange?
Resolution: A requirement for a single-pass exchange in this instance cannot be met by the challenge-response protocol as defined. It should also be noted that the protocol in question only addresses proof of possession of encryption keys.
In the challenge-response model of registration, can the RA reformat the request received from the subscriber when forwarding it to the CA?
Resolution: Yes. The intent is to establish a general model of Subscriber-RA-CA interaction that is extensible to detailed operational requirements. The RA may choose to simply re-encapsulate the subscriber's request, but is not required to do so. The RA could receive a certificate request in one format and forward to a CA in another format.
It was asked if conformance to Part 3 is defined by the text, or by the tables in Appendix B, or if there should be some other external document-defining conformance.
Resolution: It is the authors' intent that the tables in Appendix B define conformance. A blanket statement will be added to the text to clarify this intent.
Santosh Chokhani presented details on status of Part 4.
A questioner asked if Part 4 is intended to be prescriptive with respect to the Internet.
Resolution: It is beyond the scope of Part 4 to prescribe Internet certificate management policy or acceptable certification practices. Part 4 is informational in nature and is intended as an aid to the development of certificate policies and certification practices statements. Any requirement governing the implementation of automated certificate policy recognition and decision logic will be addressed by Part 1. LDAP could be used to gain access to electronic policy elements, to the extent such policy elements exist.
There was an observation that the document does not discuss storage of CRLs, or the role of repositories generally.
Resolution: It was pointed out that Part 4 does indeed recognize the existence of repositories, their role with respect to CRL distribution and provides some discussion of their relevance to the overall PKI policy management solution. Part 4 does not establish policy; rather, it identifies the elements that may be included in a certificate management policy. It was ultimately recognized that additional work is needed on specific obligations for CRLs and repositories.
It was proposed to the working group that IANA institute procedures to serve as a policy element registration authority for the purpose of establishing PKIX-Internet wide policies.
Resolution: PKIX has an item on "Guidelines for policy definition and registration," but this does not include the definition of specific policies. The proposed initiative lies beyond the original scope discussions of the Working Group. This is also consistent with the general nature of the IETF, which is inherently an Engineering group. It would, however, be reasonable for the IANA to define an OID arc under which certificate policies might be registered. (It was subsequently noted that such an arc already exists.)
Kikuchi Draft: WEB-Based Certificate and CRL Repository
Hiroaki Kikuchi presented an alternative to PKIX Part 3. The proposal addresses an HTML-based value encoding instead of BER encoding for the purposes of human readability. It further presents an alternative text-based protocol for various certificate management functions. A software package--ICAT CA Package ver 1.0, implementing the described functionality is available at: ftp://ftp.icat.or.jp/pub/interauth/icap
It is noted that the proposal needs to be updated to reflect the reduction of PKIX private extensions from three to two.
Part of the proposal involves the use of relative URLs. It was noted this is useful if all operations are confined to a well-known repository; the general case suffers, however. One repository would not work in general.
The HTML is still not all that readable. Hiroaki concurred that some of his colleagues have made the same observation.
It was hypothesized that an HTML representation of a reasonably complex certificate would be substantially larger than its corresponding ASN.1 equivalent. Hiroaki drew attention to the fact that the HTML syntax maps one-to-one to BER encoding rules.
Hiroaki accepted the invitation to write a contribution for Part 2 dealing with the use of HTTP to obtain certificates and CRLs from a repository.
Certificate Storage Interest Group
Christopher Allen of Consensus Development discussed a proposed standardization activity on personal information storage. Schemes under consideration include PFX and a scheme that is substantially simpler than the current PFX proposal. Under the second proposal, all information relevant to the transport of a subscriber's security context would be encapsulated in an "ASCII-armored" format, formatted using base-64 encoding. Internal to the storage context, PKCS 7 would be used for certificate and CRL encapsulation and PKCS 5 and 8 for private keys.
Interested parties are encouraged to participate in a mailing list dedicated to this topic (certstorage-wg@consensus.com, subject: subscribe). If sufficient interest accumulates around the topic, a BOF may be formed at the next IETF to consider moving the topic forward more formally.
Carlisle Adams proposed that PKIX begin work in this area, based on ISO 13888 Part 3. Several members of the Working Group, including representatives from
BBN, Spyrus and VeriSign, offered to participate.
Rodney Thayer, Christopher Allen and Tim Dierks of TLS working group led a discussion on the relationship between TLS and PKIX. Following are issues raised and their corresponding resolution:
It was noted that the current PKIX Part 1 does not spell out use of MD5 as a supported alternative. The text and corresponding examples are inconsistent in their suggestion of MD5 as a requirement. MD5 is required in order to enable the mandatory TLS cipher suite.
Resolution: PKIX Part 1 will be amended to provide the necessary support.
There exists some uncertainty as to the interpretation of KeyUsage bits when applied to the TLS protocol. Part 1 should make explicit the circumstances applicable to given KeyUsage bits.
Resolution: Text will be added to provide additional guidance on the assignment of KeyUsage bits. In particular, it was agreed that DigitalSignature should be set for client certificates, since TLS clients signs an object (the MasterSecret of the TLS protocol). In the case of server authentication, the server's decryption and subsequent successful use of the client's keys (which were encrypted under the server's public) is proof of server authentication. In this case KeyEncipherment shall be set. When ephemeral RSA is used to sign an ephemeral DH key, DigitalSignature shall apply. (See also Extended Key Usage below.)
It is preferable to be able to express name strings containing regular expressions for the purpose of flexible domain administration and load balancing. Clarification was requested as to whether such constructs are to be included in the Subject Name of the base certificate, or in the dNSName variant of SubjectAltName.
Resolution: Use SubjectAltName.
The current key usage bits extension is insufficient to meet needs to identify the full set of purposes for which a public key may be used. The following syntax was proposed at the meeting:
KeyPurpose ::= SEQ SIZE (1 .. MAX) of OBJECT IDENTIFIER
PKIX-1 defines OIDs for all defined values of KeyPurpose.
KeyPurpose will be presented to ISO as standard replaced for KeyUsage.
There was an observation that the certificate policy extension could be used to satisfy this requirement. However, it was felt that certificate policies are conceptually orthogonal to key purpose. Certificate policies express a measure of reliance strength, independent of purpose.
After many debates, it was decided to retain the existing KeyUsage bits and propose another standard extension called enhancedKeyUsage (or extendedKeyUsage) to carry the purpose OIDs.
Kevin Vogel described the need for additional flexibility to define new formats for CRL retrieval in a standard fashion. He suggested reverting back to the December 1996 draft concepts. The following syntax was proposed:
AccessDescription::=SEQUENCE {
format OBJECT IDENTIFIER default PKIX2
AuthorityInfoAccessSyntax ::= SEQUENCE {
authorityInfo [0] GeneralName OPTIONAL
statusInfo [1] SEQUENCE OF accessDescription OPTIONAL }
Keith also requested that AuthorityInfoAccessSyntax be defined as an ATTRIBUTE so it can be included in PKCS 7 messages. This would be used to point to certificate storage area, given only the Issuer DN + cert. Serial number in SignerInfo of PKCS 7. With the ability to automatically locate certificates by reference, they need not be included in the PKCS 7 encapsulation, thus reducing its size.
2. PKIX Part 2 – Operational Protocols
3. IPKI Part 3 – Certificate Management Protocols
4. Certificate Policy Framework
5. Proposal on Web-based Certificates and CRL Repository