Subject: [jose] Comments on draft-liusvaara-jose-cfrg-curves-00

From: "Jim Schaad" <[email-masked]>
Date: Tue, 22 Dec 2015 16:44:09 -0800

Here are some comments on the current draft.

* Abstract:  The abstract needs to be expanded to include the names of the
algorithms that are being included here.  (Note that references in an
abstract are not considered kosher so don't do that.)  You need to be able
to read the abstract without the rest of the document and be able to decide
if it is the correct document.

* Section 1:  Putting a reference to the new algorithms in the first
sentence would be a reasonable edit.  I would also probably at least
consider putting the set of algorithms here by name.  Think of reading the
introduction in 10 years when a new set of algorithms has been created.

* Section 1:  The IETF does not have the concept of extending documents.
Documents generally fall into the categories of a) stand alone, b) updates
an existing document, c) obsoletes and existing document.  The second
paragraph either should be removed or re-phrased.   Possibly something along
the lines of "This document defines the conventions to be used in the
context of [JWA] and [JWK]."  Although I am not sure that I even care for
that.

* Section 1.2:  I am not sure that this qualifies as being notation.  I
would probably change the title 

*  Section 2:  In response to a question that you had asked earlier on the
list, but which I did not respond to at the time.  I believe that you could
define any of the existing parameter to be a required parameter for a new
key type.  You would need to have a good justification for doing so, but it
would be possible to define 'alg' as a required parameter for the key type
'OKP'.  Having to do simple checks for things like
{"kty":"OKP","crv":"Ed25519",  "alg":"Ed25519p", "x":"...."} as being
illegal seems problematic.

* Section 2:  You have introduced the term 'subtype of the key' without
making it clear where this term is coming from.  This is not a field in the
registry as seems to be implied by the text.

* Section 2:  If you don't like the terms crv and x, perhaps you should
seriously think about using different names for these fields.  That is the
feeling I am getting from the Note in this section.

* Section 3.1.1:  For formatting I would remove the colons in the table.

* Section 3.1.1:  The table is a bit confusing given that all of the columns
have the same value.  Without a better description of the headers I don't
find it to be very useful.

* Section 3.1.1:  I think that I have a real problem with the concept of all
of the parameters of a signature algorithm being defined by the "crv" field
rather than the "alg" field.  This seems to be a real misuse of what crv
currently represents.   If you do combine things into one algorithm I would
really do some renaming of the key fields.   (See note above on use of 'alg'
instead of 'crv'.)

* Section 3.1.2 and 3.1.3:  Yes - I like the fact that there is not a full
description of the signature processing here!!!

* Section 3.2 - what is the 'alg' parameter supposed to be here?  It is not
in the table.  (See above notes on the table.)

* Section 3.2.1 - You need to specify what the KDF to be used is.  

* Section 3.2.1 - You need to specify either how the KDF uses K_A and K_B as
well as K or say why it is not needed.  This is not defined as part of the
shared secret by the CFRG document.

* Section 4 - s/information what key/information about what key/

Jim

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 23 Dec 2015 08:46:53 +0200

> if it is the correct document.

Did add the algorithm names.
 
> introduction in 10 years when a new set of algorithms has been created.

Did add the algorithm names and references.

> context of [JWA] and [JWK]."  Although I am not sure that I even care for

Changed the prhrasing to be in line with that.

> would probably change the title 

Moved it to section 1 (it is just one paragraph).

> illegal seems problematic.

OHOH, merging the things may cause problems with X25519 and X448. Since
those are used with ECDH-ES, which currently seems to be used with 4
algorithms (direct keying and 3x AES-KW with different keysizes).

OTOH, the other types have just one algorithm they work with.

> registry as seems to be implied by the text.

Since OKP is a new keytype, I thought I need to define fields for it.
Noticed that IANA considerations has a typo: It still refers to "algorithm
group" instead of "key subtype" (I changed the terminology at some point,
but that got left).

> feeling I am getting from the Note in this section.

The draft originally did use different names, but various people in the
WG wanted those to be "crv" and "x", damn what that impiles about the
meaning.
 
> * Section 3.1.1:  For formatting I would remove the colons in the table.

Removed in internal copy.

> find it to be very useful.

This is artifact of having different alg values for what is logically the
same operation with different keys.

