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