meeting minutes, 1st draft
Stephen Kent <kent@bbn.com> Thu, 18 March 1999 20:02 UTC
Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24550 for <pkix-archive@odin.ietf.org>; Thu, 18 Mar 1999 15:02:13 -0500 (EST)
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA07754 for ietf-pkix-bks; Thu, 18 Mar 1999 09:25:18 -0800 (PST)
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 JAA07750 for <ietf-pkix@imc.org>; Thu, 18 Mar 1999 09:25:17 -0800 (PST)
Received: from [128.33.238.134] (TC105.BBN.COM [128.33.238.105]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id MAA18136 for <ietf-pkix@imc.org>; Thu, 18 Mar 1999 12:31:55 -0500 (EST)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="============_-1290343988==_ma============"
Message-Id: <v04020a15b316e904d9f4@[128.33.238.134]>
Date: Thu, 18 Mar 1999 12:35:03 -0500
To: ietf-pkix@imc.org
From: Stephen Kent <kent@bbn.com>
Subject: meeting minutes, 1st draft
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>
Continuing with our tradition of hot off the presses meeting minutes, I hereby submit the minutes fro the 3/18 PKIX WG meeting to the WG list for review and comment. Additional info on the status of I-Ds will be included in the final version. Please provide comments to me by 4/1, for production of the final version of the minutes. Steve --------- PKIX WG Meeting 3/17/99 Edited by Steve Kent (WG co-chair) The PKIX WG met only once during the 44rd IETF and a approximately XXX 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) Published as RFC 2459. CMP (draft-ietf-pkix-ipki3cmp-08.txt) and CRMF (draft-ietf-pkix-crmf-01.txt) Published as RFC 2510. Certificate Policy/Practices Guideline (draft-ietf-pkix-ipki-part4-03.txt) Published as Informational RFC XXX. HTTP/FTP Operations (draft-ietf-pkix-opp-ftp-http-04.txt) Approved by IESG LDAP V2 Operational Protocols (draft-ietf-pkix-ipki2opp-08.txt) Approved by IESG? LDAP V2 Schema (draft-ietf-pkix-ldapv2-schema-02.txt) Approved by IESG OCSP (draft-ietf-pkix-ocsp-07.txt) Approved by IESG. KEA Algorithms for Profile (draft-ietf-pkix-ipki-kea-02.txt) Approved by IESG for publication as an Informational RFC ECDSA Algorithms for Profile (draft-ietf-pkix-ipki-ecdsa-01.txt) Undergoing revision by authors. CMC (draft-ietf-pkix-cmc-02.txt) Under development. CMMF (draft-ietf-pkix-cmmf-02.txt) Expired, due to subsumption by CMC. <insert more work items from Warwick> Reports on Established Projects: A new WG charter was presented, in draft form, which shortly will be posted to the mailing list. The expanded charter encompasses attribute certificates, time stamping and notarization services, and qualified certificates. CMC and Diffie-Hellman POP (J. Schaad-Microsoft) The CNC draft did not meet submission deadline, but was made available to the list. The D-H POP draft is undergoing revision. CMC has been revised to accommodate comments from Carlisle from the last meeting. Additional changes are planned, including removal of the key archival and recovery features, and clarification of RA operations. PKIX Roadmap (A. Arsenault-NSA) Missed submission deadline. Undergoing revision to deal with terminology inconsistencies, POP, adding a history of PKIX, new work items (e.g., qualified certificates and time stamping), explanation of name constraints for alt name forms, path validation, etc. Qualified Certificates (S. Santesson) Goals of qualified certificates were reviewed. The fundamental thrust of this work is the development of a new SubjectAltName type, for "unmistakable identity" ID information. Attribute semantics represents the top-level structure for the SubjectaltName, making it clear what form of ID is being provided, e.g., national ID card or driver license. Also, this extension will contain a registration authority field, as required by German law. A pointer to a web site for additional info was provided (http://www.accurata.se/QC/) Suggestion was made to consider splitting this work into two document: one for the new name form, and another (informational?) to explain the context for which this new name form was devised. However, to the extent that a qualified certificate imposes constraints on other certificate fields, it is not clear Data Certification and Time Stamping (R. Zucharetto-Entrust) Data certification server I-D not recently updated, but will be soon, to respond to comments, e.g., ASN.1 corrections and more explanatory text. The time stamping document also has not been updated recently, but will undergo minor revisions, e.g., to allow for issuance of a time stamp without submission of a hash. Unfortunately, the topics of time stamping and data certification are rife with intellectual property claims, which may interfere with progression of these documents. Specifically, a lawsuit has been filed by patent holders against a company that has implemented a prior version of this protocol. The WG chairs will work with the authors of the documents to help resolve these issues. Other Toics: Progressing RFC 2459 to Draft Status (T. Polk-NIST) Collecting inputs for (mostly) minor corrections and clarifications to this document in anticipation of progressing this work. OCSP Clarification (S. Kent-BBN) Two sections of OCSP will be revised to clarify what is required of compliant clients and servers with respect to what keys can be used to sign OCSP responses. Specifically, an OCSP response must be signed by either the CA who issued the certificate in question, by an entity who has been explicitly delegated this authority by that CA (through direct issuance and inclusion of a specified EKU extension), or by an entity who has been selected as authoritative by the client. Compliant OCSP servers and clients MUST be able to support all three of these options.(Satisfying the third option is largely trivial for the server, but requires a configuration capability for clients.) Will End-Entity Certificates be Fat or Low Fat? (D. Pinkas-Bull) Proposal to minimize the addition of extensions to EE certificates, by moving as much of this sort of information to CA certificates, from EE certificates. Examples of such extension data are pointers to OCSP responders and CRL servers, where applicable to all certificates issued by a CA. Attribute Certificates (S. Farrell-SSE) A kickoff announcement of this new work item. Providing pointers to work on attribute certificates for use with TLS, as an example. OCSP Interoperability Testing (A. Malparni-ValiCert) Reported on tests of seven independent implementations. All made use of HTTP and direct, DER encoding (not base 64). Discovered some problems, e.g., in hash computation. Server-based Certificate Validation (A. Malparni-ValiCert) A suggestion to explore "outsourcing" certificate validation to a server, from a client. Proposal is to develop a protocol between a client and the validation server, which might be attractive when the client is not computationally capable, or to help by centralizing administration of certificate validation management. There are security concerns here, because of the centralization of security function in servers. MISPC Reference Implementation (T. Polk-NIST) CDROM contains CA, RA, and client executable code. Represents a profile of 2459, CMP, and CRMF. Available via web site: http://crscnist.gov/pki/mispc/
- meeting minutes, 1st draft Stephen Kent