Skip to main content

Concise Software Identification Tags
draft-ietf-sacm-coswid-24

Revision differences

Document history

Date Rev. By Action
2023-06-23
24 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2023-04-17
24 (System) RFC Editor state changed to AUTH48
2023-02-28
24 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2023-02-28
24 (System) RFC Editor state changed to RFC-EDITOR from IANA
2023-02-28
24 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2023-02-28
24 (System) IANA Action state changed to In Progress from Waiting on Authors
2023-02-27
24 (System) IANA Action state changed to Waiting on Authors from In Progress
2023-02-27
24 (System) IANA Action state changed to In Progress from On Hold
2023-02-24
24 Henk Birkholz New version available: draft-ietf-sacm-coswid-24.txt
2023-02-24
24 Jenny Bui Posted submission manually
2023-02-07
23 Henk Birkholz New version available: draft-ietf-sacm-coswid-23.txt
2023-02-07
23 Jenny Bui Posted submission manually
2022-11-01
22 (System) RFC Editor state changed to IANA from EDIT
2022-09-27
22 (System) IANA Action state changed to On Hold from Waiting on Authors
2022-09-20
22 (System) RFC Editor state changed to EDIT from MISSREF
2022-09-20
22 (System) IANA Action state changed to Waiting on Authors from In Progress
2022-09-20
22 (System) IANA Action state changed to In Progress from Waiting on ADs
2022-08-09
22 (System) IANA Action state changed to Waiting on ADs from In Progress
2022-08-09
22 (System) IANA Action state changed to In Progress from Waiting on Authors
2022-08-01
22 (System) IANA Action state changed to Waiting on Authors from In Progress
2022-08-01
22 (System) IANA Action state changed to In Progress from Waiting on Authors
2022-07-28
22 (System) IANA Action state changed to Waiting on Authors from In Progress
2022-07-20
22 (System) RFC Editor state changed to MISSREF
2022-07-20
22 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2022-07-20
22 (System) Announcement was received by RFC Editor
2022-07-20
22 (System) IANA Action state changed to In Progress
2022-07-20
22 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2022-07-20
22 Cindy Morgan IESG has approved the document
2022-07-20
22 Cindy Morgan Closed "Approve" ballot
2022-07-20
22 Cindy Morgan Ballot approval text was generated
2022-07-20
22 Roman Danyliw IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup
2022-07-20
22 (System) Sub state has been changed to AD Followup from Revised ID Needed
2022-07-20
22 Henk Birkholz New version available: draft-ietf-sacm-coswid-22.txt
2022-07-20
22 Jenny Bui Forced post of submission
2022-07-20
22 (System) Request for posting confirmation emailed to previous authors: Charles Schmidt , David Waltermire , Henk Birkholz , Jessica Fitzgerald-McKay
2022-07-20
22 Henk Birkholz Uploaded new revision
2022-06-06
21 Ines Robles Closed request for Telechat review by IOTDIR with state 'Overtaken by Events': IESG state changed to Approved-announcement to be sent::Revised I-D Needed
2022-06-06
21 Ines Robles Assignment of request for Telechat review by IOTDIR to Carsten Bormann was marked no-response
2022-05-06
21 Roman Danyliw Outstanding issues from IESG Review: https://mailarchive.ietf.org/arch/msg/sacm/7h7j2WMCMi0fccrhy_I8uqff6bA/
2022-03-21
21 (System) Removed all action holders (IESG state changed)
2022-03-21
21 Roman Danyliw IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation::Revised I-D Needed
2022-03-21
21 Robert Wilton
[Ballot comment]
Hi,

I've discussed this with Roman and Henk and I've agreed to remove my discuss so that the document can be approved and …
[Ballot comment]
Hi,

I've discussed this with Roman and Henk and I've agreed to remove my discuss so that the document can be approved and move forward before the new IESG handover.

The proposal for the two issues below are:

(1) I think that it would be helpful to have a liaison statement between the SACM WG and ISO that confirms the ongoing expectation and evolution of SWID and CoSWID, i.e., my understanding is that ISO intends to reuse the IANA registry and I think that it would be good to get that more formally confirmed now whilst everyone agrees, so that this doesn't end up being a problem in future when participants have changed and moved on to new projects.  This doesn't need to block the progression of this document, it could be done in parallel.  I also don't think that this had to be written into the document, but possibly a comment in the document may be helpful to set the context for future readers.

(2) Regarding the Semver 2.0.0 reference, the suggestion from Roman, which I agree with is that it would be better if the SEMVER reference cited the ITU SWID spec as the normative reference and the current accurate github reference becomes informative.

----------------

Previous discuss comments:

1.  While an attempt to align
  SWID and CoSWID tags has been made here, future revisions of ISO/IEC
  19770-2:2015 or this specification might cause this implicit
  information model to diverge, since these specifications are
  maintained by different standards groups.

This text concerns me, in that it seems that the IETF is expecting or allowing the SWID and CoSWID specification to diverge.

Would it be possible to have stronger text here? E.g., to indicate:
- the intent is to keep the two spec's consistent.
- nothing should be added to CoSWID without working with ISO/IEC to update CoSWID
- if SWID evolves then CoSWID should be similarly updated.

Or, otherwise, are ISO/IEC okay with the IETF effectively forking their specification in future?


2.
  [SEMVER]  Preston-Werner, T., "Semantic Versioning 2.0.0",
              .

I want to check whether this URL is stable enough for a normative reference.  During the YANG Semver work we discovered, that despite the Semver specification stating that is follows the Semver rules, in fact it doesn't! Specifically, the specification has been updated without changing the version number.  The proposed solution for the YANG semver draft was to reference a specific data and revision of the "YANG Semver 2.0.0" specification in github.
the YANG Semver 2.0.0 specification on a given data.

  [semver]  "Semantic Versioning 2.0.0 (text from June 19, 2020)",
              .

Would doing something similar be wise here?
2022-03-21
21 Robert Wilton [Ballot Position Update] Position for Robert Wilton has been changed to No Objection from Discuss
2022-03-20
21 Roman Danyliw See https://mailarchive.ietf.org/arch/msg/sacm/xg3s8630uKPS_KkCZA_22cpv2wA/
2022-03-20
21 (System) Changed action holders to Roman Danyliw, David Waltermire, Henk Birkholz, Charles Schmidt, Jessica Fitzgerald-McKay (IESG state changed)
2022-03-20
21 Roman Danyliw IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation::AD Followup
2022-03-19
21 Benjamin Kaduk
[Ballot comment]
Many thanks for the updates in the -21 to address my previous
Discuss and Comment points; it was a pleasure to read.

A …
[Ballot comment]
Many thanks for the updates in the -21 to address my previous
Discuss and Comment points; it was a pleasure to read.

A few final notes on the -21 (with I think just one remaining
unchanged from my previous remarks):

Section 2.3

  *  tag-version (index 12): An integer value that indicate the
      specific release revision of the tag.  Typically, the initial
      value of this field is set to 0 and the value is increased for
      subsequent tags produced for the same software component release.

To apply a slightly finer point to my previous comment, do we want to
s/increased/incremented by one/?

Section 2.7

  *  rel (index 40): An integer or textual value that (integer label
      with text escape, see Section 2, for the "Software Tag Link Link
  [...]
      relations/link-relations.xhtml as defined by [RFC8288].  When a
      string value defined in the IANA "Software Tag Link Relationship
      Values" registry matches a Relation Name defined in the IANA "Link
      Relation Types" registry, the index value in the IANA "Software
      Tag Link Relationship Values" registry MUST be used instead, as
      this relationship has a specialized meaning in the context of a
      CoSWID tag.  String values correspond to registered entries in the
      "Software Tag Link Relationship Values" registry.

I'm not sure if the last sentence still makes sense (there were heavy
edits near it as part of the move to "integer label with text escape").
A similar comment applies to "use (index 42)" as well.

Section 2.9.2

My previous inquiry about forcing a certain filesystem structure on
CoSWID consumers got a very helpful reply.  My follow-up question is: is
it worth mentioning in the document the corollary of the [Co]SWID
structure that the on-filesystem path is fixed by the tag publisher?

Section 5.2

                              Tags to be evaluated (the base
  collection) include all tags in the context of where the "swidpath
  URI" is referenced from.  For example, when a tag is installed on a
  given device, that tag can reference related tags on the same device
  using a URI with this scheme.

This definition of "the context" feels rather under-specified and prone
to conflicting interpretations.

NITS

From -20 to -21 a number of internal references changed from Section 2.5
to "Section 2.4, paragraph 2", which mostly don't seem to make sense to
me.  Please double-check.

