Thanks! I think this is more in line with the goal of these discussions - trying to learn, share, and disseminate best practices.
Here, the best practice is that, prior to any configuration, the CA should determine what the 'model' certificate should look like. This model certificate is, in effect, the technical equivalent of their certificate profile (e.g. 7.1 of a CA's CP/CPS) - indeed, it might even make sense for CAs to include their 'model certificates' as appendices in their CP/CPS, which helps ensure that the CP/CPS is updated whenever the profile is updated, but also ensures there's a technically verifiable examination of the profile. Going further, it might make sense for CAs to share their model certificates in advance, for community review and evaluation - although we're not quite there yet, it could potentially help identify or mitigate issues before hand, as well as help the CA ensure it's considered everything in the profile. Similarly, examining these model certificates through linting is another thing to consider, and to compare these against the test certificates' linted results. One thing to consider with model certificates is every configurable option you allow (e.g. key size) can create different model certificates, so as a testing procedure, you'll want to make sure you have model certificates for every configurable option, as well as consider test certificates for various permutations. For example, lets say you're introducing a new subject attribute to a certificate - as part of developing your model certificate, and your test certificate, you'll likely want to examine the various constraints on that field (e.g. length of field, acceptable characters), and run tests to make sure they produce the correct and expected results. Consider situations like "all whitespace" - does it do the expected thing (which could be to omit the field and allow issuance, or prevent issuance, etc). As far as training goes, it does sound like there is an opportunity for routine training regarding changes to the BRs (and relevant RFCs), to make sure the team constructing and reviewing profiles know what is and is not acceptable. While it's good to examine the policies for RAs, looking more holistically, you want to make sure the team tasked with creating and reviewing these models is given adequate support and training to know - and critically evaluate - what is or isn't permitted. On Wed, Aug 8, 2018 at 6:34 AM, pekka.lahtiharju--- via dev-security-policy <[email protected]> wrote: > Telia got a serious lesson with this incident that should not have > happened. Important detail also to know is that certificates were not > issued to wrong entities and issuing new certificates with wrong OID field > was prevented immediately. > > 1) Telia has a development process with multiple steps when doing a change > to SSL process. Some steps of the process include creating test > certificates in test and pre-production systems with documented change plan > and a review. Unfortunately test certificates were using test OID values so > that the problem couldn’t be detected at test side. Telia has analysed > reasons that caused this error. The main reason was not adequately > implemented testing. Test process didn't include certificate comparison > correctly against so-called model certificate. Telia has model certificates > for each certificate type that are used in comparison when any certificate > profile changes. This time there wasn't DV model certificate at all (except > in test system with test OID) because DV was a completely new certificate > type for Telia. OV model certificate (that had OV OID value) was used > instead by the reviewers. Telia should have created a DV model certificate > at first. In model certificate creation there are several eye pairs > including senior developers when accepting a new one. As a resolution Telia > has now enhanced processes so that it is mandatory to create model > certificate when completely new certificate type is created. > 2) We have concluded that the main reason for this problem was not a lack > of training but the incomplete test process and documentation. CA audits > have annually evaluated Telia training. Recommendations about improvements > have been documented into our internal audit reports if necessary. > Recommendations (or issues) from CA auditors are always added to Telia > Security Plan to improve Telia CA process continuously. Persons involved in > the review have got many different types of training that vary from general > security to deeper CA software related trainings. E.g. recently Feisty Duck > – The Best TLS training in the World and several trainings from our CA > Vendor. > a) CA software vendor trainings have been held quarterly. > b) Vendor keep the materials up to date and we update our own training > materials annually or when needed > c) CA audits have annually evaluated Telia internal trainings to > Registration officers > > 3) When this problem was discovered the issue was immediately escalated > according to Telia Incident process. One of the main steps of Telia > incident process is to evaluate the effect of the incident. This time the > evaluation result was that no immediate risk was caused as OID was correct > OV OID, all certificates with wrong OID fields were issued to known Telia > hosted service customers, even though the issue itself was confirmed > serious. Telia prevented the issue to repeat by fixing the profile on the > same day. As none of these certificates were issued to wrong entities Telia > decided to do the replacement/revoking in the organized way that overall > harm would be minimal by replacing these certificates with the customers. > > > Telia will revoke all incorrect certificates. Most of them have already > been revoked. Today ~100 is left to be revoked in co-operation with the > Customer. > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
