Closed Bug 1551372 Opened 6 years ago Closed 5 years ago

Telia: "Some-State" in stateOrProvinceName

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: wthayer, Assigned: pekka.lahtiharju)

Details

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

One Telia certificate containing a stateOrProvinceName of "Some-State" was 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.

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

Telia Incident Report

One old Telia certificate had stateOrProvinceName (ST) value: "Some-State" which means that it wasn't properly verified under BR Section 3.2.2.1

  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.
    Telia got report about invalid ST value on Saturday, May 11, 2019 7:36:23 PM (UTC+01:00) from Alex Cohn

  2. A timeline of the actions your CA took in response.
    Saturday, May 11, 2019: reported to Telia's non-urgent support address. Non-urgent means that it is handled on the next business day.
    Monday, May 13, 2019: Analysis of the issue by Telia Security Board. Result: Not critical problem but invalid according to BR. Thus decision was: "Should be revoked within 24 hours and MUST revoke a Certificate within 5 days". It was verified that the reported certificate was in use so Telia decided to replace the old one before revocation. It was verified that this was the only problem of this kind and this can't happen again because Telia stopped using ST attribute on December 2016.
    Wednesday, May 15, 2019: Problematic certificate was replaced by Customer and revoked by Telia CA

  3. 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.
    Analysis confirmed that this was the only one of the kind and this error can't be reproduced in current Telia systems because Telia stopped using ST attribute on December 2016. This particular certificate was created on May 2016.

  4. A summary of the problematic certificates.

  5. The complete certificate data for the problematic certificates.
    Only one of this kind exists: https://crt.sh/?id=20683991

  6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
    This certificate was issued three years ago during the time when ST was still used in Telia certificates. ST is useless attribute in Telia target countries (Nordic) and hard to verify so Telia decided to stop using ST already in December 2016. It often had Openssl default values that are illegal according to BR. At the enrollment (May 2016) this one was created using a process that was dependent on visual verification and this one invalid value slipped through the process. Lint mass scan that Telia run few months ago to all old Telia certificates didn't disclose this particular problem.

  7. 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.
    Telia has already resolved this like described above.

I'm not sure that this incident report provides sufficient assurance that the underlying issues have been resolved.

I believe Telia gets close to recognizing the underlying issue, when it speaks about "created using a process that was dependent on visual verification", but completely misses the mark by suggesting that linting should have caught this or that the discontinuation of ST somehow resolves this.

A deeper analysis would suggest there are flaws in reliance on visual verification, a discussion about where visual verification occurs, an explanation for how these systems functioned then and how they function now (if they've since been modified), and the steps Telia takes to ensure that validation is correctly done.

The failure of something "so obvious" calls into question all of the verifications done, because if that can slip through, what else has slipped through?

I think it's useful to look at the discussions from the related bugs:

To see some of these concerns raised and explained further. I hope that Telia will revisit its answers in light of this better understanding, both of the expectations, as well as how other CAs have stepped up with their systems and design.

Flags: needinfo?(pekka.lahtiharju)

Thanks for the feedback. I try to clarify why Telia thinks the issue has been permanently solved. In 2016 when Telia CA started to see ST with problematic values we created a solution that is absolutely certain. After that since December 2016 all ST values have been dropped in CA system so that only subject attributes CN,L,O,OU and C are included into our SSL certificates. We could drop it because ST is useless, not used, attribute in our target countries. If there aren't any ST values there can't be any illegal values! All included subject attributes are verified. L and C must be pre-approved for a Customer. Those must be in context with O value. CN is using domain validation methods from BR. O is validated against national company registry.

Flags: needinfo?(pekka.lahtiharju)

Did you review the other bugs I mentioned?

It would seem that the L, C, and O fields still run the risk of relying on human verification. Did I misunderstand? If so, can you please provide more detail, as demonstrated in those other bugs, so that we can build a complete understanding about the overall validation processes employeed and why ST was and is an abberation?

Flags: needinfo?(pekka.lahtiharju)

Yes, it's done by a human. Allowed L,C and O values are verified by our Registration Officer (RO) against national company/address register. In the SSL ordering system each new, not previously verified, L,O,C value combination causes the order to go to our RO queue. Then RO person has to manually accept the new combination. RO has to compare the value combination against one of the pre-defined registers. As an evidence the register name and the text from the register that includes the specific combination is copied to the system (for auditing). If RO accepts the new combination manually it is then approved for max 825 days for that Customer. The allowed values are tied to business ID code of the Customer.

ST is different because in Nordic countries it is not a normal component of an address. Thus lot of odd values were used before we started to drop it completely. It also couldn't be verified like the others because it is not listed in national company/address registers.

Flags: needinfo?(pekka.lahtiharju)

But the ST values that existed were verified by a human, right? I would imagine they would just as well be verified by the Registration Officer.

So I hope you can understand that "We no longer include ST" isn't sufficient to explaining the human factors that failed, or how the current system is robust against human failure. Something as obvious as "Some-State" does not seem like it at all should be factored in.

If the answer is that y'all didn't really validate ST, then I would expect that every certificate with an ST value be revoked.

At this present moment, I'm not very inspired by the response, especially to suggest that ST was receiving looser validation than other fields. That doesn't inspire a lot of trust in the CA. Can you confirm that you reviewed the other bugs and have no other modifications to the incident report to add?

Flags: needinfo?(pekka.lahtiharju)

We did full re-verification of ST values of our active SSL certificates that were created before Dec 2016 (when we still included ST to certificates). We also confirmed that there are no ST values after that. We found two more illegal values. One that had "FI" instead of "Finland" and one with value "Unknown". All other ST values in our active certificates were normal Nordic geolocations. Our ST process before Dec 2016 was error prone and thus total 3 invalid values documented in this bz were slipped through the process. We'll revoke the new ones also within 5 days.

Our current L/C validation process is better like I described in Comment 5 (and ST isn't any more used). Each allowed L/C value combination is separately added and documented.

The full details of certificates with the other illegal ST values are:
https://crt.sh/?id=307854532 (ST=FI)
and
'C=FI, ST=Unknown, L=Helsinki, O=Teliasonera Finland Oyj, OU=admin, CN=ux002jokka.ddc.teliasonera.net'
-----BEGIN CERTIFICATE-----
MIIGsTCCBJmgAwIBAgIQMghAeTYqptFnNPtFBgscSzANBgkqhkiG9w0BAQsFADBG
MQswCQYDVQQGEwJGSTEUMBIGA1UECgwLVGVsaWFTb25lcmExITAfBgNVBAMMGFRl
bGlhU29uZXJhIFNlcnZlciBDQSB2MjAeFw0xNjEwMDYxMTQyMzFaFw0xOTEwMDYx
MTQyMzFaMIGNMQswCQYDVQQGEwJGSTEQMA4GA1UECAwHVW5rbm93bjERMA8GA1UE
BwwISGVsc2lua2kxIDAeBgNVBAoMF1RlbGlhc29uZXJhIEZpbmxhbmQgT3lqMQ4w
DAYDVQQLDAVhZG1pbjEnMCUGA1UEAwwedXgwMDJqb2trYS5kZGMudGVsaWFzb25l
cmEubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnZ8xlEUgQHBX
IXfdZrEQj87UffLk0eXaCge/EmIEMhop+d/7nvia359Kf+V7XaE7NUmSLScPAk/0
NXgQWgn1b1vQp2Z+Cg5bXXJEvtGrK5XxNsT/hBZwQP+Fn74BhdsQB8pgUqbERE+j
IjsVgR6MWDMhwdXYurK5Ms6JWX+4am8VmCenV6UkzJac0iyQ2X/wrdUuO6hmasbG
A15P25frAkYKBXoBjtaci1blhUo8nhybB3CVXZgBJeMmev3EcsP1/eEL/m80IxYC
dHHs/ZVnLhLP9Xj6oQeBpp11xebI1cX1RRT1ySnxSKg22+B7AIvbesndAOqI85GC
hVvz2qK53wIDAQABo4ICUTCCAk0wgY0GCCsGAQUFBwEBBIGAMH4wLQYIKwYBBQUH
MAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBNBggrBgEFBQcw
AoZBaHR0cDovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlh
c29uZXJhc2VydmVyY2F2Mi5jZXIwHwYDVR0jBBgwFoAUL0k8KU/XByX5xozVZPVm
PRKDIpUwVAYDVR0gBE0wSzBJBgwrBgEEAYIPAgMBAQ8wOTA3BggrBgEFBQcCARYr
aHR0cDovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzCBygYD
VR0fBIHCMIG/MEKgQKA+hjxodHRwOi8vY3JsLTMudHJ1c3QudGVsaWFzb25lcmEu
Y29tL3RlbGlhc29uZXJhc2VydmVyY2F2Mi5jcmwweaB3oHWGc2xkYXA6Ly9jcmwt
MS50cnVzdC50ZWxpYXNvbmVyYS5jb20vY249VGVsaWFTb25lcmElMjBTZXJ2ZXIl
MjBDQSUyMHYyLG89VGVsaWFTb25lcmE/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlz
dDtiaW5hcnkwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMA4GA1UdDwEB
/wQEAwIEsDApBgNVHREEIjAggh51eDAwMmpva2thLmRkYy50ZWxpYXNvbmVyYS5u
ZXQwHQYDVR0OBBYEFLD70eZGRSCmQcuR8D/1ZqUtB27UMA0GCSqGSIb3DQEBCwUA
A4ICAQArAMiApXbe71nKEkMS/D2mBKvCksoiVUq1T1OuRRRsB5SpmCvuu1h0X5Pz
iBLkSkAXRzVnLrgM7Hrmei+o4cxNXB5bMiCIvcYKQdQF7/57oZW0Y37Sk612ginx
WZIVmDd1Co+n5dmwn3sRiZ6FRkfhZkSqgrvAx4cNShCvTxoI7Cob0IOwJIk0NJaE
16oVCQaI8KdAqb073Hnyd8ex8tM7kAiONRKDFNtraNxtaqXNsnBkVJJS0V5Kfui+
HXQZHDT0h7onT8kWCL7h7XA3i8Jfe7mjbSW30oBRJuc1BYX8u8cjnjtPNGCTwKOL
lcENgebS9JAqry6id/aH7cL+pguJ2tXje20YSgb1JTnxY4SJDlUqKUiMdcxzOAwA
omLK5k94BPYoUYto+nu4djgk8Ogv8J8pg73FA8vP9yHIat/f1xriqvv7lzUeroci
9zThA39iJBFQ6F/zCoxaovDPv91fmrsW4jsVN3iKD0LcuVDgQUUoLVoAMVq9F7kp
gPCWa1XaO1LDooXlSmsA2At2sWABirGFp3JhtK0abyZ61F8q/qgQFbSGR3ecGq1q
/cBorpN7hGacVsogBLYTcROjoMd+4M2p4iefQRIU7vZ4QFrvYSL3naaU5KGKVg8/
3Lnt7ujU83r1mMSyaiMEf/8fpYx4SGskb/4bpsbnv1wF1JFONw==
-----END CERTIFICATE-----

This problem can't happen again because we stopped adding attribute ST to our SSL certificates in December 2016.

Flags: needinfo?(pekka.lahtiharju)

https://crt.sh/?id=307854532 also demonstrates an invalid localityName.

Have you examined your certificates for invalid C or L values? How do you determine whether a given value for L is valid?

I'm also not sure I understand the complexity regarding validating state: ISO 3166-2 provides subdivisions for FI (19 maakunta are documented), or, in the context of other Nordic countries, 21 counties for Sweden and 18 counties+2 nordic regions for Norway.

The response doesn't give confidence here about the controls around other values, and to reiterate, simply no longer issuing for ST does not provide confidence in the other values, since they seemingly use the same human factor process, as noted in Comment #5.

Flags: needinfo?(pekka.lahtiharju)

Now we have re-validated also C and L values. Today C values are limited using small pre-defined set. Today L values are checked against pre-approved value set that has been approved with evidence by Registration Officer like documented in comment 5. Previously L checking was similar than visual ST checking and thus some values become invalid. But not any more. In re-check we found these new problems related to C and L:

C: There was one value "SV" instead of "SE". At the time it was detected and renewed but the invalid certificate forgotten to be revoked then. We revoked it now. Case was documented in our security documentation then. No other C problems existed. The problem certificate was https://crt.sh/?id=346615481. Current primary system prevents non-preapproved values like this: "ERROR: Request contains invalid country code "SV"". One side process still allows to order free two-char value but the Registration officer should accept the wrong value. Anyway, we'll soon improve that code to use only pre-approved codes there also to minimize the risk.

L: In addition to the value "FI" in comment 7 there was one case that had value "Default city" and one that had value "LahiTapiola" that is not a geolocation but a postal office name. All three invalid ones were created before the current process to prevent non-predefined values. All other L values were normal geolocations. We believe that our pre-approval method efficiently prevents all invalid values. There are no errors after it came to use. All invalid certificates are now revoked within 5 days. Details of the new ones are https://crt.sh/?id=351011048, https://crt.sh/?id=308413403

Summary: Now all our old SSL certificate ST, L and C values have been re-checked, 6 invalid ones are soon revoked and there are existing methods to prevent similar errors in the future. The primary prevention methods are mandatory pre-approval of L/C and the decision to not use ST at all.

The complexity regarding validating state:
Finish province or "maakunta" concept is very unclear and not actively used any more in Finland. And there are no public registers that could be used to validate if the given ST value is correct or not for a particular L value. Wikipedia: "Between 1634 and 2009, Finland was administered as several provinces....Its makeup was changed drastically in 1997, when the number of the provinces was reduced from twelve to six....The provinces were eventually abolished at the end of 2009." When we still let Customers to use ST the values were quite often rubbish. There is no sense that ST should be used in Finland. The important fact is that they can't be verified officially. You could use some historical borders but is that right? Normal way to uniquely provide address in Finland is like my company is registered in official (country level) registers:

Telia Finland Oyj = O
TEOLLISUUSKATU 15 = street
00510 HELSINKI = postalcode locality

No ST never used! If we must start using ST again we have to simply convert C value to its longer country name. I suppose that kind of ST usage is allowed (but useless)? For these reasons it is much better to avoid ST completely. I understand that in some other countries like USA, ST is useful or even mandatory addition. Note! Now politicians are again planning to create new province borders to Finland. But those will not be the traditional ones.

Flags: needinfo?(pekka.lahtiharju)

Wayne, I'll let you take over for this one. I don't think I'll be able to make much further progress.

From a CA incident handling standpoint, I do not consider this a good approach to incident handling. That the issues mentioned in Comment #8 were missed until I commented on them, and that Comment #9 showed additional issues, highlights to me that the CA did not have an adequate incident response process in place. A "good" CA would have examined all of those values - C, L, ST, O, and any other manual validated - to look for issues that share the same underlying flaw. I appreciate the view that the issue was "fixed" - but without performing that exercise, I think the faith in the issue being resolved was entirely unwarranted. I attempted to highlight this through reference to other bugs, in the hopes that the CA would step up, but it does not appear this was the case. I think all of this should be taken into consideration if Telia has issues in the future, but I defer to Wayne as to how he wants to handle this specific issue and whether he's satisfied with the response to date, which is that nothing will change because it's "already" been "fixed".

Flags: needinfo?(wthayer)

I agree that an extended incident review is always a good thing but related to this case I'd like to emphasize:

  1. Original bz was about "Some-state" value used in ST. The "Some-state" issue was immediately reviewed and fixed and validated by Telia that it can't happen again. Some others also understood the original case like that. I think it is a different case/review to examine all old L and C values or some extensions and their processes. Each attribute has fully unique process in Telia. Comment 4 then changed the scope of this bz.

  2. Current Telia processes prevent efficiently illegal values for ST, L and C. All found problems were related only to older processes, mostly in 2016. Especially our ST fix was absolute so there was no way that any later ST value could be invalid because there were no ST values.

  3. During the investigation of ST values Telia itself found that at least one L value was also illegal (two others found in investigation). Based on Telia initial discovery we started L investigation but it took some work hours. Also Ryan noticed the L error. Ryan extended this bz in Comment 4 to have also L and C to be included into this bz before our own L analysis was ready. So we created our L&C analysis to this bz. Without that we would have probably created a new bz.

I add 4 more certificates to this incident report. They had geolocation in L but the value was invalid because it was Country name "Finland". Those were:

https://crt.sh/?id=1207051560
https://crt.sh/?id=575868797
https://crt.sh/?id=511267457
https://crt.sh/?id=463246471

These were reported to us by our auditors on Thursday evening 23rd May. The last ones were revoked today before the 5-day limit. When we got the report we immediately evaluated these and reason and incident report was exactly the same than what we documented above. All were created before our pre-validation improvement to older L validation was implemented for all customers. No other illegal values like this existed. Pre-validation improvement was created in two phases in 2017 to order flow and in Nov 2018 to self-service flow. It took 3 months before we had defined allowed L values for all old self-service Customers. Thus after Feb 2019 there can't be these kind of errors in any L values.

Please explain why, in Comment #7, it was stated:

Now we have re-validated also C and L values.

While in Comment #12, it was stated:

These were reported to us by our auditors on Thursday evening 23rd May

Why did your auditor find things that you were not capable of finding yourselves?

The inability of a CA to discover additional certificates with the same problem is one of the most serious failings of a CA, because it calls in to question all of their incident reporting and evaluation. In order to address the concerns, the CA needs to carefully explain the process they used for evaluation, a clear and thoughtful explanation about why they failed to detect such issues, and what systemic improvements are being done going forward. Given that such an issue was flagged in Comment #8, this is deeply troubling, as trivial evaluation should have detected this.

Flags: needinfo?(pekka.lahtiharju)

I suppose the reason we didn't find those by ourselves was the scope we put to the first own review. We only verified that values were geolocations but we didn't verify those were correct kind of geolocations. Auditors were looking for all anomalies. Note that we stated clearly in comment 8 that we checked only that values were geolocations: "All other L values were normal geolocations". After audit finding we did a deeper review and checked that all other values were cities or counties and were otherwise correct.

The method we used in the first review was to collect all unique L values to a big list and then we visually evaluated that all values were known Nordic geolocations. For some values we had to use registers to be sure. In the process we could have found the value "Finland" as invalid but unfortunately we didn't because humans did this. Our original review was done only by one person. We think that was a mistake. In the future we'll assign at least two persons to do all kind of manual reviews. The deeper review we did after the discovery was done by another person.

In the deeper analysis we also found some L values that we couldn't decide if they are fully OK. We are in discussions with auditors what they think. Can you give your opinion on this: Certificate O value was a governmental office. The office was located in one city but the office's IT solutions were delegated to an other office located elsewhere. Certificate had the L value of the the IT office. Is that acceptable? There are several this kind of value in current L values.

Next steps we plan to do to improve our L validation is to automate company register search so that only officially registered L value can be pre-registered. We also plan to improve the current self-service flow so that each combination of O,L,C is tied. Now values are pre-approved separately which in theory could lead to invalid combination. Our order process is already using this kind of restricted combination between values.

Flags: needinfo?(pekka.lahtiharju)

With respect to the L value, the Baseline Requirements state
"If present, the subject:localityName field MUST contain the subject's locality information as verified under Section 3.2.2.1"

Section 3.2.2.1 states:

If the Subject Identity Information is to include the name or address of an organization, the CA SHALL verify the identity and address of the organization and that the address is the Applicant’s address of existence or operation. The CA SHALL verify the identity and address of the Applicant using documentation provided by, or through communication with, at least one of the following:

  1. A government agency in the jurisdiction of the Applicant’s legal creation, existence, or recognition;
  2. A third party database that is periodically updated and considered a Reliable Data Source;
  3. A site visit by the CA or a third party who is acting as an agent for the CA; or
  4. An Attestation Letter.

The CA MAY use the same documentation or communication described in 1 through 4 above to verify both the Applicant’s identity and address.
Alternatively, the CA MAY verify the address of the Applicant (but not the identity of the Applicant) using a utility bill, bank statement, credit card statement, government-issued tax document, or other form of identification that the CA determines to be reliable.

What documentation did you validate, and what did it contain? It does not matter what you can validate /now/, it matters what and how you validated /then/.

Flags: needinfo?(pekka.lahtiharju)

(In reply to pekka.lahtiharju from comment #14)

I suppose the reason we didn't find those by ourselves was the scope we put to the first own review. We only verified that values were geolocations but we didn't verify those were correct kind of geolocations. Auditors were looking for all anomalies. Note that we stated clearly in comment 8 that we checked only that values were geolocations: "All other L values were normal geolocations". After audit finding we did a deeper review and checked that all other values were cities or counties and were otherwise correct.

The method we used in the first review was to collect all unique L values to a big list and then we visually evaluated that all values were known Nordic geolocations. For some values we had to use registers to be sure. In the process we could have found the value "Finland" as invalid but unfortunately we didn't because humans did this. Our original review was done only by one person. We think that was a mistake. In the future we'll assign at least two persons to do all kind of manual reviews. The deeper review we did after the discovery was done by another person.

I want to highlight and draw attention to the fact that the original incident report ( Comment #1 ) noted that it was a process that relied on "visual verification", which comment #2 noted there are flaws in, and which Comment #6 highlighted the flaws in relying on human factors. The other bugs, mentioned in Comment #2, also noted underlying concerns with the validation process.

The issues noted in Comment #12 were exactly the kind of issues being referenced in Comment #2 - obviously invalid failures - and the response in Comment #14 indicates that Telia again relied on human verification, despite lengthy discussion in this issue about the flaws with relying on human verification. As noted in the related bugs in Comment #2, a minimum best practice involves multi-party verification for human factors, but that was omitted in the investigation, as Comment #14 confirms.

Hopefully this highlights, very clearly, why I'm so concerned, especially when I highlighted these risks in Comment #8. Nothing about the response, so far, inspires confidence in the information that has been validated or the investigation to date. The only upside is that I feel slightly better than your auditor detected this issue in Comment #12, but I suspect they were quite used to detecting non-compliance issues, given the extensive issues noted in the 2018 audit - https://support.trust.telia.com/download/CA/TeliaSSLBaselineReport2018.pdf . I look forward to the disclosure of the audit through 31 March 2019, which should be provided in the next month, as to what possible new issues they may have also discovered.

Regarding Telia's 2018 audits, refer to bug 1475115 in which Telia agreed to point-in-time audits to confirm that the issues reported in 2018 had been resolved. Those audits were supplied in January and are "clean".

Flags: needinfo?(wthayer)

"What documentation did you validate, and what did it contain?"
In L validation we first verify that we can find the related organization in national organization register. In the question the governmental agency was there. The register text is copy-pasted to our database as an evidence. Then we validate that the L value matches with the main location of the organization that is always included in the national organization register. In this case it wasn't the same one. If it would be same the L value is approved for that organization. In case of mismatch we validate that the location (and address) is some other address of the organization. For that we use public third party database. In this case we had found that L was same than in their IT agency address. My question was if in case of government agency it is a good practice to use L/address of another government agency that is known to handle IT issues of the other agency. Or should L be tied to the main agency only? We have a verified authorization letter from the main agency that the IT agency and their L is handling their certificate issues. Both agencies represent Finnish state but the IT agency location is not easily related to the main agency O by end-users. You have to know it or have authorization letter like we did.

Our L validation process before "pre-validation improvement with evidence" was error prone like we've seen but no problems have been found after we did the improvements in 2017,2018 and 02/2019. It is very unlikely that any trained Registration Officer would approve a value that isn't included in the copy-pasted evidence text. Or would approve L against rules. Anyway, we'll try to automate L issues further to full automation because human validation is always error prone. We believe automation is a better approach than multi-person validation. Older visually verified L values (without stored evidence) were now re-verified by two Registation officers. ST is certainly OK with us now when we removed it completely in Dec 2016.

Flags: needinfo?(pekka.lahtiharju)

I realize you’re seeking for guidance about misissuance, but I want to make sure it’s clear: the guidance for whether or not something is misissued or not, after the fact, requires the CA to make the affirmative case as to why they believe something complied with the BRs, as written. The response here does not provide sufficient information to determine whether or how Telia believes this complied with the BRs, and what has been provided seems systemically flawed and thus misissuance, but that may simply be a communication issue.

The CA is responsible for defending every piece of information placed in the certificate, and showing how and why the information present is permitted.

Pekka: what is the status of the improvements described in comment #14?

Flags: needinfo?(pekka.lahtiharju)

There were two improvements in Comment 14. The status/plan is this:

  1. Two persons will do all manual special reviews.
    This is in use now.

  2. Automatic company L check
    We divade this to countries like this: In Finland (most our L values are here) this has been pre-evaluated. We need a new commercial agreement with the registry owner. Plan is to implement automation after summer in 3Q/2019. In Sweden we need to do pre-evaluation. It will be done in 3Q/2019. If feasible the automation will be implemented in 4Q/2019. Other countries: Currently we allow companies of other countries only in special circumstancies, thus we continue using manual approval only. That will be done by dual person process after automations ready in 4Q/2019. Until that we continue our old process where a single Registration Officer may approve a L value if he/she simultaneously copy-paste registry evidence of the used value to our database. There has been no issues after we started this copy-paste-process. All approved L values are verified by an other person in montly reviews. ST values are not used.

Flags: needinfo?(pekka.lahtiharju)

Pekka: please update this bug as progress is made toward fully implementing the automatic company L check.

Whiteboard: [ca-compliance] → [ca-compliance] - Next Update - 01-October 2019

For inappropriate L we've been investigating new automation for L checking but that solution is delayed. The original idea was to use API against Finnish company register (ytj.fi) but in evaluation it was old fashioned and we didn't like that it would solve the problem only partly (only Finnish L values). That's why we decided to find a more generic API and we've found that in September. We get test account for commercial generic API next week. If tests are OK we are able to automate all O/L/C verifications related to all our target countries (currently Finland and Sweden). The first values will be auto-verified at the end of 2019. In 1Q2020 this should be in full usage. I will update the status later when the full automation is implemented. Until that we continue using the manual pre-approval of all L values. It has been very reliable process after it was implemented and no bad L values have been accepted since.

Whiteboard: [ca-compliance] - Next Update - 01-October 2019 → [ca-compliance]

Pekka: What is the status of this issue?

Also, please explain why Telia has not provided any updates on this issue for almost 4 months. Mozilla expects weekly updates (https://wiki.mozilla.org/CA/Responding_To_An_Incident#Keeping_Us_Informed).

Flags: needinfo?(pekka.lahtiharju)

I just added a new status of this to bug https://bugzilla.mozilla.org/show_bug.cgi?id=1565270.

In our opinion the automatic L verification solution is not a mandatory requirement but normal improvement task of Telia to make it even better. This incident report already includes explanation about our manual pre-approval solution that has prevented all L problems since it was introduced. We think that our current L pre-approval method is compatible with BR/Mozilla. Or do you disagree? That's why we haven't done weekly updates about all development but the plan was to update the status when the automation is ready like I've said in comment 23: "I will update the status later when the full automation is implemented". When that sentence was not rejected by you we kept the last comment (23) as agreed.

Flags: needinfo?(pekka.lahtiharju)

The automatic L verification is a remediation step proposed by Telia and an apparent improvement over the current process, so we want to track its implementation. Since no date has been provided, Mozilla's default expectation is that Telia provide weekly progress updates. If Telia provides a date for the planned implementation, and a Mozilla representative enters a "Next Update" date into the "whiteboard" field of this bug, then no updates are required until that date.

Pekka: please acknowledge that Telia will provide regular updates in this bug and optionally a date for implementation as described above.

Flags: needinfo?(pekka.lahtiharju)

Could you put 2020-02-28 to the next update field and I'll update the status then if we are in schedule or not.

Flags: needinfo?(pekka.lahtiharju)

Given that it's only a month away, and given the potential for further delays, it seems useful to ensure there's a weekly check-in to make sure things are progressing as expected.

Dear Pekka,
Could you please provide me with an update for the status on this issue?
Thanks,
Ben

Flags: needinfo?(pekka.lahtiharju)

The original and actual issue in this problem report was an invalid ST value. That has been permanently solved by removing ST completely from our certificates in 2016. Check my explanation in comment 9 where I explain why ST is not usable in our target countries.

In comment 4 Ryan extended this bz to handle also L problems but our L status has been continuously updated instead in bz https://bugzilla.mozilla.org/show_bug.cgi?id=1565270 (Telia: Qualified BR Audit Statement) because it was raised to our audit issue also. Maybe this "ST bz" could be closed and we continue following the L issue only in the other bz? There we have explained how we have built several new L processes and compensations and we are in the middle of process to automate Telia's L/address value handling.

Flags: needinfo?(pekka.lahtiharju)

I am inclined to close this bug (invalid ST values) so that we can focus on https://bugzilla.mozilla.org/show_bug.cgi?id=1565270 (Telia: Qualified BR Audit Statement).

Status: ASSIGNED → RESOLVED
Closed: 5 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.