Reviewer: Robert Sparks Review result: Has Issues I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document has issues to address before publication as a Proposed Standard RFC. Summary: This document defines a representation of software identification using CBOR leveraging COSE. It attempts to reflect what can be represented with SWIDs XML to the degree possible, and is capable of representing things that SWID cannot. The SWID specification is behind a paywall. I have not read it, and cannot comment on whether there are security considerations discussed there that are well known by people with a lot of experience with this technology which may not be explicitly reflected in this document by way of omission-because-obvious. Ambiguity in the SWID spec is explicitly imported as ambiguity in this one (see, in particular, the definition of "media (index 10)". The considerations section spends some time discussing challenges around signature validation, particularly with a declared out-of-scope identification of a need for "an association between the signature and the tag's entity item associated corresponding to the software provider." I am not yet comfortable that I understand the ramifications of this discussion, and encourage the ADs to look closely. Major Issue: This document needs to discuss privacy issues around the creation, transport, and storage of CoSWID objects. I suggest leaning on the style of the discussion in the security considerations section of RFC8412, noting the potential issues with identifying the primary user of a system, that user's rights on the system, and (when evidence is present) exposure of runtime information. Should there be discussion of recovery from loss of control of the signing credentials specific to CoSWID? For example, would a tag-id have to be abandoned after such a loss? Minor Issues: In section 2.1, do you want to constrain names that can be registered to a subset of what validates as NMToken? What XML allows there may be surprising. There may also be a need to inspect what you're pointing to for a definition. If you follow the current reference (https://www.w3.org/TR/2004/REC-xmlschema-2-20041028), you have to follow through to the obsoleted https://www.w3.org/TR/2000/WD-xml-2e-20000814, which in the expansion of NMToken allows a wide range of things by way of CombiningChar and Extender. Note that the rules in the current spec at https://www.w3.org/TR/xml/#NT-Nmtoken and https://www.w3.org/TR/xml/#NT-NameChar have a different production. Your point is to make sure that anything you register will survive parsing when used in SWID, so restricting to an even smaller subset should be ok. And fwiw, your capitalization "NMToken" doesn't match any of the inconsistent variants of the production in the referenced doc. At 2.6 reg-id (index 32) you say "The scope SHOULD be the scope of an organization." Could you add some text motivating why, and what trouble arises from using other scopes? Or would the sentence be better stated as "The scope will usually be the scope of an organization."? At 2.9.1 I worry that "The hash-value byte string value MUST represent the raw hash value of the hashed resource generated using the hash algorithm indicated by the hash-alg-id." is underspecified. The diagram in RC6920 section 6 and some of its examples convey what's meant a little better perhaps. Is there a way to help avoid getting a string that looks like "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"? Consider RFC6648 (BCP 178) where you are reserving "x_" name prefixes for private use. Consider setting the contact for the IANA registrations to a group, area, or the IESG instead of a person. Nits: This sentence really needs this comma: OLD: In the context of software tagging software patching and updating differ in an important way. NEW: In the context of software tagging, software patching and updating differ in an important way. In section 2, I suggest: OLD: As such, it is not always possible to mechanically translate between corresponding attribute names in the two formats. In such cases, a manual mapping will need to be used. NEW: As such, it is not always possible to simply transform corresponding attribute names between the two formats. In such cases, an explicitly provided mapping will need to be used. Consider repeating the observation of SWIDs lack of advice about media (provided in section 2.3) when it comes up in 2.4. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
