ietf-rats-wg / draft-ietf-rats-corim Goto Github PK

Provide a description of a "tagged integer", in particular what purposes it serves.

Also, consider maybe a more evocative name.

At present locator allows reference by URLs. Should we allow reference by corim-map.id implying that the links are local to the verifier?

Add security and privacy considerations.

Provide a description of the Raw Values types. Also clarify why we need a type choice instead of just raw bytes.

There is a need to consider triple lifecycle e.g., CRUD where deletion at the triple level of granularity may be appropriate.

Delete should happen only if there is an error in the production of the CoRIM. Revocation is used when a triple assertion is de-asserted.

The existing CoMID has a ‘replaces’ relationship reason at the tag level of granularity. Is this adequate, or do we need a triple level deletion mechanism?

As an aside the lifecycle for triples might be:

• Create
• Revoke
• Update
• Delta update
• Evaluate?
• Delete

Carve out registry for BOM

There should be tagged tagged- definitions for the various types of tags that can be included in a corim.
for example a corim can contain these CBOR tagged structures:

$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)

but we don't have a way to refer to each as a CBOR tagged statement, such as:

tagged-concise-swid-tag = #6.505(bytes .cbor concise-swid-tag)
tagged-concise-mid-tag = #6.506(bytes .cbor concise-mid-tag)
tagged-concise-bom-tag = #6.508(bytes .cbor concise-bom-tag)

The $concise-tag-type-choice definitions could become:

$concise-tag-type-choice /= tagged-concise-swid-tag
$concise-tag-type-choice /= tagged-concise-mid-tag
$concise-tag-type-choice /= tagged-concise-bom-tag

xcorim is current method for revoking statements in a CoRIM. It is applied at RIM granularity, meaning all tags (and by extension all triples) in the RIM will be marked by Verifiers as 'revoked'.
Revocation at triple-level granularity in the form of ‘x-’ would offer greater precision in revoking statements (assertions) that are no longer true.

The current semantics for additional triples over the same triple subject (e.g., environment) are that these statements are additive to any previously asserted statements. Hence, issuing a 'new' triple doesn't have the semantics of replacing/invalidating the previous triple.

While it may be possible to use x-triples to revoke all triples in a RIM, don’t yet know if it makes sense to stop supporting xcorim as it addresses the use case where a RIM signing key is abused (but not where a private key is compromised), and an efficient method for walking back the abuse is needed / desirable.

The x-triple method is roughly characterized by creating a triple record that is identical to an existing triple record except for prepending 'x-' to the triple name and adding the field x-reason that identifies the reason for revoking the statement.

For example the triple:

reference-triple-record = [
  environment-map
  measurement-map
]

might have a revocation triple of the form:

x-reference-triple-record = [
  environment-map
  measurement-map
  ? refval-x-reason
]

$refval-x-reason /= obsolete
$refval-x-reason /= insecure

There should be a discussion as to whether x-reason should be optional.

Currently the existing CoRIM schema does not lend itself to natural expression for Providing Endorsements for SW updates.

This issue tracks the further work required in this area!

It is possible for not-well-behaved suppliers (endorsers / ref-val-providers) could assert authorship of reference values over another supplier who believes they have authorship privilege. A Verifier can detect this situation if the RIM issuing CA (or a higher level CA) ensures that the entity authorized to author reference values is named by the RIM.

The measurement-map can be extended with a statement that names the authoring entity as in:

measurement-map = {
...
? comid.authorized-by => [ + $crypto-key-type-choice ]
}
$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

Given the $crypto-key-type-choice names the supply chain entity that is authorized to provide measurements. If the certificate path used to sign the RIM includes a statement that acknowledges that entity as the measurement authoring authority, then Verifiers can check for consistency.

An attacker would have to convince the top level CA to grant it measurement issuing authority for the same set of measurements as the the other supplier or compromise the top level CA.

PR #56 replaced hash-entry with digest which added a text algorithm identifier. Hash entry used an integer algorithm identifier and has a dependency on coswid.

The goal was to allow COSE digest algorithm types.

The digest type should support a tagged digest type so that the exact semantics of which algorithm namespace and digest format can be specified.

We added the authorized-by field to the measurement-map but forgot to document it in the Measuerments section.

Add needed CoRIM registries. Most likely this needs to be just copy-pasted from -02.

corim-frags.mk lists the names of cddl files used to capture the various corim statements. When draft-ietf-rats-corim repo is a submodule to another repo, the list of cddl files are builid dependencies for profiles that depend on them. The list of dependencies needs to be updated if the corim repo updates the list.

It is difficult to reuse the corim-frags.mk file in a parent makefile because the pathnames default to the current folder. If the corim-frags.mk included a pathname macro then the parent makefile could define the pathname macro.

For example if an entry in corim-frags.mk was something like CORIM_FRAGS += $(CORIM_DIR)/corim.cddl and the parent makefile defined CORIM_DIR := draft-ietf-rats-corim/cddl then when the corim-frags.mk is imported into the parent makefile, the correct submodule path to the dependent files could be added without reentering a long list of dependencies.

We currently import hash-entry from CoSWID:

hash-entry = [
  hash-alg-id: int
  hash-value: bytes
]

which forces hash algorithm identifiers to be integer codes from IANA's named-information registry.

That's great, but imposes a dependency on yet another registry.

We could take instead the more merciful approach taken by RFC9360:

COSE_CertHash = [ hashAlg: (int / tstr), hashValue: bstr ]

which allows, for alg-ids, strings as an alternative to code points.

We should provide clear and unambiguous definitions for (at least) the following terms:

• endorsed values
• reference values
• environments
• triple

We currently allow raw keys, certified keys and cert chains as authorized-by types.

Another form of authorized-by could be a key thumbprint (e.g., PSA signer ID).

A section, description and cddl for conditional-reference-series-triple-record and reference-endorsed-record. Possibly, these should be divided into separate CDDL files.

Add needed CoMID registries. Most likely this needs to be just copy-pasted from -02.

reference, endorsed, and reference-endorsed triples support the idea that the object of the triple can be multi-valued. There are two use cases for its use. (a) when there are multiple of the same type measurements. For example, 'digest' or 'raw-value-group' where evidence is constructed so that the first digest is in the first array position and the second digest is in the second array position. Otherwise, the digests are not named (that is they share the same environment-map identity).

In the time series use case there is a single evidence value that is compared across multiple reference values. Reference values are ordered according to the series semantics (e.g., time) such that the measurement at position 0 is compared first, then the measurement at position 1 and so forth.

The verifier is undecided which comparison algorithm to apply unless the triple contains extra information. It is possible to use mkey to supply the extra information, but mkey (as part of measurement-map) should expect to match an mkey in Evidence as it becomes part of the evidence matching logic. Additionally, if mkey is deprecated this approach is no longer available to disambiguate the use cases.

A solution should include, at least, a boolean that indicates whether to apply time series vs. multi-valued attributes semantics.
It is best to keep it independent from the environment-map and the measurement-map structures as these carry matching semantics overhead.

Possible solutions:
(a) Add a flag for series:

reference-triple-record = [
  environment-map
  [ + measurement-map ]
]

measurement-map = {
  ? &(series: 0) => bool .default false
  &(mval: 1) => measurement-values-map
  ? &(authorized-by: 2) => [ + $crypto-key-type-choice ]
}

(b) Add another level of array:

measurement-map = {
  &(mval: 1) => [ + measurement-values-map ] ; If multiple array entries exist then apply series comparison semantics
  ? &(authorized-by: 2) => [ + $crypto-key-type-choice ]
}

(c) Don't deprecate mkey:

measurement-map = {
  ? &(mkey: 0) => $measured-element-type-choice
  &(mval: 1) => measurement-values-map
  ? &(authorized-by: 2) => [ + $crypto-key-type-choice ]
}
$measured-element-type-choice /= bool .default true ; only use the flag when series semantics are desired

I'd like to confirm that the following example reference value formats are both valid structures. Are they?

Each of these is designed to match against an attester providing evidence in the same format. The semantics of the two formats is intended to be the same (both convey two raw value measurements).

OIDs have been made up.

Separate environments:

  / comid.reference-triples / 0 : [
    [
      / environment-map / {
        / comid.class / 0 : {
          / comid.class-id / 0 : / 2.16.840.1.42.1 / 111(h'608648012A01') 
        }
      },
      [
        / measurement-map / {
          / comid.mval / 1 : {
            / comid.raw-value / 4 : h'12121212',
          }
        }
      ]
    ],
    [
      / environment-map / {
        / comid.class / 0 : {
          / comid.class-id / 0 : / 2.16.840.1.42.2 / 111(h'608648012A02') 
        }
      },
      [
        / measurement-map / {
          / comid.mval / 1 : {
            / comid.raw-value / 4 : h'5A5A5A5A',
          }
        }
      ]
    ],
  ]

