Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tracking revocation of public keys #75

Open
TallTed opened this issue Oct 16, 2019 · 8 comments
Assignees
Labels

Comments

@TallTed
Copy link
Contributor

@TallTed TallTed commented Oct 16, 2019

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 comment has been minimized.

Copy link
Member

@msporny msporny commented Oct 17, 2019

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

This comment has been minimized.

Copy link

@selfissued selfissued commented Oct 17, 2019

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

@ChristopherA

This comment has been minimized.

Copy link
Contributor

@ChristopherA ChristopherA commented Oct 17, 2019

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

This comment has been minimized.

Copy link
Contributor

@csuwildcat csuwildcat commented Oct 17, 2019

@msporny

This comment has been minimized.

Copy link
Member

@msporny msporny commented Oct 17, 2019

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

Doing just this is dangerous for the reasons outlined here:

#14 (comment)

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

This comment has been minimized.

Copy link
Contributor

@csuwildcat csuwildcat commented Oct 17, 2019

@dlongley

This comment has been minimized.

Copy link
Contributor

@dlongley dlongley commented Oct 17, 2019

@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

This comment has been minimized.

Copy link
Contributor Author

@TallTed TallTed commented Oct 17, 2019

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).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.