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