Closed Bug 1551374 Opened 4 months ago Closed 2 months ago

SecureTrust: "Some-State" in stateOrProvinceName

Categories

(NSS :: CA Certificate Compliance, task)

task
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: wayne, Assigned: fcorday)

Details

(Whiteboard: [ca-compliance])

Two SecureTrust certificates containing a stateOrProvinceName of "Some-State" were published at https://misissued.com/batch/53/ This is apparently the default placed in OpenSSL CSRs, indicating that this field was not validated. BR section 7.1.4.2.2(f) states: If present, the subject:stateOrProvinceName field MUST contain the Subject’s state or province information as verified under Section 3.2.2.1. The EVGLs reference the BRs.

The two certificates were revoked the day after being published.

Please provide an incident report, as described at https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report

  1. How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date.

A problem report was submitted to our problem reporting mechanism on May 11, 2019 at 12:37 CDT.

  1. A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done.
  • 05.11.2019, 12:37 CDT Alex Cohn submitted problem report to our problem reporting mechanism
  • 05.11.2019, 15:16 CDT Identified 3 additional valid certificates issued with “Some-State” in the state field
  • 05.11.2019, 16:37 CDT Certificates revoked
  • 05.11.2019, 16:44 CDT Problem reporter and subscriber notified of revocation
  1. Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation.

SecureTrust has mitigated the potential problem through a system update in April 2017. The 4 eyes principle was also introduced in the effort to minimize the human error factor.

  1. A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.

5 certificates were issued as a part of a chain of reissuances for the same product instance. The initial product issuance was 11.30.2016, 00:14 CST. The last issuance with that problem was issued on 04.18.2017, 01:50 CDT.

  1. The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.

Please see:
https://crt.sh/?id=1471108717
https://crt.sh/?id=1471108270
https://crt.sh/?id=1471107845
https://crt.sh/?id=307777766
https://crt.sh/?id=57868366

  1. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.

On April 19th 2017, SecureTrust introduced a systematic process change for validation agents that would make this type of issue more easily noticed by validation agents for correction. SecureTrust began utilizing a local, periodically updated, copy of the GeoNames data set in its validation agents’ UI. State/province and locality values that do not match data in GeoNames for the selected country are flagged in the UI with warning indicators during the validation process. Which is the reason the subsequent re-issuance of this certificate corrected the problem. There was not a process in place at that time to retroactively check for this issue.

  1. List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.

The system update to identify this issue was released on April 19th, 2017. Since then, additional steps have been implemented, such as the 4 eyes principle and additional documented procedures for validation agents to follow and correct the certificate information if the system identifies this issue.

selected country are flagged in the UI with warning indicators during the validation process

This is a great change, and I'm glad to hear it was implemented well in advance of similar suggestions being made to other CAs affected by this issue.

A question about this process: What is the workflow when a warning is present? For example, can an RA ignore this warning? If they do, is someone from Compliance notified / additional review required? Understanding the process/flow here for this new/updated UI is hugely valuable in understanding how it will be prevented in the future.

Similarly, when you implemented this change two years ago, did you examine your existing certificates for divergences? Have you done so in light of this incident? Your incident report makes it unclear whether you addressed specifically "Some-State" or whether you looked systemically and holistically, given the issues.

Since then, additional steps have been implemented, such as the 4 eyes principle and additional documented procedures for validation agents to follow and correct the certificate information if the system identifies this issue.

Can you provide additional details here as well.

Before this issue, what was your process for validating? After these changes, what does that process look like now? For example, I'm trying to understand when and where the 4-eyes principle is being applied, and how that's changed.

Similarly, you mentioned additional documented procedures - but don't specify what they are, or what they were - so it's unclear how they mitigate the issue. Having additional details here help understand the changes and how they go to address the issue.

