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