Always verify and check cross-signatures

[twiss]

Require and verify cross-signature for certification subkeys; and check cross-signature details when signing/certifying.

[andrewgdotcom]

Is it possible to disable this check at the application level? Not all implementations put backsigs on authentication subkeys, so we daren't use this in hockeypuck.

[hko-s]

I'm very concerned about the notion of "certification subkeys".

While one can of course come up with a story why having those could be neat, I think the added complexity (especially at the ecosystem level) of delegating certification capabilities to a subkey outweighs the (marginal) benefits.

(So I'd rather not see the idea casually normalized in comment or code, even if it's just for symmetry, like I assume is the intent in this PR)

[twiss]

RFC9580 says:

For subkeys that can issue signatures, the Subkey Binding signature MUST contain an Embedded Signature subpacket with a Primary Key Binding signature (Type ID 0x19) issued by the subkey on the top-level key.

So - here we're just following the spec, not introducing any new concepts, IMO.

Now - whether we should use certification subkeys when certifying, for example, is a slightly orthogonal question, but if we use one it should at least be properly bound, I think. If we never want to use them, that should be a separate change, and ideally one backed up by some new spec text, IMO.

Also @andrewgdotcom in the v2 API, this only affects certifying and verifying; it shouldn't affect parsing a key there, for example. Are you sure this causes an issue for your use case?

[andrewgdotcom]

RFC9580 says:

For subkeys that can issue signatures, the Subkey Binding signature MUST contain an Embedded Signature subpacket with a Primary Key Binding signature (Type ID 0x19) issued by the subkey on the top-level key.

So - here we're just following the spec, not introducing any new concepts, IMO.

I believe the spec is ambiguous here. What does "subkeys that can issue signatures" mean? Subkeys that use a signing-capable algorithm ID, or subkeys that have the "can be used to sign data" key flag? Historically, most implementations followed the latter, and didn't cross-sign their auth subkeys, so if we decide to change this to the former we will render a lot of historical subkeys unusable.

(Note also that type 1 RSA encryption subkeys contain key material that can theoretically be used to create signatures; should these also have backsigs? It's a silly suggestion, but we could interpret the current wording that way if we squint hard enough...)

In any case, I'm not sure what attack backsigs on auth subkeys mitigate. Authentication is normally an interactive process, and can't be done within openpgp anyway, since openpgp defines no authentication signature types, so how would a "sig stealing" attack work for authentication subkeys?

Also @andrewgdotcom in the v2 API, this only affects certifying and verifying; it shouldn't affect parsing a key there, for example. Are you sure this causes an issue for your use case?

Yes, hockeypuck uses pm/g-c for binding signature verification. If we were to import this change, the majority of the authentication subkeys currently in the SKS dataset would have their bindings invalidated and get deleted...

[twiss]

I believe the spec is ambiguous here. What does "subkeys that can issue signatures" mean? Subkeys that use a signing-capable algorithm ID, or subkeys that have the "can be used to sign data" key flag?

I'd argue it means neither of those, but literally "subkeys that can be used (according to the rest of the spec and the implementation's interpretation of it) to create signatures". For encryption(-only) subkeys, they can't be used to create signatures because of the key flags; for authentication subkeys, they can be used to create signatures according to https://www.rfc-editor.org/rfc/rfc9580.html#name-authentication-via-digital-.

Historically, most implementations followed the latter, and didn't cross-sign their auth subkeys, so if we decide to change this to the former we will render a lot of historical subkeys unusable.

But, fair enough. I suppose we could keep authentication keys out of it for now (since we never use authentication subkeys anyway), or restrict that requirement to v6?

In any case, I'm not sure what attack backsigs on auth subkeys mitigate. Authentication is normally an interactive process, and can't be done within openpgp anyway, since openpgp defines no authentication signature types, so how would a "sig stealing" attack work for authentication subkeys?

If you steal the entire subkey, then depending on the authentication flow, it might still work; though it would only lead to a real attack if you whitelist the issuer (sub)key fingerprint, and then trust the primary key & e.g. display the User ID based on that, which would admittedly be a strange thing to do, though the spec text might lead you to believe that this would be sound.

Yes, hockeypuck uses pm/g-c for binding signature verification. If we were to import this change, the majority of the authentication subkeys currently in the SKS dataset would have their bindings invalidated and get deleted...

Alrighty, fair enough.

[andrewgdotcom]

for authentication subkeys, they can be used to create signatures according to https://www.rfc-editor.org/rfc/rfc9580.html#name-authentication-via-digital-.

Yeah, this paragraph in the spec is odd, because the only way to create an authentication signature with an OpenPGP authentication subkey is to convert the key material to OpenSSH format and then make an OpenSSH signature. But that's an argument for another time. :-)

I suppose we could keep authentication keys out of it for now (since we never use authentication subkeys anyway), or restrict that requirement to v6?

I wouldn't object to a v6-only version of this, but I'd like to discuss it on the WG first since it is a breaking change in practice (even if we disagree about the spec).

Alrighty, fair enough.

Thanks. :-)

[wiktor-k]

Yeah, this paragraph in the spec is odd, because the only way to create an authentication signature with an OpenPGP authentication subkey is to convert the key material to OpenSSH format and then make an OpenSSH signature.

Agreed on the paragraph being weird. I wonder if the author wanted it to be generic to cover multiple authentication schemes (not just OpenSSH, for which the text doesn't apply anyway).

Just a slight technical clarification: for OpenSSH the key material doesn't need to be converted to OpenSSH format, it's just the raw cryptographic signature needs to be done over OpenSSH-framed data and then packed in OpenSSH framing. This distinction is apparent for key material that is HSM-backed and doesn't involve OpenPGP packets at all (e.g. here).

See ya! 👋

[twiss]

Yeah, this paragraph in the spec is odd, because the only way to create an authentication signature with an OpenPGP authentication subkey is to convert the key material to OpenSSH format and then make an OpenSSH signature. But that's an argument for another time. :-)

I don't think this needs to be true in general, although it might be true in practice. Following the instructions there, you could just create a normal OpenPGP signature using an authentication subkey, and use that in some (custom) authentication protocol. Though I don't know whether anyone does that, but that's what the text seems to suggest to me.