Closed Bug 1524877 Opened 6 years ago Closed 6 years ago

GlobalSign: IP in dnsName

Categories

(CA Program :: CA Certificate Compliance, task)

Product:
CA Program
Component:
CA Certificate Compliance
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: jonathan, Assigned: douglas.beattie)

Details

(Whiteboard: [ca-compliance] [ov-misissuance])

Linus: Could you provide an update and Incident Report (per https://wiki.mozilla.org/CA/Responding_To_An_Incident ) about why GlobalSign failed to meet the Baseline Requirements revocation window?

Assignee: wthayer → linus.hallberg
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Flags: needinfo?(linus.hallberg)
QA Contact: kwilson → wthayer
Whiteboard: [ca-compliance]

This is the file Peter Bowen created a few times to let all the CAs know about issues that lead up to the identification of GlobalSign certificates with IP addresses in dnsName:
https://docs.google.com/spreadsheets/d/1lJt-1tkgKcbw5woEr4-tcpqB-M-HKwjFNSdX2jla2EU/edit#gid=1516961828

At the time this list of non-compliant certificates was reported, there was continued discussion about this IP address topic and how browsers handled (or not) IP addresses in the SAN. Some need IP address in dnsName, others need in the ipAddress:
https://groups.google.com/d/msg/mozilla.dev.security.policy/Av6oZxbjvB4/QxveVM45BwAJ

During this period, the incident reporting process and rules for what constituted an "incident" weren't as formal nor as high visibility. The report Peter posted had over 45,000 entries from essentially every CA, and I don't recall there being hundreds of incidents. Certainty today there would be no question about how to handle an issue like this. In late 2015 and early 2016 the process wasn't as clear.

As you noticed, we updated our systems in July 2016 to address this to stop issuing new certificates with IP addresses in the dnsName field. We'll initiate revocation shortly on the list of still-active certificates.

Assignee: linus.hallberg → douglas.beattie

All of the identified certificates have been revoked.

Doug: thank you for the information.

As you point out, these certificates were originally brought to GlobalSign's attention at a time when incident reporting and revocation expectations were much different than they are today. My main concern in this bug is that GlobalSign apparently failed to respond to the problem report within 24 hours as required by BR section 4.9.5. If that is the case, please explain why that happened and how it will be prevented in the future.

Also, can you explain why GlobalSign apparently decided not to revoke these certificates until the issue was publicly reported via this bug? I suspect this is related to your answer in comment #2, but just want to understand the thinking around the BR section 4.9.1.1 requirements when an issue is reported a second time.

Flags: needinfo?(linus.hallberg) → needinfo?(douglas.beattie)

On January 29th,17:47 GMT: We received the report

On January 29th, 19:22, we closed this report as a duplicate because, as listed above, this topic was already reviewed and closed. What the support team didn't pull out as a new action was the comment about these certificates not being revoked. We had addressed the situation at the time under different terms and assumptions than we do today, and that distinction wasn't apparent to the team that processed this request.

We're currently reviewing the "report-abuse" process looking for ways to add proper rigger to future cases. At a minimum, we'll be bringing in applicable compliance experts on future emails to "report-abuse" to avoid this in the future.

Flags: needinfo?(douglas.beattie)

Even if a problem report is reporting a duplicate problem, doesn't BR 4.9.5 require the CA to respond to the reporter within 24 hours? According to the description, GlobalSign never responded to the reporter.

Flags: needinfo?(douglas.beattie)

Yes, and we're updating the process to be sure that there is a response. Normally there is, but due to this being handled like a duplicate that was inadvertently omitted. While we took action within a couple of hours, the proper interpretation of the issue and the response weren't up to our standards and this driving the need to review/update the process.

Flags: needinfo?(douglas.beattie)

Doug: please update this bug with the results of GlobalSign's review of the "report-abuse" process.

We’ve reviewed and updated our process to handle incoming emails to the report-abuse address.

We’re integrating 2 existing organizations into the processing of these reports:

  • The GlobalSign Security Operations Center (SOC) will receive copies of all incoming reports in parallel with our support organization. They will assure that the support organization responses within a timely manner (goal of maximum of 4 hours). In the event that support does not process the request, the built-in SOC escalation flow will be followed to assure timely acknowledgement. The SOC, being well versed in security and compliance topics, will provide guidance on the proper handling of incoming emails (Spam, phishing, etc)

  • All final decisions of these reported cases will be reviewed and approved by the GlobalSign Operational Governance team. After applicable research and investigation, the support organization will escalate the final decisions to this group which is well versed in risk management to assure the proper decision is rendered. The Operational Governance team will bring in subject matter experts from the Product Management, Root embedding, and Compliance groups as needed depending on the type of reported issue.

This resolves both of the issues that were uncovered here (not sending a timely acknowledgement and mis-interpreting the incident).

If you have any further questions or comments, please let us know.

It appears that remediation is complete.

Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Product: NSS → CA Program
Whiteboard: [ca-compliance] → [ca-compliance] [ov-misissuance]
You need to log in before you can comment on or make changes to this bug.