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

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.

draft-ietf-rats-corim.md

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

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 🤣

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.

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.

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

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)

CoBOM is defined in this document. Co-authored-by: Thomas Fossati <[email protected]>

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

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

Manual merge of conflicts.

Fixed build errors - duplicate sections resulting from manual merge

removed comments that were causing errors

draft-ietf-rats-corim.md

removed reference to cobom tags since we're calling them cotl now.

nedmsmith · 2025-04-29T23:24:55Z

Fixed build issues with this PR which included merging from main.
However, there are still issues with this PR having a different heading structure from the current main. Possibly, it makes sense to re-apply the changes starting from a current snapshot of main?

nedmsmith · 2025-04-29T23:25:58Z

Some examples should be developed that test the new CDDL this PR introduces.

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

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

…s-corim into quant

…o quant

…s-corim into quant

Unintentional addition.

yogeshbdeshpande · 2025-07-02T08:25:27Z

cddl/intrep-actx.cddl

@@ -0,0 +1,4 @@
+ir-appraisal-context = {


I am not clear why this data structure is needed ..?

We should just have a Staging Area, kept somewhere out side of ACS and then highlight one concept that is known as ACS.

Active Context of Appraisal is the ACS Data Structure, which tracks the Appraisal.

Appraisal starts with reception of Evidence and ACS starts getting populated.

Then ACS keeps growing and at the end, ACS is converted into Attestation Results.

I have it as a data structure primarily to have a single object of process. We then say that Appraisal = phases567(leastfixedpoint(Phases234)(Phase1(inputs)))

if the staging area and ACS don't change after running through phases 2, 3, and 4, then there are no more conditional rules that can apply, and you're ready to move to the later phases.

I do not think, such a Data Structure is Possible. Reason been, a Verifier will have Many Schemes (like TDX, Arm CCA, etc etc) For each scheme there can be Multiple CoRIMs.

Each CoRIM moves into a Staging Area Data Structure.

However, NOT all CoRIMs are part of ir-appraisal-context, but they are ALL part of a Staging Area upon reception!!!

Once the Evidence is received, Appraisal Claim Set (ACS) Population Starts, with Evidence

Then we Select suitable Staging Area Mapped Data Structure i.e. IR of CoRIMS :

Then we progress the remainder of Appraisal, Phase 2/3/4/5...

yogeshbdeshpande

Have made some fundamental Comments, to simplify the proposal....

yogeshbdeshpande

Please see my latest comments!

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

Add informative RFC reference for OCSP

66822b8

Also refer to CRL distribution points from RFC5280.

nedmsmith reviewed Oct 4, 2024

View reviewed changes

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

Update draft-ietf-rats-corim.md

8aa35d5

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

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 and others added 2 commits October 5, 2024 13:54

Update draft-ietf-rats-corim.md

f2f750e

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

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

deeglaze added 4 commits October 9, 2024 14:06

Add tag status evolution.

72ca4e6

Hermeticity attempt 3

19a0b68

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

b4c03dc

Specify session/context/activity

c262da8

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

thomas-fossati reviewed Oct 11, 2024

View reviewed changes

deeglaze and others added 5 commits October 11, 2024 06:56

Remove cobom informative reference

76fc27d

CoBOM is defined in this document. Co-authored-by: Thomas Fossati <[email protected]>

include path typo

675806d

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

Update draft-ietf-rats-corim.md

6e247a0

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

Update draft-ietf-rats-corim.md

36fed37

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

Update draft-ietf-rats-corim.md

a2b5889

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

nedmsmith added 9 commits April 29, 2025 13:03

Update crypto-key-type-choice.cddl

1e4f121

Update endorsed-triple-record.cddl

25d5ef8

Update reference-triple-record.cddl

fb47edc

Update stateful-environment-record.cddl

b88de00

Update svn-type-choice.cddl

12d22ca

Update draft-ietf-rats-corim.md

d83c9f4

Manual merge of conflicts.

Update draft-ietf-rats-corim.md

c2d3ac9

Fixed build errors - duplicate sections resulting from manual merge

Update draft-ietf-rats-corim.md

20c96d4

removed comments that were causing errors

Merge branch 'main' into quant

f019084

nedmsmith reviewed Apr 29, 2025

View reviewed changes

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

nedmsmith added 2 commits April 29, 2025 16:04

Fix invalid CDDL in intrep support for phase 1

2c7d49f

Update draft-ietf-rats-corim.md

14c9f4d

removed reference to cobom tags since we're calling them cotl now.

deeglaze and others added 5 commits April 30, 2025 07:16

Remove repeated words.

ecac8f1

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

Attestation session definition edit

a6a25d0

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

Merge branch 'main' of https://github.com/ietf-rats-wg/draft-ietf-rat…

2f9bf70

…s-corim into quant

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

404850b

…o quant

Merge cleanups

4a9fc16

deeglaze mentioned this pull request Jun 24, 2025

Address issue reported in Gap-1 #453

Merged

deeglaze and others added 6 commits June 25, 2025 14:29

Merge branch 'main' of https://github.com/ietf-rats-wg/draft-ietf-rat…

d567d2e

…s-corim into quant

Stashing work from Google computer. Bye Google!

c807e3d

Reduce the diff but keep the important content.

32a789b

Clean up diff.

7d626a8

Delete scratch.md

78da87d

Unintentional addition.

Fix inconsistent emdash

4c68af3

yogeshbdeshpande reviewed Jul 2, 2025

View reviewed changes

yogeshbdeshpande requested changes Jul 3, 2025

View reviewed changes

deeglaze mentioned this pull request Jul 4, 2025

intrep relation multiplicity is inconsistent #456

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.

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

Uh oh!

Conversation

deeglaze commented Oct 4, 2024 • edited by yogeshbdeshpande Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

thomas-fossati left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

thomas-fossati Oct 4, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nedmsmith Oct 8, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

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