Triple lifecycle - revocation at triple-level granularity

[nedmsmith]

xcorim is current method for revoking statements in a CoRIM. It is applied at RIM granularity, meaning all tags (and by extension all triples) in the RIM will be marked by Verifiers as 'revoked'. Revocation at triple-level granularity in the form of ‘x-’ would offer greater precision in revoking statements (assertions) that are no longer true.

The current semantics for additional triples over the same triple subject (e.g., environment) are that these statements are additive to any previously asserted statements. Hence, issuing a 'new' triple doesn't have the semantics of replacing/invalidating the previous triple.

While it may be possible to use x-triples to revoke all triples in a RIM, don’t yet know if it makes sense to stop supporting xcorim as it addresses the use case where a RIM signing key is abused (but not where a private key is compromised), and an efficient method for walking back the abuse is needed / desirable.

The x-triple method is roughly characterized by creating a triple record that is identical to an existing triple record except for prepending 'x-' to the triple name and adding the field x-reason that identifies the reason for revoking the statement.

For example the triple:

reference-triple-record = [
  environment-map
  measurement-map
]

might have a revocation triple of the form:

x-reference-triple-record = [
  environment-map
  measurement-map
  ? refval-x-reason
]

$refval-x-reason /= obsolete
$refval-x-reason /= insecure

There should be a discussion as to whether x-reason should be optional.

[nedmsmith]

As an aside the lifecycle for triples might be:

Create Revoke Evaluate Delete

[thomas-fossati]

As discussed:

• x-reasons are specific to each x- triple
• x-reason is mandatory for each x- triple
• all x-reason type choices are extensible
• when a triple is defined, its x- twin must also be defined (or at least considered)

Some examples for existing triples:

x-reference-triple-record = [
  environment-map
  measurement-map
  $refval-x-reason
]

$refval-x-reason /= obsolete
$refval-x-reason /= insecure
[...]

For verification keys:

x-attest-key-triple-record = [
  environment-map
  [ + $crypto-key-type-choice ]
  $attest-key-x-reason
]

$attest-key-x-reason /= decommissioned
$attest-key-x-reason /= compromised
[...]

[nedmsmith]

The range of possible reason codes is infinite and the semantics behind each reason code is defined by a specification, whether it is a standards document, profile, or other.

Do it make sense to leave it this open ended? Ideally the reason doesn't affect Verifier behavior except when an Appraisal policy for Evidence is used that keys off of the reason code. If the reason code implies changed Verifier behavior independent of a policy, then there should be some way to indicate this so that verifiers can all have consistent behavior. The examples above all have the same outcome, which is the 'x-' form of the triple causes Evidence matching to fail if matched. Compare this to 'delete' where the triple is removed from the Verifier's list. Evidence that doesn't match a Reference Value doesn't necessarily result in appraisal failure. Instead, they are held in reserve until the appraisal concludes and if the Attester is trusted the unmatched Evidence measurements are added to the appraised claims list and accepted as truth.

[thomas-fossati]

As discussed (12/14/2022) it is ok to have an open type for the x-reason. The policy must be written so that it catches an unknown x-reason and, when it does, it defaults to some sensible behaviour.