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

[Anders Rundgren <[e-mail]>]

I guess the same issues belong to signature standards like JWS?
https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-signature/

More stuff to consider includes the NUMS (Nothing Up My Sleeve) curves from Microsoft:
http://research.microsoft.com/en-us/projects/nums/

Anders

On 2014-08-18 10:55, Johannes Merkle wrote:
> 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
>