Merge branch 'main' into unsigned

Makefile

@@ -24,6 +24,7 @@ endef # cddl_targets
 
 $(eval $(call cddl_targets,corim,$(CORIM_FRAGS)))
 $(eval $(call cddl_targets,comid,$(COMID_FRAGS)))
+$(eval $(call cddl_targets,cotl,$(COTL_FRAGS)))
 $(eval $(call cddl_targets,intrep,$(INTREP_FRAGS)))
 
 cddl/concise-swid-tag.cddl: ; $(MAKE) -C cddl $(notdir $@)

cddl/Makefile

@@ -11,6 +11,7 @@ check:: cbor-tags-unique
 check:: check-intrep check-intrep-examples
 check:: check-corim check-corim-examples
 check:: check-comid check-comid-examples
+check:: check-cotl check-cotl-examples
 
 # $1: label
 # $2: cddl fragments
@@ -63,6 +64,7 @@ endef # cddl_check_template
 include corim-frags.mk
 
 $(eval $(call cddl_check_template,comid,$(COMID_FRAGS),$(COMID_EXAMPLES)))
+$(eval $(call cddl_check_template,cotl,$(COTL_FRAGS),$(COTL_EXAMPLES)))
 $(eval $(call cddl_check_template,corim,$(CORIM_FRAGS),$(CORIM_EXAMPLES)))
 $(eval $(call cddl_check_template,intrep,$(INTREP_FRAGS),$(INTREP_EXAMPLES)))
 

cddl/corim-frags.mk

@@ -50,6 +50,17 @@ COMID_FRAGS += concise-swid-tag.cddl
 
 COMID_EXAMPLES := $(wildcard examples/comid-*.diag)
 
+COTL_FRAGS := concise-tl-tag.cddl
+COTL_FRAGS += validity-map.cddl
+COTL_FRAGS += version-map.cddl
+COTL_FRAGS += tag-id-type-choice.cddl
+COTL_FRAGS += tag-identity-map.cddl
+COTL_FRAGS += uuid.cddl
+COTL_FRAGS += tag-version-type.cddl
+COTL_FRAGS += concise-swid-tag.cddl
+
+COTL_EXAMPLES := $(wildcard examples/cotl-*.diag)
+
 CORIM_FRAGS := corim.cddl
 CORIM_FRAGS += concise-tl-tag.cddl
 CORIM_FRAGS += concise-tag-type-choice.cddl

cddl/corim-locator-map.cddl

@@ -1,4 +1,4 @@
 corim-locator-map = {
-  &(href: 0) => uri
+  &(href: 0) => uri / [ + uri ]
   ? &(thumbprint: 1) => digest
 }

cddl/examples/cotl-1.diag

@@ -0,0 +1,21 @@
+/ concise-tl-tag / {
+  / cotl.tag-identity / 0 : {
+    / cotl.tag-id / 0 : h'3f06af63a93c11e4979700505690773a',
+    / cotl.tag-version / 1 : 1
+  },
+  / cotl.tags-list / 1 : [ {
+    / comid.tag-id / 0 : h'3f06af63a93c11e4979700505690773e'
+  },
+  {
+    / comid.tag-id / 0 : h'3f06af63a93c11e4979700505690773f',
+    / comid.tag-version / 1 : 5
+  },
+  {
+    / coswid.tag-id / 0 : h'3f06af63a93c11e4979700505690774f',
+    / coswid.tag-version / 1 : 2
+  }],
+  / cotl.tl-validity / 2 : {
+    / cotl.not-before / 0 : 1(1234),
+    / cotl.not-after / 1 : 1(4567)
+  }
+}

draft-ietf-rats-corim.md

@@ -121,6 +121,20 @@ informative:
     seriesinfo: Version 1.0, Revision 0.01
     date: July 2020
     target: https://trustedcomputinggroup.org/wp-content/uploads/DICE-Certificate-Profiles-r01_pub.pdf
+  TNC.Arch:
+    title: "TCG Trusted Network Connect TNC Architecture for Interoperability"
+    author:
+      org: Trusted Computing Group
+    seriesinfo: Specification Version 1.1 Revision 2
+    date: 1 May 2006
+    target: https://trustedcomputinggroup.org/wp-content/uploads/TNC_Architecture_v1_1_r2.pdf
+  TPM2.Part1:
+    title: "Trusted Platform Module Library, Part 1: Architecture"
+    author:
+      org: Trusted Computing Group
+    seriesinfo: Family "2.0", Level 00, Revision 01.83
+    date: January 24, 2024,
+    target: https://trustedcomputinggroup.org/resource/tpm-library-specification/
 
 entity:
   SELF: "RFCthis"
@@ -150,6 +164,8 @@ See {{sec-verifier-rec}}.
 
 ## Terminology and Requirements Language
 
+{::boilerplate bcp14}
+
 This document uses terms and concepts defined by the RATS architecture.
 For a complete glossary, see {{Section 4 of -rats-arch}}.
 
@@ -159,7 +175,48 @@ The terminology from CBOR {{-cbor}}, CDDL {{-cddl}} and COSE {{-cose}} applies;
 in particular, CBOR diagnostic notation is defined in {{Section 8 of -cbor}}
 and {{Section G of -cddl}}. Terms and concepts are always referenced as proper nouns, i.e., with Capital Letters.
 
-{::boilerplate bcp14}
+This document uses the following terms:
+
+{: vspace="0"}
+Endorsed values:
+: A set of characteristics of an Attester that do not appear in Evidence.
+For example, Endorsed Values may include testing or certification data related to a hardware or firmware module.
+Endorsed Values are said to be "conditional" when they apply if Attester's actual state matches Verifier's accepted Claims.
+See also {{Section 3 of -rats-endorsements}}.
+
+Environment:
+: A logical partition within an Attester.
+The term "Target Environment" refers to the group of system security metrics that are reported through Evidence.
+The term "Attesting Environment" refers to the entity that collects and cryptographically signs such security metrics.
+See also {{Section 3.1 of -rats-arch}}.
+
+Measurement:
+: A value associated with specific security characteristics of an Attester that influences the trustworthiness of that Attester.
+The object of a Measurement could be the invariant part of a firmware component loaded into memory during startup, a run-time integrity check (RTIC), a file system object, or a CPU register.
+A measured object is part of the Attester's Target Environment.
+Expected, or "golden," Measurements are compiled as Reference Values, which are used by the Verifier to assess the trust state of the Attester.
+See also {{TNC.Arch}}, and Section 9.5.5 of {{TPM2.Part1}}.
+
+Class ID:
+: An identifier for an Environment that is shared among similar Environment instances, such as those with the same hardware assembly.
+See also {{Section 4.2.4 of -eat}}.
+
+Instance ID:
+: An identifier of an Environment that is unique to that Environment instance, such as the serial number of a hardware module.
+See also {{Section 4.2.1 of -eat}}.
+
+Reference Values:
+: A set of values that represent the desired or undesired state of an Attester.
+Reference Values are compared against Evidence to determine the trustworthiness of the Attester.
+Reference Values with matching Evidence produce "acceptable Claims."
+See also {{Section 4.2 of -rats-arch}}, {{Section 8.3 of -rats-arch}}, and {{Section 2 of -rats-endorsements}}.
+
+Triple:
+: A term derived from the Resource Description Framework (RDF) to mean a statement expressing a relationship between a subject and an object resource.
+The nature of the relationship between subject and object is expressed via a predicate.
+In CoRIM, unlike RDF, the predicate of the triple is implicit and is encoded in the triple's name/codepoint.
+CoRIM triples typically represent assertions made by the CoRIM author regarding Attesting or Target Environments and their security features, such as Measurements and cryptographic key material.
+See also Section 3.1 of {{?W3C.rdf11-primer}}.
 
 # Verifier Reconciliation {#sec-verifier-rec}
 
@@ -346,7 +403,7 @@ certificates, or other relevant information can be retrieved by the Verifier.
 
 The following describes each child element of this type.
 
-* `href` (index 0): URI identifying the additional resource that can be fetched
+* `href` (index 0): a URI or array of alternative URIs identifying locations where the additional resource can be fetched.
 
 * `thumbprint` (index 1): expected digest of the resource referenced by `href`.
   See sec-common-hash-entry}}.
@@ -2141,7 +2198,7 @@ ECT authority is represented by cryptographic keys. Authority
 is asserted by digitally signing a Claim using the key. Hence, Claims are
 added to the ACS under the authority of a cryptographic key.
 
-Each Claim is encoded as an ECT. The `environment-map` and a
+Each Claim is encoded as an ECT. The `environment-map`, the `mkey` or `element-id`, and a
 key within `measurement-values-map` encode the name of the Claim.
 The value matching that key within `measurement-values-map` is the actual
 state of the Claim.