Re: [openpgp] Revocations of third-party certifications (TPK+"CRL") [was: draft-dkg-openpgp-abuse-resistant-keystore-04.txt]

[Jon Callas <[e-mail]>]

> On Aug 22, 2019, at 3:01 PM, Daniel Kahn Gillmor <[e-mail]> wrote:
> 
> The "first-party sovereignty" idea is that the certificate-holder (and
> *only* the certificate-holder) gets to decide what gets shipped with
> their certificate.  But that makes for trouble when the first party
> appears to want to distribute a third-party certification, but the
> keystore is aware of a revocation from the third-party.

Thank you, thank you for "first-party sovereignty" even if I'd say "ownership." This might be relevant below.

In 4880, 5.2.3.17 and the no-modify flag is there intentionally to provide an affirmation that the owner wants sovereignty.

[...]

> 
> My first instinct option is for the keystore to just slap the revocation
> onto Bob's certificate directly.  This is how SKS and other
> non-abuse-resistant keystores have done it in the past.

That's also mine. Of course there is more to it than that, there always is.

> 
> This has a few problems:
> 
> * It violates the "first-party sovereignty" idea.  Bob doesn't get to
>   decide whether this revocation is attached to his certificate or not.

Yes, but it's Alice's certification. I think I can argue that she has a right to revoke her signature, that her signature does not transfer over to Bob.

If this is false, then there's a lot of reason never to sign anyone else's key, because it's therefore irrevocable.

> 
> * It's open to abuse.  What if Alice makes an abusively large
>   revocation signature, or a revocation signature that contains toxic
>   data?

I think that can be taken care of. If Alice did that, I, the key server might decide that my sovereignty overrides hers, and I'm not going to be a party to her abusing Bob.

> 
> * What if Bob then revokes his attestation over Alice's third-party
>   certification, so that the keystore won't ship it?  Then presumably
>   the keystore won't ship the revocation as well.  But then clients
>   that already know about Alice's certification don't get the
>   revocation.

Well, this is why "sovereignty" might be the wrong term.

In my idealized way that I think a key server should work, it should defer to the rules of the game, and one of those rules is that it's Bob's key, and another is that it's Alice's signature. 

A resolution that shipped neither Alice's certification nor her revocation of same is to me an adequate compromise.

> 
> All this is unsatisfactory, so there needs to be another approach.
> 
> The approach i'm proposing in this draft is that revocations of
> third-party certifications are shipped with the *revoker*'s certificate
> (Alice, in the example above), not with the targeted certificate.
> 
> This has some nice properties:
> 
> * "Sovereignty" still holds: Alice still controls what's attached to
>   her certificate, because she can avoid making a revocation if she
>   doesn't want it to be visible there.
> 
> * it's abuse-resistant, because Alice has a strong incentive not to
>   make the revocation abusively large or toxic.
> 
> * A user who cares about Alice's certifications should be regularly
>   refreshing Alice's certificate anyway.  Users who don't care about
>   Alice's certifications don't need to care about her revocations
>   either.
> 
> You can see this as the keystore performing a CRL-like distribution
> service for each certificate that they distribute.  That is, each
> OpenPGP certificate is followed by a "CRL" of zero or more certification
> revocation signature packets, issued by that certificate's
> certification-capable primary key.

Yeah. I just cringed and said, "Oh, dear me, you just invented CRLs and we *know* those don't work.

[...]

> 
> Anyway, i'm thinking that this "CRL" extension to the Transferable
> Public Key might belong in RFC4880bis.  I will propose it as a separate
> patch to that draft, but i wanted to give some motivation behind why i
> think it's important and useful.
> 
> I welcome feedback,

I think that it's better to keep things more or less the way we've done them.

Alice's revocation attaches to her prior certification, and they travel together. They could both be dropped, but not only one. (Even though I can't really imagine the case of no certification, but only a revocation, in completeness.)

If Alice isn't a good citizen and makes an abusive revocation, the server can and should drop it. If Bob wants to just drop Alice's certification along with her revocation, that's fine too.

	Jon