Grouping Triples into MTI and OTI #353

henkbirkholz · 2024-12-05T16:32:44Z

Introduced an MTI/OTI categorization in an updated version of the itemized list in Section 5 Concise Module Identifier (CoMID)
Added normative language MUST for MTI & SHOULD for OTI, including examples when it is okay not to implement OTI

This is a "first draft", which I am not marking as a draft so it can be bashed early and ferociously.

Signed-off-by: Thomas Fossati <[email protected]>

…n Sec5

yogeshbdeshpande · 2024-12-05T17:05:37Z

draft-ietf-rats-corim.md

-* `conditional-endorsement-triples` (index 10): Triples describing a series of
-  Endorsement that are applicable based on the acceptance of a series of
-  stateful environment records.
+* `conditional-endorsement-triples` (index 10): Triples describing a series of conditional Endorsements based on the acceptance of a stateful environment.


We should be consistent in stating either stateful environment or stateful environment records between conditional-endorsement-series-triples and conditional-endorsement-triples

Should this spec define a process for reclassifying OTI triples as MTI? For example, that a newer RFC could update an older RFC reclassifying from OTI to MTI or deprecating something (or is that obvious)?

We should be consistent in stating either stateful environment or stateful environment records between conditional-endorsement-series-triples and conditional-endorsement-triples

I don't understand the significance. Isn't it sufficient to refer to the triples based on the name used in triples-map?

Should this spec define a process for reclassifying OTI triples as MTI? For example, that a newer RFC could update an older RFC reclassifying from OTI to MTI or deprecating something (or is that obvious)?

A CoRIM profile can prescribe its own MTIs. It cannot makre MTI from the base spec OTI, but it can make existing OTI from the base spec MTI. I am not certain how to deal with MTI from profiles, but I assume that a profile can inherit triple semantics from other profiles as is or redefine them MTI or OTI.

A CoRIM profile can prescribe its own MTIs. It cannot makre MTI from the base spec OTI, but it can make existing OTI from the base spec MTI. I am not certain how to deal with MTI from profiles, but I assume that a profile can inherit triple semantics from other profiles as is or redefine them MTI or OTI.

I interpreted Ned's question to be about whether we should create a process here to regulate how MTI and OTI classes are allowed to move.
My answer is no, we don't. Let the future selves and fellow RATS decide how to deal based on accumulated wisdom.

Fair enough

yogeshbdeshpande · 2024-12-05T17:07:36Z

draft-ietf-rats-corim.md

@@ -487,18 +487,28 @@ A CoMID defines several types of Claims, using "triples" semantics.
 At a high level, a triple is a statement that links a subject to an object via a predicate.
 CoMID triples typically encode assertions made by the CoRIM author about Attesting or Target Environments and their security features, for example measurements, cryptographic key material, etc.

-The set of triples is extensible.
-The following triples are currently defined:
+This specification defines two sets of triples.


In general looks good to me!

yogeshbdeshpande

LGTM! for the MTI part

nedmsmith

multiple comments

draft-ietf-rats-corim.md

nedmsmith · 2024-12-05T18:49:15Z

draft-ietf-rats-corim.md

-The set of triples is extensible.
-The following triples are currently defined:
+This specification defines two sets of triples.
+The first set of triples is essential to the fundamental principles of Evidence appraisal as illustrated in {{-rats-arch}} and {{-rats-endorsement}} and is mandatory to implement (MTI).


Suggested change

The first set of triples is essential to the fundamental principles of Evidence appraisal as illustrated in {{-rats-arch}} and {{-rats-endorsement}} and is mandatory to implement (MTI).

The MTI class of triples is essential for basic appraisal processing as illustrated in {{-rats-arch}} and {{-rats-endorsement}}.

draft-ietf-rats-corim.md

nedmsmith · 2024-12-05T19:01:58Z

draft-ietf-rats-corim.md


 * Reference Values triples: containing Reference Values that are expected to match Evidence for a given Target Environment ({{sec-comid-triple-refval}}).
 * Endorsed Values triples: containing "Endorsed Values", i.e., features about an Environment that do not appear in Evidence. Specific examples include testing or certification data pertaining to a module ({{sec-comid-triple-endval}}).