> really do some renaming of the key fields.   (See note above on use of 'alg'

See above.

> description of the signature processing here!!!

I only put in what goes where. There aren't a lot of values invovled.

> in the table.  (See above notes on the table.)

AFAICT: "enc", "ECDH-ES+A128KW", "ECDH-ES+A192KW" or "ECDH-ES+A256KW"
(which are the ECDH-ES -type things).

> * Section 3.2.1 - You need to specify what the KDF to be used is.  

Standard ECDH-ES KDF processing from JWA. I added a reference to JWA
section 4.6.2 in internal copy.

> * Section 4 - s/information what key/information about what key/

Fixed on internal copy.

-Ilari

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 23 Dec 2015 08:14:59 +0100

> WG wanted those to be "crv" and "x", damn what that impiles about the

Just for my (some primitive) understanding: The targeted algorithms do not
represent curves of some kind?  If not why calling the draft *-curves-*?

Anders

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 24 Dec 2015 07:46:43 +0200

On Wed, Dec 23, 2015 at 08:14:59AM +0100, Anders Rundgren wrote:
> represent curves of some kind?  

None of Ed25519, Ed25519ph, Ed448, Ed448ph, X25519 and X448 is a curve,
those all are diffie-hellman algorithms or signature algorithms.

> If not why calling the draft *-curves-*?

Those algorithms are the pracical applications of the CFRG ECC work
to JOSE (the direct curves don't have much use[1])

[1] I do know only one spec (HTTP auth type) that could use the raw
curves themselves.

-Ilari

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Thu, 24 Dec 2015 12:53:42 +0200

Hi Ilari,

Thank you for making this new contribution to the JOSE suite.

The Java library for JOSE that I maintain includes methods for
converting between JWK instances and the standard Java types for
representing keys. My reading of the spec is that the established Java
DHPublicKey
<https://docs.oracle.com/javase/7/docs/api/javax/crypto/interfaces/DHPublicKey.html>
/ DHPrivateKey
<https://docs.oracle.com/javase/7/docs/api/javax/crypto/interfaces/DHPrivateKey.html>
interfaces would be the best match for the proposed "OKP" JWK. Does this
make sense?

The current JWK types map as follows:

  * "OCT" JWKs map to / from javax.crypto.SecretKey

  * "RSA" JWKs map to / from java.security.interfaces.RSA{Public|Private}Key

  * "EC" JWKs map to / from java.security.interfaces.EC{Public|Private}Key

Can you recommend Java implementations of the new algs? I'm looking for
a good place to start in order to add support for them in JOSE.

Thanks,

Vladimir

-- 
Vladimir Dzhuvinov

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 24 Dec 2015 13:48:09 +0100

On 2015-12-24 11:53, Vladimir Dzhuvinov wrote:
> The Java library for JOSE that I maintain includes methods for converting
 > between JWK instances and the standard Java types for representing keys.
 > My reading of the spec is that the established Java DHPublicKey
 > <https://docs.oracle.com/javase/7/docs/api/javax/crypto/interfaces/DHPublicKey.html> /
 > DHPrivateKey <https://docs.oracle.com/javase/7/docs/api/javax/crypto/interfaces/DHPrivateKey.html>
 > interfaces would be the best match for the proposed "OKP" JWK. Does this make sense?

Hi Vladimir,

Is your goal to eventually make this a part of standard java?
I would be interested in cooperating on a OpenJDK contribution.

Regardless of that my experiences with named EC curves in Java
(without BouncyCastle installed) would speak against reusing DH*
since there is no place for "crv" (or whatever it will be called...)
and "x" is called Y.

https://docs.oracle.com/javase/7/docs/api/javax/crypto/spec/DHPublicKeySpec.html

I would therefore consider starting with a new key type (OKP*).

If something "standard-ish" is the target, I would try to get some
feedback on an early proposal.

Regards,
Anders

> Can you recommend Java implementations of the new algs? I'm looking for a good place to start in order to add support for them in JOSE.
>
> Thanks,
>
> Vladimir
>
> --
> Vladimir Dzhuvinov
>
>
>
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose
>

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Thu, 24 Dec 2015 16:37:44 +0200

On 24/12/15 14:48, Anders Rundgren wrote:
>> converting
> /
> > DHPrivateKey
For now I just want to figure out how these algs can be implemented in
Java, and if it's possible to do that in a way that fits established
interfaces, frameworks and conventions. The representation of the keys
is one aspect of that.

Making this part of standard Java is a serious commitment. I'm not ready
and qualified to go that far :) I'm not familiar with the standard
making process either.

> I would therefore consider starting with a new key type (OKP*).

How would you name this? In Java, as opposed to JWK, the public and
private parts are represented separately. "octet" qualifies the
encoding, and because of this I'm not sure it should be part of the
class name. EdCPublicKey / EdCPrivateKey? (EdC = Edwards-Curve)

>>   * "RSA" JWKs map to / from
>> java.security.interfaces.RSA{Public|Private}Key
>>
>>   * "EC" JWKs map to / from
>> java.security.interfaces.EC{Public|Private}Key
>>
>>
>> Can you recommend Java implementations of the new algs? I'm looking
>> for a good place to start in order to add support for them in JOSE.
>>
>> Thanks,
>>
>> Vladimir
>>
>> -- 
>> Vladimir Dzhuvinov
>>
>>
>>

-- 
Vladimir Dzhuvinov :: [email-masked]

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 24 Dec 2015 17:51:17 +0100

On 2015-12-24 15:37, Vladimir Dzhuvinov wrote:
> How would you name this?

I would name keys OKPPrivateKey and OKPPublicKey which in turn
would extend PrivateKey and PublicKey respectively as well as a new type OKPKey.

  In Java, as opposed to JWK, the public and
> encoding,

The encoding is actually quite a problem since JCE [more or less] builds
on PKCS #8 for private keys and SPKI for public keys and these are not
(yet) standardized.  Yes, the Java KeyStore won't work either until there
is a working PKCS #12 which I believe builds on PKCS #8 and X.509/SPKI.
However, using JWK you could create a public key like:

KeyFactory.getInstance("OKP").generatePublic(new OKPPublicKeySpec(curve, x));
where curve would be a String and x byte[]

Reusing DH may be possible but I think it creates more problems than it solves :-)

OTOH, the more I think of it...I wonder if it is not better simply creating
concrete classes for OKPPublicKey and OKPPrivateKey rather than interfaces and
not bother about JCE at this early stage:

OKPPublicKey publicKey = new OKPPublicKey(curve,x);

if (myKey instanceof OKPKey) {
   // run special code
} else {
   // use JCE
}

Anders

> and because of this I'm not sure it should be part of the