449892 - Enable additional EV roots for FF 3.0.2

Status: VERIFIED FIXED

(Core :: Security: PSM, defect)

Description

[Kai Engert (:KaiE:)]

I'd like to fix bug 446409 and bug 449394 with a single patch.

Comment 1

[Kai Engert (:KaiE:)]

Attachment: Patch v1

Not yet tested, because still waiting for test sites.
Therefore, I'll wait until we have test sites and a positive test result, or a statement that no testing is desired.

Comment 2

[Kai Engert (:KaiE:)]

Comment on attachment 333030 [details] [diff] [review]
Patch v1

I'm asking for review on this patch, which enables 3 new roots for EV.

I have been able to test both GlobalSign roots.

I was unable to test the WellsSecure root yet, because of a technical problem. We don't have confirmation yet whether it's a problem on the CA's OCSP server (which is my understanding) or in NSS.

I think it would make sense to skip enabling the WellsSecure root until we have a positive test.

If you agree, I'd like to propose:

- please r+ the patch if you think it is technically correct

- should we be unable to test WellsSecure before the code freeze, I'll NOT check in portion that enables it, but limit my check in to the 2 GlobalSign roots.

Comment 3

[Robert Relyea]

Comment on attachment 333030 [details] [diff] [review]
Patch v1

It would be good if a representative from wells is CC'ed on the bug.

If the problem is a missing intermediate on the OCSP responder, loading that intermediate into your database (without setting any trust) should be sufficient to allow the test to complete.

bob

Comment 4

[Kai Engert (:KaiE:)]

(In reply to comment #3)
> It would be good if a representative from wells is CC'ed on the bug.

WellsSecure is already aware of the problem, I've talked to them by email and via bug 449394.


> If the problem is a missing intermediate on the OCSP responder, loading that
> intermediate into your database (without setting any trust) should be
> sufficient to allow the test to complete.

FYI, see bug 449394. There are additional problems.

Comment 5

[Kai Engert (:KaiE:)]

I want to make use of the option I had announced in comment 2.

I'll attach a patch that enables the GlobalSign roots, only.
We should do WellsSecure at a later time, after the issue has been resolved.

Comment 6

[Kai Engert (:KaiE:)]

Attachment: Patch v1 with WellsSecure removed

This is the patch with GlobalSign, only. As Bob were aware of the possibility to remove Wells, his r+ still applies. Carrying forward his review.

Comment 7

[Kai Engert (:KaiE:)]

Comment on attachment 334487 [details] [diff] [review]
Patch v1 with WellsSecure removed

Requesting approval for Firefox 3.0.x

Comment 8

[Robert Relyea]

re comment 6. I verify I'm OK with dropping Wells if their responder issue is not fixed.

bob

Comment 9

[Samuel Sidler (old account; do not CC)]

Comment on attachment 334487 [details] [diff] [review]
Patch v1 with WellsSecure removed

Approved for 1.9.0.2. Please land in CVS. a=ss

Comment 10

[Kai Engert (:KaiE:)]

marking fixed on trunk and 1.9.0.2

removing dependency for wells

Comment 11

[Al Billings [:abillings - ex-MoCo]]

We need to get this verified for 1.9.0.2. Kai, can you confirm with the build 4 of 1.9.0.2?

Comment 12

[Kai Engert (:KaiE:)]

(In reply to comment #11)
> We need to get this verified for 1.9.0.2. Kai, can you confirm with the build 4
> of 1.9.0.2?

You could verify yourself if you want.
Go to https://ev.globalsign.com/

If you see the green identity UI, it's verified.

(no such UI with earlier FF versions for globalsign)

Comment 13

[Al Billings [:abillings - ex-MoCo]]

Verified with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.2) Gecko/2008090212 Firefox/3.0.2.