Subject: [COSE] COSE messages with kid in layer-1

From: Brian Sipos <[email-masked]>
Date: Mon, 28 Dec 2020 23:12:57 +0000

All,
In the examples of RFC 8152 [1] the COSE_Mac0 and COSE_Encrypt0 examples don't include a key identifier ("kid" parameter) in the top-level unprotected headers, and there is no example of COSE_Sign1 message. The informative text implies that there should not be a kid parameter, but I don't see this in any normative statement of RFC 8152 or in the errata [2]. I also don't see any difference in the upcoming 8152bis document [3].

I thought that the algorithm itself determined which protected/unprotected headers were acceptable within a particular layer, while the message type determined the top-level structure and whether there are sub-layers.

Is there a fundamental reason why the single-signer example (from C.1.1) of:

   98(
     [
       / protected / h'',
       / unprotected / {},
       / payload / 'This is the content.',
       / signatures / [
         [
           / protected h'a10126' / << {
               / alg / 1:-7 / ECDSA 256 /
             } >>,
           / unprotected / {
             / kid / 4:'11'
           },
           / signature / h'...'
         ]
       ]
     ]
   )

could not be rewritten as a COSE_Sign1 message of:

   18(
     [
       / protected h'a10126' / << {
           / alg / 1:-7 / ECDSA 256 /
         } >>,
       / unprotected / {
         / kid / 4:'11'
       },
       / payload / 'This is the content.',
       / signature / h'...'
     ]
   )

I thought that the point of the COSE_Mac0, COSE_Sign1, COSE_Encrypt0 messages were just to reduce the framing overhead of allowing multiple signatures.

Thanks for any clarification,
Brian S.

[1] https://tools.ietf.org/html/rfc8152#appendix-C
[2] https://www.rfc-editor.org/errata_search.php?rfc=8152
[3] https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis-struct-14

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 29 Dec 2020 10:45:40 -0800

Hi Brian,

Looks to me like there is an example of COSE_Sign1 that is pretty much identical to what you’ve requested below in C.2.1. 

My understanding is that the kid can as needed in any of the COSE message types. It is usually unprotected, but I don’t see any requirement that precludes it from being protected (and section 6 of RFC 7515, JSON Web Signature, suggests the kid should be protected at times).

I would say it is the key identification scheme that determines which headers are used and which are protected. The key identification scheme varies from one COSE use case to another.

LL

> On Dec 28, 2020, at 3:12 PM, Brian Sipos <[email-masked]> wrote:
> 
> All,
> [1] https://tools.ietf.org/html/rfc8152#appendix-C <https://tools.ietf.org/html/rfc8152#appendix-C>
> [2] https://www.rfc-editor.org/errata_search.php?rfc=8152 <https://www.rfc-editor.org/errata_search.php?rfc=8152>
> [3] https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis-struct-14 <https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis-struct-14>
> 
> _______________________________________________
> COSE mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/cose <https://www.ietf.org/mailman/listinfo/cose>