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
<kristian(_dot_)fiskerstrand(_at_)sumptuouscapital(_dot_)com>
[2 <text/plain; us-ascii (7bit)>]
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp