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

NOTE: This charter is a snapshot of the 39th IETF Meeting in Munich, Bavaria, Germany. It may now be out-of-date.

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:

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:

No Request For Comments

Current Meeting Report

Minutes of the PKIX Working Group Meeting

The PKIX Working Group met twice at the 39th IETF. A total of about 200 IETF attendees participated in these two meetings. The primary focus was status reports on the six PKIX documents. (Note that the last two of these are new documents, on which work was initiated as a result of discussions at the Memphis meeting. Hence Parts 5 and 6 are trailing the other documents.) Additional discussion focused on the topic of choosing default cryptographic algorithms.

I. Part 1: X.509 Profile (Tim Polk, NIST)

Ready to go after a few minor editing changes for clarification. Plan to go to last call in September.

II. Part 2: Operational Protocols (Sharon Boeyen, Entrust)

Major changes from Memphis include LDAP modification profile, HTTP mechanisms (not complete), and e-mail (very new, not complete). Other refinements include several OCSP changes and additions.

Outstanding issues:

· e-mail appendix is very new and requires review
· OCSP questions about path validation
· retention of historical CRLs
· OCSP caching
· LDAP responses should be signed, not just SSL protected, but this is not currently supported in LDAP
· need HTTP content type label assignment
· do we still need FTP support, given HTTP availability?
· has the document grown too big?

A suggestion was made to split apart the mechanisms by mechanism, e.g., LDAP, HTTP, OCSP, and FTP. Volunteers available for all the parts, except maybe FTP, so we decide to do this, subject to list approval. Plan to go to last call next month on LDAP. HTTP and OCSP documents not yet ready. We assume that the FTP portion will be ready soon, but need confirmation from author (who was not present). Relative to the recently introduced requirement for default algorithms, some of these documents will have to adopt such algorithms, e.g., OCSP. PowerPoint slides will be available in the IETF on-line minutes.

III. Part 3: Management Protocols (Carlisle Adams, Entrust)

Carlisle presented an evaluation of the Myers proposal (discussed below), arguing that the proposal is currently incomplete and that some portions call for processing not compatible with deployed PKCS 7/10 implementations. At lunch after the meeting, Carlisle and Mike, in discussion with the WG co-chairs, agreed to move the discussion of the use of PKCS 7 and 10 for certificate management protocols (currently in a PKIX Part 3 appendix) to a new standards track document (to be edited by Mike). PKIX Part 3 will progress to last call after this modification is performed. The document already defines default algorithms consistent with the recent IESG recommendations (3-DES, DSA, DH, and SHA-1), but a default modulus (1024 bits) will be added, as suggested by a meeting attendee. PowerPoint slides will be available in the IETF on-line minutes.

IV. Part 4: Policy Framework (Warwick Ford)

Not a standards track document, but rather an Informational or BCP RFC. Document is ready for last call after next revision, with minor changes, next month.

V. Part 5: Time Stamping (Robert Zuccherato, Entrust)

Brief presentation of what a Time Stamp Authority (TSA) does, and a proposed protocol (format and message flow). See PowerPoint slides in on-line minutes. Concern expressed over possible patents in this area, e.g., by Pitney-Bowes and Fischer International. Need to resolve these concerns. Also, a concern was expressed over the extent to which the proposed protocol is amenable to various techniques that can be employed to protect against the TSA corruption. Suggestion to consider alternative time stamping approaches, e.g., Surety technique, is rejected as out of scope for this WG. Instead, the WG chairs direct the document to explicitly state the intended scope, i.e., time stamping in an X.509 PKI context (hence, using public-key digital signature technology). PowerPoint slides will be available in the IETF on-line minutes.

VI. Part 6: Notary Protocols (Robert Zuccherato, Entrust)

Not so well defined as TSA document (Part 5). In the digital signature and security literature, the notarization function is tightly tied to the time stamping function, and one could easily imagine making the TSA a part of the larger notary function. The distinctions between this function and the TSA function, as presented here, are binding proof of possession of the data to the submitter and, possibly, vouching for validity or truth of the data submitted for notarization. Thus this function entails signature and certificate path validation by the notary, including CRLs and ARLs, and might entail other, more complex assertions about the data. It is not clear whether this is a critical function for general, Internet PKI use, and thus is it not yet considered to be a part of the base PKIX standards. Further discussion on this point will be undertaken on the list and at the next IETF meeting. See PowerPoint slides in on-line minutes.

VII. Myers Certificate Management Protocol: (Tim Polk, NIST)

Discussion lead by Tim, but the submission in question is authored by Myers et al. (VeriSign). The proposal calls for use of PKCS 7 as security encapsulation protocol and PKCS 10 as certificate management protocol. The current version of PKCS 10 is primarily oriented toward RSA support, which is not consistent with the algorithm independence goals of PKIX, and it does not support the full range of certificate management functions defined in PKIX Part 3. It is argued that future versions of these RSA standards will be capable of supporting all of these requirements, but the current proposal does not address these concerns. Similar concerns arise with regard to PKCS 7 as a secure encapsulation protocol. Moreover, the PKCS series are not under IETF control and thus there are concerns about making the PKIX management protocols too dependent on these standards. Still, there is significant support for use of PKCS 7 and 10 because of the installed base and availability of supporting toolkits. See the discussion of PKIX Part 3 above for further details.

VIII. KEA: (Tim Polk, NIST)

KEA, because it is a classified algorithm, is not part of the base specs and will be covered by a separate document.

Default algorithm suite: (Steve Kent, BBN & Jeff Schiller, MIT)

There is a recent trend by the IESG to encourage WGs to define a default (MUST implement) algorithm suite to enable interoperability. For example, the TLS proto-RFC were rejected by the IESG because of the use of a proprietary encryption algorithm (RC4) and a patented public key algorithm (RSA). The emerging pattern (in TLS and SSH) is to use DSA (vs. RSA) as a public key signature algorithm and to use Diffie-Hellman as a key agreement algorithm, to avoid patent issues.

However, we note that most of the deployed certificate technology is RSA-based, making this deployed technology non-compliant if we mandate DSA. Also, European attendees expressed concern over the patent status of DSA in Europe (vis a vis Schnoor patent). Jeff will ask the ISOC attorneys to evaluate the patent status of DSA on an international basis, relative to possible adoption of DSA as the default digital signature algorithm for use in some parts of PKIX.

Jeff suggests that the PKIX management protocols WILL need to adopt a default set of algorithms for hash, signature, encryption key management, and encryption. The current trend would be to call for use of DSA for signatures. Jeff is not prepared to state that the IESG will require PKIX to mandate DSA as the default algorithm for certificate signatures. Thus, it would seem that Part 1 need not mandate any signature and hash algorithm, but that Part 3 and some parts of Part 2 will require the addition of such default algorithms.

Slides

The PKCS 7/10 Proposal: Some Thoughts
PKIX V: Time Stamp Protocols
PKIX VI: Notary Protocols
PKIX Part 2: Operational Protocols

Attendees List

go to list

Previous PageNext Page