spec: discovery of ACI signing key revocations

[dghubble]

The discovery spec specifies mechanisms for discovering ACIs and public keys, which allows implementations (rkt and the like) to present users with choices about adding those keys to a trust store of some sort to gate ACI execution.

It could be valuable to specify a mechanism to distribute (discover) key revocation certificates to allow implementations to build features for discovering revocations automatically, updating key stores, and rotating ACI signing keys.

Maybe something like:

<meta name="ac-discovery" content="prefix-match url-tmpl">
<meta name="ac-discovery-pubkeys" content="prefix-match url">
<meta name="ac-discovery-revocations" content="prefix-match url">

I can see this being valuable to:

• provide ACI signers a way to publish key revocations in a way that is discoverable to tools.
• allow users executing ACIs with tools which can check for or discover revocations (due to key loss, theft, or compromise). Perhaps on the next ACI discovery attempt or via polling.
• support signing an ACI with a new key and revoking an old key, in order to perform a key rotation

Alternately, maybe tools should piggyback on existing key infrastructure and query key servers. It would be left to implementations to decide how to check the health of a trusted key and how often to do so. Related prior art: certificate revocation lists and OCSP.

[philips]

Yes, I think we should do this.

[dghubble]

Closing this as stale / no longer relevant.