Is there a typo here? Digicert.net.jp and Cybertrust.net.jp do not resolve, Japan tends to use the .NE.jp suffix, not .net.jp . Therefore shouldn't these be Digicert.ne.jp and Cybertrust.ne.jp ? These two do indeed resolve. On this subject, I am curious as to why it appears a lot of CA's do not tend to be publicizing information about CAA nor the issuer domains that can be used. There does appear to be a last-minute rush for compliance with CAA validation requirements, as well as confusion on how to interpret the regulations, but that's just my opinion. I very much support the idea in principle but adoption is probably being hampered by the lack of information on correct issuer domains. Sam
On Fri, Sep 8, 2017 at 10:57 PM, Jeremy Rowley via dev-security-policy <[email protected]> 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 > > _______________________________________________ > 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
