Subject: [COSE] draft -04 published

From: "Jim Schaad" <[email-masked]>
Date: Fri, 28 Aug 2015 15:20:39 -0700

I have pushed up the -04 version of the message document.  This version
pulls in the change to using arrays at the top level, changes to algorithm
sections and the reviews that we have received.

Jim

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 29 Aug 2015 10:16:32 +0300

> sections and the reviews that we have received.

Oh, regarding issue #3, TLS does not truncate the zeroes for ECDH
("leading zeros found in this octet string MUST NOT be truncated."),
maybe you were thinking about DH, where leading string truncation does
happen?

Now for some reviewing:

1) There is still one reference to "Key management" in section 1.5.
2) There have been many vulernabilies in JOSE implementations due to
   implementations using cryptographic keys with wrong algorithms (e.g.
   RSA public key as MAC key). And it looks like the document doesn't
   say anything about these types of problems (e.g. by requiring to
   check that alg of message is consistent with kty of key).
3) Regarding questionable header parameters:
   - URL-type things: jku and x5u... URL retretival has nontrivial
     security concerns.
   - X509-type things: x5c, x5t, x5t#SHA256, x5u: These assume X.509,
     which is complicated to the point that even full-powered systems
     have problems implementing it.
   - jwk: Apparently this header is used with JOSE, so I would imagine
     equivalent usecases do apply here too.
   - zip: Constrained systems probably don't appreciate compression,
     but it could be nice in full-powered systems.
4) The prose descriptions of structures don't seem to say what order
   the fields are in (looks to be order listed).
5) What does it mean to omit the ciphertext field in encryption
   structure (how is that encoded)? Also, looks like other messages
   allow omitting payload?
6) The ECDSA section should explicitly suggest P-256/P-384/P-521
   instead of arbitrary-looking curves of given bitlength.
7) ECDSA with Curve25519? I'm getting bad flashbacks... :-)
8) The CDDL description in section 11.2 looks to use arrays, yet
   there is table of labels?
9) Looks like latest cfrg-curves renames Curve25519 and Curve448
   to X25519 and X448 (and the document is in RGLC).

-Ilari

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 29 Aug 2015 11:22:24 -0700

> -----Original Message-----
> From: Ilari Liusvaara [mailto:[email-masked]]
> Sent: Saturday, August 29, 2015 12:17 AM
> To: Jim Schaad <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [COSE] draft -04 published
> 
> > I have pushed up the -04 version of the message document.  This
> > version pulls in the change to using arrays at the top level, changes
> > to algorithm sections and the reviews that we have received.
> 
> Oh, regarding issue #3, TLS does not truncate the zeroes for ECDH ("leading
> zeros found in this octet string MUST NOT be truncated."), maybe you were
> thinking about DH, where leading string truncation does happen?

Ah - I had not recently read the section on ECDH for TLS. Yes I was thinking about DH when I created the issue.  I know of the issue because I have needed to deal with both of the encodings at different times.  I was not sure what TLS did for the NIST curves.  I was sure that for the new CFRG curves that leading zeros were not going to be stripped because of the little endian encoding.  Thanks for the correction.

> 1) There is still one reference to "Key management" in section 1.5.
I see this and will look at it.

>    check that alg of message is consistent with kty of key).

Issue is in the document and I will look for a good place to put text.
How do you feel about requiring the algorithm field to be present in keys since also helps to makes sure that keys are not mis-used.

>      but it could be nice in full-powered systems.

Brian is currently working on these issues and should respond.

>    the fields are in (looks to be order listed).

I will put this into the document.  Since we can't use CDDL as normative this does need to be stated.

>    structure (how is that encoded)? Also, looks like other messages

Yes, I missed this when I move from maps back to arrays.  The correct answer is that the type becomes (bstr or null) for the content fields.

>    instead of arbitrary-looking curves of given bitlength.

Yes, this should be restricted.

> 7) ECDSA with Curve25519? I'm getting bad flashbacks... :-)

I would be happy to use a different curve.  I wanted to have a concrete example so that people would understand what I was trying to say.  I have had problems describing this type of problem in the past because people just could not understand what I was trying to say.  Could you suggest something?

>    there is table of labels?

Yes this is correct.  The fields are placed in the protected and unprotected maps for transportation and then encoded into the context structure for doing the KDF.    I will look to see if I missed something here.

>    to X25519 and X448 (and the document is in RGLC).

Missed that change.

Thanks for doing a review of the document.

Jim

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 29 Aug 2015 22:24:21 +0300

On Sat, Aug 29, 2015 at 11:22:24AM -0700, Jim Schaad wrote:
> I would be happy to use a different curve.  I wanted to have a
> concrete example so that people would understand what I was
> trying to say.  I have had problems describing this type of
> problem in the past because people just could not understand
> what I was trying to say.  Could you suggest something?

If you want an example of curve that is the same length as secp256r1
("NIST P-256") but different, there is secp256k1. That curve is
additionally much more likely to be used with ECDSA than Curve25519.

AFAIK, ECDSA-secp256k1 is at least used in the wild by one piece
of software, instead of being confined to proof of concept code.
:-)

> Yes this is correct.  The fields are placed in the protected and
> unprotected maps for transportation and then encoded into the context
> structure for doing the KDF.    I will look to see if I missed
> something here.

Looking at the CDDL (because the text doesn't say what types the
composites are), PartyUInfo, PartyVInfo and SuppPubInfo look to be
arrays ([]), not maps ({}) or groups (()).

But nevertheless, those seem to have labels specified, like those
were maps (except SuppPubInfo, which doesn't). 

That those three should be maps that are octet-string wrapped would
certainly make sense assuming Cocat KDF takes in those kinds of
parameters as octet strings.

-Ilari

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 29 Aug 2015 13:12:05 -0700

> Sent: Saturday, August 29, 2015 12:24 PM
> > > > version pulls in the change to using arrays at the top level,
> > > > changes to algorithm sections and the reviews that we have received.
> >
> > >
> > >
> > > Now for some reviewing:
> >
> > How do you feel about requiring the algorithm field to be present in keys since
> also helps to makes sure that keys are not mis-used.
> >
> > concrete example so that people would understand what I was trying to
> > say.  I have had problems describing this type of problem in the past
> > because people just could not understand what I was trying to say.
> > Could you suggest something?
> 
> If you want an example of curve that is the same length as secp256r1 ("NIST P-
> 256") but different, there is secp256k1. That curve is additionally much more
> likely to be used with ECDSA than Curve25519.

Yes that is much better.  Thanks

> 
> AFAIK, ECDSA-secp256k1 is at least used in the wild by one piece of software,
> instead of being confined to proof of concept code.
> :-)
> 
> Looking at the CDDL (because the text doesn't say what types the composites
> are), PartyUInfo, PartyVInfo and SuppPubInfo look to be arrays ([]), not maps ({})
> or groups (()).
> 
> But nevertheless, those seem to have labels specified, like those were maps
> (except SuppPubInfo, which doesn't).
> 
> That those three should be maps that are octet-string wrapped would certainly
> make sense assuming Cocat KDF takes in those kinds of parameters as octet
> strings.

Ok - I need to have a more explicit example someplace that people can look at.

The maps that I was referring to are the protected and unprotected maps in the COSE_Sign, COSE_Encrypt, COSE_Mac, and COSE_signature.  This is distinct from the context structure.  The context structure uses arrays because it is easier to get a canonical encoding out of it than out of maps.