meeting minutes
Stephen Kent <kent@bbn.com> Mon, 21 September 1998 18:58 UTC
Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA22910 for <pkix-archive@odin.ietf.org>; Mon, 21 Sep 1998 14:58:44 -0400 (EDT)
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA29336 for ietf-pkix-bks; Mon, 21 Sep 1998 09:17:24 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA29332 for <ietf-pkix@imc.org>; Mon, 21 Sep 1998 09:17:22 -0700 (PDT)
Received: from [128.33.238.151] (TC151.BBN.COM [128.33.238.151]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id MAA05250 for <ietf-pkix@imc.org>; Mon, 21 Sep 1998 12:23:14 -0400 (EDT)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="============_-1305727475==_ma============"
X-Sender: kent@po1.bbn.com
Message-Id: <v04011701b22c2cbc4e8e@[128.33.238.151]>
Date: Mon, 21 Sep 1998 12:20:00 -0400
To: ietf-pkix@imc.org
From: Stephen Kent <kent@bbn.com>
Subject: meeting minutes
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Folks, I apologize for not having mailed these sooner, for review. They were done by Friday, of IETF week, but then got lost in an avalanche of travel and e-mail. Please review and respond to me with corrections by the end of this week. Thanks, Steve ----------------------- PKIX WG Meeting Minutes 8/26-27/98 The PKIX WG met twice during the 42nd 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 Certificate/CRL Profile (draft-ietf-pkix-ipki-part1-09.txt) - IESG Last Call KEA Algorithm Profile (draft-ietf-pkix-ipki-kea-02.txt) - Close to completion by Editors HTTP/FTP Operations (draft-ietf-pkix-opp-ftp-http-04.txt) - Ready for WG last call LDAP V2 Profile (March 98 draft)- At IESG, pending WG delivery of V2 Schema LDAP V2 Schema (draft-ietf-pkix-ldapv2-schema-01.txt) - In WG last call OCSP (draft-ietf-pkix-ocsp-05.txt) - In WG last call CMP (draft-ietf-pkix-ipki3cmp-08.txt) and CRMF (draft-ietf-pkix-crmf-01.txt) - In hands of IESG; pending IESG last call CMMF (draft-ietf-pkix-cmmf-02.txt) and CMC (draft-ietf-pkix-cmc-01.txt) - In WG last call Certificate Policy/Practices Guideline (draft-ietf-pkix-ipki-part4-03.txt) - In SA Director's hands, pending publication as Informational RFC REVIEWS OF ESTABLISHED PROJECTS: - PKIX Certificate and CRL Profile (Tim Polk) Ready for IESG ballot, after receipt of minor editorial comments during IETF last call. Straw polls used to resolve last few contentious issues, specifically mandating use of DNs for all Issuers, and mandating use of strict subtrees for the NameConstraints extension. Jeff Schiller noted that the IETF web site has pointers to the Entrust license required for inclusion of CRL distribution point within this document. The license is easy to execute; there is a reciprocity clause that requires licensing to Entrust any intellectual property associated with CRL distribution, as a side effect of - KEA and ECDS Algorithms (Tim Polk) Work on these algorithm IDs continues, subject to resolution of some intellectual property issues. - LDAP V2 Schema and Profile (Tim Moses, Dave Horvath, Santosh Chokhani) Most of the schema are not controversial; outstanding issues is whether all CA certificates should appear in the cross certificate directory attribute, or whether certificates that are internal to a domain should appear in the CA certificate attribute. There is consensus that any self-signed CA certificates belong in the latter attribute. The disagreement here revolves around alternative certificate validation algorithms; both approaches have been implemented and both work, each favoring a different PKI model. The CA certificate attribute has been a feature of X.509 for a long while, so the proposal to move all (non- self-signed) CA certificates to the cross CA certificate attribute represents a non-backward compatible change for systems not making use of cross certificates. Still, this is the direction currently being pursued by the X.509 committee in resolving this ambiguity in the original standard. Performance analysis of 6 different approaches, under varying assumptions of PKI models, shows that putting all (non-self signed) CA certificates in the cross certificate attribute results in worse performance. We can make a decision now to get this long overdue schema out, or postpone and discuss more (since this is a newly discovered issue). (Although this discussion is taking place in the context of LDAP v2, the same issue arises in LDAP v3. However, v3 has better filtering capabilities and this it is believed that the issue would be less of a concern, but this is not universally agreed upon.) Work on LDAP v3 is progressing in the IETF, and so if we postpone action on this ID, it may be OBE and we will need to focus on v3 instead. Proposed compromise approach is to duplicate intra-domain CA certificates in both attributes (#4 in Santosh's analysis posted to the WG list), and which has very good overall performance. One objection raised to this is that it can result in added data sent back if one retrieves both attribute contents. Straw poll conducted resulted on no clear winner, but the two finalists are the proposed compromise and the older, backward compatible approach; the WG rejected the proposal from the current LDAP schema. - OCSP (Tim Myers and Ambrish Malpani) Various minor, but technically important, edits to many parts of the document, in response to comments from the WG list. Changes included a uniform key identifier, optional use of TLS/SSL for privacy protection of exchanges, etc. An objection was raised to mandating use of a signature, when a lower layer protocol might be used to provide security. A straw poll overwhelmingly supported the mandatory use of signatures of in OCSP. Thus there appears to be no outstanding significant technical issues at this time. A separate OCSP response extensions document will be created to define additional responses - CMP and CRMF In IESG last call. No further status to report. - CMMF and CMC (Mike Myers) The CMMF draft has completed WG last call, minor changes have been made in response to comments received during last call, it and will be forwarded to the IESG. CMC also has completed WG last call, and undergone changes in response to comments received during that process. Pending approval of secure initialization issues briefed at this meeting, the document will be forwarded to the IESG. The secure initialization requirements for CMC include use of a shared secret in a keyed hash calculation, with this secret distributed via a confidentiality-secure channel. However, objections were raised to defining this as the only way to achieve secure initialization, e.g., as opposed to use of SecurID cards or S-KEY authentication in the context of an integrity and confidentiality secure channel. It seems likely that additional mechanisms should be allowed, but there is a desire to avoid an explosion of allowed user authentication techniques, which would hinder interoperability or greatly burden CA software. This issue will be brought to the list for resolution. - IBM PKIX Software Distribution (Charlie Kaufman) IBM is implementing PKIX technology and making it available for use in products, as well as in R&D environments. Code is a mix of C++ software plus Java GUIs. Provided facilities include CMP, CRMF, LDAP, basic CA and RA functions, and client certificate processing. No crypto is included in the distribution; the software makes calls to a CAPI. The first release relies on the Cylink cyrpto toolkit, which also will be available via this web site; later version will also make use of BSAFE. Initial distribution is via an MIT web site and is not exportable. A pointer for a mailing list was provided: imc-pfi@imc.org. NEW TOPICS: - Timestamp & Notary proposals (Carlisle Adams) Several folks continuing work on these topics and have published an independent draft on these topics. The authors received a fair amount of private feedback, and hope to be able to bring forward a well-formed proposal. Jeff Schiller gave his permission to bring this into the WG, based on the WG having made substantial progress on the other work items. Thus we will expand the charter to encompass these topics. - Web-based Integrated CA services Protocol (Mine Sakurai) This presentation describes use of HTTP as an underlying communication protocol among CAs, RAs, etc. The underlying model also defines issuing, validation, and publishing authority modules within the CA. ICAP has been implemented for use with S/MIME in a medical information system in Japan. An I-D has been published describing ICAP: draft-ietf-????. It was noted that the acronym "ICAP" is already in use by a calendar protocol, so another protocol acronym would be appropriate. - Enhanced CRL Distribution Options (Phillip Hallam-Baker & Warwick Ford) There is an I-D describing alternatives CRL distribution technique, which was developed in response to the intellectual property problem that temporarily prevented use of the CRL distribution point mechanism. The CRL format can be extended to specify the scope of the CRL, e.g., by serial number range, as an alternative to placing the pointer in the certificate. To address the CRL location aspect of CRL distribution points, one also can establish CRL managers that are either locally trusted or that represent a separate CRL distribution channel, perhaps serving multiple CAs. By adding two new CRL extensions, one can extend the CRL distribution model in interesting new ways. These suggestions are being forwarded to ISO for consideration. See the latest I-D, under the PKIX, for more details. - PKIX Roadmap (Al Arsenault) The set of PKIX documents has become rather large and potentially confusing. An outline was presented as a basis for a document that would become an informational RFC, to help explain the relationships among these documents, and to other efforts, e.g., SPKI. An initial draft is ready and will be made available immediately after this IETF meeting. - Qualified Certificates (Stefan Santesson) In EC a legal framework for "qualified certificates" is being developed, referring to individual certificates that will be accepted for legally binding, international transactions, and with legal liability implications for the CAs issuing such certificates. (These certificates are used only for non-repudiation.) It is analogous to some of the work under UNICTRAL for EDI. For PKIX, the potential work item would be a profile for such certificates, specifying which extensions are mandatory and optional, establishing values and semantics for some of the extensions. For example, one might mandate use of the policy extension with a specific value to identify such certificates, with policy qualifiers to express additional characteristics of policy variants, appropriate key usage flags, naming schema constraints, etc.
- meeting minutes Stephen Kent
- Re: meeting minutes Denis Pinkas
- Re: meeting minutes Michael McNeil
- meeting minutes Stephen Kent
- RE: meeting minutes Michael Myers
- meeting minutes Stephen Kent