Subject: Re: [COSE] CFRG ECC algorithms in COSE -- design aspects

From: "Jim Schaad" <[email-masked]>
Date: Mon, 21 Dec 2015 13:27:47 -0800

> -----Original Message-----
> From: COSE [mailto:[email-masked]] On Behalf Of Ilari Liusvaara
> Sent: Sunday, November 22, 2015 9:26 PM
> To: [email-masked]
> Subject: [COSE] CFRG ECC algorithms in COSE -- design aspects
> 
> I have done a few rounds on pre-draft about CFRG ECC algorithms in JOSE on
> the jose list, and seems things are converging. Now, to porting this stuff
to
> COSE. CFRG-Curves is already in RFC-Ed.Q, but CFRG-EDDSA is unlikely to
reach
> that in time before COSE-MSG is sent to IESG (assuming you keep your
> schedule), so this stuff would likely go to an extra document[1].
> 
> 
> The important design points are:
> - A new key type "OKP" (Octet Key Pair)
> - Has paramter "crv" (don't ask why they wanted it named that) that is
>   essentially subtype of key (X25519, X448, Ed25519, Ed25519ph, Ed448,
>   Ed448ph). This is because mixing different kinds of keys is
>   dangerous.

Another possibility would be to kill the "crv" parameter and to require the
"alg" parameter to be present.   We are, for all practical purposes, going
towards saying that the algorithm and the key type are becoming synonymous.

> - Has parameter "x" (again, don't ask) that is base64-encoded public
>   key octet string.

And since we only have X - we can avoid issues of compressed formats
(yeah!!!)

> - ECDH-ES with X25519/X448 uses the respective Diffie-Hellman
>   Functions, with octet-string inputs and outputs.
> - Signatures use the signing and verification functions, with octet-
>   string inputs and outputs (except for verification, which has
>   boolean output).
> - All keys and signatures are handled are handled as octet strings with
>   no structure.
> 
> 
> Straightforward method to port most of this stuff:
> - New key type: OKP(1): Octet-string key pairs
> - Key parameters for it:
>   * crv(-1)[int/tstr]: Key subtype
>   * x(-2)[bstr]: Public key (octet string)
>   * d(-4)[bstr]: Private key (octet string)
> 
> Now, for the less trivial stuff:
> - Can one reuse the crv values 1-3 (these are used in another key
>   type ("EC2"))?

I think we can go either way on this.  If we re-use the same values then it
is a new registry and one can be happy.  If we don't re-use the same values
then we can create a registry and refer to the registry for both key types.
On the other hand, if we make alg required then we can punt this question.

> - What length of identifiers one should assign? I would think that
>   the identifiers for X25519 and Ed25519 should be from range 0-23
>   (1 byte), and others could be 24-255 (2 bytes), as Ed25519ph
>   is odd one, and the others have quite a bit larger keys and
>   signatures due to higher security level.

That would be a reasonable ask of IANA.

> - Combine all the signature algorithms under just one identifier
>   (use key subtyping to resolve what algorithm is used, removes
>   a source of security bugs)?

I am not sure that is going to remove security bugs or adds security bugs.
Once upon a time there were no problems with DSA as the key size and hash
were fixed.  Over time this has become no longer true and thus we get back
some security bugs that we would like to get rid of.  I am not really happy
with how I have specified the ECDSA algorithms in the core document due to
the fact that multiple curves can be used with a single hash size - the hash
being truncated if it is too long.  Being more hard core by making a new
algorithm for each one, and making the algorithm specify all of the details
might be a better answer.

What is the best way to talk about things - the way algorithm identifiers
are assigned for RSA-SSA v1.5 or for RSA-PSS.  In the former case the hash
algorithm is part of the identifier and a new identifier needs to be
assigned for every new hash algorithm.  The latter does not have a hash
algorithm in any part of the signed value and thus it would be possible
(although unlikely) to be able to do a hash algorithm substitution attack.

> 
> The pre-draft does talk about JWK thumbprints too (and even contains an
> example thumbprint computation). I haven't seen COSE discussing
thumbprints.

I am somewhat anti-thumbprint algorithm as I don't really believe that they
are useful.  A thumbprint is only helpful if one going to assume that two
entities can compute the same thumbprint and they have a good reason to do
so.  I would be more inclined to do something along the likes of the PKIX
key identifier where one can say - here are some different ways to compute
one, try and make them unique.

Jim

> 
> 
> [1] I realize that you do want to be a quick WG and shut down. I think
Crudle (or
> whatever the WG ends up being called) could take the work then.

Given that there is going to be a secondary algorithm draft, I don't know
that this is an issue.

> 
> 
> -Ilari
> 
> _______________________________________________
> COSE mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cose