586414 - Verify GlobalSign's continued conformance to EV guidelines

Status: RESOLVED FIXED

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

Description

[Kai Engert (:KaiE:)]

In bug 507360 comment 23 Dan Veditz said:
  > * SSL: GlobalSign verifies domain ownership/control as specified in the CPS
  > in sections 1.8 (OrganizationSSL), 1.9 (DomainSSL), 1.10 (ExtendedSSL), 
  > and 3.3.2 (Documents used for subscriber registration).
  
  Section 1.10.5(2) says they will ensure "Applicant's exclusive control of the
  domain name and applicable Subject Alternative Name domains to be included in
  certificate".

  How did they verify that for 192.168.100.1 in the cert they issued to
  https://mail.designboard.com/ ? I'm pretty sure I've got control of the
  192.168.100.1 I can see from here, which makes the Applicant's control sound
  less than "exclusive".


It has been proposed
http://groups.google.com/group/mozilla.dev.security.policy/msg/95b21903d07764ca
to file a bug report, allowing to track this incident, so I've filed this one.

In bug 582575 comment 8 (which is related to bug 582375 and bug 582381) it has been proposed to postpone adding further trust for GlobalSign until this incident has been clarified.


An initial response is found at
http://groups.google.com/group/mozilla.dev.security.policy/msg/024948169797cd65


This bug proposes to make a decision going forward related to GlobalSign roots.

I believe we at least would like to see that the incorrect root(s) get revoked as soon as possible.

What actions would we like to see?
I guess we'd like to see answers to the questions that Dan asked here:
http://groups.google.com/group/mozilla.dev.security.policy/msg/482c0e1b4c508c23

Comment 1

[Eddy Nigg (StartCom)]

I assume you meant that the incorrectly issued end-user certificates get revoked, not the roots.

Comment 2

[Kai Engert (:KaiE:)]

(In reply to comment #1)
> I assume you meant that the incorrectly issued end-user certificates get
> revoked, not the roots.

Yes, indeed!
Sorry for my mistake in writing.

Comment 3

[Kathleen Wilson]

According to m.d.s.policy, GlobalSign has already updated their issuance process in regards to this: "Incidentally GlobalSign itself updated its systems and policies to disallow RFC1918 IP's in April last year."

The remaining action item is for GlobalSign to identify and re-issue all of the certs with this problem that chain up to their roots currently in NSS (and their new SHA256 root).

Johan, Please provide an estimate of when this will be done.

Comment 4

[Johan Sys]

My apologies for the delay in answering : we were investigating the root cause of this.

Around the issuance of RFC1918 IP address within EV: based on the  policy authority meeting notes from that time the
interpretation from our side was that RFC1918 addresses are registered as
private in ICANN and exclusive to the customer.  After discussion (incl clarification on the CA/B forum) we promptly updated our internal policy.

Customer were contacted and issued certs were replaced.  We did this based on a scan of our certificate base.  Between the time of this scan, and the internal enforcement of the policy and systems (about two weeks) new orders unfortunately did come in the vetting queue: one RFC1918 cert and three others with internal domains/hostnames. We are working as a priority with the affected customers in revoking and replacing these certs : I will report back when this is completed.  We have updated our procedures and will report this to our auditors.

Hope this clarifies the situation.  We do appreciate it has been brought to our attention.  

Johan

Comment 5

[Johan Sys]

As per my comment 4 I can confirm that the affected certs are revoked and replaced.

Johan

Comment 6

[Kathleen Wilson]

My opinion is that GlobalSign has taken appropriate action to resolve this issue in a timely manner.

I propose closing this bug as resolved, fixed.

Comment 7

[Kai Engert (:KaiE:)]

Let me state one more thought, and I'll begin repeating the history:

(a) GlobalSign issued the incorrect certificate
(b) GlobalSign learned that a different policy is necessary
(c) GlobalSign implemented a new policy and stopped issuing such certificates

In my opinion, after (c) was completed, GlobalSign should have scanned their entire base of still valid certificates and and should have identified the incorrect certificate on their own.

It shouldn't have taken more than one year to discover it.

In my very personal opinion, the promise that comes with EV certificates implies the obligation that CAs shall be proactive and verify certificates after misunderstanding or potential mistakes become known (like in (a)).

I propose to ensure that the EV guidelines contain such a requirement for being proactive after mistakes, related to still valid certificates.

I agree with resolving this bug as resolved fixed, if GlobalSign intends to be proactive in the future after scenarios similar to (a).

Comment 8

[Kai Engert (:KaiE:)]

(In reply to comment #7)
> after misunderstanding or potential mistakes become known (like in (a)).

...

> proactive in the future after scenarios similar to (a).

In both sentences I meant (b)

Comment 9

[Eddy Nigg (StartCom)]

As a matter of fact, CAs that issue EV certificates must self-audit at least 3% of their issued certificates in a regular basis. What you expect to have happened is covered under the section 11.2 EV Certificate Revocation of the EV Guidelines including:

(7) A determination, in the CA's sole discretion, that the EV Certificate was not issued in accordance with the terms and conditions of these Guidelines or the CA’s EV Policies;

Comment 10

[Kai Engert (:KaiE:)]

Thanks Eddy. Section 14.1.2 talks about "regular self audits of 3% of the certs", but I can't find how this relates to calendar time, i.e. I don't see a requirement like "3% per month".

It seems possible that a few incorrect certificates might go undetected with this rule of self-auditing limited to a small sample.

Also, in section 11.2 the guidelines point out that revocation is mandatory after an revocation reason becomes known, but in this scenario, nobody had apparently detected this incorrect certificate.

In the EV guidelines version 1.2 I couldn't find a requirement (as explained in comment 7/8) that requires to self-audit all still valid certificates, whenever the policy of CA systems gets changed, and it's obvious that older issued certificates haven't been checked against the newer rules.

Should the guidelines explicitly state such a stronger requirement?

Comment 11

[Eddy Nigg (StartCom)]

This would be perhaps a good idea and I would be supportive if Mozilla would present such a motion to the CAB Forum. As for my taste (and I believe WebTrust criteria), a scan of all occurrences of a specific deficiency once it's known to the CA is the expected control the CA should have in place.

Comment 12

[Daniel Veditz [:dveditz]]

The last couple of comments sound good but belong in the security-policy list rather than this bug specific to GlobalSign. I think I have to agree with Kathleen in comment 6 that GlobalSign has dealt with the known issue (for EV certs) appropriately.