Closed Bug 405906 Opened 17 years ago Closed 16 years ago

Remove EV blessing for Verisign's legacy root before final release

Categories

(Core :: Security: PSM, defect, P2)

defect

Tracking

()

RESOLVED FIXED

People

(Reporter: KaiE, Assigned: KaiE)

References

Details

Attachments

(1 file)

Bug 404592 added Verisign's EV OID for EV testing.

Inclusion for final release has not been approved yet.
So, this bug is a reminder to check things before a final release.

If bug 402947 doesn't get addressed/approved in time, this bug requests we undo the patch from bug 404592.
Flags: blocking1.9?
Summary: Potentially Verisign's EV OID before final release → Potentially remove Verisign's EV OID before final release
Note to drivers: Kai's nominated this blocking, and I really think it needs to - it's probably a no-op, since bug 402947 is already in the pipeline, but we absolutely should NOT ship with VeriSign in our root store if it hasn't been approved; and in the case where that happens, this is a safe change.
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
What's the status here?
Has the following root been approved for the OID shown in the following snippet that we had checked in with bug 404592?

  {
    "2.16.840.1.113733.1.7.23.6",
    "Verisign EV OID",
    SEC_OID_UNKNOWN,
    "OU=Class 3 Public Primary Certification Authority,O=\"VeriSign, Inc.\",C=US",
    "OU=Class 3 Public Primary Certification Authority,O=\"VeriSign, Inc.\",C=US",
    "74:2C:31:92:E6:07:E4:24:EB:45:49:54:2B:E1:BB:C5:3E:61:74:E2"
  },

