Did-core: tracking revocation of public keys

[TallTed]

In §5.3 Public Keys (source) --

The DID Document MAY
contain revoked keys. A DID Document that contains a revoked key MUST
also contain or refer to the revocation information for the key (e.g.,
a revocation list). Each DID Method specification is expected to
detail how revocation is performed and tracked.

I may have public keys from multiple issuers, which may make their own revocation decisions. The above sentences suggest that I must track such revocations, and make note of them in my own DID Document. This does not seem workable to me, especially not on large scale.

This is related to, but I think not a duplicate of, #14.

[msporny]

This is related to, but I think not a duplicate of, #14.

Feels like there is 80% overlap here in the solution... there is a general meta issue of "how do you express keys that are revoked in a DID Document".

[selfissued]

I see keeping revoked keys in a DID document as the problem. Signal that they're revoked by removing them from the document.

[ChristopherA]

Removing the keys from the document may be a valid signal that a key has been rotated out. But for revocation we must allow for other reasons, such as as notifications of a true key compromise.

Thus I’d like for use by the smaller scale DID methods a consistent way to list keys that are more than rotated (I’m fine if the are not listed to presume rotation) and have been explicitly revoked for a specific reason other than rotation.

It could be acceptable to me that revoked keys that used to be in an older revision of a DID could be listed in a separate JSON document pointed to by the DID document, provided that JSON document can be a static document and optionally a relative URL.

For instance, for BTCR we can only list one URL to the DID extension document, but we could define in the DID method a relative url ./revocatedkeys.json could be available.

However I’d still prefer to put this list in the DID document itself, especially for immutable BTCR extension documents like IPFS where no relative URL is possible.

I suspect that other lightweight, non-global DID methods, like did:btcr, did:peer, did:git and many future iot DID methods will need these static key revocation lists as the can’t use an interactive service, or such a external service is a security risk.

A key point for those of you creating global scale DIDs, your requirements for global scale should not preclude more local solutions, and vis-versa.

— Christopher Allen

[csuwildcat]

I think the issue here with mixing in such a low-level capability is that
devs will have a frustrating time maintaining awareness of which methods do
revocation by which means. Can the method not rely on an inferential
well-known endpoint as the location of a flat revocation file?

On Wed, Oct 16, 2019, 11:05 PM Christopher Allen [e-mail]
wrote:

Removing the keys from the document may be a valid signal that a key has
been rotated out. But for revocation we must allow for other reasons, such
as as notifications of a true key compromise.

Thus I’d like for use by the smaller scale DID methods a consistent way to
list keys that are more than rotated (I’m fine if the are not listed to
presume rotation) and have been explicitly revoked for a specific reason
other than rotation.

It could be acceptable to me that revoked keys that used to be in an older
revision of a DID could be listed in a separate JSON document pointed to by
the DID document, provided that JSON document can be a static document and
optionally a relative URL.

For instance, for BTCR we can only list one URL to the DID extension
document, but we could define in the DID method a relative url
./revocatedkeys.json could be available.

However I’d still prefer to put this list in the DID document itself,
especially for immutable BTCR extension documents like IPFS where no
relative URL is possible.

I suspect that other lightweight, non-global DID methods, like did:btcr,
did:peer, did:git and many future iot DID methods will need these static
key revocation lists as the can’t use an interactive service, or such a
external service is a security risk.

A key point for those of you creating global scale DIDs, your requirements
for global scale should not preclude more local solutions, and vis-versa.

— Christopher Allen

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/w3c/did-spec/issues/75?email_source=notifications&email_token=AABAFSTHMZ76UEWSP7IMNZTQO76BLA5CNFSM4JBMJJ6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBO45AI#issuecomment-543018625,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABAFSTSD2B6QEUAFDJLKULQO76BLANCNFSM4JBMJJ6A
.

[msporny]

Signal that they're revoked by removing them from the document.

Doing just this is dangerous for the reasons outlined here:

https://github.com/w3c/did-spec/issues/14#issuecomment-543174482

I think the issue here with mixing in such a low-level capability is that devs will have a frustrating time maintaining awareness of which methods do revocation by which means.

... which suggests mandating ONE way to publish this list.

Can the method not rely on an inferential well-known endpoint as the location of a flat revocation file?

Two concerns with that approach:

1. GDPR concerns over PII when putting URLs into a DID Document.
2. No cryptographic certainty over the contents at the link, enabling compromise of the revocation list (solved using Hashlinks).

[csuwildcat]

Not sure why you're saying the data at the endpoint is unreliable - I'm
assuming it's signed with currently valid keys to prove its veracity.

On Thu, Oct 17, 2019, 6:31 AM Manu Sporny [e-mail] wrote:

Signal that they're revoked by removing them from the document.

Doing just this is dangerous for the reasons outlined here:

14 (comment)

https://github.com/w3c/did-spec/issues/14#issuecomment-543174482

I think the issue here with mixing in such a low-level capability is that
devs will have a frustrating time maintaining awareness of which methods do
revocation by which means.

... which suggests mandating ONE way to publish this list.

Can the method not rely on an inferential well-known endpoint as the
location of a flat revocation file?

Two problems with that:

1. GDPR concerns over PII when putting URLs into a DID Document.
2. No cryptographic certainty over the contents at the link, enabling
   compromise of the revocation list (solved using Hashlinks).

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/w3c/did-spec/issues/75?email_source=notifications&email_token=AABAFSU6K6CGBXR4S2LUVGTQPBSKJA5CNFSM4JBMJJ6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBQDLGY#issuecomment-543176091,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABAFSQB6PW3TJSRXI2APGTQPBSKJANCNFSM4JBMJJ6A
.

[dlongley]

@csuwildcat,

Not sure why you're saying the data at the endpoint is unreliable - I'm
assuming it's signed with currently valid keys to prove its veracity.

We need to be careful here to avoid a circular dependency. How would you check that these "currently valid keys" are actually valid?

[TallTed]

I think I did not express my concern clearly. Here's a scenario which might help --

_My employer may generate a key pair which is valid for communications with me while in their employ (because I can make use of the private key through VPN connections to relevant systems)._

_I include that public key in my DID document, which my employer does not control. My employment ends; I can no longer access the private key; my employer revokes the public key._

_While it is in my best interest to remove the revoked public key from my DID document, I may not be immediately able to do so, or I may not yet know that my employment has been terminated, etc._

Perhaps the solution to my concern is simply to reword --

A DID Document that contains a revoked key MUST
also contain or refer to the revocation information for the key (e.g.,
a revocation list).

-- to something like --

A DID Document that contains keys which may be revoked MUST
also contain sufficient information to check the revocation status 
of such key(s) (e.g., a revocation list).

[tplooker]

If we allow for linking to public key revocation statuses outside of did documents, does this set the precedent that we should be able to also define and link to off ledger public keys?

[csuwildcat]

I hope so - there's a great case to be made that with just a few keys in a
DID Doc, you can sign as many keys you want and make them accessible via a
deterministic semantic key object in the Collections interface of your
Service Endpoint-linked Hub.

On Thu, Nov 21, 2019, 4:39 PM Tobias Looker [e-mail]
wrote:

If we allow for linking to public key revocation statuses outside of did
documents, does this set the precedent that we should be able to also
define and link to off ledger public keys?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/w3c/did-core/issues/75?email_source=notifications&email_token=AABAFSXWYS26OTS2DTF23LLQU4S5NA5CNFSM4JBMJJ6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEE4EL6I#issuecomment-557336057,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABAFSQCZRGZLNDBIQ3D6NLQU4S5NANCNFSM4JBMJJ6A
.

[csuwildcat]

I feel like we got to resolution in related Issue 14, that being: we will not add a standard/scheme for retaining key references for the purpose of revocation tracking

[msporny]

I suggest we make this item a duplicate of #14.... and close this issue.

[jandrieu]

Sadly, that's not the consensus in #14.

The sense that I expressed was that only explicitly retained (semi-valid) keys would be listed in the DID Document.

That is, in general revoked keys just go away in later DID Documents.

In the specific case that the DID controller wants to indicate that a given key was in fact valid for a particular period of time, but should no longer be considered valid for forward looking uses, THEN, we would need a way to represent those keys in the DID Document.

The mechanism for doing that is still TBD, but Ken Ebert outlined a viable use case of wanting to check if a given key was valid at a particular point in time so you can tell if a given credential was, at one point in time, authentically issued.

There is an argument to say that we don't need to support that use case: that checking the validity of a credential should ALWAYS use the keys currently listed. That checking the state of something in the past is not worth the complexity of supporting it.

[CholoTook]

I'm not sure if this really adds to the discussion here, but what can we learn from PKI revocation successes and failures? I forget the latest initiative, something todo with delegated keys? I'm thinking of 'failures' like certificate revocation list and HPKP. Sorry if this context is implied.

[dlongley]

There's a PR to close #14 referenced over here that I recommend will also close this issue.

[selfissued]

We should close this on the basis of #279 and #308

[OR13]

Feels like this is still a dupe of #14 and not much progress has been made.... I believe this should be closed based on #279 ... #308 also would support closing this.

[burnburn]

@CholoTook it looks like this may be closed soon. Can you please raise a new issue if you want your question addressed?

[dlongley]

@CholoTook, with PRs #279 and #308, the group is indicating that revoked keys/verification methods must not be expressed via a verification relationship. Any other sort of representation is not going to be worked on by the group at this time. Instead, the expectation is that revoked keys/verification methods will be removed from verification relationships to indicate that they are no longer valid.

[awoie]

Seems also fine to me closing due to #279 and #308

[selfissued]

I agree with closing this.

[msporny]

Handled in #279 and #308, marking pending close. Will close in 7 days unless there are objections.

[brentzundel]

No comments since marked pending close, closing.