Hi Carsten, > On Jul 10, 2021, at 12:02 AM, Carsten Bormann <[email protected]> wrote: > > >> On 2021-07-10, at 05:44, Laurence Lundblade <[email protected]> wrote: >> >> Hi, Laurence here causing trouble again... >> >> I’m looking to add a claim in EAT that is a digest — a hash algorithm >> identifier and the hash value. > > What is that claim asserting? > If I make the claim “3” that is not a very good claim. > If I make the claim “this device needs to be allowed a sustained > communication bit rate of 3 bit/s to operate”, this is a much better claim. > >> draft-ietf-cose-hash-algs-09 defines: >> >> COSE_Hash_Find = [ >> hashAlg : int / tstr, >> hashValue : bstr >> ] > > This is the “3”.
Not sure I’m receiving the point you are trying to make here with “3”. We’ve defined COSE_Sign and COSE_Mac to carry payloads that are unspecified by COSE. People can do dumb things and good things in with what is defined today. Seems like COSE_Digest would be pretty much the same. Note also that the name “COSE_Hash_Find” does not really line up with the actual uses in EAT, SUIT or CoSWID. And it is of course incumbent on EAT to define what the digest is of, just like SUIT and CoSWID defined what the object of their digests. >> This is pretty much what is needed, but the name of it is odd and the text >> suggests it should only use this for searching for things, which is not the >> purpose. >> >> draft-ietf-cose-hash-algs-09 also “mentions": >> >> COSE_Hash_V = ( >> 1 : int / tstr, # Algorithm identifier >> 2 : bstr, # Hash value >> ? 3 : tstr, # Location of object that was hashed >> ? 4 : any # object containing other details and things >> ) > > Entries 3 and 4 complement (or, can complement in a specific context — that’s > why this is an example) the “3” to a meaningful claim. SUIT, CoSWID and EAT just need the simple pair of algorithm ID and hash value. Seems like the pair is enough to be of value to me without the extra data item for location. In all three the identification of the object of the hash is in the surrounding structure, not in the digest structure. >> But this is just an example, not an actual normative standard definition >> according to the text, so I don’t think it is right to use it in a standards >> track document. > > Of course you can use examples for building your standard-track document. My hope is to add support for a standard like COSE_Digest to my COSE library so it maybe can end up as code shared by CoSWID, SUIT and EAT. If it is a standard, then it get used more as is and more libraries may support it as is. Also, if COSE_SIgn1 where just an example, I don’t think it would be the same as what we have now. >> Also that CoSWID has a CBOR structure like this, but uses the Named >> Information Hash Algorithm Registry, not COSE algorithm identifiers. > > RFC 6920 has been around for a while and so was the go-to registry before > cose-hash-algs defined its own. > >> And, SUIT laments that COSE doesn’t have this and defines its own with a >> different non-COSE numbering scheme for identifying hash algorithms. > > To be fixed with cose-hash-algs. Is there a PR I can look at yet so I can see what to do in EAT? LL _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
