ietf-openpgp
[Top] [All Lists]

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

2019-08-27 15:05:57


On Aug 22, 2019, at 3:01 PM, Daniel Kahn Gillmor 
<dkg(_at_)fifthhorseman(_dot_)net> 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


_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp

<Prev in Thread] Current Thread [Next in Thread>