Flags: needinfo?(fcorday)
  1. A question about this process: What is the workflow when a warning is present? For example, can an RA ignore this warning? If they do, is someone from Compliance notified / additional review required? Understanding the process/flow here for this new/updated UI is hugely valuable in understanding how it will be prevented in the future.

Location data is tracked separately in two objects in our system: the certificate request record (which is initially populated from the values in the CSR but can then be modified by validation agents to be correct) and the organization validation record, which is created by the validation agent when performing the steps from BR 3.2.2.1. We show these warnings on the fields when viewing or editing either entry. Next to the locality, state, and country fields in each we show either a green checkmark if the value matches the GeoNames database or a red exclamation mark if it does not. These matches are contextual, so for example if you had Chicago / Illinois / United States, you’d see 3 checkmarks, but as soon as you began editing the “Illinois” value it would change both the state and locality checkmarks to exclamation marks since Chicago is no longer valid unless it’s in the context of the state of Illinois. The country field is presented as a pulldown and thus it will always have a checkmark. (Note, our system rejects CSR submissions with invalid country codes.)

The icons are also shown in the review and issuance dialogs later in the process.

When an agent sets these to values that trigger any exclamation marks, there is also a click-through dialog required to proceed, just to make sure the warning wasn’t missed. The warnings are just advisory at this point, for a couple of reasons. One is that the GeoNames data set is not a complete list of all locations in the world. The other is that there are often multiple ways to express particular locations and it’s often not clear cut which is the “best” way. A couple of common examples in the United States are New York City and Washington DC. GeoNames uses “New York City” as the locality, but it’s also in our view perfectly valid to put “New York” as the locality, and that may well be the way the locality is named in the data source(s) used for validation. Similarly, Washington DC, Washington D.C., and District of Columbia are all commonly-used values for the capital city of the United States. Internationally, Great Britain is the source of a lot of our mismatches with GeoNames, because the recognized state/province values there are only England, Northern Ireland, Scotland, and Wales. If the data source lists a province within England, for example, we would normally place that province in the state/province field rather than England, thus causing a mismatch. There is unfortunately a subjective aspect to this in the state/province and locality fields that preclude a hard fail. We are relying on the 4 eyes process combined with the GeoNames check to prevent an issue like in this bug where the data is obviously wrong. The system also enforces a case-insensitive match between the location data in the organization validation record and the data in the certificate request record prior to issuance.

  1. Similarly, when you implemented this change two years ago, did you examine your existing certificates for divergences? Have you done so in light of this incident? Your incident report makes it unclear whether you addressed specifically "Some-State" or whether you looked systemically and holistically, given the issues.

We did not do any examination of existing certificates for divergences at the time, as these changes were just a part of general ongoing efforts to reduce potential sources of human error and there wasn’t reason at the time to suspect that such an error had occurred (i.e. our normal audit sampling hadn’t turned up any anomalies to that point.) The review we performed in response to this incident was focused only on the default OpenSSL values that had recently come up. We are in the process now of running our existing valid certificate subjects through GeoNames in order to identify and manually re-review all of the location data that isn’t an exact match in order to see if there are any other similar types of issues. We hope to complete this review in a couple of weeks and will follow up here with the results. We expect to be able to complete the supplemental review by the first week of June.

  1. Since then, additional steps have been implemented, such as the 4 eyes principle and additional documented procedures for validation agents to follow and correct the certificate information if the system identifies this issue.
    Can you provide additional details here as well.
    Before this issue, what was your process for validating? After these changes, what does that process look like now? For example, I'm trying to understand when and where the 4-eyes principle is being applied, and how that's changed.

When these certificates were initially issued, each individual analyst was able to fully validate and issue a certificate on their own except EV. In July of 2017, we re-evaluated our protocols and implemented the 4-eyes principle to include OV and Code Signing as well. No individual analyst is authorized to issue a certificate if they have validated information on the certificate.

  1. Similarly, you mentioned additional documented procedures - but don't specify what they are, or what they were - so it's unclear how they mitigate the issue. Having additional details here help understand the changes and how they go to address the issue.

As a part of our protocol changes implemented in July of 2017, we created a more robust, internal reference area (Wiki) for certificates. Encompassing what is allowed for use on each validation step, clearly defining these steps which are broken down based on certificate type. Prior to the 2017 changes, after initial training, validation analysts were able to directly reference the CAB Forum guidelines with internal materials providing clarifying information.

Flags: needinfo?(fcorday)
Whiteboard: [ca-compliance] → [ca-compliance] - Next Update - 10-June 2019

Thanks, Frank. This level of detail really helps build an understanding of the process and flow of things, and also helps identify how some of the concerns shared on other CAs' bugs are being mitigated here.

In the future, this is a great level of detail to go through in the incident reporting - understanding how the flow is working or used to work, how the changes have addressed it, what some of the challenges are with strict controls, and how those are being addressed.

I will note that, as an alternative to GeoNames, ISO 3166-1 and ISO 3166-2 both provide a significant wealth of data with respect to countries and their subdivisions (e.g. provinces, states, departments, regions). This seems a useful way to reduce some of the ambiguity or consistency issues you were speaking of. This is relevant, in as much as I'm given to understand that GeoNames is a crowd-sourced set of data, and thus runs some risks with respect to quality that may lead to future issues. However, this may be complementary to your compliance efforts.

As a brief update, due to unanticipated resource limitations, we have not completed the supplemental review as of yet. However, we are very close to completion. Our team is working diligently where we aim to provide our findings within the next few days.

Frank: Any updates here?

Flags: needinfo?(fcorday)

Ryan: Please expect to view our report posted here tomorrow.

We have completed our supplemental review of our certificate location data. We are revoking these certificates in compliance with baseline requirements. We will look into and consider additional systematic changes as a result of this review.

We found these certs to have errors:

Certificate information: https://crt.sh/?id=575860967
Problem discovered: Locality field is set to “East Oakleigh”, however the proper name is “Oakleigh East”.
Resulting action: Revoke
Current validation protocols would have discovered the error (Yes/No): Yes

Certificate information: https://crt.sh/?id=723613593
Problem discovered: Miss-spelling: Locality is set to “Mount Claremount”, however the proper name is “Mount Claremont”.
Resulting action: Revoke
Current validation protocols would have discovered the error (Yes/No): Yes

Certificate information: https://crt.sh/?id=1574427212
Problem discovered: State/Province is set to “VictoriaNew South Wales” but it should just be “New South Wales”.
Resulting action: Revoke
Current validation protocols would have discovered the error (Yes/No): Yes

Certificate information: https://crt.sh/?id=1574430772
https://crt.sh/?id=42738113
Problem discovered: Miss-spelling: Locality is set to “St. Jhon’s” instead of “St. John’s”.
Resulting action: Revoke
Current validation protocols would have discovered the error (Yes/No): Yes

Certificate information: https://crt.sh/?id=128757015
https://crt.sh/?id=112657846
Problem discovered: State/Province is set to “Switzerland” but it should be “Vaud”.
Resulting action: Revoke
Current validation protocols would have discovered the error (Yes/No): No

Certificate information: https://crt.sh/?id=202772694
Problem discovered: Miss-spelling: State/Province is set to “Issy-les-Molineaux” but it should be “Issy-les-Moulineaux”.
Resulting action: Revoke
Current validation protocols would have discovered the error (Yes/No): No

Certificate information: https://crt.sh/?id=1574428532
Problem discovered: Birmingham is listed as the State/Province with Quinton as the Locality, however Quinton is a suburb of Birmingham rather than being a state or province.
Resulting action: Revoke
Current validation protocols would have discovered the error (Yes/No): No

Certificate information: https://crt.sh/?id=1285313613
Problem discovered: Street address is in the locality field and locality information is in the state/province field.
Resulting action: Revoke
Current validation protocols would have discovered the error (Yes/No): Yes

Certificate information: https://crt.sh/?id=1574433113
Problem discovered: Country code (US) is listed in the state/province field rather than the actual state.
Resulting action: Revoke
Current validation protocols would have discovered the error (Yes/No): Yes

Certificate information: https://crt.sh/?id=69384816
Problem discovered: The state/province abbreviation (VA) was appended to the locality value, giving “Meadows of Dan VA” where it should just be “Meadows of Dan.”
Resulting action: Revoke
Current validation protocols would have discovered the error (Yes/No): Yes

Certificate information: https://crt.sh/?id=144298984
https://crt.sh/?id=160958031
Problem discovered: State/province and locality values are transposed (“ZA Montredon” in state/province field and “L’Union” in locality field.)
Resulting action: Revoke
Current validation protocols would have discovered the error (Yes/No): Yes

Certificate information: https://crt.sh/?id=563332447
Problem discovered: Miss-spelling: “Londonberry” in State/Province should have been “Londonderry”.
Resulting action: Revoke
Current validation protocols would have discovered the error (Yes/No): No

Certificate information: https://crt.sh/?id=1129540223
https://crt.sh/?id=1120970516
https://crt.sh/?id=1141955886
https://crt.sh/?id=1120966474
https://crt.sh/?id=1126245611
https://crt.sh/?id=1120966412
https://crt.sh/?id=1120972824
https://crt.sh/?id=1120972221
Problem discovered: State/Province set to “Worcester” instead of “Worcestershire”.
Resulting action: Revoke
Current validation protocols would have discovered the error (Yes/No): Yes

Certificate information: https://crt.sh/?id=307541992
Problem discovered: Locality value is in State/Province field (“Tegucigalpa”) and Locality is set to “TG”. State/Province should be set to “Francisco Morazan.”
Resulting action: Revoke
Current validation protocols would have discovered the error (Yes/No): Yes

Certificate information: https://crt.sh/?id=1574427061
https://crt.sh/?id=1574432560
https://crt.sh/?id=1574432593
https://crt.sh/?id=891954891
Problem discovered: Street address is in the locality field and locality information is in the state/province field.
Resulting action: Revoke
Current validation protocols would have discovered the error (Yes/No): Yes

Certificate information: https://crt.sh/?id=274707914
Problem discovered: State field is set to “Bolzano” but that is a locality.
Resulting action: Revoke
Current validation protocols would have discovered the error (Yes/No): No

Certificate information: https://crt.sh/?id=995474976
Problem discovered: Street address is in the locality field and locality information is in the state/province field.
Resulting action: Revoke
Current validation protocols would have discovered the error (Yes/No): Yes

Certificate information: https://crt.sh/?id=1574429059
https://crt.sh/?id=1031466609
https://crt.sh/?id=1574427956
https://crt.sh/?id=830174719
https://crt.sh/?id=1574429943
https://crt.sh/?id=280316217
https://crt.sh/?id=106235911
https://crt.sh/?id=1574429623
https://crt.sh/?id=42184346
https://crt.sh/?id=118696153
Problem discovered: Locality and State/Province values are switched.
Resulting action: Revoke
Current validation protocols would have discovered the error (Yes/No): No

Certificate information: https://crt.sh/?id=332864483
https://crt.sh/?id=1063864531
https://crt.sh/?id=23888038
https://crt.sh/?id=46179952
https://crt.sh/?id=23694476
https://crt.sh/?id=1574427112
Problem discovered: Locality and State/Province values are switched.
Resulting action: Revoke
Current validation protocols would have discovered the error (Yes/No): No

Certificate information: https://crt.sh/?id=1574432559
https://crt.sh/?id=1231647762
https://crt.sh/?id=1232100055
https://crt.sh/?id=669457101

Problem discovered: State/Province value in Locality field.
Resulting action: Revoke
Current validation protocols would have discovered the error (Yes/No): Yes

Certificate information: https://crt.sh/?id=1207206673
https://crt.sh/?id=939742401
https://crt.sh/?id=1574428493
https://crt.sh/?id=380854803
https://crt.sh/?id=1227466549
https://crt.sh/?id=463245540
https://crt.sh/?id=1574430671
https://crt.sh/?id=1574430746
https://crt.sh/?id=1574428592
https://crt.sh/?id=431034424
https://crt.sh/?id=1574429582
https://crt.sh/?id=1574430081
https://crt.sh/?id=1574429980
https://crt.sh/?id=1574429066
https://crt.sh/?id=370271338
https://crt.sh/?id=1574432688
https://crt.sh/?id=1574429266
https://crt.sh/?id=1435493286
https://crt.sh/?id=445700314
Problem discovered: State/Province value duplicated in Locality field.
Resulting action: Revoke
Current validation protocols would have discovered the error (Yes/No): Yes

Certificate information: https://crt.sh/?id=1376746427
Problem discovered: State/Province value in Locality field.
Resulting action: Revoke
Current validation protocols would have discovered the error (Yes/No): Yes

Certificate information: https://crt.sh/?id=1574427240
https://crt.sh/?id=1574427194
https://crt.sh/?id=1574428473
https://crt.sh/?id=996501827
https://crt.sh/?id=1042487920
https://crt.sh/?id=986010786
https://crt.sh/?id=1043030761
https://crt.sh/?id=976635768
https://crt.sh/?id=1574427109
https://crt.sh/?id=976635581
https://crt.sh/?id=1042909922
Problem discovered: Non-existent locality (“MTxico”) in Locality field.
Resulting action: Revoke
Current validation protocols would have discovered the error (Yes/No): Yes

Certificate information: https://crt.sh/?id=74731334
Problem discovered: Non-existent state (“New York”) for country Nicaragua.
Resulting action: Revoke
Current validation protocols would have discovered the error (Yes/No): Yes

Certificate information: https://crt.sh/?id=1231497163
https://crt.sh/?id=1231866518
https://crt.sh/?id=1178007850
Problem discovered: Street address is in the locality field and locality information is in the state/province field.
Resulting action: Revoke
Current validation protocols would have discovered the error (Yes/No): Yes

Certificate information: https://crt.sh/?id=308193945
https://crt.sh/?id=307348195
Problem discovered: Country code is duplicated in state/province field instead of correct province value.
Resulting action: Revoke
Current validation protocols would have discovered the error (Yes/No): No

Certificate information: https://crt.sh/?id=1192513293
Problem discovered: Value of “Other” is set in state/province field.
Resulting action: Revoke
Current validation protocols would have discovered the error (Yes/No): Yes

Certificate information: https://crt.sh/?id=55028252
Problem discovered: Incorrect country code set for Singapore.
Resulting action: Revoke
Current validation protocols would have discovered the error (Yes/No): Yes

Certificate information: https://crt.sh/?id=415049678
Problem discovered: State/province set to “British Virgin Islands” when in fact it is part of the US Virgin Islands.
Resulting action: Revoke
Current validation protocols would have discovered the error (Yes/No): Yes

Certificate information: https://crt.sh/?id=43518785
Problem discovered: Miss-spelling: “Milipitas” in locality field instead of “Milpitas”.
Resulting action: Revoke
Current validation protocols would have discovered the error (Yes/No): Yes

Certificate information: https://crt.sh/?id=94451519
Problem discovered: Miss-spelling: “New Brittian” in locality field instead of “New Britain”.
Resulting action: Revoke
Current validation protocols would have discovered the error (Yes/No): Yes

Certificate information: https://crt.sh/?id=95010908
Problem discovered: Miss-spelling: “New Britian” in locality field instead of “New Britain”.
Resulting action: Revoke
Current validation protocols would have discovered the error (Yes/No): Yes

Certificate information: https://crt.sh/?id=1574432537
Problem discovered: Country code set incorrectly.
Resulting action: Revoke
Current validation protocols would have discovered the error (Yes/No): Yes

Certificate information: https://crt.sh/?id=1574429935
Problem discovered: Miss-spelling: “Wilmingtion” in locality field instead of “Wilmington”.
Resulting action: Revoke
Current validation protocols would have discovered the error (Yes/No): Yes

Certificate information: https://crt.sh/?id=1438081317
Problem discovered: County and locality were combined to make “Wilmington New Castle” in the locality field.
Resulting action: Revoke
Current validation protocols would have discovered the error (Yes/No): Yes

Certificate information: https://crt.sh/?id=307374384
Problem discovered: State/province field set incorrectly to “Florida” rather than “South Carolina”.
Resulting action: Revoke
Current validation protocols would have discovered the error (Yes/No): Yes

Certificate information: https://crt.sh/?id=987955782
Problem discovered: Miss-spelling: Locality field set to “Mirarmar” rather than “Miramar”.
Resulting action: Revoke
Current validation protocols would have discovered the error (Yes/No): Yes

Certificate information: https://crt.sh/?id=580486604
Problem discovered: Miss-spelling: Locality field set to “Tallahasee” rather than “Tallahassee.”
Resulting action: Revoke
Current validation protocols would have discovered the error (Yes/No): Yes

Certificate information: https://crt.sh/?id=41060164
Problem discovered: Miss-spelling: Locality field set to “Lake Zuric” rather than “Lake Zurich.”
Resulting action: Revoke
Current validation protocols would have discovered the error (Yes/No): Yes

Certificate information: https://crt.sh/?id=933570441
Problem discovered: State/province incorrectly set to “New Jersey” rather than “Pennsylvania.”
Resulting action: Revoke
Current validation protocols would have discovered the error (Yes/No): Yes

Certificate information: https://crt.sh/?id=31497339
Problem discovered: Miss-spelling: Locality field set to “Glensdie” rather than “Glenside.”
Resulting action: Revoke
Current validation protocols would have discovered the error (Yes/No): Yes

Flags: needinfo?(fcorday)

Frank: Thanks. This incident continues to be the best, most detailed, and most comprehensive report out of all CAs’ responses to this issue, and continues to help build a better understanding about the challenges faced and the design of effective controls.

I note that some of these may not be caught by the current controls, and I appreciate you’re re-evaluating for how to improve things. I think with the level of detail provided so far, it does not require urgent response, but do you have a sense on when you can expect to share an update? Are there additional steps that the community of users active in m.d.s.p. and/or the CA/Browser Forum assist in? And are there any temporary or short-lived changes being implemented as quality control, while those systemic changes are considered?

Flags: needinfo?(fcorday)
Whiteboard: [ca-compliance] - Next Update - 10-June 2019 → [ca-compliance]

We continue to analyze these findings and evaluate next steps. Please expect an update by the end of this week.

In analyzing our findings, we have discussed next steps in the efforts to catch these errors prior to issuance.

SecureTrust is in the process of creating a more focused approach for individual specialists. Where validation specialists will have less support tasks assigned while conducting validation. In conjunction with the already implemented 4 eyes principle, we expect to reduce the error rate.

Validating global localities present unique, locally known nuances which can be difficult to ascertain validity. Ryan mentioned ISO 3166-1 and ISO 3166-2. In conjunction with GeoNames, we are looking to include this data and make it available during the workflow for our validation specialists. This additional data will help ensure correct localities are determined and certificate information is accurate.

Additionally, we have discussed internally the question of what should be done when the data source shows a locality but no province information, for a country with provinces. Is it acceptable to leave out the province information in this case? It is not clear to us from the BRs what rule should be followed. Additional thoughts or ideas on best practices are welcome.

