On Mon 2019-08-05 19:44:01 +0200, Werner Koch wrote:
On Wed, 31 Jul 2019 16:34, dkg(_at_)fifthhorseman(_dot_)net said:
The "revocation key" subpacket is problematic. It is the the most
fragile piece of the specification wrt the fingerprint (collisions
against a fingerprint can create surprising revocation effects). And
With the move to v5 keys this will be solved en-passant.
Sure, but this isn't the most important part of the problem.
The important part is that people need to be able to see the public key
of the revoker, and it's not always clear that this will be available.
replaces it with a "designated revoker" subpacket that includes the
full key, rather than the fingerprint.
I view this as problematic in the light of our preparations to allow for
larger key material. With PQC we may need megabyte large keys and then
including an entire key would double the size of a keyblock.
I agree with you that this would make such a packet larger. And
therefore, the people who want to make use of such a scheme -- and the
peers that they contact -- would need to accept a larger
certificate/keyblock size as a result. It's not quite doubling, though:
given that there may be subkeys the certificate, and non-negligible
certifications themselves (including self-sigs and subkey binding
signatures, etc), such a subpacket is likely to be smaller than the rest
of the surrounding certificate. and in any case, it's comparatively
small compared to some things we distribute today in much more common
circumstances than a "designated revoker".
Moreover, the verifier who discovers a third-party revocation needs to
check fetch the associated public key somehow no matter what. And it's
always possible to distribute a "designated revoker" packet alongside
the revocation itself. This approach increases the size of a
revocation, but incurs *no extra cost* compard to "normal" certificate
size (and no metadata leakage). For a single verification, this is
likely to be less traffic for the verifier than if they were obliged to
fetch the full transferable public key associated with the revoker in
the first place.
So: my argument here remains that shipping the revoker's key in
"designated revoker" has benefits in terms of:
* more convenience for verifiers
* higher likelihood that verifiers can actually assess and accept a
delegated revocation when encountered
* better metadata properties (self-contained messages reduce side
channels for their users)
* lower traffic/bandwidth costs for a verifier who encounters a
delegated revocation from an unknown key
And is only a marginal costs in terms of:
* in one possible deployment configuration, for the uncommon user of
such a packet, a modest increase in certificate size.
This seems like a clear win to me, though i acknowledge that it is not
without some minor tradeoffs.
--dkg
signature.asc
Description: PGP signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp