Subject: Re: [sacm] CoSWID review

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 18 Nov 2019 07:35:56 -0500

On Sun, Nov 17, 2019 at 6:45 AM Kathleen Moriarty <
[email-masked]> wrote:

> Hi Dave,
>
>
>
> On Sun, Nov 17, 2019 at 3:02 AM Dave Waltermire <[email-masked]>
> wrote:
>
>> Kathleen,
>>
>> Thank you for the review. I have addressed your comments in the latest
>> draft. Some comments on your comments are inline below.
>>
>> From: sacm <[email-masked]> on behalf of Kathleen Moriarty <
>>> [email-masked]>
>>>
>> Date: Fri, October 25, 2019 11:57 PM +0800
>>> To: "<[email-masked]>" <[email-masked]>
>>> Subject: [sacm] CoSWID review
>>>
>>> Hello!
>>>
>>> Thank you for your extensive work on this document!  If it gains wide
>>> adoption, it could be quite helpful to industry and software security
>>> management.  I support publication of this document and have some comments
>>> and concerns to be addressed.  I did not go through all sections thoroughly
>>> yet, so I may come back with additional comments.
>>>
>>> Section 4,
>>> Consider another comma in the first sentence of this text after
>>> component:
>>>
>>> Software Patching.  When a new patch is applied to the software
>>>          component a new patch tag is provided, supplying details about
>>>          the patch and its dependencies.
>>>
>>
>> I reworded this as follows:
>>
>> A new patch tag is provided, when a patch is applied to the software
>> component, supplying details about the patch and its dependencies.
>>
>> I think the comma placement is better this way.
>>
>
> Thanks.
>
>>
>>  Section 2.4:
>>
>>> I see rel(ation) only appears in this section.  I had to poke a bit and
>>> see that (I think) you just mean for rel to expand to relation and rel is
>>> used elsewhere.  Would it be more clear to just define that?  If this is
>>> how it is in SWID, ignore the comment.  I'm just thinking about other
>>> reviewers/readers.  It's defined in 2.7 just as rel.  It's helpful to know
>>> that's short for relation, but if that's all you mean, how about rel
>>> (relation) so it doesn't look like more than it is?
>>>
>>
>> I changed the reference to just "rel". I agree this is more consistent to
>> how other data elements are referenced.
>>
> Great, thanks!
>
>>
>>
>>> Section 2.6:
>>> A Thumbprint is specified in this section, should this be referenced for
>>> clarity on hashes with COSE for object identification:
>>> https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/
>>> <https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-cose-hash-algs%2F&data=02%7C01%7Cdavid.waltermire%40nist.gov%7Cb8c696edcc7243c06a4308d759641092%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637076158616321536&sdata=zAho%2FhohQF50Lv7Ux3ftxOWnFeRiT8S3XfamkLf5vEY%3D&reserved=0>
>>> Would it be better to tie to the COSE set of supported algorithms (they
>>> likely match, but I didn't verify)?
>>>
>>
>> The IANA COSE Algorithms registry contains other types of algorithms
>> beyond hash algorithms. To use this registry, we would need to list the
>> hash-specific algorithms, which is less ideal. Its a shame this registry
>> isn't broken out by algorithm type, which would make this decision easy.
>> With the IANA "Named Information Hash Algorithm Registry", we get only hash
>> algorithms, which is what we are looking for. Can you live with use of the
>> IANA "Named Information Hash Algorithm Registry"?
>>
>
> COSE is open as is their main draft.  This is a problem that can likely be
> solved this week...  Talk to Jim. Let me and the list know what's possible.
>
>>
>>
>>> Section 5:
>>> It might be helpful to list what is being requested at the start of the
>>> IANA section
>>> X registries are established with this request with initial entries for
>>> X registries. Values for Z existing registries are requested.
>>>
>>
>> Done.
>>
> Thanks.
>
>>
>>
>>> 5.1:
>>> s/This document uses integer/This registry uses integer/
>>>
>>
>> Fixed.
>>
>>
>>> Section 5.2.5:
>>>
>>> s/This document defines a new a new a/This document establishes a/
>>>
>>
>> Fixed a bunch of cases that matched this pattern. Thanks for catching
>> this.
>>
> Just trying to head off issues at the later review stages :-) . And they
> were all super minor and may have gone through unnoticed.
>
>
>>
>>
>>> Security Considerations:
>>>
>>> I'm wondering why CWT [RFC8392] was not used or recommended for signing.
>>> Is it that the other method fits better within SWIMA?
>>>
>>
>> COSE was chosen for CoSWID, since it is parallel to the use of
>> XMLDSig.for SWID tags. We could consider CWTs, but this would require a
>> bunch of additional work, and we are fairly close to shipping this draft to
>> the IESG. Maybe a better option might be to write a second draft discussing
>> the use of CWTs with CoSWID? This would allow this draft to move forward,
>> while CWT use is defined. Would you be interested in working on this draft?
>>
>
> Yes, I am interested, with coauthors. Are you offering?
>
>>
>> If CWTs are to be proliferated the way JWTs have been, I suspect it will
>>> be easier for CoSWID to gain traction.  I think it would be good to list
>>> use of a CWT as an option, then registering the claims that one might use
>>> for let's say having the CWT be an EAT and be a remote attestation.  I
>>> think adoption may be better if these are tied together and made simple for
>>> regular readers who will likely start to come across CWTs as opposed to
>>> just signing with one or more signers.  I think what you have us good, but
>>> having both as options would be better.
>>>
>>
>> Both options would also create the need for some signature verifiers to
>> support both options. This is something that should be discussed at greater
>> length, as it could also create potential interoperability issues. I am not
>> against both options, but we should talk to potential implementors about
>> what they want. This is maybe more reason to do this work in a separate
>> draft to allow for some time to work out these details..
>>
>
> OK, great point on interoperability.  My hunch is that since CWTs are in
> EATs, there is code and there is an established pattern of use that this
> would be more likely to be supported (more widely).  It may be good to pull
> this all out as not to create confusion as if it is int he base draft, this
> will be seen as necessary as opposed to a choice and as you note, will
> create confusion.
>
>>
>>
>>> The claims about the signature may vary from the data in the CoSWID, so
>>> this could be potentially useful.
>>>
>>
> Right and minimal claims are possible too.
>
> Thanks,
> Kathleen
>
>>
>> True.
>>
>>
>>> Thank you!
>>> --
>>>
>>> Best regards,
>>> Kathleen
>>>
>>
>
> --
>
> Best regards,
> Kathleen
>

