Closed Bug 431621 Opened 16 years ago Closed 16 years ago

Add DigiNotar Root CA root to NSS

Categories

(NSS :: Libraries, enhancement)

Product:
NSS
Component:
Libraries
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
3.11.10

People

(Reporter: hecker, Assigned: KaiE)

References

Details

This bug requests inclusion in the NSS root certificate store of the following root CA certificate, owned by DigiNotar:

1) Friendly name: "DigiNotar Root CA"
   SHA-1 fingerprint:
C0:60:ED:44:CB:D8:81:BD:0E:F8:6C:0B:A2:87:DD:CF:81:67:47:8C
   Trust flags: Web sites, code signing
   URL:
http://www.diginotar.nl/files/Rootcertificaten/DigiNotar%20root%20CA2007.crt

The DigiNotar Root CA root has been assessed in accordance with the Mozilla project guidelines, and the certificate approved for inclusion per bug 369357.

The remaining steps are as follows:

1) A representative of the CA must confirm that all the data in this bug is correct, and that the correct certificate(s) have been attached. They must also specify what OS they would like to use to perform the verification below.

2) A Mozilla representative creates a test build of NSS with the new certificate(s), and attaches nssckbi.dll to this bug. A representative of the CA must download this, drop it into a copy of Firefox and/or Thunderbird on the OS in question and confirm (by adding a comment here) that the certificate(s) have been correctly imported and that websites work correctly.

3) The Mozilla representative checks the certificate(s) into the NSS store, and marks the bug RESOLVED FIXED.

4) At some time after that, various Mozilla products will move to using a version of NSS which contains the certificate(s). This process is mostly under the control of the release drivers for those products.
Blocks: 369357
Blocks: 431772
addbuiltin -n "DigiNotar Root CA" -t C,,C < 431_381_621/diginotar.der >> mozilla/security/nss/lib/ckfw/builtins/certdata.txt

This command was used to produce the patch in bug 431772.

Dear DigiNotar representative, are you able to get the information in this bug reviewed and approved today? This will give you a chance to be included in FF 3.
No longer blocks: 431772
Depends on: 431772
Please find the test binary (mentioned in comment 0 section 2) in bug 431772 comment 2 (attachment 318917 [details])
Hello Kai,

I confirm that the binary is tested and that I validated that the root certificate is a build in object and enabled for SSL and Object Signing.

Regards,

Kick Willemse
Kai,

I have one question. We previously cross signed our Root certificate with Entrust. If I install the latest binary and look at a sub CA cert it keeps showing the Entrust chain.

http://www.diginotar.nl/files/rootcertificaten/public2025.crt (Example of a subca cert)


Can you explain why it is not taking our pure DigiNotar Root instead now that it is included by default? It only takes this chain if I delete all the Entrust CA certs first.


Kai, this root must not be chained to Entrust, specially now that the email bits haven't been approved yet for DigiNotar. I'll follow up on this also on the mailing list.
Kick, For purposes of displaying a cert chain, when NSS finds a cert with
multiple valid issuer certs, it will choose the "newest" one, which is the
one with the newest "notBefore" date, or (if multiple certs exist with the
same notBefore date) the one with the farthest future notAfter date.  
If the intermediate from Entrust is newer than your root, that cert will be
chosen for display.
In reply to comment 6,
Eddy,  You say it "must not be chained", but in fact it is already chained
and has been for quite some time.  That decision was made by Entrust, not
by Mozilla.

Are you asserting that this situation is enough to warrant Mozilla removing
trust from Entrust?

If you ask me, this has implications. Not sure about which yet, but I've started discussion about it on the dev-tech-crypto.

Strictly speaking, the email bit should be removed from the affected Entrust CA root as well until the situation has been cleared. The same applies to EV if the OID chains to Entrust as well. I think it's upon Frank to react here and make a decision (Before everything is locked down for FF3).
Eddy: This has nothing to do with EV; Entrust is not enabled for EV, and neither is DigiNotar. As for resetting trust bits on Entrust, I don't think that is relevant here either. If path processing stops with the DigiNotar root (which I think is the case, and which I think Nelson and/or Kai can confirm), then AFAIK the trust bits consulted are those for the DigiNotar root, not for the Entrust root.
(In reply to comment #10)
> Eddy: This has nothing to do with EV; Entrust is not enabled for EV, and
> neither is DigiNotar. 

I haven't checked that concerning EV, should have done that of course.

> As for resetting trust bits on Entrust, I don't think
> that is relevant here either. If path processing stops with the DigiNotar root
> (which I think is the case, and which I think Nelson and/or Kai can confirm),
> then AFAIK the trust bits consulted are those for the DigiNotar root, not for
> the Entrust root.

I understood that it's chained to the Entrust root for the reasons Nelson explained in comment 7 and apparently Kick's comment 5 confirms that even after adding this root, he sees it still chained to Entrust. The root doesn't stop with DigiNotar's root apparently. However I expect that since email bit is off for DigiNotar's root, than email signing shouldn't work (as with an intermediate CA cert), is that correct?


If Diginotar certs chain to Entrust's root (as Kick seems to say they do,
in comment 5) and Entrust's root has email trust, then those certs will be
found to be valid for email by NSS.
Hence I suggested to remove the email bit from the affected Entrust CA root for now. Franks comment made me unsure a little bit and it could have been either way, so thanks Nelson for confirming it.
(In reply to comment #12)
> If Diginotar certs chain to Entrust's root (as Kick seems to say they do,
> in comment 5) and Entrust's root has email trust, then those certs will be
> found to be valid for email by NSS.

Nelson, I'm a bit confused here: Are you saying that including DigiNotar's root as a trust anchor is basically a no-op, in that given a chain going back to the Entrust root NSS will always select Entrust as the trust anchor?


I have received r+ for the patch to add the root in bug 431772, and I've just commited it. Marking bug fixed.

Please let me know if you think this was wrong.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Frank, Given that 
- Entrust is itself a trusted root, and 
- Entrust has cross-certified Diginotar's root, and 
- Entrust's cross-cert for Diginotar is newer than Diginotar's own root, 
the addition of Diginotar's root to FF3 will have little effect on FF3 for
ordinary (non-EV) SSL server certs, unless a user removes trust from 
Entrust's root (but not from Diginotar's root).

Once Diginotar's root is given EV approval for its own EV policy OID, then
Diginotar's root will have a significant effect on EV SSL server certs 
issued by Diginotar.


By trying to look at this by myself I went to https://www.diginotar.nl/ however FF3 issues following error:

Invalid OCSP signing certificate in OCSP response.

(Error code: sec_error_ocsp_invalid_signing_cert)

Frank: I think there are more problems here! This should have been verified before approval IMO. 
FF2 allowed me to view the page eventually. The affected root is "Entrust.net Secure Server Certification Authority". Please strip the email trust from this root for now.

Kick: there is something wrong with your OCSP responder. Please check and correct.
The AIA extension of the issuing intermediate CA signed by the DigiNotar root has the following value:

OCSP: URI: http://validation.diginotar.nl

The (EV) SSL server certificate issued by the intermediate CA above to www.diginotar.nl has the following AIA value:

OCSP: URI: http://validation.diginotar.nl

This is the same responder URI as the one for the intermediate CA. Most likely this is never going to work.
(In reply to comment #17)
> FF2 allowed me to view the page eventually. The affected root is "Entrust.net
> Secure Server Certification Authority". Please strip the email trust from this
> root for now.

Eddy, I think it would be unwise (to put it mildly) to make a major change like disabling Entrust's email trust bit in a rush. We have no idea at this point what the impact of a change like that would be. And in any case the change is irrelevant to Firefox 3, since AFAIK Firefox would never consult the email trust bit. 
I think we have some opposing views on the subject. Well, it isn't the first time... :-)

CAs are today required by improving standards and best practices to publish CRLs in an ever shorter period, down to 24 hours of renewal period at least. OCSP responders give almost instant results on the status of EE certificates.

CAs have procedures and regulations in place for various scenarios which includes a security breach, key compromise, fraudulent or wrongful issuance of EE certificates and so on. Most of the times these regulations require action within a very limited time period.

And here you come and say that this issue, which is comparable to some sort of compromise, more exactly a breach of the most basic policy requirements of Mozilla, is a major change (like disabling the email trust bit of Entrust, which they most likely never should have enabled in first place) and that you have no idea about the impact of such a change.

Shall I tell you which impact this has on the trust and reliance for the relying parties? Do you know how unwise it is to have CAs not adhering to the Mozilla CA policy? Why are there no policies which require Mozilla to react under such circumstances? Why is this an issue for debate and discussion at all? What about Mozilla's responsibilities? I start to get the feeling that the concepts of how CAs (should) operate, how policies require actions to enforce them are simply misunderstood here.

Some analogy:

Bystander: Sheriff, the bank was robbed.
Sheriff: Mhhh, do you know who it was?
Bystander: It was the Entrust Gang, Sheriff, I'm sure about it.
Banker: They stole most of our assets (Trust, Reliance).
Sheriff: I think it unwise to chase the gangsters, they might have weapons and I could get shot.
Bystander: But Sir, you are the Sheriff, you should enforce the law.
Sheriff: Right, lets see what impact this would have. I could get hurt, I could miss the dinner, I might even....
Bystander and Banker: - Silence
Sheriff: Lets wait a little bit until they can get away far enough so a chase would be useless.
Banker: But what about our assets?
Sheriff: I don't know, but I don't want to rush things....


I thought the Mozilla Foundation acts for the good of all projects. Sure, Firefox doesn't need the email trust bit usually, but Seamonkey relies on NSS, Thunderbird 3 Alpha will be out soon, Thunderbird 2 receives updates with NSS, other software relies on NSS.

(Lets continue the discussion at the mailing list. I cross-posted this comment there as well.)
In reply to comment 17,
The OCSP response signature problem is real, at least for the one diginotar
EV cert I've tested.  Can't tell from a sample size of 1 if this is a problem
for all Diginotar EV certs or just one.  I have added comments about this to
bug 369357. 

In reply to comment 18,
It's quite feasible for a single OCSP responder to provide responses for 
multiple CAs, even including unrelated CAs.  The crucial issue is whether
the signature certificate in the OCSP response is the right one for the 
certificate under test (the cert whose status is reported in the response).
As long as the responder can send a response that was signed by the right
signer, there's no reason it can't serve responses for multiple CAs.

Note that caching OCSP responders can work much like caching http proxies.
Mozilla clients can be configured to use such caching OCSP responders.  

It would also be possible to use an ordinary caching http proxy as a 
caching OCSP responder, except for the fact that presently our OCSP client
uses http PUT requests instead of http GET requests for OCSP requests,
and IIRC, http proxies cannot cache responses to POST requests.
(In reply to comment #21)
> It's quite feasible for a single OCSP responder to provide responses for 
> multiple CAs, even including unrelated CAs.  The crucial issue is whether
> the signature certificate in the OCSP response is the right one for the 
> certificate

Yes, I thought about this one too, but except if they have some magical detection or unique serials throughout their whole PKI, I'm not sure how that is possible.
Target Milestone: --- → 3.12
Target Milestone: 3.12 → 3.11.10
You need to log in before you can comment on or make changes to this bug.