Those are typos. See section 4.2.1 of our CPS posted here: https://www.digicert.com/wp-content/uploads/2017/09/DigiCert_CPS_v412.pdf
-----Original Message----- From: dev-security-policy [mailto:dev-security-policy-bounces+ben=digicert....@lists.mozilla.org] On Behalf Of Samuel Pinder via dev-security-policy Sent: Friday, September 8, 2017 4:08 PM To: Jeremy Rowley <jeremy.row...@digicert.com> Cc: mozilla-dev-security-pol...@lists.mozilla.org; Andrew Ayer <a...@andrewayer.name> Subject: CAs not compliant with CAA CP/CPS requirement 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 <dev-security-policy@lists.mozilla.org> 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.m > ozilla .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 > > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ 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
