NOTE: This charter is a snapshot of the 40th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 24-Oct-97
Chair(s):
Stephen Kent <kent@bbn.com>
Warwick Ford <wford@verisign.com>
Security Area Director(s):
Jeffrey Schiller <jis@mit.edu>
Security Area Advisor:
Jeffrey Schiller <jis@mit.edu>
Mailing Lists:
General Discussion:ietf-pkix@tandem.com
To Subscribe: listserv@tandem.com
In Body: subscribe <email address> ietf-pkix
Archive: ftp://ftp.tandem.com/ietf/mailing-lists/current
Description of Working Group:
Many Internet protocols and applications which use the Internet employ public-key technology for security purposes and require a public-key infrastructure (PKI) to securely manage public keys for widely-distributed users or systems. The X.509 standard constitutes a widely-accepted basis for such an infrastructure, defining data formats and procedures related to distribution of public keys via certificates digitally signed by certification authorities (CAs). RFC 1422 specified the basis of an X.509-based PKI, targeted primarily at satisfying the needs of Internet Privacy Enhanced Mail (PEM). Since RFC 1422 was issued, application requirements for an Internet PKI have broadened tremendously, and the capabilities of X.509 have advanced with the development of standards defining the X.509 version 3 certificate and version 2 certificate revocation list (CRL).
The task of the working group will be to develop Internet standards needed to support an X.509-based PKI. The goal of this PKI will be to facilitate the use of X.509 certificates in multiple applications which make use of the Internet and to promote interoperability between different implementations choosing to make use of X.509 certificates. The resulting PKI is intended to provide a framework which will support a range of trust/hierarchy environments and a range of usage environments (RFC1422 is an example of one such model).
Candidate applications to be served by this PKI include, but are not limited to, PEM, MOSS, GSS-API mechanisms (e.g., SPKM), ipsec protocols, Internet payment protocols, and www protocols. This project will not preclude use of non-infrastructural public-key distribution techniques nor of non-X.509 PKIs by such applications. Efforts will be made to coordinate with the IETF White Pages (X.500/WHOIS++) project.
The group will focus on tailoring and profiling the features available in the v3 X.509 certificate to best match the requirements and characteristics of the Internet environment. Other topics to be addressed potentially include:
o Alternatives for CA-to-CA certification links and structures, including guidelines for constraints
o Revocation alternatives, including profiling of X.509 v2 CRL extensions
o Certificate and CRL distribution options (X.500-based, non-X.500-based)
o Guidelines for policy definition and registration
o Administrative protocols and procedures, including certificate generation, revocation notification, cross-certification, and key-pair updating
o Naming and name forms (how entities are identified, e.g., email address, URN, DN, misc.)
o Generation of client key pairs by the PKI
Goals and Milestones:
Oct 95 |
|
Agree on working group charter. |
Nov 95 |
|
Complete initial strawman PKI specification. |
Dec 95 |
|
First meeting at Dallas IETF. |
Jul 96 |
|
Submit PKI (X.509) specification to IESG for consideration as a Proposed Standard. |
Internet-Drafts:
· Internet Public Key Infrastructure X.509 Certificate and CRL Profile
· Internet Public Key Infrastructure Certificate Management Protocols
· Internet Public Key Infrastructure Operational Protocols - LDAPv2
· Internet Public Key Infrastructure Certificate Policy and Certification Practices Framework
· Internet Public Key Infrastructure
· Internet Public Key Infrastructure Part V: Time Stamp Protocols
· Internet Public Key Infrastructure Representation of Key Exchange Algorithm (KEA) Keys in Internet Public Key Infrastructure Certificates
· Internet Public Key Infrastructure Operational Protocols: FTP and HTTP
· Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP
· Internet X.509 Public Key Infrastructure Representation of Elliptic Curve Digital Signature Algorithm (ECDSA) Keys and Signatures in Internet X.509 Public Key Infrastructure Certificates
No Request For Comments
Minutes of the Public-Key Infrastructure (X.509) (PKIX) WG
Approximately 360 attendees participated in the two PKIX WG session at the 40th IETF. Several of the PKIX I-Ds have been through working group last call and have moved on to the IESG for review, but a few issues remain and must be resolved prior to IESG approval and IETF last call.
I. Part 1 (Certificate/CRL Profile)
This draft completed WG last call, but a few issues remain to be resolved. Issues relating to use of algorithm OIDs and some ASN.1 errors have been resolved, and the authors have avoided inclusion of some legal language that was previously proposed.
Unresolved issues:
· There is disagreement about wildcarding in names (e.g., DNS and RFC 822). A small group met to resolve this issue after the (2nd) meeting. That group suggested disallowing use of asterisks in these name forms as a means of conveying the notion that the name was a place-holder for a set of names. Instead, a new document will be created to describe name form conventions, on a per-application context basis, with explicitly declared semantics, in support of the requirements that motivated use of wildcard name forms.
· We are using '88 ASN.1, but BMP string is a new ASN.1 construct, so this is a technical matter (but does not affect bit on the wire format).
· There is a related issue is use of UTF8, a new ('98 ASN.1) character set encoding, an alternative to BMP. This appears to be an issue at the IESG last call level of approval, but is not an issue among PKIX members.
· For key usage, we propose to stay with what X.509 says, despite disagreements over whether it is the "right" interpretation.
· Should CRLDistributionPoint be critical, non-critical, or at the discretion of the CA? Currently, it cannot be marked critical, but this can cause problems. The concern is that if marked critical, then a client without support for this would reject the certificate, even if the user was willing to ignore this extension, as required by X.509. Not resolved.
II. Part 2 (Split into LDAP, FTP, HTTP, OCSP)
No problems with FTP or HTTP. LDAP v2 profile completed both last calls and is to be forwarded to IESG for approval. We agree to add a new work item to deal with v3, since current LDAP use in PKIX is based on v2. There was a suggestion to add a work item to develop a minimal schema for PKIX use of LDAP. This is a possible overlap with the LDAP WG, so coordination is required. Later during the week the LDAP WG chair was contacted and it was determined that creation of a schema for use with PKIX was within the purview of the PKIX WG. See slides for additional details.
III. Part 3 (Certificate Management Protocol)
No issues here other than the character set concerns raised under Part 1.
IV. Certificate Request Syntax (PKCS7/10 focus)
A proposal was made to move work on this to S/MIME WG, and Schiller and Housley (S/MIME WG chair) have no objections. However, this work is not S/MIME-specific and several PKIX and S/MIME WG members believe that this work item should remain in PKIX, as it is more general. The fundamental question is whether CRS is a completely separate protocol, focused on S/MIME, or if it is a profile for Part 3. This was subsequently resolved [see below]. A straw poll of attendees showed a plurality of attendees in favor of keeping the work item in this WG, and only a single vote in favor of moving it to S/MIME. The S/MIME WG, meeting two days later, concurred with this and did not recommend adoption of CRS within that WG, assuming that PKIX would reconcile CRS/CMP differences and include a specification for securely transporting commonly-agreed certificate management messages over
V. CMS (i.e., son of PKCS 7)
At the second PKIX WG meeting, a compromise approach was announced, aimed at reconciling differences between CRS and CMP. In essence, a common certificate request message syntax was agreed upon, and CMP will adopt this syntax as the certificate request payload type within that protocol (replacing the current certificate request payload format). CRS also will be revised to reference that syntax. This new, harmonized certificate request format will appear as a separate RFC. It is not anticipated that this will delay the progression of CMP to proposed standard, since it is simply a protocol syntax change for alignment purposes, plus a splitting of one document into two in the interest of facilitating future developments.
CRS will continue to progress, specifying the mapping of certificate management messages onto CMS and providing the vehicle for producing and RFC (or RFCs) that document agreed common formats for other certificate management messages (i.e., messages other than certificate request).
VI. Time-Stamping and Notary Protocols
These are new, potential work items, discussed on a preliminary basis in Munich. Two presentations: Rob Zuccherato (Entrust) on time stamping and notary functions, and Stuart Haber (Surety) on time stamping. See slides for additional details.
Entrust- Time stamping service described here deals exclusively with establishing existence of data (really a hash of data) at a point in time. Basic notary service for data demonstrates that a requester posses data (not just a hash of the data) at a given time. A certificate notary service requires validation of a certificate chain for the requester, including CRLs and ARLs. There is also a fancy data notarization service, encompassing data validity, and a combined service of data possession and validity. Some folks note that validation of data (and certificates) is outside the scope of what real world notaries do in the U.S. (but Latin Notaires do have broader functions).
Surety- Stuart provided an overview of time stamping problem and solution space, with a focus on the hash tree technology developed (patented) and offered by Surety as a service. The current Surety service offers a 1 second granularity,
At least one WG member argued that the notary and time stamping functions are not completely PKI-specific, and we should try to avoid duplication of efforts like the PKIX/SPKI situation. Another member noted that there is a new I-D for time stamping via NTP, that raises possible overlap concerns as well. One possible outcome is a split of time stamping vs. notary functions. Certificate path validation, a part of the described notary service, does make sense for PKIX, consistent with X.509 validation procedures.
A straw poll during the second PKIX meeting showed a strong sentiment that this WG amend its charter to include development of a standard for time stamping, but there was not strong support for adding a work item to develop notary functions (other than certificate path validation). Thus an extension of the WG charter will be proposed to the IESG in order to address time stamping.
VII. OCSP
Mike Myers provided a status review for this I-D, and responded to comments that have appeared on the WG list over the last few weeks. A number of modifications will be made as a result of these comments Mike described a schedule for revisions and (new) comments to bring OCSP to WG last call in time for the next (LA) IETF meeting. Included in the revisions will be a better characterization of the contexts in which OCSP are expected to operate, since that range of environments has grown since OCSP was initially designed. To better accommodate this diversity, a document structure was proposed that establishes a base OCSP document and syntax and one or more supplementary texts that build upon
the base syntax, as noted above.
None Received