PKIX WG Meetings Minutes A total of approximately 190 IETF members attended the PKIX WG meetings (two time slots) on 6/25/96. Steve Kent and Warwick Ford, co- chairs, presided over the meeting. Steve Kent prepared these meeting minutes. Agenda Introduction ISO X.509 Update PKIX Part 1 (Certificate and CRL Profiles) Review PKIX Part 3 Management Protocols Review DoD Management Protocols Japanese PKI Report ASN.1 Documentation Validity Periods Reference Implementations & Conformance Testing Steve Kent welcomed attendees to the WG meeting and solicited additions to the agenda. Warwick Ford provided a review of the newly revised X.509 AM, based on the editing meeting in early June. A number of changes from the DAM have been made, and many of these were motivated by comments and suggestions from the PKIX membership. Major changes relevant to PKIX include criticality bit assignments, key usage, name forms, basic constraints, indirect CRLs, hold mechanism, and delta CRL mechanism. See WarwickÕs slides for more details of the AM/DAM changes. The AM is available at ftp://NC- 17.MA02.Bull.com/pub/OSIdirectory/Certificates. Russ Housley reviewed the PKIX Part 1 document, which profiles the X.509 AM for Internet use. The document also adds 3 extensions that are Internet-specific. This document describes what it means to support each extension, from the perspective of a certificate issuer and certificate user. It also specifies whether the extension is recommended or not, and whether it is critical, not critical, or either (at the discretion of the CA). There was almost unanimous agreement that the final document must contain the ASN.1 syntax and the accompanying processing rules to make this document comprehensive, i.e., so that readers will not have to refer to the base ISO document. Still, there is a need to exercise care in creating this mirror document and to track defect reports relative to the ISO base document. Work on this document will now move to a phase where WG inputs are needed to help decide the status of different extension features, i.e., to indicate whether a compliant implementation (issuer or user) MUST, SHOULD, or MAY provide support for the extension, plus any Internet- specific constraints imposed on the syntax of the extension. See the Internet-Draft for details. Stephen Farrell reviewed the status of the current draft of the PKIX Part 3 document, which describes management protocols for use with certificates and CRLs. Very little progress has been made on this document since the LA meeting, so this was a short report. See the Internet draft for more details. A brief discussion of the relationship of PKCS-10 to a part of this document ensued, with the proposal that PKIX profile PKCS-10. This suggestion will be explored in more depth on the mailing list. Greg Bergren provided a report on DoD work on certificate management protocols, analogous to the protocols being described in the PKIX Part 3 document. Specifically, Greg spoke of experience gained from work on MMP, the MISSI (Multi-level Information System Security Initiative) Management Protocol. Three items were suggested as important features present in MMP, but not addressed in the PKIX documents: - CA support for mail list (for secure e-mail, e.g., MSP) - ability to request a CRL from a CA - support for indirect CRLs (ICRLs) However, an Internet-specific extension described earlier in this meeting already supports CRL requests being directed to various destinations. Also, ICRLs are part of the X.509 v3 extensions being profiled. So, the only major feature of MMP not also encompassed by the PKIX Part 3 document, is mail list agent support. It is not clear if mail list support belongs here, since this is an application-specific technology, not applicable to most certificate applications. However, several WG members noted that this technology might be more generally useful, e.g., for conferencing applications. Greg offered to send a message to the PKIX list providing pointers to SDN.703 (the MMP spec) and to SDN.701 (the MSP specification, for a discussion of mail list facilities). Kikuchi Hiroaki described the status of certificate infrastructure in Japan, including a discussion of the certification hierarchy deployed for PEM use two years ago. He also provided statistics on PEM use, and ongoing work on an expended PKI. Analysis of web of trust for use in Japan, based on preliminary experiments and an estimated 100,000 user base, suggests a web diameter of about 13. A full web for a large portion of the population would suggest a much larger diameter, but it is not clear that even the smaller (13) diameter is viable. One possible solution is to have ISPs act as CAs; also an organization for computer- based authentication (ICAT) is interested in helping organize CAs at a national level. (See http://www.icat.or.jp for more info.) Use HTTP for on-line registration, CRL distribution, and policy statement distribution. User software PEMCAT available for Macs, Windows, and UNIX. Future work will focus on v3 certificates, public key algorithms other than RSA, and more experimentation. Steve Kent renewed a call for ASN.1 (88) documentation to help facilitate implementation of certificate and CRL processing. Tim Polk agreed to work on providing this sort of documentation from NIST resources. It was reported that Burt Kalaski offered to secure copyright release for the RSA Labs document, ÒA LaymanÕs Guide to a Subset of ASN.1, BER and DERÓ for publication as an Internet RFC, either in whole or part. Steve Kent agreed to follow up with RSA Labs on this topic. This document is available via the RSA web site: http://www.rsa.com/ftpdir/pub/pkcs/ps/layman.ps (postscript) or http://www.rsa.com/ftpdir/pub/pkcs/ascii/layman.asc (ASCII). Denis Pinkas lead a brief discussion of issues related to interpretation of the validity period field in the X.509 (v1) certificate. He notes that interpretation of this field differs based on whether the signature mechanism is being used for non-repudiation or authentication and integrity. For non-repudiation, in the absence of the privateKeyUsageValidityPeriod extension, then the private key is assumed to have been valid during the validityInterval, but the public key is assumed to be valid forever, i.e., for use in verifying signatures generated during the validityInterval timeframe. However, this may not be sufficient in all circumstances, e.g., due to concerns over the cryptanalytic strength of the signature and/or hash algorithms. Note that for non-repudiation to be effective, one must establish the timeframe in which a signature was purportedly applied, and that the key used was not reported as revoked during that time frame. In contrast, when the private key is used for encryption purposes, ... Denis argues that when the key is used for encryption, the validity interval applies only to the public key, and the private key is assumed to ÒliveÓ forever. Others note that the definition of this field applies to the certificate, not to either the private or public key, but to the binding between the public key and the other certificate attributes. The validityInterval field also is interpreted as delimiting the interval over which the certificate would be retained on a CRL. Tim Polk talked about NIST activities in the conformance testing and interoperability testing arena, and thus his interest in these topics relevant to PKIX. Three NIST projects relevant to PKIX: - minimum interoperability specification for PKI components (MISPC) - conformance testing for PKI components - reference implementation for PKI components MISPC is being pursued by NIST with co-operation/assistance from commercial entities, under CRADAs. Scope includes certificate and CRL profiles, CA/RA management protocols, etc. Work is independent of signature and hash algorithms and of underlying transport mechanisms. MISPC should be available by September 30, 1996. NIST will then (staring in September) develop tests to measure conformance of PKI components relative to the MISPC. NIST also wants to develop CA, RA, and client reference implementations, for free distribution. These implementations should support multiple algorithms and provide a sanity check for the test suite. Existing NIST contributions include DSA and SHA-1 code, a CA/RA implementation, and sample client software. NIST is looking for assistance in developing the reference implementations. They have decided that the CRADA process is not ideally suited to this task, but they are open to other suggestions on how to proceed, e.g., funding or donated development resources. Denis Pinkas reviewed (verbally, no slides) a few of his comments relative to the Part 1 and Part 3 PKIX I-Ds. DenisÕ comments are already available via the mail list, and so are not reproduced here.