PKIX WG Meeting 12/8/98 & 12/9/98 Edited by Steve Kent (WG co-chair) The PKIX WG met twice during the 43rd IETF and a approximately 190 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 Cert/CRL Profile (draft-ietf-pkix-ipki-part1-11.txt) Approved for Proposed Standard KEA Algorithms for Profile (draft-ietf-pkix-ipki-kea-02.txt) In WG Chairs' hands - ready for publication as Informational RFC ECDSA Algorithms for Profile (draft-ietf-pkix-ipki-ecdsa-01.txt) In Editors' hands. HTTP/FTP Operations (draft-ietf-pkix-opp-ftp-http-04.txt) In WG Chairs'/Area Director's hands - ready for IESG LDAP V2 Operational Protocols (draft-ietf-pkix-ipki2opp-08.txt) Awaiting schema document and will be reviewed by IESG together. LDAP V2 Schema (draft-ietf-pkix-ldapv2-schema-02.txt) In Area Director's hands, will be forwarded to IESG very soon. OCSP (draft-ietf-pkix-ocsp-07.txt) In Area Director's hands CMP (draft-ietf-pkix-ipki3cmp-08.txt) and CRMF (draft-ietf-pkix-crmf-01.txt) About to be approved by IESG CMC (draft-ietf-pkix-cmc-02.txt) Under development. CMMF (draft-ietf-pkix-cmmf-02.txt) In WG last call, but probably will be deleted, due to subsumption by CMC. Certificate Policy/Practices Guideline (draft-ietf-pkix-ipki-part4-03.txt) In Area Director's hands - ready for publication as Informational RFC Reports on Established Projects: OCSP (A. Malpani-ValiCert) Announcement of an OCSP server available for interoperability testing. CMC (J. Weinstein-Netscape) Notable changes from last time, and new text makes explicit what requirements are being met. Given the extent of these changes, this I-D is NOT yet in WG last call. CMC is primarily based on PKCS 10, and CMRF, and CMS (PKCS 7 successor developed in S/MIME). Protocol is stateless, to make life easier for the server, optional for client. Features supported include client or CA generation of key pairs, optional key recovery, POP, realtime and staged delivery responses, and (local) RAs. Mandatory algorithms include DSA and D-H, with RSA as an option. Steve Kent, WG co-chair, asked that the document be revised to make explicit the security requirements imposed on CMC transactions and whether these requirements are met by CMC in all cases, or whether CMC optionally satisfies these requirements. In the latter case, there are security dependencies relative to the underlying protocol employed for transport. Such dependencies must be explicitly stated in the document. Jeff agreed to make the edits necessary to satisfy these concerns. Carlisle Adams raised some concerns about the POP mechanisms contained in the protocol and raised issues about the need for more details, and some edits (e.g., OID values), to ensure interoperability. Carlislie was asked to send these issues to the list so that the CMC authors can address them prior to WG last call. Diffie-Hellman POP Mechanisms (J. Schaad-Microsoft) Jim provided an update on an informational document that will specify a means of proof of possession with non-fixed groups, consistent with S/MIME contexts. There was general agreement that the result of this work will be appropriate as a standards track (vs. informational) RFC. PKIX Roadmap (A. Arsenault-NSA) Al has received a few comments but is looking for more, and will continue to refine the document as the last of the mainline X.509 PDAM Update (T. Polk- NIST) Tim presented several slides provided by Sharon Boyen (Entrust), describing X.509 proposed changes from the September ITU-T meeting. The PDAM describes new extensions related to attribute certificate revocation, etc. Comments are requested from PKIX WG members. For more details, see the message to the WG from Hoyt Kesterson (Hoyt.Kesterson@bull.com), dated 11/23/98. Reports on New(er) Topics: Qualified Certificates (draft-ietf-santesson-qc-01.txt) (S. Santesson) This I-D addresses profiling X.509 certificates for use in a particular application context, i.e., for generation of digital signatures that will be recognized as legal throughout the EU. These certificates are to be issued to individuals who will generate digital signatures that support non-repudiation. There is an assumption that these certificates will be used not only with custom applications, but also with standard IETF applications such as S/MIME, hence the relevance to this WG. Only four certificate fields are addressed by this: Issuer, Subject, Policy, and Key usage. Thus a primary focus of this document is on naming, both requiring support for specific DN attributes and specifying semantics for the names. The slides provide additional details. ETSI Report on Electronic Signature Standardization (D. Pinkas) Denis provided a brief report on "electronic" signature standardization. This is quite analogous to the previous presentation, with the further focus on signatures for high value transactions. Again, non-repudiation is essential, but here roles, not just individual identities, are relevant, as is the context in which the signature is applied, e.g., as indicated by policy. The ETSI group has identified a list of issues to be resolved in order to provide the necessary framework for such high value signature applications. See the slides for additional details. The report is available at: http://www.etsi.org/SEC/ESRep042.pdf Timestamp (draft-ietf-pkix-time-stamp-00.txt) Data Certification Server (draft-ietf-pkix-dcs-00.txt) C. Adams- Entrust Carlisle reviewed differences between the current drafts and the drafts reviewed at the previous IETF meeting. In particular, the new version of the timed stamp I-D offers finer granularity for time stamps and support for time stamping of just a nonce. It was suggested that we combine the services of time stamping and document "notarization" into a single protocol, where the object submitted could be a hash or the object itself. However, there was not agreement that such combination was beneficial in all cases, and a single server may offer both timestamping and data certification services with only slightly greater complexity. The CMP-derived status indications need to be "masked" to clarify the fact that some CMP error conditions are not relevant to this application. The timestamp I-D appears to be ready to move to WG last call with the next version, however the data certification I-D needs more work. Also, the WG chairs need to co-ordinate with the Security AD to modify the charter to encompass both of these I-Ds.