Subject: RE: Straw poll for Algorithm Identifiers in Subject Public Key In fo.

From: Robert Zuccherato <[email-masked]>
Date: Tue, 12 Dec 2006 13:26:21 -0500

I vote NO on this straw poll.  I am concerned that if PKIX follows this
proposal, then there will be two methods for indicating supported ECC
algorithms, one defined by ANSI X9.62 and the other defined by PKIX.  If we
could be certain that ANSI X9 would adopt the PKIX proposal (in a timely
manner) then I could be persuaded to change my vote.  

	Robert Zuccherato.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stefan Santesson
> Sent: December 6, 2006 9:48 AM
> To: [email-masked]
> Subject: Straw poll for Algorithm Identifiers in Subject 
> Public Key Info.
> 
> 
> 
> I'm requesting a straw poll on the future direction of 
> specifying algorithm identifiers in the Subject Public Key 
> Info field in X.509 certificates.
> 
> Background
> ----------
> The draft 
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-ecc-pkalgs
> -03.txt defines algorithm OIDs for ECC to be included in the 
> Subject Public Key Info field. One of these OIDs (specified 
> by ANSI X9.62/2005) allow a list of supported algorithmic 
> modes to be specified with the parameters of the public key.
> 
> Concerns about this approach has been raised on the list, 
> primary because it presents a new approach for the same 
> problem as adapted by RFC 4055, where new algorithm OIDs have 
> been defined for some modes of RSA. Another concern raised is 
> that the deployed products today are not deigned to handle 
> usage restrictions provided in the Subject Public Key Info 
> field, and doing so would require updates of crypto library 
> API's in a way that would severely harm deployment and 
> interoperability. Finally, it was exposed that the structured 
> OID from the ECC algs draft is limited to the use of the 
> public key with SHA-1, which is a quite unacceptable restriction.
> 
> The defenders of the ECC algorithm draft has pointed at the 
> fact that the algorithm OIDs of this draft is defined by ANSI 
> X9.62/2005 and should be valid also for PKIX, and the fact 
> that problems related to mode restrictions in the subject 
> public key info field, also apply to RFC 4055.
> 
> Recently a design team was formed under the leadership of Tim 
> Polk, which provided a report and a proposed way forward, 
> presented at the PKIX meeting during the San Diego IETF in 
> November 2006. The slides from this presentation is available 
> from:  http://www3.ietf.org/proceedings/06nov/slides/pkix-7.ppt
> 
> The design team concluded that both the approach of RFC 4055 
> and the approach of the current ECC algorithms draft are 
> problematic. They also concluded that implementation of RFC 
> 4055 is almost non-existent, except a few experimental 
> environments. As a result, the design team  suggested a 3rd approach.
> 
> 
> The proposal from the Design team
> ---------------------------------
> The proposal from the design team is to revert back to the 
> algorithm OIDs defined in RFC 3279, using a single OID for 
> ECC, and to defer mode restrictions to a future certificate 
> extension to be specified in a new PKIX draft.
> 
> In addition, Russ Housley has stated that the use of 
> different approaches for RSA keys and EC keys is unacceptable 
> to him.  Therefore, this straw poll assumes that RFC 4055 
> will also be revised to align with the Design Team 
> recommendation.  That is, the new extension will be designed 
> to cover the algorithms and modes listed in RFC 4055 as well 
> as the EC algorithms and modes studied by the Design Team.
> 
> 
> The straw poll
> --------------
> I would like to make a simple straw poll if this group can 
> accept the proposal of the design team, with the amended task 
> to also align RFC 4055 with this approach.
> 
> Please reply with a YES, or a NO.
> Optionally provide a short motivation for your vote.
> 
> Thank you.
> 
> 
> Stefan Santesson
> Senior Program Manager
> Windows Security, Standards
> 
> 
>

---

From: Robert Zuccherato <[email-masked]>
Date: Tue, 12 Dec 2006 13:26:21 -0500

Robert Zuccherato.