Closed Bug 525250 Opened 15 years ago Closed 15 years ago

DOD Root CA 2 is untrusted

Categories

(CA Program :: CA Certificate Root Program, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: bugzilla-graveyard, Assigned: kathleen.a.wilson)

References

Details

See bug 525223. I'm filing this so that the appropriate authorities within NSS can look into it. It's not clear to me whether the DoD needs to sign their certificates differently (thus making that truly a TE bug) or if NSS should trust the certificate they're using as a root certificate (making it a CA Certificates bug, I guess).
CCing Nelson and Robert for additional help here.
Root CA certificates are added to NSS only when Mozilla Foundation (or 
Corporation, not sure which) has determined that they meet the criteria 
set forth in Mozilla's root CA certificate policy, as shown in 
http://www.mozilla.org/projects/security/certs/policy/

The policy makes it clear that an official representative of the CA itself 
must participate in the process.  In the past, IIRC, it was required that 
the request to include the CA's cert(s) originate with an official CA 
representative, and not with some third party, although I don't see that in 
the policy statement now, and I think that if the CA agrees to participate 
in the process and help get their cert(s) included, then perhaps it does not 
matter who originated the request.  I'll let Mozilla resolve that question.  

If some official representative of the DOD CAs wants to see those CAs 
included, then he or she should read and understand the policy at the URL 
cited above, then visit and read the following pages:
https://wiki.mozilla.org/CA:How_to_apply
https://wiki.mozilla.org/CA:Information_checklist
https://wiki.mozilla.org/CA:Recommended_Practices
https://wiki.mozilla.org/CA:Problematic_Practices
and perhaps some of the other pages to which links are given on this page
https://wiki.mozilla.org/CA:Overview
Chris, If you are able to, please contact someone at the DoD who can request root inclusion as per 
https://wiki.mozilla.org/CA:How_to_apply

I submitted a request for the DoD to do so through their website, but it may not be effective.

I cannot proceed with this inclusion request until there is an official representative of the DoD involved, so that all of the necessary information can be properly evaluated.
Bob, do we have any contacts at all within the DoD who we might be able to get to help with this process?
Having a self-signed OCSP responder cert is a major "problematic practice".
That's the finding of bug 525223.  IMO, it's a major obstacle to that root
CA cert being usable to all but a tiny fraction of Mozilla browser users.
chofmann: ping?
if we are looking for contacts still bob lord can probably help.
Is this bug about trusting the DoD Root CA 2?  If so, I have not heard any requests from the DoD to add the root. Like other large enterprises, they have their own system for managing root trusts inside their intranet. 

If you would like me to ask them if they want to be added, I'd be happy to do that, but I suspect they will not want to bother meeting the requirements of inclusion.
(In reply to comment #8)
> If you would like me to ask them if they want to be added, I'd be happy to do

Please, if you don't mind.
Well, they're clearly going to have to deal with the OCSP responder issues 
documented in bug 525223 before it will do any good to trust their root.
Let me be crystal clear about comment 10.
Adding the DoD Root CA 2 to Mozilla's trusted root CA list won't help a 
bit while the OCSP responder for all the intermediate CAs issued by that 
root continue to use the services of an OCSP responder that uses a self-
signed server certificate.  Details in bug 525223.
No longer blocks: 525223
Depends on: 525223
(In reply to comment #9)
> > If you would like me to ask them if they want to be added, I'd be happy to do
> 
> Please, if you don't mind.

I'd really rather we not.

Our root program is smaller than other browsers, but it's still big, with a healthy queue of applicants. I think the last thing we need to do is start asking other CAs to join it, most especially US DoD which has had, I'm quite sure, at least 3 or 4 requests historically where they've shown no real desire to be included, going at least as far back as bug 208323.

If there's a problem with an individual site that ought to be publicly consumable, but where asking users to install the DoD root is not practical, I suggest taking it up with them.

To quote the inimitable Frank Hecker, module owner of the CA root program, in bug 208323 comment 5:

> The last time I dealt with the issue
> of
> the DoD PKI it was essentially a DoD-internal PKI for the use of U.S. military
> personnel (active or retired), DoD civilian employees, DoD contractors, and
> (maybe) allied forces (e.g., NATO). It was *not* intended for the use of the
> general public (whether U.S. citizens or not), and I'm not aware that members
> of
> the general public would ever be in a situation where they would encounter
> SSL-enabled web servers, S/MIME email, or signed code that used DoD-issued
> certificates.
> 
> Based on that I would consider this an "intranet" CA (albeit for a very large
> intranet) and based on my previous "meta-policy" comments I would recommend
> *not* including this in Mozilla et.al. I'll leave this bug open for a period of
> public comments, and then I'll close it with "WONTFIX" unless someone can
> provide compelling reasons why I should do otherwise.
(In reply to comment #12)

> To quote the inimitable Frank Hecker, module owner of the CA root program, in
> bug 208323 comment 5:

To be fair, that was five years ago, and things might have changed since then. I certainly got the impression from the TE bug filed against Firefox (bug 525223) that civilian contractors have need of this. As far as I'm concerned, that's pretty much "the general public", because there are literally millions of people who work at civilian contractors and might have need to access this site.

That said, as Nelson points out here, and as is pointed out in comments 12 and 13 on bug 208323, the DoD is doing seemingly everything in their power to make this as difficult and complicated as possible as-is. If the process of making their root certificate work was vastly simplified, I'd be OK with a WONTFIX here, assuming the end result of this bug and the TE bug to end-users of Gecko was a workable user experience. Right now, it's not "usable" in any sense of the term, even for reasonably technical people.

cl
I asked and they do not with to apply to the program at this time.  That could change at any time, of course, but it means we can probably close this bug for now.

This does mean that contractors (and people like me) have to load the root manually from a trusted source, but since it's their policy that's what we'll go with for now.
INCOMPLETE for now, but if the DoD changes their mind, we can reopen.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → INCOMPLETE
Thanks, Bob. Gonna resolve this WONTFIX and start dup'ng new requests here instead of the older ones, since this is a more up to date statement from DoD on the subject.

I'll leave the TE bug alone - getting the DoD to change their more public-facing sites to use public certs is something that could be done independent of adding their root in this bug. But if you were to ask me, I'd say that's really more a matter for email to DoD webmasters than it is for Firefox TE bugs. That is, it doesn't seem likely that a TE bug here will be effective.

I'm not trying to be fatalistic or even pessimistic, I just think that this isn't a place where Mozilla is likely to have more sway than the site's users.
Resolution: INCOMPLETE → WONTFIX
(Sorry Chris, we collided. But I think WONTFIX is more appropriate - the bug report was complete, and made a valid request, but on consideration we've decided not to make the requested change. That's a WONTFIX.  As you say, if the DoD ever changed their mind, we could always file a new bug, or re-open this one.)
Product: mozilla.org → NSS
Product: NSS → CA Program
You need to log in before you can comment on or make changes to this bug.