Last Call Review of draft-ietf-sacm-coswid-18
review-ietf-sacm-coswid-18-secdir-lc-sparks-2021-08-11-00

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.