Subject: RE: Elliptic Curve Cryptography with PKIX

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 1 Sep 2006 13:14:23 +0100

I noticed that this draft has expired (02 draft expired July 2006)

I would appreciate if a new draft could be posted. And hopefully this
time not MIME tagged as a zip file :-)

On this issue I still agree with Russ. X.9 is going too far with this
X.509 field.

The purpose of this field is just to carry the public key and its
parameters.

The algorithm identifier serves to define what type of key and
parameters that are provided, not to define its usage.

If we change this, I think we violate an important principle of X.509
which may open a whole can of worms for the future.

A comparable situation would be (which has been proposed) if we instead
of just defining an RSA public key to be an RSA key, started to define
new identifiers with structured parameters that restricts the usage of
the key for e.g. signatures based on a certain rage of hash algorithms,
or key transport for certain symmetric algorithms. The list can be done
endless and so can the complexity.

But this is not how we do things.

The only reason I've seen so far why you may need to define different
algorithm identifiers for the same algorithm would be if a picking the
wrong algorithm mode would compromise the key or the expected level of
protection.

My understanding of this is that X.9 goes far beyond that.

Stefan Santesson

Senior Program Manager

Windows Security, Standards

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Waterhouse, Richard
Sent: den 31 augusti 2006 18:53
To: Russ Housley; Robert Zuccherato
Cc: Daniel Brown; [email-masked]
Subject: RE: Elliptic Curve Cryptography with PKIX

I liked the approach Mr Brown was proposing some time back though I
don't know where it stands today. I need to, for example, restrict a key
to be used with ECMQV. (I also need to, for example, inform the other
end that the key is based on the NIST p384 curve.)

	-----Original Message-----
	From: [email-masked]
[mailto:[email-masked]]On Behalf Of Russ Housley
	Sent: Thursday, August 31, 2006 10:48 AM
	To: Robert Zuccherato
	Cc: 'Daniel Brown'; [email-masked]
	Subject: RE: Elliptic Curve Cryptography with PKIX

	My opinion has not changed.  I believe that we need to follow
the precedent set by RFC 4055.
	
	In my opinion, this situation is a result of the ANSI X9 process
not allowing public review of their draft documents.  However, I do not
expect this policy to change.
	
	Russ
	
	At 10:24 AM 8/31/2006, Robert Zuccherato wrote:

	It's been more than a few months now since Russ posted this
message and I haven't seen any further discussion on the topic.  As I
said back in April, my preference would be for PKIX to use the
AlgorithmIdentifier in the already approved X9.62 standard, since I
don't think it is helpful to have more than one AlgorithmIdentifier
defined.
	
	However, whatever we decide to do, I think that we should
resolve the issue and advance the draft as quickly as possible.
Developers of ECC applications need to know which AlgorithmIdentifier to
use.  
	
	Does anyone else have any opinions on this topic?  When can we
hope to see a new ID? 
	
	        Robert Zuccherato. 
	
	> -----Original Message----- 
	> From: [email-masked] 
	> [ mailto:[email-masked]
<mailto:[email-masked]> ] On Behalf Of Russ Housley 
	> Sent: May 3, 2006 3:01 PM 
	> To: [email-masked] 
	> Subject: RE: Elliptic Curve Cryptography with PKIX 
	> 
	> 
	> 
	> RFC 3280 does not provide as much guidance as I would like.
Section 
	> 4.1.2.7 says the following about the  Subject Public Key Info
field: 
	> 
	>     This field is used to carry the public key and identify 
	> the algorithm 
	>     with which the key is used (e.g., RSA, DSA, or 
	> Diffie-Hellman).  The 
	>     algorithm is identified using the AlgorithmIdentifier
structure 
	>     specified in section 4.1.1.2.  The object identifiers for
the 
	>     supported algorithms and the methods for encoding the
public key 
	>     materials (public key and parameters) are specified in
[PKIXALGS]. 
	> 
	> Section 4.1.1.2 includes these words: 
	> 
	>     The algorithm identifier is used to identify a
cryptographic 
	>     algorithm.  The OBJECT IDENTIFIER component identifies 
	> the algorithm 
	>     (such as DSA with SHA-1).  The contents of the optional
parameters 
	>     field will vary according to the algorithm identified. 
	> 
	> It does not really provide much guidance to developers of 
	> AlgorithmIdentifiers. 
	> 
	> I characterize the X9.62 approach as using the OBJECT
IDENTIFIER to 
	> name a class of elliptic curve algorithms, and then using a
portion 
	> of the parameters to list the members of that class that are 
	> acceptable for the subject public key. 
	> 
	> I am very interested to know how this fits with real
implementations. 
	> 
	> My suspicion is that implementation that support key agreement
are 
	> used to looking into the parameter to determine if the public
key is 
	> a member of the same group.  This is needed for static-static 
	> Diffie-Hellman (in discrete log or elliptic curve).  This is
also 
	> needed for MQV (and KEA, if anyone cares anymore). 
	> 
	> My suspicion is that digital signature validation does not
anticipate 
	> constraints in the public key algorithm parameters.  An
underlying 
	> crypto routine may need the parameters, but the signature is
not 
	> going to fail because of a constraint in the parameters, which
could 
	> happen in this proposed syntax. 
	> 
	> I would greatly appreciate some insight from implementors. 
	> 
	> Russ 
	>

---