-- 

Best regards,
Kathleen

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Tue, 19 Nov 2019 01:36:55 +0000

Not sure if Jim is here this week. I will email him to see what he says.

Thanks,
Dave
________________________________
From: sacm <[email-masked]> on behalf of Kathleen Moriarty <[email-masked]>
Sent: Monday, November 18, 2019 7:35 AM
To: David Waltermire <[email-masked]>
Cc: <[email-masked]> <[email-masked]>
Subject: Re: [sacm] CoSWID review

On Sun, Nov 17, 2019 at 6:45 AM Kathleen Moriarty <[email-masked]<mailto:[email-masked]>> wrote:
Hi Dave,

On Sun, Nov 17, 2019 at 3:02 AM Dave Waltermire <[email-masked]<mailto:[email-masked]>> wrote:
Kathleen,

Thank you for the review. I have addressed your comments in the latest draft. Some comments on your comments are inline below.

From: sacm <[email-masked]<mailto:[email-masked]>> on behalf of Kathleen Moriarty <[email-masked]<mailto:[email-masked]>>
Date: Fri, October 25, 2019 11:57 PM +0800
To: "<[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]>>
Subject: [sacm] CoSWID review

Hello!

Thank you for your extensive work on this document!  If it gains wide adoption, it could be quite helpful to industry and software security management.  I support publication of this document and have some comments and concerns to be addressed.  I did not go through all sections thoroughly yet, so I may come back with additional comments.

Section 4,
Consider another comma in the first sentence of this text after component:

A new patch tag is provided, when a patch is applied to the software component, supplying details about the patch and its dependencies.

Thanks.

 Section 2.4:
I see rel(ation) only appears in this section.  I had to poke a bit and see that (I think) you just mean for rel to expand to relation and rel is used elsewhere.  Would it be more clear to just define that?  If this is how it is in SWID, ignore the comment.  I'm just thinking about other reviewers/readers.  It's defined in 2.7 just as rel.  It's helpful to know that's short for relation, but if that's all you mean, how about rel (relation) so it doesn't look like more than it is?

I changed the reference to just "rel". I agree this is more consistent to how other data elements are referenced.
Great, thanks!

Section 2.6:
A Thumbprint is specified in this section, should this be referenced for clarity on hashes with COSE for object identification: https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/<https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-cose-hash-algs%2F&data=02%7C01%7Cdavid.waltermire%40nist.gov%7C75ba45cd96ab47c1496808d76c23fd62%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637096774138383674&sdata=7FGlZBW3KNZeR7ur3baxZKvGm5m8jYR%2BdQnng6L1%2Bmc%3D&reserved=0>
Would it be better to tie to the COSE set of supported algorithms (they likely match, but I didn't verify)?

The IANA COSE Algorithms registry contains other types of algorithms beyond hash algorithms. To use this registry, we would need to list the hash-specific algorithms, which is less ideal. Its a shame this registry isn't broken out by algorithm type, which would make this decision easy. With the IANA "Named Information Hash Algorithm Registry", we get only hash algorithms, which is what we are looking for. Can you live with use of the  IANA "Named Information Hash Algorithm Registry"?

COSE is open as is their main draft.  This is a problem that can likely be solved this week...  Talk to Jim. Let me and the list know what's possible.

Section 5:
It might be helpful to list what is being requested at the start of the IANA section
X registries are established with this request with initial entries for X registries. Values for Z existing registries are requested.

Done.
Thanks.

5.1:

Fixed.

Section 5.2.5:

Fixed a bunch of cases that matched this pattern. Thanks for catching this.
Just trying to head off issues at the later review stages :-) . And they were all super minor and may have gone through unnoticed.

Security Considerations:

I'm wondering why CWT [RFC8392] was not used or recommended for signing. Is it that the other method fits better within SWIMA?

COSE was chosen for CoSWID, since it is parallel to the use of XMLDSig.for SWID tags. We could consider CWTs, but this would require a bunch of additional work, and we are fairly close to shipping this draft to the IESG. Maybe a better option might be to write a second draft discussing the use of CWTs with CoSWID? This would allow this draft to move forward, while CWT use is defined. Would you be interested in working on this draft?

If CWTs are to be proliferated the way JWTs have been, I suspect it will be easier for CoSWID to gain traction.  I think it would be good to list use of a CWT as an option, then registering the claims that one might use for let's say having the CWT be an EAT and be a remote attestation.  I think adoption may be better if these are tied together and made simple for regular readers who will likely start to come across CWTs as opposed to just signing with one or more signers.  I think what you have us good, but having both as options would be better.

Both options would also create the need for some signature verifiers to support both options. This is something that should be discussed at greater length, as it could also create potential interoperability issues. I am not against both options, but we should talk to potential implementors about what they want. This is maybe more reason to do this work in a separate draft to allow for some time to work out these details..

OK, great point on interoperability.  My hunch is that since CWTs are in EATs, there is code and there is an established pattern of use that this would be more likely to be supported (more widely).  It may be good to pull this all out as not to create confusion as if it is int he base draft, this will be seen as necessary as opposed to a choice and as you note, will create confusion.

The claims about the signature may vary from the data in the CoSWID, so this could be potentially useful.

Thanks,
Kathleen

True.

Thank you!
--

Best regards,
Kathleen

--

Best regards,
Kathleen

--

Best regards,
Kathleen

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Tue, 19 Nov 2019 01:39:58 +0000

Section 2.6:

Section 5:

Done.
Thanks.

5.1:

Fixed.

Section 5.2.5:

Security Considerations:

Thanks,
Kathleen

True.

Thank you!
--

Best regards,
Kathleen

--

Best regards,
Kathleen

--

Best regards,
Kathleen

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Tue, 19 Nov 2019 01:52:15 +0000

COSE WG,

I accidently sent the last email early. Please ignore it.

