Open Bug 1894560 Opened 16 days ago Updated 2 days ago

DigiCert: Incorrect case in Business Category

Categories

(CA Program :: CA Certificate Compliance, task)

Product:
CA Program
Component:
CA Certificate Compliance
Type:
task

Tracking

(Not tracked)

Status:
ASSIGNED

People

(Reporter: martin.sullivan, Assigned: martin.sullivan)

Details

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

Attachments

(1 file)

bugzilla_list.csv
1.50 MB, text/csv
Details

On 29th of April 2024 a DigiCert employee received a personal call from a Sectigo employee. During the call, Sectigo mentioned that they had seen some issues with the case sensitivity of entries in the business category for some EV certificates. This was escalated internally, and an investigation was started.

The initial investigation showed there is no issue with certificates currently being issued. Expanding this investigation to previously issued certificates, we confirmed there is some subset of certificates issued in 2023 where the Business Category included "Private organization" rather than "Private Organization" and "Government entity" rather than "Government Entity".

Section 7.1.4.2.3 states that the businessCategory field MUST contain one of the following strings: “Private Organization”, “Government Entity”, “Business Entity”, or “Non‐Commercial Entity”.

Although we will file a full incident report later, our initial investigation shows that part of the issue resulted from an internal debate on whether the language required a case-sensitive string. Section 71.1.4.2.3 was also confused with section 9.2.5 as the initial report was for “Government entity”. Note that section 9.2.5 does not have the same exact string requirement.

The fact the EV guidelines were written by lawyers a long time ago. While engineers are case sensitive by default, lawyers are not, which makes this a question of intent. It's plausible to interpret the EVGs as non-case sensitive, while retaining case sensitivity for the BRs. Note that not all terms surrounded by quotes are case sensitive. For example, in 8.5.2 would be ridiculous if an “inactive” company was blocked but not an “Inactive” company.

This is especially true as there is a general [mis] conception that X.509 is case insensitive due to domain names being case insensitive. Although X.509 itself does not explicitly state that it is case insensitive, a quick google search shows this is a widely held believe: https://security.stackexchange.com/questions/150770/are-certificate-sans-case-sensitive or https://security.stackexchange.com/questions/187095/do-tls-standards-require-applications-to-be-picky-on-case-sensitivity-of-hostnam. As part of this effort we are rectifying this misunderstanding.

DigiCert is currently investigating the full scope of this issue and compiling a list of certificates. We will post the results of our investigation along with a root cause by the 9th of May.

I'm quite fresh to reading the fine details but perhaps this interpretation would be helpful to consider?

BR 7.1.4.2, 'Table 78: Encoding Requirements for Selected Attributes' notes:

...
Attribute: businessCategory
OID: 2.5.4.15
Specification: X.520
Encoding Requirements: MUST use UTF8String or PrintableString
Max Length: 128

Looking into X.520 (also see: Ryan Sleevi's post 2 years ago brings up:

6.5.4 Business Category

The Business Category attribute type specifies information concerning the occupation of some common objects, e.g., people. For example, this attribute provides the facility to interrogate the Directory about people sharing the same occupation.

businessCategory ATTRIBUTE ::= {
WITH SYNTAX UnboundedDirectoryString
EQUALITY MATCHING RULE caseIgnoreMatch
SUBSTRINGS MATCHING RULE caseIgnoreSubstringsMatch
LDAP-SYNTAX directoryString.&id
LDAP-NAME {"businessCategory"}
ID id-at-businessCategory }

...looking into detail on caseIgnoreMatch:

8.1.1 Case exact match and case ignore match
...

The Case Ignore Match rule compares for equality a presented string with an attribute value of type UnboundedDirectoryString or one of the data types appearing in the choice type DirectoryString, e.g., UTF8String, without regard to the case (upper or lower) of the strings (e.g., "Dundee" and "DUNDEE" match) and insignificant spaces (see clause 7.6). The rule is identical to the caseExactMatch rule except upper-case characters are folded to lower case during string preparation as discussed in clause 7.2. After taking white space into account, caseless matching shall be performed by performing case folding as described in The Unicode Standard and applying Normalization Form D or Form KC as described in Unicode Technical Report 15, depending on the character repertoire commonly examined and performance requirements.

caseIgnoreMatch MATCHING-RULE ::= {
SYNTAX UnboundedDirectoryString
LDAP-SYNTAX directoryString.&id
LDAP-NAME {"caseIgnoreMatch"}
ID id-mr-caseIgnoreMatch }

Both rules return TRUE if the prepared strings are the same length and corresponding characters in the prepared strings are identical.

I would read caseIgnoreMatch to imply case isn't a factor in businessCategory? I fear this isn't an issue of lawyer vs engineer but layered specifications that are vaguely referenced next to very specific requirements.

Apologies forgot to include this line:

Note that this differs from #1874196 which was a 7.1.4.3 issue involving the Common Name and Subject Alternative Name fields.

Thanks Wayne - that's what we're internally running into with this incident. There's layered specifications and a lack of history on the intent on case sensitivity. There are other sections of the EV guidelines which are clearly not case sensitive and others (like the cited incident) where case matters. This langugage dates back to the early EV guidelines (at least dating back to EV Guidelines 1.3). Because those discussions were made before the CABF opened its mailing list to the public, I am unaware of any history or discussion about the language. Back in ~2010, when the language first appeared in the EV Guidelines, the CAB Forum representatives primarily consisted of attorneys. As they were not engineers, I believe the intent was case insensitive, especially in light of what you posted from Ryan Sleevi.

Could a browser chime in on whether this is an issue? There is an internal hot debate on the case dependency of this section based on the caseIgnoreMatch that Wayne cited to, the history of the EV Guidelines, and the fact this language wasn't updated. If it is mis-issued, then we can revoked the certificates.

Granted, we could have avoided a debate altogether by simply keeping the case identical to the EV Guidelines. We are currently looking into the root cause of the deviation and, regardless of what the browsers respond, we will update this bug with an incident report to explain what failed in our process. However, in the mean-time, I woud love guidance from Ben or Ryan on the issue.

Flags: needinfo?(ryandickson)
Flags: needinfo?(bwilson)

Hi Jeremy,

I’ll emphasize that the Chrome Root Program’s opinion is just one of many that should be considered. If members of the community disagree with the following interpretation, discussion is always welcome.

Examining BR Requirements:

EV Guidelines - Section 7.1.4.2.3:

  • Certificate Field: subject:businessCategory (OID: 2.5.4.15)
  • Required/Optional: Required
  • Contents: This field MUST contain one of the following strings: “Private Organization”, “Government Entity”, “Business Entity”, or “Non‐Commercial Entity” depending upon whether the Subject qualifies under the terms of Section 4.1.1.1, Section 4.1.1.2, Section 4.1.1.3 or Section 4.1.1.4, respectively.

Examining DigiCert’s own requirements:

The DigiCert Certificate Profile repeats the EVGs using the following phrase: “This field MUST contain one of the following strings: "Private Organization", "Government Entity", "Business Entity", or "Non-Commercial Entity".

Note: We see the DigiCert CPS was updated in Version 6.01 on September 5, 2023, with the changes listed as: “Link to Certificate Profiles Repository included.” - hence use of the reference above.

Examining DigiCert’s issuance patterns for the related field values:

Private Organization:

Government Entity:

Business Entity:

Non-Commercial Entity:

Summary: More often than not, DigiCert has issued using the exact phrasing included in its CPS.

Examining other EV-issuer issuance patterns for related fields:

Private Organization:

Government Entity:

Business Entity:

Non-Commercial Entity:

Summary: Our quick research demonstrates that other EV-issuers appear to follow the exact strings represented in the EVGs.

Chrome Root Program Opinion:

  • By incorporating the phrasing included in the EVGs, DigiCert’s CPS sets the expectation that certificates will only contain one of the following strings: "Private Organization", "Government Entity", "Business Entity", or "Non-Commercial Entity."
  • We consider any deviation from the above (which to us, appears to imply the use of exact strings), as certificates not issued in accordance with the EVGs and DigiCert’s CPS.
  • The above interpretation (the values are case sensitive) appears both widely and reliably interpreted by other EV-issuers.
  • While we can appreciate that x.520 states “Business Category” should be considered with “caseIgnoreMatch," that consideration is orthogonal to the fact that the EVGs and DigiCert’s CPS present an explicit string to be included in certificates.
Flags: needinfo?(ryandickson)

Previously, I wasn't aware that case sensitivity was an issue, so it will take me a little bit more time to digest. I'll take a look and provide another comment soon. Thanks.

Assignee: nobody → martin.sullivan
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Flags: needinfo?(bwilson)
Whiteboard: [ca-compliance] [ev-misissuance]

Summary

On April 29th, 2024, a DigiCert employee held a personal call with a Sectigo employee. During the call, the Sectigo employee mentioned that DigiCert needed to investigate the businessCategory field in some EV certificates. We immediately launched an investigation, running our historic certificates through PKIlint. We found that some certificates issued between Sep 1st, 2023, and Dec 14th, 2023, listed “Government entity” and “Private organization” in the certificate instead of “Government Entity” or “Private Organization”. Section 7.1.4.2.3 requires the businessCategory field “contain one of the following strings: “Private Organization”, “Government Entity”, “Business Entity”, or “Non‐Commercial Entity””. Because the string “Government entity” and “Government Entity” are not identical, case sensitivity is implied and the certificates are mis-issued and requires revocation under Section 4.9.1.1(12) of the Baseline Requirements. DigiCert fixed the issue in December when adding PKIlint to our pre-issuance linting process. Prior to December, DigiCert used ZLint and custom pre-linting, neither of which caught the issue. PKIlint was added as a pre-issuance linter in an update unrelated to this incident.

Impact

We have 10,926 unexpired and unrevoked certificates impacted by this issue and are revoking all impacted certificates. We will need to file a delayed revocation bug because of a data pull issue that occurred when finding the certificates and problems with replacing certificates. We will provide full disclosure of the delayed revocation in that separate report, including a proposal on when all certificates can be replaced, the reason they cannot be replaced, and commitments to automation. A couple of important points is that the note is that the delay is not related to validation of any customer’s identity, we have emphasized that there is no exception or extension to the Baseline Requirements, and we are adhering strictly to the requirements found in https://wiki.mozilla.org/CA/Responding_To_An_Incident.

Timeline

All times are UTC.

2023-09-01 – While deploying changes for SC-62, DigiCert engineering noticed a file pointer for a file containing static values was incorrect. The file pointer was wrong from an architecture perspective, not that the old file pointed to had incorrect values within it. Engineering fixed the pointer. Unfortunately, the new file contained “Government entity”, “Private organization”, and “Business entity” instead of “Government Entity”, “Private Organization”, and “Business Entity”. The update was applied only to our new validation system and not our legacy DigiCert validation system, leaving the legacy businessCategory field values unchanged. QA reviewed the file change (but not the file contents) as the updated file was not new to the system. This fix caused certificates to issue with incorrect contents. Several issues with the change led to the problem: a) DigiCert did not have a unit test for this issue, b) no one reviewed the contents of the file, and c) we relied on Zlint to catch compliance issues rather than performing a thorough review of the change.

