Quantize inputs with a session initialization phase. #307

deeglaze · 2024-10-04T18:15:56Z

Closes Issue #242

The text already refers to an appraisal session and an appraisal context, but they are not introduced as concepts the same way the ACS is. Add Context and Session as specific constructs that serve distinct purposes.

I think the "CoRIMs are collected" text is a bit too vague, so I put all input fetching in phase 0. Validation and transformation is in phase 1.

I found it weird that Evidence Collection was not part of input gathering, so I've moved it.

This change clarifies the meaning of "active" and "inactive", and what "requires CoBOMs" means. It's just whether all available tags are included in the search space or only referenced ones are. A CoBOM is not a bundle of tags the way a CoRIM is. A CoBOM must reference tags that are already in the input set. It just flips them to being usable in the appraisal procedure.

I did not provide CDDL for the session or context since I think that needs to be sequenced after PR#299.

thomas-fossati

Nice.

draft-ietf-rats-corim.md

thomas-fossati · 2024-10-04T18:44:12Z

draft-ietf-rats-corim.md

+During this setup phase, the Verifier populates its Appraisal Session with a consistent view of all its inputs to the Appraisal Procedure.
+Inputs are various conceptual messages collected from Reference Value Providers, Endorsers, Verifier Owners, and Attesters.
+Conceptual messages may include Attestation Evidence, CoMID tags {{sec-comid}}, CoSWID tags {{-coswid}}, CoBOM tags {{sec-cobom}}, and static cryptographic validation key material (including raw public keys, root certificates, intermediate CA certificate chains, and Concise Trust Anchor Stores (CoTS) {{-ta-store}}.
+It is left to Verifier Policy to determine if input sources must use supply chain transparency constructs (see {{-scitt-arch}}) to track input provenance.


I expect the Policy to be under the complete control of the Verifier Owner.
However, auditability and traceability requirements may also be imposed by the external regulatory context.

Verifier Policy can be to follow regulations or not. I didn't want to add speculation about this spec going to regulators as a framework.

Understood. The thing is 9334's definition of policy is:

"A set of rules that a Verifier uses to evaluate the validity of information about an Attester."

which would make any regulatory aspects out of scope.

thomas-fossati · 2024-10-04T18:48:43Z

draft-ietf-rats-corim.md

+
+The time at which the Verifier evaluates certificate- and tag-validity is an input.
+Once the Appraisal Session inputs are collected, no more may be added to the Appraisal Session apart from one exception.
+Certificate revocation status results may be collected during Phase 1, since there is no collective simultaneity of all responses.


OK, but this may or may not be an issue in practice. "Some" clock skew is typically taken into account when comparing time bounds during validation. I am not expecting Phase 0 and Phase 1 to be far apart enough to dwarf normal tolerances.

Sounds like you're saying I should allow for the wall clock input to also be collected multiple times during Phase 1? I'm just trying to temper all sources of external influence on the hermeticity of an appraisal.

I am just pointing out that creating an exception just for revocation checks to the general rule that "Phase 0 locks all inputs" is probably unnecessary. If we go without, the loss of functionality doesn't seem too big, given:

Temporal distance between Phases 0 and 1 is likely to be (very) short, and

Some clock skew tolerance will be in place anyway, making the boundaries between 0 and 1 even fuzzier.

Moved the lock to be back at the end of Appraisal Context construction then.

draft-ietf-rats-corim.md

nedmsmith · 2024-10-04T23:48:40Z

draft-ietf-rats-corim.md


-After context initialization, additional inputs are held back until appraisal processing has completed.
+No inputs other than dynamically-fetched information about certificate revocation status (see {{RFC6960}}, and {{Section 4.2.1.13 of -pkix-cert}}) may be collected in Phase 1.


I thought the previous text was better / orthogonal to the suggested text.

Suggested change

No inputs other than dynamically-fetched information about certificate revocation status (see {{RFC6960}}, and {{Section 4.2.1.13 of -pkix-cert}}) may be collected in Phase 1.

After the Appraisal Context is initialized, appraisal processing is allowed to complete before new inputs are considered.

I thought the previous text was better / orthogonal to the suggested text.

The “allowed” worries me, since we don’t require monotonic matching conditions for profiles and mid-appraisal additions of tags can lead to inconsistent ACS results.

Party pooper mode on. (For different reasons) I don't like either 🤣

I've added a hermeticity subsection to describe this without any need for operational suggestions like having inputs be "held back".

draft-ietf-rats-corim.md

thomas-fossati · 2024-10-05T18:20:32Z

draft-ietf-rats-corim.md


-After context initialization, additional inputs are held back until appraisal processing has completed.
+No inputs other than dynamically-fetched information about certificate revocation status (see {{RFC6960}}, and {{Section 4.2.1.13 of -pkix-cert}}) may be collected in Phase 1.


Party pooper mode on. (For different reasons) I don't like either 🤣

deeglaze · 2024-10-05T21:21:43Z

draft-ietf-rats-corim.md

+The same Appraisal Context processed at any time MUST produce the same Attestation Results.
+
+The reason to lock the inputs before Attestation Appraisal is to ensure consistent ACS construction when accounting for any profile-driven semantics.


Please help wordsmith this. There are obviously different levels of hermeticity and auditability that Verifier policy will impose. I don't want to require absolute determinism since that imposes a requirement on policy evaluation.
I don't like "same" since we're not prescribing any Attestation Result construction or representation, so there is no strong notion of sameness.

If we go with

Suggested change

The same Appraisal Context processed at any time MUST produce the same Attestation Results.

The reason to lock the inputs before Attestation Appraisal is to ensure consistent ACS construction when accounting for any profile-driven semantics.

The reason to lock the inputs before Attestation Appraisal is for all Appraisal Procedure dependencies to be accounted for before interpreting them.

Fully determined inputs SHOULD ensure consistent ACS construction when accounting for any profile-driven semantics.

I agree that the old L1906 is not 100% correct: it should probably have said instead:

The same Appraisal Context processed at any time MUST produce the same ACS.

I like the text you suggest. The only thing is we should state more strongly that what we are trying to achieve is deterministic ACS construction.

Fully determined inputs SHOULD ensure consistent ACS construction when accounting for any profile-driven semantics.

Suggested change

The same Appraisal Context processed at any time MUST produce the same Attestation Results.

The reason to lock the inputs before Attestation Appraisal is to ensure consistent ACS construction when accounting for any profile-driven semantics.

Given the same Appraisal Context, different Verifier appraisals MUST produce deterministic results.

Verifier inputs are locked (see Phase 0) before Attestation Appraisal to ensure ACS construction is deterministic.

Text above addresses the question of profile or policy inputs rendering non-deterministic ACS results.

thomas-fossati · 2024-10-06T14:12:07Z

draft-ietf-rats-corim.md

@@ -1464,6 +1463,10 @@ They are not required to use the same internal representation or evaluation orde

 The appraisal procedure is divided into several logical phases for clarity.

+ **Phase 0**: Session setup
+
+During Phase 0, the Verifier collects its set of inputs from external sources that will be used for the remainder of the Appraisal Procedure to ensure the Procedure is deterministic.


The deterministic nature is ensured by the consistency of the appraisal algorithm.

Suggested change

During Phase 0, the Verifier collects its set of inputs from external sources that will be used for the remainder of the Appraisal Procedure to ensure the Procedure is deterministic.

During Phase 0, the Verifier collects its set of inputs from external sources that will be used for the remainder of the Appraisal Procedure.

The appraisal algorithm is deterministic for the base CDDL, but profiles can define their own comparison algorithms that can be complex and have computational timeouts that lead to nondeterministic results (for example). Considering the SLSA level 4 language about hermeticity and reproducibility, we should have wording about best-effort reproducibility https://slsa.dev/spec/v0.1/requirements

If we consider a Verifier to be a "builder" of attestation results, then we can apply the same requirements whole sale.

Hmm, even with profile-specific comparison algorithms (or other kinds of custom behaviour), successful ACS computation should be deterministic.

If computational timeouts, or other conditions that make the ACS "incomplete", happen, they must be made fully visible to the downstream appraisal policy.

Suppose we have a profile that has unification variables that are allowed in conditions and in additions. The logic it employs for unification does not have principal types, so there are multiple incomparable correct solutions to a system of constraints. Which substitution it resolves on can be dependent on something nondeterministic like hash map iteration order. The resulting ACS is not consistently reproducible in this case, the way a compiler can choose which way it allocates registers or orders if/then/else basic blocks.

I'm not saying it's sensible, I'm saying it's not ruled out and it is very difficult to rule out. Thus a SHOULD be reproducible.

Suppose we have a profile that has unification variables that are allowed in conditions and in additions. The logic it employs for unification does not have principal types, so there are multiple incomparable correct solutions to a system of constraints. Which substitution it resolves on can be dependent on something nondeterministic like hash map iteration order. The resulting ACS is not consistently reproducible in this case, the way a compiler can choose which way it allocates registers or orders if/then/else basic blocks.

This is an interesting observation. However, ...

I'm not saying it's sensible, I'm saying it's not ruled out and it is very difficult to rule out. Thus a SHOULD be reproducible.

... the conclusion I draw from this is that we should clearly say: "profiles MUST NOT introduce randomized behaviour."

IMO one core promise we make to downstream ACS consumers is that given the same input, a CoRIM appraiser always computes the same predictable output.

Any non-deterministic behaviour creates confusion at best, whilst in the worst case it can be used by an attacker to subvert the overall appraisal outcome.

We've already said that certain decisions can be make by policy. Are those decisions made strictly after phase 4? If we can say phases 2, 3, and 4 must be deterministic without imposing policy burden by the way we define semantics, then I'd certainly like to make that declaration.

I don't think profiles would be introducing randomized behavior. Non-deterministic isn't necessarily random. You can have "the same" outcome by means of equivalence but not syntactic equality. When we're talking about ACS construction we're making representation choices that may be more conducive to equal outputs than something that uses, say, hash maps or algebraic constructions that represent "the same object" in multiple ways.

We've already said that certain decisions can be make by policy. Are those decisions made strictly after phase 4?

yes

If we can say phases 2, 3, and 4 must be deterministic without imposing policy burden by the way we define semantics, then I'd certainly like to make that declaration.

👍

I don't think profiles would be introducing randomized behavior. Non-deterministic isn't necessarily random. You can have "the same" outcome by means of equivalence but not syntactic equality. When we're talking about ACS construction we're making representation choices that may be more conducive to equal outputs than something that uses, say, hash maps or algebraic constructions that represent "the same object" in multiple ways.

Got it. Then:

"profiles MUST NOT introduce non-deterministic behaviour."

We've already said that certain decisions can be make by policy. Are those decisions made strictly after phase 4?

yes

Regardless of which phase is active, phase 0 is described as collecting all the inputs. This includes policies IMO. That is how we assert consistent behavior resulting in an ACS that is the same for different Verifiers.

... the conclusion I draw from this is that we should clearly say: "profiles MUST NOT introduce randomized behaviour."

I agree. It also extends to policies. They can't introduce randomized behavior either. Otherwise, different Verifiers will get different ACS results.

draft-ietf-rats-corim.md

thomas-fossati · 2024-10-06T14:25:00Z

draft-ietf-rats-corim.md

+Selected CoRIMs are transformed into an internal representation (see {{sec-phase1-trans}}).
+If CoBOMs are required by policy, the selected tags are considered *inactive*.
+An *inactive* tag MUST NOT be used during the Appraisal Procedure.


I find this way of presenting activation/disactivation a bit puzzling.

I see the flow from undecided/unknown to either active or inactive.
It'd be probably easier to grok if we introduced an initial "unknown" state and describe the decision tree as:

flowchart TD A[unknown] --> C{use_cobom} C -->|true| D{is_listed} C -->|false| E[active] D -->|true| F[active] D -->|false| G[inactive]

Loading

A diagram like this would be helpful IMO.

A diagram like this would be helpful IMO.

But maybe the diagram should be backed out of this PR until the tooling issues can be addressed. It's difficult to suggest changes when it doesn't build.

thomas-fossati · 2024-10-06T14:26:37Z

draft-ietf-rats-corim.md


-This section is not applicable if the Verifier appraisal policy does not require CoBOMs.
+This step can be skipped of all tags are implicitly active.


Doesn't read right to this non-native speeker. Did you mean s/of/if/? Or something else?

Regardless, I prefer it stupid and explicit, as it was before :-)
Unless you see a case that would not be covered using the old phrasing.

Yes s/of/if/, typo.

thomas-fossati · 2024-10-06T14:34:27Z

draft-ietf-rats-corim.md

+The same Appraisal Context processed at any time MUST produce the same Attestation Results.
+
+The reason to lock the inputs before Attestation Appraisal is to ensure consistent ACS construction when accounting for any profile-driven semantics.


I agree that the old L1906 is not 100% correct: it should probably have said instead:

The same Appraisal Context processed at any time MUST produce the same ACS.

I like the text you suggest. The only thing is we should state more strongly that what we are trying to achieve is deterministic ACS construction.

nedmsmith · 2024-10-08T22:15:04Z

draft-ietf-rats-corim.md

+Selected CoRIMs are transformed into an internal representation (see {{sec-phase1-trans}}).
+If CoBOMs are required by policy, the selected tags are considered *inactive*.
+An *inactive* tag MUST NOT be used during the Appraisal Procedure.


A diagram like this would be helpful IMO.

nedmsmith · 2024-10-08T22:35:22Z

draft-ietf-rats-corim.md


 CoBOMs which are not within their validity period are discarded.
-
-The Verifier processes all CoBOMs that are valid at the point in time of Evidence Appraisal and activates all tags referenced therein.
+The Verifier processes all CoBOMs that are valid at the point in time of Evidence Appraisal.


Shouldn't this reflect the previous text for phase 1 where all inputs are resolved including coboms? This should be when activation happens so that the set of inputs is deterministically known before progressing to phase 2.

nedmsmith · 2024-10-08T23:18:26Z

draft-ietf-rats-corim.md

+The same Appraisal Context processed at any time MUST produce the same Attestation Results.
+
+The reason to lock the inputs before Attestation Appraisal is to ensure consistent ACS construction when accounting for any profile-driven semantics.


Fully determined inputs SHOULD ensure consistent ACS construction when accounting for any profile-driven semantics.

Suggested change

The same Appraisal Context processed at any time MUST produce the same Attestation Results.

The reason to lock the inputs before Attestation Appraisal is to ensure consistent ACS construction when accounting for any profile-driven semantics.

Given the same Appraisal Context, different Verifier appraisals MUST produce deterministic results.

Verifier inputs are locked (see Phase 0) before Attestation Appraisal to ensure ACS construction is deterministic.

Text above addresses the question of profile or policy inputs rendering non-deterministic ACS results.

draft-ietf-rats-corim.md

thomas-fossati · 2024-10-11T07:56:12Z

draft-ietf-rats-corim.md

+flowchart TD
+    A[unknown] --> C{use_cobom}
+    C -->|true| D{is_listed}
+    C -->|false| E[active]
+    D -->|true| F[active]
+    D -->|false| G[inactive]


It'd be nice, isn't it :-) but I don't think this will work as you expect.

You need to tell the processor that it needs to dispatch the block to mermaid, i.e.:

Suggested change

flowchart TD

A[unknown] --> C{use_cobom}

C -->|true| D{is_listed}

C -->|false| E[active]

D -->|true| F[active]

D -->|false| G[inactive]

~~~mermaid

flowchart TD

A[unknown] --> C{use_cobom}

C -->|true| D{is_listed}

C -->|false| E[active]

D -->|true| F[active]

D -->|false| G[inactive]

~~~

mermaid-cli must be installed both in your dev environment and the CI

Currently, mmdc produces SVG that doesn't makes svgcheck unhappy.

All that to say that diagramming in I-Ds is still mostly an (ASCII) art.

For more info see martinthomson/i-d-template#416

The referenced issue does not appear to have solved the problem. Do you know if this change would work?

I believe it wouldn't because of point 3 (i.e., mmdc not producing conformant SVG)

nedmsmith · 2024-10-11T17:36:03Z

cddl/intrep-actx.cddl

+  ev : [ ev ]
+  evs : [ evs ]
+  ACS: ACS
+  extra: any


Suggested change

extra: any

ar : [ ar ]

ARS: ARS

These are defined by the internal representation but omitted from the appraisal context. Was this on purpose?
What is extra for? If it is extensibility, a future I-D can extend the model as needed and update the representation appropriately.

Extra in actx is meant to capture implementation-specific details. I could leave it unsaid, but I don't want to make appraisal seem like it can only consider the spec's types.

I don't think actx should contain ar or ARS since that's a phase after the ACS is fully constructed. actx should just be for processing determined-good inputs to a final ACS.

draft-ietf-rats-corim.md

cddl/intrep-actx.cddl

nedmsmith · 2024-10-11T18:11:40Z

draft-ietf-rats-corim.md


-Later stages will further select the CoRIMs appropriate to the Evidence Appraisal stage.
+How the Verifier collects its inputs is out of scope of this document.
+There will be some amount of CoRIMs and standalone tags available as inputs that make an `asession`:


Trying to define an internal representation for a wide variety of inputs, each having potentially vastly different representations invites unnecessary scrutiny to the internal representation. It seems sufficient to describe the session as the set of inputs (line 1770) collected within some window of time (line 1771). We don't want to try to define a session format for all these inputs IMHO and the current definition doesn't account for all these inputs.

Okay, I'll remove the internal representation and leave the description to the prose of the Verifier Abstraction.

draft-ietf-rats-corim.md

nedmsmith · 2024-10-11T19:16:58Z

draft-ietf-rats-corim.md

-These objects will be utilized in the Evidence Appraisal phase that follows.
-The primary goal of this phase is to ensure that all necessary information is available for subsequent processing.
+An Appraisal Session includes Verifier-specific session state as well as a collection of inputs to process.
+Conceptual Messages are given explicit representation in the session.


This doesn't seem to be saying much. An explanation of each member of ir-appraisal-session would communicate that a session context includes an internal representation of the CMs. It likely would describe assumptions for how to populate it?

nedmsmith · 2024-10-11T19:23:36Z

draft-ietf-rats-corim.md


-Other selection criteria MAY be applied.
-For example, if the Evidence format is known in advance, CoRIMs using a profile that is not understood by a Verifier can be readily discarded.
+The exchange of a request for attestation appraisal for a response of Attestation Results corresponds to a single Attestation Session.


I'm not sure why we need to talk about Attestation Results as part of forming an appraisal context (and vetting its inputs).

It's not. The results are produced at the end of a session. An Appraisal Context is only for getting to the end of constructing the ACS. It's a bit matryoshka doll-ish.

nedmsmith · 2024-10-11T19:31:11Z

draft-ietf-rats-corim.md

-During the initialization phase, the CoRIM Appraisal Context is loaded with various conceptual message inputs such as CoMID tags ({{sec-comid}}), CoSWID tags {{-coswid}}, CoBOM tags {{-cobom}}, and cryptographic validation key material (including raw public keys, root certificates, intermediate CA certificate chains), and Concise Trust Anchor Stores (CoTS) {{-ta-store}}.
-These objects will be utilized in the Evidence Appraisal phase that follows.
-The primary goal of this phase is to ensure that all necessary information is available for subsequent processing.
+An Appraisal Session includes Verifier-specific session state as well as a collection of inputs to process.


Suggested change

An Appraisal Session includes Verifier-specific session state as well as a collection of inputs to process.

An Appraisal Session contains an Appraisal Context that contains validated inputs used by the Appraisal Procedure.

nedmsmith · 2024-10-11T20:12:54Z

I tried to build on local environment after installing mermaid-cli but still get errors.
Also, the branch seems to be significantly behind main - getting build warnings that have been fixed in main.

The text already refers to an appraisal session and an appraisal context, but they are not introduced as concepts the same way the ACS is. Add Context and Session as specific constructs that serve distinct purposes. I think the "CoRIMs are collected" text is a bit too vague, so I put all input fetching in phase 0. Validation and transformation is in phase 1. I found it weird that Evidence Collection was not part of input gathering, so I've moved it. This change clarifies the meaning of "active" and "inactive", and what "requires CoBOMs" means. It's just whether all available tags are included in the search space or only referenced ones are. A CoBOM is not a bundle of tags the way a CoRIM is. A CoBOM must reference tags that are already in the input set. It just flips them to being usable in the appraisal procedure. I did not provide CDDL for the session or context since I think that needs to be sequenced after PR#299. Signed-off-by: Dionna Glaze <[email protected]>

Also refer to CRL distribution points from RFC5280.

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

Verifier Policy on its own doesn't apparently carry enough weight about its responsibilities, so I've added a note. Added Ned's Evidence Selection subsection. Added a new hermeticity subsection to describe why we freeze inputs before performing appraisal.

Includes a note about conditional endorsements needing fixed point computation since they're not ramified the way that evidence and reference values are.

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

Minor editorial changes.

…o quant

draft-ietf-rats-corim.md

Co-authored-by: Yogesh Deshpande <[email protected]>

yogeshbdeshpande · 2024-11-20T14:46:30Z

draft-ietf-rats-corim.md

+
+### Input Collection {#sec-phase1-collect}
+
+The exchange of a request for attestation appraisal for a response of Attestation Results corresponds to a single Attestation Session.


Suggested change

The exchange of a request for attestation appraisal for a response of Attestation Results corresponds to a single Attestation Session.

A single attestation session is a period when attestation appraisal process is initiated upon Verifier receiving Evidence from Attester or Relying Party and generating the results of the Appraisal.

Co-authored-by: Yogesh Deshpande <[email protected]>

yogeshbdeshpande · 2025-01-29T14:52:22Z

draft-ietf-rats-corim.md


-The selection process MUST yield at least one usable tag.
+> The selection process MUST yield at least one usable conceptual message.


Need to discuss this..

deeglaze requested review from henkbirkholz, thomas-fossati, yogeshbdeshpande and nedmsmith as code owners October 4, 2024 18:15

deeglaze force-pushed the quant branch 2 times, most recently from 1b28e20 to 31e0804 Compare October 4, 2024 18:24

thomas-fossati reviewed Oct 4, 2024

View reviewed changes

deeglaze force-pushed the quant branch from 4efb13b to 1006450 Compare October 4, 2024 21:56

nedmsmith reviewed Oct 4, 2024

View reviewed changes

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

nedmsmith reviewed Oct 4, 2024

View reviewed changes

nedmsmith requested changes Oct 5, 2024

View reviewed changes

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

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

thomas-fossati reviewed Oct 5, 2024

View reviewed changes

deeglaze commented Oct 5, 2024

View reviewed changes

thomas-fossati reviewed Oct 6, 2024

View reviewed changes

nedmsmith reviewed Oct 8, 2024

View reviewed changes

thomas-fossati reviewed Oct 11, 2024

View reviewed changes

nedmsmith reviewed Oct 11, 2024

View reviewed changes

deeglaze and others added 9 commits October 12, 2024 20:02

Add informative RFC reference for OCSP

259e273

Also refer to CRL distribution points from RFC5280.

Update draft-ietf-rats-corim.md

fccba47

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

Update draft-ietf-rats-corim.md

30be5c8

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

Add tag status evolution.

b992e05

Hermeticity attempt 3

bfe9bab

Remove normative language about phases 5, 6, and 7.

c2fe37c

Specify session/context/activity

367d01e

Includes a note about conditional endorsements needing fixed point computation since they're not ramified the way that evidence and reference values are.

deeglaze force-pushed the quant branch from a2b5889 to 367d01e Compare October 12, 2024 20:04

deeglaze and others added 2 commits October 12, 2024 20:05

Remove flowchart.

605860f

Update draft-ietf-rats-corim.md

6a70abf

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

deeglaze and others added 3 commits October 12, 2024 13:16

Update draft-ietf-rats-corim.md

0cbd439

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

Reference cleanup

5599738

Minor editorial changes.

Merge branch 'quant' of github.com:deeglaze/draft-ietf-rats-corim int…

fa79af0

…o quant

yogeshbdeshpande reviewed Nov 20, 2024

View reviewed changes

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

yogeshbdeshpande reviewed Nov 20, 2024

View reviewed changes

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

Update draft-ietf-rats-corim.md

7fb65c7

Co-authored-by: Yogesh Deshpande <[email protected]>

yogeshbdeshpande reviewed Nov 20, 2024

View reviewed changes

Update draft-ietf-rats-corim.md

d257e50

Co-authored-by: Yogesh Deshpande <[email protected]>

yogeshbdeshpande reviewed Jan 29, 2025

View reviewed changes

nedmsmith mentioned this pull request Jan 29, 2025

Is CoBOM (now CoTL) Extensible? #368

Open


		After context initialization, additional inputs are held back until appraisal processing has completed.
		No inputs other than dynamically-fetched information about certificate revocation status (see {{RFC6960}}, and {{Section 4.2.1.13 of -pkix-cert}}) may be collected in Phase 1.

	No inputs other than dynamically-fetched information about certificate revocation status (see {{RFC6960}}, and {{Section 4.2.1.13 of -pkix-cert}}) may be collected in Phase 1.
	After the Appraisal Context is initialized, appraisal processing is allowed to complete before new inputs are considered.

		The same Appraisal Context processed at any time MUST produce the same Attestation Results.

		The reason to lock the inputs before Attestation Appraisal is to ensure consistent ACS construction when accounting for any profile-driven semantics.

	During Phase 0, the Verifier collects its set of inputs from external sources that will be used for the remainder of the Appraisal Procedure to ensure the Procedure is deterministic.
	During Phase 0, the Verifier collects its set of inputs from external sources that will be used for the remainder of the Appraisal Procedure.


		This section is not applicable if the Verifier appraisal policy does not require CoBOMs.
		This step can be skipped of all tags are implicitly active.

	An Appraisal Session includes Verifier-specific session state as well as a collection of inputs to process.
	An Appraisal Session contains an Appraisal Context that contains validated inputs used by the Appraisal Procedure.


		### Input Collection {#sec-phase1-collect}

		The exchange of a request for attestation appraisal for a response of Attestation Results corresponds to a single Attestation Session.

	The exchange of a request for attestation appraisal for a response of Attestation Results corresponds to a single Attestation Session.
	A single attestation session is a period when attestation appraisal process is initiated upon Verifier receiving Evidence from Attester or Relying Party and generating the results of the Appraisal.


		The selection process MUST yield at least one usable tag.
		> The selection process MUST yield at least one usable conceptual message.

Quantize inputs with a session initialization phase. #307

Are you sure you want to change the base?

Quantize inputs with a session initialization phase. #307

Conversation

deeglaze commented Oct 4, 2024 • edited by yogeshbdeshpande Loading

thomas-fossati 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

Choose a reason for hiding this comment

thomas-fossati Oct 4, 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

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 Oct 8, 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

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

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

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nedmsmith Oct 8, 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

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

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nedmsmith commented Oct 11, 2024

yogeshbdeshpande Nov 20, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

deeglaze commented Oct 4, 2024 •

edited by yogeshbdeshpande

Loading

thomas-fossati Oct 4, 2024 •

edited

Loading

nedmsmith Oct 8, 2024 •

edited

Loading

nedmsmith Oct 8, 2024 •

edited

Loading

yogeshbdeshpande Nov 20, 2024 •

edited

Loading