Re: [sacm] CoSWID review

[Kathleen Moriarty <[e-mail]>]

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

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