]> Fraunhofer SIT

henk.birkholz@sit.fraunhofer.de

arm

Thomas.Fossati@arm.com

arm

yogesh.deshpande@arm.com

Intel

ned.smith@intel.com

Huawei Technologies

william.panwei@huawei.com

Security Remote ATtestation ProcedureS RIM, RATS, attestation, verifier, supply chain Remote Attestation Procedures (RATS) enable Relying Parties to assess the trustworthiness of a remote Attester and therefore to decide whether to engage in secure interactions with it. Evidence about trustworthiness can be rather complex and it is deemed unrealistic that every Relying Party is capable of the appraisal of Evidence. Therefore that burden is typically offloaded to a Verifier. In order to conduct Evidence appraisal, a Verifier requires not only fresh Evidence from an Attester, but also trusted Endorsements and Reference Values from Endorsers and Reference Value Providers, such as manufacturers, distributors, or device owners. This document specifies Concise Reference Integrity Manifests (CoRIM) that represent Endorsements and Reference Values in CBOR format. Composite devices or systems are represented by a collection of Concise Module Identifiers (CoMID) and Concise Software Identifiers (CoSWID) bundled in a CoRIM document. Discussion Venues Source for this draft and an issue tracker can be found at .

Introduction Content missing. Tracked at: https://github.com/ietf-rats-wg/draft-ietf-rats-corim/issues/4

Terminology and Requirements Language This document uses terms and concepts defined by the RATS architecture. For a complete glossary see . The terminology from CBOR , CDDL and COSE applies; in particular, CBOR diagnostic notation is defined in and . The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

CDDL Typographical Conventions The CDDL definitions in this document follow the naming conventions illustrated in . Type Traits & Typographical Conventions

Type trait	Example	Typographical convention
extensible type choice	int / text / ...	$NAME-type-choice
closed type choice	int / text	NAME-type-choice
group choice	( 1 => int // 2 => text )	$$NAME-group-choice
group	( 1 => int, 2 => text )	NAME-group
type	int	NAME-type
tagged type	#6.123(int)	tagged-NAME-type
map	{ 1 => int, 2 => text }	NAME-map
flags	&( a: 1, b: 2 )	NAME-flags

Common Types The following CDDL types are used in both CoRIM and CoMID.

Non-Empty The non-empty generic type is used to express that a map with only optional members MUST at least include one of the members. = (M) .and ({ + any => any }) ]]>

Entity The entity-map is a generic type describing an organization responsible for the contents of a manifest. It is instantiated by supplying two parameters:

• A role-type-choice, i.e., a selection of roles that entities of the instantiated type can claim
• An extension-socket, i.e., a CDDL socket that can be used to extend the attributes associated with entities of the instantiated type

= { &(entity-name: 0) => $entity-name-type-choice ? &(reg-id: 1) => uri &(role: 2) => [ + role-type-choice ] * extension-socket } $entity-name-type-choice /= text ]]> The following describes each member of the entity-map.

• entity-name (index 0): The name of entity which is responsible for the action(s) as defined by the role. $entity-name-type-choice can only be Other specifications can extend the $entity-name-type-choice (see ).
• reg-id (index 1): A URI associated with the organization that owns the entity name
• role (index 2): A type choice defining the roles that the entity is claiming. The role is supplied as a parameter at the time the entity-map generic is instantiated.
• extension-socket: A CDDL socket used to add new information structures to the entity-map.

Examples of how the entity-map generic is instantiated can be found in and .

Validity A validity-map represents the time interval during which the signer warrants that it will maintain information about the status of the signed object (e.g., a manifest). In a validity-map, both ends of the interval are encoded as epoch-based date/time as per . time &(not-after: 1) => time } ]]>

• not-before (index 0): the date on which the signed manifest validity period begins
• not-after (index 1): the date on which the signed manifest validity period ends

UUID Used to tag a byte string as a binary UUID defined in .

UEID Used to tag a byte string as Universal Entity ID Claim (UUID) defined in .

OID Used to tag a byte string as the BER encoding of an absolute object identifier .

Tagged Integer Type Used as a class identifier for the environment. It is expected that the integer value is vendor specific rather than globally meaningful. Therefore, the sibling vendor field in the class-map MUST be populated to define the namespace under which the value must be understood.

Digest A digest represents the value of a hashing operation together with the hash algorithm used. The type of the digest algorithm identifier can be either int or text. When carried as an integer value, it is interpreted according to the "Named Information Hash Algorithm Registry" . When it is carried as text, there are no requirements with regards to its format. In general, the int encoding is RECOMMENDED. The text encoding should only be used when the digest type conveys reference value measurements that are matched verbatim with Evidence that uses the same convention - e.g., ).

CoRIM Content missing. Tracked at: https://github.com/ietf-rats-wg/draft-ietf-rats-corim/issues/6 At the top-level, a CoRIM can either be a CBOR-tagged corim-map () or a COSE signed corim-map ().

CoRIM Map The CDDL specification for the corim-map is as follows and this rule and its constraints must be followed when creating or validating a CoRIM map. $corim-id-type-choice &(tags: 1) => [ + $concise-tag-type-choice ] ? &(dependent-rims: 2) => [ + corim-locator-map ] ? &(profile: 3) => profile-type-choice ? &(rim-validity: 4) => validity-map ? &(entities: 5) => [ + corim-entity-map ] * $$corim-map-extension } ]]> The following describes each child item of this map.

• id (index 0): A globally unique identifier to identify a CoRIM. Described in
• tags (index 1): An array of one or more CoMID or CoSWID tags. Described in
• dependent-rims (index 2): One or more services supplying additional, possibly dependent, manifests or related files. Described in
• profile (index 3): An optional profile identifier for the tags contained in this CoRIM. The profile MUST be understood by the CoRIM processor. Failure to recognize the profile identifier MUST result in the rejection of the entire CoRIM. If missing, the profile defaults to DICE. Described in
• rim-validity (index 4): Specifies the validity period of the CoRIM. Described in
• entities (index 5): A list of entities involved in a CoRIM life-cycle. Described in
• $$corim-map-extension: This CDDL socket is used to add new information structures to the corim-map. See .

Identity A CoRIM id can be either a text string or a UUID type that uniquely identifies a CoRIM.

Tags A $concise-tag-type-choice is a tagged CBOR payload that carries either a CoMID () or a CoSWID .