Combined environments:

  / comid.reference-triples / 0 : [
    [
      / environment-map / {
        / comid.class / 0 : {
          / comid.class-id / 0 : / 2.16.840.1.42.1 / 111(h'608648012A01') 
        }
      },
      [
        / measurement-map / {
          / comid.mval / 1 : {
            / comid.raw-value / 4 : h'12121212',
            / private value / -1 : h'5A5A5A5A',
          }
        }
      ]
    ],
  ]

We should have a way to indicate whether a CoRIM provides a delta update -- i.e., an entry in the update sequence (e.g., $\delta_n$ in the chain: $\delta_{1} \leftarrow \delta_{2} \leftarrow \ldots \leftarrow \delta_{n}$) --, or the full set of deltas in one go, i.e. the whole chain.
The updates link relation should be used to create the linked CoRIMs list in the former case.

Describe SVN and "min" SVN.

I plan to add full descriptions of different types of matching rules and provide them in a future pull request.

I hope this is not controvertial (for example, integers should be compared as integers) but we need to make sure all edge cases are addressed.

If you are interested, the draft I will rewrite to fill in these sections is in the andrew-draper-verifier-processing branch

The TCG Endorsement Architecture spec can be used to justify the need for a block allocation from #6.500 to #6.599 from IANA CBOR tag registry.

Systems that build CoRIM might also be involved in building BOMs. We should make it clear that although such systems are likely to use the same input data, CoRIM and BOMs are different objects, with separate scope/applicability. A CoRIM serves the quite specific purpose of describing RATS target and attesting environments, in terms of their shape and aggregation, to attestation verifiers. This generally involves a different level of abstraction than that required for a BOM.

$domain-type-choice currently is:

$domain-type-choice /= uint
$domain-type-choice /= text
$domain-type-choice /= tagged-uuid-type

It is reasonable that an Environment identifier doubles as a domain for example a top level "device" environment may have endorsed values that apply to the entire device such as 'device-X is common criteria certified'. Device X would be a described by an endorsed-values-triple-record containing an environment-map and class-id in the form of a $class-id-type-choice .

$class-id-type-choice /= tagged-oid-type
$class-id-type-choice /= tagged-uuid-type
$class-id-type-choice /= tagged-int-type

There is existing overlap for tagged-uuid-type and the tagged-int-type and uint types could be easily mapped to achieve the use case goal. The tagged-uuid-type to domain id mapping could be achieved using text that contains an ascii OID representation, but that seems problematic. It is safer to add tagged-oid-type to $domain-type-choice.

We must clarify how a receiver is supposed to process unknown semantics.

Currently CoRIM does not have a way to say: "if you don’t understand this triple you should abort processing, because it contains critical semantics."

The implicit assumption (which we should clearly state) is that any such decision belongs to the definition of a CoRIM profile.

Additionally, we need to say

1. what is the default behaviour that all profiles should implement
2. what to do if a profile is not specified

CoRIM allows tags of type coswid. We should have examples that exercise this option.

It should contain at least:

• An overview of the CoRIM model
• A big-picture pic of the data structures and their relationships

It is likely that, for at least the measurement-values-map structure, the code point space could be large. There is competition for smaller code points (<2 bytes). Measurement-values-map contains both class and instance measurements which could grow over time as new forms of measurements are identified. Additionally, there could be profile-specific code points that have not, for whatever reason, been defined by a standard.

The corim specification should describe conventions for managing the limited resource code points (<2 bytes). For example, maps that are likely to be extended by profiles might do something like the following:

0 - 29: defined in the base CORIM for measurement-values-map
30 - 69: reserved for standards
70 - 99: reserved, for prototyping
100 - 255: available for profile specific use
 
Maybe it doesn't make sense to put "prototyping" in the <2byte range, but this is just an example.

In a perfect world, profile specific code points would be candidates for inclusion in a standard, if there is code point partitioning, that would require reassignment of a code points to the proper partition, which will break implementations, but maybe that is good?

A TCG specification extends the flags-map as follows:

;
; Flags map extensions
;
$$flags-map-extension //= (
  ? &(runtime-meas: 6) => bool
  ? &(immutable-meas: 7) => bool
  ? &(tcb-meas: 8) => bool
)

Should CoRIM incorporate this extension into the base (as several of the other extension have already been incorporated such as domain-dependency-triples)?

Currently we allow 0..n profile(s) in the CoRIM.

There is no way a receiver can unambiguously identify which profile applies to which of the embedded CoMIDs / CoSWIDs, which makes the ingestion process unnecessarily brittle.

We should allow 0..1 instead, and explain that - if present - the profile applies to all the embedded CoMIDs & CoSWIDs.

