Closed Bug 751960 Opened 13 years ago Closed 12 years ago

Enable StartCom's SHA256 and G2 root certificates for EV in PSM

Categories

(Core :: Security: PSM, enhancement)

Product:
Core
Component:
Security: PSM
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: kathleen.a.wilson, Assigned: mayhemer)

References

Details

Per bug #602750 the request from StartCom has been approved to enable its SHA256 version of the “StartCom Certification Authority” root certificate for EV use. Please make the corresponding changes to PSM. The relevant information is as follows. Friendly name: StartCom Certification Authority SHA1 Fingerprint: A3:F1:33:3F:E2:42:BF:CF:C5:D1:4E:8F:39:42:98:40:68:10:D1:A0 Test URL: https://www.startssl.com/ EV Policy OID: 1.3.6.1.4.1.23223.1.1.1 Currently PSM has an old EV Policy OID, 1.3.6.1.4.1.23223.2, that StartCom doesn’t need after this new OID is added. StartCom would like all of it’s roots changed to only the 1.3.6.1.4.1.23223.1.1.1 EV OID in PSM.
Eddy, Please confirm that the above information is correct.
Fingerprint and new EV OID are the correct ones.
Depends on: 751954
Per bug #640368 the request from StartCom has been approved to enable its “StartCom Certification Authority G2” root certificate for EV use. Please also make the corresponding changes to PSM for the G2 root. Friendly name: StartCom Certification Authority G2 SHA1 Fingerprint: 31:F1:FD:68:22:63:20:EE:C6:3B:3F:9D:EA:4A:3E:53:7C:7C:39:17 Test URL: https://g2.startcom.org/ EV Policy OID: 1.3.6.1.4.1.23223.1.1.1 Note: To test this, I deleted all of the other StartCom certs from the Authorities list in the Certificate Manager. Then I was able to browse to this website and see the correct cert chain.
Summary: Enable StartCom's SHA256 root certificate for EV in PSM → Enable StartCom's SHA256 and G2 root certificates for EV in PSM
Eddy, Please confirm that the information in Comment #3 is also correct.
Blocks: 640368
Yes, correct.
> Currently PSM has an old EV Policy OID, 1.3.6.1.4.1.23223.2, that StartCom > doesn’t need after this new OID is added. StartCom would like all of it’s > roots changed to only the 1.3.6.1.4.1.23223.1.1.1 EV OID in PSM. OOPS.
In the past, when we worked on EV implementation in Mozilla, the following statement was made: "Any certificate MUST contain AT MOST one (EV) policy OID." The code in Mozilla is tailored to this requirement. Today's code will never try multiple EV OIDs. Mozilla/PSM will search for exactly one of the OIDs listed in PSM's whitelist. Then it will check if this OID can be verified for EV. If it doesn't verify, we give up. Because of the above, I had hope that we would never, ever have to deal with such certificates. But now I see that certificates on www.startssl.com indeed use multiple OIDs that are all supposed to mean EV. This is a surprise and news to me. We must carefully research what happens. I had hoped that we could avoid this complexity.
Kay, you can simply remove the old EV OID and add the new one. It works as expected (it did so far and will also in the future). Also as far as I know, there is no limitation for an EV cert not to have more than one EV OID - but we are transitioning to the new one now in any case (which is in use already since 2009). There are no valid EV certs that don't have both OIDs.
I'm OK to address your request as part of this bug, which is, remove the EV-activated combination of "old root and old OID", and replace with an EV-activated combination of "old root and new OID", with the effect that all use of the old OID is eliminated from the Mozilla code, and stop worrying what might happen. (I understand that's what Kathleen has suggested in the initial comment of this bug, and that you have confirmed in comment 1). I'm OK to stop worrying about it.
Blocks: 757240
(In reply to Eddy Nigg (StartCom) from bug 751954 comment #9) > in that case we'll need both OIDs for > the older root at least for the time-being? Having both OIDs won't solve this problem for multiple reasons. The most obvious is that you cannot update the old stable branch to include your new OID. NSS contains *ONLY* the root and the "general trust". Firefox/PSM contains *ONLY the EV-activation ON TOP of the general trust. If you combine old Firefox (only knows about EV-activation for old root), with a newer NSS that only has the newer root, then you won't get EV, because the root identified by NSS cannot be found in the EV whitelist. If you want to get EV in an old environment, where the Firefox/PSM application only knows about the older root, then we must ensure that the newer root is still contained in the newer NSS. And having both the old root and new root with overlapping details might give you a random selection of either one (I don't understand the NSS internals enough to predict what exactly will happen). Because a newer Firefox, a Firefox that still uses the classic NSS verification engine (not libpkix), might select either of two similar root certificates, and you want EV for both selections, then both roots must be enabled for EV. But we could change the newer Firefox to use the new OID for EV-activiation for all 3 Startcom certificates. This is the only way things *might* work - but I cannot make promises.
Alright, whatever works - you are the specialist. I'm just confirming that both OIDs are currently in use and will for a while for all EV certs that are valid at this moment. So whatever the solution for old and/or new EV OID, old and/or new root(s), both OIDs are there.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Whiteboard: In FF16
I think that even though the test websites show the EV treatment in FF16, this bug has not actually been fixed. The reason I think so, is because I was just looking at the code and did not see the changes as specified above. http://mxr.mozilla.org/mozilla-beta/source/security/manager/ssl/src/nsIdentityChecking.cpp This bug is to enable two root certs for EV, and to change the EV Policy OID of the already-EV-enabled root cert. Friendly name: StartCom Certification Authority SHA1 Fingerprint: A3:F1:33:3F:E2:42:BF:CF:C5:D1:4E:8F:39:42:98:40:68:10:D1:A0 Test URL: https://www.startssl.com/ EV Policy OID: 1.3.6.1.4.1.23223.1.1.1 Friendly name: StartCom Certification Authority G2 SHA1 Fingerprint: 31:F1:FD:68:22:63:20:EE:C6:3B:3F:9D:EA:4A:3E:53:7C:7C:39:17 Test URL: https://g2.startcom.org/ EV Policy OID: 1.3.6.1.4.1.23223.1.1.1
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee: nobody → honzab.moz
Whiteboard: In FF16
We failed to follow up on this bug after the confirmation, sorry. The patch is ready in bug 752106 and needs a code review.
I meant in bug 757240
What is status of this bug?
Looks like the work was done in bug 757240, and this one can be marked fixed? (also 752106)
I see the changes in mozilla-aurora, mozilla-beta, and mozilla-central http://mxr.mozilla.org/mozilla-beta/source/security/manager/ssl/src/nsIdentityChecking.cpp So I think this bug can be marked as fixed.
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.