On Thu 2020-03-12 13:45:48 -0400, Daniel Kahn Gillmor wrote: > It's not clear how a receiving implementation would treat such a > composite certificate. GnuPG, for example, appears to take the union of > all validity times when it comes to expiration (valid through 2025), but > the intersection of all capabilities when it comes to key usage flags > (primary key is certification-capable only): > > > pub rsa3072 2020-03-12 [C] [expires: 2025-03-11] > 7138FE5EB6895581ED99E3AD3CB7A19683B428D1 > uid [ultimate] <[email protected]> > uid [ultimate] <[email protected]> > sub rsa3072 2020-03-12 [E]
Hm, i take back the assertion above about unions and intersections.
Rather, it appears that in the case of a conflict, GnuPG simply prefers
the self-sig over the user ID that appears *first* in the certificate.
However, since certificates are trivially reorderable by anyone (not
just the primary key holder) this means that i can make the certificate
look different just by rearranging things.
The attached alice-reordered.key certificate contains the exact same
OpenPGP packets, but in a different order. Importing it into an
otherwise empty GnuPG homedir now shows:
pub rsa3072 2020-03-12 [SC] [expires: 2022-03-12]
7138FE5EB6895581ED99E3AD3CB7A19683B428D1
uid [ultimate] <[email protected]>
uid [ultimate] <[email protected]>
sub rsa3072 2020-03-12 [E]
I've noted this weirdness over at https://dev.gnupg.org/T4879, fwiw.
Anyway, i think this is a pretty clear argument that "hokey lint" should
warn if there is incompatible key metadata in the relevant self-sigs.
--dkg
alice-reordered.key
Description: application/pgp-keys
signature.asc
Description: PGP signature
_______________________________________________ Pkg-haskell-maintainers mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-haskell-maintainers