2023-09-13
18:30 – A DigiCert compliance employee using PKIlint noticed that an EV certificate was flagged with an incorrect businessCategory field values. The compliance person pointed out that we issued at least one certificate with “Government entity” instead of “Government Entity”. The compliance person raised the issue on our SC-62 slack channel, which had many concurrent conversations around SC-62 profile requirements and deployments. No one raised an official incident or followed our incident process at this point. Instead, an informal internal debate started about whether subject fields in certificates are case sensitive. Engineering looked at what changed and reported there was no change to the businessCategory field. We also mentioned that X.520 specifies this field as case insensitive.

20:36 - I reviewed Section 9.2.5 of EV Guidelines v. 1.8, a section about serialNumber instead of businessCategory. I was working on a project related to serialNumbers for Government Entities at the same time and both investigations were classified as “Government Entity” capitalization. This was an error and caused confusion until rectified much later. Relying on the statement that X.520 is case insensitive and the fact 9.2.5 is case insensitive, I classified the issue as a false positive in PKIlint without reviewing 9.2.3 - the correct section of the EV Guidelines for businessCategory. I asked engineering to deploy a fix the same day because a) I did not see a reason to deviate from other CAs even if case sensitivity was not required, and b) the language (in 9.2.5) is vague and I didn’t want to risk that I incorrectly evaluated the requirements. Engineering deployed the fix and closed the issue. However, engineering did not properly reset the profile associated with organizations verified using the bad profile between Sep 1 and Sep 19. This fixed the issue for new validations but not existing validations.

