Subject: RE: Elliptic Curve Cryptography with PKIX

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 1 Sep 2006 07:54:29 -0700

If people want to do that type of thing the mechanism defined for the purpose is an extension with the criticality bit set.

There is no penalty in this particular case.

Sent from my GoodLink Wireless Handheld (www.good.com)

 -----Original Message-----
From: 	Stefan Santesson [mailto:[email-masked]]
Sent:	Friday, September 01, 2006 07:17 AM Pacific Standard Time
To:	Waterhouse, Richard; Russ Housley; Robert Zuccherato
Cc:	Daniel Brown; [email-masked]
Subject:	RE: Elliptic Curve Cryptography with PKIX

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 
	>