Thanks in advance for an update.
Blocking for resolution.
Flags: tracking1.9+ → blocking1.9+
Well, now that the GoDaddy EV cert has been approved and checked in, do we really need the Verisign one for testing anymore anyway?
(In reply to comment #4)
> Well, now that the GoDaddy EV cert has been approved and checked in, do we
> really need the Verisign one for testing anymore anyway?

We don't need it for testing in the same way we originally did, but I don't think it makes a lot of sense to pull the root back out, given that in bug 402947 comment 17, Frank's preliminary disposition is to approve the cert, pending public review.  If that review turns up irreconcilable problems, then we definitely revisit this, but if that approval goes ahead, we can resolve this one WONTFIX.
Progress on this?
(In reply to comment #6)
> Progress on this?

Bug 402947 comment 19 has approved Verisign's "VeriSign Class 3 Public Primary CA - G5" cert for EV issuing.  Bug 422921 tracks the request to mark that cert as EV capable, at which point this entry will no longer be needed, and should be removed.

However, since what we're talking about now is code cleanliness rather than shipping a trusted EV cert that the Foundation has not approved, my opinion is that this no longer blocks release.  Obviously though, we should fix it as part of bug 422921, and I will comment there to that effect.

Re-nom'ng so that drivers can decide if they agree this no longer blocks.
Flags: blocking1.9+ → blocking1.9?
Depends on: 422921
Yep.  Sounds good.  Removing from the blocker list.  Thanks Jonath.
Flags: blocking1.9? → blocking1.9-
Depends on: 425518
I think it was wrong to remove the approval.

While the new stuff got approved, it's unclear when we will be able to add the new stuff in time, because we're very late.

But the incorrect blessing must be removed.
I propose to do things in order.
Flags: blocking1.9- → blocking1.9?
Attachment #313216 - Flags: review?(rrelyea)
Comment on attachment 313216 [details] [diff] [review]
Patch to remove the unapproved test blessing

r+ rrelyea
Attachment #313216 - Flags: review?(rrelyea) → review+
Comment on attachment 313216 [details] [diff] [review]
Patch to remove the unapproved test blessing

Requesting approval.

This bug had blocking status until 2 days ago. It was only meant as a thought for simplication, but let's do things in steps.
Attachment #313216 - Flags: approval1.9?
Summary: Potentially remove Verisign's EV OID before final release → Remove EV blessing for Verisign's legacy root before final release
-'ing this as originally intended, but approving the patch.
Flags: blocking1.9? → blocking1.9-
Comment on attachment 313216 [details] [diff] [review]
Patch to remove the unapproved test blessing

a1.9+=damons
Attachment #313216 - Flags: approval1.9? → approval1.9+
(In reply to comment #13)
> -'ing this as originally intended, but approving the patch.

Well, this definitely blocks Firefox 3's release, as we shouldn't be including this unapproved OID.
(In reply to comment #15)
> (In reply to comment #13)
> > -'ing this as originally intended, but approving the patch.
> 
> Well, this definitely blocks Firefox 3's release, as we shouldn't be including
> this unapproved OID.

I don't think we should remove this, and create the predictable ensuing rash of "EV is broken" feedback if Frank is going to say (as he has suggested in email copying kai, nelson, myself and others) that his EV review of Verisign should be read to include this OID as well.

Clearly, we should not ship a browser with trust that we have not verified, it's good that we have this bug, this review, and this approval.  That means we can pull the trigger as late as we want.  Pulling it early will create feedback cycles that I don't personally think will help us ship a better browser, or give our root store any more integrity.  Indeed, I think it could be harmful to those things.

I think a better approach is to get Verisign to be clear about whether or not this root is needed, since it is a code cleanliness issue to not have unnecessary EV blessings; Frank has sent an email to Verisign asking for quick answers to that question (among others).  I think that if the legacy root is needed for EV, we should get Frank to confirm whether or not his EV review includes the legacy root.  If the legacy root's EV status isn't needed, we can pull it with this patch as part of including the new root.

I think the end result will be the same here - no roots that haven't been cleared - but the interim will involve significantly less churn and spent cycles trying to explain why things that used to work and are intended to work in the final release have deliberately regressed.
The patch listed in this bug has been checked in as part of the larger landing in bug 425518.

I don't mean to make a final decision, but I think it's a good thing to do.

The patch in bug 425518 enabled the new G5 root at the same time as removing EV blessing for the legacy root, which we had added for testing purposes.

Because we are still without confirmation whether or not it's necessary to have the legacy roots enabled for EV, I think it's good that we'll have tomorrow's build.

Tomorrow's build will enable people to test whether verisign sites are still reported with EV. According to the major sites I have tested, the answer is yes. But naturally my test is incomplete, because I don't overlook the universe of certs issued by verisign.

After we have test results based on tomorrow's build we can reconsider.

I'm keeping this bug open, pending final decisions.
Please keep the "EV Blessing" for legacy Thawte, VeriSign and GeoTrust roots. I don't have a url handy to provide you with an EV site that chains up to the legacy root, but I know we have issued such certs in the Japanese market. They required a chain without 2048-bit keys, because many mobile devices in their market cannot handle 2048. They are well aware of the upcoming 2010 restriction, but for now we do issue such certs
(In reply to comment #18)
> Please keep the "EV Blessing" for legacy Thawte, VeriSign and GeoTrust roots. I
> don't have a url handy to provide you with an EV site that chains up to the
> legacy root, but I know we have issued such certs in the Japanese market. They
> required a chain without 2048-bit keys, because many mobile devices in their
> market cannot handle 2048. They are well aware of the upcoming 2010
> restriction, but for now we do issue such certs

Frank,

Given this response from Rick, can you please comment as to whether your existing EV approval extends to this legacy root as well, so that we know whether this root can be re-tagged as EV?
(In reply to comment #19)
> Frank,
> 
> Given this response from Rick, can you please comment as to whether your
> existing EV approval extends to this legacy root as well, so that we know
> whether this root can be re-tagged as EV?

I'm OK with leaving the EV OID on the VeriSign Public Primary Certification Authority (PCA-G1) root. Based on my reading of the audit docs and CPS(s), VeriSign compliance with the EV guidelines is not restricted to the PCA-G5 root but applies to the VeriSign CA hierarchy as a whole.


(In reply to comment #20)
> I'm OK with leaving the EV OID on the VeriSign Public Primary Certification
> Authority (PCA-G1) root.

Sorry, to be clear: My statement applies to the VeriSign *Class 3* Public Primary Certification Authority (PCA3-G1) root, which is the root at issue here.
I believe this bug is a non-issue now.  The current state of things is that verisign-issued certs behave as EV through the blessing on the new root, and have been approved by Frank for that purpose.  If we need to make adjustments in terms of which roots are EV-activated in the future, I think those can be follow-up bugs, but I don't think we intend to do any more work here.

Kai - if you disagree or if I have misunderstood, please feel free to re-open - it's your bug after all.  But I don't think this bug should be showing up on queries for "bugs with approved patches that haven't landed yet" - as though there was work still to be done here. 
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
It's correct to close it, because we have technically removed the blessing for the legacy root, a while ago, as part of bug 425518.

After we did, Verisign had confirmed "things are looking good", so we have not added the legacy root back.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: