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 |