Subject: [COSE] A standard definition for digests in draft-ietf-cose-hash-algs?

From: Laurence Lundblade <[email-masked]>
Date: Fri, 9 Jul 2021 20:44:40 -0700

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

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 10 Jul 2021 09:02:34 +0200

> On 2021-07-10, at 05:44, Laurence Lundblade <[email-masked]> wrote:
> 

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:

This is the “3”.

>     ? 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

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 12 Jul 2021 21:03:18 -0700

Hi Carsten,

> On Jul 10, 2021, at 12:02 AM, Carsten Bormann <[email-masked]> wrote:
> 
> 

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.

> 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.

> 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.

> 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