From: Daniel Brown <[email-masked]>
Date: Fri, 1 Sep 2006 10:03:43 -0400

"Stefan Santesson" <[email-masked]> wrote on 09/01/2006 08:14:23 
AM:

> I would appreciate if a new draft could be posted. And hopefully 
> this time not MIME tagged as a zip file

I will post a new draft, and make a special request that it be correctly 
MIME tagged as a text file. 

> 
> On this issue I still agree with Russ. X.9 is going too far with 
> this X.509 field.
parameters.
> If we change this, I think we violate an important principle of X.
> 509 which may open a whole can of worms for the future.
> 
> A comparable situation would be (which has been proposed) if we 
> instead of just defining an RSA public key to be an RSA key, started
> to define new identifiers with structured parameters that restricts 
> the usage of the key for e.g. signatures based on a certain rage of 
> hash algorithms, or key transport for certain symmetric algorithms. 
> The list can be done endless and so can the complexity.
> 

I disagree, based on my understanding on RFC 4055, which is a standards 
track. 

PKIX defined new identifiers in RFC 4055 with parameters restricting the 
use of a key.  The X9.62 syntax merely does the same thing, with the only 
difference being that the parameters carry more of the information than in 
RFC 4055 (I had thought that this was the only sticking point, but 
apparently there's a much larger issue).

Perhaps, you should ask the retract the MUSTs in RFC 4055 be restricted, 
if you don't wish the subject public key info to have such binding 
restrictions of algorithm usage.

> 
> The only reason I?ve seen so far why you may need to define 
> different algorithm identifiers for the same algorithm would be if a
> picking the wrong algorithm mode would compromise the key or the 
> expected level of protection.

Correct.

> My understanding of this is that X.9 goes far beyond that.

How?  The X9 (and RFC 4055 syntax) provide an optional method to say, in a 
certificate, what "mode" of algorithm one would like one's certificate to 
be used with.

        -- Dan

---

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 1 Sep 2006 17:02:15 +0100

> My understanding of this is that X.9 goes far beyond that. 

How?  The X9 (and RFC 4055 syntax) provide an optional method to say, in
a certificate, what "mode" of algorithm one would like one's certificate
to be used with. 

That is the problem. It messes with deployed software architecture
created around PKI.

Currently many deployments are not designed to use this information to
do anything more than to parse the keying material.

It may cause a lot of pain to change that principle. It is not just
about parsing this data in the certificate; it is even more about
modifying APIs to allow this information to be passed on to applications
(who rely on crypto libraries for certificate processing).

It had been a lot easier if such information, if necessary, was obtained
from an extension without messing with the key field.

Stefan Santesson

Senior Program Manager

From: Daniel Brown [mailto:[email-masked]] 
Sent: den 1 september 2006 16:04
To: Stefan Santesson
Cc: Russ Housley; [email-masked]; Waterhouse, Richard; Robert
Zuccherato
Subject: RE: Elliptic Curve Cryptography with PKIX

parameters. 

PKIX defined new identifiers in RFC 4055 with parameters restricting the
use of a key.  The X9.62 syntax merely does the same thing, with the
only difference being that the parameters carry more of the information
than in RFC 4055 (I had thought that this was the only sticking point,
but apparently there's a much larger issue). 

>   
> The only reason I've seen so far why you may need to define 

Correct. 

> My understanding of this is that X.9 goes far beyond that. 

How?  The X9 (and RFC 4055 syntax) provide an optional method to say, in
a certificate, what "mode" of algorithm one would like one's certificate
to be used with. 

        -- Dan

---

From: Daniel Brown <[email-masked]>
Date: Fri, 1 Sep 2006 13:22:17 -0400

Stefan Santesson wrote on 09/01/2006 12:02:15 PM:

> > How?  The X9 (and RFC 4055 syntax) provide an optional method to 
> > say, in a certificate, what "mode" of algorithm one would like one's
> > certificate to be used with. 

> Currently many deployments are not designed to use this information 
> to do anything more than to parse the keying material.

Then these deployments do not conform with 4055.  Maybe I am missing 
something.

> modifying APIs to allow this information to be passed on to 
> applications (who rely on crypto libraries for certificate processing).

Entities that wish to restrict to a particular algorithm (mode) need a 
mechanism to communicate this.  Any way you cut it, to do this is painful 
to APIs, as far as I can tell.  A cert seems the most logical place to 
communicate the restrictions, but this requires the cert processing to 
pass additional info to the lower crypto libraries, and perhaps vice 
versa.

The effectiveness of restrictions depends on libraries who do not 
understand them (and therefore cannot follow them), to be unable to 
process them, i.e. backwards interop is bad if one wants restrictions. 
This is like a critical extension.

> 
> It had been a lot easier if such information, if necessary, was 
> obtained from an extension without messing with the key field.
> 

Why would be it much easier?  I can only see this: if restrictions were 
instead put in a critical extension, then existing implementations would, 
instead of reporting an unrecognized algorithm key type, could more 
intelligently report an unrecognized critical extension.

For what it's worth, the old X9.62-1998 (ECDSA), current X9.63-2001 (ECDH 
etc), and SEC1 v1.0 syntaxes allowed algorithm restrictions by placing the 
corresponding OIDs in the "extended key usage" (extension).  I was told 
that this use of extended key usage was inappropriate, so I suggested that 
X9 follow the method of RFC 4055 (with what I viewed as only very minor 
variations).

-- Dan