Re: [COSE] A couple of COSE questions

[Jim Schaad <[e-mail]>]

No id assignment for the algorithms yet because the draft has not gone to IANA.

 

Jim

 

 

From: Laurence Lundblade [mailto:[e-mail]] 
Sent: Thursday, June 15, 2017 2:14 PM
To: Jim Schaad <[e-mail]>
Cc: cose <[e-mail]>
Subject: Re: [COSE] A couple of COSE questions

 

Thank you Jim,

 

A few comments below.

 

 

On Jun 15, 2017, at 2:01 PM, Jim Schaad <[e-mail] <mailto:[e-mail]> > wrote:

 

See in line comments

 

Jim

 

 

From: COSE [ <mailto:[e-mail]> mailto:[e-mail]] On Behalf Of Laurence Lundblade
Sent: Thursday, June 15, 2017 12:58 PM
To: cose < <mailto:[e-mail]> [e-mail]>
Subject: [COSE] A couple of COSE questions

 

Hello I have a few questions… 

 

Registration of hash algs

There’s no assignments for hash algs (SHA-256.. SHA-512, SHA3-256…) in the IANA registry  <https://www.iana.org/assignments/cose/cose.xhtml#algorithms> here. I assume this is because the COSE protocol doesn’t have a need because they are bundled up with the signing alg identifiers.  For non-COSE protocols that use CBOR and do have a need to identify a hash, would it be reasonable to add them?  The COSE registry seems like it is the place to register algorithm IDs for use in CBOR in general.  I assume the process would be to write a simple RFC, publish and then add to the registry.

 

[JLS]  Yes the reason that there are no hash algorithms is that they were not needed for any of the core COSE functions.  I am in the process of registering two hash functions as part of ietf-schaad-cose-x509.  These are a SHA-256 and a truncated SHA-256.  If you want to write up a more complete RFC for this that would be fine with me.

 

SHA-256 will do for now for me.  Do you have the value for it yet?  I don’t have time for a more general write of more algs at the moment. 

 

 

 

 

Registration of tagging for COSE messages

Why isn’t there a registry section for the tags for these different COSE messages? 

   COSE_Tagged_Message = COSE_Sign_Tagged / COSE_Sign1_Tagged /
       COSE_Encrypt_Tagged / COSE_Encrypt0_Tagged /
       COSE_Mac_Tagged / COSE_Mac0_Tagged

 

[JLS] Not too sure what registry you are looking for here.  But I think you want this registry  <https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml#tags> https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml#tags

 

That’s what I was looking for. 

 





 

Tagging of bstr wrapped data

It seems like it would be helpful to use an option tag on the bstr-wrapped payload for COSE_Sign and such to tell general purpose parsers and translators to remove the bstr wrapping and keep going. Tag 55799 seems like the best fit so far, but it may not be a perfect fit and it would be nice to use a tag less than 24.   

 

[JLS]  I am not sure that you would find this generically helpful.  The problem is that the parser needs to provide both the encoded version and the unencoded version if you are going to do an automatic recursion of the CBOR decoder.  You need the first in order to do the signature validation processing.  This means that there does not seem to be a real point to making the recursion occur automatically that I can see.  We have not provided all of the cues that would be needed to do a stream decode and validation at the same process ala how CMS does it (and even then there are cases where you need to go back and restart the process again).

 

I figured the answer would be along these lines. 

 

To be more clear on the use case, it seems you could have a small chunk of SW that just does signature verification, that doesn’t really understand the details of the payload.  Its output is a yes or no.   Then you use a general purpose off-the-shelf CBOR-to-JSON translator on the payload.  It only runs if the sig verification passed. 

 

LL