There isn't anything in our CPS directly. However, we state that we follow the baseline requirements in the CPS. The baseline requirements give a profile for the state field. We weren't sure this was strictly followed.
We finished our validation review over the weekend. There are about 3000 older certs with information indicating a field was not applicable (such as a "-", "N/A", etc). On top of this, we issued about 1000 certificates with mismatched validation information. The mismatched information can be divided into about 850 certificates with numbers in the state field. These numbers indicate a location code that was provided by the auto-populator. The remaining 150 are certificates with "Select", a state, or a postal code improperly included in the certificate. The root issue was a combination of the auto-populator inserting incorrect data into the cert request and our validation staff not properly updating the certificate information after completing the validation process. Based on these results, we propose the following remediation plan: 1. We already removed the auto-populator from our CSR and certificate order generators. 2. We already blocked this information on the CA side from included in signed SSL/TLS objects. 3. We will revoke the 150 certificates with mismatched information. 4. We plan to let the remaining 3850 expire normally but will correct the certificate for all future orders (including rekeys). Is this an acceptable plan? We are proposing not revoking the 3850 certificates because the information isn't misleading, the information is accurate, and there isn't a risk posed to Mozilla's users by inclusion of the numeric location code or not applicable indicator. Any thoughts? Jeremy -----Original Message----- From: Gervase Markham [mailto:g...@mozilla.org] Sent: Thursday, April 27, 2017 2:41 AM To: Jeremy Rowley <jeremy.row...@digicert.com>; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: CA Validation quality is failing On 27/04/17 00:16, Jeremy Rowley wrote: > 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; What line in your CP or CPS is violated by these certs? > 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; I agree that a "." or "-" instead of a field being empty is not inaccurate or misleading. However, #10 also says "the CA determines", so it's your view, not mine, which is most relevant :-) Gerv
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
