NOTE: This charter is a snapshot of the 41st IETF Meeting in Los Angeles, California. It may now be out-of-date. Last Modified: 05-Feb-98
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/pub/ietf-pkix.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 X.509 Public Key Infrastructure Certificate Management Protocols
· Internet X.509 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
· Certificate Request Message Format
· Internet X.509 Public Key Infrastructure Certificate Management Message Formats
· Certificate Management Messages over CMS
· Internet X.509 Public Key Infrastructure LDAPv2 Schema
No Request For Comments
Minutes of the Public-Key Infrastructure (X.509) (pkix) Working Group
I. Certificate and CRL Profile
Tim Polk summarized the status and outstanding issues on Draft 07 of the profile. It is essential that this document be progressed quickly since several other standards are waiting on it. New additions to 07 include the addition of UTF-8 in accordance with IETF Best Practices, correction of the path processing algorithm to align with X.509, and removal of semantics for wildcards in alternative names. A few other minor fixes have been noted but not yet published. The TLS group has requested that wildcards not be forbidden. Also, after discussion on the mailing list and in other places, it was decided that issuer name (a distinguished name) must be in all certificates, and that CA validation chaining should not include any alternative names of a CA.
Beyond these issues, the document is currently stuck in last call owing to patent issues resulting from an Entrust patent issued in December. Tim proposed that all text relating to unresolved issues be removed to a separate I-D, and the rest of the document be progressed immediately to Proposed Draft. This means removing CRL distribution points, authority access info, and some policy qualifiers, and removing URI semantics from altnames. (Sections impacted: Policy Qualifiers, CRL Distribution Points, and Issuing Distribution Points.) Steve Kent reported that the Area Director had agreed with this approach. A straw poll of those present indicated strong support for and no support against this approach.
II. OCSP
Mike Myers described the current status. Recent changes included adoption of ASN.1 notation and transport independence. It is also proposed that the following changes be made. Clients and servers SHALL support basic response. Make clear that CRLs not be required to implement OCSP. The response is modified to only send back certID. The "certificate data required" response will be kept. The policy ID extension will be deleted. The CRL inclusion extension exceeds the scope, therefore the "noCRL" response should be deleted. Nobody raised objections to any of these.
With regards to specification of non-CA responders' certificates, it is proposed that we define an extension to enable clients to specify which key to use to sign responses. It is also proposed to define an extension to enable clients to specify the key they are currently relying on. (The responder only sends its certificate back if different.) Re caching of responses, it is proposed that a separate draft be produced on transport mechanisms to address caching. The reference to authority information access will also be removed for patent reasons.
The possibility of using CMS to protect OCSP was raised. This will be considered.
Ambarish Malpani briefed the group on the following open issues: What types of responders to OCSP requests will be supported: CA, client-trusted responder, CA-designated responder? Also the issue of the semantics of thisUpdate, nextUpdate, and producedAt. (Descriptions need to be tightened up.) Also the method of identification of certificates - should it include a hash of the public key of the issuer?
Mike Myers raised some issues of response semantics: Does notRevoked imply that the certificate exists? Should there be multiple status bits returned, e.g., one bit for expired, one for revoked? (General feeling: Yes.) What should the response be for a certificate known to have not been issued? It was also pointed out that there may be a patent by Silvio Micali covering OCSP. The authors were asked to explore.
III. IPSEC Support
Rodney Thayer described IPSEC PKI requirements, and work to prepare an IPSEC specification for use of PKI and PKIX. Issues include subject names (and altnames), cross-certification, off-line operations, hard limits (e.g., on hierarchy depth), identity vs. address vs. usage, and extended key usage. For cross-certificates, there is a need for an optional nameConstraint containing DNSname, RFC822name, or IPaddress. For IPaddress Rodney proposed to use an address plus mask. This is not yet resolved.
PKIX Minutes - April 2, 1998
I. LDA Profile and Schema
Pat Richard reported that the LDAP v2 profile had been rejected by the IESG because of some security issues (subsequently fixed in a revised draft), the absence of a schema, the need for a section on "acceptable searches", and the fact that LDAP v2 rather than v3 is used. A new schema draft has been produced - the profile will not be approved by the IESG without simultaneous approval of this schema. Re v2/v3 there are various options. Tim Howes reported that work is still under way on some v3 extensions (access control, referrals, replication), but this probably does not impact PKIX. There are two choices on how to proceed: (1) produce v2 profile and schema then make them informational when v3 is developed, and (2) stop work on v2 and start work on just v3. On a show of hands, there was substantially more support for (1) than (2). This will also be referred to the list.
II. CRMF, CMMC and CMC
Mike Myers outlined the status of these projects. CRMF defines a standard format for a certificate request. CMMF defines message formats for other certificate management functions. CMC defines a protocol for carrying CRMF and CMMF messages over CMS, to support certification of a public key, querying status of certificate requests, and certificate/CRL retrieval.
Some comments were received on CRMF, regarding public-key MAC, registration control, PKI archive options, the definition of dhMAC, and ASN.1 imports/exports. These will be addressed in an updated draft of CRMF.
Paul Hoffman raised the question of possible pending patents impacting CRMF and CMC, and suggested that the Chairs try to get commitments from authors that there are no current or anticipated patent encumbrances. Attention was also drawn to RFC 2028 which spells out expectations regarding intellectual property disclosures by IETF participants.
Mike also presented a list of open issues (most submitted by Jim Schaad) for CMMF and CMC. Some of the issues require discussion on the list before resolution. The following significant issues were discussed:
(1) CMRF describes the certificate request message of choice for PKIX. CMC specifies an alternate format as "mandatory to implement". The sense of the group was that CRMF should be the mandatory request format for CMC.
(2) Carlisle Adams noted that secure initialization is not a feature of CMC. After some discussion, there was a straw poll. The sense of the group was that secure initialization should be feature of CMC and should be mandatory to implement. This requirement can be supported using the CRMF message format discussed above.
(3) Paul Hoffman brought up the idea that CMC and CMP should both offer CAs the same services so that a CA vendor doesn't have to implement both in order to get all the services needed by their application. He suggested that if the WG wants to come out with two parallel protocols to do the same thing, it should be sure they do the same thing.
(4) The CMMF draft contains alternative formats for most messages. In brief discussion of this fact, some attendees indicated a single format for messages would be preferable. There was no discussion of how this could be achieved.
(5) CMC includes a Diffie-Hellman based MAC. Paul Hoffman asked about the patent status of this feature. The WG chair asked the authors to determine the patent status and report to the group.
It was clarified that a new draft of CRMF will be produced taking into account ASN.1 fixes and the fixes mentioned above. This new draft will be sent to the IESG to replace the draft they are currently considering. The target timescale for CMMF and CMC documents is to go to last call at the Chicago IETF.
III. Timestamp AMP and Notary Drafts
Rob Zuccherato presented an update on the timestamp and notary drafts. The PKIX charter has not been modified, so both the timestamp draft and the notary protocol draft have been moved to independent status. Jeff Schiller informed the WG that he will not consider amending the charter until the profile becomes an RFC.
Revised drafts for these protocols are now available under "ietf-draft-adams-*" Most of the discussion centered on the difference between the two protocols, which remains a source of confusion. The timestamping protocol does not attempt to verify the identify of the submitter; the notary protocol does. The notary protocol may also attempt to validate a particular certification path at the time of submission. This may be useful since secure archiving support is not widely deployed.
The title of the notary protocol may be one reason for the confusion. It was suggested that the draft be renamed to reduce the ambiguity. Another reason is the perceived overlap between the notary protocol and OCSP. The goals of the protocols are very different; this should probably be clarified in the notary draft.
Rob presented several outstanding issues for discussion. As a result of the discussion, the group requested that the timestamp draft use CMS signed data encapsulation, and omit the requester name in the response. (Since the timestamp server does not verify the requester's identity, its appearance in the response gives the wrong impression.)
In addition, Rob noted that both areas are the subject of numerous patents. This may present a difficulty in progressing the drafts.
Brian LaMaachia presented implementation issues that he has encountered in the area of path building. In particular, inconsistent use of key identifiers and distinguished name fields makes it difficult to develop paths. As a result of this discussion, the group proposed to require key identifiers in all certificates and clarify the name matching rules. In conjunction with the proposal to require issuer distinguished names in all certificates, key identifiers will greatly simplify path building in PKIX1 compliant systems. The name matching rules will clarify ambiguities introduced by BMPString and UTF8String encodings.
OCSP
Notary Protocol
Time Stamp Protocols