2023-09-19 7:01 - A compliance employee raised the same issue on the SC-62 channel. As Zlint was not showing an error, engineering closed the issue believing the fix worked.

2023-12-14 - Engineering deployed PKIlint. PKIlint detected the bad profiles and blocked issuance. Engineering cleared the existing validation profiles which removed the bad profile from validated organizations.

2023-12-18 - A compliance team member raised the issue again. The issue was closed again because our pre-issuance linting system did not detect any errors. At this point, PKIlint was fully functional as part of our pre-issuance linter system. Because the organization profiles were cleared, PKIlint detected no errors, and the issue was closed as previously resolved.

2024-04-29 - During a personal conversation, a Sectigo employee mentioned to a DigiCert employee that they noticed a potential issue in our businessCategory field in some EV certificates. The DigiCert employee escalated the issue to me.

2024-04-29:

3:16 - I started a formal incident process and began investigating “Government entity”.

3:29 - We realized the issue goes beyond “Government entity” and includes “Private organization” and started a discussion on whether capitalization is required began. We use our formal compliance opinion process to confirm capitalization is required under Section 9.2.3. Engineering pointed out that the decision is contrary to the previous note on our SC-62 slack channel. SC-62 is archived so I review the slack channel to create a timeline of what happened and review why we decided this was not an issue. On review, I realized the error mixing the serialNumber question with the businessCategory question. We post the opinion and reasoning about why these are mis-issued on our incident channel.

9:58 - We opened an investigation into why Zlint did not detect the error. We discovered Zlint planned to add detection here: https://github.com/zmap/zlint/pull/830.

20:08 - Initial data pull completed. We began reviewing the data to confirm accuracy. Several issues were spotted over the next couple of days.

2024-05-02, 3:47 – The errors in the initial data pull were reported, and we submitted a request for a new data pull. The data engineering team revised its query and pulled new data.

2024-05-02, 18:42 – The new data pull completed. We began reviewing the data for errors. We also drafted customer communication alerting them to the issue.

2024-05-06, 16:00 – We completed our review. No errors were detected in the data. We sent serial numbers to impacted customers informing them of the mis-issuance.

Root Cause Analysis

