Accept subkey signatures #2905
Accept subkey signatures #2905
Conversation
16b1b24 to
b40f9b8
Compare
|
@drGrove I think this PR’s approach seems viable, at least for my purpose of Sequoia interoperability. Would that suit your purposes as well? |
|
(Marked as ready for review.) |
signature/mechanism_gpgme.go
Outdated
| } | ||
| // With https://github.com/proglottis/gpgme/pull/42, we could just | ||
| // return key.Fingerprint(), nil | ||
| subkey := key.SubKeys() |
There was a problem hiding this comment.
subkey returns a *SubKey, I think we'll want to iterate through this subkey.Next() until we hit the end. Currently the test keys only have a single signing subkey, but there is a chance that a subkey could also be an encryption or authentication subkey. Since a Primary key can have multiple signing subkeys AND signatures are only valid if they come from a signing subkey (certify key is only valid for signing another gpg key) we may need to return an slice
There was a problem hiding this comment.
I imagine a similar type of implementation will be needed in sequoia as well
There was a problem hiding this comment.
Re-reading this I'm realizing that we are providing the subkey fingerprint to get back the primary for comparison sake. The validation concern probably isn't a problem on the gpg side as the signature verification logic should already handle that but may be on the sequoia side (it's been a while since I've looked over the rust library but I remember it being pretty low level).
There was a problem hiding this comment.
Re-reading this I'm realizing that we are providing the subkey fingerprint to get back the primary for comparison sake.
Yes. The first element of Subkeys is the primary key.
The validation concern probably isn't a problem on the gpg side as the signature verification logic should already handle that
Yes.
but may be on the sequoia side (it's been a while since I've looked over the rust library but I remember it being pretty low level).
That’s handled as well, compare #2569 (comment) . But note the warning in the PR description.
Yes, this works just fine for me. Subkey pinning was a secondary thought and not something I'm necessarily concerned about currently. I was also able to vendor this into a build of |
9c984b7 to
5fd4bef
Compare
a151f4e to
970cb6d
Compare
Encapsulate the wanted/recorded tuples a bit more, to prepare for changes to the signatureAcceptanceRules type. Should not change (test) behavior. Signed-off-by: Miloslav Trmač <mitr@redhat.com>
…ryKeyFingerprints Move more code into the centralized function, to allow us to change the implementation in the future. Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Document how the key identities from NewEphemeralGPGSigningMechanism and SigningMechanism should relate. For the GPGME implementation where the relationship isn't as desired, introduce signingMechanismWithVerificationIdentityLookup . For the openpgp implementation, just fix the returned value to match new expecations. Currently, the simple signing verifyAndExtractSignature rejects subkey signatures for both mechanism implementations, so this does not change behavior for any previously-accepted signatures (but it might affect theoretical external direct callers of SigningMechanism). We will actually use this in the next commit. WARNING: Adding support for subkeys makes subkey revocation relevant. Revocation is always messy - to support long-term signature validity (which is very relevant for container image signing), smooth handling of revocation might require trusted timestamps (not natively supported in OpenPGP). In practice, this library (partially out of necessity) lets the underlying OpenPGP implementations impose their own policy, and that handling DIFFERS between various SigningMechanism implementations: it seems that GnuPG and refuses to use a revoked subkey regardless of revocation time, while Sequoia-PGP decides based on the revocation reason whether the revocation applies to all signatures or only to signatures (supposedly!!) made after the revocation happened. It is STRONGLY recommended to avoid all of this complexity, and to plan for workflows where subkey revocation never happens. Just revoke and reissue the whole key - either way you'll need to distribute an updated key to all consumers. Signed-off-by: Miloslav Trmač <mitr@redhat.com>
This does not change behavior for mechanisms which already always return the primary key fingerprint (after a recent change, openpgp); for the others, add support for signingMechanismWithVerificationIdentityLookup . Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Accept simple signing signatures made using a subkey.
This currently breaks because we insist that signature verification reports using a key which we know we have imported.
For the
openpgpmechanism, modify verification to report the primary key’s fingerprint.For GPGME, the information is not easily available (well, we’d have to collect subkey fingerprints on import, and that would affect public API); instead, if the returned fingerprint does not match, do another GPG operation to find the primary key’s fingerprint.
To do this, centralize the key identity matching a bit more in
verifyAndExtractSignature.See individual commit messages for details.
We need this because Sequoia-PGP generates, by default, keys where the primary key can only certify subkeys, and signing happens using a subkey. So, we must support signatures by subkeys in the other mechanism implementations.
See https://github.com/mtrmac/image/tree/sequoia-interop for a proof that this allows accepting Sequoia-PGP keys (for now, by GPGME at least).
Some users also want to use subkeys for other uses, so this will resolve containers/podman#16406 , but …
WARNING: Adding support for subkeys makes subkey revocation relevant. Revocation is always messy — to support long-term signature validity (which is very relevant for container image signing), smooth handling of revocation might require trusted timestamps (not natively supported in OpenPGP).
In practice, this library (partially out of necessity) lets the underlying OpenPGP implementations impose their own policy, and that handling DIFFERS between various
SigningMechanismimplementations: it seems that GnuPG andx/openpgprefuse to use a revoked subkey regardless of revocation time, while Sequoia-PGP decides based on the revocation reason whether the revocation applies to all signatures or only to signatures (supposedly!!) made after the revocation happened.It is STRONGLY recommended to avoid all of this complexity, and to plan for workflows where subkey revocation never happens. Just revoke and reissue the whole key — either way you'll need to distribute an updated key to all
consumers.