Subject: draft meeting minutes

From: Stephen Kent <[email-masked]>
Date: Wed, 8 Nov 2006 22:43:32 -0500

Please send comments to me by 11/27.

Steve
-----

PKIX WG Meeting 11/8/06

Edited by Steve Kent
Chairs: Stephen Kent <[email-masked]> &  Stefan Santesson <[email-masked]>

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. A straw poll 
will be conducted on the WG list. (slides)

---

From: Russ Housley <[email-masked]>
Date: Thu, 09 Nov 2006 13:06:03 -0500

Dear PKIX WG:

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.)

This is draft-choi-pkix-ui-03.txt.

It is not a PKIX WG document, but the authors have not responded to
messages from me.  I am going to drop it if the authors do not
respond soon.  If the PKIX WG thinks there is value in this
document, I'll send it to the WG instead of dropping it.

Russ

---

From: "Stefan Santesson" <[email-masked]>
Date: Thu, 9 Nov 2006 21:12:59 -0000

This document does not specify any protocol.

It specifies subjective design criteria for a UI that I seriously doubt
can be a base for a consensus process.

If this document is progressed I suggest that it is handled as an
informational input progressed outside of the pkix wg.

Stefan Santesson

Senior Program Manager

Windows Security, Standards

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Russ Housley
Sent: den 9 november 2006 10:06
To: Stephen Kent; [email-masked]
Subject: Re: draft meeting minutes

Dear PKIX WG:

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.) 

This is draft-choi-pkix-ui-03.txt.
It is not a PKIX WG document, but the authors have not responded to
messages from me.  I am going to drop it if the authors do not respond
soon.  If the PKIX WG thinks there is value in this document, I'll send
it to the WG instead of dropping it.

Russ

---

From: Russ Housley <[email-masked]>
Date: Thu, 09 Nov 2006 18:36:32 -0500

Thanks.  If I do not hear from the authors soon, then I will presume
that the effort is dead.

Russ

At 04:12 PM 11/9/2006, Stefan Santesson wrote:

Stefan Santesson

Senior Program Manager

From: [email-masked]
[
mailto:[email-masked]] On Behalf Of Russ
Housley

Dear PKIX WG:

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.)

Russ