Cond ref series triple branch

[nedmsmith]

Added section for conditional reference series triple.

[nedmsmith]

Closes issue #44.

[shnwc]

Suggested edits. The input evidence already has claims that match all the reference values in the matched record, so the reference values in that record should not be accepted again (which creates duplicates).

[nedmsmith]

change 'given' to 'if'

[nedmsmith]

Ned captured an issue raised by others: is there a syntactical bug with measurement-map / measurement-values-map?

[nedmsmith]

Note that tooling doesn't complain about syntax and examples pass schema checks. If there is a problem, it doesn't appear to be syntactical. The parser may be handed a byte string that could be either a measurement-map or measurement-values-map, but given one or the other may have failed a parsing test (but not both), chances are good the type of byte string would be included with the byte string to the parser. This would substitute for a well-known type such as a CBOR tag. In any case, it seem unlikely that a parser would be confused unless the first few bytes can satisfy both the measurement-map and measurement-values-map schema constraints and an implementation favors one over the other (incorrectly). Nevertheless, the use doesn't require supporting this much optionality, especially if the initial reference values are always measurement-maps and authorized-by, if used, applies to all measurements in the series data.

[shnwc]

The latest commits look good to me.

[shnwc]

I see that the term "claims" are used a few times. Wonder if it will be more clear to change all "endorsement measurements" to "endorsement claims"?

[nedmsmith]

A Claim is the combination of a named thing and its measurement(s). In this triple the triple subject is the named thing and the object is the set of measurements that are accepted. The measurement is more or less the triple object, but given a compound object like series records, the measurement could refer to either the reference or endorsed values. Given this understanding of Claim, does the proposed text still make sense?

[shnwc]

Yes, the existing proposed text still make sense.

[yogeshbdeshpande]

In my view we should have a simplified triple object that simply says that accept these values when the subject matches evidence.

This PR makes the individual conditional checking within the triple object far too complicated to have it in the main specifiction

[yogeshbdeshpande]

I feel the proposed changes are far too complex to be part of base specification:

What we can have is a simple statement as under:

; A supply chain actor would like to provision additional reference values or endorsed values,
; based on the simple condition that the subject specified using the given env and ref values
; matches the criterion specified by the Verifier
; Then we should leave it to individual schemes/profiles, how individual verifiers want to accept the series
; of reference and/or endorsed values specified within the object of the triple
based on their specific implementations

conditional-reference-series-triple-record = [
; triple subject
[ environment-map,
measurement-map ; initial reference values
]
; triple object - series of ref-end values
[ + ref-end-series-map ] ; not sure we need a series here as well, but retaining to clarify?
]

ref-end-series-map = non-emtpy <{
? [+measurement-values-map] ; reference values
? [+measurement-values-map] ; endorsed values
}>

[nedmsmith]

I’m not sure what is being proposed here. The CDDL below differs from what is proposed in the base draft. What is proposed below is arguably more complex as it puts arrays around each measurement-values-map in the inner triple renamed to ‘ref-end-series-map’. The proposal also changes a record to a map, but formats it as a record and makes both optional. As a record, making both optional leads to undecidability as we don’t know whether what is provided is a reference or an endorsement since both are optionally allowed. As a map, this could be resolved as each would have its own code point definition – but this example lacks specification of code points. Uplevelling, the concern seems to be with complexity. We need to establish a definition for complexity to justify whether what is initially proposed is “too” complex (or not). This definition will also help evaluate if counter-proposals are also “too” complex. The argument for why the current proposal isn’t too complex it that it addresses a real-world use case, as SGX and TDX are shipping features. There is a possible argument for wanting a triple that is usable more broadly. For example, maybe there is a user that wants to simply assert several endorsement values if a particular set of evidence / reference values are matched. This wouldn’t be possible with this triple because it requires ‘series’ matching semantics. But it was determined, early in the design of CoRIM/CoMID, that CoMID wanted the complexity to reside in the triples that encourages as many triples as necessary to satisfy a broad reach of users/use cases. I think the conditional-reference-series-triple holds true to these principles. The question of whether a triple should be included in a “base” / “standard” definition vs. is included in a profile is a question should be discussed head on. If we say that profiles are optional (which is what the CDDL says currently), but then say that generalized Verifiers must rely on a profile to determine which triples to implement, then we are mandating use of profiles in a roundabout way. If we assert that any triple that is defined in a standard means we highly recommend that generalized verifiers should implement the triple, then that means anyone can use the triple to author a manifest / evidence without first consulting the verifier community to ensure there is verifier support. Given there is a population of millions or billions of nodes, this should be reasonable criteria for it being included into the base / standard.

…

-Ned From: Yogesh Deshpande ***@***.***> Reply-To: ietf-rats-wg/draft-ietf-rats-corim ***@***.***> Date: Wednesday, February 15, 2023 at 5:46 AM To: ietf-rats-wg/draft-ietf-rats-corim ***@***.***> Cc: "Smith, Ned" ***@***.***>, Assign ***@***.***> Subject: Re: [ietf-rats-wg/draft-ietf-rats-corim] Cond ref series triple branch (PR #49) I feel the proposed changes are far too complex to be part of base specification: What we can have is a simple statement as under: ; A supply chain actor would like to provision additional reference values or endorsed values, ; based on the simple condition that the subject specified using the given env and ref values ; matches the criterion specified by the Verifier ; Then we should leave it to individual schemes/profiles, how individual verifiers want to accept the series ; of reference and/or endorsed values based on their specific implementations conditional-reference-series-triple-record = [ ; triple subject [ environment-map, measurement-map ; initial reference values ] ; triple object - series of ref-end values [ + ref-end-series-map ] ; not sure we need a series here as well, but retaining to clarify? ] ref-end-series-map = non-emtpy <{ ? [+measurement-values-map] ; reference values ? [+measurement-values-map] ; endorsed values }> — Reply to this email directly, view it on GitHub<#49 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABPMCSFV3CUOFSXTYALJDS3WXTMZNANCNFSM6AAAAAAUOLDLXU>. You are receiving this because you were assigned.Message ID: ***@***.***>

[nedmsmith]

Applied changes discussed as part of issue #44 - PR #49 is ready for review

[thomas-fossati]

Applied changes discussed as part of issue #44 - PR #49 is ready for review

I think we should use the CDDL in #44 (comment)

[nedmsmith]

I think we should use the CDDL in #44 (comment)

I thought I did. What is different?

[thomas-fossati]

I think we should use the CDDL in #44 (comment)

I thought I did. What is different?

sorry, my bad. I checked out a similarly named branch conditional-reference-series-triple-record and got utterly confused :-(

[thomas-fossati]

thanks, a few comments inlined

[thomas-fossati]

not related to this PR, just noting this duplicates L1

[shnwc]

LGTM.