(Pulled into a new subject.)
Can someone explain why key usage and preference flags for the primary
were made part of user id signatures instead of a direct key signature
or something of the sort? I felt like this added a lot of complexity
and non-determinism to those parts of the implementation which dealt
with that.
Because you want the key owner to issue a signed statement that says "this is
how I want you to use my key" and you want that to be part of the
self-signature that says "I own this key." You don't want a separate signature,
because you don't want them to be torn apart.
Secondly, (this came up somewhere else), I'm not convinced at all that
designated revokers (5.2.3.15) are a good idea. Is there a significant
advantage over just handing the person a revocation certificate of your
key? I remember deciding against implementing this feature at some point
in OpenKeychain because the complexity/benefit tradeoff just wasn't
there.
Let's face it. Revocation is not as good as people think it is. In the general
case it cannot work. There are specific cases where it can work, but you must
always account for the case that there is revocation information, you're just
not getting it. It's true in OpenPGP, where a revocation signature can be
stripped from the key, and true in CRLs where there are all sorts of spoofing
things that can be done that block you from the information. You can in some
cases *know* you've been blocked. (Suppose the connection to the CRLDP (etc.)
fails outright, or it hands you an old CRL.)
Sadly, the correct thing to do is almost never to pull the emergency brake and
stop whatever process you're doing. The reason is that the likelihood of a
completely reasonable reason for the failure (your network sucks) is several
orders of magnitude higher than a real needed revocation.
(There are many, many unneeded revocations. For example, I know a code-signing
system where the code-signing cert includes a bunch of developer information.
Every time the developer changes anything in their web profile, a new cert gets
issued, the old cert gets put on a CRL, and the old cert is also thrown away.
It's rigorous and tidy, but utterly unneeded.)
Anyway, I advise not going too far to fix revocation because there are edge
conditions on the edge conditions. It works when it works and how it works, and
just accept it.
But I didn't answer your question. Sorry. You can do that now -- Alice can give
Bob a pre-revoked key and ask him to release it when she asks.
But you don't want to do that for a number of reasons. One is that you can't a
priori know *why* you're going to revoke. You also can't a priori know *when*
you want to revoke. If Alice loses her laptop on April 24, you want signatures
she made on April 23 to still be valid. You really don't want to undo
everything that key ever did. That makes revocation worse than useless.
Presently revocation is kinda sorta often useful.
On top of that, the thing that Bob has is dangerous data. It has to be stored
somewhere with all the seriousness of a private key, if not more because it's
trust issue. (Not this weird thing we call trust in public key infrastructure,
but actual real trust.) It makes a whole huge OPSEC issue that's harder to
solve than it is to implement the designated revoker. Yeah, having it makes it
hard on a developer, but not having it pushes the problem to people who are
incapable of doing it right.
Jon
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp