Re: [pkix] Edwards/DJB curves - New PKI(X) work?

[Michael StJohns <[e-mail]>]

At 03:38 AM 8/15/2014, Johannes Merkle wrote:
>The usage of ECDSA-SHA256 within PKIX is already fully specified in RFC 5758. The curve (more specifically, the elliptic
>curve parameters) are a property of the public key not of the digital signature, DH value or cipher text.
>In order to use other curves, you just need to replace the OID for the named curve which is a parameter of the
>SubjectPublicKeyInfo according to RFC 5480.


If I had to make a guess as to whether this is correct or not I'd say that it mostly isn't.  Starting with PKIX public key representation, the OID for the AlgorithmIdentifier.algorithm type idEcPublicKey specifies how the public key is formatted; the curve OID (included in the parameters field) merely describes the curve parameters by reference.   (Section 2.2 of RFC5480 - but other places as well).  So you can't really reuse that algorithm type identifier.

Then there's the actual verification process.  The code I use for example looks first at the SignatureAlgorithm field of a certificate.  When it sees "SHA256withECDSA",  it instantiates a Signature object of that specific type *before* grabbing the appropriate public key to initialize the verification operation.   In other words, I'm stuck with  FIPS186-3 compliant signature function trying to parse a DJB curve key.

Basically, while you're correct that the key  curve is going to determine how you verify the signature, I would be surprised if any code checks the key curve first as the current understanding is that ECDSA means SECG1/X9.62/NISP FIPS186-3 (which are basically the same math and representations).  

For PKIX at least for signatures you need:

1) An ASN1 public key representation (and the appropriate OID).  Since there's only one DJB curve(?is that correct or are two needed for signature and ecdh?), you could get away with just a new OID for AlgorithmIdentifier.algorithm.
2) The format of the bitstring that represents a signature 
3) One or more signature algorithms (e.g. SHA256withX, SomeOtherHashWithX, etc) and their OIDs.

I think that any attempt to use the current set of EC code points  for DJB curve data is going to lead to really bad interactions with existing code (included but not limited to PKIX, TLS and IPSEC).  Better to assign new code points where necessary.

Later, Mike