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

[Johannes Merkle <[e-mail]>]

Michael StJohns wrote on 17.08.2014 05:16:
> 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).  
> 


You are right, I was imprecise. As I wrote in my previous message:

  Even if
  Montgomery curves or Edwards curves are chosen, there is still the option of using traditional (Weierstrass)
  representation / semantic on-the-wire, as transformation is quite simple. See
  https://www.ietf.org/mail-archive/web/cfrg/current/msg04816.html

My statement above (that using a new curve only requires a curve OID) only referred to the case that the representation
of the EC points don't change. In the alternative case, you are right: if we want to use new EC point semantics, new
specs for X.509 certs / CRLs, for CMS etc. would be needed.

> 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 disagree with 2) though: In all Schnorr-like signatures, the signature consists of two integers, not (EC) group
elements. Thus, the EC point semantic has no influence on the signature encoding. It only has impact on the signature
generation and verification algorithms (e.g. defined in ANSI X9.62 and FIPS 186-4), but these are out of the scope of PKIX.

Of course, if new signature algorithms are introduced in PKIX (3), this implies that new semantics of signature values (2).

Johannes