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
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp