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)
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jun 10 2021
May 26 2021
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.
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
In T5395#145417, @gniibe wrote:I can't see null pointer de-reference (you claimed) in [4/5].
Could you please elaborate?
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
gniibe wrote:
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.
Comparing old cms.asn and new cms.asn, now I understand how RFC 3370 matters. I added those things back from RFC 5911 (which cites RFC 3370) which comes with BSD license for code.
May 30 2019
@gniibe thank you!
I did some work (since Debian is important for us).
Please have a look at my topic branch: gniibe/fix-4487
or:
https://dev.gnupg.org/source/libksba/history/gniibe%252Ffix-4487/
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libksba.git;a=shortlog;h=refs/heads/gniibe/fix-4487
May 29 2019
Perhaps i wasn't clear enough in the earlier messages on this thread. The inclusion of restrictively-licensed code in a file that also claims LGPL/GPL appears to be an unredistributable license. Could you please clarify why the GPL or LGPL applies to libksba while it contains src/cms.asn in its current form?
May 24 2019
Interesting tinge: The main CRL of the dgn.de CA uses a nextUpdate in the year 2034 (15 years in the future) which would force dirmngr to cache the CRL until then. However, the CRL of the intermediate certificate has a nextUpdate only one month in the future. There is currently no entry in that second level CRL, so their idea might be that an updated second level CRL will also trigger a reload of the main CRL. I have not checked how we implement that in Dirmngr but I doubt that such a thing will work for us and that it is in any way standard compliant.
May 8 2019
Thanks for the explanation.
If the ASN.1 is not from an RFC, then the AUTHORS file should not claim that it is from an RFC.
May 7 2019
As I want to keep this tracker clean I would say this is a Wontfix at least until someone (DKG?) provides an argument what would be gained and why we should do this.
That is not a functional feature request and I see no value in chnaging data structures just for being up to the latest RFC. Actually the ASN.1 is not from an RFC but from a specific X.509 profile. For CMS most parsing is anyway done with handcrafted code.
May 6 2019
Feb 27 2019
We also need to fix for encryption and signature in CSR.
Feb 19 2019
Jan 17 2019
Applied.
Jan 16 2019
Done for gpgme.
Jan 15 2019
Done for libgcrypt.
Jan 14 2019
I give this normal priority to move it out of the "Needs Triage" queue.
Jan 10 2019
Done for libgpg-error.
Topic branch of libgpg-error is not good to show changes (for other libraries).
So, I made D473: Introducing LDADD_FOR_TESTS_KLUDGE to enable 'make check' with LD_LIBRARY_PATH.
Appliying to libgpg-error.
Jan 8 2019
For other distros, it seems it's quite old issue: https://sourceware.org/ml/binutils/2012-05/msg00037.html
My patches on the topic branch: https://dev.gnupg.org/source/libgpg-error/history/gniibe%252Fdisable-new-dtags/
Jan 7 2019
My tentative conclusion: When (GNU) ld supports --disable-new-dtags, add it to LDADD in tests/Makefile.am.
Dec 20 2018
Reading this discussion: http://lists.gnu.org/archive/html/bug-libtool/2018-01/msg00014.html
It seems that it could be fixed if we care about the order of libraries.
And it's not the issue for libgpg-error, which doesn't require external libraries.
For binutils, in Stretch, Debian specific patch was introduced.
Then, upstream introduced --enable-new-dtags option for configure to build binutils.
Now, Debian uses --enable-new-dtags option (at build time).
Dec 17 2018
Dec 13 2018
Oct 29 2018
New gpg-error.m4 detects gpgrt-config, too.
And configure supplies --libdir when it invokes gpgrt-config.
For other *.m4 (libassuan, ksba, libgcrypt, ntbtls), it is possible for them to check GPGRT_CONFIG to use gpgrt-config if any.
For npth.m4, it can do that too, with no hard dependency to libgpg-error.
Oct 26 2018
Oct 25 2018
A bit tricky, but this would be good to use gpgrt-config by gpg-error.m4.
I say "tricky", because its name is gpg-error.m4 but it configure GPGRT_CONFIG to access to GPG_ERROR_CONFIG.
It might be good idea to provide libgcrypt.pc in libgcrypt 1.8.x for forward compatibility with libgpg-error 1.33.
Well, I changed my mind. Use of new gpgrt-config requires software update to introduce gpgrt.m4 and update of configure.ac to switch gpgrt from gpg-error, in standard way.
That's too much this time. It's good to defer this change.
OK, I'll change to use gpgrt-config, along with requiring newer version of libgpg-error.
Oct 24 2018
May I suggest to use a (new) gpgrt-config instead of the current name libgpg-error-config. The long term plan is to change the name of the library.