On 12/21/2022 3:33 AM, Daiki Ueno wrote:
IMO, those attributes should ideally be handled at run-time, not at
extraction time.
Yes, for GnuTLS and NSS, this makes sense, but as you've outlined below,
the OpenSSL, Java, and legacy flat bundles for GnuTLS have no mechanism
to handle the distrust-after values. My issue here is that the trust
utility's behavior was unexpected. A root that is explicitly distrusted
is still being placed into the downstream bundles as a trusted root.
This is an issue. We already have the ability to interpret the
distrust-after values. If extracting and we are passed that date, why
not simply interpret that certificate as distrusted for the purpose of
extract (this is no different than what would happen if using internally
at runtime - or after [2] below - which is good to see BTW). And, not
that I know how to fix this just yet, I haven't had a chance to dig in
with holiday and all, I was more hoping for "Oh, yeah, that makes sense
it'll be fixed in the next release." but I'll get around to it in a
couple of days. For LFS and like, it's not a big deal for me to adjust
the trust values on the fly after expiration, I've actually already done
that in both of my tools (temporarily, pending discussion here), it's
just the unexpected behavior that is in question.
p11-kit's support for nss-*-distrust-after is simply to passthrough
those attributes as PKCS#11 attributes (CKA_NSS_*_DISTRUST_AFTER[1]).
To use that information, there needs to be support from the client
libraries: the trust store is backed by PKCS#11 and those attributes are
respected when enumerating CA certificates from the trust store.
Hence, why I thought it odd that trust extract allowed the distrusted
certificates to be placed into the new trusted bundles.
Afaik, currently only NSS supports both, GnuTLS supports the former but
not for the latter[2], and OpenSSL does neither.
If there is an imminent need for disabling certain CA certificates, I
would suggest removing or blocklisting them[3].
Agreed, and I effectively have done this temporarily. This makes perfect
sense for normal distros, but nothing is normal about regular consumers
of LFS! :-) In this case, the end user is expected to maintain their own
trust store and PKI policy, hence the overreaching scope of the tools to
assist the user in adopting Mozilla and Microsoft's policies. I'm
anxious to see if/how the CCADB plays out with the major distros.
Footnotes:
[1]
https://github.com/p11-glue/p11-kit/blob/d39043f7c6e44247b5b1a237888e80b2a4d9c2b2/trust/test-extract.sh#L80
[2] https://gitlab.com/gnutls/gnutls/-/issues/912
[3] https://p11-glue.github.io/p11-glue/p11-kit/manual/trust-module.html
Thanks.
--DJ Lucas
