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

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 23 Nov 2015 07:25:30 +0200

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.
- Has parameter "x" (again, don't ask) that is base64-encoded public
  key octet string.
- 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"))?
- 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.
- Combine all the signature algorithms under just one identifier
  (use key subtyping to resolve what algorithm is used, removes
  a source of security bugs)?

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

[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.

-Ilari

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 22 Nov 2015 22:23:52 -0800

You will find some of this already defined in
http://datatracker.ietf.org/doc/draft-schaad-cose-alg/.

Jim

> -----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 pre-draft does talk about JWK thumbprints too (and even contains an
> example thumbprint computation). I haven't seen COSE discussing
thumbprints.
> 
> 
> [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.
> 
> 
> -Ilari
> 
> _______________________________________________
> COSE mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cose

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 23 Nov 2015 21:11:36 +0200

> http://datatracker.ietf.org/doc/draft-schaad-cose-alg/.

For EC1, the points are encoded in little endian... Well, for X25519
and X448, the point encoding is actually little-endian. Scalar
encoding is diferent matter. Basically, X25519 and X448 are functions
defined in terms of octet string inputs.

Then there would be Ed25519, Ed25519ph, Ed448 and Ed448ph. The public
keys of those aren't little-endian encodings of X coordinate, but
something bit more complicated. And the private keys definitely are
not scalars (again, the functions are defined in terms of octet
strings).

-Ilari