Locator Map The locator map contains pointers to repositories where dependent manifests, certificates, or other relevant information can be retrieved by the Verifier. uri ? &(thumbprint: 1) => digest } ]]> The following describes each child element of this type.

• href (index 0): URI identifying the additional resource that can be fetched
• thumbprint (index 1): expected digest of the resource referenced by href. See .

Profile Types A profile specifies which of the optional parts of a CoRIM are required, which are prohibited and which extension points are exercised and how.

Entities The CoRIM Entity is an instantiation of the Entity generic () using a $corim-role-type-choice. The only role defined in this specification for a CoRIM Entity is manifest-creator. The $$corim-entity-map-extension extension socket is empty in this specification. $corim-role-type-choice /= &(manifest-creator: 1) ]]>

Signed CoRIM Signing a CoRIM follows the procedures defined in CBOR Object Signing and Encryption . A CoRIM tag MUST be wrapped in a COSE_Sign1 structure. The CoRIM MUST be signed by the CoRIM creator. The following CDDL specification defines a restrictive subset of COSE header parameters that MUST be used in the protected header alongside additional information about the CoRIM encoded in a corim-meta-map (). The following describes each child element of this type.

• protected: A CBOR Encoded protected header which is protected by the COSE signature. Contains information as given by Protected Header Map below.
• unprotected: A COSE header that is not protected by COSE signature.
• payload: A CBOR encoded tagged CoRIM.
• signature: A COSE signature block which is the signature over the protected and payload components of the signed CoRIM.

Protected Header Map int &(content-type: 3) => "application/corim-unsigned+cbor" &(issuer-key-id: 4) => bstr &(corim-meta: 8) => bstr .cbor corim-meta-map * cose-label => cose-value } ]]> The following describes each child item of this map.

• alg-id (index 1): An integer that identifies a signature algorithm.
• content-type (index 3): A string that represents the "MIME Content type" carried in the CoRIM payload.
• issuer-key-id (index 4): A bit string which is a key identity pertaining to the CoRIM Issuer.
• corim-meta (index 8): A map that contains metadata associated with a signed CoRIM. Described in .

Additional data can be included in the COSE header map as per .

Meta Map The CoRIM meta map identifies the entity or entities that create and sign the CoRIM. This ensures the consumer is able to identify credentials used to authenticate its signer. corim-signer-map ? &(signature-validity: 1) => validity-map } ]]> The following describes each child item of this group.

• signer (index 0): Information about the entity that signs the CoRIM. Described in
• signature-validity (index 1): Validity period for the CoRIM. Described in

Signer Map $entity-name-type-choice ? &(signer-uri: 1) => uri * $$corim-signer-map-extension } ]]>

• signer-name (index 0): Name of the organization that performs the signer role
• signer-uri (index 1): A URI identifying the same organization
• $$corim-signer-map-extension: Extension point for future expansion of the Signer map.

Unprotected CoRIM Header Map cose-value } ]]>

CoMID Content missing. Tracked at: https://github.com/ietf-rats-wg/draft-ietf-rats-corim/issues/7

Structure The CDDL specification for the concise-mid-tag map is as follows and this rule and its constraints MUST be followed when creating or validating a CoMID tag: text &(tag-identity: 1) => tag-identity-map ? &(entities: 2) => [ + comid-entity-map ] ? &(linked-tags: 3) => [ + linked-tag-map ] &(triples: 4) => triples-map * $$concise-mid-tag-extension } ]]> The following describes each member of the concise-mid-tag map.

• lang (index 0): A textual language tag that conforms with IANA "Language Subtag Registry" . The context of the specified language applies to all sibling and descendant textual values, unless a descendant object has defined a different language tag. Thus, a new context is established when a descendant object redefines a new language tag. All textual values within a given context MUST be considered expressed in the specified language.
• tag-identity (index 1): A tag-identity-map containing unique identification information for the CoMID. Described in .
• entities (index 2): Provides information about one or more organizations responsible for producing the CoMID tag. Described in .
• linked-tags (index 3): A list of one or more linked-tag-map (described in ), providing typed relationships between this and other CoMIDs.
• triples (index 4): One or more triples providing information specific to the described module, e.g.: reference or endorsed values, cryptographic material, or structural relationship between the described module and other modules. Described in ().

Tag Identity $tag-id-type-choice ? &(tag-version: 1) => tag-version-type } ]]> The following describes each member of the tag-identity-map.

• tag-id (index 0): A universally unique identifier for the CoMID. Described in .
• tag-version (index 1): Optional versioning information for the tag-id . Described in .

Tag ID A Tag ID is either a 16-byte binary string, or a textual identifier, uniquely referencing the CoMID. The tag identifier MUST be globally unique. Failure to ensure global uniqueness can create ambiguity in tag use since the tag-id serves as the global key for matching, lookups and linking. If represented as a 16-byte binary string, the identifier MUST be a valid universally unique identifier as defined by . There are no strict guidelines on how the identifier is structured, but examples include a 16-byte GUID (e.g., class 4 UUID) , or a URI .

Tag Version Tag Version is an integer value that indicates the specific release revision of the tag. Typically, the initial value of this field is set to 0 and the value is increased for subsequent tags produced for the same module release. This value allows a CoMID tag producer to correct an incorrect tag previously released without indicating a change to the underlying module the tag represents. For example, the tag version could be changed to add new metadata, to correct a broken link, to add a missing reference value, etc. When producing a revised tag, the new tag-version value MUST be greater than the old tag-version value.

Entities ]]> The CoMID Entity is an instantiation of the Entity generic () using a $comid-role-type-choice. The $$comid-entity-map-extension extension socket is empty in this specification. The roles defined for a CoMID entity are:

• tag-creator (value 0): creator of the CoMID tag.
• creator (value 1): original maker of the module described by the CoMID tag.
• maintainer (value 2): an entity making changes to the module described by the CoMID tag.

Linked Tag The linked tag map represents a typed relationship between the embedding CoMID tag (the source) and another CoMID tag (the target). $tag-id-type-choice &(tag-rel: 1) => $tag-rel-type-choice } ]]> The following describes each member of the tag-identity-map.

• linked-tag-id (index 0): Unique identifier for the target tag. For the definition see .
• tag-rel (index 1): the kind of relation linking the source tag to the target identified by linked-tag-id.

The relations defined in this specification are:

• supplements (value 0): the source tag provides additional information about the module described in the target tag.
• replaces (value 1): the source tag corrects erroneous information contained in the target tag. The information in the target MUST be disregarded.

Triples The triples-map contains all the CoMID triples broken down per category. Not all category need to be present but at least one category MUST be present and contain at least one entry. [ + reference-triple-record ] ? &(endorsed-triples: 1) => [ + endorsed-triple-record ] ? &(identity-triples: 2) => [ + identity-triple-record ] ? &(attest-key-triples: 3) => [ + attest-key-triple-record ] ? &(dependency-triples: 4) => [ + domain-dependency-triple-record ] ? &(membership-triples: 5) => [ + domain-membership-triple-record ] ? &(coswid-triples: 6) => [ + coswid-triple-record ] ? &(conditional-endorsement-series-triples: 8) => [ + conditional-endorsement-series-triple-record ] ? &(conditional-endorsement-triples: 9) => [ + conditional-endorsement-triple-record ] * $$triples-map-extension }> ]]> The following describes each member of the triples-map:

• reference-triples (index 0): Triples containing reference values. Described in .
• endorsed-triples (index 1): Triples containing endorsed values. Described in .
• identity-triples (index 2): Triples containing identity credentials. Described in .
• attest-key-triples (index 3): Triples containing verification keys associated with attesting environments. Described in .
• dependency-triples (index 4): Triples describing trust relationships between domains. Described in .
• membership-triples (index 5): Triples describing topological relationships between (sub-)modules. Described in .
• coswid-triples (index 6): Triples associating modules with existing CoSWID tags. Described in .
• conditional-endorsement-series-triples (index 8) Triples describing a series of conditional Endorsements based on the acceptance of a stateful environment. Described in .
• conditional-endorsement-triples (index 9) Triples describing conditional Endorsement based on the acceptance of a stateful environment. Described in .

Common Types

Environment An environment-map may be used to represent a whole attester, an attesting environment, or a target environment. The exact semantic depends on the context (triple) in which the environment is used. An environment is named after a class, instance or group identifier (or a combination thereof). class-map ? &(instance: 1) => $instance-id-type-choice ? &(group: 2) => $group-id-type-choice }> ]]> The following describes each member of the environment-map:

• class (index 0): Contains "class" attributes associated with the module. Described in .
• instance (index 1): Contains a unique identifier of a module's instance. See .
• group (index 2): identifier for a group of instances, e.g., if an anonymization scheme is used.

Class The Class name consists of class attributes that distinguish the class of environment from other classes. The class attributes include class-id, vendor, model, layer, and index. The CoMID author determines which attributes are needed. $class-id-type-choice ? &(vendor: 1) => tstr ? &(model: 2) => tstr ? &(layer: 3) => uint ? &(index: 4) => uint }> $class-id-type-choice /= tagged-oid-type $class-id-type-choice /= tagged-uuid-type $class-id-type-choice /= tagged-int-type ]]> The following describes each member of the class-map:

• class-id (index 0): Identifies the environment via a well-known identifier. Typically, class-id is an object identifier (OID) or universally unique identifier (UUID). Use of this attribute is preferred.
• vendor (index 1): Identifies the entity responsible for choosing values for the other class attributes that do not already have naming authority.
• model (index 2): Describes a product, generation, and family. If populated, vendor MUST also be populated.
• layer (index 3): Is used to capture where in a sequence the environment exists. For example, the order in which bootstrap code is executed may have security relevance.
• index (index 4): Is used when there are clones (i.e., multiple instances) of the same class of environment. Each clone is given a different index value to disambiguate it from the other clones. For example, given a chassis with several network interface controllers (NIC), each NIC can be given a different index value.

Instance An instance carries a unique identifier that is reliably bound to an instance of the attester. The types defined for an instance identifier are UEID or UUID.

 Group A group carries a unique identifier that is reliably bound to a group of attesters, for example when a number of attester are hidden in the same anonymity set. The type defined for a group identified is UUID.

Measurements Measurements can be of a variety of things including software, firmware, configuration files, read-only memory, fuses, IO ring configuration, partial reconfiguration regions, etc. Measurements comprise raw values, digests, or status information. An environment has one or more measurable elements. Each element can have a dedicated measurement or multiple elements could be combined into a single measurement. Measurements can have class, instance or group scope. This is typically determined by the triple's environment. Class measurements apply generally to all the attesters in the given class. Instance measurements apply to a specific attester instances. Environments identified by a class identifier have measurements that are common to the class. Environments identified by an instance identifier have measurements that are specific to that instance. $measured-element-type-choice &(mval: 1) => measurement-values-map ? &(authorized-by: 2) => [ + $crypto-key-type-choice ] } ]]> The following describes each member of the measurement-map:

• mkey (index 0): An optional unique identifier of the measured (sub-)environment. See .
• mval (index 1): The measurements associated with the (sub-)environment. Described in .

Measurement Keys The types defined for a measurement identifier are OID, UUID or uint.

Measurement Values A measurement-values-map contains measurements associated with a certain environment. Depending on the context (triple) in which they are found, elements in a measurement-values-map can represent class or instance measurements. Note that some of the elements have instance scope only. version-map ? &(svn: 1) => svn-type-choice ? &(digests: 2) => [ + digest ] ? &(flags: 3) => flags-map ? ( &(raw-value: 4) => $raw-value-type-choice, ? &(raw-value-mask: 5) => raw-value-mask-type ) ? &(mac-addr: 6) => mac-addr-type-choice ? &(ip-addr: 7) => ip-addr-type-choice ? &(serial-number: 8) => text ? &(ueid: 9) => ueid-type ? &(uuid: 10) => uuid-type ? &(name: 11) => text * $$measurement-values-map-extension }> ]]> The following describes each member of the measurement-values-map.

• version (index 0): Typically changes whenever the measured environment is updated. Described in .
• svn (index 1): The security version number typically changes only when a security relevant change is made to the measured environment. Described in .
• digests (index 2): Contains the digest(s) of the measured environment together with the respective hash algorithm used in the process. See .
• flags (index 3): Describes security relevant operational modes. For example, whether the environment is in a debug mode, recovery mode, not fully configured, not secure, not replay protected or not integrity protected. The flags field indicates which operational modes are currently associated with measured environment. Described in .
• raw-value (index 4): Contains the actual (not hashed) value of the element. An optional raw-value-mask (index 5) indicates which bits in the raw-value field are relevant for verification. A mask of all ones ("1") means all bits in the raw-value field are relevant. Multiple values could be combined to create a single raw-value attribute. The vendor determines how to pack multiple values into a single raw-value structure. The same packing format is used when collecting Evidence so that Reference Values and collected values are bit-wise comparable. The vendor determines the encoding of raw-value and the corresponding raw-value-mask.
• mac-addr (index 6): A EUI-48 or EUI-64 MAC address associated with the measured environment. Described in .
• ip-addr (index 7): An IPv4 or IPv6 address associated with the measured environment. Described in .
• serial-number (index 8): A text string representing the product serial number.
• ueid (index 9): UEID associated with the measured environment. See .
• uuid (index 10): UUID associated with the measured environment. See .
• name (index 11): a name associated with the measured environment.

Version A version-map contains details about the versioning of a measured environment. text ? &(version-scheme: 1) => $version-scheme } ]]> The following describes each member of the version-map:

• version (index 0): the version string
• version-scheme (index 1): an optional indicator of the versioning convention used in the version attribute. Defined in . The CDDL is copied below for convenience.

Security Version Number The following details the security version number (svn) and the minimum security version number (min-svn) statements. A security version number is used to track changes to an object (e.g., a secure enclave, a boot loader executable, a configuration file, etc.) that are security relevant. Rollback of a security relevant change is considered to be an attack vector, as such, security version numbers can't be decremented. If a security relevant flaw is discovered in the Target Environment and subsequently fiexed, the svn value is typically incremented. There may be several revisions to a Target Environment that are in use at the same time. If there are multiple revisions with different svn values, the revision with a lower svn value may or may not be in a security critical condition. The Endorser may provide a minimum security version number using min-svn to specify the lowest svn value that is acceptable. svn values that are equal to or greater than min-svn do not signal a security critical condition. svn values that are below min-svn are in a security critical condition that is unsafe for normal use. The svn-type-choice measurement consists of a tagged-svn or tagged-min-svn value. The tagged-svn and tagged-min-svn tags are CBOR tags with the values #6.552 and #6.553 respectively.

Flags The flags-map measurement describes a number of boolean operational modes. If a flags-map value is not specified, then the operational mode is unknown. bool ? &(secure: 1) => bool ? &(recovery: 2) => bool ? &(debug: 3) => bool ? &(replay-protected: 4) => bool ? &(integrity-protected: 5) => bool * $$flags-map-extension } ]]> The following describes each member of the flags-map:

• configured (index 0): The measured environment is fully configured for normal operation if the flag is true.
• secure (index 1): The measured environment's configurable security settings are fully enabled if the flag is true.
• recovery (index 2): The measured environment is NOT in a recovery state if the flag is true.
• debug (index 3): The measured environment is in a debug enabled state if the flag is true.
• replay-protected (index 4): The measured environment is protected from replay by a previous image that differs from the current image if the flag is true.
• integrity-protected (index 5): The measured environment is protected from unauthorized update if the flag is true.

Raw Values Types Content missing. Tracked at: https://github.com/ietf-rats-wg/draft-ietf-rats-corim/issues/9

Address Types The types or associating addressing information to a measured environment are:

Crypto Keys A cryptographic key can be one of the following formats:

• tagged-pkix-base64-key-type: PEM encoded SubjectPublicKeyInfo. Defined in .
• tagged-pkix-base64-cert-type: PEM encoded X.509 public key certificate. Defined in .
• tagged-pkix-base64-cert-path-type: X.509 certificate chain created by the concatenation of as many PEM encoded X.509 certificates as needed. The certificates MUST be concatenated in order so that each directly certifies the one preceding.

A fourth format is used to represent thumbprints of raw keys or certificated keys:

• tagged-thumbprint-type: hash of a certificate or raw public key.

Domain Types A domain is a context for bundling a collection of related environments and their measurements. Three types are defined: uint and text for local scope, UUID for global scope.

Reference Values Triple A Reference Values triple relates reference measurements to a Target Environment. For Reference Value Claims, the subject identifies a Target Environment, the object contains measurements, and the predicate asserts that these are the expected (i.e., reference) measurements for the Target Environment.

Endorsed Values Triple An Endorsed Values triple declares additional measurements that are valid when a Target Environment has been verified against reference measurements. For Endorsed Value Claims, the subject is either a Target or Attesting Environment, the object contains measurements, and the predicate defines semantics for how the object relates to the subject.

Device Identity Triple A Device Identity triple relates one or more cryptographic keys to a device. The subject of an Identity triple uses an instance or class identifier to refer to a device, and a cryptographic key is the object. The predicate asserts that the identity is authenticated by the key. A common application for this triple is device identity.

Attestation Keys Triple An Attestation Keys triple relates one or more cryptographic keys to an Attesting Environment. The Attestation Key triple subject is an Attesting Environment whose object is a cryptographic key. The predicate asserts that the Attesting Environment signs Evidence that can be verified using the key.

Domain Dependency Triple A Domain Dependency triple defines trust dependencies between measurement sources. The subject identifies a domain () that has a predicate relationship to the object containing one or more dependent domains. Dependency means the subject domain’s trustworthiness properties rely on the object domain(s) trustworthiness having been established before the trustworthiness properties of the subject domain exists.

Domain Membership Triple A Domain Membership triple assigns domain membership to environments. The subject identifies a domain () that has a predicate relationship to the object containing one or more environments. Endorsed environments () membership is conditional upon successful matching of Reference Values () to Evidence.

CoMID-CoSWID Linking Triple A CoSWID triple relates reference measurements contained in one or more CoSWIDs to a Target Environment. The subject identifies a Target Environment, the object one or more unique tag identifiers of existing CoSWIDs, and the predicate asserts that these contain the expected (i.e., reference) measurements for the Target Environment.

Conditional Endorsement Series Triple A Conditional Endorsement Series triple uses a stateful environment, (i.e., stateful-environment-record), that identifies a Target Environment based on an environment-map plus the measurement-map measurements that have matching Evidence. The stateful Target Environment is a triple subject that MUST be satisfied before the series triple object is matched. The series object is an array of conditional-series-record that has both Reference and Endorsed Values. Each conditional-series-record record is evaluated in the order it appears in the series array. The Endorsed Values are accepted if the Reference Values in a conditional-series-record matches Evidence. The first conditional-series-record that sucessfully matches Evidence terminates the series and the matching Reference Values as well as the Endorsed Values are accepted. If none of the Reference Values in the series match Evidence, the triple is not matched, and no Claims are accepted. The authorized-by value in measurement-map in the stateful environment, if present, applies to all measurements in the triple, including conditional-series-record records.

Conditional Endorsement Triple A Conditional Endorsement triple uses a stateful environment, (i.e., stateful-environment-record), that identifies a Target Environment based on an environment-map plus the measurement-map measurements that have matching Evidence. The stateful Target Environment is a triple subject that MUST be satisfied before the Endorsed Values in the triple object are accepted. The authorized-by value in measurement-map in the stateful environment, if present, applies to all measurements in the triple, including those in measurement-values-map.

Extensibility Content missing. Tracked at: https://github.com/ietf-rats-wg/draft-ietf-rats-corim/issues/10

CoBOM A Concise Bill of Material (CoBOM) object represents the signal for the verifier to activate the listed tags. Data contained in a tag MUST NOT be used for appraisal until a CoBOM which activates that tag has been received and successfully processed. All the tags listed in the CoBOM must be activated in the same transaction, i.e., either all or none.

Structure The CDDL specification for the concise-bom-tag map is as follows and this rule and its constraints MUST be followed when creating or validating a CoBOM tag: tag-identity-map &(tags-list: 1) => [ + tag-identity-map ], &(bom-validity: 2) => validity-map * $$concise-bom-tag-extension } ]]> The following describes each member of the concise-bom-tag map.

• tag-identity (index 0): A tag-identity-map containing unique identification information for the CoBOM. Described in .
• tags-list (index 1): A list of one or more tag-identity-maps identifying the CoMID and CoSWID tags that constitute the "bill of material", i.e., a complete set of verification-related information. The tags-list behaves like a signaling mechanism from the supply chain (e.g., a product vendor) to a Verifier that activates the tags in tags-list for use in the Evidence appraisal process. The activation is atomic: all tags listed in tags-list MUST be activated or no tags are activated.
• bom-validity (index 2): Specifies the validity period of the CoBOM. Described in
• $$concise-bom-tag-extension: This CDDL socket is used to add new information structures to the concise-bom-tag. See . The $$concise-bom-tag-extension extension socket is empty in this specification.

Implementation Status This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in . The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to , "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".

Veraison

• Organization responsible for the implementation: Veraison Project, Linux Foundation
• Implementation's web page: https://github.com/veraison/corim/README.md
• Brief general description: The corim/corim and corim/comid packages provide a golang API for low-level manipulation of Concise Reference Integrity Manifest (CoRIM) and Concise Module Identifier (CoMID) tags respectively. The corim/cocli package uses the API above (as well as the API from the veraison/swid package) to provide a user command line interface for working with CoRIM, CoMID and CoSWID. Specifically, it allows creating, signing, verifying, displaying, uploading, and more. See https://github.com/cocli/README.md for further details.
• Implementation's level of maturity: alpha.
• Coverage: the whole protocol is implemented, including PSA-specific extensions .
• Version compatibility: Version -02 of the draft
• Licensing: Apache 2.0 https://github.com/veraison/corim/blob/main/LICENSE
• Implementation experience: n/a
• Contact information: https://veraison.zulipchat.com
• Last updated: https://github.com/veraison/corim/commits/main

Security and Privacy Considerations Content missing. Tracked at: https://github.com/ietf-rats-wg/draft-ietf-rats-corim/issues/11

IANA Considerations

New COSE Header Parameters Content missing. Tracked at: https://github.com/ietf-rats-wg/draft-ietf-rats-corim/issues/12

New CBOR Tags Content missing. Tracked at: https://github.com/ietf-rats-wg/draft-ietf-rats-corim/issues/13 IANA is requested to allocate the following tags in the "CBOR Tags" registry , preferably with the specific CBOR tag value requested:

Tag	Data Item	Semantics	Reference
500	tag	A corim, one out of $concise-rim-type-choice, see	RFCthis
501	map	A corim-map, see	RFCthis
502	tag	A signed-corim, see	RFCthis
503-504	any	Earmarked for CoRIM	RFCthis
505	bytes	An encoded concise-swid-tag, see	RFCthis
506	bytes	An encoded concise-mid-tag, see }	RFCthis
507	any	Earmarked for CoRIM	RFCthis
508	bytes	An encoded concise-bom-tag, see }	RFCthis
509-549	any	Earmarked for CoRIM	RFCthis
550	bytes .size 33	tagged-ueid-type, see	RFCthis
551	int	tagged-int-type, see	RFCthis
552	uint	tagged-svn, see	RFCthis
553	uint	tagged-min-svn, see	RFCthis
554	text	tagged-pkix-base64-key-type, see	RFCthis
555	text	tagged-pkix-base64-cert-type, see	RFCthis
556	text	tagged-pkix-base64-cert-path-type, see	RFCthis
557	digest: [alg: int/text, val: bytes]	tagged-thumbprint-type, see	RFCthis
558-559	any	Earmarked for CoRIM	RFCthis
560	bytes	$raw-value-type-choice, see	RFCthis
561-599	any	Earmarked for CoRIM	RFCthis

Tags designated as "Earmarked for CoRIM" can be reassigned by IANA based on advice from the designated expert for the CBOR Tags registry.

New CoRIM Registries Content missing. Tracked at: https://github.com/ietf-rats-wg/draft-ietf-rats-corim/issues/14

New CoMID Registries Content missing. Tracked at: https://github.com/ietf-rats-wg/draft-ietf-rats-corim/issues/15

New CoBOM Registries Content missing. Tracked at: https://github.com/ietf-rats-wg/draft-ietf-rats-corim/issues/45

New Media Types IANA is requested to add the following media types to the "Media Types" registry . New Media Types

Name	Template	Reference
corim-signed+cbor	application/corim-signed+cbor	RFCthis,
corim-unsigned+cbor	application/corim-unsigned+cbor	RFCthis,

corim-signed+cbor

Type name:

application

Subtype name:

corim-signed+cbor

Required parameters:

n/a

Optional parameters:

"profile" (CoRIM profile in string format. OIDs MUST use the dotted-decimal notation.)

Encoding considerations:

binary

Security considerations:

of RFCthis

Interoperability considerations:

n/a

Published specification:

RFCthis

Applications that use this media type:

Attestation Verifiers, Endorsers and Reference-Value providers that need to transfer COSE Sign1 wrapped CoRIM payloads over HTTP(S), CoAP(S), and other transports.

Fragment identifier considerations:

n/a

Magic number(s):

D9 01 F6 D2, D9 01 F4 D9 01 F6 D2

File extension(s):

n/a

Macintosh file type code(s):

n/a

Person & email address to contact for further information:

RATS WG mailing list (rats@ietf.org)

Intended usage:

COMMON

Restrictions on usage:

none

Author/Change controller:

IETF

Provisional registration?

Maybe

corim-unsigned+cbor

Type name:

application

Subtype name:

corim-unsigned+cbor

Required parameters:

n/a

Optional parameters:

"profile" (CoRIM profile in string format. OIDs MUST use the dotted-decimal notation.)

Encoding considerations:

binary

Security considerations:

of RFCthis

Interoperability considerations:

n/a

Published specification:

RFCthis

Applications that use this media type:

Attestation Verifiers, Endorsers and Reference-Value providers that need to transfer unprotected CoRIM payloads over HTTP(S), CoAP(S), and other transports.

Fragment identifier considerations:

n/a

Magic number(s):

D9 01 F5, D9 01 F4 D9 01 F5

File extension(s):

n/a

Macintosh file type code(s):

n/a

Person & email address to contact for further information:

RATS WG mailing list (rats@ietf.org)

Intended usage:

COMMON

Restrictions on usage:

none

Author/Change controller:

IETF

Provisional registration?

Maybe

CoAP Content-Formats Registration IANA is requested to register the two following Content-Format numbers in the "CoAP Content-Formats" sub-registry, within the "Constrained RESTful Environments (CoRE) Parameters" Registry : New Content-Formats

Content-Type	Content Coding	ID	Reference
application/corim-signed+cbor	-	TBD1	RFCthis
application/corim-unsigned+cbor	-	TBD2	RFCthis

References Normative References This specification defines a Uniform Resource Name namespace for UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally Unique IDentifier). A UUID is 128 bits long, and can guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System and later in the Open Software Foundation\'s (OSF) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms. This specification is derived from the DCE specification with the kind permission of the OSF (now known as The Open Group). Information from earlier versions of the DCE specification have been incorporated into this document. [STANDARDS-TRACK] This document describes and discusses the textual encodings of the Public-Key Infrastructure X.509 (PKIX), Public-Key Cryptography Standards (PKCS), and Cryptographic Message Syntax (CMS). The textual encodings are well-known, are implemented by several applications and libraries, and are widely deployed. This document articulates the de facto rules by which existing implementations operate and defines them so that future implementations can interoperate. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. The Concise Binary Object Representation (CBOR), defined in RFC 8949, is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. This document defines CBOR tags for object identifiers (OIDs) and is the reference document for the IANA registration of the CBOR tags so defined. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] Fraunhofer SIT National Security Agency The MITRE Corporation National Institute of Standards and Technology ISO/IEC 19770-2:2015 Software Identification (SWID) tags provide an extensible XML-based structure to identify and describe individual software components, patches, and installation bundles. SWID tag representations can be too large for devices with network and storage constraints. This document defines a concise representation of SWID tags: Concise SWID (CoSWID) tags. CoSWID supports a similar set of semantics and features as SWID tags, as well as new semantics that allow CoSWIDs to describe additional types of information, all in a more memory efficient format. Fraunhofer SIT Microsoft Sandelman Software Works Intel Corporation Huawei Technologies In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. Security Theory LLC Qualcomm Technologies Inc. Qualcomm Technologies Inc. Red Hound Software, Inc. An Entity Attestation Token (EAT) provides an attested claims set that describes state and characteristics of an entity, a device like a smartphone, IoT device, network equipment or such. This claims set is used by a relying party, server or service to determine how much it wishes to trust the entity. An EAT is either a CBOR Web Token (CWT) or JSON Web Token (JWT) with attestation-oriented claims. IANA International Telecommunications Union IANA In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. IANA IANA IANA Informative References This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. Arm Ltd Arm Ltd Fraunhofer SIT PSA Endorsements include reference values, cryptographic key material and certification status information that a Verifier needs in order to appraise attestation Evidence produced by a PSA device. This memo defines such PSA Endorsements as a profile of the CoRIM data model. Arm Limited Arm Limited HP Labs Arm Limited The Platform Security Architecture (PSA) is a family of hardware and firmware security specifications, as well as open-source reference implementations, to help device makers and chip manufacturers build best-practice security into products. Devices that are PSA compliant are able to produce attestation tokens as described in this memo, which are the basis for a number of different protocols, including secure provisioning and network access control. This document specifies the PSA attestation token structure and semantics. The PSA attestation token is a profiled Entity Attestation Token (EAT). This specification describes what claims are used in an attestation token generated by PSA compliant systems, how these claims get serialized to the wire, and how they are cryptographically protected.

Full CoRIM CDDL tag-identity-map &(tags-list: 1) => [ + tag-identity-map ], &(bom-validity: 2) => validity-map * $$concise-bom-tag-extension } $concise-tag-type-choice /= #6.505(bytes .cbor concise-swid-tag) $concise-tag-type-choice /= #6.506(bytes .cbor concise-mid-tag) $concise-tag-type-choice /= #6.508(bytes .cbor concise-bom-tag) corim-entity-map = entity-map<$corim-role-type-choice, $$corim-entity-map-extension> $corim-id-type-choice /= tstr $corim-id-type-choice /= uuid-type corim-locator-map = { &(href: 0) => uri ? &(thumbprint: 1) => digest } corim-map = { &(id: 0) => $corim-id-type-choice &(tags: 1) => [ + $concise-tag-type-choice ] ? &(dependent-rims: 2) => [ + corim-locator-map ] ? &(profile: 3) => profile-type-choice ? &(rim-validity: 4) => validity-map ? &(entities: 5) => [ + corim-entity-map ] * $$corim-map-extension } corim-meta-map = { &(signer: 0) => corim-signer-map ? &(signature-validity: 1) => validity-map } $corim-role-type-choice /= &(manifest-creator: 1) corim-signer-map = { &(signer-name: 0) => $entity-name-type-choice ? &(signer-uri: 1) => uri * $$corim-signer-map-extension } cose-label = int / tstr cose-value = any COSE-Sign1-corim = [ protected: bstr .cbor protected-corim-header-map unprotected: unprotected-corim-header-map payload: bstr .cbor tagged-corim-map signature: bstr ] profile-type-choice = uri / tagged-oid-type protected-corim-header-map = { &(alg-id: 1) => int &(content-type: 3) => "application/corim-unsigned+cbor" &(issuer-key-id: 4) => bstr &(corim-meta: 8) => bstr .cbor corim-meta-map * cose-label => cose-value } signed-corim = #6.18(COSE-Sign1-corim) tagged-corim-map = #6.501(corim-map) unprotected-corim-header-map = { * cose-label => cose-value } validity-map = { ? &(not-before: 0) => time &(not-after: 1) => time } concise-mid-tag = { ? &(language: 0) => text &(tag-identity: 1) => tag-identity-map ? &(entities: 2) => [ + comid-entity-map ] ? &(linked-tags: 3) => [ + linked-tag-map ] &(triples: 4) => triples-map * $$concise-mid-tag-extension } attest-key-triple-record = [ environment-map [ + $crypto-key-type-choice ] ] $class-id-type-choice /= tagged-oid-type $class-id-type-choice /= tagged-uuid-type $class-id-type-choice /= tagged-int-type class-map = non-empty<{ ? &(class-id: 0) => $class-id-type-choice ? &(vendor: 1) => tstr ? &(model: 2) => tstr ? &(layer: 3) => uint ? &(index: 4) => uint }> comid-entity-map = entity-map<$comid-role-type-choice, $$comid-entity-map-extension> $comid-role-type-choice /= &(tag-creator: 0) $comid-role-type-choice /= &(creator: 1) $comid-role-type-choice /= &(maintainer: 2) conditional-endorsement-series-triple-record = [ stateful-environment-record ; order matters: the first matching record wins and halts matching [ + conditional-series-record ] ] conditional-endorsement-triple-record = [ stateful-environment-record, ; endorsed values measurement-values-map ] conditional-series-record = [ ; reference values to be matched against evidence refv: measurement-values-map ; endorsed values that apply in case revf matches endv: measurement-values-map ] coswid-triple-record = [ environment-map [ + concise-swid-tag-id ] ] concise-swid-tag-id = text / bstr .size 16 $crypto-key-type-choice /= tagged-pkix-base64-key-type $crypto-key-type-choice /= tagged-pkix-base64-cert-type $crypto-key-type-choice /= tagged-pkix-base64-cert-path-type $crypto-key-type-choice /= tagged-thumbprint-type tagged-pkix-base64-key-type = #6.554(tstr) tagged-pkix-base64-cert-type = #6.555(tstr) tagged-pkix-base64-cert-path-type = #6.556(tstr) tagged-thumbprint-type = #6.557(digest) domain-dependency-triple-record = [ $domain-type-choice [ + $domain-type-choice ] ] domain-membership-triple-record = [ $domain-type-choice [ + environment-map ] ] $domain-type-choice /= uint $domain-type-choice /= text $domain-type-choice /= tagged-uuid-type endorsed-triple-record = [ environment-map measurement-map ] entity-map = { &(entity-name: 0) => $entity-name-type-choice ? &(reg-id: 1) => uri &(role: 2) => [ + role-type-choice ] * extension-socket } $entity-name-type-choice /= text environment-map = non-empty<{ ? &(class: 0) => class-map ? &(instance: 1) => $instance-id-type-choice ? &(group: 2) => $group-id-type-choice }> flags-map = { ? &(configured: 0) => bool ? &(secure: 1) => bool ? &(recovery: 2) => bool ? &(debug: 3) => bool ? &(replay-protected: 4) => bool ? &(integrity-protected: 5) => bool * $$flags-map-extension } $group-id-type-choice /= tagged-uuid-type identity-triple-record = [ environment-map [ + $crypto-key-type-choice ] ] $instance-id-type-choice /= tagged-ueid-type $instance-id-type-choice /= tagged-uuid-type ip-addr-type-choice = ip4-addr-type / ip6-addr-type ip4-addr-type = bytes .size 4 ip6-addr-type = bytes .size 16 linked-tag-map = { &(linked-tag-id: 0) => $tag-id-type-choice &(tag-rel: 1) => $tag-rel-type-choice } mac-addr-type-choice = eui48-addr-type / eui64-addr-type eui48-addr-type = bytes .size 6 eui64-addr-type = bytes .size 8 $measured-element-type-choice /= tagged-oid-type $measured-element-type-choice /= tagged-uuid-type $measured-element-type-choice /= uint measurement-map = { ? &(mkey: 0) => $measured-element-type-choice &(mval: 1) => measurement-values-map ? &(authorized-by: 2) => [ + $crypto-key-type-choice ] } measurement-values-map = non-empty<{ ? &(version: 0) => version-map ? &(svn: 1) => svn-type-choice ? &(digests: 2) => [ + digest ] ? &(flags: 3) => flags-map ? ( &(raw-value: 4) => $raw-value-type-choice, ? &(raw-value-mask: 5) => raw-value-mask-type ) ? &(mac-addr: 6) => mac-addr-type-choice ? &(ip-addr: 7) => ip-addr-type-choice ? &(serial-number: 8) => text ? &(ueid: 9) => ueid-type ? &(uuid: 10) => uuid-type ? &(name: 11) => text * $$measurement-values-map-extension }> non-empty = (M) .and ({ + any => any }) oid-type = bytes tagged-oid-type = #6.111(oid-type) $raw-value-type-choice /= #6.560(bytes) raw-value-mask-type = bytes reference-triple-record = [ environment-map measurement-map ] stateful-environment-record = [ environment-map, measurement-map ] svn-type = uint svn = svn-type min-svn = svn-type tagged-svn = #6.552(svn) tagged-min-svn = #6.553(min-svn) svn-type-choice = tagged-svn / tagged-min-svn $tag-id-type-choice /= tstr $tag-id-type-choice /= uuid-type tag-identity-map = { &(tag-id: 0) => $tag-id-type-choice ? &(tag-version: 1) => tag-version-type } $tag-rel-type-choice /= &(supplements: 0) $tag-rel-type-choice /= &(replaces: 1) tag-version-type = uint .default 0 tagged-int-type = #6.551(int) triples-map = non-empty<{ ? &(reference-triples: 0) => [ + reference-triple-record ] ? &(endorsed-triples: 1) => [ + endorsed-triple-record ] ? &(identity-triples: 2) => [ + identity-triple-record ] ? &(attest-key-triples: 3) => [ + attest-key-triple-record ] ? &(dependency-triples: 4) => [ + domain-dependency-triple-record ] ? &(membership-triples: 5) => [ + domain-membership-triple-record ] ? &(coswid-triples: 6) => [ + coswid-triple-record ] ? &(conditional-endorsement-series-triples: 8) => [ + conditional-endorsement-series-triple-record ] ? &(conditional-endorsement-triples: 9) => [ + conditional-endorsement-triple-record ] * $$triples-map-extension }> ueid-type = bytes .size 33 tagged-ueid-type = #6.550(ueid-type) uuid-type = bytes .size 16 tagged-uuid-type = #6.37(uuid-type) version-map = { &(version: 0) => text ? &(version-scheme: 1) => $version-scheme } digest = [ alg: (int / text), val: bytes ] concise-swid-tag = { tag-id => text / bstr .size 16, tag-version => integer, ? corpus => bool, ? patch => bool, ? supplemental => bool, software-name => text, ? software-version => text, ? version-scheme => $version-scheme, ? media => text, ? software-meta => one-or-more, entity => one-or-more, ? link => one-or-more, ? payload-or-evidence, * $$coswid-extension, global-attributes, } payload-or-evidence //= ( payload => payload-entry ) payload-or-evidence //= ( evidence => evidence-entry ) any-uri = uri label = text / int $version-scheme /= multipartnumeric $version-scheme /= multipartnumeric-suffix $version-scheme /= alphanumeric $version-scheme /= decimal $version-scheme /= semver $version-scheme /= int / text any-attribute = ( label => one-or-more / one-or-more ) one-or-more = T / [ 2* T ] global-attributes = ( ? lang => text, * any-attribute, ) hash-entry = [ hash-alg-id: int, hash-value: bytes, ] entity-entry = { entity-name => text, ? reg-id => any-uri, role => one-or-more<$role>, ? thumbprint => hash-entry, * $$entity-extension, global-attributes, } $role /= tag-creator $role /= software-creator $role /= aggregator $role /= distributor $role /= licensor $role /= maintainer $role /= int / text link-entry = { ? artifact => text, href => any-uri, ? media => text, ? ownership => $ownership, rel => $rel, ? media-type => text, ? use => $use, * $$link-extension, global-attributes, } $ownership /= shared $ownership /= private $ownership /= abandon $ownership /= int / text $rel /= ancestor $rel /= component $rel /= feature $rel /= installationmedia $rel /= packageinstaller $rel /= parent $rel /= patches $rel /= requires $rel /= see-also $rel /= supersedes $rel /= supplemental $rel /= -256..64436 / text $use /= optional $use /= required $use /= recommended $use /= int / text software-meta-entry = { ? activation-status => text, ? channel-type => text, ? colloquial-version => text, ? description => text, ? edition => text, ? entitlement-data-required => bool, ? entitlement-key => text, ? generator => text / bstr .size 16, ? persistent-id => text, ? product => text, ? product-family => text, ? revision => text, ? summary => text, ? unspsc-code => text, ? unspsc-version => text, * $$software-meta-extension, global-attributes, } path-elements-group = ( ? directory => one-or-more, ? file => one-or-more, ) resource-collection = ( path-elements-group, ? process => one-or-more, ? resource => one-or-more, * $$resource-collection-extension, ) file-entry = { filesystem-item, ? size => uint, ? file-version => text, ? hash => hash-entry, * $$file-extension, global-attributes, } directory-entry = { filesystem-item, ? path-elements => { path-elements-group }, * $$directory-extension, global-attributes, } process-entry = { process-name => text, ? pid => integer, * $$process-extension, global-attributes, } resource-entry = { type => text, * $$resource-extension, global-attributes, } filesystem-item = ( ? key => bool, ? location => text, fs-name => text, ? root => text, ) payload-entry = { resource-collection, * $$payload-extension, global-attributes, } evidence-entry = { resource-collection, ? date => integer-time, ? device-id => text, ? location => text, * $$evidence-extension, global-attributes, } integer-time = #6.1(int) tag-id = 0 software-name = 1 entity = 2 evidence = 3 link = 4 software-meta = 5 payload = 6 hash = 7 corpus = 8 patch = 9 media = 10 supplemental = 11 tag-version = 12 software-version = 13 version-scheme = 14 lang = 15 directory = 16 file = 17 process = 18 resource = 19 size = 20 file-version = 21 key = 22 location = 23 fs-name = 24 root = 25 path-elements = 26 process-name = 27 pid = 28 type = 29 entity-name = 31 reg-id = 32 role = 33 thumbprint = 34 date = 35 device-id = 36 artifact = 37 href = 38 ownership = 39 rel = 40 media-type = 41 use = 42 activation-status = 43 channel-type = 44 colloquial-version = 45 description = 46 edition = 47 entitlement-data-required = 48 entitlement-key = 49 generator = 50 persistent-id = 51 product = 52 product-family = 53 revision = 54 summary = 55 unspsc-code = 56 unspsc-version = 57 multipartnumeric = 1 multipartnumeric-suffix = 2 alphanumeric = 3 decimal = 4 semver = 16384 tag-creator=1 software-creator=2 aggregator=3 distributor=4 licensor=5 maintainer=6 abandon=1 private=2 shared=3 ancestor=1 component=2 feature=3 installationmedia=4 packageinstaller=5 parent=6 patches=7 requires=8 see-also=9 supersedes=10 optional=1 required=2 recommended=3 ]]>

Acknowledgments for review and comments on this document.

Contributors Universität Bremen TZI

Postfach 330440 Bremen D-28359 Germany +49-421-218-63921 cabo@tzi.org

Carsten Bormann contributed to the CDDL specifications and the IANA considerations.