CURRENT MEETING REPORT Reported by Stephen Kent, BBN Minutes of the Public Key Infrastructure Working Group (PKIX) Co-chairs: Steve Kent (BBN) Warwick Ford (Nortel) Additional Speakers: Stephen Farrell (SSE) Russ Housley (Spyrus) Denis Pinkas (Bull) Dave Solo (BBN) This was the inaugural meeting of the PKIX Working Group and was attended by approximately 147 IETF members. Introduction o Agenda review The co-chairs presided over the meeting, following the agenda distributed to the mailing list, and reproduced with notes, below. A quick poll indicated that a majority of the (overflow) crowd had fetched, and many have read, the Internet-Draft posted prior to this meeting. o Why a PKI? Kent provided an overview of what a PKI encompasses and why it is needed. He emphasized that a PKI is useful only relative to a set of applications that employ certificates. One ought to evaluate the utility and adequacy of a proposed PKI features relative to a proposed set of applications that are clients of the PKI. This working group will need to identify the set of (Internet) applications that will be supported by this PKI, and derive from these applications the requirements imposed on a supporting PKI. Candidate applications include: e-mail, IPSEC protocols, GSS API, WWW security (e.g., SSL and S-HTTP), and various electronic commerce payment schemes. o X.509 status update Ford discussed the history and status of X.509. X.509 activity grew out of CCITT (now ITU) directory system work in the later 1980s. The first certificate and CRL specifications were published with the 1988 directory specifications. Work in the PEM context (RFC 1422, published in 1993) expanded on this format, introducing various conventions to address shortcomings in the initial versions of certificate and CRL syntax. In 1994, an extensible format for version 3 certificates and version 2 CRLs was adopted. In 1995, work is progressing in ISO on definition of a specific set of "standard" extensions for version 3 certificates and version 2 CRLs. Ford provided a quick overview of the certificate and CRL extensions and the motivations for many of these extensions. He also provided a URL for the on-line versions of the relevant documentation: ftp://NC-17.MA02.Bull.com/pub/OSIdirectory/Certificates. Initial Draft Document o Overview Housley provided a road map to the document, highlighting which portions have text now and which portions need contributions from the working group. Also at issue is whether the output of the working group should be one or multiple documents, and how multiple documents might be organized. o Certificate and CRL profiles Solo discussed some of the issues associated with use of version 3 certificate extensions, e.g., what constitutes required support for compliant implementations and the use of the Critical flag. Concern was expressed over how to expand, over time, the set of "required" extensions that must be supported by compliant implementation. Solo emphasized the importance of a thoughtful discussion of selecting supported name types and representing various forms of identity in the syntax options present. Solo provided a discussion and some initial suggestions with regard to possible Internet use of various extensions: alternative subject and issuer names, key attributes, key usage restriction, basic constraints on names certified by a CA, pointers to CRL distribution points, and pointers to other information access points. (See the Internet-Draft for details.) Housley reviewed version 2 CRL extensions, describing the motivation for each extension and making some suggestions for an Internet profile for these extensions. Overall CRL extensions reviewed included Authority Key Identifier, Issuer Alternate Name, CRL Number, Issuing Distribution Point, and the Delta CRL Indicator. Use of the last of these was disparaged by the speaker. Per-entry CRL extensions reviewed include Invalidity date, Reason Code, Expiration Date, and Instruction Code. the last three of these were disparaged by the speaker. (See the Internet-Draft for details.) o Management Protocols Ford discusses the need for protocols to support certificate registration and initialization (in general), key pair recovery (escrow), key pair updating, on-line requests for revocation, and cross-certification exchanges. The intent is to establish application layer protocols for these management functions, which are largely independent of the underlying protocol stack, plus to map these protocols to specific Internet protocol environments, e.g., e-mail or HTTP. (See the Internet- Draft for details on initial proposals for several of these protocols.) Farrell describes proposed requirements for a CA key pair updating protocol, emphasizing minimal impact on existing client certificates and allowing for a graceful transition to a new CA key. (See the Internet-Draft for details for this proposed new data structure and modified certificate validation procedure.) Focused Topic Discussions o Key Usage Control and Security Policy Pinkas provided feedback on the Internet-Draft, as well as speaking about his advertised agenda topic. He began by noting that the owner of a private key generally does not need to "know" the key, but only needs to be able to use it, even though a (trusted) third party (e.g., an escrow agent) might have a requirement to "know" the key. This approach implies using hardware (vs. software) to enforce this security policy. Lastly, there was volunteer to set a certificate stays on a CRL, and a requirement that older CRLs ought to be available. There is a suggestion that the Invalidity Date extension is important in supporting non-repudiation, in contrast with earlier comments on this extension. Pinkas also raised some questions about proposed management protocols in the Internet-Draft, and about some of the extensions discussed in the Internet-Draft. (See handout slides for details of these comments read the Internet-Draft.) Due to time constraints, the last two technical presentations were severely abbreviated. o Certification Policies Kent very briefly described motivations for establishing and using certification policies, and the X.509 v3 extensions that are available for supporting policies. o ORAs and LRAs Farrell very briefly described some motivations for establishing Local Registration Authority (LRA) or and Organizational Registration Authority (ORA), and alluded to the need for protocols to support this CA representatives. General Discussion Time did not permit any separate general discussion, although a number of questions were fielded during the presentations. Attendees were encouraged to review the Internet-Draft and comment on it to the authors and or to the list in general.