PKIX WG Meeting 11/8/06

Edited by Steve Kent

Chairs: Stephen Kent <kent@bbn.com> & Stefan Santesson <stefans@microsoft.com>

The PKIX WG met once, for a total of two hours, during the 67th IETF. A total of approximately 50 individuals participated in the meeting.

Document Status Review - Stefan Santesson (Microsoft)

Two new RFCs issued: SIM and Update to Directory String Processing in RFC 3280. Five documents in IESG review: SCVP, Lightweight OCSP, and 3 CMC documents. Follow up is needed for the first two, and a revised I-D is needed for CMC. (Russ Housley requested WG direction re the UI draft. This individual submission received AD comments requesting changes, but no revised document has been delivered to the IESG.) Two documents have completed WG last call, and will soon be forwarded to the IESG: 3280bis and SAN for Service Names. Two documents still under WG review: ECC algorithms (waiting for resolution of algorithm parameter resolution) and the Draft for ECDSA and DSA with SHA-2. (slides)

PKIX WG Specifications

3280bis - David Cooper (NIST)

A new draft 05 was recently posted as response to past WG last call. David reviewed the changes made from version 4 to version 5, and provided an explanation for each change. (slides)

Simple Certificate Validation Protocol (SCVP)- Tim Polk (NIST)

This document is still in AD evaluation and a new draft requested by the AD. We are currently at version 28! Tim reviewed the changes made in response to Sam's comments. He noted that these changes were posted to the list on Halloween, and that there have been no responses to this posting. However, Tim identified one or two additional fixes that need to be effected before the document will be finished. He also identified one open issue, related to whether the document satisfies the interoperability requirements established by 2026.

[Sam wants us to run a straw poll to confirm that the WG is comfortable with a single spec that defines both DPD and DPV and does not mandate that a server do either one as a base.]

(slides)

Certificate Management Messages over CMS (CMC) - Jim Schaad (Soaring Hawk Consulting)

These documents are under IESG review which has resulted in several change requests. For example, there is a need for the section detailing the changes from the base documents (since this is a 'bis' document). There is also a need to accommodate hash algorithm agility, a relatively easy fix. A bigger issue is whether to change the OID used to refer to the encrypted data, because of the way S/MIME has defined this OID. A more significant issue is a request from the AD to make use of CRMF a MUST and make use of PKCS #10 structures a MAY. We plan to complete WG last call by December, in parallel with AD re-review. (slides)

Algorithm IDs for Elliptic Curve Cryptography in PKIX – Brian Minard (Certicom)

Dan Brown (the document author) could not be physically present, but monitored the presentation via Jabber. Looking for feedback on several issues, including support for parameters for SHA-2, and references to KDFs to be used with the public key in the certificate, in the context of EC-DH or EC-MQV. The question was raised as to why one needs to make reference to a KDF in a certificate, given that the KDFs are not protocol specific, but one needs protocol-specific details to completely specify how key derivation is performed. Much of the discussion on this topic is subsumed by the next topic. (slides)

Design team report on ECC public key IDs - Tim Polk (NIST)

We instantiated a design team of Tim, Brian Minard, and Tolga Acar to address this complex issue. RFC 3279 defines an OID for EC, and includes algorithm parameters, but this does not provide a way to distinguish between a bit string to be used with EC-DH vs. EC-MQV. Two choices were evaluated: RFC 4055-style solution vs. the ANSI X.962 solution to specify which algorithm or algorithms can be used with the key. RFC 4055 was developed to distinguish among RSA modes, but is easily adapted to accommodate ECC. ANSI X.962 puts into the parameters field the additional info needed to specify the algorithms that the key can be used with. This leads to potential nesting of OIDs, and one can also specify KDFs here as well. The design team suggested a third approach, namely to retain the 3279 parameter model, and to optionally augment it with a certificate extension to specify the additional data that the ANSI approach encodes in the parameters field, as well as accommodating the notion of family OIDs, something not supported in the ANSI approach. A feature of this approach is that if the extension is non-critical, the result is backwards compatible with 3279, but making it critical allows one to enforce the sort of fine-grained controls available in the ANSI approach. The team developed a set of criteria for evaluating the 3 approaches. They polled a variety of folks and got a diverse set of answers. Their decision was that the use of a new extension is preferred, in conjunction with the RFC 3279 ECC syntax. Numerous questions were raised by attendees. The discussion will continue on the list, and we will probably result in a new work item to resolve this issue, including asking whether the use of a new extension is appropriate for RSA as well (in lieu of RFC 4055). (slides)

Related Specifications & Liaison Presentations

Validation Certificates in CRLs - Stefan Santesson (Microsoft)

A new individual draft that proposes an optional extension that allows one to embed one or more certificates in a CRL. The intent is to facilitate CRL validation when the certificate(s) needed to verify a CRL are different from the certificate associated with the CA under whose auspices the CRL is issued. One can already embed a pointer to the requisite certificate, so the advantage to this approach is that it can save a retrieval request (across a net), and for CRL validation in the NR context, when CRL processing will take place long after CRL issuance. One should use this extension only in 'appropriate' contexts, e.g., to avoid unnecessary CRL bloat. The question is whether this be accepted as a WG document. If necessary, a straw poll will be conducted on the WG list after a more concrete proposal is presented. (slides)