Editor's Note: These minutes have not been edited. PKIX WG Minutes, April 7-8 1997 (Reported by Michael Myers, VeriSign) SUMMARY The PKIX WG 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 also an informational presentation drawing attention to an alternative certificate management protocol based on HTTP and HTML technology. This information was presented for the WG's consideration in the development of the IETF standard certificate management protocol. Parts 1 and 3 will transition to WG 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. MONDAY, 7 APR 97 PART 1: CERTIFICATE AND CRL PROFILES Tim Polk presented the changes to Part 1 between the Dec. 96 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 * KEA encoding added * Examples added * Improved references OPEN ISSUES * RSA patent statement still outstanding, should be resolved soon. * Examples: expand? remove? * ASN.1 checking (check '88 vs. '93 constructs) It is the intent of the WG that Part 1 will go to WG Last Call following this IETF. DISCUSSION 1. 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. 2. 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. 3. 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. PART 2: OPERATIONAL PROTOCOLS 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). DISCUSSION 1 - Should we consider splitting the document into two separate ones, since the OCSP is a new protocol definition which may require significant 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. 2 - 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. 3 - 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. 4 - A question was raised on the specific contents of a ".cer" file. Resolution: Each .cer file contains exactly one certificate, encoded in DER format. 5 - 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. 6 - LDAP versions 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. PART 3: MANAGEMENT PROTOCOL 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 WG that Part 3 will go to WG Last Call following this IETF. DISCUSSION 1. It was pointed out that the current statement regarding PKCS 10 usage was overly specific as to the allowable context of its use. Resolution: The text will be amended to generally accommodate PKCS 10 requests. 2. At the San Jose meeting, a general consensus was established within the WG 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. 3. More flexibility in the statements regarding requirements on POP is desired. Resolution: The editor will amend the text to more fully express the intended flexibility. 4. 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. 5. 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. 6. 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. 7. 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. 8. 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. PART 4: POLICY GUIDELINES Santosh Chokhani presented details on status of Part 4. 1. 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 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. 2. 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 recognizes 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 was needed on specific obligations for CRLs and repositories. 3. 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 WG. 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.) TUESDAY, 8 APR 97 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 DISCUSSION It was 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. TIMESTAMPING / NOTARIES Carlisle Adams proposed that PKIX begin work in this area, based on ISO 13888 part 3. Several members of the WG, including representatives from BBN, Spyrus and VeriSign, offered to participate. TLS LIASON 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: 1. 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. 2. 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.) 3: 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. PART 1 MODIFICATIONS Enhanced Key Usage 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. It was felt however that certificate policies are conceptually orthogonal to key purpose. Certificate policies express a measure of reliance strength, independent of purpose. After much debate, it was decided to retain the existing KeyUsage bits and propose another standard extension called enhancedKeyUsage (or extendedKeyUsage) to carry the purpose OIDs. AuthorityInfoAcces syntax 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 96 draft concepts. The following syntax was proposed: AccessDescription::=SEQUENCE { format OBJECT IDENTIFIER default PKIX2 location GeneralNAME } 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. --------------------------------------------------------------------- Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140 wford@verisign.com; Tel: (617)492 2816 x225; Fax: (617)661 0716 ---------------------------------------------------------------------