See in line comments
Jim From: COSE [mailto:[email protected]] On Behalf Of Laurence Lundblade Sent: Thursday, June 15, 2017 12:58 PM To: cose <[email protected]> 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 here <https://www.iana.org/assignments/cose/cose.xhtml#algorithms> . 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. 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 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). Thanks! LL
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