+* Conditional Endorsement triples: describing one or more conditions that, once matched, result in augmenting the Attester's actual state with the supplied Endorsed Values ({{sec-comid-triple-cond-endors}}).
+* CoMID-CoSWID linking triples: associating a Target Environment with existing CoSWID Payload tags ({{sec-comid-triple-coswid}}).


Why is coswid mandatory? CoSWID has its own tag type and can be processed as part of corim without impacting comid. There is significant work required to create a comid-to-coswid mapping. Processing of coswids could be done independent from processing of comids.

There was some comment about it being in the base set of CoRIM contents: CoBOM, CoMID, CoSWID.

That's why I put it in there. The requirements might be external to the CoMID structure. The editors have to figure that out in the next meeting.

The requirements might be external to the CoMID structure.

Inclusion of different (from CoMID) tags in a corim doesn't obviate the need to map the other tags to CoMID. There can be a separate discussion (not necessarily in the CoRIM draft) for how to translate the external representation into an internal representation that doesn't have to be intrep. However, could be intrep too. That would be the topic for a design team to wrestle with. The coswid triples in comid could be lower priority to work on now since a mapping between a coswid internal representation with a comid internal representation would be useful pretext. It seems this sort of thing doesn't meet the criteria of something that is "base" capability for a comid engine.

nedmsmith · 2024-12-05T19:27:09Z

draft-ietf-rats-corim.md

 * Device Identity triples: containing cryptographic credentials - for example, an IDevID - uniquely identifying a device ({{sec-comid-triple-identity}}).
 * Attestation Key triples: containing cryptographic keys that are used to verify the integrity protection on the Evidence received from the Attester ({{sec-comid-triple-attest-key}}).
 * Domain dependency triples: describing trust relationships between domains, i.e., collection of related environments and their measurements ({{sec-comid-triple-domain-dependency}}).
 * Domain membership triples: describing topological relationships between (sub-)modules. For example, in a composite Attester comprising multiple sub-Attesters (sub-modules), this triple can be used to define the topological relationship between lead- and sub- Attester environments ({{sec-comid-triple-domain-membership}}).
-* CoMID-CoSWID linking triples: associating a Target Environment with existing CoSWID tags ({{sec-comid-triple-coswid}}).
+
+The set of triples is extensible and this document specifies an extension mechanism via profiles (see {{sec-extensibility}}). While the use of profiles can also define constraints that limit the types of triples processed by a Verifier, every Verifier MUST nevertheless implement and support triples specified as MTI in this document.


Suggested change

The set of triples is extensible and this document specifies an extension mechanism via profiles (see {{sec-extensibility}}). While the use of profiles can also define constraints that limit the types of triples processed by a Verifier, every Verifier MUST nevertheless implement and support triples specified as MTI in this document.

CoMID triples are extensible ({{sec-comid-triples}}). Triples added via the extensibility feature MUST be OTI class triples. This document specifies profiles (see {{sec-extensibility}}). OTI triples MAY be reclassified as MTI using a profile. Profiles MUST NOT reclassify MTI triples as OTI.

"OTI triples MAY be reclassified as MTI using a profile."

May be misinterpreted to say that a profile can reclassify an OTI to MTI globally.

I'd rather say: "Within the context of a profile, OTI triples MAY be reclassified as MTI."

"Profiles MUST NOT reclassify MTI triples as OTI."

OK, but also "Profiles can decide not to use MTI triples."

OK, but also "Profiles can decide not to use MTI triples."

Yes. I think that is unavoidable, but also see below.

nedmsmith · 2024-12-05T19:30:33Z

draft-ietf-rats-corim.md

-* `conditional-endorsement-triples` (index 10): Triples describing a series of
-  Endorsement that are applicable based on the acceptance of a series of
-  stateful environment records.
+* `conditional-endorsement-triples` (index 10): Triples describing a series of conditional Endorsements based on the acceptance of a stateful environment.


Should this spec define a process for reclassifying OTI triples as MTI? For example, that a newer RFC could update an older RFC reclassifying from OTI to MTI or deprecating something (or is that obvious)?

nedmsmith · 2024-12-05T19:32:21Z

draft-ietf-rats-corim.md

-* `conditional-endorsement-triples` (index 10): Triples describing a series of
-  Endorsement that are applicable based on the acceptance of a series of
-  stateful environment records.
+* `conditional-endorsement-triples` (index 10): Triples describing a series of conditional Endorsements based on the acceptance of a stateful environment.


We should be consistent in stating either stateful environment or stateful environment records between conditional-endorsement-series-triples and conditional-endorsement-triples

I don't understand the significance. Isn't it sufficient to refer to the triples based on the name used in triples-map?

Fix build errors and update Gemfile with latests cddl command

draft-ietf-rats-corim.md

Co-authored-by: Ned Smith <[email protected]>

Co-authored-by: Thomas Fossati <[email protected]>

thomas-fossati · 2024-12-10T13:43:55Z

draft-ietf-rats-corim.md

 * Device Identity triples: containing cryptographic credentials - for example, an IDevID - uniquely identifying a device ({{sec-comid-triple-identity}}).
 * Attestation Key triples: containing cryptographic keys that are used to verify the integrity protection on the Evidence received from the Attester ({{sec-comid-triple-attest-key}}).
 * Domain dependency triples: describing trust relationships between domains, i.e., collection of related environments and their measurements ({{sec-comid-triple-domain-dependency}}).
 * Domain membership triples: describing topological relationships between (sub-)modules. For example, in a composite Attester comprising multiple sub-Attesters (sub-modules), this triple can be used to define the topological relationship between lead- and sub- Attester environments ({{sec-comid-triple-domain-membership}}).
-* CoMID-CoSWID linking triples: associating a Target Environment with existing CoSWID tags ({{sec-comid-triple-coswid}}).
+
+The set of triples is extensible and this document specifies an extension mechanism via profiles (see {{sec-extensibility}}). While the use of profiles can also define constraints that limit the types of triples processed by a Verifier, every Verifier MUST nevertheless implement and support triples specified as MTI in this document.


Suggested change

The set of triples is extensible and this document specifies an extension mechanism via profiles (see {{sec-extensibility}}). While the use of profiles can also define constraints that limit the types of triples processed by a Verifier, every Verifier MUST nevertheless implement and support triples specified as MTI in this document.

CoMID triples are extensible ({{sec-comid-triples}}).

Triples added via the extensibility feature MUST be OTI class triples.

This document specifies profiles (see {{sec-extensibility}}).

OTI triples MAY be reclassified as MTI using a profile.

Conversely, profiles can choose not to _use_ certain MTI triples.

Profiles MUST NOT reclassify MTI triples as OTI.

This is Ned's proposal + L517 as per my comment.

@thomas-fossati line 513 usage of MTI triples in a profile is contradictory to usage supported on Line 517 of your suggested text. We need to polish the language that

Introduces generic text to say that it is required that Verifiers MUST implement MTI Triples.
However certain profile may choose to not implement certain MTI Triples, as per their own Appraisal policy!

Add a clarification: That Profiles cannot dictate an MTI behviour for all the Verifiers! (in a more clear way)

yogeshbdeshpande · 2024-12-11T15:16:41Z

draft-ietf-rats-corim.md

-The following triples are currently defined:
+This specification defines two classes of triples, the Mandatory to Implement (MTI) and the Optional to Implement (OTI).
+The MTI triples are essential to basic appraisal processing as illustrated in {{-rats-arch}} and {{-rats-endorsements}}.
+Every CoRIM Verifier MUST support the MTI triples.


Suggested change

Every CoRIM Verifier MUST support the MTI triples.

Every CoRIM Verifier MUST implement the MTI triples.

thomas-fossati and others added 2 commits December 5, 2024 14:41

fix: triples description

411195b

Signed-off-by: Thomas Fossati <[email protected]>

added an MTI/OTI split with corresponding text to the itemized list i…

2bac775

…n Sec5

henkbirkholz requested review from deeglaze, nedmsmith, thomas-fossati, yogeshbdeshpande and andrew-draper December 5, 2024 16:32

henkbirkholz changed the title ~~Grouping Triples into MIT and OTI~~ Grouping Triples into MTI and OTI Dec 5, 2024

yogeshbdeshpande reviewed Dec 5, 2024

View reviewed changes

yogeshbdeshpande approved these changes Dec 5, 2024

View reviewed changes

nedmsmith reviewed Dec 5, 2024

View reviewed changes

fix build errors

7a421ea

Fix build errors and update Gemfile with latests cddl command

nedmsmith reviewed Dec 5, 2024

View reviewed changes

draft-ietf-rats-corim.md Outdated Show resolved Hide resolved

henkbirkholz and others added 5 commits December 6, 2024 14:32

Update draft-ietf-rats-corim.md

3900b5d

Co-authored-by: Ned Smith <[email protected]>

Update draft-ietf-rats-corim.md

9aa506d

Co-authored-by: Ned Smith <[email protected]>

Update draft-ietf-rats-corim.md

f73c6d8

Co-authored-by: Thomas Fossati <[email protected]>

Update draft-ietf-rats-corim.md

16a5ff2

Co-authored-by: Thomas Fossati <[email protected]>

Update draft-ietf-rats-corim.md

48369be

thomas-fossati reviewed Dec 10, 2024

View reviewed changes

yogeshbdeshpande reviewed Dec 11, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Grouping Triples into MTI and OTI #353

Grouping Triples into MTI and OTI #353

henkbirkholz commented Dec 5, 2024

yogeshbdeshpande Dec 5, 2024

nedmsmith Dec 5, 2024

nedmsmith Dec 5, 2024

henkbirkholz Dec 6, 2024 •

edited

Loading

thomas-fossati Dec 6, 2024

henkbirkholz Dec 6, 2024

yogeshbdeshpande Dec 5, 2024

yogeshbdeshpande left a comment

nedmsmith left a comment

nedmsmith Dec 5, 2024

nedmsmith Dec 5, 2024

henkbirkholz Dec 6, 2024

nedmsmith Dec 6, 2024

nedmsmith Dec 5, 2024 •

edited by henkbirkholz

Loading

thomas-fossati Dec 6, 2024

thomas-fossati Dec 6, 2024

henkbirkholz Dec 6, 2024

nedmsmith Dec 5, 2024

nedmsmith Dec 5, 2024

thomas-fossati Dec 10, 2024 •

edited

Loading

thomas-fossati Dec 10, 2024

yogeshbdeshpande Dec 11, 2024

yogeshbdeshpande Dec 11, 2024

yogeshbdeshpande Dec 11, 2024

	The first set of triples is essential to the fundamental principles of Evidence appraisal as illustrated in {{-rats-arch}} and {{-rats-endorsement}} and is mandatory to implement (MTI).
	The MTI class of triples is essential for basic appraisal processing as illustrated in {{-rats-arch}} and {{-rats-endorsement}}.

	The set of triples is extensible and this document specifies an extension mechanism via profiles (see {{sec-extensibility}}). While the use of profiles can also define constraints that limit the types of triples processed by a Verifier, every Verifier MUST nevertheless implement and support triples specified as MTI in this document.
	CoMID triples are extensible ({{sec-comid-triples}}). Triples added via the extensibility feature MUST be OTI class triples. This document specifies profiles (see {{sec-extensibility}}). OTI triples MAY be reclassified as MTI using a profile. Profiles MUST NOT reclassify MTI triples as OTI.

-The set of triples is extensible and this document specifies an extension mechanism via profiles (see {{sec-extensibility}}). While the use of profiles can also define constraints that limit the types of triples processed by a Verifier, every Verifier MUST nevertheless implement and support triples specified as MTI in this document.
+CoMID triples are extensible ({{sec-comid-triples}}).
+Triples added via the extensibility feature MUST be OTI class triples.
+This document specifies profiles (see {{sec-extensibility}}).
+OTI triples MAY be reclassified as MTI using a profile.
+Conversely, profiles can choose not to _use_ certain MTI triples.
+Profiles MUST NOT reclassify MTI triples as OTI.

	Every CoRIM Verifier MUST support the MTI triples.
	Every CoRIM Verifier MUST implement the MTI triples.

Grouping Triples into MTI and OTI #353

Are you sure you want to change the base?

Grouping Triples into MTI and OTI #353

Conversation

henkbirkholz commented Dec 5, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

henkbirkholz Dec 6, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

yogeshbdeshpande left a comment

Choose a reason for hiding this comment

nedmsmith left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nedmsmith Dec 5, 2024 • edited by henkbirkholz Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

thomas-fossati Dec 10, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

henkbirkholz Dec 6, 2024 •

edited

Loading

nedmsmith Dec 5, 2024 •

edited by henkbirkholz

Loading

thomas-fossati Dec 10, 2024 •

edited

Loading