Status Update: We are still scanning our database to discover all certificates containing incorrect data. So far, the count is at 1510. The issues fall into two categories: 1) a failure to properly convey that BRs prohibit inclusion of meta data (BR 7.1.4.2.2.j) and 2) auto-population of data in the order that validation forgot to clear before issuing the certificate.
On the training issue, the validation team inserted characters like "-", "." or other similar information in approximately 1000 certificates. This information asserted that the field was not applicable. The remaining 500 included auto-population data. The auto-population took three formats (such as a number representing the country code) depending on the customer's location and access to our certificate management platform. Interestingly, the validation database contains the correct documentation. However, we failed to properly update the certificate information to match the validated data. Since Mike reported the issue, we've patched our system to prevent meta-data and made substantial improvements to the validation process. These improvements help identify mis-matches between validation information and certificate data. We also started the revocation process for the 500 certificates containing meta-data. However, we wanted to ask about the 1000 certificates containing data indicating the field was not applicable. We recognize these were not properly issued, but I am curious whether revocation is required by Mozilla in this case. Should we start revoking those certificates as well despite the certificate information clearly not indicating a state/province? My thought is yes because of BR 4.9.1.1: 9. 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; I don't think #10 applies because the information is accurate - the field is not applicable: 10. The CA determines that any of the information appearing in the Certificate is inaccurate or misleading; Thoughts? Jeremy -----Original Message----- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert....@lists.mozilla.org] On Behalf Of Jeremy Rowley via dev-security-policy Sent: Thursday, April 20, 2017 6:11 PM To: mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org> Subject: RE: CA Validation quality is failing Thanks Mike for bringing this up. We’ve looked into it and have an initial report to share. After receiving the email on the Mozilla list, we investigated the identified certificates and discovered a couple of very related issues in our process that led to certificates with bad info: 1. As Jakob pointed out, part of the issue was that our intake form required a state if US was selected. As country is the last requested field, the state only became optional after the customer completed the rest of the form. This led to a lot of customers submitting bad data. 2. We have an old tool that generates information based on a customer’s location. This tool helps customers create CSRs and complete certificate requests. The tool inserts bad data into some fields if the field is left blank by the customer. The result was customers using this tool outside of the US had numbers included in the state field. 3. There was a gap in our validation process. This is the more important issue as the validation process should have caught the bad data inserted by the other two issues. Although we are obtaining validation documents from the appropriate government entity, the data submitted via the tool or intake form was not properly being updated with retrieved validated information. The end result was that the bad CSR data was submitted for signing instead of the data listed on the government document. This was a personnel problem, not a failure in our system as the validation staff was not appropriately updating the required signing fields. So far, we have identified approximately 600 certificates that have the wrong state, zip, or locality. This is just a measurement of the problem scope and not the exact number as we are still reviewing are certificate database using a mapping API to determine whether the address exists. We expect the search to have a lot of false positives initially but provide a maximum scope of the problem. In parallel, we are contacting each customer with a non-compliant certificate, replacing the certificate, and revoking the certificate. All mis-matched certificates are being uploaded to the Google and DigiCert CT logs. To fix our process, we are planning the following: a. We are immediately deprecating our geolocation tool and updating our intake form to help reduce the amount of bad data. b. We are updating our validation process to flag the differences in validation data and customer-provided data. c. We are providing our validation staff with an extra mandatory tool that checks address information for accuracy. Part of our process going forward will be to use a separate source to verify that the city/state are actually in the country specified by the certificate. 4. Finally, we are implementing additional restrictions on our CA that prohibit signing of bad locality/state/zip information. We have a tool internally named “cert shield”. This tool is similar to CAB lint and that checks information submitted to the CA for compliance with the BRs and EV Guidelines. The rule set in cert shield is being updated to include additional restrictions designed to catch issues like numeric states and cities. I’ll report back more on our progress next week with additional ideas. Please let me know if you have any questions. Jeremy -----Original Message----- From: Jeremy Rowley Sent: Wednesday, April 19, 2017 7:49 PM To: Jeremy Rowley <jeremy.row...@digicert.com>; r...@sleevi.com; Mike vd Ent <pasarellaph...@gmail.com> Cc: Ben Wilson <ben.wil...@digicert.com>; mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org> Subject: RE: CA Validation quality is failing FYI - still looking into this. I should have a report tomorrow. -----Original Message----- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert....@lists.mozilla.org] On Behalf Of Jeremy Rowley via dev-security-policy Sent: Wednesday, April 19, 2017 2:27 PM To: r...@sleevi.com; Mike vd Ent <pasarellaph...@gmail.com> Cc: Ben Wilson <ben.wil...@digicert.com>; mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org> Subject: RE: CA Validation quality is failing I’m looking into it right now. I’ll report back shortly. Jeremy From: Ryan Sleevi [mailto:r...@sleevi.com] Sent: Wednesday, April 19, 2017 2:25 PM To: Mike vd Ent <pasarellaph...@gmail.com> Cc: mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org>; Jeremy Rowley <jeremy.row...@digicert.com>; Ben Wilson <ben.wil...@digicert.com> Subject: Re: CA Validation quality is failing On Wed, Apr 19, 2017 at 3:47 PM, Mike vd Ent via dev-security-policy <dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> > wrote: Ryan, My answers on the particular issues are stated inline. But the thing I want to address is how could (in this case Digicert) validate such data and issues certificates? I am investigation more of them and afraid even linked company names or registration numbers could be false. Shouldn't those certificates be revoked? You are correct that it appears these certificates should not have issued. Hopefully Jeremy and Ben from DigiCert can comment on this thread ( https://groups.google.com/d/msg/mozilla.dev.security.policy/DgeLqKMzIds/ig8UmHT2DwAJ for the archive) with details about the issues and the steps taken.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
