Thu, Jun 10
Wed, May 26
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.1135126.96.36.199 DN component.
fwiw, RFC 2253 is obsoleted by rfc 4514 -- which also doesn't have 1.2.840.1135188.8.131.52 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.
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.
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.
Attached is a proposed patch.
Apr 21 2021
Thank you for your confirmation. Closing.
Apr 20 2021
I applied 1,2,3, and 5 in rKfbb1f303198b: Fixes for static analysis reports.
I can't see null pointer de-reference (you claimed) in [4/5].
Could you please elaborate?
Apr 14 2021
Apr 6 2021
Nov 23 2020
Released on 2020-11-18
Nov 18 2020
Nov 16 2020
May 19 2020
Seems to be fixed now.
Parsing and creating of certs does now work. I was not able to find sample CMS objects so this part is not yet finished.
May 14 2020
Won't fix because there is no need for it. ASN.1 modules are the formal description of a protocol and as such not copyrightable.
Thanks. Applied. Will go into 1.4.0
May 11 2020
May 4 2020
It works for me(tm).
Apr 21 2020
Apr 14 2020
Data (ie.e CMS) signatures do now also work.
Apr 9 2020
Okay certificate and CRL checking does now work with rsaPSS. Need to work on data signatures and check the compliance modes.
Apr 8 2020
I started to work on it so that I can actually use the certificates on my new D-Trust card. This will be a verify-only implementation.
Mar 31 2020
For public key, it's done.
Mar 30 2020
Mar 24 2020
This should work well with libksba master and gnupg/sm master.
Mar 5 2020
It is actually questionable whether PSS is a better padding scheme than PKCS#1, see
https://www.metzdowd.com/pipermail/cryptography/2019-November/035449.html . PSS seems indeed be rarely used; quoting Peter from a followup on his writeup: “If I get time over the weekend, and I can find a CMS message signed with RSA-PSS, I'll create a forgery using xor256.”
Mar 4 2020
To summarize: The DGN CRL uses a the RSA-PSS Padding / Signature Scheme. ( https://de.wikipedia.org/wiki/Probabilistic_Signature_Scheme )
Jan 8 2020
Sorting the table is a good idea for reproducibility, since otherwise the tree depends on the order of the arguments to asn1-gentables, which are generated with a wildcard expansion that might be shell or file system dependent.
Frankly, I am not sure why we sort that table at all. Your patch does not harm, though.
Jun 1 2019
May 31 2019
RFC 5280 only addresses about BCP78 and not about TLP, while RFC 5652, RFC 5755, RFC 5911 and RFC 5912 address explicitly about TLP. In this situation, I wonder if it's better to take the definitions of Extensions, UniqueIdentifier, and GeneralNames from RFC 5280. To be conservative, I don't include them now.
I pushed more changes to include modules in RFC 5911 and RFC 5912.