@cabo has made a proposal for managing CBOR numbers in Internet-Drafts, which we should consider.

Provide an introduction to CoMID that contain at least:

• An overview of the CoMID model
• A big-picture pic of the data structures and their relationships

Also think of where to put the triples high level description. Does that go only here or also detailed in §3.1.4 ?

Since cddl/corim-frags.mk reuses all the COMID_FRAGS defined in cddl/comid-frags.mk, we should just initialise CORIM_FRAGS from COMID_FRAGS.

see https://github.com/ietf-rats-wg/draft-ietf-rats-corim/wiki/Multiple--vs-Single-measurements-Environments

In the 11th Jan 2023 meeting we have identified the need for a new BOM (bill of material) object that tells the verifier what a complete set of tags looks like.

The BOM object must list all the needed tags (CoMID, CoSWIDs, CoTS) using their IDs.

Additionally, the BOM will indicate the validity period of the aggregate.

A BOM 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 BOM which activates that tag is received and successfully processed. All the tags listed in the BOM must be activated in the same transaction, i.e., either all or none.

In the context of defining a triples lifecycle model such as:

• create
• revoke
• evaluate
• delete
  The Evaluate step is probably least well defined. There is a recurrent debate around the static/dynamic nature of CoRIM.
  There may be two cases for Evaluate semantics,

1. Reference values are not ‘exact match’ wrt evidence values. That is to say reference measurements are of a different form than evidence measurements and Verifier matching is 'exact' matching. For example, a match could be true if evidence is with in a range of values.
2. One triple is used to define evidence while a different triple is needed for reference values.The ‘reference’ triple has predicate semantics and possibly subject / object syntax that are inappropriate for both reference and evidence.

There could be more to the evaluation as a result of Appraisal Policy for Evidence but use cases are needed. Possibly the trust anchors addition to CoRIM is one?

Given there may be a small collection of related triples - a 'family' of triples, the logic that relates the ‘family’ of triples may appropriately be Evaluation stage.

A state transition diagram might be:
C -> D, R, E
R -> D
E -> R, D

Text (temporarily) expunged:

Concise Reference Integrity Manifests (CoRIM) contain tags that describe the
composition and measurements of a platform, device, component, or software.

CoRIM is an envelope to carry information typically exchanged between Endorsers
and Verifiers {{-rats-arch}}. Endorsements are information produced by
Endorsers and consumed by Verifiers. CoRIM contains Endorsement Claims. Inside
CoRIM, Claims about hardware or firmware are described using CoMID tags.
Software Claims are described using CoSWID tags.

CoRIM can be integrity protected and authenticated using cryptography. The
CoRIM signer is the entity that asserts Endorsement Claims.  In a complex
supply chain, it is likely multiple Endorsers will produce CoRIMs, pertaining
to individual components they produce, at different times. Hence a CoRIM can
provide a link to other CoRIMs such that a combination of CoRIMs describe a
device class.

There are a couple of problems with that text:

1. it mentions RATS-ARCH but does not use the vocabulary correctly (specifically, it squashes together endorsements and ref-values into endorsements -- and their providers are merged accordingly)
2. there are some other clarity issues that popped up in a quick skimming session before submission of -03

Some attestation evidence collectors take DICE and SPDM measurements and put them into other formats, for example all class measurements might be used to extend a PCR.

Definitions:

• Class measurement = two devices configured with the same firmware, fuse values etc will have the same value for the measurement
• Instance measurement = two devices configured with the same firmware etc might have different values for the measurement, but the value does not change over time (if not reconfigured)
• Dynamic measurement = a single device may report different values for the measurement over time
  An example use for a dynamic measurement is a counter indicating how many times the device has been rebooted

Mixing different types of measurement in the same PCR causes problems. A class PCR provides information that the device is in a particular state while an instance PCR provides proof that the device is the same as last time.

Do we need a way for the evidence collector to determine the locality of a measurement without having to understand the difference between types of measurement?

Currently some instance measurement can be identified because their environment-map includes an instance field, but there are instance measurements which do not include instance in environment-map.

One way to fix this would be to add a field to environment-map, perhaps something like:
? &(scope: 3) => &(class-scope: 0) / &(instance-scope: 1) / &(dynamic-scope: 2)

This is primarily for use in evidence, but CoRIM reference values will need to match what the device reports

The profile-type-choice is an identifier (uri / oid) only. It should allow for a digest of the profile that can be integrity checked. Alternatively, the profile could be included directly in the RIM. This approach might extend $concise-tag-type-choice that defines a profile structure in which case the corim.profile element might be omitted.

If the profile is realized as a machine readable file (e.g. cddl) then the profile ID also should have a locator which may require a digest for integrity checking.
Note: Profile could extend CoRIM and could be included in the CoRIM.

Applying an update requires a way to represent the update to the CoRIM community. The linked-tag-relationship is an existing mechanism that probably should include 'update' as we currently have 'supplements' and 'replaces'. However, the specific details of how to apply the update may require a triple record.

The top-level Makefile does not invoke the check-co{rim,mid}-examples targets in the cddl folder. As a result the examples are not checked as part of the CI execution.

To handle a class of endorsements that are conditionally asserted based on acceptance of specific reference value(s), a new triple is needed.

;
; Triples map extension
;
 $$triples-map-extension //= (
  comid.endorsed-reference-triples => [+ endorsed-reference-triple-record]
)
comid.endorsed-reference-triples = 7

endorsed-reference-triple-record = [
  environment-map ; target environment
  [ + endorsed-reference-map ] ; reference values with endorsed values
]
endorsed-reference-map = non-empty<{
  ? comid.pos => uint ; position - avoids using mkey
  ? comid.refv => measurement-map, ; reference values
  ? comid.endv => measurement-map / measurement-values-map ; endorsed values
}>
comid.refv = 0
comid.endv = 1
comid.pos = 2

Note that profile-type-choice = uri / tagged-oid-type isn't an extensible type.
Given EAT profiles are defined differently: general-uri / general-oid and it makes sense to have profiles in other attestation messages such as AR and potentially appraisal policies.
It makes sense to define an extensible profile type.

Ideally:

$profile-type-choice /= uri
$profile-type-choice /= tagged-oid-type
$profile-type-choice /= general-uri
$profile-type-choice /= general-oid

and then

corim-map = {
...
  ? &(profile: 3) => $profile-type-choice
...
}

Populate the table from the contents found in cbor-tags.txt. Use the template below.

Verifier matching measurements from a single set of attestation environments

This issue uses the term Attestation Transport to describe the transport over which evidence was passed to the Verifier. A SPDM connection is an example of an Attestation Transport, it carries measurements from the SPDM Attestation Environment and from related DICE Attestation Environments within the same entity.

The simple use case for a Verifier is where it has received a set of measurements through a single Attestation Transport and it needs to match these against a CoMID tag containing reference values.

IMHO we should make the simple case easy to encode. I suggest that when matching a Reference Value Triple containing only environment-map and measurement-values-map, the Verifier must ensure that match them against evidence received from the same Attestation Transport. In some cases there may be multiple Attestation Environment groups which match against the same Reference Value Triple, if this happens then each group would receive an identical Endorsement.

For example, a CoMID tag encoding the semantics "If this device has a measurement identified by OID 1.2.3.4 and SHA-384 hash 0x5678 then the device is an Acme Ethernet Card version 1.0"

Verifier matching measurements from multiple attesters

Higher level Verifiers, or rather the CoRIMs controlling higher level Verifiers, will want to match against more complicated sets of evidence. For example, a CoRIM might want to encode the semantics Match against a type A PCIe card in slot 0, with firmware hash B, and against a second identical PCIe card in slot 1.

Do we need a way for a CoRIM to indicate that it must match against a set of evidence from one source (eg one Attestation Transport) and a potentially different set of evidence from a different source?

An example encoding of reference-values when matching against multiple Attestation Transports

I suggest that we use the mkey field to identify the attestor to be chosen.

For example, the following encoding encodes the two PCIe cards case above:

- Reference Value Triples
  - (first card)
    - Environment Map A
    - Measurement Map
      - mkey = K1
      - mvalue = B
  - (second card)
    - Environment Map A
    - Measurement Map
      - mkey = K2
      - mvalue = B

This would be associated with an Endorsement triple or similar providing more information about the combined system.

The exact values of K1 and K2 are not important, what is important is that all measurements with the same mkey value must come over the same Attestation Transport. Using the integer encoding of mkey normally produces the smallest encoding.

We might need a profile to enable this behavior.

I think this can be extended to multiple levels of compound devices, but wanted to get a sense of whether this is going in the right direction first.

Question

Is it going in the right direction?

Provide a description of the extensibility features of CoRIM & CoMID.

Specifically, we need to document:

• CDDL sockets ($$NAME-extension) using the new registries
• extensible type choices ($NAME-type-choice) using CBOR tags

Besides, we need to define what we mean by "standard CoRIM type" (see the Profile Types section).