Section 2.3

  *  version-scheme (index 14): An integer or textual value
      representing the versioning scheme used for the software-version
      item, as an integer label with text escape (Section 2, for the

needs a close paren somewhere

Section 9

  Converse, generators of CoSWID tags need to ensure that only public

"Conversely"
2022-03-19
21 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss
2022-03-07
21 (System) Changed action holders to Roman Danyliw (IESG state changed)
2022-03-07
21 (System) Sub state has been changed to AD Followup from Revised ID Needed
2022-03-07
21 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2022-03-07
21 Henk Birkholz New version available: draft-ietf-sacm-coswid-21.txt
2022-03-07
21 (System) New version accepted (logged-in submitter: Henk Birkholz)
2022-03-07
21 Henk Birkholz Uploaded new revision
2022-02-17
20 (System) Changed action holders to Roman Danyliw, David Waltermire, Henk Birkholz, Charles Schmidt, Jessica Fitzgerald-McKay (IESG state changed)
2022-02-17
20 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2022-02-17
20 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2022-02-17
20 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2022-02-16
20 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2022-02-16
20 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2022-02-16
20 Zaheduzzaman Sarker [Ballot comment]
Thanks for the document.

I would appreciate a verbose explanation of TBD1 and TBD2, not really clear what they are.
2022-02-16
20 Zaheduzzaman Sarker [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker
2022-02-15
20 Francesca Palombini
[Ballot comment]
Thank you for the work on this document.

Many thanks to Rich Salz for his review: https://mailarchive.ietf.org/arch/msg/art/adGh-_pOSDVJObN06Qps2Scilts/ and thanks to the authors for …
[Ballot comment]
Thank you for the work on this document.

Many thanks to Rich Salz for his review: https://mailarchive.ietf.org/arch/msg/art/adGh-_pOSDVJObN06Qps2Scilts/ and thanks to the authors for addressing it.

I support Rob's first DISCUSS point: I had the same reaction when reading that text. I also have some additional comments, mostly having to do with the use of SHOULD in the document.

Francesca

1. -----

  *  If the patch item is set to "true", the tag SHOULD contain at
      least one link item (see Section 2.7) with both the rel item value
      of "patches" and an href item specifying an association with the
      software that was patched.

  *  If the supplemental item is set to "true", the tag SHOULD contain
      at least one link item with both the rel item value of
      "supplemental" and an href item specifying an association with the
      software that is supplemented.

FP: This is missing text about why these are SHOULD and not MUST or MAY. I agree with John Klensin, who formulated it very clearly:

If SHOULD is used, then it must be accompanied by at least one of:
(1) A general description of the character of the exceptions and/or in what areas exceptions are likely to arise.  Examples are fine but, except in plausible and rare cases, not enumerated lists.
(2) A statement about what should be done, or what the considerations are, if the "SHOULD" requirement is not met.
(3) A statement about why it is not a MUST.

2. -----

  *  artifact (index: 37): To be used with rel="installation-media",

FP: Should "installation-media" be "installationmedia" instead?

3. -----

  *  date (index 35): The date and time the information was collected
      pertaining to the evidence item.

FP: Please add a reference to Section 3.4.1 [RFC8949] and mention that this is the standard date/time string.

4. -----

      space, the "decimal" version scheme SHOULD be used.

FP: Here (and following bullets) is another case that either requires a better context description about the use of SHOULD, or should be rephrased (possibly avoiding the BCP 14 SHOULD) for example:

      space, it is expected that the "decimal" version be used.

5. -----

Section 4.3

FP: Another place where SHOULD appears without explanation.
2022-02-15
20 Francesca Palombini [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini
2022-02-15
20 Robert Wilton
[Ballot discuss]
Hi,

Sorry, but I have a couple of issues that it would be helpful to discuss ...

1.  While an attempt to align …
[Ballot discuss]
Hi,

Sorry, but I have a couple of issues that it would be helpful to discuss ...

1.  While an attempt to align
  SWID and CoSWID tags has been made here, future revisions of ISO/IEC
  19770-2:2015 or this specification might cause this implicit
  information model to diverge, since these specifications are
  maintained by different standards groups.

This text concerns me, in that it seems that the IETF is expecting or allowing the SWID and CoSWID specification to diverge.

Would it be possible to have stronger text here? E.g., to indicate:
- the intent is to keep the two spec's consistent.
- nothing should be added to CoSWID without working with ISO/IEC to update CoSWID
- if SWID evolves then CoSWID should be similarly updated.

Or, otherwise, are ISO/IEC okay with the IETF effectively forking their specification in future?


2.
  [SEMVER]  Preston-Werner, T., "Semantic Versioning 2.0.0",
              .

I want to check whether this URL is stable enough for a normative reference.  During the YANG Semver work we discovered, that despite the Semver specification stating that is follows the Semver rules, in fact it doesn't! Specifically, the specification has been updated without changing the version number.  The proposed solution for the YANG semver draft was to reference a specific data and revision of the "YANG Semver 2.0.0" specification in github.
the YANG Semver 2.0.0 specification on a given data.

  [semver]  "Semantic Versioning 2.0.0 (text from June 19, 2020)",
              .

Would doing something similar be wise here?

Thanks,
Rob
2022-02-15
20 Robert Wilton
[Ballot comment]
  +-------+-------------------------+--------------------------------+
  | 4    | decimal                | A floating point number (e.g., |
  …
[Ballot comment]
  +-------+-------------------------+--------------------------------+
  | 4    | decimal                | A floating point number (e.g., |
  |      |                        | 1.25 is less than 1.3)        |
  +-------+-------------------------+--------------------------------+
  | 16384 | semver                  | A semantic version as defined  |
  |      |                        | by [SWID].  Also see the      |
  |      |                        | [SEMVER] specification for    |
  |      |                        | more information              |
  +-------+-------------------------+--------------------------------+

I'm surprised to see 16384 assigned for Semver, is there a reason why are not allocating 5?
2022-02-15
20 Robert Wilton [Ballot Position Update] New position, Discuss, has been recorded for Robert Wilton
2022-02-14
20 Benjamin Kaduk
[Ballot discuss]
The volume of my comments notwithstanding, this document was actually
quite nice to read.  I think that these discuss points, at least, should …
[Ballot discuss]
The volume of my comments notwithstanding, this document was actually
quite nice to read.  I think that these discuss points, at least, should
be fairly straightforward to resolve.

(1) In a number of places we have text roughly of the form:

    String values based on a  from MUST NOT be used, as these values are less concise than
    their index value equivalent.

This seems like it could have some nasty interactions with updates to the
IANA registry in question, especially if consumers attempt to enforce the
MUST NOT.  Consider a version scheme "foo", used by an implementation M to
emit CoSWID tags.  Implementation M is old and predates "foo"'s
registration, so it uses the text form.  Implementation N postdates "foo"'s
registration and knows to use the integer form for encoding it.  But if N
insists on the integer form for decoding, it will reject M's tags, and
needlessly so.  So I think we need a warning that the "MUST NOT" is only for
encoding, and that decoders MUST accept both forms (at least for names not
listed in this document).

(2) Section 4.1 contains SHOULD-level guidance to use the "semver" version
scheme when the value matches the semantic versioning syntax.  That seems
like it would be highly problematic if the version number only happens to
match the syntax by accident and does not actually match the semantic
versioning semantics.  Shouldn't we be giving recommendations based on the
underlying (intended) semantics rather than just the syntax?
(A similar concern might apply to the recommendation to use any scheme other
than "alphanumeric", but there are not really well-known semantics for the
"alphanumeric" syntax such that expectations of semantics would fail to be
met if the wrong version scheme was assigned.)

(3) The integer values assigned to link ownership values disagree between
Table 5 and the CDDL.  (The IANA registry guidance matches Table 5.)
I did not attempt to obtain a copy of ISO/IEC 19770-2:2015 to confirm
whether it uses integer identifiers that we want to maintain compatibility
with -- the prose in §4.3 is a little unclear as to whether such
compatibility is relevant since it only talks about "values" that are to
match.

(4) It's quite possible that I'm just confused about one or both of the
statements in question, but it seems like there may be some inconsistency
between §2.7's "This specification does not define how to resolve an XPath
query in the context of CBOR" and §5.2's "This XPath is evaluated over SWID
or CoSWID tags found on a system" (with, IIRC, a couple other relevant
mentions elsewhere).  My understanding is that a CoSWID tag is intrinsically
represented in a CBOR form, so I'm not sure how one could cause an XPath
evaluation to match without having defined semantics for evaluating that
query in a CBOR context.

(5) There are a couple of references to first-come, first-served
allocations for SWID index value registrations (e.g., §2's "new constructs
are assigned a unique index value on a first-come, first- served basis",
§6.2.1's "New index values will be provided on a First Come First Served as
defined by [
BCP26]", but I do not see any direction to IANA to create a
registry using such an allocation policy for any range of the registry in
question.  It seems like this indicates some internal inconsistency to be
resolved, but I'm not entirely sure what the proper resolution is.

(6) Section 6.2.2 attempts to provide a namespaced scheme for distributed
allocation of unique (collision-free) names for private-use index values,
but I do not think it admits a unique partition into "domain.prefix" and
"name" by treating U+002D HYPHEN-MINUS as a separator, since that character
is valid in both LDH hostnames and in NMTOKEN names.  This makes it
impossible to guarantee uniqueness, since we could have different
partitionings of the same consolidated name into the underlying components.

(7) We seem to have conflicting statements in §7 about how a signed CoSWID
tag is represented.  First we say that "[a] CoSWID tag MUST be wrapped in a
COSE Single Signer Data Object (COSE_Sign1) that contains a single signature
and MUST be signed by the tag creator", but just a few paragraphs later we
say that "[t]he COSE_Sign structure that allows for more than one signature to
be applied to a CoSWID tag MAY be used", but following the MAY would violate
the MUST.  Furthermore(!), the last paragraph of the section says only that
"[a] CoSWID SHOULD be signed, using the above mechanism", which again is in
conflict with the MUST.  (Section 8 goes on to admit the possibility of
unsigned tags as well as both forms of signed tag, and Section 9 includes "a
signature provided by the supplier if present in the CoSWID tag".)

(8) Table 1 seems to be missing an entry for
$$resource-collection-extension, defined in §2.9.2 and appearing in multiple
other locations.
2022-02-14
20 Benjamin Kaduk
[Ballot comment]
I put the (hopefully!) editorial bits I had specific suggestions for in github at
https://github.com/sacmwg/draft-ietf-sacm-coswid/pull/49

Section 1

  percent reduction of size in …
[Ballot comment]
I put the (hopefully!) editorial bits I had specific suggestions for in github at
https://github.com/sacmwg/draft-ietf-sacm-coswid/pull/49

Section 1

  percent reduction of size in generic usage scenarios.  Additional
  size reduction is enabled with respect to the memory footprint of XML
  parsing/validation as well as the reduction of stack sizes where XML
  processing is now obsolete.

I suggest clarifying regarding "stack", i.e., if this is the memory
allocation chunk that is not the heap, or if this is the amount of
executable code on the system.

Section 2

  two formats.  In such cases, a manual mapping will need to be used.
  These cases are specifically noted in this and subsequent sections
  using an [W3C.REC-xpath20-20101214] where a manual mapping is needed.

I feel like there's some additional text needed around the W3C reference.

Section 2.1

  All names registered with IANA according to requirements in
  Section 6.2 also MUST be valid according to the XML Schema NMTOKEN
  data type (see [W3C.REC-xmlschema-2-20041028] Section 3.3.4) to
  ensure compatibility with the SWID specification where these names
  are used.

The secdir reviewer notes that NMTOKEN has a very large expansion space and
that some further restriction is likely merited (really, in all instances
where NMTOKEN is used, but I'll just mention it once).  What would motivate
allowing the full NMTOKEN space without such restriction?

Section 2.3

    ? payload-or-evidence,

The prose goes on to describe 'payload' and 'evidence' separately, which is
perhaps a slight bump in the road for the reader.

      identifier as defined by [RFC4122].  There are no strict
      guidelines on how this identifier is structured, but examples
      include a 16 byte GUID (e.g. class 4 UUID) [RFC4122], or a text
      string appended to a DNS domain name to ensure uniqueness across
      organizations.

Is there existing deployed reality w.r.t. "DNS domain name" vs "reversed DNS
domain name"?  The latter seems more attractive in theory for this use case.

  *  tag-version (index 12): An integer value that indicate the
      specific release revision of the tag.  Typically, the initial
      value of this field is set to 0 and the value is monotonically
      increased for subsequent tags produced for the same software
      component release.  [...]

I guess "typical" would be "increase by one" each time, which is not exactly
"monotonic" (or even "strictly monotonic" which is what we really need).

  *  media (index 10): This text value is a hint to the tag consumer to
      understand what target platform this tag applies to.  This item
      item MUST be formatted as a query as defined by the W3C Media
      Queries Recommendation (see [W3C.REC-css3-mediaqueries-20120619]).
      Support for media queries are included here for interoperability
      with [SWID], which does not provide any further requirements for
      media query use.  Thus, this specification does not clarify how a
      media query is to be used for a CoSWID.

Following the W3C reference, it's quite hard to see how the media query
would indicate a target platform, but I trust that the authors are
accurately portraying the situation w.r.t. SWID and providing the field for
compatibility purposes.

Section 2.4

Do we want to say what a consumer should do if it encounters a CoSWID tag
that violates the protocol constraints?

Section 2.6

  *  reg-id (index 32): The registration id value is intended to
      uniquely identify a naming authority in a given scope (e.g.
      global, organization, vendor, customer, administrative domain,
      etc.) for the referenced entity.  The value of a registration ID
      MUST be a RFC 3986 URI.  The scope will usually be the scope of an
      organization.

What scheme(s) might we expect to see for these URIs?

Section 2.7

  *  artifact (index: 37): To be used with rel="installation-media",
      this item's value provides the path to the installer executable or
      script that can be run to launch the referenced installation.

Is this a filesystem path, an arbitrary URI, or something else?
If a filesystem path, does it need to be an absolute path?  If relative
paths are allowed, how is the base determined?

      -  If no URI scheme is provided, then the URI-reference is a
        relative reference relative to the URI of the CoSWID tag.  For
        example, "./folder/supplemental.coswid".

What is "the URI of the CoSWID tag"?  I don't see a protocol element in
the concise-swid-tag root map that would obviously convey such a thing.
Would this necessarily be a "swid:" URI that leverages the tag-id of the tag
in question?

  *  media-type (index 41): A link can point to arbitrary resources on
      the endpoint, local network, or Internet using the href item.  Use
      of this item supplies the resource consumer with a hint of what
      type of resource to expect.  [...]

I know we already say "hint", but I'd consider explicitly stating that there
is no obligation for the server hosting the target of the URI to use the
indicated media type when the URI is dereferenced.

Section 2.8

      release.  This version is intended to be used for string
      comparison only and is not intended to be used to determine if a
      specific value is earlier or later in a sequence.

"string comparison" implies automated or mechanical use.  Is that the
intent, as opposed to just "interpretation by humans"?

  *  generator (index 50): The name (or tag-id) of the software
      component that created the CoSWID tag.  If the generating software
      component has a SWID or CoSWID tag, then the tag-id for the
      generating software component SHOULD be provided.

The 'generator' is only defined to hold "text", but the 'tag-id' could be
either text or "bstr .size 16".  How would a bstr tag-id be used here?

Section 2.9.1

  The number used as a value for hash-alg-id is an integer-based hash
  algorithm identifier who's value MUST refer to an ID in the IANA
  "Named Information Hash Algorithm Registry" [IANA.named-information]
  with a Status of "current"; other hash algorithms MUST NOT be used.

"current" as determined when?  Surely this is not introducing a requirement
to consult the live registry prior to any operation on the CoSWID tag...

  If the hash-alg-id is not known, then the integer value "0" MUST be
  used.  This ensures parity between the SWID tag specification [SWID],
  which does not allow an algorithm to be identified for this field.

I'm not sure that "ensures parity" is the best phrasing here; do we mean to
say that it "allows for conversion from" the SWID tags due to the latter
specification not indicating the hash algorithm used?

Section 2.9.2

Some elements of the resource-collection group include information about
filesystem paths.  But if CoSWIDs are immutable after creation, does that
force a certain filesystem hierarchy structure on a consumer of that
software (in effect, squatting on the filesystem namespace per BCP 190)?  Is
there any mechanism for supplemental tags to indicate that different
filesystem paths are to be used?

  The CDDL for the resource-collection group follows:

  path-elements-group = ( ? directory => one-or-more,
                          ? file => one-or-more,
                        )

  resource-collection = (
    path-elements-group,

Is there a reason to not put the "resource-collection" definition first in
the CDDL listing?

Also, I'm not sure I understand the semantics of the array form for both
'directory' and 'file'.  I guess, in order for there to be a parallel
interpretation between the two, it would have to be that each list holds the
elements of the corresponding type that are children of the current
directory.  But an ordered list of "directory" elements might also be
interpreted as a path hierarchy, so some clarification seems in order.

  file-entry = {
    filesystem-item,
    ? size => uint,
    ? file-version => text,
    ? hash => hash-entry,
    * $$file-extension,
    global-attributes,
  }

How would we achieve algorithm agility (BCP 201) for the hash algorithm used
to verify the file's contents?

  *  file-version (index 21): The file's version as reported by
      querying information on the file from the operating system.  This
      item maps to '/SoftwareIdentity/(Payload|Evidence)/File/@version'
      in [SWID].

Not all file systems record file version information; do we want to mention
that limitation here?

  *  location (index 23): The filesystem path where a file is expected
      to be located when installed or copied.  The location MUST be
      either relative to the location of the parent directory item
      (preferred) or relative to the location of the CoSWID tag if no
      parent is defined.  [...]

Does the "location of the CoSWID tag" refer to a location embedded in the
tag or the location on disk where the tag is found?

  *  type (index 29): A string indicating the type of resource.

Is this human-readable, from a registry, ...?

Section 2.10

Thanks for automatically generating the consolidated CDDL block; it saves a
lot of time reviewing it for consistency.

Section 4.x

It looks like in the actual registries we are going to mark 0 as reserved;
should we indicate that in these sections as well?

Section 4.1

I suggest including some example multipart version numbers that include
multi-digit components (and confirming that they sort as integers by
component).

Section 5.2

                Tags to be evaluated include all tags in the context of
  where the tag is referenced from.  For example, when a tag is
  installed on a given device, that tag can reference related tags on
  the same device using a URI with this scheme.

This definition of "the context" feels rather under-specified and prone to
conflicting interpretations.

  For URIs that use the "swidpath" scheme, the requirements apply.

Is there a word missing here (maybe "following")?

Section 6.1

Is index 30 available for registration or should it be marked as reserved?

Section 6.2.2

  domain.prefix-name

  Where "domain.prefix" MUST be a valid Internationalized Domain Name
  as defined by [RFC5892], and "name" MUST be a unique name within the

I would suggest using the keyword "U-label" from RFC 5890 here.  While using
RFC 5892 as the reference implicitly requires U-label form, it seems more
comfortable for the reader to lay it out explicitly.

  namespace defined by the "domain.prefix".  Use of a prefix in this
  way allows for a name to be used initially in the private use range,
  and to be registered at a future point in time.  This is consistent
  with the guidance in [BCP178].

Is the intention that just the "name" suffix part be what is registered, or
the whole "domain.prefix-name" construct?

Section 6.2.3

  Designated experts MUST ensure that new registration requests meet
  the following additional guidelines:

If they MUST be met, that sounds like "criteria" rather than "guidelines".

That said, in other protocol ecosystems managed by the IETF, we've been
shifting towards much more lenient registration policies, in some cases
essentially a "shall-issue" guidance to the experts.  This has been an
evolution in response to codepoint squatting and is an attempt to make
registration so easy that we can pretty reliably have all codepoints being
used be reflected in the registry.  Attempting to use the registry and the
experts as a gatekeeping function may not always have the desired effect.

  *  Index values and names outside the private use space MUST NOT be
      used without registration.  This is considered squatting and
      SHOULD be avoided.  Designated experts MUST ensure that reviewed
      specifications register all appropriate index values and names.

Why are we matching a SHOULD with a MUST NOT?  Those are different
requirements levels.

Section 6.2.4

                                        Guidelines on how to deconflict
  these value spaces are defined in Section 4.1.

I'm not sure which part of §4.1 we're trying to refer to, here -- I see
guidance on how to interpret values using the version schemes registered by
this document, but am not finding much about how to define new version
schemes in the future.

Section 6.3

  Fragment identifier considerations: Fragment identification for
  application/swid+cbor is supported by using fragment identifiers as
  specified by Section 9.5 of [RFC8949].

Hmm, that reference says:

%  Fragment Identifier Considerations:  The syntax and semantics of
%    fragment identifiers specified for +cbor SHOULD be as specified
%    for "application/cbor".  (At publication of RFC 8949, there is no
%    fragment identification syntax defined for "application/cbor".)

I think it might be more typical to repeat the "SHOULD be as specified ...
at publication of RFC-AAA, there is no fragment identification syntax
defined..." text in this document rather than to say that it's supported and
point to a reference that says it isn't supported.  (But I'm not really an
expert here, and it's a shame that the request for review on the media-types
list didn't get any responses back in October.)

  Magic number(s): first five bytes in hex: da 53 57 49 44

This magic number only holds if the toplevel concise-swid-tag is wrapped by
an explicit tag, but the use of the dedicated media type would normally
render the use of such a tag unnecessary.  (It also only holds if the
requested CBOR Tag value is allocated, of course.)  Do we need/want to
require the presence of this explicit tag somewhere in this document?

Section 6.7

  TAG_CREATOR_REGID "_" "_" UNIQUE_ID

I think this construction suffers a lack of unique decomposition akin to
what I describe in Discuss point (6) -- underscore, including double
underscore, seems to be permitted in both the reg-id ("any-uri") and in the
textual form of the tag-id.

Section 7

  Signing CoSWID tags follows the procedures defined in CBOR Object
  Signing and Encryption [RFC8152].  [...]

draft-ietf-cose-rfc8152bis-struct is in AUTH48 waiting for me to reply to
some RFC Editor questions on Jim Schaad's behalf.  I expect it to be
published before this document is ready, so updating the reference may be in
order.

  protected-signed-coswid-header = {
      1 => int,                      ; algorithm identifier
      3 => "application/swid+cbor",
      4 => bstr,                    ; key identifier

I note that the COSE spec does not require kid to be in the protected
headers, since it's not guaranteed to be unique and is just a hint as to
what key was used.

  Additionally, the COSE Header counter signature MAY be used as an
  attribute in the unprotected header map of the COSE envelope of a
  CoSWID.  The application of counter signing enables second parties to
  provide a signature on a signature allowing for a proof that a
  signature existed at a given time (i.e., a timestamp).

Mention of COSE countersignatures should reference
draft-ietf-cose-countersign since the RFC 8152 countersignature does not
provide the desired properties.

Section 9

A handful of additional potential security considerations to include:

We allow the use of hash values accompanied by a "hash algorithm not known"
identifier, which seems to expose some risk of cross-algorithm attacks
that's worth noting here.  I believe there only becomes practical impact if
some endpoints allow use of an insecure algorithm, but of course we may not
know immediately if an algorithm becomes insecure.

We might also note that an attacker might try to prevent a CoSWID consumer
from learning about new (tag-)versions of a given CoSWID.  CoSWID tags do
not have expiration dates or required freshness checks, so in principle a
powerful attacker could keep an endpoint stuck on an old (vulnerable)
tag-version for quite some time and leverage the vulnerable old tag in some
manner.

Does [SWID] have any discussion of security considerations that we want to
incorporate by reference?

It seems like entitlement-keys have the potential for actually being
confidential information in the CoSWID tag, that should not be distributed
widely.

The use of "persistent-id" for grouping components could allow an attacker
to maliciously claim that their software is a member of some other group.

Errors in setting the 'key' field of a filesystem-item could lead to bad
results from a check for whether a given component is installed.

We probably want to incorporate the security considerations of RFC 8949 by
reference, even if we do already mention that decoders need to exercise
caution in certain regards.

                                                  To support signature
  validation, there is the need associate the right key with the
  software provider or party originating the signature.  This operation
  is application specific and needs to be addressed by the application
  or a user of the application; a specific approach for which is out-
  of-scope for this document.

I feel like we should say something about the need to protect the integrity
of this database of hat keys are authorized to sign which CoSWID tags.

  When an authoritative tag is signed, the originator of the signature
  can be verified.  A trustworthy association between the signature and
  the originator of the signature can be established via trust anchors.
  [...]

I feel like somewhere in here would be a good place to note that just
because there is a signature, and even that the signature can be validated,
does not mean that the CoSWID tag is suitable for a certain use.  The
trustworthy association mentioned here really is required, and it may not be
a simple matter of "all signatures that can be chained to a trust anchor are
trusted for all purposes".

                                                      Consumers of
  CoSWID tags would need to validate the tag using the new credentials
  and would also need to revoke certificates associated with the
  compromised credentials to avoid validating tags signed with them.

Consumers would not need to "revoke" certificates associated with
compromised credentials, but rather consume revocation information about
those certificates, with the revocation information being issued by the
original issuer of the certificates in question.

  CoSWID tags are intended to contain public information about software
  components and, as such, the contents of a CoSWID tag does not need
  to be protected against unintended disclosure on an endpoint.

I know we cover this later on, but we might mention here that the
association of a collection of CoSWID tags with a particular endpoint may
merit confidentiality protection.

  Since the tag-id of a CoSWID tag can be used as a global index value,
  failure to ensure the tag-id's uniqueness can cause collisions or
  ambiguity in CoSWID tags that are retrieved or processed using this
  identifier.  [...]

It seems that a malicious CoSWID issuer could trivially cause such
collisions.  It might be worth discussing this, and the potential
mitigations (don't use the issuer anymore!).

  applications that are vulnerable to certain types of attacks.  As
  noted earlier, CoSWID tags are designed to be easily discoverable by
  an endpoint, but this does not present a significant risk since an

I think we specifically said "*authorized* applications and users" earlier
(emphasis mine), so we might want to qualify the "easily discoverable" here
as well.

Section 11.1

Whether [SAM] or [SEMVER] needs to be classified as normative is not
entirely clear.

X.1520 probably would be fine as informative.

NITS

Section 2.9.1

  The hash-value MUST represent the raw hash value in byte
  representation (in contrast to, e.g., base64 encoded byte
  representation) of the byte string that represents the hashed
  resource generated using the hash algorithm indicated by the hash-
  alg-id.

I'm not sure that "hashed resource" is the most common phrasing for this
sentiment.  Maybe it's the "hash over the [representation of the] resource"?

Section 2.9.2

  *  root (index 25): A filesystem-specific name for the root of the
      filesystem.  The location item is considered relative to this

Is it a filesystem-specific name or a host-specific name?
2022-02-14
20 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2022-02-08
20 Warren Kumari
[Ballot comment]
Thank you for this document. I found it an interesting read.

Also, much thanks to Scott Bradner for his OpsDir review, and to …
[Ballot comment]
Thank you for this document. I found it an interesting read.

Also, much thanks to Scott Bradner for his OpsDir review, and to the authors for addressing it.
2022-02-08
20 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2022-02-08
20 Ines Robles Request for Telechat review by IOTDIR is assigned to Carsten Bormann
2022-02-08
20 Ines Robles Request for Telechat review by IOTDIR is assigned to Carsten Bormann
2022-02-08
20 Erik Kline Requested Telechat review by IOTDIR
2022-02-08
20 Éric Vyncke
[Ballot comment]
Thank you for the work put into this document. The document is deep in CBOR & CDDL so my review is quite superficial …
[Ballot comment]
Thank you for the work put into this document. The document is deep in CBOR & CDDL so my review is quite superficial as I do not have the expertise on these domains.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Christopher Inacio for the shepherd's write-up including the section about the WG consensus, but I would have preferred to see a justification for the intended status.

I hope that this helps to improve the document,

Regards,

-éric

# COMMENTS

There appear to be little traffic on the CBOR mailing list about CoSWID but Carsten Borman is in the acknowledgment section and I am trusting the ART AD for the CBOR review.

The id-nits tool detects a couple of issues (e.g., RFC 8126 and BCP 26 are duplicates).

## Section 1

  "While SWID
  and CoSWID are intended to share the same implicit information model,
  this specification does not define this information model, or a
  mapping between the the two data formats.  While an attempt to align
  SWID and CoSWID tags has been made here, future revisions of ISO/IEC
  19770-2:2015 or this specification might cause this implicit
  information model to diverge, since these specifications are
  maintained by different standards groups."

After reading the above, I was wonder whether there is still value to define such a 'moving target' specification. Suggestion: introduce the extension mechanism early in section 1.

## Section 2

Is there any reason why some CamelCase names (e.g., "version") are not identical in the KebabCase names (e.g., "software-version") ? This break automatic mapping for a minor improvement; hence, a short explanation would be welcome.

# NITS 

## Section 1

"...between the the two data formats...." ;-)

## Other nits

"e.g." and "for example" should be followed by a ","

s/16 byte binary string /16-byte binary string / and similar
2022-02-08
20 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2022-02-01
20 Robert Sparks Request for Telechat review by SECDIR Completed: Ready. Reviewer: Robert Sparks. Sent review to list.
2022-01-28
20 Tero Kivinen Request for Telechat review by SECDIR is assigned to Robert Sparks
2022-01-28
20 Tero Kivinen Request for Telechat review by SECDIR is assigned to Robert Sparks
2022-01-26
20 Cindy Morgan Placed on agenda for telechat - 2022-02-17
2022-01-26
20 Roman Danyliw Ballot has been issued
2022-01-26
20 Roman Danyliw [Ballot Position Update] New position, Yes, has been recorded for Roman Danyliw
2022-01-26
20 Roman Danyliw Created "Approve" ballot
2022-01-26
20 Roman Danyliw IESG state changed to IESG Evaluation from Waiting for Writeup::AD Followup
2022-01-26
20 Roman Danyliw Ballot writeup was changed
2022-01-26
20 Roman Danyliw Ballot approval text was generated
2022-01-26
20 (System) Changed action holders to Roman Danyliw (IESG state changed)
2022-01-26
20 (System) Sub state has been changed to AD Followup from Revised ID Needed
2022-01-26
20 Henk Birkholz New version available: draft-ietf-sacm-coswid-20.txt
2022-01-26
20 (System) New version accepted (logged-in submitter: Henk Birkholz)
2022-01-26
20 Henk Birkholz Uploaded new revision
2022-01-13
19 Roman Danyliw Second post-IETF 112 status check on resolution of IETF LC feedback -- https://mailarchive.ietf.org/arch/msg/sacm/dmYykWlVGnT25KHdIhtffUfEbtw/
2021-10-28
19 Sabrina Tanamal IANA Experts State changed to Expert Reviews OK from Reviews assigned
2021-10-21
19 Roman Danyliw See https://mailarchive.ietf.org/arch/msg/sacm/l-WgSI8rWQZPramFcUlTHzxe_4Y/ (per IETF LC's SECDIR, OPSDIR and ARTART reviews)
2021-10-21
19 (System) Changed action holders to Roman Danyliw, David Waltermire, Henk Birkholz, Charles Schmidt, Jessica Fitzgerald-McKay (IESG state changed)
2021-10-21
19 Roman Danyliw IESG state changed to Waiting for Writeup::Revised I-D Needed from Waiting for Writeup::AD Followup
2021-10-20
19 (System) Changed action holders to Roman Danyliw (IESG state changed)
2021-10-20
19 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-10-20
19 (System) IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2021-10-20
19 Henk Birkholz New version available: draft-ietf-sacm-coswid-19.txt
2021-10-20
19 (System) New version accepted (logged-in submitter: Henk Birkholz)
2021-10-20
19 Henk Birkholz Uploaded new revision
2021-09-09
18 Jean Mahoney Closed request for Last Call review by GENART with state 'Team Will not Review Version'
2021-09-09
18 Jean Mahoney Assignment of request for Last Call review by GENART to Pete Resnick was marked no-response
2021-09-01
18 Roman Danyliw Please review and process the SECDIR, ARTART and OPSDIR feedback.
2021-09-01
18 (System) Changed action holders to Roman Danyliw, David Waltermire, Henk Birkholz, Charles Schmidt, Jessica Fitzgerald-McKay (IESG state changed)
2021-09-01
18 Roman Danyliw IESG state changed to Waiting for Writeup::Revised I-D Needed from Waiting for Writeup
2021-08-11
18 Robert Sparks Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Robert Sparks. Sent review to list.
2021-08-09
18 Sabrina Tanamal IANA Experts State changed to Reviews assigned
2021-08-09
18 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2021-08-09
18 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-sacm-coswid-18. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-sacm-coswid-18. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are eleven actions which we must complete.

IANA understands that, among other requests, there are six requests for new registries to be created by the publication of this document.

IANA Question --> Where should these new registries be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols? Should all the new registries be located at: https://www.iana.org/assignments/swid ?

First, a new registry is to be created called the CoSWID Items Registry. The registration policy for the new registry is as follows:

-4294967295 - -1: Private Use
0 - 32767 : Standards Action
32768 - 4294967295: Specification Required

There are initial registrations in the new registry as follows:

+===============+===========================+===============+
| Index | Item Name | Specification |
+===============+===========================+===============+
| 0 | tag-id | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 1 | software-name | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 2 | entity | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 3 | evidence | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 4 | link | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 5 | software-meta | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 6 | payload | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 7 | hash | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 8 | corpus | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 9 | patch | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 10 | media | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 11 | supplemental | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 12 | tag-version | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 13 | software-version | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 14 | version-scheme | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 15 | lang | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 16 | directory | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 17 | file | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 18 | process | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 19 | resource | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 20 | size | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 21 | file-version | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 22 | key | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 23 | location | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 24 | fs-name | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 25 | root | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 26 | path-elements | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 27 | process-name | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 28 | pid | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 29 | type | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 31 | entity-name | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 32 | reg-id | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 33 | role | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 34 | thumbprint | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 35 | date | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 36 | device-id | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 37 | artifact | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 38 | href | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 39 | ownership | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 40 | rel | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 41 | media-type | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 42 | use | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 43 | activation-status | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 44 | channel-type | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 45 | colloquial-version | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 46 | description | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 47 | edition | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 48 | entitlement-data-required | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 49 | entitlement-key | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 50 | generator | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 51 | persistent-id | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 52 | product | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 53 | product-family | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 54 | revision | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 55 | summary | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 56 | unspsc-code | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 57 | unspsc-version | [ RFC-To-be ] |
+---------------+---------------------------+---------------+
| 58-4294967295 | Unassigned | |
+---------------+---------------------------+---------------+

Second, a new registry is to be created called the Software Tag Version Scheme Values Registry. The new registry will be located at:

https://www.iana.org/assignments/swid

The registration procedure for the new registry, as defined in RFC 8126 is:

0 - 16383: Standards Action
16384 - 65535: Specification Required

There are initial registrations in the new registry as follows:

+=============+=========================+=================+
| Index | Version Scheme Name | Specification |
+=============+=========================+=================+
| 0 | Reserved | |
+-------------+-------------------------+-----------------+
| 1 | multipartnumeric | [ RFC-to-be, Section 4.1] |
+-------------+-------------------------+-----------------+
| 2 | multipartnumeric+suffix | [ RFC-to-be, Section 4.1] |
+-------------+-------------------------+-----------------+
| 3 | alphanumeric | [ RFC-to-be, Section 4.1] |
+-------------+-------------------------+-----------------+
| 4 | decimal | [ RFC-to-be, Section 4.1] |
+-------------+-------------------------+-----------------+
| 5-16383 | Unassigned | |
+-------------+-------------------------+-----------------+
| 16384 | semver | [ RFC-to-be, Section 4.1] |
+-------------+-------------------------+-----------------+
| 16385-65535 | Unassigned | |
+-------------+-------------------------+-----------------+

Third, a new registry is to be created called the Software Tag Entity Role Values Registry. The new registry will be located at:

https://www.iana.org/assignments/swid

The registration procedure for the new registry, as defined in RFC 8126 is:

0 - 127: Standards Action
128 - 255: Specification Required

There are initial registrations in the new registry as follows:

+=======+=================+=================+
| 0 | Reserved | |
+-------+-----------------+-----------------+
| 1 | tagCreator |[ RFC-to-be, Section 4.2] |
+-------+-----------------+-----------------+
| 2 | softwareCreator |[ RFC-to-be, Section 4.2] |
+-------+-----------------+-----------------+
| 3 | aggregator | [ RFC-to-be, Section 4.2] |
+-------+-----------------+-----------------+
| 4 | distributor | [ RFC-to-be, Section 4.2] |
+-------+-----------------+-----------------+
| 5 | licensor | [ RFC-to-be, Section 4.2] |
+-------+-----------------+-----------------+
| 6 | maintainer | [ RFC-to-be, Section 4.2] |
+-------+-----------------+-----------------+
| 7-255 | Unassigned | |
+-------+-----------------+-----------------+

Fourth, a new registry is to be created called the Software Tag Link Ownership Values Registry. The new registry will be located at:

https://www.iana.org/assignments/swid

The registration procedure for the new registry, as defined in RFC 8126 is:

0 - 127: Standards Action
128 - 255: Specification Required

There are initial registrations in the new registry as follows:

+=======+=====================+=================+
| Index | Ownership Type Name | Definition |
+=======+=====================+=================+
| 0 | Reserved | |
+-------+---------------------+-----------------+
| 1 | abandon | [ RFC-to-be, Section 4.3] |
+-------+---------------------+-----------------+
| 2 | private | [ RFC-to-be, Section 4.3] |
+-------+---------------------+-----------------+
| 3 | shared | [ RFC-to-be, Section 4.3] |
+-------+---------------------+-----------------+
| 4-255 | Unassigned | |
+-------+---------------------+-----------------+

Fifth, a new registry is to be created called the Software Tag Link Relationship Values Registry. The new registry will be located at:

https://www.iana.org/assignments/swid

The registration procedure for the new registry, as defined in RFC 8126 is:

0 - 32767: Standards Action
32768 - 65535: Specification Required

There are initial registrations in the new registry as follows:

+==========+========================+=================+
| Index | Relationship Type Name | Specification |
+==========+========================+=================+
| 0 | Reserved | |
+----------+------------------------+-----------------+
| 1 | ancestor | [ RFC-to-be, Section 4.4] |
+----------+------------------------+-----------------+
| 2 | component | [ RFC-to-be, Section 4.4] |
+----------+------------------------+-----------------+
| 3 | feature | [ RFC-to-be, Section 4.4] |
+----------+------------------------+-----------------+
| 4 | installationmedia | [ RFC-to-be, Section 4.4]|
+----------+------------------------+-----------------+
| 5 | packageinstaller | [ RFC-to-be, Section 4.4] |
+----------+------------------------+-----------------+
| 6 | parent | [ RFC-to-be, Section 4.4] |
+----------+------------------------+-----------------+
| 7 | patches | [ RFC-to-be, Section 4.4] |
+----------+------------------------+-----------------+
| 8 | requires | [ RFC-to-be, Section 4.4] |
+----------+------------------------+-----------------+
| 9 | see-also | [ RFC-to-be, Section 4.4] |
+----------+------------------------+-----------------+
| 10 | supersedes | [ RFC-to-be, Section 4.4] |
+----------+------------------------+-----------------+
| 11 | supplemental | [ RFC-to-be, Section 4.4] |
+----------+------------------------+-----------------+
| 12-65535 | Unassigned | |
+----------+------------------------+-----------------+

Sixth, a new registry is to be created called the Software Tag Link Use Values Registry. The new registry will be located at:

https://www.iana.org/assignments/swid

The registration procedure for the new registry, as defined in RFC 8126 is:

0 - 127: Standards Action
128 - 255: Specification Required

There are initial registrations in the new registry as follows:

+=======+====================+=================+
| Index | Link Use Type Name | Specification |
+=======+====================+=================+
| 0 | Reserved | |
+-------+--------------------+-----------------+
| 1 | optional | [ RFC-to-be, Section 4.5] |
+-------+--------------------+-----------------+
| 2 | required | [ RFC-to-be, Section 4.5] |
+-------+--------------------+-----------------+
| 3 | recommended | [ RFC-to-be, Section 4.5] |
+-------+--------------------+-----------------+
| 4-255 | Unassigned | |
+-------+--------------------+-----------------+

Seventh, in the application registry of the Media Types registry located at:

https://www.iana.org/assignments/media-types/

a new registration will be made as follows:

Name: swid+cbor
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Eighth, in the CoAP Content-Formats registry on the Constrained RESTful Environments (CoRE) Parameters registry page located at:

https://www.iana.org/assignments/core-parameters/

a new registration is to be made as follows:

Media Type: application/swid+cbor
Encoding:
ID: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

The registration will be made from the IETF Review or IESG Approval Space (256-9999) range of the registry.

Ninth, in the Concise Binary Object Representation (CBOR) Tags registry located at:

https://www.iana.org/assignments/cbor-tags/

a new registration is to be made as follows:

Tag: [ TBD-at-Registration ]
Data Item: map
Semantics: Concise Software Identifier (CoSWID)
Reference: [ RFC-to-be ]

IANA notes that the authors request a value of 1398229316 for the Tag.

Tenth, in the Uniform Resource Identifier (URI) Schemes registry located at:

https://www.iana.org/assignments/uri-schemes/

two new registrations are to be made as follows:

URI Scheme: swid
Template: [ TBD-at-Registration ]
Description: Applications that require Software-IDs (SWIDs) or Concise Software-IDs (CoSWIDs); see Section 5.1 of [ RFC-to-be ].
Status: Permanent
Well-Known URI Support:
Reference: [ RFC-to-be; Section 5.1 ]
Notes:

URI Scheme: swidpath
Template: [ TBD-at-Registration ]
Description: Applications that require Software-IDs (SWIDs) or Concise Software-IDs (CoSWIDs); see Section 5.2 of [ RFC-to-be ].
Status: Permanent
Well-Known URI Support:
Reference: [ RFC-to-be; Section 5.2 ]
Notes:

IANA Question --> Registrations in the Uniform Resource Identifier (URI) Schemes registry are to be preceded by mailing list review as specified in Section 7.2 of [RFC7595]. Is this action complete?

Eleventh, in the Software Data Model Types registry on the Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC) Parameters registry page located at:

https://www.iana.org/assignments/pa-tnc-parameters/

a new registration will be made as follows:

PEN: 0
Integer: [ TBD-at-Registration ]
Name: Concise Software Identifier (CoSWID)
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist
2021-08-09
18 (System) IESG state changed to Waiting for Writeup from In Last Call
2021-08-07
18 Scott Bradner Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Scott Bradner. Sent review to list.
2021-08-02
18 Rich Salz Request for Last Call review by ARTART Completed: Ready with Nits. Reviewer: Rich Salz. Sent review to list.
2021-07-29
18 Jean Mahoney Request for Last Call review by GENART is assigned to Pete Resnick
2021-07-29
18 Jean Mahoney Request for Last Call review by GENART is assigned to Pete Resnick
2021-07-29
18 Tero Kivinen Request for Last Call review by SECDIR is assigned to Robert Sparks
2021-07-29
18 Tero Kivinen Request for Last Call review by SECDIR is assigned to Robert Sparks
2021-07-28
18 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Scott Bradner
2021-07-28
18 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Scott Bradner
2021-07-27
18 Barry Leiba Request for Last Call review by ARTART is assigned to Rich Salz
2021-07-27
18 Barry Leiba Request for Last Call review by ARTART is assigned to Rich Salz
2021-07-26
18 Christopher Inacio
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

~~This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

~~This version is dated 1 November 2019.~~
This version is dated 27 July 2021.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

The standard defines a more compact and concise format using CBOR encoding for the ISO ISO-19770-2:2015 SWID (Software Identifier) information format.  The standard allows more compact exchange of this information as opposed to the ISO XML format.  The CoSWID standard does allow semantic versioning to capture changes in ISO SWID and allows a superset of ISO SWID information.  Additionally, CoSWID creates an IANA based registry for additional information elements to be added to the CoSWID lexicon.

Working Group Summary:

The only controversy was related to the document signing defined in CoSWID and if that should be using a JWT/CWT  compatible signature or the one defined in the standard.

Document Quality:

This has had through reviews and in particular strong reviews from NIST involved in the ISO standard development.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Shepherd SACM WG Chair: Chris Inacio (inacio@cert.org)
Responsible AD: Roman Danyliw (rdd@cert.org)

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I've thoroughly reviewed the document three times and it has gone through WGLC twice as well.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

The document has been reviewed by a CBOR expert as well as review by the URI scheme reviewers.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

None.  All issues have been resolved in the extensive last call and review process.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

I believe it has strong WG support and code signing issues have been resolved.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Non-ascii character for the appropriate university spelling name:  ä - which is acceptable to this chair.
FQDN - one nit captured, but I couldn't find to be real.
References to be resolved via IESG submission.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The IANA sections have been checked for the new registries requested, including review and initial definitions.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

CoSWID Items Registry - combination of Standards action for lower set of code point range and (standards) specification for higher set of code point range.  Higher range code points are intended for allocation by SDOs that are not IETF.

SWID/CoSWID Version Scheme Registry - Standards action for lower set of code point range and specification for higher set of code point range.  Expert review and instructions provided.

Additions to the following new registries are per the defined expert review:

Entity Role Values - These initial entries match the ISO/IEC 19770-2:2015 standard
SWID/CoSWID Link Ownership Values - These initial entries match the ISO/IEC 19770-2:2015
SWID/CoSWID Link Relationship Value Registry - These initial entries match the ISO/IEC 19770-2:2015
SWID/CoSWID Link Use Value Registry - These initial entries match the ISO/IEC 19770-2:2015

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

None.  I would like to have automated checks for CBOR definitions, but those do not yet exist.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A
2021-07-26
18 Amy Vezza IANA Review state changed to IANA - Review Needed
2021-07-26
18 Amy Vezza
The following Last Call announcement was sent out (ends 2021-08-09):

From: The IESG
To: IETF-Announce
CC: Christopher Inacio , Karen O'Donoghue , draft-ietf-sacm-coswid@ietf.org, inacio@cert.org …
The following Last Call announcement was sent out (ends 2021-08-09):

From: The IESG
To: IETF-Announce
CC: Christopher Inacio , Karen O'Donoghue , draft-ietf-sacm-coswid@ietf.org, inacio@cert.org, rdd@cert.org, sacm-chairs@ietf.org, sacm@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Concise Software Identification Tags) to Proposed Standard


The IESG has received a request from the Security Automation and Continuous
Monitoring WG (sacm) to consider the following document: - 'Concise Software
Identification Tags'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-08-09. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  ISO/IEC 19770-2:2015 Software Identification (SWID) tags provide an
  extensible XML-based structure to identify and describe individual
  software components, patches, and installation bundles.  SWID tag
  representations can be too large for devices with network and storage
  constraints.  This document defines a concise representation of SWID
  tags: Concise SWID (CoSWID) tags.  CoSWID supports a similar set of
  semantics and features as SWID tags, as well as new semantics that
  allow CoSWIDs to describe additional types of information, all in a
  more memory efficient format.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-sacm-coswid/



No IPR declarations have been submitted directly on this I-D.




2021-07-26
18 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2021-07-26
18 Roman Danyliw Last call was requested
2021-07-26
18 Roman Danyliw Last call announcement was generated
2021-07-26
18 Roman Danyliw Ballot approval text was generated
2021-07-26
18 Roman Danyliw Ballot writeup was generated
2021-07-26
18 (System) Changed action holders to Roman Danyliw (IESG state changed)
2021-07-26
18 Roman Danyliw IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2021-07-22
18 Karen O'Donoghue Added to session: IETF-111: sacm  Mon-1200
2021-07-12
18 (System) Removed all action holders (IESG state changed)
2021-07-12
18 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-07-12
18 Henk Birkholz New version available: draft-ietf-sacm-coswid-18.txt
2021-07-12
18 (System) New version accepted (logged-in submitter: Henk Birkholz)
2021-07-12
18 Henk Birkholz Uploaded new revision
2021-03-10
17 Roman Danyliw Review AD Review of -17 per IETF 110 discussion: https://mailarchive.ietf.org/arch/msg/sacm/JOdWmBUqxv4TwuPZunVTueu84hc/
2021-03-09
17 Karen O'Donoghue Added to session: IETF-110: sacm  Wed-1300
2021-03-05
17 Roman Danyliw See updated AD review: https://mailarchive.ietf.org/arch/msg/sacm/IDi8scO7T4PhTXLA-Wzvl-XnbiQ/
2021-03-05
17 (System) Changed action holders to David Waltermire, Henk Birkholz, Charles Schmidt, Jessica Fitzgerald-McKay (IESG state changed)
2021-03-05
17 Roman Danyliw IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup
2021-02-22
17 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-02-22
17 David Waltermire New version available: draft-ietf-sacm-coswid-17.txt
2021-02-22
17 (System) New version approved
2021-02-22
17 (System) Request for posting confirmation emailed to previous authors: Charles Schmidt , David Waltermire , Henk Birkholz , Jessica Fitzgerald-McKay , sacm-chairs@ietf.org
2021-02-22
17 David Waltermire Uploaded new revision
2020-11-15
16 Karen O'Donoghue Added to session: IETF-109: sacm  Mon-1200
2020-11-15
16 Roman Danyliw Per remaining items from AD Review: https://mailarchive.ietf.org/arch/msg/sacm/sYG4jhw0e56eD9v5nAQgl_z7lXs/
2020-11-15
16 Roman Danyliw IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup
2020-11-02
16 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-11-02
16 Henk Birkholz New version available: draft-ietf-sacm-coswid-16.txt
2020-11-02
16 (System) New version accepted (logged-in submitter: Henk Birkholz)
2020-11-02
16 Henk Birkholz Uploaded new revision
2020-10-01
15 Roman Danyliw Please see AD Review: https://mailarchive.ietf.org/arch/msg/sacm/lZsk8wlOprU-WKPxgQAYLfBzDdE/
2020-10-01
15 Roman Danyliw IESG state changed to AD Evaluation::Revised I-D Needed from Publication Requested
2020-10-01
15 Roman Danyliw AD Review: https://mailarchive.ietf.org/arch/msg/sacm/lZsk8wlOprU-WKPxgQAYLfBzDdE/
2020-07-27
15 Christopher Inacio
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

The standard defines a more compact and concise format using CBOR encoding for the ISO ISO-19770-2:2015 SWID (Software Identifier) information format.  The standard allows more compact exchange of this information as opposed to the ISO XML format.

Working Group Summary:

The only controversy was related to the document signing defined in CoSWID and if that should be using a JWT/CWT  compatible signature or the one defined in the standard.

Document Quality:

This has had through reviews and in particular strong reviews from NIST involved in the ISO standard development.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Shepherd SACM WG Chair: Chris Inacio (inacio@cert.org)
Responsible AD: Roman Danyliw (rdd@cert.org)

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I've thoroughly reviewed the document twice and it has gone through WGLC twice as well.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

If there were CBOR expert review; although one of the coauthors has been involved in CBOR development and there isn't a CBOR expert review available to the best of my knowledge.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Not yet, but we're calling them out here.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

I believe it has strong WG support excepting the JWT/CWT issue.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Only outdated references which will be resolved during IESG submission waiting for the chair writeup.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The IANA sections have been checked for the new registries requested, including review and initial definitions.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

CoSWID Items Registry - combination of Standards action for lower set of code point range and (standards) specification for higher set of code point range.  Higher range code points are intended for allocation by SDOs that are not IETF.

SWID/CoSWID Version Scheme Registry - Standards action for lower set of code point range and specification for higher set of code point range.  Expert review and instructions provided.

Additions to the following new registries are per the defined expert review:

Entity Role Values - These initial entries match the ISO/IEC 19770-2:2015 standard
SWID/CoSWID Link Ownership Values - These initial entries match the ISO/IEC 19770-2:2015
SWID/CoSWID Link Relationship Value Registry - These initial entries match the ISO/IEC 19770-2:2015
SWID/CoSWID Link Use Value Registry - These initial entries match the ISO/IEC 19770-2:2015

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

None.  I would like to have automated checks for CBOR definitions, but those do not yet exist.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A
2020-07-27
15 Christopher Inacio Responsible AD changed to Roman Danyliw
2020-07-27
15 Christopher Inacio IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2020-07-27
15 Christopher Inacio IESG state changed to Publication Requested from I-D Exists
2020-07-27
15 Christopher Inacio IESG process started in state Publication Requested
2020-07-27
15 Christopher Inacio
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

The standard defines a more compact and concise format using CBOR encoding for the ISO ISO-19770-2:2015 SWID (Software Identifier) information format.  The standard allows more compact exchange of this information as opposed to the ISO XML format.

Working Group Summary:

The only controversy was related to the document signing defined in CoSWID and if that should be using a JWT/CWT  compatible signature or the one defined in the standard.

Document Quality:

This has had through reviews and in particular strong reviews from NIST involved in the ISO standard development.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Shepherd SACM WG Chair: Chris Inacio (inacio@cert.org)
Responsible AD: Roman Danyliw (rdd@cert.org)

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I've thoroughly reviewed the document twice and it has gone through WGLC twice as well.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

If there were CBOR expert review; although one of the coauthors has been involved in CBOR development and there isn't a CBOR expert review available to the best of my knowledge.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Not yet, but we're calling them out here.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

I believe it has strong WG support excepting the JWT/CWT issue.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Only outdated references which will be resolved during IESG submission waiting for the chair writeup.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The IANA sections have been checked for the new registries requested, including review and initial definitions.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

CoSWID Items Registry - combination of Standards action for lower set of code point range and (standards) specification for higher set of code point range.  Higher range code points are intended for allocation by SDOs that are not IETF.

SWID/CoSWID Version Scheme Registry - Standards action for lower set of code point range and specification for higher set of code point range.  Expert review and instructions provided.

Additions to the following new registries are per the defined expert review:

Entity Role Values - These initial entries match the ISO/IEC 19770-2:2015 standard
SWID/CoSWID Link Ownership Values - These initial entries match the ISO/IEC 19770-2:2015
SWID/CoSWID Link Relationship Value Registry - These initial entries match the ISO/IEC 19770-2:2015
SWID/CoSWID Link Use Value Registry - These initial entries match the ISO/IEC 19770-2:2015

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

None.  I would like to have automated checks for CBOR definitions, but those do not yet exist.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A
2020-07-20
15 Karen O'Donoghue Added to session: IETF-108: sacm  Mon-1100
2020-05-04
15 Karen O'Donoghue IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2020-05-04
15 Karen O'Donoghue Notification list changed to Christopher Inacio <inacio@cert.org>, Karen O'Donoghue <odonoghue@isoc.org> from Christopher Inacio <inacio@cert.org>
2020-05-01
15 David Waltermire New version available: draft-ietf-sacm-coswid-15.txt
2020-05-01
15 (System) New version approved
2020-05-01
15 (System) Request for posting confirmation emailed to previous authors: David Waltermire , Henk Birkholz , Charles Schmidt , Jessica Fitzgerald-McKay
2020-05-01
15 David Waltermire Uploaded new revision
2020-05-01
15 David Waltermire Uploaded new revision
2020-05-01
14 Christopher Inacio Notification list changed to Christopher Inacio <inacio@cert.org>
2020-05-01
14 Christopher Inacio Document shepherd changed to Christopher Inacio
2020-04-30
14 Henk Birkholz New version available: draft-ietf-sacm-coswid-14.txt
2020-04-30
14 (System) New version approved
2020-04-30
14 (System) Request for posting confirmation emailed to previous authors: Henk Birkholz , Charles Schmidt , Jessica Fitzgerald-McKay , David Waltermire
2020-04-30
14 Henk Birkholz Uploaded new revision
2020-04-28
13 Karen O'Donoghue Added to session: interim-2020-sacm-01
2019-11-17
13 David Waltermire New version available: draft-ietf-sacm-coswid-13.txt
2019-11-17
13 (System) New version approved
2019-11-16
13 (System) Request for posting confirmation emailed to previous authors: Charles Schmidt , David Waltermire , Henk Birkholz , Jessica Fitzgerald-McKay
2019-11-16
13 David Waltermire Uploaded new revision
2019-11-16
13 David Waltermire Uploaded new revision
2019-07-26
12 Karen O'Donoghue Changed consensus to Yes from Unknown
2019-07-26
12 Karen O'Donoghue Intended Status changed to Proposed Standard from None
2019-07-26
12 Karen O'Donoghue These WGLC started 27 June 2019, but I neglected to set the flag.
2019-07-26
12 Karen O'Donoghue IETF WG state changed to In WG Last Call from WG Document
2019-07-25
12 David Waltermire New version available: draft-ietf-sacm-coswid-12.txt
2019-07-25
12 (System) New version approved
2019-07-25
12 (System) Request for posting confirmation emailed to previous authors: Charles Schmidt , David Waltermire , Henk Birkholz , Jessica Fitzgerald-McKay
2019-07-25
12 David Waltermire Uploaded new revision
2019-07-25
12 David Waltermire Uploaded new revision
2019-07-13
11 Karen O'Donoghue Added to session: IETF-105: sacm  Thu-1740
2019-06-26
11 David Waltermire New version available: draft-ietf-sacm-coswid-11.txt
2019-06-26
11 (System) New version approved
2019-06-26
11 (System) Request for posting confirmation emailed to previous authors: Charles Schmidt , David Waltermire , Henk Birkholz , Jessica Fitzgerald-McKay
2019-06-26
11 David Waltermire Uploaded new revision
2019-06-26
11 David Waltermire Uploaded new revision
2019-06-24
10 David Waltermire New version available: draft-ietf-sacm-coswid-10.txt
2019-06-24
10 (System) New version approved
2019-06-24
10 (System) Request for posting confirmation emailed to previous authors: Charles Schmidt , David Waltermire , Henk Birkholz , Jessica Fitzgerald-McKay
2019-06-24
10 David Waltermire Uploaded new revision
2019-06-24
10 David Waltermire Uploaded new revision
2019-05-12
09 Henk Birkholz New version available: draft-ietf-sacm-coswid-09.txt
2019-05-12
09 (System) New version approved
2019-05-12
09 (System) Request for posting confirmation emailed to previous authors: Charles Schmidt , David Waltermire , Henk Birkholz , Jessica Fitzgerald-McKay
2019-05-12
09 Henk Birkholz Uploaded new revision
2019-05-11
08 (System) Document has expired
2018-11-07
08 Henk Birkholz New version available: draft-ietf-sacm-coswid-08.txt
2018-11-07
08 (System) New version approved
2018-11-07
08 (System) Request for posting confirmation emailed to previous authors: Charles Schmidt , David Waltermire , Henk Birkholz , Jessica Fitzgerald-McKay
2018-11-07
08 Henk Birkholz Uploaded new revision
2018-10-23
07 Henk Birkholz New version available: draft-ietf-sacm-coswid-07.txt
2018-10-23
07 (System) New version approved
2018-10-23
07 (System) Request for posting confirmation emailed to previous authors: Charles Schmidt , David Waltermire , Henk Birkholz , Jessica Fitzgerald-McKay
2018-10-23
07 Henk Birkholz Uploaded new revision
2018-07-11
06 Karen O'Donoghue Added to session: IETF-102: sacm  Fri-1150
2018-07-02
06 Henk Birkholz New version available: draft-ietf-sacm-coswid-06.txt
2018-07-02
06 (System) New version approved
2018-07-02
06 (System) Request for posting confirmation emailed to previous authors: Charles Schmidt , David Waltermire , Henk Birkholz , Jessica Fitzgerald-McKay
2018-07-02
06 Henk Birkholz Uploaded new revision
2018-03-21
05 David Waltermire New version available: draft-ietf-sacm-coswid-05.txt
2018-03-21
05 (System) New version approved
2018-03-21
05 (System) Request for posting confirmation emailed to previous authors: Charles Schmidt , David Waltermire , Henk Birkholz , Jessica Fitzgerald-McKay
2018-03-21
05 David Waltermire Uploaded new revision
2018-03-15
04 Karen O'Donoghue Added to session: IETF-101: sacm  Thu-0930
2018-03-05
04 David Waltermire New version available: draft-ietf-sacm-coswid-04.txt
2018-03-05
04 (System) New version approved
2018-03-05
04 (System) Request for posting confirmation emailed to previous authors: Charles Schmidt , David Waltermire , Henk Birkholz , Jessica Fitzgerald-McKay
2018-03-05
04 David Waltermire Uploaded new revision
2018-02-23
03 David Waltermire Added to session: interim-2018-suit-01
2018-01-03
03 Henk Birkholz New version available: draft-ietf-sacm-coswid-03.txt
2018-01-03
03 (System) New version approved
2018-01-03
03 (System) Request for posting confirmation emailed to previous authors: Charles Schmidt , David Waltermire , Henk Birkholz , Jessica Fitzgerald-McKay
2018-01-03
03 Henk Birkholz Uploaded new revision
2017-07-03
02 Henk Birkholz New version available: draft-ietf-sacm-coswid-02.txt
2017-07-03
02 (System) New version approved
2017-07-03
02 (System) Request for posting confirmation emailed to previous authors: Charles Schmidt , David Waltermire , Henk Birkholz , Jessica Fitzgerald-McKay
2017-07-03
02 Henk Birkholz Uploaded new revision
2017-02-16
01 Henk Birkholz New version available: draft-ietf-sacm-coswid-01.txt
2017-02-16
01 (System) New version approved
2017-02-16
01 (System) Request for posting confirmation emailed to previous authors: "Henk Birkholz" , "Jessica Fitzgerald-McKay" , "Charles Schmidt" , "David Waltermire"
2017-02-16
01 Henk Birkholz Uploaded new revision
2017-01-09
00 Karen O'Donoghue This document now replaces draft-birkholz-sacm-coswid instead of None
2017-01-09
00 Henk Birkholz New version available: draft-ietf-sacm-coswid-00.txt
2017-01-09
00 (System) WG -00 approved
2017-01-09
00 Henk Birkholz Set submitter to "Henk Birkholz ", replaces to draft-birkholz-sacm-coswid and sent approval email to group chairs: sacm-chairs@ietf.org
2017-01-09
00 Henk Birkholz Uploaded new revision