CURRENT MEETING REPORT

Reported by Stephen Kent, BBN Corporation, and Warwick Ford, Nortel Technology

Minutes of the Public-Key Infrastructure (X.509) Working Group (pkix)

The PKIX WG met on Tuesday and Wednesday, 3/5-6/96, in Los Angeles. Approximately 91 individuals attended these meetings. The meeting began with a quick review of the agenda, document locations, mailing list subscription information, etc. The content and status of the four documents that will be the primary WG product were described briefly. Cylink made a very brief presentation on new license terms that might be relevant to use of Diffie-Hellman and Digital Signature Standard algorithms.

Dave Solo reviewed, in detail, the v3 certificate extensions profile documented in the I-D posted in late February. There was consensus on the specifications of a number of the profiled extensions for which the I-D authors suggested a specific profile. However, severalextensions clearly require further work. A major unresolved issue ishow to best integrate general names into certificates, given theconstraints on the subject and issuer name, vs. the fairly generalforms allowed in the altName extensions. This also affects the use ofthe subtreesConstraint portion of the basicConstraints, i.e., it needsto be profiled for use with general names (vs. distinguished names).

Another outstanding issue is the criticality of various extensions,and whether we need to retain the criticality assignments present inthe X.509 documentation. Note that criticality must be viewed bothfrom the perspective of the issuer of a certificate and from that ofthe entity that validates a chain of certificates. This issues arisewith regard to several extensions, e.g., restrictedKeyUsage vs.intendedKeyusage, etc.

Russ Housley led a similar review of the profiled v2 CRL extensions,which are described in the same I-D. There was WG consensus on mostof the profiled CRL extensions, which are fewer in number andgenerally less complex and/or controversial than the certificateextensions. The only controversial point in this profile was theproposed deprecation of the "hold" facility. There was somediscussion in favor of retaining this facility, though there also wasconsiderable opposition to its use; there is not yet consensus on thisaspect of the CRL profile. However, some of the same unresolvedissues with regard to use of general name forms and extensioncriticality arise for CRLs too.

On Wednesday, Stephen Farrell reviewed the initial draft ofcertificate and CRL management protocols, which are described in thethird I-D in the proposed series. (This I-D was not submitted priorto the deadline for this meeting and thus was not available on-lineprior to the meeting.) This I-D is more preliminary than the firstone in the series and thus many more details remain to be resolved.Still, there was consensus on the list of management protocols thatare required and that are enumerated in the I-D.

A suggestion was made that the model presented here be refined tointroduce more functional elements, irrespective of where thefunctions are implemented, e.g., with regard to registration agent andkey backup functions. About a dozen protocols for certificate and CRLmanagement were identified, though not all of these protocols aredescribed at the same level of detail in the I-D. A few of theseprotocols may be moved to the second I-D, as they are more closelyrelated certificate and CRL use (vs. management). The review includeda discussion of the top level format for these management messages,plus a smaller set of corresponding message body types. There weresome suggestions for simplifying the set of protocols, e.g., buildingthe cross-certification protocol from one-way certificationoperations.

Warwick Ford raised the question of whether this WG should endeavor toproduce an API for certificate and CRL management. Use of an APIfacilitates adoption of this technology by making it easier forapplication developers to interface to PKI processing in a standardway. The WG response was generally enthusiastic with regard to thecreation of an API, but there are other venues where this activitymight be pursued, e.g., X-OPEN. The WG consensus was that we need notpursue development of an API at this time.

Steve Kent sought a volunteer to author a small guide to the subsetof ASN.1 that is used in PKIX specifications, including encoding rulesand conventions adopted for distinguished encoding for UTCT.Attendees from NIST and RSADSI offered to provide some backgroundmaterial to aide in this effort.

An ancillary discussion raised the question of how extensively ASN.1needs to be used in PKIX. There was general agreement thatcertificates and CRLs need to be specified in AASN.1 and DER encoded.However, the management protocols that are now being defined in ASN.1might be specified in some other language or in bit-on-the-wireformats. This is a topic for further discussion.

Wolfgang Schneider and Warwick Ford made brief presentations on thetopic of trust models. Wolfgang described a project in the EC thatwill make use of X.509 v3 certificates to support variousapplications. The presentation described requirements for trustmodels, including automated validation of certificate paths,accommodation of hierarchic and mesh certification structures, minimalneed for on-line retrieval of certificates, etc. In an abbreviatedpresentation, Warwick pointed out that X.509 accommodates general meshcertification and that v3 certificates incorporate features thatfacilitate controlling potentially undesirable side effects of meshcertification. There was discussion of what sorts of trust modelsshould be supportable under this PKI. The discussion focused on thedistribution of security policy information between certificates andend users.

The meeting concluded with a solicitation for comments on the I-Ds,and a request for volunteers to work on the second and fourth I-Ds,as well as the API I-D.