Re: [sacm] CoSWID review

["Waltermire, David A. (Fed)" <[e-mail]>]

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 <[e-mail]> on behalf of Waltermire, David A. (Fed) <david.waltermire=[e-mail]>
Sent: Monday, November 18, 2019 8:36 PM
To: Kathleen Moriarty <[e-mail]>; David Waltermire <[e-mail]>
Cc: <[e-mail]> <[e-mail]>
Subject: Re: [sacm] CoSWID review

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

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



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



On Sun, Nov 17, 2019 at 3:02 AM Dave Waltermire <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> on behalf of Kathleen Moriarty <[e-mail]<mailto:[e-mail]>>
Date: Fri, October 25, 2019 11:57 PM +0800
To: "<[e-mail]<mailto:[e-mail]>>" <[e-mail]<mailto:[e-mail]>>
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%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)?

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