There were several errors that ended up resulting in mis-issuance.

  1. QA and unit tests failed to detect the issue with capitalization. When we changed file pointers, no one reviewed the file to ensure correct contents. QA focused on the changed pointer working correctly. We did not have unit tests in the CA for case sensitivity on the businessCategory field.

  2. Over-reliance on Zlint. The internal teams assumed the certificates profiles were correct as the certificate passed our internal linting, which included the use of Zlint. Although PKIlint flagged the issue, we assumed (because PKIlint was new) that PKIlint had a false positive error instead of Zlint missing the check. PKIlint was not part of DigiCert’s internal linting process in September when the error occurred.

  3. Single-person evaluation of a compliance requirement. My analysis of the compliance issue reached the wrong conclusion. I was working on a few projects at the same time and mixed the businessCategory review with a subject:serialNumbers review as both related to “Government Entity” capitalization in the certificate. Because of this mistake, I incorrectly categorized businessCategory as case insensitive.

  4. Informal review process. Normally, for official compliance opinions, we use a set process where a ticket is logged in JIRA. Then, a committee of compliance personnel review the ticket and provide a written opinion on the requirements. This question was opened and answered outside of that process in a slack channel related to SC-62. Similarly, both the compliance and engineering team failed to follow our documented incident process. All discussions around this topic occurred on our SC-62 Slack channel, which allowed the issue to skip a formal review and be drowned out by the noise surrounding implementation of the SC-62 ballot. Compliance raised the issue a few times on the thread but most conversation was focused on SC-62 implementation. Because of this, the incident was closed as a false positive associated with PKIlint each time the issue was raised. If we’d had a formal review of the requirements or raised an incident, we would have avoided delays in detecting and reporting the issue.

  5. Confusion about requirements. There was uncertainty around whether this was a compliance issue. Part of that was confusion around whether X.509 subject information is case sensitive. This field’s case sensitivity requirement, in particular, was confusing for the following reasons: a) the browsers have not treated the field as case sensitive, b) the field does not exist in 5280 so no guidance is provided, c) ITU lists the field but does not specify case sensitivity, d) X.520 specifically lists this field as case insensitive, and e) the EV guidelines themselves do not specify whether the field is case sensitive. Given the EV guidelines were written back in 2007 by mostly lawyers, the assumption that the drafters intended the field to be case insensitive makes sense. However, the Guidelines state that “This field MUST contain one of the following strings: “Private Organization”, “Government Entity”, “Business Entity”, or “Non‐Commercial Entity” depending upon whether the Subject qualifies under the terms of Section 4.1.1.1, Section 4.1.1.2, Section 4.1.1.3 or Section 4.1.1.4, respectively”, which makes it clear the exact string is expected. Afterall, U+006F is different than u+004F so the string would be different from what’s specified if the field is case insensitive. Plus, X.520 only applies to browser implementations, not to CA requirements.

  6. Failure to update existing validations. Compliance detected the issue on Sep 13, 2023, and asked engineering to inject a fix for the issue that same day. Engineering fixed the issue but the organizations impacted by the issue were stored with the incorrect business type. Organization validation profiles are supposed to synch back to the CA and ensure compliance with the latest requirements but did not in this case. Nothing skips our pre-issuance linting service which allowed PKIlint to detect the problem when deployed. We are still investigating what happened and why the org information did not sync automatically.

Lessons Learned

What went well

• PKIlint correctly flagged the businessCategory capitalization issue.

What didn't go well

• We relied on a single, unofficial review of the issue rather than going through our official compliance opinion process. This resulted in an incorrect interpretation of the requirements being relied on.

• We failed to review the accuracy of the updated file before implementing a pointer to the file. Although the pointer worked correctly, the contents of the file were not correct. There wasn’t a unit test to ensure the correct string in that field.

• We failed to raise the issue using our documented incident process. No one raised the issue as a compliance incident nor did we do additional investigation on why the certificates were issuing despite an engineering fix being in place. The additional flagged certificates were lost in the noise of a very active slack channel and closed without proper review.

• We relied too heavily on Zlint for compliance alerts. We should have checked the requirements more closely rather than assuming Zlint had the requisite checks.

Where we got lucky

• PKIlint, when added to our pre-issuance linter pool, detected the bad certificates and blocked additional issuance.

• The file change made by engineering only impacted EV certificates and not DV or OV

Action Items

  1. Compliance Reviews. We already require all compliance decisions to be decided by a compliance committee and include formal documentation. This documentation is saved in a JIRA project where anyone can see and review the decision. This process will ensure a better review procedure and prevent mistakes during the decision-making process. Regardless of the issue, all compliance related questions must be directed to this review process. | Prevent | Done

  2. PKIlint. We added both PKIlint and Zlint to our internal linting process. | Prevent | Done

  3. Certificate Review. We are running PKIlint against all active certificates and will provide a report on any errors found. All findings will undergo an additional review. | Detect | 5/15/2024

  4. We are replacing and revoking all impacted certificates and will file a delayed revocation bug as explained above. |Mitigate | 11 May 2024

  5. We are still investigating why the validation information for an organization did not sync back to the CA and how to prevent it from happening again. We will provide an update on the status of that JIRA in our next update. |Mitigate | 15 May 2024

Appendix

The affected certificates are listed in the attachment.

Attached file bugzilla_list.csv —

This opens a can of worms on casing and expectations throughout the document. I'll be succinct as even briefly researching this has resulted in CPRs to 3 different CAs on more than one issue.

Keeping the scope to purely X.520 we have the following fields all of which are caseIgnoreMatch:

businessCategory

  • Explicit strings listed in EVG 7.1.4.2.3, discussed above

organizationIdentifier

  • Implicitly case sensitive, uppercase only due to EVG 7.1.4.2.8

postalCode

  • Extremely regional on casing

streetAddress

  • Extremely regional, you'd think Pascal Case but I've found a mixture of certificates with inconsistent casings

The headache with the above is they all have to come from business records, or more realistically paid address banks. Speaking from a different industry these aren't even consistent between the companies selling the data on address consistency for a single property. The truth source has to be the document the CA verified, and the public records can't be relied on.

But I digress, my point is more if we've diverged from the explicit parts of X.520, then why mention it at all? This could also apply to other RFCs mentioned and is going to result in several incidents raised here shortly for even the most basic of information. Should BR/EVGs be updated to hold all of these decisions in one location to avoid another CA falling foul to this? Please note I'm not against any of this, but questions have to be asked.

Also of note is when precisely does the start of revocation clock begin for an open question like this incident? When one Root Program has opined, or when a full consensus is reached? Who makes that call, and does the clock begin once the CA has then read that message confirming a consensus? Presumably one program would tip the scale on the CA's behalf, but what if their decision is changed in later discourse?

I can't answer about the divergence from X.520 as (from a personal standpoint) I am still in disbelief that the industry cares about capitalization in fields that the browsers never intend to use. I suppose opinions do not matter as strict compliance is required, and two browsers have indicated that this is a compliance issue. If one browser decides its a compliance issue, then you have to revoke IMO. Afterall, who would use a CA where the certificates only work in half the user agents? One of the reasons the CABForum was started in the first place was to try to ensure browsers didn't create conflicting requirements, which we identified as a distinct possibility back in 2006-2007.

I had the same concern about when the clock starts. I don't really know as 4.9.1.1 states that it starts when the CA is made of aware of an issue. This is one reason we are filing the delayed revocation report. Did that clock start back in September when there was an issue? Did it start when we first found out there might be an issue? When we had the data? Regardless, we're filling a delayed revocation report to cover all those scenarios. We set the five days for this one when we had the data and confirmed it was accurate. I think that's the correct approach as its when you know a certificate is incorrect but others may have a different opinion. If its earlier, then you're going to miss the five day revocation deadline every time as it might take five days to notify a customer during a mass revocation event or you might receive a report on a Thursday, confirm on a Friday, send a notice on Monday, leaving only two days to revoke. We have a lot of customers using automation and even the ones with wide-spread ACME usage struggle with a five day turn around. Simply communicating internally at non-tech companies can take that much time.

I am still in disbelief that the industry cares about capitalization in fields that the browsers never intend to use. I

Honestly, same. I'm also still in disbelief that EV is being relied upon since it's usually the type of validation that ends up with this class of incidents as well.

I generally agree with comment 4 here. I also think that stricter specifications should probably happen here to make life easier for everyone so we're not searching through decades old documents :P

When I see something like, string must contain "WoRd", where the word has a mix of upper and lower case characters: I'm going to assume that case sensitivity matters there. This is probably just my read about it though.

Also of note is when precisely does the start of revocation clock begin for an open question like this incident? When one Root Program has opined

The flow I've had is, if the answer to "is this an incident or not" is actually not clear (e.g. there is a discussion like this about it), then the timer starts once a consensus without root program involvement has been reached. However, If a root program says this is an incident, then the timer starts without there being a consensus.

Note that this is probably pretty abusable if CAs start asking "is this an incident" for very obvious problems.

For full transparency, DigiCert historically started the date as soon as we know any serial numbers that we need to revoke, regardless of whether they are sent by a third party or pulled from our database. Starting a revocation clock at that time made sense as section 4.9.1.1(12) states that a CA must revoke within 5 days of becoming aware that a certificate does not comply with the requirements. I figured that we aren't aware of the certificate until we have its thumprint or serial number.

That doesn’t quite sit right with me. If you have evidence that you have misissued (such as by messing up CPS), I think the 5 day responsibility includes finding all the affected certificates. Otherwise it’s fine for CAs to do a sloppy search and miss some, and rely on others to report the specific ones missed. As we’ve seen in a number of incidents over the last several months, CAs aren’t always able to quickly produce the list of affected certs, and I don’t think that should give them more time to revoke.

There are a couple of factors that mitigate that concerns. First, a CA is required to report the incident within 72 hours. That alerts the community the CA is at least doing an investigation. Second, a CA is required to provide a complete incident report that includes timestamps of actions taken. That ensurs the community is fully aware of the activity a CA takes in discovering issues, pulling data, and reporting on issues. Third, the browsers treat CAs that don't understand what they issued rather badly (see the Symantec distrust). As a CA, I'd much rather gather the data quickly and show that I can manage my data than get caught trying to fake the timelines. Afteall, the primary penalty for a delay revocation is filing a delayed incident reports. The public gets full awareness into what happened, which means the community can call shennanigans on any CAs trying to be fancy with the timing.

Respectfully, that a CA is “required” to do those things does not mean that they actually will, and relying on the incident opening to trigger prompt revocation feels like adding risk to risk. We have ample evidence of that from a number of CAs, including at least one very established one with very important subscribers using very expensive certificates.

I think we’re past the point of being able to rely on earnest attention to the intent of BRs and Root Program requirements and need to layer on specific requirements that provide more clarity and attention to the things that are most important (revoking missed certs, for example).

Oh - I agree that the incident shouldn't start the prompt for revocation, even with the current language. Per 4.9.1.1(12):

"The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA’s Certificate Policy or Certification Practice Statement (CRLReason #4, superseded);"

Per that language, revocation should start when the CA is aware that the certificate was not issued in accordance with the requirement. I agree that we should revise this language to provide clarity around timelines and better guidance on when delays are acceptable. Right now we just have the Mozilla policy for guidance, and I’m never 100% sure what qualifies as “critical infrastructure”.

The current language about revoking when a CA is aware of a mis-issued certificate does give a perverse incentive to remain blissfully unaware of issues. However, the threat of distrust counters that. You might disagree (based on your post), but I’ve always found it a strong incentive to promptly investigate and report issues.

(In reply to Jeremy Rowley from comment #15)

but I’ve always found it a strong incentive to promptly investigate and report issues.

And, unironically, I am grateful for it on behalf of the WebPKI system.

I will note that when I provided data on 20 incidents to the m-d-s-p mailing list that the revocation timeframe start point was an explicit issue:

  • There is imprecise wording and different interpretations on when the revocation start timer begins, and how CAs note this in their incident reports. To that end I've separated the time that a CA seems to have internally confirmed the issue, and when they actively started some process of revocation: contacting subscribers or actively revoking.

If you go into the summary page of that spreadsheet you can see a list of 'start times' that vary across CAs. Perhaps I should be far more explicit on issues in later research rather than trusting people to read the fine print though. I can put together a list of where each CA's assumptions of when the revocation timer begins at a later date but it should be quickly apparent looking at their incident reports.

I personally read the BRs as the clock starting once acknowledgment of an issue happens internally. The issue is looking at how CAs start the 5 day timer across a variety of issues it seems that in general they consider when a finalized list of prepared to be the start time. Note that for some CAs this can be multiple days, and can even be once they start contacting subscribers directly. I was very generous with those start times.

I'm not sure how you can justify the five days starting sometime after you notify customers. At that point, the CA is aware that the certificate was mis-issued. Otherwise, why would they reach out to have it replaced? That’s a weird one.

When investigating the organization syncing issue, we found that the organization syncing was tied to validation expiration. This meant that the org information updated to changes whenever it was manually reset, when the org information was invalidated (due to a change in business or data), or when any piece of the information expired. Given that there are many reasons to sync the CA and org validation more often (including compliance issues), we are updating the syncing timeframe to 3 days. We plan to tweak it as needed to balance freshness and robustness but will no longer tie the sync to valdiation. We will be deploying this change on May 21.

We ran PKIlint over all active DigiCert certificates and found the following (along with status and explanation on resolution):

  • pkix.invalid_domain_name_syntax - this is flag for wildcard certificates, which are technically prohibtted under 5280 but allowed by the CABF Baseline requirements.
  • cabf.ev_guidelines.cps_uri_policy_qualifier_missing - this 1 certificate was addressed in bug # 1888016
  • cabf.ev_guidelines.invalid_business_category - these certificates are addressed in this bug
  • cabf.serverauth.organization_identifier_mismatched_state_province - this 1 certificate was addressed in bug # 1888016
  • cabf.serverauth.subscriber.non_critical_basic_constraints_extension - All certificates issued before SC62, which created this requirement
  • cabf.serverauth.subscriber.non_critical_basic_constraints_extension - All certificates issued before SC62, which created this requirement
  • cabf.serverauth.iv.given_name_attribute_absent - All certificates issued before SC62, which created this requirement
  • cabf.serverauth.iv.surname_attribute_absent - All certificates issued before SC62, which created this requirement
  • cabf.serverauth.subscriber.non_critical_basic_constraints_extension - All certificates issued before SC62, which created this requirement
  • cabf.internal_domain_name - This is a new public TLD that needs to be updated in pkilint. We will work on a fix in PKIlint
  • cabf.serverauth.subscriber_prohibited_ku_present - Issued before SC62, which created this requirement
  • cabf.serverauth.subscriber.non_critical_basic_constraints_extension - All certificates issued before SC62, which created this requirement
  • pkix.invalid_domain_name_syntax - this is flag for wildcard certificates, which are technically prohibtted under 5280 but allowed by the CABF Baseline requirements.
  • cabf.serverauth.subscriber.non_critical_basic_constraints_extension - All certificates issued before SC62, which created this requirement

We should have all fixes done for this bug by our next update, which I believe is all action items except revocation of the remaining certificates. We will continue to address that on the delayed revocation bug associated with this incident.

cabf.internal_domain_name - This is a new public TLD that needs to be updated in pkilint. We will work on a fix in PKIlint

Just to clarify this finding: The version of the publicsuffixlist package used by the machine for this historical scanning was older and did not include the TLD present in the certificates. We confirmed that the TLD in question was present on the list at time of issuance and also currently present on the list. Additionally, updating the publicsuffixlist package on the machine resolved this false positive finding.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: