cose-wg / cose-spec Goto Github PK

Carsten has suggested that we could eliminate the need for the COSE_MSG structure if we were to get tags assigned from CBOR for these structures.

Should this be done?

Should there be two different versions of epk? One for JSON versions of the ephemeral key and one for CBOR versions of the ephemeral key?

Do we need to have compression as one of the ways to manipulate data?

If we have compression, is it separate or combined into the current objects?

Each algorithm should have a sentence specifying where the authentication tag is to be placed. This needs to be algorithm dependent because of algorithms like SIV which do not really have one.

In Section 13.2. there is the following text: "This key structure contains only private key information, care must be taken that it is never transmitted accidentally. For public keys, there are no required fields. For private keys, it is REQUIRED that 'k' be present in the structure."

This should probably read something like this:
"This key structure only contains secret (or symmetric) key information, care must be taken that it is never transmitted accidentally. For symmetric keys, it is REQUIRED that 'k' be present in the structure."

The trend in things to is to move to a fixed sized authentication tag for a given algorithm and to encode that tag as part of the encryption stream. Since a number of the algorithms that we are using don't have a separate authentication tag value, we should change from JOSE to use this model rather than having empty tag array members for a large number of the encryption structures. Expected savings in space is 1 byte for the content plus 1 byte for every recipient.

Carsten has an interesting idea in his COSE document. He says to build an array of the items to be concatenated together and then CBOR encode them before running it into the hashing/MAC function.

This would make things easier to explain as it them makes sense to just copy the elements that are going to be transported into the array and encode the array. This makes it easier than saying bstr encode this and tstr encode that and so forth.

Comments?

Section 3.10 of RFC 7049 has good text in it about avoiding potential decoding errors. Specifically things like duplicate keys in maps. Does this need to be a general requirement on the use of CBOR decoders?

It may be better to use the CBOR tag 24 rather than a bstr wrapper for the protected attributes field. The major question that needs to be addressed is how this is treated by existing parsers - will they try and decode it anyway or will the wait to decode them later.

It is going to be required that they are both decode later and immutable to changes if they run through an intermediary which will decode, modify and re-encode any of the top level information.

I don't believe that there is any benefits to using this rather than bstr for the payload field on signatures and macs since they could be any data type inside rather than a fixed one.

JOSE now allows for a single recipient to be encoded at the same level as the content. While COSE does not allow for quite the same way of encoding this it would be possible to do something similar.

Current syntax is "recipients : COSE_encrypt_a* | null;" This can be changed to "recipients : COSE_encrypt | COSE_encrypt_a* | null;" Do so would allow for a single recipient to be appended to the end of the current array of values rather than creating two array sub-encodings in CBOR. This encoding saves 2 bytes in the event of a single recipient at the expense of needing to pass in an offset in the array structure when parsing it.

Not really that hard to do from a programmers point of view.

It is possible that we can do some size reductions by changing the string "alg" to the integer 1. There are 23 possible values that can be used for a one byte encoding in this manner

the current KDF text about how to build the string to be hashed is a complete mess for JOSE.

It would be much simpler to define a CBOR structure to hold the individual fields, encode that structure and then hash it.

Hi,
I can find the difference between COSE_Sign and COSE_Sign1. But don't know what is COSE_Sign0.
Thanks.
Best.

We have the ability to have protected attributes for a key wrap of a CEK. The current JOSE documents do not allow for this possibility as encoding it in the JOSE structures would have been painful while for COSE it just falls out. Do we want to extend the definition of AES-GCM KW to allow for having authenticated attributes, or alternatively allow for the the generic AES-GCM algorithm to be used as the key wrap algorithm. There is currently no way to support this option for the generic AES key wrap function or for key transport using RSA. (If RSA-KEM were defined this would be a different story).

It is a given that v1.5 encryption has to be deprecated as it is a security mess.

Should we also deprecate v1.5 signature operations?

At this point, I do not know of any actual security problems with v1.5 signature operations. PSS has a better security proof than v1.5 does but that is the only real difference that I know of.

Currently not a good header for that bullet

Some authenticated data will be carried in the message, however other authenticated data will be carried in other locations. For example the concept of needing to either sign or authenticate header information that is not being carried in the security structure but is instead being carried in the headers.

We currently do not have this concept and need to add it in order to deal with CoAP issues.

We need to define these new fields for encoding easier in COSE. What do we say about these fields for JOSE if anything.

Should the kid attribute be a binary value rather than a string value?

Should we attempt to add the MAC_verify and MAC_create elements to the key_ops field since we have decided to distinguish between a signature and a MAC - or do we keep the same signature/verify tags that are currently used in the JWK document?