Thanks for the comments as well, and I'm really glad you're taking this task
on. It's been one of my peeves for a long time. I know you've been dealing with
it at least in part because the issues have been inflicted upon you, too.
I want to pull back and take a number of the discussion points in text
paragraphs, too. I think we're mostly in violent agreement.
One way that I think about this is that the server is an actor in the
interactions, and I'd encourage a server to have opinions and policies. We tend
to look at the security actors as Alice and Bob, but the server is also an
actor and should consider both Alice and Bob as potential adversaries.
There's two broad classes of abuse that we have to deal with. I'm going to call
them syntactic abuse and semantic abuse. Syntactic abuse is something that is
often relatively easy to discuss and solve. For example, if Alice puts a 1GB
signature or revocation on Bob's key, we can solve that easily. Discussions we
have had are pretty non-controversial and I like your suggestion about minimal
revocations.
There are other forms of syntactic abuse that's similar -- for example, if
someone put a million certifications on a key, that would suck. The server
could guard against with a policy like stripping certifications from a key
that's not on the server. The obvious workaround for the abuser is to upload
that million keys first. I still think that a policy (possibly per user?) of
stripping certifications from keys not on that server is not a bad idea. I can
imagine others, like not allowing Alice to submit certifications other than her
own. Nonetheless, there's a lot of potential issues here and I agree with you
that some of the things we discuss aren't sufficient, but I'll bet that a few
(like syntactic parsing and size limits) are necessary.
One part of abuse protection is going to be to have a cleaner function that
will do things like take the submitted certification and return a clean version
of it. I'd include in that some hygiene functions like stripping expired
certifications (except self-sigs), and so on.
Semantic abuse is different and much of that's going to be in the eye of the
beholder. I think one might argue that something like many certifications as a
form of spamming is actually semantic. Much of that's going to be in the eye of
the beholder. In many cases, the only one who can tell us if Alice is being
abusive to Bob is Bob.
You gave the use case of Alice revoking her certification of Bob's key because
she believes he's suffered a key compromise. Fair enough, but what if she
thinks that for some legitimate, but eccentric reason. Oh, let's suppose Bob
says he keeps his passphrase in a password manager and Alice is horrified, and
thus wants nothing more to do with Bob's key?
Here's a case where I think that we're more or less in violent agreement on
"ownership." I think it's Bob's key and if he wants to delete Alice's
certification+revocation, fine. Let him, it's his key. The place where I think
we agree on concept but perhaps not on the word "own" is her certification.
Certainly, we shouldn't be seeing Alice's certification re-appear without its
revocation. Whatever term we want to use to describe that is fine with me. As
long as we are ending up with the idea that the revocation sticks to the
certification and can't be removed, we're on the same page.
You noted that we're probably going to need to have a way to tombstone a
certification. I agree. If Bob deletes Alice's certification, we don't want it
to reappear. My hand wave back in 2440 days was the flag that says "let me
manage this key, myself" which yes is a large hammer, but it works. If Bob's
key is groomed the way Bob wants it, it's not abusive -- given that we agree
that Bob owns his key. (There are people I know who disagree with this, but
let's ignore them for now.)
If I were writing a server, I'd implement the tombstones with a non-exportable
signature made by a key that the server itself owns. I'd write the tombstone
details in a notation. This leaves dangling the issue of how it gets
propagated, as you noted, and I'm willing to leave that as an exercise for the
future. I'll state the problem though: Bob deletes Alice's certification from
his key; how does Charlie find that out?
Let's rewind, though and come back to Alice's revocation. Let's consider the
case where Alice really is trying to make Bob mad. Alice can even create a
certification just to revoke it with a reason that's insulting. That's really
just the certification-spamming abuse with frosting and sprinkles, but it's
still an issue.
Summing up, you said:
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
That's great, I agree completely. Key servers shouldn't (and likely can't) be
CAs. Heck, if there's anything we know from X.509 it's that being a CA is hard.
However, they can't just be a key store, if a store is a database with a web
interface that allows anyone to put something into it.
A key server has to have policy that it runs. It has to solve a number of
problems including abuse, but also including things like Bob being able to get
rid of a key that they don't control. One of the oldest problems in the
ecosystem is the new person who creates a key and then forgets their
passphrase. No one yet has done the automated abuse of submitting keys for
other people, but it's bound to happen, especially now that I mentioned it. Key
servers need to run code to be a fair arbiter of cryptographic information.
Jon
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp