1639032 - DigiCert: "Internet Widgits Pty Ltd" in organizationalUnitName

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[tiago.kieliger]

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:71.0) Gecko/20100101 Firefox/71.0

Steps to reproduce:

DigiCert issued multiple certificates with the value "Internet Widgits Pty Ltd" in organizationalUnitName:

https://crt.sh/?id=1694087072
https://crt.sh/?id=831777268
https://crt.sh/?id=279251194

"Internet Widgits Pty Ltd" is a default name in CSRs generated by OpenSSL, suggesting that the organizationalUnitName field might not have been correctly validated.

Comment 1

[Ryan Sleevi]

It's unclear that this represents a legitimate issue. Could you clarify what you believe in the Baseline Requirements has been violated?

Comment 2

[tiago.kieliger]

The Baseline Requirements (v1.7.0) states in 7.1.4.2.2 i) :
"The CA SHALL implement a process that prevents an OU attribute from including a name, DBA, tradename, trademark, address, location, or other text that refers to a specific natural person or Legal Entity unless the CA has verified this information in accordance with Section 3.2"

The name "Internet Widgits Pty Ltd" seems to refer to a Legal Entity from the "Pty Ltd" abbreviation. Admittedly, "Internet Widgits Pty Ltd" is a fictitious Legal Entity and it might be up to interpretation to decide whether clause 7.1.4.2.2 i) applies in such case.

Additionally, DigiCert CPS (v5.1) states in 3.2.2 for OV certificates :
"DigiCert verifies any DBA included in a Certificate using a third party or government source, attestation letter, or reliable form of identification in accordance with section 3.2.2 of the Baseline Requirements."

Therefore if "Internet Widgits Pty Ltd" is considered to be a DBA, it should not be allowed in the certificate. In general, I feel this bogus value resulting from OpenSSL defaults should not be allowed in (OV) certificates, although it is unclear to me whether it really violates the Baseline Requirements.

Comment 3

[Ryan Sleevi]

Ben: I think this should be “Resolved/Invalid”

Despite my reputation as a notoriously strict reader of the BRs, I am very cautious in the application of “might be” versus “is”. If this was a real organization, I absolutely would be applying the logic of this section, but this is not, as far as I can tell and based on the evidence provided. The danger here is that, if we accept the hypothetical ‘might be an organization’, is that values such as “IT Department” or “Marketing” are values that also ‘might be’ and organization.

While I think this could be worth discussion on m.d.s.p. and clarified in the future, especially given I am on record in the CA/B Forum of wanting to prohibit OUs and the discussion in the Bratislava F2F already highlighted the trouble with this language, I don’t think we have a reasonable amount of information to treat this as a CA incident.

While I certainly would be appreciative of an explanation from DigiCert about how this happened, I do want to make sure we distinguish “policy violations” from “weird and interesting things that could (and likely will, at some point) lead to policy violations”

Comment 4

[Ben Wilson]

Rather than requiring an Incident Report and before closing this bug as Invalid, I also would like to know the actions that DigiCert is taking to remediate this issue and prevent this type of OU field in the future. It appears that https://crt.sh/?id=831777268 expired and that https://crt.sh/?id=1694087072 replaced it until Jul 21 2020. That certificate shouldn't be renewed with that OU. Similarly, https://crt.sh/?id=279251194 for *.vtv.stillw.com should be replaced.

Comment 5

[Martin Sullivan]

Thanks for this.

I can confrim DigiCert is looking in to this and we should have an update shortly.

Comment 6

[Martin Sullivan]

After completing our analysis on this we agree that this is not a miss issuance but as there is no copyright infringement this has passed our validation process.

However yes this is not a desired outcome.
We agree that these certificates shall be replaced.

After running scans we have found 2 more entry’s with the same OU:
https://crt.sh/?id=1677592536
https://crt.sh/?id=1896163778

All the owners of all these unexpired certificates have been contacted and we are working to replace these with new certificates removing the offending OU.

We have also added this OU value to our validation blacklist to stop this happening again.

I think this has answers all the questions, so we ask that this is closed as invalid.

Comment 7

[Ryan Sleevi]

Martin: I’m not sure that provides sufficient detail to Ben’s question.

Can you describe how you validate these fields? And what was reviewed to permit them? This seems like a “near miss” of what would have been a substantial incident, given DigiCert’s past issues here, so it’s at least useful to be transparent about why this was exceptional and an “actual” incident wouldn’t happen.

Comment 8

[Martin Sullivan]

Thanks for that Ryan, let me describe the DigiCert OU approval process in a bit more detail.
Regarding OU Validation, we separate this into three categories, a whitelist, a blacklist, and manual validation.

Our system scans the OU and does the initial check.
This is compared to a whitelist and a blacklist.
The whitelist, includes many common terms that we have pre vetted, these include terms like IT department, accounting, web services etc.
The blacklist is one that have common terms used in fraud or copyright infringement. Examples of this include, Microsoft, Google, PayPal.
Anything that does not fall within either of these two buckets is then manually validated.
This includes checks for location names and trademarks.

If there is a trademark registered with that OU then the customer must either prove ownership of that or have the OU removed.
Lastly if there is no infringement (which is the case here), then the Certificate is issued with the requested OU.

Comment 9

[Martin Sullivan]

Hi, if there are not further questions I ask that this be closed off.

Comment 10

[Ryan Sleevi]

So, when this went to manual review, what happened? How did the validation agent determine there was no infringement? Did they search a global directory for registered businesses? A WIPO Trademark search? Something else?

That there's a manual process is useful, but what happens in this manual process is I think important, for understanding how this was determined to be OK, but something else would be reasonably prevented. As with all incident reports, part of the goal is understanding what systemic checks all CAs can or should be looking at in order to meet these requirements, and sharing DigiCert's experience for why it's completely confident that the process it has cannot produce any untoward results seems valuable.

Comment 11

[Martin Sullivan]

actually you got it in one.

I'm attaching the screen shot of that step from the validation work flow below.
But the short is that:
It triggers a risk that only a staff member with the expierience level higher than that risk score can approve.
(staff start at 0 where all their checks are double checked and work their way up after doing tests and building experience)

the system lets them know the OU is not in the white list.

Informs them to do a check for Location/Trademark

and to add a WIPO trademark search doc or remove the OU.

Comment 12

[Martin Sullivan]

Attachment: Internet_widgets_OU.png

Comment 13

[Ryan Sleevi]

Thanks. That seems to only address Trademarks, from the requirement

from including a name, DBA, tradename, trademark, address, location, or other text that refers to a specific natural person or Legal Entity

But how does that process address validation against a name, DBA, tradename, address, location, or other text?

The screenshot is really helpful, because it only seems to be addressing location or trademark, but the requirement is a bit broader.

It seems like there's an opportunity here, both to improve the description of the validation required, to potentially raise the score required, and potentially improve your blocklist to look at other terms that might refer to a legal entity and thus require additional validation (e.g. both Pty and Ltd seem like opportunities, and I'm sure DigiCert has a long list of other 'legal entity terms')

Comment 14

[Martin Sullivan]

Thank you for your suggestion. We are looking at other automation opportunities for better checking of OU as we look to roll out a new Validation Workbench later this year. We are also closely following discussions at the CA/Browser Forum about challenges with this requirement, and welcome suggestions about how the requirements can be made more concrete and auditable.

Comment 15

[Ben Wilson]

If there are no other questions or comments, on or about 31-July-2020 I intend to close this matter as resolved.