Complete the section on Quantisation of inputs

[yogeshbdeshpande]

Need to complete the section - that deals with Quantizing Inputs {#sec-quantize}

[deeglaze]

I think we need to clarify that we're specifying a single step of logical propagation in the context of computing a fixed point. We need to clarify if the CoRIM author can depend on the fixed point getting computed, or whether they have to be concerned about an arbitrary limit to the number of steps that the Verifier may take. That boils down to the question, what is a CoRIM-compliant Verifier?

To further get rid of the need for the notion of "quantum", we need a way of describing the verification status of certificates, and that that status is an input to the appraisal process. The time that a CoRIM is accepted to the knowledge base is different from the time that appraisal happens.

The knowledge base's certificates should have their revocation status and expiry checked periodically. The validity period of a CoRIM included in the knowledge base should be checked periodically. We won't demand a specific periodicity or that a check precedes every single appraisal request.

The revocation status of certificates are determined through multiple messages to different services. Time passes between each request. The time at which expiry is checked could be wall clock time or the time that appraisal began. There is no simultaneity of the state of consistency of all facts checked to admit a CoRIM to the knowledge base.

I don't think we can specify that knowledge base checks must happen at the time of appraisal, since there is no one time.

[thomas-fossati]

If the appraisal process is broken down into a sequence of well-defined and non-overlapping phases (which I think is already the case), then it is sufficient to define an "appraisal context preparation" phase and say that such a phase happens once and before all other phases.

The goal of the "appraisal context preparation" phase is to gather the needed knowledge base && determine the suitability of each knowledge base component in terms of its freshness, revocation status, etc.

[deeglaze]

Do you want all those phases to happen every appraisal request is the question. If we want to say suitability can be "predetermined" such as "this has been checked in the last hour, so we don't need to check it again", then I'm fine with including that in the phasing documentation.

[thomas-fossati]

Do you want all those phases to happen every appraisal request is the question.

formally, yes. implementations can optimise/amortise provided they do not violate the security invariants, i.e.:

1. allowing stale
2. allowing revoked

If we want to say suitability can be "predetermined" such as "this has been checked in the last hour, so we don't need to check it again", then I'm fine with including that in the phasing documentation.

yes, exactly.

[deeglaze]

You're asking for contradictory things. Stale and revoked are time-dependent properties that must have room for error and or time-limited caching.

[thomas-fossati]

You're asking for contradictory things. Stale and revoked are time-dependent properties that must have room for error and or time-limited caching.

Sure. I am not sure I see the contradiction: however one implements the appraisal machine, it needs to refuse artefacts that are stale or revoked at the time appraisal starts.

[deeglaze]

Every appraisal needs request needs to make multiple ocsp requests to check for certificate revocation even it just did so a second or a minute ago? You said you would allow caching, but if the checks have to be performed before every appraisal then you’re caching nothing.

[thomas-fossati]

Every appraisal needs request needs to make multiple ocsp requests to check for certificate revocation even it just did so a second or a minute ago? You said you would allow caching, but if the checks have to be performed before every appraisal then you’re caching nothing.

It is not impossible to cache OCSP responses, see Section 6 of RFC5019. A similar argument can be made for CRLs.

[yogeshbdeshpande]

While I quite agree with a need for an "appraisal context preparation" phase, we should avoid implementation specific caching and any details about how revocation/freshness is determined by each Verifier.

[thomas-fossati]

While I quite agree with a need for an "appraisal context preparation" phase, we should avoid implementation specific caching and any details about how revocation/freshness is determined by each Verifier.

exactly my point.

[deeglaze]

Okay, we're in violent agreement.