Re: What are CERTDB_INVISIBLE_CA and CERTDB_GOVT_APPROVED_CA used for?
Hubert Kario <[email protected]> Tue, 11 Dec 2018 14:50:00 +0100
| Newsgroups | gmane.comp.mozilla.security |
|---|---|
| Message-ID | <[email protected]> |
--===============5151662906595994895== Content-Type: multipart/signed; boundary="nextPart9036331.MyV7auWdIY"; micalg="pgp-sha512"; protocol="application/pgp-signature" --nextPart9036331.MyV7auWdIY Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Friday, 7 December 2018 23:26:32 CET Eli the Bearded wrote: > In mozilla.dev.security, Jeremy Rand <[email protected]> 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 > > . > >=20 > > 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. >=20 > This four year old bug report claims they are not used anymore: >=20 > https://bugzilla.mozilla.org/show_bug.cgi?id=3D1045907 >=20 > 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). >=20 > 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. >=20 > I'm not sure if CERTDB_VALID_CA or CERTDB_INVISIBLE_CA are even > stored anymore. I know NSS doesn't actually use them. >=20 > Not sure if that's the reassurance you want. >=20 > 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=20 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 bot= h=20 the 'g' flag (to specify Government Approved CA) or 'i' (to supposedly make= it=20 invisible) in certutil trust flags, none of them have any effect - the CA=20 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=3DCERTDB_INVISIBLE_CA that would indicate special handling =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart9036331.MyV7auWdIY Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAlwPwIgACgkQkqjRuAHS 9fV14g//UfLl+4O1eeFylXiLQICp1RRFpSsYXTRe7GPQeNiaBL5e3spjw+xY/xxP JZx1pJC45k+SF/8DE+ktJrsdgWRFbV94bXw+jM/tc8YucZUt2ajpdKNOWlfxlRwQ 6im/RgHc2p5N25L2uwUw6Jwr3UosHXSnqJFegiNckMGFgZOloo1BPBVpd+hpRAZA t0SiHu9pkHw0tWKrQcGMs5m97fD84AQ6kc+yQ5aqtrcsT+8q9k0XNvFuEl7Ubxh9 AnzOKiG77p2gsctjtqNC4hJEQUkn3+wtSwuAbF/gD07RuiR6LhtLwLrF9l9aTqlW pVBt2E0gMX46Yl5GEWyntmSBY+kgnb6CFDpZIUqh935E2rwn4Dz6qPnEEaEhCCKq rj05DOtCnmwlqLz30zfGHDtGtvQG42pQYSXegU5jatkqCJ8MO/BxkOajbgHGWq/m 2G7gmJqfjJB+szngrTLALe03cc3dE8Qat5YHNDg8FTYFy6XXD/A2cegGMLRsjbt7 Jr5vkdIxYJQT0i+EsyHxW/yzxq1MnBldY9UijfQgsrS+5GBujnrEF1JiaUbm5Of/ 6CdLGzkpR4GbU0CqTULCejf/DmHMtsIy0TnVUkX20CDrc/gF90aa9Xsl04Kcb3LY TJkxiu693n0CuLo/1nIG2jyWJXo+siusRn3KGmvsI2PslHAR90E= =fVgZ -----END PGP SIGNATURE----- --nextPart9036331.MyV7auWdIY-- --===============5151662906595994895== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security --===============5151662906595994895==--