Kathleen provided comments below on draft-ietf-sacm-coswid suggesting that we use the COSE proposed algorithm identifiers for hashes in CoSWID. We are currently using the entries in the IANA Named Information Hash Algorithm Registry. It would be great to align with the COSE hash algorithms, but I can't figure out a way to point to only the hash algorithms in the COSE Algorithms registry. We can point to the draft-ietf-cose-hash-algs once its published as an RFC, but this would be less agile in the face of future updates to COSE hash algorithms. It would very useful if the COSE Algorithms registry has a column for algorithm type. That way we could select only the hash algorithms.

Do you have any suggestions on how we might move forward?

Regards,
Dave Waltermire

________________________________
From: Waltermire, David A. (Fed) <[email-masked]>
Sent: Monday, November 18, 2019 8:39 PM
To: [email-masked] <[email-masked]>
Cc: sacm <[email-masked]>
Subject: Fw: [sacm] CoSWID review

Section 2.6:

---

From: Jim Schaad <[email-masked]>
Date: Tue, 19 Nov 2019 10:24:37 +0800

Do you believe that there is an issue where you cannot say.  Use the values
from registry X and this must be a hash algorithm without trying to do some
type of filter.  If we do a filter then we start playing the game of naming
all of the different types of algorithms and potentially need to deal with
algorithms which would have two algorithm type labels.

Jim

From: COSE <[email-masked]> On Behalf Of Waltermire, David A. (Fed)
Sent: Tuesday, November 19, 2019 9:52 AM
To: [email-masked]
Cc: sacm <[email-masked]>
Subject: Re: [COSE] [sacm] CoSWID review

COSE WG,

Kathleen provided comments below on draft-ietf-sacm-coswid suggesting that
we use the COSE proposed algorithm identifiers for hashes in CoSWID. We are
currently using the entries in the IANA Named Information Hash Algorithm
Registry. It would be great to align with the COSE hash algorithms, but I
can't figure out a way to point to only the hash algorithms in the COSE
Algorithms registry. We can point to the draft-ietf-cose-hash-algs once its
published as an RFC, but this would be less agile in the face of future
updates to COSE hash algorithms. It would very useful if the COSE Algorithms
registry has a column for algorithm type. That way we could select only the
hash algorithms.

Regards,

Dave Waltermire

  _____  

From: Waltermire, David A. (Fed) <[email-masked]
<mailto:[email-masked]> >
Sent: Monday, November 18, 2019 8:39 PM
To: [email-masked] <mailto:[email-masked]>  <[email-masked]
<mailto:[email-masked]> >
Cc: sacm <[email-masked] <mailto:[email-masked]> >
Subject: Fw: [sacm] CoSWID review 

 

On Sun, Nov 17, 2019 at 6:45 AM Kathleen Moriarty
<[email-masked] <mailto:[email-masked]>

Hi Dave, 

On Sun, Nov 17, 2019 at 3:02 AM Dave Waltermire <[email-masked]
<mailto:[email-masked]> > wrote:

Kathleen,

From: sacm <[email-masked] <mailto:[email-masked]> > on behalf
of Kathleen Moriarty <[email-masked]
<mailto:[email-masked]> >

Date: Fri, October 25, 2019 11:57 PM +0800
To: "<[email-masked] <mailto:[email-masked]> >" <[email-masked]
<mailto:[email-masked]> >
Subject: [sacm] CoSWID review

Section 2.6:

A Thumbprint is specified in this section, should this be referenced for
clarity on hashes with COSE for object identification:
https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/
<https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrack
er.ietf.org%2Fdoc%2Fdraft-ietf-cose-hash-algs%2F&data=02%7C01%7Cdavid.walter
mire%40nist.gov%7C75ba45cd96ab47c1496808d76c23fd62%7C2ab5d82fd8fa4797a93e054
655c61dec%7C1%7C0%7C637096774138383674&sdata=7FGlZBW3KNZeR7ur3baxZKvGm5m8jYR
%2BdQnng6L1%2Bmc%3D&reserved=0> 

The IANA COSE Algorithms registry contains other types of algorithms beyond
hash algorithms. To use this registry, we would need to list the
hash-specific algorithms, which is less ideal. Its a shame this registry
isn't broken out by algorithm type, which would make this decision easy.
With the IANA "Named Information Hash Algorithm Registry", we get only hash
algorithms, which is what we are looking for. Can you live with use of the
IANA "Named Information Hash Algorithm Registry"?

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Tue, 19 Nov 2019 03:08:02 +0000

Jim,

Your suggestion of expressing the filter by way of text in the CoSWID draft would provide a path forward. This approach is less clear cut as it leaves the implementer to decide which algorithms are "hash algorithms". This will likely lead to different implementations choosing a different set of algorithms. To address this, I guess we will need to include some text that makes sure that a parser will not fail the parse when encountering an unsupported hash algorithm identifier.

Any other ideas that might provide a clearer solution?

Thanks,
Dave

________________________________
From: Jim Schaad <[email-masked]>
Sent: Monday, November 18, 2019 9:24 PM
To: Waltermire, David A. (Fed) <[email-masked]>; [email-masked] <[email-masked]>
Cc: 'sacm' <[email-masked]>
Subject: RE: [COSE] [sacm] CoSWID review

Do you believe that there is an issue where you cannot say.  Use the values from registry X and this must be a hash algorithm without trying to do some type of filter.  If we do a filter then we start playing the game of naming all of the different types of algorithms and potentially need to deal with algorithms which would have two algorithm type labels.

Jim

COSE WG,

Regards,

Dave Waltermire

From: Waltermire, David A. (Fed) <[email-masked]<mailto:[email-masked]>>
Sent: Monday, November 18, 2019 8:39 PM
To: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Cc: sacm <[email-masked]<mailto:[email-masked]>>
Subject: Fw: [sacm] CoSWID review

Hi Dave,

Kathleen,

Section 2.6:

A Thumbprint is specified in this section, should this be referenced for clarity on hashes with COSE for object identification: https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/<https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-cose-hash-algs%2F&data=02%7C01%7Cdavid.waltermire%40nist.gov%7C2410b750742b4ee7f88108d76c97ace8%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637097271007090632&sdata=NB0wIJTokNhicaXPWlVp448muGvavHVQTxFHBNL%2F0ZI%3D&reserved=0>

---

From: Jim Schaad <[email-masked]>
Date: Tue, 19 Nov 2019 11:22:30 +0800

You probably need to have that text in any event.  If a new hash algorithm
is added to the table you can still end up with the same problem.  Old code
vs new code.

jim

From: Waltermire, David A. (Fed) <[email-masked]> 
Sent: Tuesday, November 19, 2019 11:08 AM
To: Jim Schaad <[email-masked]>; [email-masked]
Cc: 'sacm' <[email-masked]>
Subject: Re: [COSE] [sacm] CoSWID review

Jim,

Your suggestion of expressing the filter by way of text in the CoSWID draft
would provide a path forward. This approach is less clear cut as it leaves
the implementer to decide which algorithms are "hash algorithms". This will
likely lead to different implementations choosing a different set of
algorithms. To address this, I guess we will need to include some text that
makes sure that a parser will not fail the parse when encountering an
unsupported hash algorithm identifier.

Thanks,

Dave

  _____  

From: Jim Schaad <[email-masked] <mailto:[email-masked]> >
Sent: Monday, November 18, 2019 9:24 PM
To: Waltermire, David A. (Fed) <[email-masked]
<mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]>
<[email-masked] <mailto:[email-masked]> >
Cc: 'sacm' <[email-masked] <mailto:[email-masked]> >
Subject: RE: [COSE] [sacm] CoSWID review 

Jim

From: COSE <[email-masked] <mailto:[email-masked]> > On Behalf
Of Waltermire, David A. (Fed)
Sent: Tuesday, November 19, 2019 9:52 AM
To: [email-masked] <mailto:[email-masked]> 
Cc: sacm <[email-masked] <mailto:[email-masked]> >
Subject: Re: [COSE] [sacm] CoSWID review

COSE WG,

Regards,

Dave Waltermire

  _____  

 

Hi Dave, 

Kathleen,

 

Section 2.6:

