On Fri, Aug 3, 2018 at 3:51 AM pekka.lahtiharju--- via dev-security-policy < [email protected]> wrote:
> Indident reports: > > ERROR IN DV OID VALUE (deviation 4) > > How Telia became aware: > Telia got preliminary CA audit report on 25th June 2018. One of its BR > deviations was a finding that "17 Telia DV certificates had incorrectly > same OID value that was used for Telia OV certificates." > > Timeline of actions: > On the same day Telia fixed the OID value into DV profile so that error > won't happen again. Telia's opinion is that the incorrect OID value has no > impact on any common system but anyway Telia's plan is to revoke all > incorrect certificates ASAP and latest at September 2018. Customers need to > replace their original incorrect certificate with a new certificate > provided by Telia. Telia will update this bug until all incorrect > certificates are revoked. > > Summary and details of problematic certificates: > About ~300 of Telia DV certificates for a single pilot DV Customer > included OV OID 2.23.140.1.2.2 instead of DV OID 2.23.140.1.2.1. All > incorrect ones were enrolled between 20-Mar-2018 and 25-Jun-2018. All are > logged to CT and can be found using given dates and issuer "Telia Domain > Validation SSL CA v1". Certificates are also available in Telia CA database. > > Explanation about how and why the mistakes were made or bugs introduced, > and how they avoided detection until now: > Telia CA started to enroll DV SSL certificates in March 2018. Previously > all Telia's SSL certificates were OV SSL certificates. The new certificate > type was basically sub-type of Telia OV certificate but with fewer subject > fields. Its profile was copied from OV and then modified, tested and > piloted but still there was this error in the OID value that was undetected > because it won't have any effect anywhere and was commonly used by Telia > before. > > Steps to fix: > 1. fix the DV profile; DONE 25-Jun-2018, no errors occurred after that > 2. reproduce all incorrect certificates any provide those to Customer; > ONGOING, planned to finnish 30-Sep-2018 > 3. revoke all incorrect ones; ONGOING, planned to finnish 30-Sep-2018 > 4. Telia CA decided to improve its testing process to avoid similar errors > in the future; DONE 6-Jul-2018 > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > I think this highlights a rather significant and serious failure on Telia’s part when establishing a new certificate profile, and I don’t really see what concrete steps are being taken to remediate this or detect if it has happened in the past. 1) What process does Telia have in place for the review of profiles before being deployed to production? a) In light of this, how has that process changed? 2) What level of training is provided to those employees tasked with reviewing? a) Frequency of training b) Frequency of reevaluating the training materials? c) Independent assessments of those training materials? 3) These certificates materially misstate the level of validation provided by Telia, and the BRs require revocation within 24 hours. What steps has Telia taken to ensure this? I cannot understate how significant this failure is. At least one CA (Turktrust) through a failure of process to adequately review, configure, and test their certificate profiles, ended up releasing CA certificates into the wild to entities not qualified to receive them. The result of that ultimately ended with them exiting the CA business after finding it difficult to get their products universally trusted. While it may be argued by some that this is less severe, because it was “just” an OID, the demonstrated failure of that process calls into fundamental question the operations of Telia, and the confidence that a similar incident won’t occur. Part of the reason for these postmortems is to ensure that all CAs can learn and improve their best practices, through the mistakes others have made, so that the public can reliably trust such certificates. As such, there is an onus on Telia to demonstrate how this is different from past incidents, how they have learned and incorporated changes from those past incidents into their current processes, and where those improvements were deficient. While it sounds as if Telia did not take those lessons to heart when they occurred, as the CA community was still unaccustomed to learning from others mistakes, I think we as a community need to understand - in concrete and thorough detail - what the old processes were, why they failed, and how they’re being improved. My questions are merely an illustrative attempt to show some of how that might be done, but it is by no means exhaustive. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
