PKIX WG Meeting 7/14/99 Edited by Steve Kent (WG co-chair) The PKIX WG met only once during the 45th IETF and a approximately 180 individuals participated in these meetings. The meeting began with a review of the status of all of the WG document, presented by Warwick Ford, WG co-chair. The following text summarizes the status of the documents: PKIX COMPLETED DOCUMENTS PKIX Cert/CRL Profile (RFC 2459) Approved as Proposed Standard KEA Algorithms for Profile (RFC 2528) Approved as Informational RFC HTTP/FTP Operations (RFC 2585) Approved as Proposed Standard LDAP V2 Operational Protocols (RFC 2559) Approved as Proposed Standard LDAP V2 Schema (RFC 2587) Approved as Proposed Standard OCSP (RFC 2560) Approved as Proposed Standard CMP (RFC 2510) Approved as Proposed Standard CRMF (RFC 2511) Approved as Proposed Standard Certificate Policy/Practices Guideline (RFC 2527) Approved as Informational RFC PKIX WORK IN PROGRESS ECDSA Algorithms for Profile (draft-ietf-pkix-ipki-ecdsa-01.txt) New draft to be issued for WG last call shortly CMC (draft-ietf-pkix-cmc-02.txt) Diffie-Hellman POP (draft-ietf-pkix-dhpop-00.txt) Ready for WG last call Qualified Certificates (draft-ietf-pkix-qc-01.txt) Version ready for WG last call CMMF (draft-ietf-pkix-cmmf-02.txt) This item to be dropped from the program Time Stamp (draft-ietf-pkix-time-stamp-00.txt) Near to WG last call DCS (draft-ietf-pkix-dcs-00.txt) Under WG review PKIX Rodamap (draftietf-pkix-roadmap-??.txt) Under WG review. Others?? Reports on Established Projects: Progressing RFC 2459 to Draft Status (R. Housley-Spyrus) Russ described the requirements for progression to draft standard status and solicited inputs from the PKIX community in support of this progression. He also solicited edits to 2459 and noted that a defect report on policy mapping in certificate validation processing has been filed. This defect is expected to be resolved in a meeting in September, and the results will be reflected in the revisions to 2459. Depending on the resolution of this defect, it may be necessary for 2459 to "cycle in grade," or it may be possible to progress to draft standard status. A straw poll on a technical detail of delta CRL management was conducted, and the consensus was to allow delta CRLs to be based on any specified base (vs. only the most recently issued base). Revision of RFC 2527 Certificate Policy Practice Guidelines (J. Rodriguez-IBM) An activity on revising this informational RFC, based on operational experience in the CA realm, and inputs from the legal community (ABA) has been initiated. A small group has been created, with a corresponding mailing list (pkix4@raleigh.ibm.com), to pursue this revision. CMC and Diffie-Hellman POP (J. Schaad-Microsoft) Final draft for CMC will be published in about one week, and then go to WG last call. The D-H POP draft will follow shortly. PKIX Roadmap (S. Turner-IECSA) Updated QC discussion, and added a number of items (not all of which are accepted as work items for the WG). A comparison of PKIX vs. other certificate profiles will be the subject of a separate document, as per the recommendation of the WG chairs. Time Stamping Protocol (D. Pinkas-Bull) Denis has taken over as editor for this work, from R. Zuccherato. A new draft (version 2) was posted just prior to the IETF. Major revisions include the scope of the protocol, removal of TDA support, moving status outside of the signed token per se, removal of support for sequence of hashes, format of TST time, etc. Choice of TST format uses GeneralisedTime plus sub-second granularity as a separate component, taken directly from NTP. But this second component is primarily used as a means to serialize time stamps within a one-second interval, not specifically to offer highly precise time stamps. The question was raised whether it is appropriate to make dual use of this field, i.e., for sub-second accuracy and for serialization. Alternative is to use GeneralizedTime to millisecond accuracy, and then use serial number for further serialization. This needs to be resolved on the list. Denis observed that time stamping is an area rife with intellectual property claims. A list of patents in this area, provided by Denis, illustrates the recent history in this area (back to 1989). It is noted that a submission to ISO in April 1989, in part of work on a non-repudiation framework, constitutes early published work in this area, perhaps calling into question some of the most general patents on time stamping. Work will continue to resolve the cloud that hangs over this work item. (See slides for additional details.) Data Certification Server Protocol (C. Adams-Entrust) Peter Sylvester is the new lead editor and a new I-D has been published as of this week. Scope has been pretty broad, encompassing features of notarization OCSP, SCVP, TSP, etc. So, this is an example of the question raised on the list with regard to different protocols for different services, or a grand unified protocol approach. Possible options include freezing this spec now as an experimental protocol, reduce scope to avoid conflicts with other work items and continue as a standard track protocol, or keep broad scope and kill other protocols. Denis notes that, from a conformance standpoint, bundling would create the need to allow subset compliance, since not all clients or servers will need all of the features offered by a unified protocol. Discussion explored the dimensions in which one may choose to partition protocols, e.g., mandatory use of a server for non-repudiation vs. optional use of a server for operations that could be performed by a client. Simple Certificate Validation Protocol (P. Hoffman-VPNC & A. Malpani-ValiCert) Questions arise about many different parts of this proposal, including use of the "tiny" syntax, choice of higher level encapsulation formats, support for non-X.509 (OPGP) certificates, etc. The authors agreed to delete the tiny syntax for now, due its controversy. (One WG chair pointed out that support for other than X.509 certificates is not within scope for PKIX. Members of the OPGP WG question this position, asserting that the IESG precluded OPGP from pursuing its own PKI work. This needs to be addressed via discussion with the security ADs.) Denis and others provided more detailed criticism. A straw poll of attendees shows did not show clear consensus for or against the general notion of offloading certificate processing from a client. Discussion of this topic will continue on the list, and a new draft (minus the tiny syntax) will be published. Qualified Certificates (S. Santesson) A new draft will be posted shortly, reflecting the latest set of changes based on mailing list discussions. Highlights of this new draft include: "de-legalization" of scope of the document, an extension for inclusion of a hash of biometric data (for human verification), and a new extension for marking a certificate as qualified (via reference to an OID) and for expressing reliance limits, separate from the use of the policy extension. (This extension is general in order to fit any legal system, and thus is not restricted to marking a certificate as a qualified certificate.) The author requested that a WG last call be issued, after the list has had a chance to review this latest version. Other Topics: LDAPv3 Profile (D. Chadwick- University of Salford) Description of what features of LDAP v3 are relevant to PKIX and thus why a profile is needed. This is especially important because LDAP v2 is being phased out as an IETF standard and PKIX must migrate to v3. The author is soliciting comments from the list, and will co-ordinate with the LDAP WG as well. Attribute Certificates (S. Farrell-SSE) Stephen briefly reviewed the document, which profiles the X.509 AC. Several WG members discussed appropriate forms of linkage between the AC and the PKC, i.e., name vs. certificate or key hash, vs. issuer and serial #, revisiting a debate on the list. This discussion did not resolve the debate. General agreement to include a standard attribute set, but still need to resolve details of these attributes, and must require support for creation of new AC extensions. Questions were raised whether a new, lightweight protocol is needed pull ACs, vs. use of LDAP, as an adjunct to the push model that now underlies the AC use model. Straw poll showed overwhelming support for moving the retrieval protocol to another document. This document defines the base profile, plus extensions that are optional. The WG needs to work out details of what is base vs. extension. Do we need an extension in the AC authority's public key certificate to characterize what the authority is authorized to issue what ACs, or should this be done via an attribute certificate itself? Basic Event Representation Token (M. McNeil-GMT) The author notes that this proposal relates to the TSP work, but uses what is believed a more compact format so that it may be used in environments where the size of the response from a TSA is too big. The primary use model provided here is rather implementation-specific, i.e., tamper-evident hardware in a local context, vs. a TSA accessible via a network. A Security AD raised questions about any intellectual property claims associated with this model, as this may affect whether the proposal is appropriate for an IETF WG. The speaker stated that he is aware of no IP with regard to the proposed formats, etc. A PKIX WG chair expressed concern over the apparent product-specific nature of the proposed model. The author acknowledges that only one vendor (Datum) offers the sort of hardware cited as the primary use example. The WG chairs and the Security ADs will discuss whether this work is appropriate for PKIX, given the issues cited above. CMP Interoperability Testing (R. Moskowitz-ISSA) Bob reported results of four classes of testing for 5 CMP implementations, conducted by ICSA and NIST. The next workshop will continue and expand testing. One lesson from this work is that the CMP RFC fails to mandate defaults in many instances, which reduces interoperability. Bob's analysis of this testing is that we need more MUSTs in this standard! One security concern arose, with regard to the size of the salt used in registration. Temporal Data Token (M. Duren-WetStone) Presentation focused on format for TDT (in the TSA) that helps attest to the integrity of the time source, i.e., providing a link to a trusted time source. This approach pushes evidence of time source into a token, vs. other, external measures that a TSA takes to ensure the accuracy and integrity of its time source. A claimed feature of this approach is that it allows a client to be able to verify the utility (for non-repudiation) of the returned token immediately, vs. the deferred verification more typical of TSA operation. As with the BERT presentation, the speaker was asked about possible intellectual property claims and about the breadth of vendor support for the propose TDT format. The speaker asserted that he was aware of no IP claims, and that he was aware of at least two vendors who had expressed interest in this format, although no more than one was building products to this spec at this time. The WG Chairs and the Security ADs also will need to discuss whether this is within the scope of PKIX, before this item progresses.