Hi Andrew, I'm not certain how to update the previous Mozilla response with respect to CAA, but we added the following as authorized CAA records: Digicert.com *.digicert Digicert.net.jp Cybertrust.net.jp
I wasn't sure if adding a wildcard to the CAA record is kosher, but I didn't seem anything prohibiting use of wildcard characters in CAA records. We saw quite a few records similar to CAA.digiert.com during the testing and added this to the list. Jeremy Jeremy -----Original Message----- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Andrew Ayer via dev-security-policy Sent: Friday, September 8, 2017 1:25 PM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: CAs not compliant with CAA CP/CPS requirement The BRs state: "Effective as of 8 September 2017, section 4.2 of a CA's Certificate Policy and/or Certification Practice Statement (section 4.1 for CAs still conforming to RFC 2527) SHALL state the CA's policy or practice on processing CAA Records for Fully Qualified Domain Names; that policy shall be consistent with these Requirements. It shall clearly specify the set of Issuer Domain Names that the CA recognises in CAA 'issue' or 'issuewild' records as permitting it to issue. The CA SHALL log all actions taken, if any, consistent with its processing practice." Since it is now 8 September 2017, I decided to spot check the CP/CPSes of some CAs. At time of writing, the latest published CP/CPSes of the following CAs are not compliant with the above provision of the BRs: Amazon (https://www.amazontrust.com/repository/) - Does not check CAA Comodo (https://www.comodo.com/about/comodo-agreements.php) - Does not specify issuer domain names DigiCert (https://www.digicert.com/legal-repository/) - Does not specify issuer domain names, and processing is not compliant with BRs ("If a CAA record exists that does not list DigiCert as an authorized CA, DigiCert verifies that the applicant has authorized issuance, despite the CAA record.") Google Trust Services (https://pki.goog/) - Does not check CAA Identrust (https://secure.identrust.com/certificates/policy/ts/) - Does not check CAA Izenpe (http://www.izenpe.eus/s15-content/en/contenidos/informacion/descarga_certif icados/es_url/index.shtml) - Does not specify issuer domain names PROCERT (https://www.procert.net.ve/eng/ca.html) - No mention of CAA Symantec / GeoTrust (https://www.geotrust.com/resources/repository/legal/) - Does not specify issuer domain names Trustis (https://www.trustis.com/pki/trustis-ssl/standard/index.htm) - No mention of CAA Visa (http://www.visa.com/pki/) - Does not check CAA These CAs have compliant CP/CPSes: Entrust GlobalSign GoDaddy Let's Encrypt QuoVadis Trustwave It would be nice to hear confirmation from the non-compliant CAs that they really are checking CAA as required, and if so, why they overlooked the requirement to update their CP/CPS. Regards, Andrew _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
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
