Subject: Call for volunteers for a ECC subject public key info design team

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 29 Sep 2006 03:49:01 +0100

We have since quite some time had two diverse positions on how to
specify subject public key info for ECC public keys in X.509
certificates.

On one hand the current proposal embracing the ANSI solution with a
structured subject public key info that has the capacity to specify
algorithm modes, and the RFC 4055 approach on the other hand using a
single OID to specify algorithm and parameters.

As other groups are dependent on our progress on this issue, in
particular the Kerberos group, the Security ADs has requested us to form
a design team to prepare a decision for the WG.

The design team shall;

(1) be made up of no more than five people.

(2) interview (via the phone and/or e-mail) concerned parties.

(3) document the pros and cons of each proposal, and make a
recommendation to the WG.

The authors of RFC 4055 and authors of draft-ietf-pkix-ecc-pkalgs should
be excluded from design team membership.

The selected design team should be prepared to make their recommendation
at the PKIX meeting in San Diego (or before on the mail list, which
would be even better).  Then, the PKIX WG can have a straw poll to see
if the design team recommendation is accepted.  Of course, it needs to
be followed up by WG mail list confirmation.

If you are interested to be part of this design team, please send me and
Steve Kent an e-mail no later than Friday next week (October 6).  

Stefan Santesson

Senior Program Manager

Windows Security, Standards

---

From: Daniel Brown <[email-masked]>
Date: Fri, 29 Sep 2006 10:27:56 -0400

certificates.
> single OID to specify algorithm and parameters.

Ok, but again, just to clarify: this oversimplifies RFC 4055, which uses 
up to three OIDs: one to specify the algorithm, and then some further 
optional OIDs to specify the paramters.

Many of the objections I've heard to the ANSI syntax apply equally well to 
RFC 4055. 

The main difference between the two approaches is that ANSI inserts one 
extra layer: a SEQ of OIDs (and parameters as needed), whose purpose is 
allow a single cert to permit more than one algorithm mode without leaving 
it completely open.

My suggested compromise is to fix the ANSI sequence length to at most one, 
which would make 4055 and ANSI functionally the same (by reducing the 
capabilities of the ANSI syntax).  This would leave only syntactical 
differences, which are trivial to handle.

Thanks,

Dan

> particular the Kerberos group, the Security ADs has requested us to 
> form a design team to prepare a decision for the WG.
> 
> The design team shall;
> 
> The authors of RFC 4055 and authors of draft-ietf-pkix-ecc-pkalgs 
> should be excluded from design team membership.
> 
> The selected design team should be prepared to make their 
> recommendation at the PKIX meeting in San Diego (or before on the 
> mail list, which would be even better).  Then, the PKIX WG can have 
> a straw poll to see if the design team recommendation is accepted. 
> Of course, it needs to be followed up by WG mail list confirmation.
> 
> If you are interested to be part of this design team, please send me
> and Steve Kent an e-mail no later than Friday next week (October 6). 
> 
> 
> Stefan Santesson
> Senior Program Manager

---

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 29 Sep 2006 15:53:42 +0100

Daniel,

First of all I would like to ask you to submit a new draft, at this
moment there is no valid draft available.

I'm not personally convinced restricting the sequence to 1 algorithm
solves the issue but what you state below is a good input to the design
team.

Stefan Santesson

Senior Program Manager

From: Daniel Brown [mailto:[email-masked]] 
Sent: den 29 september 2006 16:28
To: Stefan Santesson
Cc: [email-masked]; Stephen Kent
Subject: Re: Call for volunteers for a ECC subject public key info
design team

certificates. 

Many of the objections I've heard to the ANSI syntax apply equally well
to RFC 4055.   

The main difference between the two approaches is that ANSI inserts one
extra layer: a SEQ of OIDs (and parameters as needed), whose purpose is
allow a single cert to permit more than one algorithm mode without
leaving it completely open. 

My suggested compromise is to fix the ANSI sequence length to at most
one, which would make 4055 and ANSI functionally the same (by reducing
the capabilities of the ANSI syntax).  This would leave only syntactical
differences, which are trivial to handle. 

Thanks, 

Dan