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

[Leo Gaspard <[e-mail]>]

On 05/25/2018 11:59 AM, Neal H. Walfield wrote:
> 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

Another use case supporting this opinion: certification subkeys are also
a way to increase the security of an offline OpenPGP key, as with them
it becomes possible to put the master key behind a diode while still
being able to certify keys, and only ever move data out:
 1. On the machine with the master key, generate a certification subkey
 2. Move the certification subkey to another system, less trusted
 3. Push the to-be-signed key to this other system
 4. On this other system, certify the to-be-signed key
 5. Rotate the certification subkey from time to time to be able to
revoke one were it compromised

This thus enables people to participate to the WoT without compromising
master key security. I wanted to do this for my key, but learned that it
was a not-very-supported capability bit, and had to fallback to pushing
the to-be-signed keys to my offline system, thus making it handle
untrusted data.

So I think clarifying that certification subkeys MUST be supported would
be better indeed, so that people can assume RFC4880bis-compliant
implementations do support them, both for the use case described by Neal
(ie. usability) and this one (ie. security).

Just my 2¢,
Leo