On Friday, September 8, 2017 at 5:57:44 PM UTC-4, Jeremy Rowley wrote: > 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: [email protected] > 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 > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy
IdenTrust confirms CAA record check has been implemented for every SSL certificate prior to issuance, effective September 8, 2017. We will post updated CPS as soon as possible. Currently it is under PMA review and approval. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
