[openpgp] Revocations of third-party certifications (TPK+"CRL") [was: dr

On Thu 2019-08-22 17:08:44 -0400, Daniel Kahn Gillmor wrote:
>  * introduce augmentation to TPK for third-party certification revocation
>    distribution
This bit is likely to be the most-controversial part of this update, so
i wanted to explain it more.  Sorry that this note is so long.

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.

A concrete example:

- Alice is a popular and well-respected certifier.

- Bob meets Alice and they exchange fingerprints.  Alice certifies Bob's
  identity, and Bob attests to Alice's 3rd-party certification, shipping
  it with his OpenPGP certificate.

- They go their separate ways.

- Later, Alice learns from a reliable source that Bob's OpenPGP secret
  key material has fallen into the hands of Eve, or that Bob was not who
  he claimed to be, or whatever.  She decides to revoke her
  certification, and she tries to reach Bob but he is uncontactable.

- Alice pushes her revocation to the keystore so that it learns of it,
  and it can cryptographically verify it.

- How does Alice's revocation get attached to Bob's certificate for
  redistribution?  How does a keystore client learn of Alice's
  revocation?


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.

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.

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

 * 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.

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.

There are two downsides to this approach:

 A) it violates the definition of a transferable public key in RFC4880
    (clients aren't expecting these packets)

 B) It's not obvious to to match up these revocation certificates with
    the certifications they revoke

(A) isn't really a problem -- we can just update the spec; legacy
clients will ignore the trailing "CRL" and discard it anyway.

(B) requires a bit more engineering, but not much.  Clients that know
about this CRL can keep an index of all third-party certifications based
on the SHA256 digest of the certifications.  If all revocations have one
or more "Target Signature" subpackets that use SHA256, to point to the
certification(s) that they revoke, then an indexed keystore can find
them and revoke them without much trouble.

Note that this only works if there is a well-established convention
about what digest algorithm to use.  I don't want to keep a SHA256 and a
SHA512 and a blake2b index of all the certifications i know about.  Note
also that SHA256 isn't used here for strong cryptographic purposes --
it's just a hash table indexer.

For bandwidth optimizations, one can imagine a keystore that provides
two "refresh" interfaces for a certificate: one with the "CRL" attached,
and one without it.  I think that would only be useful for a certificate
that issues lots and lots of revocations (not common in the OpenPGP
world), and if a client only selects "with CRL" for the certificates
that it "trusts" as a certifier, it would expose the user's trust model,
so i'm not inclined to propose such an interface explicitly.

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,

      --dkg

signature.asc
Description: PGP signature

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