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

On Tue 2019-08-27 13:05:35 -0700, Jon Callas wrote:
> Yeah. I just cringed and said, "Oh, dear me, you just invented CRLs
> and we *know* those don't work.
haha, sigh -- the way that CRLs "don't work" is roughly the same way
that HKP-style keyservers "don't work".  In particular, most users don't
check CRLs, and they don't refresh keys from keyservers.

One of the reasons that they don't check CRLs is because the relevant
time for the check is often a low-latency situation (e.g. TLS session
establishment) and the implementation doesn't want to block.
Additionally, the user might not want to leak metadata about their
activity to the CRL operator.  Both of these reasons are also why
OpenPGP signature verifiers have a hard time collecting revocation
information about the signature-issuing certificates.

In either case (X.509 or PGP), though, if we're willing to accept a
delay (i.e., we don't support low-latency requirements), and we can do
scheduled/backgrounded onion-routed updates to our certificate stores to
obscure the metadata patterns, we can mitigate some of those concerns.

But an additional concern for OpenPGP certificates (which X.509 doesn't
have) is that the common keyservers are vulnerable to flooding attacks,
as outlined in the draft under discussion here.

So while this discussion isn't aiming to fix the low-latency or metadata
leakage concerns, it is trying to address the abuse concerns.  Maybe we
can focus on that?

> I think that it's better to keep things more or less the way we've
> done them.
The way we've done them in OpenPGP up to now is vulnerable to abuse, as
we've seen.  I'm hoping we can concretely specify what we need to do to
avoid leaving the door open to that abuse.

> 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.)
The case of an omitted certification but included revocation seems
sensible to me.  If the keystore knows that a given certification is
revoked, it might very sensibly want to refrain from redistributing it.

At the same time, it knows that the certification is out there, some
people might have a copy of it, and those people need to know that a
revocation has been issued.

> If Alice isn't a good citizen and makes an abusive revocation, the
> server can and should drop it.
How would you define "abusive revocation" in this context?  Is it a
universal view of "abuse", or might different people have different
perspectives?

For example, if we define abuse as being simply "too large", then
perhaps we can fix a byte limit on what a "redistributable" revocation
looks lke.  And if Bob attests to Alice's certification, he is
implicitly willing to accept her (as yet unseen) revocation as well.

This gets thornier if we look at arbitrary data in the revocation.  For
example, if Alice's certification revocation contains a Reason for
Revocation subpacket with a text string that says "the King is an
imbecile" (and Bob needs his certificate to be distributable in a place
where it's illegal to insult the King) or it says "Joe Smith was born on
1957-03-25" (and Bob lives needs his certificate to be distributable
somwhere it's illegal to distribute "personal information" without the
person's consent), then that would make Bob's certificate difficult to
redistribute where he needs it to be.  This is where i get uncomfortable
about the idea that there is some universally-applicable view of what an
"abusive" revocation is, and why i think that Bob's sovereignty over his
own certificate makes it really important.

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.

But does that mean that *any* revocation is freely attachable to any
certificate?  What if Bob doesn't ask for a distribution of Alice's
certification in the first place?  Is Alice allowed to slap a revocation
onto Bob's certificate?

This brings us to this case:

> If Bob wants to just drop Alice's certification along with her
> revocation, that's fine too.
So let's say Mallory gets ahold of Bob's secret key, and Bob's
certificate has a certification from Alice, which Mallory likes.  Alice
learns that Bob's secret key has been compromised, and she wants to
revoke her certification of Bob.  But Mallory (masquerading as Bob)
indicates "actually, do not distribute Alice's certification".  Then
Mallory can hide Alice's revocation.  I don't think that's an acceptable
outcome.

Furthermore, it's possible that Bob has *never* attested to (requested
redistribution of) Alice's certification, though Alice's certification
is known to some other party, let's say "Carol".  How should Carol be
confident that she will learn of Alice's revocation, if it is created
and published?

Something like a CRL seems to still be required.

     --dkg

signature.asc
Description: PGP signature

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