2.6.6 Public-Key Infrastructure (X.509) (pkix)

NOTE: This charter is a snapshot of the 45th IETF Meeting in Oslo, Norway. It may now be out-of-date. Last Modified: 04-Jun-99

Chair(s):

Stephen Kent <kent@bbn.com>
Warwick Ford <wford@verisign.com>

Security Area Director(s):

Jeffrey Schiller <jis@mit.edu>
Marcus Leech <mleech@nortel.ca>

Security Area Advisor:

Jeffrey Schiller <jis@mit.edu>

Mailing Lists:

General Discussion:ietf-pkix@imc.org
To Subscribe: ietf-pkix-request@imc.org
In Body: subscribe (In Body)
Archive: http://www.imc.org/ietf-pkix

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:

Request For Comments:

RFC

Status

Title

 

RFC2459

PS

Internet X.509 Public Key Infrastructure Certificate and CRL Profile

RFC2510

PS

Internet X.509 Public Key Infrastructure Certificate Management Protocols

RFC2511

PS

Internet X.509 Certificate Request Message Format

RFC2527

  

Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework

RFC2528

  

Internet X.509 Public Key Infrastructure Representation of Key Exchange Algorithm (KEA) Keys in Internet X.509 Public Key Infrastructure Certificates

RFC2559

PS

Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2

RFC2585

PS

Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP

RFC2587

PS

Internet X.509 Public Key Infrastructure LDAPv2 Schema

RFC2560

PS

X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP

Current Meeting Report

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.

Slides

An Internet AttributeCertificate Profile for Authorization
Basic Event Representation Token (BERT)
Attribute Certificate profile for authorization
RFC 2459 Status
SCVP
Temporal Data Authority
Time Stamping Protocol (TSP)