Re: [openpgp] [RFC4880bis PATCH] Deprecate "Revocation Key", replacing with full-key "Designated Revoker"

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

On Wed 2019-07-31 22:55:11 +0200, Neal H. Walfield wrote:
> Justus proposed an embedded TPK subpacket for cases like this with
> this as a motivating example.  See:
>
>   Subject: [openpgp] Embedded TPK subpacket
>   From: Justus Winter <[e-mail]>
>   Date: Mon, 25 Mar 2019 10:20:45 +0100
>   Message-ID: <[e-mail]>
>
>   https://mailarchive.ietf.org/arch/msg/openpgp/F1Wdrldzd3k9tqOos4hmokOV0r0
>
> Do you think a point solution is better?

sure, i think Embedded TPK is interesting, but it's much more than is
needed for having a designated revoker.  The additional complexity comes
at a cost i'd rather not impose for implementers.

For a designated revoker, we don't care about who the revoking key
belongs to.  we just care that we know it.

once you have an embedded TPK, then you have some kind of potentially
recursive situation (as Marcus pointed out).  it's also strange because
a TPK is not a static entity -- it changes over time as the composable
certificate mutates.  So embedding such a thing in a self-sig is looking
at a particular version, and implies things like expiration, etc.  we
don't want an endpoint that is trying to process a designated revoker to
be distracted by the additional non-public-key packets.

it's also not clear that an embedded TPK subpacket in a self-sig that
also has a "Revoker Key" subpacket is necessarily referring to the
revoker key itself -- the semantics are potentially ambiguous, as an
embedded TPK subpacket in a different signature packet would have
different semantics.  I'm not fond of that kind of ambiguity.

Additionally, what if there are multiple embedded TPK subpackets, or if
the embedded TPK subpacket's primary key fingerprint doesn't match the
"revoker key" fingerprint?

Finally, if a client processes a direct-key signature with a "revoker
key" subpacket that *doesn't* have an embedded TPK, they're just back in
the soup.  I think the deprecation story is clearer to just burn the old
subpacket type entirely (it was originally specified very much in
v4-only mode), and have an unambiguous subpacket for this use case.  It
is at least marginally simpler for an implementation to say "i don't
support 'revoker key' but i do support 'designated revoker'" than it is
to say "i only support 'revoker key' if it is in a direct key signature
that contains exactly one embedded TPK whose primary key fingerprint
matches the 'revoker key' fingerprint". 

In general, i think we should not aim for maximum flexibility in the
format specification, because that flexibility is a major cost for
implementers.  I'd rather identify the specific use cases we want to
support and clearly and unambiguously ensure that the spec meets those
use cases.

        --dkg