PKIX WG Meeting 3/20/06

Edited by Steve Kent

Chairs: Stephen Kent <kent@bbn.com> & Tim Polk <tim.polk@nist.gov>

The PKIX WG met once, for one hour, during the 65th IETF. A total of approximately 34 individuals participated in the meeting.

Document status – Tim Polk (NIST)

RFCs just issued: CRL AIA, CertStore HTTP, Certificate Extensions for Authentication in PPP and WLAN, AND PKIX REP

Documents in the RFC editor's queue: GOST Crypto Algorithmns & Attribute Certificate Policies Extension

Documents with the IESG: SIM is in IETF last call, ending 3/20/06.

WG Last Call (completed or in process): SCVP, SRV, Lightweight OCSP, CMC drafts, UTF-8

Other WG documents in process: 3280bis & ECC algorithms

(Slides)

PKIX WG Document Presentations

Algorithm Agility in PKIX – Tim Polk (NIST)

Tim has reviewed PKIX protocols re algorithm agility, e.g., what is required to be able to migrate from one signature or hash algorithm to another in the context of the protocol. Certificates and CRLs are not algorithm agile, per se, but they are algorithm neutral. These data structures contain one signature created with one signature algorithm, as declared in the data structures. So, the only way to transition these data structures to new algorithms is to sign new structures, using the new algorithms. However, we have relatively few documents that specify how to use different signature or hash algorithms, e.g., DSA with SHA-1, ECDSA with SHA-1, RSA with MD5, the GOST algorithms, etc.

OCSP has an error facility to allow a sever to indicate that it does not support a given signature algorithm. However, the error response does not indicate what algorithms the server does support! In general we anticipate that an OCSP server supports the same algorithm suite as that which was used for certificate (and CRL) signing. We might address this via a new extension in the certificate issued to an OCSP server by a CA, or by creating a new, signed error response that is not specific to a given query or query issuer, but which states the set of supported algorithms. Lightweight OCSP is especially algorithm-specific, specifying SHA-1. Since it is a profile, this may be acceptable.

SCVP has been revised to better support algorithm agility. It does this via the server policy mechanism. Because OIDs are used for this signaling, there is no way to state key length constraints associated with given algorithms. For example, there is no way to say that a given server will not verify signatures generated with keys smaller (or larger) than some specified size.

CRMF seems to have no explicit way to signal algorithm preferences, although use of the policy OID might provide an indirect means for such signaling. Thus it may be necessary to add an extension to better support this.

In CMC and CMP there does not seem to be a strong need for algorithm signaling for RA/CA interactions, since these pairs of entities tend to be closely coordinated. Nonetheless, one can argue that such signaling is appropriate for subject to CA or RA requests, if only to accommodate transitions within the client base for a given CA/RA.

Attendees questions how serious the need is for the sort of agility being discussed, given a general lack of experience in dealing with such transitions in the real world. The suggestion is that we not rush into creating fixes before we understand the form this problem may take in practice.

The to-do list: think about signaling some more, develop a general strategy, apply to PKIX protocols, document the underlying assumptions about algorithm agility for our protocols. (Slides)

SCVP rev 23 - David Cooper (NIST)

As noted above, several changes were made to better support algorithm agility. The authors generated a compliance relative to RFC 3379 (requested by Steve Kent as part of final WG approval), and two changes were made as a result. (Slides)

3280bis - David Cooper (NIST)

One revision since the last meeting. Added AIA as a CRL extension, and deleted Appendix D (privateKeyUsagePeriod). A few remaining open issues to be resolved (e.g., URIs in cRLDistributionList, alignment with the UTF-8 I-D, with planned release of a final revision within a few weeks after this meeting. (Slides)

Universal Principal Name - Stefan Santesson (Microsoft)

A new I-D that specifies an ID in the form of an e-mail address, but does not assume that a mailbox with this name exists. This is widely used in MS products, and has been assigned an OID. The format and semantics were previously documented in RFC 4282, so the purpose of this document is to define a subject alternative name type (under Other Name) and to specify name constraints matching rules for it. The question for PKIX is whether we want to make this a WG document, or just have it submitted as an informational RFC? (Slides)

Related Specifications & Liaison Presentations

PKI Support in Opera - Yngve Pettersen (Opera Software)

Opera displays certificate info for browser users (e.g., organization name and country name), but they were unhappy that many CAs issued certificates where this data was not very reliable. Opera and several other players (WebTrust, Microsoft, and the ABA) propose the notion of 'extended validation' certificates, where better controls are employed by CAs. For the most part this is just a CA policy agreed upon by this group of vendors and issuers. However, the browser vendors may display a different lock icon in the browser UI to represent certificates issued under the this policy. Mapping of the policy OID to trust anchors would be managed by updates issued via MS security updates, Opera, and WebTrust. (Slides)