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==--