According to the RATS Architecture, two reference models for Challenge/Response Attestation have been proposed.  This section <del> highlights the information flows bewteen the Attester, Verifier and </del>  Relying Party undergoing Remote Attestation Procedure, using these models. The passport model is so named because of its resemblance to how nations issue passports to their citizens.  In this model, the <del> attestation sequence is a two step procedure.  In the first step, an Attester conveys Evidence to a Verifier which compares the Evidence </del>  against its appraisal policy.  The Verifier then gives back an Attestation Result to the Attester, which simply caches it.  In the second step, the Attester presents the Attestation Result (and how employers and volunteer organizations perform background checks. In this model, the attestation sequence is initiated by a Relying Party.  The Attester conveys Evidence to the Relying Party, which <del> does not process its payload, but realys the message and optionally check its signature against a policed trust anchor store.  Upon receiving the evidence the Relying Party initiates a session with the Verifier.  Once session is established, it forwards the received Evidence to the Verfier.  The Verifier, appraises the received Evidence according to its appraisal policy for Evidence and returns a corresponding Attestation Result to the Relying Party.  The Relying Party then checks the Attestation Result against its own appraisal policy to conclude attestation. </del>  7.2.

fix some typos and optimize the newly added diagrams to adapt to the width limitation
Thanks Wei! My humongous backlog told me "you'll fix this later" and now you did. Awesome!

According to the RATS Architecture, two reference models for Challenge/Response Attestation have been proposed.  This section  <ins> highlights the information flows bewteen the Attester, Verifier, and </ins> Relying Party undergoing Remote Attestation Procedure, using these models. The passport model is so named because of its resemblance to how nations issue passports to their citizens.  In this model, the  <ins> attestation sequence is a two-step procedure.  In the first step, an Attester conveys Evidence to a Verifier, which compares the Evidence </ins> against its appraisal policy.  The Verifier then gives back an Attestation Result to the Attester, which simply caches it.  In the second step, the Attester presents the Attestation Result (and how employers and volunteer organizations perform background checks. In this model, the attestation sequence is initiated by a Relying Party.  The Attester conveys Evidence to the Relying Party, which  <ins> does not process its payload, but relays the message and optionally checks its signature against a policed trust anchor store.  Upon receiving the Evidence, the Relying Party initiates a session with the Verifier.  Once the session is established, it forwards the received Evidence to the Verifier.  The Verifier appraises the received Evidence according to its appraisal policy for Evidence and returns a corresponding Attestation Result to the Relying Party.  The Relying Party then checks the Attestation Result against its own appraisal policy to conclude attestation. </ins> 7.2.


(for example, to keep the implementation complexity to a minimum) and has a secure channel, such as a local IPC, to interact with a lead Attester (see Composite Device, I-D.ietf-rats-architecture).  The <del> sub-Attester produces a UCCS with the required set of claims and </del>  sends the UCCS through the secure channel to the lead Attester.  The lead Attester then computes a cryptographic hash of the UCCS and protects that hash using its signing key for Evidence, for example, Environment based on the cryptographic mechanisms used when a privacy preserving secure channel is employed. <del> In the case of a Remote Attestation, the attester must consider </del>  whether any UCCS it returns over a privacy preserving secure channel compromises the privacy in unacceptable ways.  As an example, the use of the EAT UEID I-D.ietf-rats-eat Claim in UCCS over a privacy

(As per Ned Smith's message of November 8, 2022)
Claim Key as specified in RFC8392 are currently called lables in the CDDL in the Appendix. "Claim Key" by itself is only used in the definition of UCCS and never again. Should we decide on a consistent use of Claim Key or highlight that is a synonym to label before the CDDL in appendix?

(for example, to keep the implementation complexity to a minimum) and has a secure channel, such as a local IPC, to interact with a lead Attester (see Composite Device, I-D.ietf-rats-architecture).  The  <ins> sub-Attester produces a UCCS with the required CWT Claims Set and </ins> sends the UCCS through the secure channel to the lead Attester.  The lead Attester then computes a cryptographic hash of the UCCS and protects that hash using its signing key for Evidence, for example, Environment based on the cryptographic mechanisms used when a privacy preserving secure channel is employed.  <ins> In the case of a Remote Attestation, the Attester must consider </ins> whether any UCCS it returns over a privacy preserving secure channel compromises the privacy in unacceptable ways.  As an example, the use of the EAT UEID I-D.ietf-rats-eat Claim in UCCS over a privacy


This specification allocates a CBOR tag to mark Unprotected CWT Claims Sets (UCCS) as such and discusses conditions for its proper <del> use in the scope of Remote Attestation Procedures (RATS) in the usage scenario that is the conveyance of Evidence from an Attester to a Verifier. </del>  This specification does not change RFC8392: A true CWT does not make use of the tag allocated here; the UCCS tag is an alternative to 2. <del> Usage scenarios involving the conveyance of Claims, in particular, Remote Attestation Procedures (RATS, see RFC9334) require a standardized data definition and encoding format that can be transferred and transported using different communication channels. As these are Claims, RFC8392 is a suitable format.  However, the way these Claims are secured depends on the deployment, the security capabilities of the device, as well as their software stack.  For example, a Claim may be securely stored and conveyed using a device's Trusted Execution Environment (TEE, see I-D.ietf-teep-architecture) or a Trusted Platform Module (TPM, see TPM2).  Especially in some resource constrained environments, the same process that provides the secure communication transport is also the delegate to compose the Claim to be conveyed.  Whether it is a transfer or transport, a Secure Channel is presumed to be used for conveying such UCCS.  The following sections elaborate on Secure Channel characteristics in general and further describe RATS usage scenarios and corresponding requirements for UCCS deployment. </del>  3. the UCCS through the Secure Channel to the lead Attester.  The lead Attester then computes a cryptographic hash of the UCCS and protects that hash using its signing key for Evidence, for example, using a <del> Detached EAT Bundle (I-D.ietf-rats-eat). </del>  4.3. secchan discusses security considerations for Secure Channels, in which UCCS might be used.  This document provides the CBOR tag definition for UCCS and a discussion on security consideration for <del> the use of UCCS in Remote Attestation Procedures (RATS).  Uses of UCCS outside the scope of RATS are not covered by this document.  The UCCS specification - and the use of the UCCS CBOR tag, correspondingly - is not intended for use in a scope where a scope- specific security consideration discussion has not been conducted, vetted and approved for that use. </del>  6.1.

Archived-At:
straight forward. :ship: it! A few comments/questions for WGLC: The secure channel definition in section 1.1 may benefit from stating that mutual authentication is not required. This is hinted at by stating "the same qualities" as CWT conveyance are required but, given the NIST definition requires mutual auth, additionally saying mutual auth is not required would be clearer.In section 3.1.2, perhaps change the end of the last sentence to "using a Detached-Submodule-Digest or Detached-EAT-Bundle" since the Detached-Submodule-Digest is what conveys the hash and can be used independent of a Detached-EAT-Bundle.In Table 1 in Section 4, should the Data Item be Claims-Set instead of map? The registry is inconsistent. Some definitions are general with only map or array listed, others identify a specific type, e.g., the COSE types.There is a TODO in Appendix A and a note to insert definitions from 9052.The CDDL should include the tag definition that is the focus of this draft, something like: UCCS = .TBD601(Claims-Set) Independent of this draft, many current specs that use CDDL (including this one) repeat definitions that appear elsewhere. Perhaps it is close to time to discontinue this practice, publish an I-D or two that provide CDDL definitions for specs that predate CDDL (like RFC5911 and 5912 did for ASN.1), and then have future specs only define new things. On 1/11/23, 1:27 PM, "RATS on behalf of Henk Birkholz" on behalf of EMAIL > wrote: Dear RATS WG, this I-D should now be ready for WGLC. Viele Grüße, Henk RATS mailing list EMAIL URL

This specification allocates a CBOR tag to mark Unprotected CWT Claims Sets (UCCS) as such and discusses conditions for its proper  <ins> use in the scope of Remote Attestation Procedures (RATS RFC9334) in the usage scenario that is the conveyance of Evidence from an Attester to a Verifier. </ins> This specification does not change RFC8392: A true CWT does not make use of the tag allocated here; the UCCS tag is an alternative to 2.  <ins> Usage scenarios involving the conveyance of Claims, in particular RATS, require a standardized data definition and encoding format that can be transferred and transported using different communication channels.  As these are Claims, RFC8392 is a suitable format. However, the way these Claims are secured depends on the deployment, the security capabilities of the device, as well as their software stack.  For example, a Claim may be securely stored and conveyed using a device's Trusted Execution Environment (TEE, see I-D.ietf- teep-architecture) or a Trusted Platform Module (TPM, see TPM2). Especially in some resource constrained environments, the same process that provides the secure communication transport is also the delegate to compose the Claim to be conveyed.  Whether it is a transfer or transport, a Secure Channel is presumed to be used for conveying such UCCS.  The following sections elaborate on Secure Channel characteristics in general and further describe RATS usage scenarios and corresponding requirements for UCCS deployment. </ins> 3. the UCCS through the Secure Channel to the lead Attester.  The lead Attester then computes a cryptographic hash of the UCCS and protects that hash using its signing key for Evidence, for example, using a  <ins> Detached-Submodule-Digest or Detached EAT Bundle (I-D.ietf-rats-eat). </ins> 4.3. secchan discusses security considerations for Secure Channels, in which UCCS might be used.  This document provides the CBOR tag definition for UCCS and a discussion on security consideration for  <ins> the use of UCCS in RATS.  Uses of UCCS outside the scope of RATS are not covered by this document.  The UCCS specification - and the use of the UCCS CBOR tag, correspondingly - is not intended for use in a scope where a scope-specific security consideration discussion has not been conducted, vetted and approved for that use. </ins> 6.1.


Secure Automation and Continuous Monitoring (SACM) Architecture <del> draft-ietf-sacm-architecture-04 </del>  Abstract

Revise the document to not have a specific version number Fire off travis to get a build running.

Secure Automation and Continuous Monitoring (SACM) Architecture  <ins> draft-ietf-sacm-architecture-latest </ins> Abstract


UTF-8 RFC3629" (see RFC7049 section 2.1).  Thus both SWID and CoSWID use UTF-8 for the encoding of characters in text strings. <del> To ensure that UTF-8 character strings are able to be encodes/decoded </del>  and exchanged interoperably, text strings in CoSWID MUST be encoded consistent with the Net-Unicode definition defined in RFC5198. If the supplemental item is set to "true", the tag SHOULD contain at least one link item with both the rel(ation) item value of <del> "supplements" and an href item specifying an association with the </del>  software that is supplemented. If all of the corpus, patch, and supplemental items are "false", 5.6.1. <del> SWID or CoSWID by the referenced tag's tag-id.  This URI needs to be resolved in the context of the endpoint by software that can lookup other SWID or CoSWID tags.  For example, "swid:2df9de35-0aff- 4a86-ace6-f7dddd1ade4c" references the tag with the tag-id value "2df9de35-0aff-4a86-ace6-f7dddd1ade4c". </del> There is a need for a scheme name that can be used in URIs that point to a specific SWID/CoSWID tag by that tag's tag-id, such as the use of the link entry as described in section model-link) of this [THIS SECTION TO BE REMOVED BY THE RFC EDITOR.]  Changes from version 03 to version 11: Reduced representation complexity of the media-entry type and

Fixed typo identified by Alex Nelson. Also removed some extra working text that was accidentally left in an IANA section. This PR will be kept open until the WGLC concludes.

UTF-8 RFC3629" (see RFC7049 section 2.1).  Thus both SWID and CoSWID use UTF-8 for the encoding of characters in text strings.  <ins> To ensure that UTF-8 character strings are able to be encoded/decoded </ins> and exchanged interoperably, text strings in CoSWID MUST be encoded consistent with the Net-Unicode definition defined in RFC5198. If the supplemental item is set to "true", the tag SHOULD contain at least one link item with both the rel(ation) item value of  <ins> "supplemental" and an href item specifying an association with the </ins> software that is supplemented. If all of the corpus, patch, and supplemental items are "false", 5.6.1.  There is a need for a scheme name that can be used in URIs that point to a specific SWID/CoSWID tag by that tag's tag-id, such as the use of the link entry as described in section model-link) of this [THIS SECTION TO BE REMOVED BY THE RFC EDITOR.] <ins> Changes in version 12: Addressed a bunch of minor editorial issues based on WGLC feedback. Added text about the use of UTF-8 in CoSWID. Adjusted tag-id to allow for a UUID to be provided as a bstr. Cleaned up descriptions of index ranges throughout the document, removing discussion of 8 biut, 16 bit, etc. Adjusted discussion of private use ranges to use negative integer values and to be more clear throughout the document. Added discussion around resolving overlapping value spaces for version schemes. Added a set of expert review guidelines for new IANA registries created by this document. Added new registrations for the "swid" and "swidpath" URI schemes, and for using CoSWID with SWIMA. </ins> Changes from version 03 to version 11: Reduced representation complexity of the media-entry type and


a physical resource location with any acceptable URI scheme (e.g., file:// http:// https:// ftp://) <del> a URI with "swid:" as the scheme refers to another SWID or CoSWID by the referenced tag's tag-id.  This URI needs to be resolved in the context of the endpoint by software that can lookup other SWID or CoSWID tags.  For example, "swid:2df9de35- 0aff-4a86-ace6-f7dddd1ade4c" references the tag with the tag-id value "2df9de35-0aff-4a86-ace6-f7dddd1ade4c". a URI with "swidpath:" as the scheme, which refers to another software tag via an XPATH query W3C.REC-xpath20-20101214 that matches items in that tag (uri-scheme-swidpath).  This scheme is provided for compatibility with SWID.  This specification does not define how to resolve an XPATH query in the context of CBOR, see uri-scheme-swidpath. </del>  media (index 10): A hint to the consumer of the link to what target platform the link is applicable to.  This item represents a entries in the "Software ID Link Ownership Values" registry. rel (index 40): An integer or textual value that (integer label <del> with text escape, see data-def, for the "Software ID Link Link </del>  Relationship Values" registry indexed-link-ownership) identifies the relationship between this CoSWID and the target resource identified by the "href" item.  If an integer value is used it in the range -256 to -1 are reserved for testing and use in closed environments (see iana-private-use).  Integer values in the range 0 to 65535 correspond to registered entries in the IANA "Software <del> ID Link Relationship Values" registry (see iana-link-rel).  If a </del>  string value is used it MUST be either a private use name as defined in iana-private-use or a "Relation Name" from the IANA "Link Relation Types" registry: https://www.iana.org/assignments/ link-relations/link-relations.xhtml as defined by RFC8288.  When a <del> string value defined in the IANA "Software ID Link Relationship </del>  Values" registry matches a Relation Name defined in the IANA "Link <del> Relation Types" registry, the index value in the IANA "Software ID 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 ID Link Relationship Values" registry. </del>  media-type (index 41): A link can point to arbitrary resources on the endpoint, local network, or Internet using the href item.  Use Link/@type' in SWID. use (index 42): An integer or textual value (integer label with <del> text escape, see data-def, for the "Software ID Link Link Relationship Values" registry indexed-link-ownership) used to determine if the referenced software component has to be installed before installing the software component identified by the COSWID tag.  If an integer value is used it MUST be an index value in the range -256 to 255.  Integer values in the range -256 to -1 are reserved for testing and use in closed environments (see iana- private-use).  Integer values in the range 0 to 255 correspond to registered entries in the IANA "Link Use Values" registry (see iana-link-use).  If a string value is used it MUST be a private use name as defined in iana-private-use.  String values correspond to registered entries in the "Software ID Link Use Values" registry. </del>  $$link-extension: This CDDL socket can be used to extend the link- entry map model.  See model-extension. 5. <del> This specification defines the following URI schemes for use in </del>  CoSWID and to provide interoperability with schemes used in SWID. <del> Note: These URI schemes are used in SWID without an IANA registration.  The present specification ensures that these URI schemes are properly defined going forward. </del>  5.1. <del> There is a need for a scheme name that can be used in URIs that point to a specific software tag by that tag's tag-id, such as the use of the link entry as described in model-link.  Since this scheme is used both in a standards track document and an ISO standard, this scheme needs to be used without fear of conflicts with current or future actual schemes.  In swid-reg, the scheme "swid" is registered as a 'permanent' scheme for that purpose. URIs specifying the "swid" scheme are used to reference a software tag by its tag-id.  A tag-id referenced in this way can be used to identify the tag resource in the context of where it 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 URIs with this scheme. </del>  <del> For URIs that use the "swid" scheme, the scheme specific part MUST consist of a referenced software tag's tag-id.  This tag-id MUST be URI encoded according to RFC3986. </del>  The following expression is a valid example: 5.2. <del> There is a need for a scheme name that can be used in URIs to identify a collection of specific software tags with data elements that match an XPath expression, such as the use of the link entry as described in model-link.  The scheme named "swidpath" is used for this purpose in SWID, but not registered.  To enable usage without fear of conflicts with current or future actual schemes, the present document registers it as a 'permanent' scheme for that purpose (see swidpath-reg). URIs specifying the "swidpath" scheme are used to filter tags out of a base collection, so that matching tags are included in the </del>  identified tag collection.  The XPath expression W3C.REC- xpath20-20101214 references the data that must be found in a given software tag out of base collection for that tag to be considered a matching tag.  Tags to be evaluated (the base collection) include all <del> 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. </del>  For URIs that use the "swidpath" scheme, the following requirements apply: 6.6. <del> The ISO 19770-2:2015 SWID specification describes use of the "swid" and "swidpath" URI schemes, which are currently in use in implementations.  This document continues this use for CoSWID.  The following subsections provide registrations for these schemes in to ensure that a permanent registration exists for these schemes that is suitable for use in the SWID and CoSWID specifications. URI schemes are registered within the "Uniform Resource Identifier (URI) Schemes" registry maintained at IANA.uri-schemes. 6.6.1. IANA is requested to register the URI scheme "swid".  This registration request complies with RFC7595. 6.6.2. IANA is requested to register the URI scheme "swidpath".  This registration request complies with RFC7595. 6.7. </del> The Software Inventory Message and Attributes (SWIMA) for PA-TNC specification RFC8412 defines a standardized method for collecting an endpoint device's software inventory.  A CoSWID can provide evidence [THIS SECTION TO BE REMOVED BY THE RFC EDITOR.]  Changes from version 12 to version 14: Moved key identifier to protected COSE header

Removed IANA registrations for swid and swidpath and updated text to note these are not technically URIs but just expressions using URI syntax.

a physical resource location with any acceptable URI scheme (e.g., file:// http:// https:// ftp://)  <ins> a URI-like expression with "swid:" as the scheme refers to another SWID or CoSWID by the referenced tag's tag-id.  This expression needs to be resolved in the context of the endpoint by software that can lookup other SWID or CoSWID tags.  For example, "swid:2df9de35-0aff-4a86-ace6-f7dddd1ade4c" references the tag with the tag-id value "2df9de35-0aff- 4a86-ace6-f7dddd1ade4c". a URI-like expression with "swidpath:" as the scheme, which refers to another software tag via an XPATH query W3C.REC- xpath20-20101214 that matches items in that tag (uri-scheme- swidpath).  This scheme is provided for compatibility with SWID.  This specification does not define how to resolve an XPATH query in the context of CBOR, see uri-scheme-swidpath. </ins> media (index 10): A hint to the consumer of the link to what target platform the link is applicable to.  This item represents a entries in the "Software ID Link Ownership Values" registry. rel (index 40): An integer or textual value that (integer label  <ins> with text escape, see data-def, for the "Software Tag Link </ins> Relationship Values" registry indexed-link-ownership) identifies the relationship between this CoSWID and the target resource identified by the "href" item.  If an integer value is used it in the range -256 to -1 are reserved for testing and use in closed environments (see iana-private-use).  Integer values in the range 0 to 65535 correspond to registered entries in the IANA "Software  <ins> Tag Link Relationship Values" registry (see iana-link-rel.  If a </ins> string value is used it MUST be either a private use name as defined in iana-private-use or a "Relation Name" from the IANA "Link Relation Types" registry: https://www.iana.org/assignments/ link-relations/link-relations.xhtml as defined by RFC8288.  When a  <ins> string value defined in the IANA "Software Tag Link Relationship </ins> Values" registry matches a Relation Name defined in the IANA "Link  <ins> 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. </ins> media-type (index 41): A link can point to arbitrary resources on the endpoint, local network, or Internet using the href item.  Use Link/@type' in SWID. use (index 42): An integer or textual value (integer label with  <ins> text escape, see data-def, for the "Software Tag Link Relationship Values" registry indexed-link-ownership) used to determine if the referenced software component has to be installed before installing the software component identified by the COSWID tag. If an integer value is used it MUST be an index value in the range -256 to 255.  Integer values in the range -256 to -1 are reserved for testing and use in closed environments (see iana-private-use). Integer values in the range 0 to 255 correspond to registered entries in the IANA "Link Use Values" registry (see iana-link-use. If a string value is used it MUST be a private use name as defined in iana-private-use.  String values correspond to registered entries in the "Software Tag Link Use Values" registry. </ins> $$link-extension: This CDDL socket can be used to extend the link- entry map model.  See model-extension. 5.  <ins> This specification defines the following expressions for use in </ins> CoSWID and to provide interoperability with schemes used in SWID.  <ins> Because both the "swid" and "swidpath" schemes are to be interpreted within a local, rather than a global, context, neither of these scheme are URIs as defined in RFC3986 and the swid and swidpath scheme names are not registered as permanent schemes with IANA.  That noted, swid and swidpath expressions conform to all rules for URI syntax.  All uses of these expressions encountered within a CoSWID are to be interpreted as described in this section. </ins> 5.1.  <ins> Expressions specifying the "swid" scheme are used to reference a software tag by its tag-id.  A tag-id referenced in this way can be used to identify the tag resource in the context of where it 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 expressions with this scheme. </ins>  <ins> For expressions that use the "swid" scheme, the scheme specific part MUST consist of a referenced software tag's tag-id.  This tag-id MUST be URI encoded according to RFC3986 Section 2.1. </ins> The following expression is a valid example: 5.2.  <ins> Expressions specifying the "swidpath" scheme are used to filter tags out of a base collection, so that matching tags are included in the </ins> identified tag collection.  The XPath expression W3C.REC- xpath20-20101214 references the data that must be found in a given software tag out of base collection for that tag to be considered a matching tag.  Tags to be evaluated (the base collection) include all  <ins> tags in the context of where the swidpath expression 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 an expression with this scheme. </ins> For URIs that use the "swidpath" scheme, the following requirements apply: 6.6.  The Software Inventory Message and Attributes (SWIMA) for PA-TNC specification RFC8412 defines a standardized method for collecting an endpoint device's software inventory.  A CoSWID can provide evidence [THIS SECTION TO BE REMOVED BY THE RFC EDITOR.] <ins> Changes from version 22 to version 23 Removed request for IANA registration of swid and swidpath as URI schemes.  Updated text to note that that these are not URIs but expressions that follow URI syntax </ins> Changes from version 12 to version 14: Moved key identifier to protected COSE header


5. <del> This specification defines the following expressions for use in CoSWID and to provide interoperability with schemes used in SWID. Because both the "swid" and "swidpath" schemes are to be interpreted within a local, rather than a global, context, neither of these scheme are URIs as defined in RFC3986 and the swid and swidpath scheme names are not registered as permanent schemes with IANA.  That noted, swid and swidpath expressions conform to all rules for URI </del>  syntax.  All uses of these expressions encountered within a CoSWID are to be interpreted as described in this section. 6.6.  The Software Inventory Message and Attributes (SWIMA) for PA-TNC specification RFC8412 defines a standardized method for collecting an endpoint device's software inventory.  A CoSWID can provide evidence

Added back IANA registrations (as provisional) for swid and swidpath URI schemes. Slight re-wording of the intro paragraph to section 5 (discussing the schemes) to reflect this modification.

5.  <ins> This specification defines the following scheme names for use in CoSWID and to provide interoperability with scheme names used in SWID.  Because both the "swid" and "swidpath" scheme names are to be interpreted within a local (rather than a global) context, neither of these are technically URI scheme names as defined in RFC3986.  For this reason, the swid and swidpath scheme names are registered with IANA as provisional, rather than permanent, scheme names.  However, registering these scheme names as provisional ensures that the scheme names are reserved and that they are properly defined going forward. The swid and swidpath expressions conform to all rules for URI </ins> syntax.  All uses of these expressions encountered within a CoSWID are to be interpreted as described in this section. 6.6. <ins> The ISO 19770-2:2015 SWID specification describes use of the "swid" and "swidpath" URI schemes, which are currently in use in implementations.  This document continues this use for CoSWID.  The following subsections provide registrations for these schemes in to ensure that a registration exists for these schemes that is suitable for use in the SWID and CoSWID specifications.  URI schemes are registered within the "Uniform Resource Identifier (URI) Schemes" registry maintained at IANA.uri-schemes. 6.6.1. IANA is requested to register the URI scheme "swid".  This registration request complies with RFC7595. 6.6.2. IANA is requested to register the URI scheme "swidpath".  This registration request complies with RFC7595. 6.7. </ins> The Software Inventory Message and Attributes (SWIMA) for PA-TNC specification RFC8412 defines a standardized method for collecting an endpoint device's software inventory.  A CoSWID can provide evidence


cases.  Also, this document uses terminology defined in I-D.ietf- sacm-terminology.  2. This document defines requirements based on the SACM use cases models must adhere to and comply with the SACM information model. The requirements for the SACM information model include: <del> Extensible Attribute Vocabulary: the information model MUST define </del>  a minimum set of attributes for communicating Posture Information, to ensure interoperability between data models.  (Individual data models may define attributes beyond the mandatory-to-implement structure, and the ability to search based on patterns ("wildcard searches") as well as specific data elements. <del> Full Vs.  Partial Updates: The data model SHOULD include the </del>  ability to allow providers of data to provide the data as a whole, or when updates occur.  For example, a consumer can request a full update on initial engagement, then request to receive deltas Either or both confidentiality and integrity at the data layer.  5. 5.1.

Updates to address 3 of four open issues
Version -09 The document is not consistent if the character following the pithy title is capitalized. A pass needs to be made to fix this.
Hi Jim, I only found 1 straggler in IM-URL there are others please let me know so I can fold it into the -10 draft. Thanks, Nancy
Fixed in Pull request
-version 09 There are two nits that needs to be resolved. Missing 2119 boilerplate Reference to RFC 3444 exists, but is not referred to.
Hi Jim, Will fix in -10 draft..... Thanks, Nancy
Fixed in Pull request

cases.  Also, this document uses terminology defined in I-D.ietf- sacm-terminology. <ins> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. When the words appear in lower case, their natural language meaning is used. </ins> 2. This document defines requirements based on the SACM use cases models must adhere to and comply with the SACM information model. The requirements for the SACM information model include:  <ins> Extensible Attribute Vocabulary: The information model MUST define </ins> a minimum set of attributes for communicating Posture Information, to ensure interoperability between data models.  (Individual data models may define attributes beyond the mandatory-to-implement structure, and the ability to search based on patterns ("wildcard searches") as well as specific data elements.  <ins> Full vs. Partial Updates: The data model SHOULD include the </ins> ability to allow providers of data to provide the data as a whole, or when updates occur.  For example, a consumer can request a full update on initial engagement, then request to receive deltas Either or both confidentiality and integrity at the data layer. <ins> 4.2. SACM information may contain sensitive information about the target endpoint as well as revealing identity information of the producer or consumer of such information.  Similarly, as part of the SACM discovery mechanism, the advertised capabilities (and roles, e.g. SACM components enabled) by the endpoint may be construed as private information.  There may be applications as well as business and regulatory practicess that require that aspects of such information be hidden from any parties that do not need to know it. Data confidentiality can provide some level of privacy but may fall short where unecessary data is still transmitted.  In those cases, filtering requirements at the data model such as OP-005 must be applied to ensure that such data is not disclosed.  RFC6973 provides guidelines for which SACM protocols and information and data models should follow. </ins> 5. 5.1.


specific provider, and a provider can publish information without having a specific consumer targeted to receive it. <del> Provider Identification: The interfaces and actions in the data model MUST include the ability to identify data from a specific provider.  For example, a SACM consumer should be able to request all data to come from a specific provider (e.g.  Provider A) as there can be a larger set of providers. </del> Data Cardinality: The data model MUST describe their constraints (e.g. cardinality).  As posture information and the tasks for collection, aggregation, or evaluation, could comprise one or more components SHOULD have interfaces defined to transmit this data directly or to refer to where the information can be retrieved.  2.6. The term transport protocol is frequently overloaded.  The term SACM

Change the location of DM-006 to OPS and make some new text for it.
Do you have any text to suggest?
Sorry. I see has text.
I like the change but my only suggestion is to capitalize "Consumer" and "Provider" to make it clearer that these are the SACM components.
Version -09 I am not sure what this statement is actually trying to say. I first read it as referring to a Data Origin source, but then realized that this could refer to a provider in the architecture sense. This should probably be clarified.
Hi Jim, The intent is to have the endpoint acting an instance of a SACM Provider's identity be specified. Would the following be more clear (as a replacement to the 1st sentence): The data model MUST include the ability to provide the identity of the SACM Provider. Thanks, Nancy
That does not seem to say the same thing as the current sentence. I think what you want to say is closer to: The interfaces and actions in the data model MUST include the ability to identify data published by a specific provider. I used published because I don't know if there is a better SACM verb. What I mean by it is "data collected, processed or assessed". That is data that originated with that provider as oppose to data which it received from elsewhere and relayed on.
Hi Jim, I think it is the distinction is that when the data is provided, in that encapsulation there must be a means to specify the provider of that URL is what I was striving for.....I interpret the "identify data published by a specific provider" as potentially being a separate interface as well?
Getting back into the flow of things again. This seems to me to be better stated as an operation requirement than as a data model requirement. The query would say - only get the data from provider X. However it is not clear that I would model this as part of the data when I am doing processing on it. I would not necessary expect to keep this as part of my internal data structures. Data source is already provided as DM-0012 so that would not need to be duplicated here. I would suggest OP-XXXX Provider Restriction: Request operations MUST include the ability to restrict the data to be provided by a specific provider or a provider with specific characteristics. Response operations MUST include the ability to identify the provider that supplied the response. For example, a SACM consumer should be able to request that all of the data come from a specific provider by identity (e.g. Provider A) or from a provider that is in a specific location (e.g. in the Boston office).
Hi Jim, I have the suggested text now in the merged branch and will fold it into rev -12

specific provider, and a provider can publish information without having a specific consumer targeted to receive it.  Data Cardinality: The data model MUST describe their constraints (e.g. cardinality).  As posture information and the tasks for collection, aggregation, or evaluation, could comprise one or more components SHOULD have interfaces defined to transmit this data directly or to refer to where the information can be retrieved. <ins> Provider Restriction: Request operations MUST include the ability to restrict the data to be provided by a specific provider or a provider with specific characteristics.  Response operations MUST include the ability to identify the provider that supplied the response.  For example, a SACM Consumer should be able to request that all of the data come from a specific provider by identity (e.g.  Provider A) or from a Provider that is in a specific location (e.g. in the Boston office). </ins> 2.6. The term transport protocol is frequently overloaded.  The term SACM


Secure Automation and Continuous Monitoring (SACM) Terminology <del> draft-ietf-sacm-terminology-07 </del>  Abstract

A couple of bookkeeping changes: Fix a format error in the readme Make the date be the date it was generated rather than a fixed date Change the document title to be more generic as it does not match the published numbered version on the IETF website.

Secure Automation and Continuous Monitoring (SACM) Terminology  <ins> draft-ietf-sacm-terminology-latest </ins> Abstract


results.  Types, classes or the characteristics of an individual target endpoint are defined via endpoint profiles.  The task by which endpoint attributes are evaluated. The resulting value from having evaluated a set of posture general, it cannot be simply assumed that the source of time a target endpoint uses is synchronized or trustworthy.  3. This memo includes no request to IANA.

added terms from the vulnerability assessment scenario
Hi Danny, I still want to highlight one last time that we will have 3-4 different kinds of capability in the terminology in -10 if we pull this in. I understand this to be a basis of discussion still :) I am not sure if that is the case, though! Let me elaborate. We have in SACM used by the architecture: Capability: : The extent of an SACM component's ability enabled by the functions it is composed of. Capabilities are propagated by a SACM component and can be discovered by or negotiated with other SACM components. For example, the capability of a SACM Provider may be to provide endpoint management data, or only a subset of that data. We have in i2nsf, referenced in the sacm terminology: We have the VA Terms: +Endpoint management capability: +: An enterprise IT capability managing endpoint identity, endpoint information, and associated metadata on an ongoing basis. +Vulnerability management capability: +: An enterprise IT capability managing endpoint vulnerabilities and associated metadata on an ongoing basis by ingesting vulnerability description information and vulnerability detection data, and performing a vulnerability assessment. "Managed" in i2nsf means "has interface on the management-plane". I still do not understand what managing actually means in the context of an VA capability :) What potential functions are propagated as capabilities? What is their input? What is their output? Is it possible that the two VA capabilities are actually tasks? Viele Grüße, Henk TL;DR I will pull these terms in, but we will have to align these terms better. On 07/08/2016 01:56 PM, Danny Haynes wrote:

results.  Types, classes or the characteristics of an individual target endpoint are defined via endpoint profiles. <ins> An enterprise IT capability managing endpoint identity, endpoint information, and associated metadata on an ongoing basis. </ins> The task by which endpoint attributes are evaluated. The resulting value from having evaluated a set of posture general, it cannot be simply assumed that the source of time a target endpoint uses is synchronized or trustworthy. <ins> Information pertaining to the existence of a flaw or flaws in software, hardware, and/or firmware, which could potentially have an adverse impact on enterprise IT functionality and/or security. Vulnerability description information should contain enough information to support vulnerability detection. A type of guidance extracted from vulnerability description information that describes the specific mechanisms of vulnerability detection that is used by an enterprise's vulnerability management capability to determine if a vulnerability is present on an endpoint. An enterprise IT capability managing endpoint vulnerabilities and associated metadata on an ongoing basis by ingesting vulnerability description information and vulnerability detection data, and performing a vulnerability assessment. The process of determining whether a set of endpoints is vulnerable according to the information contained in the vulnerability description information. </ins> 3. This memo includes no request to IANA.


Each distinct instant in time can be represented in a descriptive text format using a timestamp, and ISO8601 standardizes a widely- adopted timestamp format, which forms the basis of RFC3339.  However, <del> this format doesn't allow timestamps to contain any additional relevant information, which means that any contextual information related to a given timestamp needs to be either handled separately or attached to it in a non-standard manner. </del>  This is already a pressing issue for applications that handle each instant with an associated time zone name, to take into account timezone to the timestamp in a non-standard format, at least one of which is fairly well-adopted JAVAZDT.  Furthermore, applications might want to attach even more information to the timestamp, <del> including but not limited to the calendar system it must be </del>  represented in. This document defines an extension syntax for timestamps as specified The extension suffix is completely optional, making existing RFC3339 timestamps compatible with this format. <del> The format is compatible to the pre-existing popular syntax for </del>  attaching time zone names to timestamps (JAVAZDT). <del> The format provides generalized way to attach any additional </del>  information to the timestamp. 2. BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <del> For more information about time scales, see Appendix E of RFC1305, Section 3 of ISO8601, and the appropriate ITU documents ITURTF460-6. </del>  3. The format should allow implementations to specify additional important information in addition to the bare timestamp.  This is <del> done by allowing implementations to include an informative suffix at the end with as many tags as required, each with a key and value separated by an equals sign.  The value can be a hyphen delimited list of multiple values. </del>  In case a key is repeated or conflicted, implementations MUST give precedence to whichever value is positioned first. 3.2. <del> Since the suffix can include all sorts of additional information, different standards bodies/organizations need a way to identify which part adheres to their standards.  For this, all information needs to be namespaced.  Each key is therefore divided into two hyphen- separated sections: the namespace and the key.  For example, the calendar as defined by the Unicode consortium could be included as </del>  "u-ca=<value>". All single-character namespaces are reserved for BCP47 extensions A "suffix-value" is limited to "3*8alphanum".  Multi-character namespaces can be registered specifically for use in <del> this format.  They are assigned by IANA using the "IETF Review" policy defined by RFC8126.  This policy requires the development of an RFC, which SHALL define the name, purpose, processes, and procedures for maintaining the subtags.  The maintaining or registering authority, including name, contact email, discussion list email, and URL location of the registry, MUST be indicated clearly in the RFC.  The RFC MUST specify or include each of the following: </del>  The specification MUST reference the specific version or revision of this document that governs its creation and MUST reference this IANA will maintain a registry of allocated multi-character namespaces.  This registry MUST use the record-jar format described <del> by the ABNF in RFC5646.  Upon publication of a namespace as an RFC, the maintaining authority defined in the RFC MUST forward this </del>  registration form to <<mailto:iesg@ietf.org>>, who MUST forward the request to <<mailto:iana@iana.org>>.  The maintaining authority of the namespace MUST maintain the accuracy of the record by sending an solely with the IESG and is subject to the normal review and appeals process associated with the RFC process. <del> 3.3. </del>  The following rules extend the ABNF syntax defined in RFC3339 in <del> order to allow the inclusion of an optional suffix. </del>  <del> 3.4. </del>  Here are some examples of Internet extended date/time format. <del> This represents 39 minutes and 57 seconds after the 16th hour of December 19th, 1996 with an offset of -08:00 from UTC.  Note that this is equivalent to 1996-12-20T00:39:57Z in UTC. </del>  <del> This represents the exact same instant as the previous example but additionally specifies the human time zone associated with it ("Pacific Time") for time-zone-aware implementations to take into account. </del>  <del> This represents the exact same instant but it informs calendar-aware implementations that they should project it to the Hebrew calendar. </del>  <del> This timestamp utilizes the private use namespace to declare two additional pieces of information in the suffix that can be interpreted by any compatible implementations and ignored otherwise. </del>

I looked through the inline comments as well. Should we file issues for all of these?
I think we should have a quick check if we can resolve any of these between us, and then make issues. Grüße, Carsten
(Many of the comments are really editorial. E.g., if you have a “BCP47 extensions registry” in mind, we can simply point to that; I just couldn’t find that.) I think I’ll submit the -01 now anyway, so we do have a new version to look at for the interim. Grüße, Carsten
Perfect, thanks. I'll try to see how many of the comments can be trivially resolved.
Please confirm -01; we can submit a -02 quickly after that (I-D deadline 2021-10-25!).
-01 is published o/
Perfect, thanks for the changes! They look great, and I apologize for the issues especially with the references, Metanorma was not making my life any easier.

Each distinct instant in time can be represented in a descriptive text format using a timestamp, and ISO8601 standardizes a widely- adopted timestamp format, which forms the basis of RFC3339.  However,  <ins> this format only allows timestamps to contain very little additional relevant information, which means that, beyond that, any contextual information related to a given timestamp needs to be either handled separately or attached to it in a non-standard manner. </ins> This is already a pressing issue for applications that handle each instant with an associated time zone name, to take into account timezone to the timestamp in a non-standard format, at least one of which is fairly well-adopted JAVAZDT.  Furthermore, applications might want to attach even more information to the timestamp,  <ins> including but not limited to the calendar system it needs to be </ins> represented in. This document defines an extension syntax for timestamps as specified The extension suffix is completely optional, making existing RFC3339 timestamps compatible with this format.  <ins> The format is compatible with the pre-existing popular syntax for </ins> attaching time zone names to timestamps (JAVAZDT).  <ins> The format provides a generalized way to attach any additional </ins> information to the timestamp. 2. BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here.  <ins> For more information about time scales, see RFC1305, Section 3 of ISO8601, and the appropriate ITU documents ITU-R-TF.460-6. </ins> 3. The format should allow implementations to specify additional important information in addition to the bare timestamp.  This is  <ins> done by defining , each with a and a separated by an equals sign, and allowing implementations to include an informative at the end with as many tags as required.  The value of a tag can be a hyphen delimited list of multiple values. </ins> In case a key is repeated or conflicted, implementations MUST give precedence to whichever value is positioned first. 3.2.  <ins> Since tags can include all sorts of additional information, different standards bodies/organizations need a way to identify which part adheres to their standards.  For this, all information needs to be namespaced.  Each key is therefore divided into two hyphen-separated sections: the namespace and the key.  For example, the calendar as defined by the Unicode consortium could be included as </ins> "u-ca=<value>". All single-character namespaces are reserved for BCP47 extensions A "suffix-value" is limited to "3*8alphanum". <ins> 3.3. </ins> Multi-character namespaces can be registered specifically for use in  <ins> this format, see iana-cons.  The registration policy requires the development of an RFC, which SHALL define the name, purpose, processes, and procedures for maintaining the tags using the namespace registered. (This subsection uses BCP 14 language to describe the requirements on the information interchanged indirectly by providing requirements on the RFC registering a namespace and the principles of its evolution.) The maintaining or registering authority, including name, contact email, discussion list email, and URL location of the registry, MUST be indicated clearly in the RFC.  The RFC MUST specify each of the following (directly or included by reference): </ins> The specification MUST reference the specific version or revision of this document that governs its creation and MUST reference this IANA will maintain a registry of allocated multi-character namespaces.  This registry MUST use the record-jar format described  <ins> by the ABNF in BCP47.  Upon publication of a namespace as an RFC, the maintaining authority defined in the RFC MUST forward this </ins> registration form to <<mailto:iesg@ietf.org>>, who MUST forward the request to <<mailto:iana@iana.org>>.  The maintaining authority of the namespace MUST maintain the accuracy of the record by sending an solely with the IESG and is subject to the normal review and appeals process associated with the RFC process.  <ins> 3.4. </ins> The following rules extend the ABNF syntax defined in RFC3339 in  <ins> order to allow the inclusion of an optional suffix: the extended date/time format is described by the rule "date-time-ext". </ins>  <ins> 3.5. </ins> Here are some examples of Internet extended date/time format.  <ins> rfc3339-datetime represents 39 minutes and 57 seconds after the 16th hour of December 19th, 1996 with an offset of -08:00 from UTC.  Note that this is the same instant in time as "1996-12-20T00:39:57Z", expressed in UTC. datetime-tzname represents the exact same instant as the previous example but additionally specifies the human time zone associated with it ("Pacific Time") for time-zone-aware implementations to take into account. date-time-hebrew represents the exact same instant but it informs calendar-aware implementations that they should project it to the Hebrew calendar. date-time-private, based on rfc3339-datetime, utilizes the private use namespace to declare two additional pieces of information in the suffix that can be interpreted by any compatible implementations and ignored otherwise. 4. </ins>  <ins> Multi-character namespaces are assigned by IANA using the "IETF Review" policy defined by RFC8126; the IETF review process needs to be based on the requirements laid out in multi-char. </ins>  <ins> 5. </ins>  <ins> TBD </ins>


including but not limited to the calendar system it needs to be represented in.  This document defines an extension syntax for timestamps as specified in RFC3339 that has the following properties: The format provides a generalized way to attach any additional information to the timestamp. <del> 2. </del>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and For more information about time scales, see RFC1305, Section 3 of ISO8601, and the appropriate ITU documents ITU-R-TF.460-6. <del> 3. </del>  This section discusses desirable qualities of formats for the timestamp extension suffix and defines such a format that extends RFC3339 for use in Internet protocols. <del> 3.1. </del>  The format should allow implementations to specify additional important information in addition to the bare timestamp.  This is In case a key is repeated or conflicted, implementations MUST give precedence to whichever value is positioned first. <del> 3.2. </del>  Since tags can include all sorts of additional information, different standards bodies/organizations need a way to identify which part A "suffix-value" is limited to "3*8alphanum". <del> 3.3. </del>  Multi-character namespaces can be registered specifically for use in this format, see iana-cons.  The registration policy requires the solely with the IESG and is subject to the normal review and appeals process associated with the RFC process. <del> 3.4. </del>  The following rules extend the ABNF syntax defined in RFC3339 in order to allow the inclusion of an optional suffix: the extended date/time format is described by the rule "date-time-ext". <del> 3.5. </del>  Here are some examples of Internet extended date/time format. suffix that can be interpreted by any compatible implementations and ignored otherwise. <del> 4. </del>  Multi-character namespaces are assigned by IANA using the "IETF Review" policy defined by RFC8126; the IETF review process needs to be based on the requirements laid out in multi-char. <del> 5. </del>  TBD

The current draft does not say what it actually means when a timezone name is added to a timestamp. Is the combination of the timezone name and the timezone offset an assertion that the offset was correct for the named timezone at the time? What if that assertion is not true? What about future times? Does the timezone name take precedence over the offset given (i.e., the timestamp changes its meaning with political decisions) or does the offset win?
(From the SEDATE meeting: "encode the intention"?)
(From the SEDATE meeting: "don't encode the timezone if that is not the overriding information".) One use case is documenting the time zone name, though.
We now have a clarified scope ( as published in -02). This makes the underlying issue out of scope -- the RFC 3339 semantics prevail. Discuss.
essentially is the continuation of this issue with a revised question. The resolution of the question in this PR remains in place.
As a description of one path forward, this is good - and it's sufficient for the proposal that I made. Good threading of the potential needle here.

including but not limited to the calendar system it needs to be represented in. <ins> 1.1. </ins> This document defines an extension syntax for timestamps as specified in RFC3339 that has the following properties: The format provides a generalized way to attach any additional information to the timestamp.  <ins> This document does not address extensions to the format where the semantic result no longer is a fixed timestamp that is referenced to a (past or future) UTC time.  For instance, it does not address: Future time given as a local time in some specified time zone, where changes to the definition of that time zone (e.g., a political decision to enact or rescind daylight savings time) changes the actual time in UTC time. Time given as a "floating time", i.e., a local time without information as to which time zone this local time refers to. The use of time scales different from UTC, such as TAI. However, the additional information provided that augments a fixed timestamp may be sufficient to detect an inconsistency between intention and the actual information given in the timestamp, e.g., between the additional timezone information given and the timezone offset recorded in the timestamp.  For instance, such an inconsistency might arise because of: Political decisions as discussed above, or errors in the applications producing and consuming such a timestamp. While the information available is not generally sufficient to resolve the inconsistency, it may be used to initiate some out of band processing to obtain sufficient information for such a resolution. In order to address some of the requirements implied here, future related specifications might define syntax and semantics of strings similar to RFC3339.  Note that the extension syntax defined in the present document is designed in such a way that it can be useful for such specifications as well. 1.2. </ins> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and For more information about time scales, see RFC1305, Section 3 of ISO8601, and the appropriate ITU documents ITU-R-TF.460-6.  <ins> 2. </ins> This section discusses desirable qualities of formats for the timestamp extension suffix and defines such a format that extends RFC3339 for use in Internet protocols.  <ins> 2.1. </ins> The format should allow implementations to specify additional important information in addition to the bare timestamp.  This is In case a key is repeated or conflicted, implementations MUST give precedence to whichever value is positioned first.  <ins> 2.2. </ins> Since tags can include all sorts of additional information, different standards bodies/organizations need a way to identify which part A "suffix-value" is limited to "3*8alphanum".  <ins> 2.3. </ins> Multi-character namespaces can be registered specifically for use in this format, see iana-cons.  The registration policy requires the solely with the IESG and is subject to the normal review and appeals process associated with the RFC process.  <ins> 2.4. </ins> The following rules extend the ABNF syntax defined in RFC3339 in order to allow the inclusion of an optional suffix: the extended date/time format is described by the rule "date-time-ext".  <ins> 2.5. </ins> Here are some examples of Internet extended date/time format. suffix that can be interpreted by any compatible implementations and ignored otherwise.  <ins> 3. </ins> Multi-character namespaces are assigned by IANA using the "IETF Review" policy defined by RFC8126; the IETF review process needs to be based on the requirements laid out in multi-char.  <ins> 4. </ins> TBD


information to the timestamp. This document does not address extensions to the format where the <del> semantic result no longer is a fixed timestamp that is referenced to </del>  a (past or future) UTC time.  For instance, it does not address: Future time given as a local time in some specified time zone, Actual keys are registered by supplying the information in record: <del> 'Identifier' contains the key name. </del>  'Description' contains the name and description of the namespace. 4. <del> Define a registry that can contain both namespaces and keys. Namespaces can be recognized by ending with a hyphen/minus.  Actual keys do not.  See registered for the detailed information (to be edited). </del>  The policy is "RFC required", "Specification Required", ??? RFC8126.

Replace "DST" and "daylight savings time" with "daylight saving time" Replace "timezone" with "time zone" Properly capitalize "Unicode Consortium" Improve phrasing
If you don't have time to work further on this very useful PR, I could merge it and fix these three nits.
Please don't add material to this one. We went the opposite direction in the last interim, so I'm about to remove some of this text.
OK, I pushed a commit just before your last comment but will withhold any further changes.
Sorry for the unsmooth handling of this PR. I now cherry-picked from this PR. Can I ask you to rebase to main and see what remaining parts you want to pursue?
My last message was too close to the holidays. Do you want to rebase this PR? Or do you think it is essentially covered by my cherry-picking?
Thanks for the ping, NAME Almost everything was covered by the cherry-picking, but a few things remain. I have rebased the PR to include only those.

information to the timestamp. This document does not address extensions to the format where the  <ins> semantic result is no longer a fixed timestamp that is referenced to </ins> a (past or future) UTC time.  For instance, it does not address: Future time given as a local time in some specified time zone, Actual keys are registered by supplying the information in record:  <ins> 'Identifier' contains the key name.  A key name ending with a hyphen/ minus sign ""-"" is a namespace that covers all timestamp tag keys beginning with that prefix. </ins> 'Description' contains the name and description of the namespace. 4.  <ins> IANA is requested to establish a registry called "Timestamp Suffix Tag Keys".  Each entry in the registry shall consist of the information described in registered.  Initial contents of the registry are specified in namespaced. </ins> The policy is "RFC required", "Specification Required", ??? RFC8126.


BCP178 for a discussion about the danger of experimental keys leaking out to general production and why that MUST be prevented.  3. 3.1.

(Elective, ignore option if not understood) (Critical, must understand/must reject date if not understood)
It's possible for a timestamp's offset to conflict with the timezone extension. Usually this is caused by a programmer bug where the wrong offset or the wrong timezone was put in the string. However, in rare cases changes to TZDB rules can cause a conflict. Assume was stored by a program running in 2018 using TZDB rules in effect that time. But after Brazil's time zone rules were changed in April 2019, the correct offset for that point in time is now . How should the SEDATE standard deal with conflicts like this? UPDATE 2022-03-21: Our (Temporal team's) understanding is that the WG wants the new standard to be a strict superset of RFC 3339, which implies that the timestamp should be considered a higher priority than the bracketed time zone extension. Using the Brazil example above, a timezone-aware implementation using the current TZDB should interpret (now the wrong offset) as the same timestamp but a different local time: . If this understanding is correct, then here's strawman text for discussion: Our assumption is that a later standard (maybe the same one that will standardize floating times?) may provide a way to encode a different conflict-resolution preference into timestamp strings. Note that the offset exception is needed because, as noted in , many applications (and libraries like URL) use to mean "I don't know the local offset". ORIGINAL CONTENT (LONG) Here's how Temporal handles conflicts like this in our current API design: A "conflict" means that the date and time shown in the timestamp is not valid for the time zone in brackets, according to the TZDB rules that the parsing program is using. If there's a conflict, by default an exception is thrown when parsing. The offset will never cause a conflict, because Temporal interprets as a "null time zone" that is not asserting anything about the local date or local time in a real place on earth. Therefore, the bracketed time zone will take precedence if a offset is used. Callers can optionally override the behaviors above by calling the parsing function using an optional parameter that controls parsing behavior: will make the offset win, will make the bracketed extension win, and is the default behavior. We'd prefer the standardized behavior to be compatible with the current Temporal implementation described above. But if we must make a change, then we'd be OK to change the default behavior from "throw an exception in case of conflict" to "non-Z offsets always win". We think that "throw on conflict" is the best default behavior because it helps the developer detect conflicts which would otherwise go unnoticed by the 99% of developers who'll never anticipate possible conflicts. But we also acknowledge valid arguments in favor of an "offset wins by default" behavior. We WOULD NOT be OK with a behavior that always rejects Z offsets with bracketed time zones, because that would prevent creating strings where the original local date/time is unknown. This "don't know the offset" limitation is very common for timestamps stored in a relational database and other systems that only store a "time since epoch" value without an offset. In those cases, there's no clear alternative to using a Z offset in the string. We WOULD NOT be OK with a change that prevented Temporal from providing callers with an option (see (4) above) to override the default conflict-resolution behavior. The ability for callers to have an opt-in way to decide conflict resolution behavior is important because, as discussed above in the Brazil example, in rare cases valid strings will later become conflicting. In many cases, it's not practical for these previously-stored strings to be updated. (For example, they may be stored in a database owned by someone else.) So programmers need to have a way to deal with those kinds of strings if they receive them.
NAME and I discussed this issue tonight in context of recent discussions on the WG, and I just updated the OP to simplify and and clarify Temporal's requests to align with the latest WG discussions. Apologies for late-breaking updates, but hopefully it should simplify the discussion in the real-time meeting.
(see also discussion under )
While most of this is covered by the new Section 2, we could discuss what is remaining under . RFC 3339 says that the offset -00:00 should be used when the local offset is unknown. . Unknown Local Offset Convention If the time in UTC is known, but the offset to local time is unknown, this can be represented with an offset of "-00:00". This differs semantically from an offset of "Z" or "+00:00", which imply that UTC is the preferred reference point for the specified time. RFC2822 [IMAIL-UPDATE ] describes a similar convention for email. However, my understanding is that many (most? almost all?) applications and libraries ignore the standard's advice and instead use Z, not -00:00, when the local offset is unknown. For example, URL uses Z even though it does not know the local offset because its data model is only a single time-since-epoch value. Example: import URL; class Main { public static void main(String[] args) { Instant instant = URL("2017-06-16T21:25:37.258Z"); URL(instant.toString()); // => 2017-06-16T21:25:37.258Z } } Is my assumption correct that most applications use Z when -00:00 would be more correct according to the standard? If so, do you know why -00:00 never became popular? Cheers, Justin

BCP178 for a discussion about the danger of experimental keys leaking out to general production and why that MUST be prevented. <ins> 2.3. For the format defined here, suffix tags are always : They can be added or left out as desired by the generator of the string in Internet Date/Time Format.  (An application might require the presence of specific suffix tags, though.) Without further indication, they are also : Even if included in the Internet Date/Time Format string, the recipient is free to ignore the suffix tag.  Reasons might include that the recipient does not implement (or know about) the specific suffix key, or that it does recognize the key but cannot act on the value provided. A suffix tag may also indicate that it is : The recipient is advised that it MUST not act on the Internet Date/ Time Format string unless it can process the suffix tag as specified. A critical suffix tag is indicated by following its opening bracket with an exclamation mark (see "critical-flag" in abnf). Internet Date/Time Format strings such as: are internally inconsistent, as Europe/Paris does not use a time zone offset of 0 (which is indicated in the "Z", an abbreviation for "+00:00"), nor a time zone offset of "+01:00" in July 2022.  The time zone hint given in the suffix tag is elective, though, so the recipient is not required to act on the inconsistency; it can treat the Internet Date/Time Format string as if it were: Similar with: However, all have an internal inconsistency or an unrecognized suffix key/ value, so a recipient MUST treat the Internet Date/Time Format string as erroneous. Note that this does not mean that an application is disallowed to perform additional processing on elective suffix tags, e.g., asking the user how to resolve the inconsistency.  It means it is not required to do so with elective suffix tags, but is required to reject or perform some other error handling when encountering inconsistent or unrecognized suffix tags marked as critical. </ins> 3. 3.1.


RFC3339 for representing additional information including a time zone.  1. Dates and times are used in a very diverse set of internet 2.  This section discusses desirable qualities of formats for the timestamp extension suffix and defines such a format that extends RFC3339 for use in Internet protocols. <del> 2.1. </del>  The format is intended to allow implementations to specify additional important information in addition to the bare timestamp. implementations MUST give precedence to whichever value is positioned first. <del> 2.2. </del>  Actual suffix tag keys are registered by supplying the information specified in this section.  This information is modeled after that BCP178 for a discussion about the danger of experimental keys leaking out to general production and why that MUST be prevented. <del> 2.3. </del>  For the format defined here, suffix tags are always IXDTF strings such as: are internally inconsistent, as Europe/Paris does not use a time zone <del> offset of 0 (which is indicated in the "Z", an abbreviation for "+00:00"), nor a time zone offset of "+01:00" in July 2022.  The time zone hint given in the suffix tag is elective, though, so the recipient is not required to act on the inconsistency; it can treat the Internet Date/Time Format string as if it were: </del>  Similar with: <del> However, </del>  <del> all have an internal inconsistency or an unrecognized suffix key/ value, so a recipient MUST treat the IXDTF string as erroneous. </del>  Note that this does not mean that an application is disallowed to perform additional processing on elective suffix tags, e.g., asking reject or perform some other error handling when encountering inconsistent or unrecognized suffix tags marked as critical. <del> 3. </del>  <del> 3.1. </del>  The following rules extend the ABNF syntax defined in RFC3339 in order to allow the inclusion of an optional suffix. but does not include an equals sign.  This special case is only available for time zone tags. <del> 3.2. </del>  Here are some examples of Internet Extended Date/Time Format (IXDTF). interpreted by implementations that take part in the controlled experiment making use of these tag keys. <del> 4. </del>  Out of the possible suffix keys, the suffix key "u-ca" is allocated to indicate the calendar in which the date/time is preferably this suffix key is as defined by the CLDR data for TR35.  At the time of writing, this information is collected in CLDR-CALENDAR. <del> 5. </del>  IANA is requested to establish a registry called "Timestamp Suffix Tag Keys".  Each entry in the registry shall consist of the second case, the expert is instructed to ascertain that a basic specification does exist, even if not complete or published yet. <del> 6. </del>  TBD

Section 3.3 is not yet updated (but will clearly change a lot) (As discussed at IETF 114)
cc NAME
Hi NAME NAME - what are the next steps on this PR?
NAME NAME - Is there any update on this PR?
There isn't yet, but vacation time has officially ended in Europe... RSN.
Looks great! Thanks for bringing all these edits together. I left one minor comment in case you'd want to make that change, but also OK to merge if you don't think it's needed.

RFC3339 for representing additional information including a time zone. <ins> It updates RFC3339 in the specific interpretation of the local offset "Z", which is no longer understood to "imply that UTC is the preferred reference point for the specified time"; see update. </ins> 1. Dates and times are used in a very diverse set of internet 2. <ins> RFC3339 states that an offset given as "Z" or "+00:00" implies that "UTC is the preferred reference point for the specified time".  The offset "-00:00" is provided as a way to express that "the time in UTC is known, but the offset to local time is unknown". This convention mirrors a similar convention for date/time information in email headers, described in RFC5322 and introduced earlier in RFC2822.  The latter convention is in actual use, while the former always was handicapped by the fact that ISO8601 does not actually allow "-00:00". Implementations that needed to express the semantics of "-00:00" therefore tended to use "Z" as a "neutral" offset instead. This specification updates RFC3339, aligning it with the actual practice of interpreting the local offset "Z": this is no longer understood to "imply that UTC is the preferred reference point for the specified time". Note that the semantics of the local offset "+00:00" is not updated; this retains the implication that UTC is the preferred reference point for the specified time. Note also that the fact that ISO8601 does not allow "-00:00" as a local offset reduces the level of interoperability that can be achieved in using this feature; the present specification however does not formally deprecate this syntax.  For the intents and purposes of the present specification, the local offset "Z" can be used in its place. 3. </ins> This section discusses desirable qualities of formats for the timestamp extension suffix and defines such a format that extends RFC3339 for use in Internet protocols.  <ins> 3.1. </ins> The format is intended to allow implementations to specify additional important information in addition to the bare timestamp. implementations MUST give precedence to whichever value is positioned first.  <ins> 3.2. </ins> Actual suffix tag keys are registered by supplying the information specified in this section.  This information is modeled after that BCP178 for a discussion about the danger of experimental keys leaking out to general production and why that MUST be prevented.  <ins> 3.3. </ins> For the format defined here, suffix tags are always IXDTF strings such as: are internally inconsistent, as Europe/Paris does not use a time zone  <ins> offset of "+01:00" in July 2022.  The time zone hint given in the suffix tag is elective, though, so the recipient is not required to act on the inconsistency; it can treat the Internet Date/Time Format string as if it were: </ins> Similar with:  <ins> (assuming that the recipient does not understand the suffix key "knort"). </ins>  <ins> In contrast to this elective use of a suffix tag, each have an internal inconsistency or an unrecognized suffix key/ value that are marked as critical, so a recipient MUST treat the IXDTF string as erroneous. </ins> Note that this does not mean that an application is disallowed to perform additional processing on elective suffix tags, e.g., asking reject or perform some other error handling when encountering inconsistent or unrecognized suffix tags marked as critical.  <ins> 3.4. An RFC 3339 timestamp can contain a "time-offset" value that indicates the offset between local time and UTC (see RFC3339, noting that update of the present specification updates RFC3339). The information given in such a "time-offset" value can be inconsistent with the information provided in a time zone suffix for an IXDTF timestamp. For example, a calendar application could store an IXDTF string representing a far-future meeting in a particular time zone.  If that time zone's definition is subsequently changed to abolish Daylight Saving Time, IXDTF strings that were originally consistent may now be inconsistent. In case of inconsistent "time-offset" and time zone suffix, if the critical flag is used on the time zone suffix, an application MUST act on the inconsistency.  If the critical flag is not used, it MAY act on the inconsistency.  Acting on the inconsistency may involve rejecting the timestamp, or resolving the inconsistency via additional information such as user input and/or programmed behavior. For example, the IXDTF timestamps in example-inconsistent represent 00:14:07 UTC, indicating a local time with a "time-offset" of +00:00. However, because Europe/London used offset +01:00 in July 2022, the timestamps are inconsistent: As per RFC3339 as updated by update, IXDTF timestamps may also forego indicating local time information in their RFC3339 part.  The IXDTF timestamps in example-consistent (which represent the same instant in time as the strings in example-inconsistent) are not inconsistent because they do not assert any particular local time nor local offset in their RFC3339 part.  Instead, applications that receive these strings can base their local offset and local time calculations on the time zone suffix given, i.e., using the Europe/London time zone rules. </ins>  <ins> 4. 4.1. </ins> The following rules extend the ABNF syntax defined in RFC3339 in order to allow the inclusion of an optional suffix. but does not include an equals sign.  This special case is only available for time zone tags.  <ins> 4.2. </ins> Here are some examples of Internet Extended Date/Time Format (IXDTF). interpreted by implementations that take part in the controlled experiment making use of these tag keys.  <ins> 5. </ins> Out of the possible suffix keys, the suffix key "u-ca" is allocated to indicate the calendar in which the date/time is preferably this suffix key is as defined by the CLDR data for TR35.  At the time of writing, this information is collected in CLDR-CALENDAR.  <ins> 6. </ins> IANA is requested to establish a registry called "Timestamp Suffix Tag Keys".  Each entry in the registry shall consist of the second case, the expert is instructed to ascertain that a basic specification does exist, even if not complete or published yet.  <ins> 7. </ins> TBD


IXDTF strings such as: <del> are internally inconsistent, as Europe/Paris does not use a time zone offset of "+01:00" in July 2022.  The time zone hint given in the suffix tag is elective, though, so the recipient is not required to act on the inconsistency; it can treat the Internet Date/Time Format string as if it were: </del>  Similar with:

Minor fix of 3.3, now that we have 3.4. There is still a certain amount of redundancy between the two sections, which might be smoothened out by further editorial action. For now, let's get agreement on Section 2 before further tinkering.

IXDTF strings such as:  <ins> are internally inconsistent (see inconsistent), as Europe/Paris did not use a time zone offset of "+01:00" in July 2022.  The time zone hint given in the suffix tag is elective, though, so the recipient is not required to act on the inconsistency; it can treat the Internet Date/Time Format string as if it were: </ins> Similar with:


political decisions as discussed above, or  errors in the applications producing and consuming such a timestamp.

Minor suggested update to the RFC draft to explain another reason for conflicts: TZDB updates are not applied to all computers at the same time.
LGTM

political decisions as discussed above, or <ins> updates to time zone definitions being applied at different times by timestamp producers and receivers, or </ins> errors in the applications producing and consuming such a timestamp.


set of protocols and algorithms that are requested by applications or by a system policy.  2. The following terms are used throughout this document to describe the

Do you think this non-goal is helpful for people who are confused that "important" security protocols are omitted from this survey? (e.g. )
This document is a survey of network security protocols and their interaction with transport and application protocols. It is clearly written and easy to read. I have a minor comment on the contents of this draft. It is not abundantly clear what the criteria was for selecting the subset of security protocols included in this draft. Some notable omissions include SSH, L2TP, and GRE. These seem like interesting omissions given their popularity in a number of deployment scenarios. Not a showstopper in my opinion, but interesting to note.
Proposal: Add a paragraph to non-goals saying that we are not attempting to provide a comprehensive survey of all security protocols, or a survey of all "important" protocols that a TAPS implementation would have to support. Perhaps this also isn't entirely clear in the Introduction, which says our included protocols represent "a superset of features a Transport Services system may need to support". By this, we mean that it may need to implement any protocol that provides these features, and/or it may need to expose an interface to configure these features. We do NOT mean that the Transport Services System has to implement these exact protocols, or that it should limit itself to these protocols. But people might be misunderstanding it this way.
I think this is a fine idea -- thanks for the PR!

set of protocols and algorithms that are requested by applications or by a system policy. <ins> The protocols surveyed in this document represent a superset of functionality and features a Transport Services system may need to support.  It does not list all transport protocols that a Transport Services system may need to implement, nor does it mandate that a Transport Service system implement any particular protocol. A Transport Services system may implement any secure transport protocol that provides the described features.  In doing so, it may need to expose an interface to the application to configure these features. </ins> 2. The following terms are used throughout this document to describe the


QUIC <del> ESP IPsec OpenVPN </del> tcpcrypt MinimaLT  WireGuard  5.2. Identity Validation (IV): During a handshake, the security

Read through the Opsdir review we recently got. Not sure we want to add anything to that BGP questions, but there was also a minor editorial nit, which this PR fixes. Now the order of these protocols is the same as in the table.

QUIC  tcpcrypt MinimaLT <ins> IPsec ESP </ins> WireGuard <ins> OpenVPN </ins> 5.2. Identity Validation (IV): During a handshake, the security


3.6. <del> tcpcrypt is a lightweight extension to the TCP protocol to enable opportunistic encryption. </del>  3.6.1. <del> tcpcrypt extends TCP to enable opportunistic encryption between the two ends of a TCP connection I-D.ietf-tcpinc-tcpcrypt.  It is a type of TCP Encryption Protocol (TEP).  The use of a TEP is negotiated using TCP headers during the initial TCP handshake.  Negotiating a TEP also involves agreeing upon a key exchange algorithm.  If and when a TEP is negotiated, the tcpcrypt key exchange occurs within the data segments of the first packets exchanged after the handshake completes.  The initiator of a connection sends a list of support AEAD algorithms, a random nonce, and an ephemeral public key share. The responder chooses an AEAD algorithm and replies with its own nonce and ephemeral key share.  The traffic encryption keys are derived from the key exchange. Each tcpcrypt session is associated with a unique session ID; the value of which is derived from the current shared secret used for the session.  This can be cached and used to later resume a session. Willingness to resume a session is signaled within the TCP-ENO negotiation option during the TCP handshake I-D.ietf-tcpinc-tcpeno. Session identifiers are rotated each time they are resumed.  Sessions may also be re-keyed if the natural AEAD limit is reached. tcpcrypt only encrypts the data portion of a TCP packet.  It does not encrypt any header information, such as the TCP sequence number. </del>  3.6.2. <del> Forward-secure TCP packet encryption. </del>  Session caching and address-agnostic resumption. <del> Session re-keying. </del>  3.6.3. <del> TCP (with option support). </del>  3.7.

The one remaining item here is around address-agnosticism: I know the tcpcrypt draft asserts it, but I'm unclear on how that would be implemented in practice in the kernel, both because: Host resolution and connection establishment are separate stacks The complexity of state sharing for session caches makes server pools (the most common reason for IP changing) unlikely to implement it

3.6.  <ins> Tcpcrypt is a lightweight extension to the TCP protocol to enable opportunistic encryption with hooks available to the application layer for implementation of endpoint authentication. </ins> 3.6.1.  <ins> Tcpcrypt extends TCP to enable opportunistic encryption between the two ends of a TCP connection I-D.ietf-tcpinc-tcpcrypt.  It is a family of TCP encryption protocols (TEP), distinguished by key exchange algorithm.  The use of a TEP is negotiated with a TCP option during the initial TCP handshake via the mechanism described by TCP Encryption Negotiation Option (ENO) I-D.ietf-tcpinc-tcpeno.  In the case of initial session establishment, once a tcpcrypt TEP has been negotiated the key exchange occurs within the data segments of the first few packets exchanged after the handshake completes.  The initiator of a connection sends a list of supported AEAD algorithms, a random nonce, and an ephemeral public key share.  The responder typically chooses a mutually-supported AEAD algorithm and replies with this choice, its own nonce, and ephemeral key share.  An initial shared secret is derived from the ENO handshake, the tcpcrypt handshake, and the initial keying material resulting from the key exchange.  The traffic encryption keys on the initial connection are derived from the shared secret.  Connections can be re-keyed before the natural AEAD limit for a single set of traffic encryption keys is reached. Each tcpcrypt session is associated with a ladder of resumption IDs, each derived from the respective entry in a ladder of shared secrets. These resumption IDs can be used to negotiate a stateful resumption of the session in a subsequent connection, resulting in use of a new shared secret and traffic encryption keys without requiring a new key exchange.  Willingness to resume a session is signaled via the ENO option during the TCP handshake.  Given the length constraints imposed by TCP options, unlike stateless resumption mechanisms (such as that provided by session tickets in TLS) resumption in tcpcrypt requires the maintenance of state on the server, and so successful resumption across a pool of servers implies shared state. Owing to middlebox ossification issues, tcpcrypt only protects the payload portion of a TCP packet.  It does not encrypt any header information, such as the TCP sequence number. Tcpcrypt exposes a universally-unique connection-specific session ID to the application, suitable for application-level endpoint authentication either in-band or out-of-band. </ins> 3.6.2.  <ins> Forward-secure TCP payload encryption and integrity protection. </ins> Session caching and address-agnostic resumption.  <ins> Connection re-keying. Application-level authentication primitive. </ins> 3.6.3.  <ins> TCP TCP Encryption Negotiation Option (ENO) </ins> 3.7.