ietf-rats-wg / draft-ietf-rats-corim Goto Github PK
View Code? Open in Web Editor NEWLicense: Other
License: Other
We should have a way to indicate whether a CoRIM provides a delta update -- i.e., an entry in the update sequence (e.g.,
The updates
link relation should be used to create the linked CoRIMs list in the former case.
It should contain at least:
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:
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
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.
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:
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
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
)?
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 should provide clear and unambiguous definitions for (at least) the following terms:
CoRIM allows tags of type coswid. We should have examples that exercise this option.
$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
.
Populate the table from the contents found in cbor-tags.txt. Use the template below.
Tag | Data Item | Semantics | Reference |
---|---|---|---|
{{&SELF}} |
Provide an introduction to CoMID that contain at least:
Also think of where to put the triples high level description. Does that go only here or also detailed in §3.1.4 ?
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:
In the context of defining a triples lifecycle model such as:
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
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.
Describe SVN and "min" SVN.
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
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.
Provide a description of the Raw Values types. Also clarify why we need a type choice instead of just raw bytes.
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.
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!
Add needed CoRIM registries. Most likely this needs to be just copy-pasted from -02.
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
.
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
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).
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.
Carve out registry for BOM
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',
}
}
]
],
]
@cabo has made a proposal for managing CBOR numbers in Internet-Drafts, which we should consider.
Add needed CoMID registries. Most likely this needs to be just copy-pasted from -02.
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.
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"
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?
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.
Is it going in the right direction?
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
Add security and privacy considerations.
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?
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.
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
...
}
Provide a description of the extensibility features of CoRIM & CoMID.
Specifically, we need to document:
$$NAME-extension
) using the new registries$NAME-type-choice
) using CBOR tagsBesides, we need to define what we mean by "standard CoRIM type" (see the Profile Types section).
At present locator allows reference by URLs. Should we allow reference by corim-map.id
implying that the links are local to the verifier?
We added the authorized-by
field to the measurement-map
but forgot to document it in the Measuerments section.
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
Provide a description of a "tagged integer", in particular what purposes it serves.
Also, consider maybe a more evocative name.
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.
A section, description and cddl for conditional-reference-series-triple-record and reference-endorsed-record. Possibly, these should be divided into separate CDDL files.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.