> 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”. > 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. > 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. > 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. Grüße, Carsten _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
