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

[Daniel Kahn Gillmor <[e-mail]>]

Hi Jon--

Thanks for the feedback!  I'm trying to distill it to concrete guidance
we can use to make OpenPGP certificate redistribution more robust…

On Wed 2019-08-28 00:29:04 -0700, Jon Callas wrote:
> Yeah. An issue with OpenPGP certificates is that they are ultimately a
> list of statements, and those statements can be rewritten with
> impunity. Overall, I think it's far more of a feature than a bug,
> because an alternative would make it so no one would be able to do
> anything without the key owner's permission, and that would disrupt
> things like key signings.

I agree that we want people to be able to compose OpenPGP certificates.
It is definitely a feature of the format, but it's a tricky one, and one
that keystores have had difficulty in managing without opening
themselves to abuse.

> I define it the way it's defined. An abusive revocation is something
> we'll learn over time, and it's something that the key server decides.

This isn't sufficient, unfortunately, because what's abusive for one
keyserver might not be abusive for some of its clients, and vice versa :(

>> Perhaps we could say that the most narrowly-tailored third-party
>> certification revocation signature is acceptable -- the only three
>> subpackets allowed:
>> 
>> * Issuer Fingerprint
>> * Signature Creation Time
>> * Reason For Revocation -- only with a code, and string MUST be empty
>> 
>> And of course the abuse-resistant keystore would have to
>> cryptographically verify the certification revocation signature.
>
> That works. I don't think it has to be that narrow, but that would work.

So this sounds like useful concrete guidance that we can offer in the
abuse-resistant keystores draft.  I'll include it in the next revision.
thanks!

> Yes. Alice is revoking *her* certification of Bob's key. Bob owns
> Bob's key, but Alice owns her certification of Bob's key. Bob can
> freely discard the certification or the certification+revocation, but
> he should not be allowed to keep Alice's certification without its
> matching revocation.

Alice doesn't "own" her certification of Bob's certificate -- we're 

> Part of my prologue of revocation not working is that Bob can always
> go do key surgery. To some extent, anyone can do key surgery. Bob can
> go in with a hex editor and pull off Alice's revocation, but general
> tools shouldn't allow it.

I start this from the assumption that the (ab)user has powerful,
flexible client-side tools, and their only limitation is that they don't
have access to (certain) secret keys.  This is Kerckchoff's principle,
basically.

> Moreover, a key server shouldn't allow it. If Bob uploads a new copy
> of his key without Alice's mention at all, that's fine. The key server
> MUST not allow the revocation to be vanished alone.

But if the keystore allows the revocation to be vanished in any way on
its own terms, it has not solved the problem for the client that does
merge-based updates but already knows of Alice's certification?

Or, are you suggesting that a client of the keystore which knows of
Alice's certification, but receives Bob's certificate without it from
the keystore, should themselves *drop* Alice's certification just
because the keystore doesn't report it?  That would be a pretty radical
change to how most OpenPGP keystore clients work today.

> We have not seen the abuse problem of certificates being nonsensical,
> but that could really happen. I am sure that if you did something like
> take the first part of Bob's key, threw in one of Aice's user ids
> along with all its certifications, and some subways and other things
> from Charlie's key, that some implementation's going to barf in
> amusing ways -- or worse, just accept it.

these are straight up bugs. If you see them in any OpenPGP
implementation -- client or keystore or wherever -- please report them
and get them fixed.

> Any problem that starts with "Mallory gets ahold of Bob's secret key"
> and then goes on, is kinda like discussing an operating system exploit
> that starts with, "okay, the attacker is in kernel mode." In general,
> the attacker can have much more fun than whatever's described. Yes,
> yes, if Malloy has Bob's secret key, Mallory can do anything.

No, that's not true in this situation.  We're talking here about how to
get control of the key back from Mallory, or how to stop Mallory from
decrypting messages already encrypted to the key, or anything like
that.  We're talking about how Alice can reliably publish her revocation
of her certification even in the face of Bob being impaired,
intransigent, or compromised.

> However, this is part of why we have designated revokers.

Designated Revokers need to be set up ahead of time.  If you've done
that, and your designated revoker isn't asleep at the switch, then all's
well.  but most people haven't, and it would be nice to handle that
case.

> Perhaps a key server ought to be a designated revoker itself in some
> but not all cases. Perhaps even the default one. Of course, I'm
> handwaving away things like accounts on that server, authentication,
> takeover policies, and lots of other things that will be fun for
> someone else.

I'm looking for concrete guidance that we can offer to operators of
keystores and clients of keystores today.

Keystore operators have traditionally not wanted to be in the role of
certificate authority, or of designated revoker (i can confirm this as a
past and present keystore operator, but it's not just me).  They're
looking for a reliable set of guidelines they can follow to ensure that

 (a) the ecosystem is healthy,
 
 (b) clients with different trust models and trusted introducers can
     find what they need,

 (c) the keystore can operate efficiently in terms of bandwidth and
     computational resources, and 

 (d) the keystore operator themselves is at minimal technical and legal
     risk.

> Or a signature on the key that's made by the key server itself that
> has a timeout and a lot of policy coded in it.

How does this help in redistributing Alice's certifications?  I am wary
about trying to "code a lot of policy" -- the devil is in the details
there, and i'd like to be clear about what those details are.  Do you
have something specific you're trying to propose here?

The CRL-like mechanism that launched this thread is concrete,
implementable, and has a set of functional properties that seem better
than the status quo (though i think it can be improved too).  If you've
got specific text that you want to propose to improve it, or a
counterproposal that makes it unnecessary, i'd be happy to see it.

Thanks for thinking this through here,

       --dkg