nss-{email, server}-distrust-after values ignored when generating certificate bundles

[DJ Lucas]

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