Enterprise advice: replace the root list

[ianG]

More fallout. We are entering a Brave New World.

This article is a fairly good summary of the implications. I've just
snipped out one section, because it is the first time an article seems
to have picked up the point: the universal implicit cross-certification
of the browser UI, coupled with the solid base of statistics for CA
hacking, means that an Enterprise can no longer rely on the root list:


====================
http://www.law.com/jsp/cc/PubArticleCC.jsp?id=1202517008883&From_the_Experts_SSL_Hacked

The most important step for corporate counsel and IT departments is to
collaborate on the quickest, perhaps most effective measure of all:
configuring the enterprise browser platform so as to reduce the number
of root CAs the enterprise relies upon.

First, weed out those root certificates that no one recognizes. If you
do not know the CA well, there is no way for you to trust that CA.

Second, weed out those root certificates that are used rarely or not at
all. If a root certificate is not being used, then its only purpose is
to loiter around in the browser platform until such time as it can be
leveraged against the enterprise in an attack. So just delete it.

Third, for those CAs that remain, take a few moments to interact with
the CAs .....
=====================


In short, the Enterprise must roll its own root list.

Now, this is a pretty obvious defence, so there's no point in debating
the efficacy. What Mozilla could do is make it a lot easier to follow
someone else's root list. That is, instead of having one root list
only, modify browsers to be able to follow one of many root lists
dynamically (daily update). As a user selection.

Mozilla's root list would be one. Corporate, another. CABForum. Mine,
yours. EFF, CAcert, USG. We could all do one.

iang

[David E. Ross]

How do we protect ourselves against a hostile hack of "someone else's
root list"? Frequent updates sometimes result in shortcuts in security.

--

David E. Ross
<http://www.rossde.com/>.

Anyone who thinks government owns a monopoly on inefficient, obstructive
bureaucracy has obviously never worked for a large corporation.
© 1997 by David E. Ross

[ianG]

On 29/09/11 12:16 PM, David E. Ross wrote:
> On 9/28/11 5:03 PM, ianG wrote:

> How do we protect ourselves against a hostile hack of "someone else's
> root list"? Frequent updates sometimes result in shortcuts in security.
>

We don't. If a user or enterprise sets up a new root list, they take on
total responsibility. They will be responsible for policing the root
list operator, just as (in theory) users who download firefox are
responsible for coming to this list and policing the operation of this
root list.

iang

[ArkanoiD]

Sure! The biggest problem is a lot of software used on the enterprise does
*not* provide an option to separate enterprise and public domains of trust for CA at all! And it really sucks, because it is the most obvious thing that needs to be done immediately: no one in sane mind would ever trust "big internet pki" to sign access to corporate infrastucture! And implementing this configuration while still being able to access outside resources is not always trivial.

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
> email protected and scanned by AdvascanTM - keeping email useful -
> www.advascan.com
>

[Stephen Schultze]

On 9/28/11 8:03 PM, ianG wrote:
> What Mozilla could do is make it a lot easier to follow someone else's
> root list. That is, instead of having one root list only, modify
> browsers to be able to follow one of many root lists dynamically (daily
> update). As a user selection.
>
> Mozilla's root list would be one. Corporate, another. CABForum. Mine,
> yours. EFF, CAcert, USG. We could all do one.

+1 to this suggestion.

In fact, this is something I've been saying a lot lately. At USENIX
Security, I described it as similar to the model of Ad Block
subscription lists. The session is here (Friday at 11AM, my comments
are during the discussion period):
https://db.usenix.org/events/sec11/tech/

Somebody just needs to put the pieces together:
https://groups.google.com/group/mozilla.dev.security/browse_thread/thread/f8afac1eef7cb4cd/3c6745b5dee31b00#5596694c6381a9ae

[Walter Goulet]

On Sep 28, 7:03 pm, ianG <i...@iang.org> wrote:
> More fallout.  We are entering a Brave New World.
>
> This article is a fairly good summary of the implications.  I've just
> snipped out one section, because it is the first time an article seems
> to have picked up the point:  the universal implicit cross-certification
> of the browser UI, coupled with the solid base of statistics for CA
> hacking, means that an Enterprise can no longer rely on the root list:
>

> ====================http://www.law.com/jsp/cc/PubArticleCC.jsp?id=1202517008883&From_the_...

>
> The most important step for corporate counsel and IT departments is to
> collaborate on the quickest, perhaps most effective measure of all:
> configuring the enterprise browser platform so as to reduce the number
> of root CAs the enterprise relies upon.
>
> First, weed out those root certificates that no one recognizes. If you
> do not know the CA well, there is no way for you to trust that CA.
>
> Second, weed out those root certificates that are used rarely or not at
> all. If a root certificate is not being used, then its only purpose is
> to loiter around in the browser platform until such time as it can be
> leveraged against the enterprise in an attack. So just delete it.
>
> Third, for those CAs that remain, take a few moments to interact with
> the CAs .....
> =====================
>
> In short, the Enterprise must roll its own root list.
>
> Now, this is a pretty obvious defence, so there's no point in debating
> the efficacy.  What Mozilla could do is make it a lot easier to follow
> someone else's root list.  That is, instead of having one root list
> only, modify browsers to be able to follow one of many root lists
> dynamically (daily update).  As a user selection.
>
> Mozilla's root list would be one.  Corporate, another.  CABForum.  Mine,
> yours.  EFF, CAcert, USG.  We could all do one.
>
> iang

+1 on the idea (not entirely in agreement with the article however). I
setup enterprise PKIs for a living and can tell you that having an
'enterprise' trust list that enterprise users could point their
browsers too would make life vastly easier for enterprise PKI
administrators. As another poster pointed out, it's generally viewed
as a bad idea to use public CAs to sign certs for enterprise
applications/servers/devices (enterprise doesn't control actions of
the CA). But, the pain of updating all browsers and other relying
parties with an enterprise root list today is so painful, I've seen
several customers go with the public CA route anyways. This is an area
where I'm actually quite thankful for Microsoft AD and IE; at least I
can roll out custom trust lists in AD to large enterprises in a matter
of hours. For FF, however, I'm not aware of anything similar.

Walter

[Kathleen Wilson]

Is there a bug (enhancement request) or an add-on for the ability to use
different root lists?

My understanding is that the main reason that in-premise enterprise
sub-CAs chain to a root in NSS is interoperability with their customers
and business partners. I'm not convinced that this enhancement would
solve this need. However, I see that this enhancement would be useful
within an enterprise.

Kathleen

[Walter Goulet]

Agreed; the need to chain to a root in NSS for interoperability with
customers/business partners is certainly a valid use case. However,
the lack of an easy way to manage FF's trust lists in a centralized
fashion makes it tempting to use certs issued by a public CA for
internal use. An enhancement which permitted FF to use externally
specified root lists would eliminate motivation to use publicly issued
certs for internal use only.

[Kathleen Wilson]

Enhancement request has been created:
https://bugzilla.mozilla.org/show_bug.cgi?id=692248

Kathleen

[Walter Goulet]

Thanks Kathleen. One more thought for consideration; it would be
useful if such an external list could be stored in a repository that
just about any enterprise would support such as an enterprise LDAP
directory (Microsoft Active Directory, OpenLDAP, OpenDS etc.) Then the
external trust list lookup could be a simple LDAP query that FF would
perform on startup. I'll follow the comments on the enhancement
request and see what the devs have to say.

Walter

[Robert Malmgren]

On 10/5/11 10:42 PM, Walter Goulet wrote:

> Thanks Kathleen.

second that!

> One more thought for consideration; it would be
> useful if such an external list could be stored in a repository that
> just about any enterprise would support such as an enterprise LDAP
> directory (Microsoft Active Directory, OpenLDAP, OpenDS etc.) Then the
> external trust list lookup could be a simple LDAP query that FF would
> perform on startup.

+1 on that.

But consider the sensitivity of this, from an attack vector perspectiv,
should it be mandated it should be LDAPS (and thus also introducing a
nice catch 22 :-). Else, how should one bootstrap something like that?

> I'll follow the comments on the enhancement
> request and see what the devs have to say.

Me too.

--r

--
---
Robert Malmgren Encrypted e-mail preferred
E-mail: r...@romab.com PGP RSA 4096, id: 0x5B979EF5
Cellular: +46(0)708-330378 Fingerprint: DE59 D86C 4CAF 2E59 A64E
Jabber: r...@romab.com 5476 2360 F1B4 5B97 9EF5

[Jean-Marc Desperrier]

Robert Malmgren wrote:
> consider the sensitivity of this, from an attack vector perspectiv,
> should it be mandated it should be LDAPS (and thus also introducing a
> nice catch 22:-). Else, how should one bootstrap something like that?

Step by step, this is getting nearer from Microsoft's Update Root
Certificates component :
http://technet.microsoft.com/fr-fr/library/cc749331%28WS.10%29.aspx#BKMK_How

The list is downloaded from
http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab
(at least for some versions of Windows) and signed by "Microsoft
Certificate Trust List Publisher" under "Microsoft Root Certificate
Authority"

[Walter Goulet]

On Oct 7, 7:12 am, Jean-Marc Desperrier <jmd...@gmail.com> wrote:
> Robert Malmgren wrote:
> > consider the sensitivity of this, from an attack vector perspectiv,
> > should it be mandated it should be LDAPS (and thus also introducing a
> > nice catch 22:-). Else, how should one bootstrap something like that?
>
> Step by step, this is getting nearer from Microsoft's Update Root

> Certificates component :http://technet.microsoft.com/fr-fr/library/cc749331%28WS.10%29.aspx#B...
>
> The list is downloaded fromhttp://www.download.windowsupdate.com/msdownload/update/v3/static/tru...

> (at least for some versions of Windows) and signed by "Microsoft
> Certificate Trust List Publisher" under "Microsoft Root Certificate
> Authority"

I would argue this is the opposite of what is being requested. The
Update Root Certificate component updates the list of roots that are
trusted by Microsoft; in other words the source of trusted information
is still from Microsoft. If you want to add your own enterprise root
CA to your trust list, you do it by publishing your root certificate
as a trusted root authority in Active Directory (in a Microsoft
environment). What is being requested is something similar for Firefox
(although I'm not convinced LDAPS is really necessary for an
enterprise LDAP lookup) so that Firefox can use an internally
maintained trusted list of root certs.

As far as I can tell in my research, the only way to provide similar
functionality today would be to create a script that updates the NSS
root cert database using tools like addcert and have such a script be
executed on all hosts using Firefox.

[Stephen Schultze]

On 10/7/11 2:06 AM, Robert Malmgren wrote:
>
> On 10/5/11 10:42 PM, Walter Goulet wrote:
>> One more thought for consideration; it would be
>> useful if such an external list could be stored in a repository that
>> just about any enterprise would support such as an enterprise LDAP
>> directory (Microsoft Active Directory, OpenLDAP, OpenDS etc.) Then the
>> external trust list lookup could be a simple LDAP query that FF would
>> perform on startup.
>
> +1 on that.

I have to vote -1 on this particular suggestion. As much as enterprise
folks love complex solutions like LDAP, such systems are not highly
usable for non-enterprise folks... to run or to use. I see no reason
why the standard shouldn't be flat files served over HTTP(s), like the
AdBlock lists:

https://adblockplus.org/en/subscriptions

[Walter Goulet]

On Oct 7, 9:10 am, Stephen Schultze <sjschultze.use...@gmail.com>
wrote:

Agree LDAP is not for the faint of heart, but do we really need
another standard when LDAP is well known and supported in most
enterprise environments? I'd argue that for non-enterprise users, CA
trust agility is better served by solutions like Convergence.

[Stephen Schultze]

LDAP may be a standard, but how to represent a certificate list is not.

Convergence is a completely different trust model, not a substitution
for this approach.

Would you like to prevent global human rights activists from using this
feature just because you think that enterprise users would prefer to
take the misguided approach of mangling the data into a directory server?

Let the enterprise users post flat files too. I guarantee that they
will make less mistakes anyway.

[Walter Goulet]

On Oct 7, 9:37 am, Stephen Schultze <sjschultze.use...@gmail.com>

I fail to understand why you think using LDAP is misguided; after all
that's what directory servers are for, providing information that can
be centrally managed and distributed easily to users of the service.
Seems like a natural fit especially with all the tools that enterprise
admins have for administrating LDAP directories.

That being said, the protocol used to disseminate the information is
not that important to me, the functionality is what matters. If
serving such information over HTTP makes the feature more generally
useful and increases the possibility of it's adoption then I'm OK with
it.

[Stephen Schultze]

LDAP is too complex a tool for a simple task, and it's inaccessible to a
large part of the potential user base... that's why I think it's
misguided for this purpose.

[Paul Tiemann]

On Oct 7, 2011, at 9:02 AM, Stephen Schultze wrote:

> LDAP is too complex a tool for a simple task, and it's inaccessible to a large part of the potential user base... that's why I think it's misguided for this purpose.

For the Enterprise side: Couldn't Firefox automatically detect when it is installed on a computer that is joined to an Active Directory domain, and in such a scenario, couldn't it use the system-level trust anchors (or import or sync them?) That way we don't have to invent another way to do it -- Active Directory in the enterprise is how people push out custom trust anchor lists currently for the rest of their Windows Certificate Stores at least.

For the non-Enterprise users: A simple text file would suffice, but should it be signed like mozilla plugins are, to help avoid tampering and inserting "Secret Police Special MITM CA" to someone's list? Or should they just be available via the mozilla addons infrastructure altogether, and not hosted at any ad-hoc URL? If you hosted them at AMO, then you could provide statistics on how many people have downloaded it (a relative indicator of popularity at least?)

I'm reminded of an IETF draft I heard about a while ago: TAMP (Trust Anchor Management Protocol)

http://tools.ietf.org/html/draft-ietf-pkix-tamp-08

[Walter Goulet]

I think building in detection for Firefox to determine whether or not
it is part of an AD domain is a little too complex (and platform
specific). That's why I'm advocating using LDAP since custom trust
anchor lists are published as objects in LDAP (Active Directory is
just a customized LDAP server); although as Steve pointed out the
format of certificate trust lists is not standardized AFAIK. This way,
FF clients on all platforms get to benefit from the CA trust info
published to AD.

[Brian Smith]

Paul Tiemann wrote:
> For the Enterprise side: Couldn't Firefox automatically detect when it
> is installed on a computer that is joined to an Active Directory
> domain, and in such a scenario, couldn't it use the system-level trust
> anchors (or import or sync them?)

I would like to do this:

1. Use the system trust database to decide what trust anchors are to be used.

2. If a root is trusted by the system, but not trusted or distrusted by Mozilla, then we would consider it to be an "enterprise" root. If is in Mozilla's root program AND the system trust store, then consider it the same way we do now. This would allow and require distinct security indicators for connections that are using "enterprise" roots.

> For the non-Enterprise users:

Non-enterprise users would use their operating system tools to manage what roots they trust, so we wouldn't distinguish between enterprise and non-enterprise users.

Separately, we would use the operating system's client certificate store / smartcard system. And, we change our certificate request (<keygen>) infrastructure to use the system's client cert store.

Put all together, we would then be able to remove all of the end-user certificate management features from our products, except the exception/override mechanism.

- Brian

[Rob Stradling]

On Friday 07 Oct 2011 20:00:58 Brian Smith wrote:
> Paul Tiemann wrote:
> > For the Enterprise side: Couldn't Firefox automatically detect when it
> > is installed on a computer that is joined to an Active Directory
> > domain, and in such a scenario, couldn't it use the system-level trust
> > anchors (or import or sync them?)
>
> I would like to do this:
>
> 1. Use the system trust database to decide what trust anchors are to be
> used.
>
> 2. If a root is trusted by the system, but not trusted or distrusted by
> Mozilla, then we would consider it to be an "enterprise" root. If is in
> Mozilla's root program AND the system trust store, then consider it the
> same way we do now. This would allow and require distinct security
> indicators for connections that are using "enterprise" roots.

Brian, I think you might be on to a good idea here, but I have some
questions...

Firstly, what about Roots that are trusted by Mozilla but NOT trusted by "the
system trust database" ?
(IMHO, you should "consider it the same way we do now" in these cases too).

> > For the non-Enterprise users:
> Non-enterprise users would use their operating system tools to manage what
> roots they trust, so we wouldn't distinguish between enterprise and
> non-enterprise users.
>
> Separately, we would use the operating system's client certificate store /
> smartcard system. And, we change our certificate request (<keygen>)
> infrastructure to use the system's client cert store.

Which "operating systems" are you intending to support?

I can see how your proposal would work with the Windows and OSX system trust
databases.

But what about Linux? Isn't NSS/certdata.txt the closest thing Linux has to
"operating system tools to manage what roots they trust" and a "system trust
database" ? (This appears to be the view of Google [1] and Red Hat [2]
anyway)
Are you envisaging there being 2 installations of NSS on each Linux system?
1: A "system" NSS install.
2: A "local" NSS install for each application (e.g. Firefox).
And so if a Root has been added to the "system" NSS's certdb, but is not
present in the "local" NSS's certdb, then it would be regarded as an
"enterprise" Root?

[1] http://www.chromium.org/developers/design-documents/network-stack/ssl-
stack
"We want Chromium to integrate nicely with the OS.
- Use the system certificate and key stores.
- On Linux, we use SQLite-based NSS databases in $HOME/.pki/nssdb,
following the NSS Shared DB and LINUX proposal."

[2] http://fedoraproject.org/wiki/FedoraCryptoConsolidation

> Put all together, we would then be able to remove all of the end-user
> certificate management features from our products, except the
> exception/override mechanism.

You want to remove NSS's command-line utilities (e.g. certutil) ?!?

Or is certutil not an "end-user certificate management feature"?
Or does certutil fall outside your definition of "our products"?

Thanks.

> - Brian

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

[Brian Smith]

Rob Stradling wrote:
> Firstly, what about Roots that are trusted by Mozilla but NOT trusted
> by "the system trust database" ?
> (IMHO, you should "consider it the same way we do now" in these cases
> too).

If we did consider it the same we do now, then we wouldn't really be solving the problem of helping sysadmins control the list of trusted roots. So, I would propose that if the user or system administrator wants these additional roots to be trusted, then he/she would have to add them to the system root store. (Anyway, I believe that getting into Microsoft's root program should be a prerequisite for getting into ours, at least unless/until we make substantial improvements to our program's requirements.)

> 1: A "system" NSS install.
> 2: A "local" NSS install for each application (e.g. Firefox).
> And so if a Root has been added to the "system" NSS's certdb, but is
> not present in the "local" NSS's certdb, then it would be regarded as
> an "enterprise" Root?

Basically like that.

> You want to remove NSS's command-line utilities (e.g. certutil) ?!?

I mean we would remove the (Tools -> Options -> Advanced -> Encryption -> Certificates) UI, except for the exception/overrides part, at least on platforms that have a system root database.

> Or is certutil not an "end-user certificate management feature"?
> Or does certutil fall outside your definition of "our products"?

I am not suggesting to change anything about certutil. I am suggesting to change only Gecko.

- Brian

[Kathleen Wilson]

On 10/11/11 11:39 AM, Brian Smith wrote:
> (Anyway, I believe that getting into Microsoft's root program should
> be a prerequisite for getting into ours, at least unless/until we make
> substantial improvements to our program's requirements.)

Please consider this...

Microsoft does not have to face public scrutiny over every action they
take regarding their CAs. That means that Microsoft can state a certain
policy, but then allow as many exceptions to that policy as they want.

[Brian Smith]

Kathleen Wilson wrote:
> Please consider this...
>
> Microsoft does not have to face public scrutiny over every action they
> take regarding their CAs. That means that Microsoft can state a
> certain policy, but then allow as many exceptions to that policy as
> they want.

I am not trying to say that their program is better than ours. In fact, I think the opposite. That is why I am suspicious of any CA that doesn't get into their program.

Do we have a list of CAs that are in our program but not in Microsoft's, and why?

Thanks,
Brian

[Rob Stradling]

Here's a list of the 7 Root Certificates that are currently in Mozilla's
program [1] but not in Microsoft's [2]:


SHA1 Fingerprint=2F:78:3D:25:52:18:A7:4A:65:39:71:B5:2C:A2:9C:45:15:6F:E9:19
subject= /C=ES/O=IZENPE S.A./CN=Izenpe.com
serial=B0B75A16485FBFE1CBF58BD719E67D

This Root has a sha256WithRSAEncryption signature. A sha1WithRSAEncryption
"version" of the same Root _is_ in the Microsoft program.


SHA1 Fingerprint=80:1D:62:D0:7B:44:9D:5C:5C:03:5C:98:EA:61:FA:44:3C:2A:58:FE
subject= /O=Entrust.net/OU=www.entrust.net/CPS_2048 incorp. by ref. (limits
liab.)/OU=(c) 1999 Entrust.net Limited/CN=Entrust.net Certification Authority
(2048)
serial=3863B966

This Root was present in the Microsoft program until ~May 2010. I don't know
why it was removed. Entrust still have other Roots in both the Microsoft and
Mozilla programs.


SHA1 Fingerprint=CC:AB:0E:A0:4C:23:01:D6:69:7B:DD:37:9F:CD:12:EB:24:E3:94:9D
subject= /C=SE/O=AddTrust AB/OU=AddTrust TTP Network/CN=AddTrust Class 1 CA
Root
serial=01

SHA1 Fingerprint=2A:B6:28:48:5E:78:FB:F3:AD:9E:79:10:DD:6B:DF:99:72:2C:96:E5
subject= /C=SE/O=AddTrust AB/OU=AddTrust TTP Network/CN=AddTrust Public CA
Root
serial=01

SHA1 Fingerprint=4D:23:78:EC:91:95:39:B5:00:7F:75:8F:03:3B:21:1E:C5:4D:8B:CF
subject= /C=SE/O=AddTrust AB/OU=AddTrust TTP Network/CN=AddTrust Qualified CA
Root
serial=01

These 3 Roots currently belong to Comodo. We would have liked to have added
them to the Microsoft program, but we came up against Microsoft's policy of a
maximum of 3 Roots per CA.


SHA1 Fingerprint=4A:65:D5:F4:1D:EF:39:B8:B8:90:4A:4A:D3:64:81:33:CF:C7:A1:D1
subject= /C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=Secure
Certificate Services
serial=01

SHA1 Fingerprint=E1:9F:E3:0E:8B:84:60:9E:80:9B:17:0D:72:A8:C5:BA:6E:14:09:BD
subject= /C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=Trusted
Certificate Services
serial=01

These 2 Roots were present in the Microsoft program until ~November 2008 and
~December 2009 respectively. Again, we came up against Microsoft's policy of
a maximum of 3 Roots per CA when we needed to add another Root which we felt
was more useful in that context.


Also, with the next update to the Microsoft's program (which we hope will land
soon), there will be 2 more Root certs that are in Mozilla's program but will
no longer be in the Microsoft program:

