Re: [openpgp] Clarify status of subkeys with certification use

["Neal H. Walfield" <[e-mail]>]

Hi Kristian,

Justus and I have been thinking about how to realize per-device keys
and approximate forward secrecy.  These two things are related: if we
want devices to do their own key rotation (and I think this is
sensible, as the alternative is to somehow regularly transfer secret
key material to each device), then the devices need to be able to
generate self-signatures.  Since we don't want all devices to have
access to the primary key, each device could have its own
certification subkey.

We also want the master device to be able to revoke individual devices
if the device is compromised or retired, etc.  Using certification
subkeys, it is straightforward to revoke an individual device: we just
revoke its certification subkey, which automatically revokes any
self-signatures that that certification subkey might have made.

(For those familiar with object capability terminology: one way to
think of a certification subkey is like a capability wrapper.)


Consequently, please do not remove certification subkeys from RFC
4880bis.  If anything, I would prefer that RFC 4880bis clarifies that
certification subkeys should be supported.

Thanks,

:) Neal & Justus

On Mon, 07 May 2018 20:09:01 +0200,
Kristian Fiskerstrand wrote:
> 
> [1  <multipart/signed (7bit)>]
> [1.1 Clarify status of subkeys with certification use <multipart/mixed (7bit)>]
> [1.1.1  <text/plain; utf-8 (quoted-printable)>]
> Hi,
> 
> From time to time there have been discussions about whether
> certification subkeys are valid according to rfc4880. I don't believe
> they should be, and I also believe the current specs can be read in a
> way that it isn't, however I would ask that we are more explicit on it
> in 4880bis in order to avoid any ambiguity. As far as I'm aware current
> implementation will ignore certify capabilities of such subkeys.
> 
> Some background; section 11.1 of rfc4880 includes;
> 
>  After the User ID packet or Attribute packet, there may be zero or
>    more Subkey packets.  In general, subkeys are provided in cases where
>    the top-level public key is a signature-only key.  However, any V4
>    key may have subkeys, and the subkeys may be encryption-only keys,
>    signature-only keys, or general-purpose keys.  V3 keys MUST NOT have
>    subkeys.
> ...
>    Each Subkey packet MUST be followed by one Signature packet, which
>    should be a subkey binding signature issued by the top-level key.
>    For subkeys that can issue signatures, the subkey binding signature
>    MUST contain an Embedded Signature subpacket with a primary key
>    binding signature (0x19) issued by the subkey on the top-level key.
> 
> Arguably if certification was intended for subkeys, the list in the
> former paragraph would likely not be explicitly mentioning
> encryption-only and signature-only as well as general purpose keys,
> without mentioning certifying keys, but rather say all subkeys or
> similar. This is further strengthened by the second part that mentions
> signatures (which is used for data in our context, whereby the use flag
> for certifying other keys is clearly marked as such)
> 
> In any case, there have been discussions along the way, so I propose we
> explicitly mark certification subkeys forbidden and ignored by
> implementations.
> 
> Maybe something like;
> "when generating a subkey binding signature, the implementation MUST NOT
> set the certify usage flag. When interpreting a subkey binding
> signature, implementations MUST ignore the certify subkey binding usage
> flag if it is set."
> 
> PS! As a tangent point, we likely also want to change the default
> behavior for no usage flag specified for v5 to be ignored as not having
> a recognized flag, instead of defaulting to all features, although I
> don't have a specific proposal for this.
> 
> -- 
> ----------------------------
> Kristian Fiskerstrand
> Blog: https://blog.sumptuouscapital.com
> Twitter: @krifisk
> ----------------------------
> Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
> fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
> ----------------------------
> Ab esse ad posse
> From being to knowing
> 
> [1.2 OpenPGP digital signature <application/pgp-signature (7bit)>]
> Signature made by expired key 250B7AFED6379D85 Kristian Fiskerstrand <[e-mail]>
> [2  <text/plain; us-ascii (7bit)>]
> _______________________________________________
> openpgp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/openpgp