[SCITT] Claim revocation & freshness

[Antoine Delignat-Lavaud <[e-mail]>]

Hi all,

One of the major unresolved issues in the SCITT Architecture draft 0 [1] is how we expect verifiers to check the freshness and/or revocation of a transparent claim or its signing key, and what are the resulting additional requirements for issuers and for transparency services that need to be added to the current IDs for SCITT architecture and receipts.

Claim revocation. An issuer has signed claims, but it wants to make sure that TS won't register them anymore and/or that verifiers won't accept them anymore. For TS, one way to achieve this is to revoke the key that the issuer used to sign this claim (see the companion thread on issuer key revocation). However, it can also be achieved at a finer granularity - for instance, only the claims relative to a given artifact are revoked. What is more important is that verifiers need a mechanism to check for revocation of claims. Since claim revocation is a ledger-based notion (a revoked claim is still valid from the point of view of DID), it needs a revocation mechanism for the ledger countersignature.

Claim freshness. Similarly, the verifier may want to know if a given claim is the most "up to date" for the given issuer and feed. (recall that by default SCITT does not enforce claims to be registered in the same order they are issued, so this concept requires and additional semantic order over claims with the same issuer and feed). While this is achievable with short-lived claims, they are painful to produce by issuers. Transparency services are aware of when claims are updated and can produce evidence without any involvement from the original issuer.

There are several variants of claim revocation: the issuer may want to revoke only a particular claim (other claims from the same issuer/key and feed may continue to exist), or revoke an artifact (that is, revoke all claims associated with the artifact and prevent the registration of new claims with the same associated issuer and feed, i.e. feed revocation). We may also want to consider supporting external revocation of claims (e.g. take down notice) where an entity that is not the original issuer is authorized to revoke claims on the ledger. As much as possible, our goal is to make it possible to express the TS impact of claim revocation as registration policies, while we need the ledger countersignatures to enable client revocation and freshness policies.

Regarding registration policies, it may be desirable to allow issuers to define custom revocation policy for their feed. For instance, the presence of certain registration policy info fields may be used to request the TS to apply some pre-defined standard revocation policies, or the issuer could use special claims with a payload meant to be interpreted by the TS to signal the revocation of a claim or the change of policy. A third alternative is for the TS to expose an explicit claim revocation API; while this may enable more flexible authentication/authorization than forcing the issuer to produce a full SCITT claim, it would need to be auditable in the same way as claim registration is, which probably requires duplication of effort compared to encoding revocation requests as a specialized usage of the standard claim registration API. Currently, we are open to proposals but our preferred approach is to use the registration policy info of the envelope to signal revocation requests or to stop using a particular feed.

Verifier policies to enforce claim revocation are more difficult to achieve as verifiers now need evidence of non-revocation, which is a form of claim freshness (revocation can be encoded as an update to an empty claim). In the world of X.509 and PKIX, revocation lists and OCSP-style short-lived certificates of non-revocation both suffer from significant drawbacks especially if they need to be fetched on-line during certificate validation. OCSP is most successful when it is stapled to certificates. Following the same pattern, for a given receipt, a TS should be able to issue a short-lived proof that a registered claim is not revoked. The receipts defined in draft 0 are based on a historical Merkle Tree, and relate to the registration of the claim - sometimes referred to as "write receipt". Other transparency systems (such as CONIKS) use a prefix tree where the claims are indexed and stored in lexicographic index order, which means that if a claim is updated/deleted, the TS can issue a new receipt that shows that for the given ledger state the claim associated at the given index (issuer/feed) is also updated/deleted - sometimes referred to as a "read receipt". Unlike read receipts, it is not possible to tell with a write receipt if the registered claim is still up to date. However, it is possible to define more complex Merkle trees that support both read and write receipts on the same tree (see e.g. Merkle2 [2]). We are investigating an extension of the receipt draft to support read receipts, so that they can be used to verify the freshness or non-revocation of claims and plan to submit a new draft to that extent.

Best,
Antoine & Cedric

[1] An Architecture for Trustworthy and Transparent Digital Supply Chains (ietf-scitt.github.io)<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fietf-scitt.github.io%2Fdraft-birkholz-scitt-architecture%2Fdraft-birkholz-scitt-architecture.html&data=05%7C01%7Cantdl%40microsoft.com%7Cbd829ba6d5b44c9faef608da2907e8dd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637867411187632292%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=xrd%2Bp9vrpulYRs3A5OSRvcE9D8WkOYxJS2ytuzp9i0I%3D&reserved=0>
[2] https://eprint.iacr.org/2021/453.pdf<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Feprint.iacr.org%2F2021%2F453.pdf&data=05%7C01%7Cantdl%40microsoft.com%7Cbd829ba6d5b44c9faef608da2907e8dd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637867411187632292%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=235VTPIlrYdKdLdWxeFHIgkVq0SSajzJCF7kWGscXfg%3D&reserved=0>