Re: [COSE] [sacm] CoSWID review

[Jim Schaad <[e-mail]>]

-----Original Message-----
From: COSE <[e-mail]> On Behalf Of Michael Richardson
Sent: Wednesday, November 20, 2019 2:12 PM
To: [e-mail]; 'sacm' <[e-mail]>
Subject: Re: [COSE] [sacm] CoSWID review


In order to understand this thread, I took a look at
draft-ietf-cose-hash-algs.
MINOR:
* I think that the term "Thumbprint" is not often used, and that fingerprint
is
  a more common term to use.

[JLS] I betray my past.  Microsoft has always used Thumbprint for this term,
regardless of what anybody else is calling it.
I think it probably makes sense to change it.

Jim


My understand is that there is a proposal to use an existing registry for
the list ("COSE Algorithms"), but that this registry has things which are
not hash algorithms.

There are I think, three entities that care, and I think that there is an
over-generality being applied which is causing people to have concerns.

1) There are people who look at the list of algorithms to decide which one
to
   use for a particular application.  I hope these aren't end-users, but
   rather application writers who need to decide which ones they need to
   implement.  Better is that they are defining some protocol/profile which
   uses COSE.  It's Thread or OPC or Azure IoT, etc.
   I think that we can depend upon those people to be able to discard things
   which are of the wrong shape.

2) There is code which creates signatures or hashes to put into objects.
   It knows which algorithm it is using (it's been programmed to use that
   one), and finding the right number is trivial.

3) There is code which is validating things, and it needs to know which
   algorithm is using to avoid the situation where it becomes possible for
an
   attacker to replace a stronger hash with a weaker one for which a
   pre-image attack is easier to perform.

In case (3), the verifyer has to be ready to accept any hash from the
"list", and it has to be a valid hash.  But, it also has to be for code
which the verifier has implemented. I recall attacks against verifies of
certificates that had hard coded SHA1 (or maybe it was MD5) and ignored the
ASN.1 inside the signature which specified the actual algorithm to use.

If an attacker tells me to use the "RC4 hash", and I don't have a hash like
that, then I reject the number because I don't have it, not because it's not
a hash.

But, maybe I just don't get the problem.
   

--
Michael Richardson <[e-mail]>, Sandelman Software Works  -=
IPv6 IoT consulting =-