On Friday, 7 December 2018 23:26:32 CET Eli the Bearded wrote:
> In mozilla.dev.security, Jeremy Rand wrote:
> > I was digging through the NSS source code, and I ran across two
> > undocumented trust flags: CERTDB_INVISIBLE_CA and CERTDB_GOVT_APPROVED_CA
> > .
> >
> > As far as I can tell, CERTDB_INVISIBLE_CA seems to indicate that the UI
> > should hide the existence of the CA from the user, while
> > CERTDB_GOVT_APPROVED_CA seems to have something to do with crypto export
> > regulations. I'm wondering if anyone can explain what exactly the
> > intended purpose of these flags is, and whether they actually have any
> > effect in any of the NSS software ecosystem (including Firefox, but also
> > including the NSS certificate verifier, any of the various NSS tools
> > distributed by Mozilla, and anything else that uses NSS that you're
> > aware of). I can't think of any reason for CERTDB_INVISIBLE_CA to exist
> > (other than making it easier for backdoors to be stealthily inserted,
> > which I assume isn't the intended use case), and I'm also surprised that
> > CERTDB_GOVT_APPROVED_CA is a thing in 2018 since (as far as I know)
> > crypto export regulations haven't existed for a couple of decades.
>
> This four year old bug report claims they are not used anymore:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1045907
>
> Comment 4 (in part):
> > However, note line 1670. CERTDB_PRESERVE_TRUST_BITS is
> > (CERTDB_USER | CERTDB_NS_TRUSTED_CA |
> > CERTDB_VALID_CA | CERTDB_INVISIBLE_CA | CERTDB_GOVT_APPROVED_CA).
>
> So these don't have mappings through the PKCS #11 trust interface.
> CERTDB_USER is set based on finding the associated private key.
> CERTDB_GOVT_APPROVED_CA is set based on a different PKCS #11
> attribute. It's no longer used by NSS.
> CERTDB_NS_TRUSTED_CA isn't used either.
>
> I'm not sure if CERTDB_VALID_CA or CERTDB_INVISIBLE_CA are even
> stored anymore. I know NSS doesn't actually use them.
>
> Not sure if that's the reassurance you want.
>
> Elijah
> --
> agrees that CERTDB_INVISIBLE_CA seems a dangerous thing
yes, *if* it worked as its name suggests
but NSS prises itself also on backwards compatibility, that unfortunately
means that some identifiers that are no longer used need to be defined still
as far as I can tell the MZBZ#1045907 is correct; while you can specify both
the 'g' flag (to specify Government Approved CA) or 'i' (to supposedly make it
invisible) in certutil trust flags, none of them have any effect - the CA
remains visible and the 'G' flag is not reported
I didn't find any other references to that constant:
https://searchfox.org/nss/search?q=CERTDB_INVISIBLE_CA
that would indicate special handling
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
___
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