Flags: needinfo?(fcorday)

Additionally, we have discussed internally the question of what should be done when the data source shows a locality but no province information, for a country with provinces.

That's a good question. At the recent CA/Browser Forum F2F, members of both Asian and European CAs shared a bit more about the unique challenges they face with respect to locality information and unambiguous representation, which I think is related to that question. They provided several examples of areas where it was complex, and for which many answers 'may' be right. It might be useful to have a few examples here, to understand what rules might be generalized from this to provide better guidance?

Here are 3 examples:

  1. Data source shows an address of “244 King Street, ABERDEEN, AB24 5BW, GB”

From this address we can glean a country (GB) and locality (Aberdeen) but no province is specified. For province it seems one might reasonably put Scotland (as the next subdivision under the country code) or Aberdeen City (as the “Council area” within Scotland that contains Aberdeen). Our implementation of the GeoNames data set in our application will only show checkmarks for the combination of “GB/Scotland/Aberdeen”. Is it acceptable in this case to omit the province entirely since it is not specified in the data source?

  1. Data source shows an address of
    “Gruuss-Strooss 28
    9991, Weiswampach Luxembourg”

Luxembourg is contained in the canton of Clervaux, so that would seem to be a reasonable thing to specify as the province; however, Clervaux is not mentioned in the data source. Our GeoNames implementation expects “LU/Clervaux/Luxembourg”.

  1. Data source shows an address of “Airport House, CROYDON, CR0 0XZ, GB”

Similar to the first example, we could reasonably specify “England” or “Greater London” as the province, but neither is specified in the data source. Our GeoNames implementation expects “GB/England/Croydon” in this instance.

Additionally, we have discussed if “Greater London” is acceptable as a province if specified in the data source. It is unclear if it would be acceptable.

Essentially these questions come down to whether it is preferable to use a resource like GeoNames to fill in missing hierarchical components of an address or to adhere entirely to the components explicitly mentioned in the data source.

From all three examples, the BRs permit you to omit stateOrProvince in the presence of locality information. Given that your QGIS/QIIS omits the data, you haven't verified it according to 3.2.2.1, so I think omitting it from the cert is the 'correct' answer.

For what should be expected from the QGIS/QIIS:
Example 1: I would expect that, were it there, it'd contain "Scotland" (which aligns with the ISO 3166-2 subdivision for that level)
Example 2: I would expect that, were it there, it'd contain the canton of Clervaux, as the applicable ISO 3166-2 subdivision
Example 3: Ditto England, for the same reason as Example 1

The general answer is, I believe, that you need to

  1. Ensure your datasource satisfies all the necessary information in 3.2.2.1 of the BRGs, and by proxy, all of the necessary fields in 7.1.4.2.2.
  2. Enter that information directly

From what I take it, that's what you're doing, and your GeoNames system is alerting on the omission of the stateOrProvince when locality is present - which the BRs permit. I suspect you could change your comparison against GeoNames to ensure that, /if/ stateOrProvince is present, it matches, but otherwise, allow it to be permitted, provided that omission is compatible with 7.1.4.2.2(f)

Wayne: I'm pretty sure this is my new favorite incident report, in the level of comprehensive detail and discussion captured, the pre-existing controls, and their updates and modifications. This is definitely an example of Good Practice, but may be worth calling out in a future CA Communications about the level CAs should be aspiring to meet-or-exceed.

I defer this to you to see if there are any follow-ups, but I think that the comprehensive analysis, combined with the changes already completed, address this.

Flags: needinfo?(wthayer)

I've added this incident as an example of good practice at https://wiki.mozilla.org/CA/Responding_To_An_Incident#SecureTrust_.22Some-State.22_in_stateOrProvinceName

It appears that all questions have been answered and remediation is complete.

Status: ASSIGNED → RESOLVED
Closed: 2 months ago
Flags: needinfo?(wthayer)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.