SHA1 Fingerprint=66:31:BF:9E:F7:4F:9E:B6:C9:D5:A6:0C:BA:6A:BE:D1:F7:BD:EF:7B
subject= /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO
Certification Authority
serial=4E812D8A8265E00B02EE3E350246E53D

SHA1 Fingerprint=74:F8:A3:C3:EF:E7:B3:90:06:4B:83:90:3C:21:64:60:20:E5:DF:CE
subject= /C=US/O=Network Solutions L.L.C./CN=Network Solutions Certificate
Authority
serial=57CB336FC25C16E6471617E3903168E0

These Roots are being replaced with different "versions" that have different
validity dates, but the same Names and Keys. See [3] for some more
information.

"That is why I am suspicious of any CA that doesn't get into their program"

Hopefully you are no longer suspicious.

Comodo would prefer that you don't make any changes to how you treat the 6
Comodo-owned Roots mentioned above.


[1]
https://mxr.mozilla.org/mozilla/source/security/nss/lib/ckfw/builtins/certdata.txt?raw=1
(v1.79)

[2]
http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab
(last updated September 2011)

[3] http://codereview.chromium.org/8113003


> Thanks,

[Kathleen Wilson]

On 10/11/11 12:31 PM, Brian Smith wrote:
>>> (Anyway, I believe that getting into Microsoft's root program should
>>> be a prerequisite for getting into ours, at least unless/until we make
>>> substantial improvements to our program's requirements.)
>>

First, I would like to say that I think our program should stand on its
own. I think there is something very wrong with our program if people
believe that we need to have a policy to check someone else’s root
program first.

Out of curiosity, I did perform a comparison against Microsoft’s list
that they posted here:
http://social.technet.microsoft.com/wiki/contents/articles/2592.aspx
This list is current through March 2011, so the comparison that Rob
Stradling posted has more current information.

My comparison found the same results as Rob’s, except that I found the
following additional 2 roots that are currently in NSS and not in MS.

1) CN = MD5 Collisions Inc. (http://www.phreedom.org/md5)
O = Equifax Secure Inc.
SHA1: 64:23:13:7E:5C:53:D6:4A:A6:64:85:ED:36:54:F5:AB:05:5A:8B:8A
Valid From: 2004 Jul 30
Valid To: 2004 Sep 01
1024, MD5
All trust bits are turned off for this root.

Is this root needed until we have turned of MD5? Or can we remove it now?

2) OU = Class 4 Public Primary Certification Authority - G2
O = "VeriSign, Inc."
SHA1: 0B:77:BE:BB:CB:7A:A2:47:05:DE:CC:0F:BD:6A:02:FC:7A:BD:9B:52.
Valid From: 1998 May 17
Valid To: 2028 Aug 01
1024, SHA-1
All trust bits are turned on for this root.

This legacy root is to be removed as per the current Root Cleanup bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=682071#c4

Just FYI... Out of curiosity I also counted the number of roots that are
in the MS program and not in NSS, and I found over 160.

If part of your concern is in regards to the SafeScrypt root inclusion
request that is currently under discussion, then you might like to know
that the SafeScript certificates are sub-CAs of the “CCA India 2007”
root certificate that is included in the MS program. CCA submitted bug
#557167 for inclusion of that root in NSS, but due to the size and
complexity of the hierarchy it was determined that each sub-CA should
apply for inclusion separately.

There is another CA, PROCERT, in a similar situation and in our queue
for discussion. PROCERTS’ certificate is a sub-CA of the SUSCERTE root
that is included in MS. In Bug #489240 it was determined that SUSCERTE’s
sub-CAs should apply for inclusion themselves as separate trust anchors.

Kathleen

[Kathleen Wilson]

On 10/12/11 3:15 AM, Rob Stradling wrote:
>
> SHA1 Fingerprint=80:1D:62:D0:7B:44:9D:5C:5C:03:5C:98:EA:61:FA:44:3C:2A:58:FE
> subject= /O=Entrust.net/OU=www.entrust.net/CPS_2048 incorp. by ref. (limits
> liab.)/OU=(c) 1999 Entrust.net Limited/CN=Entrust.net Certification Authority
> (2048)
> serial=3863B966
>
> This Root was present in the Microsoft program until ~May 2010. I don't know
> why it was removed. Entrust still have other Roots in both the Microsoft and
> Mozilla programs.
>

Just to clarify, MS doesn't have this particular root because a newer
root took it's place. The new root has the same Issuer:

CN = Entrust.net Certification Authority (2048)
OU = (c) 1999 Entrust.net Limited
OU = www.entrust.net/CPS_2048 incorp. by ref. (limits liab.)
O = Entrust.net

And same Valid From date: 12/24/99

But a different Valid To date: 07/24/29 instead of 12/24/19.

Entrust is planning to submit the new root for inclusion in NSS too.

Kathleen

[Gervase Markham]

On 08/10/11 01:00, Brian Smith wrote:
> I would like to do this:
>
> 1. Use the system trust database to decide what trust anchors are to
> be used.
>
> 2. If a root is trusted by the system, but not trusted or distrusted
> by Mozilla, then we would consider it to be an "enterprise" root. If
> is in Mozilla's root program AND the system trust store, then
> consider it the same way we do now. This would allow and require
> distinct security indicators for connections that are using
> "enterprise" roots.

Wouldn't that mean that anyone could get into our root program by
getting into Microsoft's and Apple's root programs? Or, to put it
another way, we would be delegating our root program maintenance to
Microsoft and Apple?

In that case, why would anyone want to bother being in our root program?

Gerv

[Brian Smith]

Gervase Markham wrote:
> > 2. If a root is trusted by the system, but not trusted or distrusted
> > by Mozilla, then we would consider it to be an "enterprise" root. If
> > is in Mozilla's root program AND the system trust store, then
> > consider it the same way we do now. This would allow and require
> > distinct security indicators for connections that are using
> > "enterprise" roots.
>
> Wouldn't that mean that anyone could get into our root program by
> getting into Microsoft's and Apple's root programs? Or, to put it
> another way, we would be delegating our root program maintenance to
> Microsoft and Apple?
>
> In that case, why would anyone want to bother being in our root
> program?

This idea depends on there being some compelling UX differences for enterprise vs public CAs, that hasn't been determined.

Additionally, perhaps there is a way to determine, using the OS vendor's APIs, whether the root is built-in or added by the administrator. In that case, we wouldn't have to do extra work. In the absence of such a mechanism, we may have to explicitly distrust all the public CAs that are in the OS's program but not in ours (effectively making our CA inclusion backlog explicit instead of implicit.)

And/or, we could just make this a pref: by default, we would use our root list, but if the pref is set, then we would use the operating system's. The default would be to use our root list.

Also, we should have technical controls in place in Gecko so that we could effectively delegate the root program maintenance to the operating system vendor and/or system administrator without any appreciable decrease in security.

The main point is that we should avoid wasting resources--ours and system administrators'--duplicating the operating system's certificate management/provisioning tools.

Cheers,
Brian

[Walter Goulet]

Hi Brian,

To your point, as I had mentioned earlier in the thread when deploying
PKI infrastructures in controlled enterprise environments it is common
in a Microsoft network to configure the enterprise PKI as a CA within
Active Directory. I believe other PKI solutions such as Redhat's
solution also support publishing enterprise CAs to LDAP directories.
That is, a simple LDAP query is sufficient to get a list of CA
certificates that correspond to enterprise-owned and operated PKIs.
Granted, such CA certificates are also usually added to OS certificate
trust stores, but perhaps this distinction is helpful when considering
how Firefox will treat enterprise owned CAs vs third party roots.

Thanks,
Walter

[Gervase Markham]

On 18/10/11 07:18, Brian Smith wrote:
> This idea depends on there being some compelling UX differences for
> enterprise vs public CAs, that hasn't been determined.
>
> Additionally, perhaps there is a way to determine, using the OS
> vendor's APIs, whether the root is built-in or added by the
> administrator. In that case, we wouldn't have to do extra work. In
> the absence of such a mechanism, we may have to explicitly distrust
> all the public CAs that are in the OS's program but not in ours
> (effectively making our CA inclusion backlog explicit instead of
> implicit.)

Well, not necessarily. Some CAs in the OS program may not have applied
at all to be in our program, and may not want to (for whatever reason).

Microsoft in particular has a very large number of CAs in its program,
and (I believe, in recent releases of Windows) the ability to download
and add more to the root store on demand. Keeping a static list of "no,
not this one... no, not this one" inside NSS to "cancel out" all of the
MS CAs which are MS-installed rather than user-installed seems like a
rather complex task to me.

> And/or, we could just make this a pref: by default, we would use our
> root list, but if the pref is set, then we would use the operating
> system's. The default would be to use our root list.

That makes more sense to me, if the default is still to use ours - but
it actually adds rather than decreases complexity, because now
instructions to e.g. distrust DigiNotar need to start with "check
about:config to see what the value of preference X is. If it's A,
then... If it's B, then..."

> The main point is that we should avoid wasting resources--ours and
> system administrators'--duplicating the operating system's
> certificate management/provisioning tools.

The trouble with this is that if we delegate certificate management and
provisioning to the OS, we also delegate the trust list to the OS. If we
were able to use their tools on our store, then that would be fine :-)

Gerv

[Rob Stradling]

On Thursday 13 Oct 2011 19:51:33 Kathleen Wilson wrote:
<snip>

> Out of curiosity, I did perform a comparison against Microsoft’s list
> that they posted here:
> http://social.technet.microsoft.com/wiki/contents/articles/2592.aspx
> This list is current through March 2011, so the comparison that Rob
> Stradling posted has more current information.
>
> My comparison found the same results as Rob’s, except that I found the
> following additional 2 roots that are currently in NSS and not in MS.
>
> 1) CN = MD5 Collisions Inc. (http://www.phreedom.org/md5)
> O = Equifax Secure Inc.
> SHA1: 64:23:13:7E:5C:53:D6:4A:A6:64:85:ED:36:54:F5:AB:05:5A:8B:8A
> Valid From: 2004 Jul 30
> Valid To: 2004 Sep 01
> 1024, MD5
> All trust bits are turned off for this root.
>
> Is this root needed until we have turned of MD5? Or can we remove it now?

I think this root needs to remain in the NSS trust list until MD5 (when used
for digital signatures) has been "turned off".

> 2) OU = Class 4 Public Primary Certification Authority - G2
> O = "VeriSign, Inc."
> SHA1: 0B:77:BE:BB:CB:7A:A2:47:05:DE:CC:0F:BD:6A:02:FC:7A:BD:9B:52.
> Valid From: 1998 May 17
> Valid To: 2028 Aug 01
> 1024, SHA-1
> All trust bits are turned on for this root.

Actually, this VeriSign Root has been in the MS trust list for at least 4
years, and it's still there.

Perhaps http://social.technet.microsoft.com/wiki/contents/articles/2592.aspx
is a little out-of-sync with the actual trust list files that Windows boxes
download from Microsoft.

<snip>

[Eddy Nigg]

On 10/18/2011 11:51 AM, From Rob Stradling:

> Perhaps
> http://social.technet.microsoft.com/wiki/contents/articles/2592.aspx
> is a little out-of-sync with the actual trust list files that Windows
> boxes download from Microsoft.

It has AffirmTrust, so it can't that bad. Certainly a root that should
be there for 4 years...

--
Regards

Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg