Page MenuHome GnuPG
Create Task
Maniphest T5450

gpgsm --with-colons --list-keys misreports uid: lines where cert subject DN contains an emailAddress component
Closed, ResolvedPublic
Actions

Description

The certificate below can be extracted from a multipart/signed message sent to the quic mailing list at the ietf.

-----BEGIN CERTIFICATE-----
MIIF9DCCA9ygAwIBAgIPAXZRPSJ2GTmC5dcxnqeCMA0GCSqGSIb3DQEBCwUAMEcx
CzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nz
b24gTkwgSW5kaXZpZHVhbCBDQSB2MzAeFw0yMDEyMTEwOTU4NDlaFw0yMzEyMTIw
OTU4NDlaMF4xETAPBgNVBAoMCEVyaWNzc29uMRowGAYDVQQDDBFNYWdudXMgV2Vz
dGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nz
b24uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAiE+lPXXVKVAh
K8iANu8bRfFrEQCH3OYwWr37tDhg5sCE2GEQ9j2jBHRCviOHas9H+sXAqw5wZNl4
/icY4WkZKkwInyWYpmvVhNiaCP7qvFLEthyVpYbKQMCsdaLAEYLUYjI0WWcsn4kW
S24Fx1mKZ07d4vULLl/7qPaGRVqQwm2XnuCJfbpXbFHLgS2cdj8mbwbwvCglGgV7
GV+m8Fe4bLEVZ/gYBQrhInryTMdJIU0VYYvYKDm8buSZeOEbcG2TWAdVBNSM0VhG
cPm93BL14kIz5dnt8rTGUpocviGipo8REujg4roedSgHJj2X2SGl9nY5g++mBovh
E5p2/F5t3QIDAQABo4IBxDCCAcAwHwYDVR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq
49stplMwHQYDVR0OBBYEFCAjv/PE9BELxFJufh1bf3fTJvmfMA4GA1UdDwEB/wQE
AwIFoDBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixo
dHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzApBgNV
HREEIjAggR5tYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20wSAYDVR0fBEEw
PzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGlu
ZGl2aWR1YWxjYXYzLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIw
gYIGCCsGAQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0
LnRlbGlhLmNvbTBIBggrBgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29u
ZXJhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjMuY2VyMA0GCSqGSIb3DQEB
CwUAA4ICAQDUWV0MvpVFve7mi7gKTosZwyi6VKM/jf+TsHf/YpZZm8UAxGNf6T7O
CiUr8PPKfhd25js2/ny1DWujIv9k8PNxcxFZjt0asyrXGviPRg6UUPKFi+4a1Dya
DWnInUmS5gD+C+JMByIbxjV+H9XP6AeHwJD/8WbAAMWIu5ysXVwNp/yjFjZHs8gf
QUrA/GTkuKVlPFGmY3ea9H86jOc0G1OBD6h2vIxTEjM9VK2FzyisZehOFgN0xMNa
C43JYtDVhkB8kPtyoe33usz6F3y3f9hEI69qO+rLIKKndldTMeU0R3VMsYyDDxDl
WKb3HqzVAYRAZGjkPRboGHDITHPARe50GavobC/0+4nYOIBNrBHzXSvUQX/xFR9d
BjK5m2nak8nM7Q9YFC93VUMYpOEwjMSHLbfV6rUxh2jHsGS0AF6f7B1pVP75s/W6
3Ls2EPWFXeYU3p3RjFMhoVj1fyr8aLijys3axnhKlEAngcFoEAEkDTq6U8zCcGQF
f1sNxMUAox735b1EM1blNLAugBFZIKjAEyF0uoeq4yy99aY7diVfOF0YxeWn2JHE
SB07K7XKFnhbTrvxqWTYbavrXXtEL55ErI3MzFlNICpNIVwZl8BBlIprg1av1r69
Jq9fHfZigOsTzUDn5/1S+Qll2tdTrTo4/FrE8t11KcienXPWe9k5ig==
-----END CERTIFICATE-----

The DN contains an emailAddress component, which gpgsm correctly renders when using gpgsm --list-keys 0x248BEABE.

However, using gpgsm --with-colons --list-keys magnus produces a uid: line that doesn't display the e-mail address element, instead producing:

uid:::::::::1.2.840.113549.1.9.1=#6D61676E75732E7765737465726C756E64406572696373736F6E2E636F6D,CN=Magnus Westerlund,O=Ericsson::

I traced this back to the append_atv function in libksba's src/dn.c which apparently only renders items in the oid_name_tbl with a source of 1 (rfc 2253). But the EMAIL entry is referenced as having a source of 3 ("Peter Gutmann"), despite it being present in rfc 2985.

I'm seeing this in libksba version 1.5.0 (in debian unstable) but it appears to be present in libksba's main branch as well.

The easiest fix appears to be to modify append_atv to accept and render tags that have arbitrary source values. ea11f8ef7fd665c98216e23b7bf247fc793414ae introduced the source field, but the text doesn't justify why sources other than RFC 2253 aren't acceptable to be appended as a named tag.

Other X.509 certificate-parsing tools (including GnuTLS's certtool -i and openssl x509 -text) are willing to render the field as an e-mail address.

Details

Version
1.5.0

Related Objects

Event Timeline

dkg created this task.May 26 2021, 3:25 AM
dkg added a comment.May 26 2021, 3:32 AM

Attached is a proposed patch.

0003-dn-render-any-known-DN-string-tag-not-just-those-fro.patch890 BDownload

dkg added a comment.May 26 2021, 3:39 AM

I'm reporting this because the above message renders poorly in notmuch -- notmuch gets the user ID from gmime's g_mime_certificate_get_user_id, and gmime populates that field from the uids field of a gpgme_key_t object, and gpgme pulls uid information from gpgsm --with-colons.

It's not useful to see a MUA report:

[ Good signature by: 1.2.840.113549.1.9.1=#6D61676E75732E7765737465726C756E64406572696373736F6E2E636F6D,CN=Magnus Westerlund,O=Ericsson ]
• werner closed this task as Resolved.May 26 2021, 6:00 PM
• werner claimed this task.
• werner added a subscriber: • werner.

We translate only those OIDs from RFC-2253 to have a stable set of names in the libksba interface. If you need anything else, you need to do this yourself. For example gpgsm does this in in parse_dn_part, gpa has the code in format-dn.

Sorry, this won't be changed in libksba.

dkg added a comment.May 26 2021, 9:03 PM

fwiw, RFC 2253 is obsoleted by rfc 4514 -- which also doesn't have 1.2.840.113549.1.9.1 associated with "EMAIL", but does provide more detailed guidance for implementers of DN-to-string (and string-to-DN, to the extent that this is possible) conversions. Maybe the code should be updated to refer to the non-obsolete specification at least.

The result here is that consumers of user IDs from gpgme in an X.509 certificate context are in a bit of a bind.

What i'm hearing from this is that any user of gpgme that wants to produce a human-readable user ID needs to be capable of both of the following:

  • identify when a given uid field from a gpgme_key_t is in fact a DN. For example, when a uid record comes from an OpenPGP certificate, it is not a DN. Likewise, when a uid is reported from an X.509 certificate's subjectAltName, the record is also not a DN. I don't know how to do this.
  • In a situation where a uid is somehow determined to be a DN, it needs its own parser of string representations of a DN, along with a database of likely candidate representations similar to the table already found in libksba's src/dn.c.

Is this the expected situation? If so, do you have any recommendations for how a gpgme user is supposed to distinguish between a DN uid and the other gpgme_key_t.uids?

dkg added a comment.EditedMay 26 2021, 9:34 PM

Another solution to make life easier for gpgme users encountering this stuff would be if gpgme itself knows which uid is a DN and which is not, it could populate the gpgme_user_id_t.address field with content of the 1.2.840.113549.1.9.1 DN component. (or maybe gpgme_user_id_t.email, or both? as a user of gpgme, i don't really understand the difference between these fields)