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.
draft-ietf-cose-hash-algs-09 defines:
COSE_Hash_Find = [
hashAlg : int / tstr,
hashValue : bstr
]
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
)
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.
Also that CoSWID has a CBOR structure like this, but uses the Named Information
Hash Algorithm Registry, not COSE algorithm identifiers.
And, SUIT laments that COSE doesn’t have this and defines its own with a
different non-COSE numbering scheme for identifying hash algorithms.
All of the above uses are reasonably secure because they are embedded secured
structures so the reasoning that digest shouldn’t exist because it isn’t secure
in and of itself does seem right and deprives us of something useful.
Seems to me like draft-ietf-cose-hash-algs-09 should have a solid standard
definition for a digest. My proposal would to replace COSE_Hash_Find and
COSE_Hash_V with this:
COSE_Digest = (
1 : int / tstr, # COSE Algorithm identifier
2 : bstr, # Hash value
* : $$cose-digest-extensions
)
It seems too open-ended to try to figure out a standard for location of the
object that is hashed, so I left that out.
Seems OK to just define a group and let the user of it make it into a map or
array as they wish.
LL
_______________________________________________
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose
