RE: Double-checking with NUMS and Curve 25519 [was Re: Elliptic Curve Extensibility - your view is expected]

My analysis inlined below...

> From: Mark Watson [mailto:watsonm@netflix.com]
> Sent: jeudi 16 octobre 2014 00:52
> To: public-webcrypto@w3.org
> Subject: Elliptic Curve Extensibility
> 
> All,
> 
> According to the status on Bug 25618, I am working on proposed revisions to specify extensibility for import / export more explicitly in terms of the enum / string / OID values specified in the main spec, extension specs or unrecognized (as per Richard's generic proposal).
> 
> So, it would not be possible for extension specifications to completely override the import / export procedures as per my original proposal.
> 
> In the case of elliptic curves, this has some consequences. I would like to know if the group is ok with these:
> 
> (1) For SPKI and PKCS8 import / export the curve must be identified 
> entirely and only by the namedCurve choice of the parameters field of 
> the algorithm field of algorithm field of the SPKI

This should be OK -- in practice namedCurve is the only way curves are being identified in protocols in use and the only choice allowed by RFC 5480, and anyone can create their own namedCurve OIDs once they have an OID arc assigned to them.  

> (2) for SPKI import, the EC public key can be identified by the "conversion steps defined in Section 2.2 of RFC 5480"

This works fine for curves that send (x,y) coordinates on the wire, either compressed or uncompressed, but would not work for those wanting to send x-coordinates only (as was the original proposal with the Curve25519 D-H function).  Wire formats have been declared out of scope in CFRG (they will be discussed in individual IETF protocol WGs), and since with point compression there is no savings over sending just the x coordinate (because the y value is encoded into the leading type byte of the OCTET STRING) I wouldn't make any changes to (2).

> (3) for PKCS8 import, the EC private key can be identified by the "conversion steps defined in Section 3 of RFC 5915"

This should be fine.

> (4) for JWK import, the EC public key can be identified by "interpreting jwk according to Section 6.2.2 of JSON Web Algorithms"

I think you have 6.2.2 and 6.2.1 swapped here and in (5) -- in https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-34 Section 6.2.1 is the public key section and 6.2.2. is the private key section.    Additionally, because 6.2.1 specifies that the public key must be sent as an uncompressed (x,y), this will have the same problem as (2) for those wishing to use Montgomery coordinates (no impact on any of the NUMS curves).

> (5) for JWK import, the EC private key can be identified by "interpreting jwk according to Section 6.2.1 of JSON Web Algorithms"

As above, I think this is meant to reference Section 6.2.2 but otherwise is OK.

> (6) for SPKI export, the EC public key has a defined representation as 
> an octet string

Yes.  You might want to say further that the format has to be compatible with RFC 5480 Section 2.2 (since you're requiring that on import) -- I think it's a good idea to be able to round-trip acceptable values.

> (7) for PKCS8 export, the key has a defined representation as "an instance of the ECPrivateKey structure defined in Section 3 of RFC 5915"

This matches (3) and should be fine.

> (8) for JWK export, the EC public key has a representation as "x" and 
> "y" values according to Sections 6.2.1.2 and 6.1.2.3 of JWA, 
> respectively and the EC private key has a representation as a "d" 
> value according to 6.2.2.1 of JWA

These references are correct for (x,y) coordinates on the wire -- those wishing to do Montgomery x-only would need to do something different.

> If any of these things are not true for some potential future named curve then the curve could only be added to the existing ECDSA and ECDH algorithms if the key format concerned is not supported. Otherwise, the curve would have to be added as a new algorithm instead.

Based on my analysis above I think what you have is fine.  It works for all of the NUMS curves as is.

> Alternatively, we can punt much more of the definition of EC import / export for "extension" values of namedCurve to the extension specifications, but this involves a much bigger text change.

Let's not do that -- folks wishing to use x-only coordinates can put that in their own spec, but for all of us using (x,y) the text should remain in the main spec.  With what you've proposed, I can use the NUMS curves in this spec solely by defining the namedCurve OIDs for each of the them, and that's exactly the type of extensibility we want.

Thanks,

--bal

-----Original Message-----
From: Harry Halpin [mailto:hhalpin@w3.org] 
Sent: Thursday, October 16, 2014 10:26 AM
To: public-webcrypto@w3.org; Brian LaMacchia
Subject: Double-checking with NUMS and Curve 25519 [was Re: Elliptic Curve Extensibility - your view is expected]

Trevor and BAL,

Given this may influence Curve 25519 and NUMS, could you give Mark's proposal a careful review so we know that we can go forward with this more limited form of curve extensibility?

If you could do so before our next meeting on Monday, that would be ideal, although it is short notice.


   yours,
       harry


On 10/16/2014 05:30 PM, GALINDO Virginie wrote:
> Dear all,
> Thanks helping the editors by making sure you agree with his proposal… 
> Regards, Virginie
> 
> From: Mark Watson [mailto:watsonm@netflix.com]
> Sent: jeudi 16 octobre 2014 00:52
> To: public-webcrypto@w3.org
> Subject: Elliptic Curve Extensibility
> 
> All,
> 
> According to the status on Bug 25618, I am working on proposed revisions to specify extensibility for import / export more explicitly in terms of the enum / string / OID values specified in the main spec, extension specs or unrecognized (as per Richard's generic proposal).
> 
> So, it would not be possible for extension specifications to completely override the import / export procedures as per my original proposal.
> 
> In the case of elliptic curves, this has some consequences. I would like to know if the group is ok with these:
> 
> (1) For SPKI and PKCS8 import / export the curve must be identified 
> entirely and only by the namedCurve choice of the parameters field of 
> the algorithm field of algorithm field of the SPKI
> (2) for SPKI import, the EC public key can be identified by the "conversion steps defined in Section 2.2 of RFC 5480"
> (3) for PKCS8 import, the EC private key can be identified by the "conversion steps defined in Section 3 of RFC 5915"
> (4) for JWK import, the EC public key can be identified by "interpreting jwk according to Section 6.2.2 of JSON Web Algorithms"
> (5) for JWK import, the EC private key can be identified by "interpreting jwk according to Section 6.2.1 of JSON Web Algorithms"
> (6) for SPKI export, the EC public key has a defined representation as 
> an octet string
> (7) for PKCS8 export, the key has a defined representation as "an instance of the ECPrivateKey structure defined in Section 3 of RFC 5915"
> (8) for JWK export, the EC public key has a representation as "x" and 
> "y" values according to Sections 6.2.1.2 and 6.1.2.3 of JWA, 
> respectively and the EC private key has a representatopm as a "d" 
> value according to 6.2.2.1 of JWA
> 
> If any of these things are not true for some potential future named curve then the curve could only be added to the existing ECDSA and ECDH algorithms if the key format concerned is not supported. Otherwise, the curve would have to be added as a new algorithm instead.
> 
> Alternatively, we can punt much more of the definition of EC import / export for "extension" values of namedCurve to the extension specifications, but this involves a much bigger text change.
> 
> Please let me know your opinions.
> 
> ...Mark
> 
> 
> ________________________________
> This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
> Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.
>

Received on Friday, 17 October 2014 18:11:37 UTC