A Thumbprint is specified in this section, should this be referenced for
clarity on hashes with COSE for object identification:
https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/
<https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrack
er.ietf.org%2Fdoc%2Fdraft-ietf-cose-hash-algs%2F&data=02%7C01%7Cdavid.walter
mire%40nist.gov%7C2410b750742b4ee7f88108d76c97ace8%7C2ab5d82fd8fa4797a93e054
655c61dec%7C1%7C1%7C637097271007090632&sdata=NB0wIJTokNhicaXPWlVp448muGvavHV
QTxFHBNL%2F0ZI%3D&reserved=0>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 20 Nov 2019 14:11:31 +0800

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.

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 <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Jim Schaad <[email-masked]>
Date: Wed, 20 Nov 2019 14:32:37 +0800

-----Original Message-----
From: COSE <[email-masked]> On Behalf Of Michael Richardson
Sent: Wednesday, November 20, 2019 2:12 PM
To: [email-masked]; 'sacm' <[email-masked]>
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.

1) There are people who look at the list of algorithms to decide which one
to

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.

--
Michael Richardson <[email-masked]>, Sandelman Software Works  -=
IPv6 IoT consulting =-

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Thu, 21 Nov 2019 05:02:34 +0000

I have been thinking about the two registry options for hash algorithms.

  1.
IANA "Named Information Hash Algorithm Registry"
  2.
IANA COSE Algorithms Registry + draft-ietf-cose-hash-algs<https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-cose-hash-algs%2F&data=02%7C01%7Cdavid.waltermire%40nist.gov%7C97462d06d07641efcd7208d76c9102a3%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637097242385976328&sdata=USzaQ8fPYRxwEBSbHTR9as83iQiFxcuw1XRqAZiudLo%3D&reserved=0>

The Named Information Hash Algorithm Registry provides a hash-specific set of identifiers that can be used across ISO SWID and IETF CoSWID. This is the original reason we choose this registry, since it has always been our goal to keep as much parity as possible between SWID and CoSWID.  This choice was made in draft-birkholz-sacm-coswid-01 back in January 2017.

The COSE Algorithms registry contains other types of algorithms beyond hash algorithms. After talking with Jim Schaad, it doesn't look like there will be a clear-cut way to point to only the hash algorithms in this registry. This leaves implementers to decide what is a hash algorithm and also makes CoSWID dependent on the publication of draft-ietf-cose-hash-algs<https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-cose-hash-algs%2F&data=02%7C01%7Cdavid.waltermire%40nist.gov%7C97462d06d07641efcd7208d76c9102a3%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637097242385976328&sdata=USzaQ8fPYRxwEBSbHTR9as83iQiFxcuw1XRqAZiudLo%3D&reserved=0>.

For these reasons, I'd like to stick with using the Named Information Hash Algorithm Registry.

Kathleen, is this something you can live with?

Regards,
Dave

________________________________
From: sacm <[email-masked]> on behalf of Waltermire, David A. (Fed) <david.waltermire=[email-masked]>
Sent: Monday, November 18, 2019 8:36 PM
To: Kathleen Moriarty <[email-masked]>; David Waltermire <[email-masked]>
Cc: <[email-masked]> <[email-masked]>
Subject: Re: [sacm] CoSWID review

Thanks,
Dave

Hello!

Section 4,

Thanks.

 Section 2.4:

Section 2.6:
A Thumbprint is specified in this section, should this be referenced for clarity on hashes with COSE for object identification: https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/<https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-cose-hash-algs%2F&data=02%7C01%7Cdavid.waltermire%40nist.gov%7C97462d06d07641efcd7208d76c9102a3%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637097242385976328&sdata=USzaQ8fPYRxwEBSbHTR9as83iQiFxcuw1XRqAZiudLo%3D&reserved=0>
Would it be better to tie to the COSE set of supported algorithms (they likely match, but I didn't verify)?

Section 5:

Done.
Thanks.

5.1:

Fixed.

Section 5.2.5:

Security Considerations:

COSE was chosen for CoSWID, since it is parallel to the use of XMLDSig..for SWID tags. We could consider CWTs, but this would require a bunch of additional work, and we are fairly close to shipping this draft to the IESG. Maybe a better option might be to write a second draft discussing the use of CWTs with CoSWID? This would allow this draft to move forward, while CWT use is defined. Would you be interested in working on this draft?

Thanks,
Kathleen

True.

Thank you!
--

Best regards,
Kathleen

--

Best regards,
Kathleen

--

Best regards,
Kathleen