CAs not compliant with CAA CP/CPS requirement

[Andrew Ayer]

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_certificados/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

[Jeremy Rowley]

Hey Andrew, we are checking CAA records at time of issuance. The CPS update should publish today.

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

[Peter Bowen]

On Fri, Sep 8, 2017 at 12:24 PM, Andrew Ayer via dev-security-policy

<dev-secur...@lists.mozilla.org> wrote:
> 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
>
>

> 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.

Amazon Trust Services is checking CAA prior to issuance of
certificates. We provided the domain list in our responses to the
last Mozilla communication and will be updating our externally
published policy and practice documentation to match shortly.

Thanks,
Peter

[Jeremy Rowley]

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=digice...@lists.mozilla
.org] On Behalf Of Andrew Ayer via dev-security-policy
Sent: Friday, September 8, 2017 1:25 PM
To: mozilla-dev-s...@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.

[Samuel Pinder]

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

[Ben Wilson]

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

[Ryan Hurst]

Responding from my personal account but I can confirm that Google Trust Services does check CAA and our policy was updated earlier today to reflect that.

[García Jimeno, Oscar]

Andrew, thanks for your information. We'll update our CP as soon as possible
Best regards
________________________________________

[Andy Warner]

Google Trust Services published updated CP & CPS versions earlier today covering CAA checking. I'd suggest checking all CAs again tomorrow. Given the range of timezones CA operational staffs operate across, some may not have had a chance to publish their updates yet.

In terms of the 'rush' I suspect many CAs have had language prepared to publish well in advance, but were holding off given the number of discussions in various forums about how to interpret some sections of the RFC and BRs. Many of those discussions continued until the last moment, so holding off to ensure published details aligned with community consensus was a reasonable approach.

[iden...@gmail.com]

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.

[Andrew Ayer]

On Fri, 8 Sep 2017 15:22:52 -0700 (PDT)
Andy Warner via dev-security-policy

<dev-secur...@lists.mozilla.org> wrote:

> Google Trust Services published updated CP & CPS versions earlier
> today covering CAA checking. I'd suggest checking all CAs again
> tomorrow. Given the range of timezones CA operational staffs operate
> across, some may not have had a chance to publish their updates yet.

At the time I checked, it was already September 8 in all timezones.

> In terms of the 'rush' I suspect many CAs have had language prepared
> to publish well in advance, but were holding off given the number of
> discussions in various forums about how to interpret some sections of
> the RFC and BRs. Many of those discussions continued until the last
> moment, so holding off to ensure published details aligned with
> community consensus was a reasonable approach.

Could you point to a discussion that would suggest that not checking CAA
at all (which is what many CAs' CP/CPSes said, including Google Trust
Services') was a reasonable interpretation of the BRs?

The published details need to align with what the CA is doing. In some
cases there may be ongoing discussions about how to interpret
requirements (though I believe in the case of CAA they had all
concluded well before the deadline), but that shouldn't stop a CA from
publishing how _they_ have interpreted the requirements, so that
relying parties know what the CA is doing.

Regards,
Andrew

[Andrew Ayer]

[Jeremy Rowley]

I would have checked Sept 9th as Sept 8th at midnight would be the last possible moment when the CPS could be updated and still be compliant.

[Jeremy Rowley]

[Kim Nguyen]

Dear all,
we can confirm that D-Trust is also performing CAA as required, the updated CA/CPS is currently under Review with our conformity assessment Body and will be published as soon as possible.
Regards, Kim

[Gervase Markham]

Hi Ben and Jeremy,

On 09/09/17 01:25, Ben Wilson wrote:
> 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

This reads:

"The Certification Authority CAA identifying domains for CAs within
DigiCert’s operational control are “digicert.com”, “digicert.ne.jp”,
"cybertrust.ne.jp”, and any domain containing those identifying domains
as suffixes (e.g. *.digicert.com)."

This latter part, while not perhaps being against the letter of the RFC,
is somewhat unhelpful for people who want to write software working with
CAA, because they now can't just load it with a per-CA list of valid
domain names, but have to post-process and stem the value in this case.
Are you certain you need that provision?

Gerv

[Jeremy Rowley]

Let me pull the data and share it with you. For some reason we saw a few sub domains right before the 8th. We added *.digicerts.com at the last minute until we had time to figure out why. I suspect it's being caused by documentation or a partner telling the customers the wrong thing. Once we track down the source, we can drop the wildcard.

> On Sep 11, 2017, at 5:09 AM, Gervase Markham <ge...@mozilla.org> wrote:
>
> Hi Ben and Jeremy,
>
>> On 09/09/17 01:25, Ben Wilson wrote:

>> 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
>

[sero...@gmail.com]

Izenpe has approved and published its CP last version, specifying issuer domain names. http://www.izenpe.eus/contenidos/informacion/doc_especifica/en_def/adjuntos/Izenpe_CP_website%20certificates_v1.2_(09-2017).pdf

Best regards

[iden...@gmail.com]

On Friday, September 8, 2017 at 3:25:20 PM UTC-4, Andrew Ayer wrote:

Updated IdenTrust TrustID CPS covering CAA record check can be found at https://secure.identrust.com/certificates/policy/ts/

[Steve Medin]

Our Policy Management Authority completed review of this and numerous other changes on September 8. The GeoTrust and Thawte CPS updated that day. The Symantec CP and CPS were updated the following day

Kind regards,
Steven Medin
PKI Policy Manager, Symantec Corporation

> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symant...@lists.mozilla.org] On Behalf Of
> Andrew Ayer via dev-security-policy
> Sent: Friday, September 08, 2017 3:25 PM
> To: mozilla-dev-s...@lists.mozilla.org

> Subject: [EXT] 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://clicktime.symantec.com/a/1/NmZ9sYttj7vKv6t18I35QRQ0FMHxkP
> NpP8WSJXL-eYo=?d=zu-
> OWyaepWo9aCiMKjwr_Mpk4cgBKZV809pQKiSOuM3HCRZv0YTyzv9-
> gtKYjE_ERhEPC5j03wspJwAD4li2UOxAGHhETJWCGtzKlfXxGQLL2HNwx5Xqij
> SYUlRc5C1CkmOZFwcAwAZvkRfXUWHpJfR33lZYK3iYtpD8t39Q7rqXydnBQ
> BL618AIpfNXYKPDaQJCqQlYMht4TC2jgbN3Rjgop8ONMaQi52cLQecwyH_S
> IHxrAuOmMYlc6mR9d9rhGxg_OtQjib6ZG8F1wAwDcLX7L3PuzzQ7HSw3PO
> RbIh6pk4zjCf82u_iftEUSCG3OQrrwYYOZkdGhTM592FLJ4VHMfK-
> 4eLpWYyI9-34iNLgu-RMpKedB_9X7prQsOgeQIvH-9jN6T4OyOQeh-
> o00JBr6kYjJXpNaIaUfWYo1GjkxmdtxeLK4brTdhhPD2BpC1Q9t_YpQBoP6s
> 1eRu6EjgQZ7KQ%3D%3D&u=https%3A%2F%2Fwww.amazontrust.com%
> 2Frepository%2F) - Does not check CAA
>
> Comodo
> (https://clicktime.symantec.com/a/1/7dk4IPNLHeQgWaoO8HJ5ksv2_spTr
> Mwd0vsOAxU735E=?d=zu-
> OWyaepWo9aCiMKjwr_Mpk4cgBKZV809pQKiSOuM3HCRZv0YTyzv9-
> gtKYjE_ERhEPC5j03wspJwAD4li2UOxAGHhETJWCGtzKlfXxGQLL2HNwx5Xqij
> SYUlRc5C1CkmOZFwcAwAZvkRfXUWHpJfR33lZYK3iYtpD8t39Q7rqXydnBQ
> BL618AIpfNXYKPDaQJCqQlYMht4TC2jgbN3Rjgop8ONMaQi52cLQecwyH_S
> IHxrAuOmMYlc6mR9d9rhGxg_OtQjib6ZG8F1wAwDcLX7L3PuzzQ7HSw3PO
> RbIh6pk4zjCf82u_iftEUSCG3OQrrwYYOZkdGhTM592FLJ4VHMfK-
> 4eLpWYyI9-34iNLgu-RMpKedB_9X7prQsOgeQIvH-9jN6T4OyOQeh-
> o00JBr6kYjJXpNaIaUfWYo1GjkxmdtxeLK4brTdhhPD2BpC1Q9t_YpQBoP6s
> 1eRu6EjgQZ7KQ%3D%3D&u=https%3A%2F%2Fwww.comodo.com%2Fab
> out%2Fcomodo-agreements.php) - Does not specify issuer domain names
>
> DigiCert
> (https://clicktime.symantec.com/a/1/xlVibpoycRtW78OkiI3usE639u_3QGd
> RehxP5QhPWPs=?d=zu-
> OWyaepWo9aCiMKjwr_Mpk4cgBKZV809pQKiSOuM3HCRZv0YTyzv9-
> gtKYjE_ERhEPC5j03wspJwAD4li2UOxAGHhETJWCGtzKlfXxGQLL2HNwx5Xqij
> SYUlRc5C1CkmOZFwcAwAZvkRfXUWHpJfR33lZYK3iYtpD8t39Q7rqXydnBQ
> BL618AIpfNXYKPDaQJCqQlYMht4TC2jgbN3Rjgop8ONMaQi52cLQecwyH_S
> IHxrAuOmMYlc6mR9d9rhGxg_OtQjib6ZG8F1wAwDcLX7L3PuzzQ7HSw3PO
> RbIh6pk4zjCf82u_iftEUSCG3OQrrwYYOZkdGhTM592FLJ4VHMfK-
> 4eLpWYyI9-34iNLgu-RMpKedB_9X7prQsOgeQIvH-9jN6T4OyOQeh-
> o00JBr6kYjJXpNaIaUfWYo1GjkxmdtxeLK4brTdhhPD2BpC1Q9t_YpQBoP6s
> 1eRu6EjgQZ7KQ%3D%3D&u=https%3A%2F%2Fwww.digicert.com%2Flega
> l-repository%2F) - 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://clicktime.symantec.com/a/1/FDXLCPoMms9u5GaLDCj2Qk1jqwAV
> PQjmvvu2wergGPg=?d=zu-
> OWyaepWo9aCiMKjwr_Mpk4cgBKZV809pQKiSOuM3HCRZv0YTyzv9-
> gtKYjE_ERhEPC5j03wspJwAD4li2UOxAGHhETJWCGtzKlfXxGQLL2HNwx5Xqij
> SYUlRc5C1CkmOZFwcAwAZvkRfXUWHpJfR33lZYK3iYtpD8t39Q7rqXydnBQ
> BL618AIpfNXYKPDaQJCqQlYMht4TC2jgbN3Rjgop8ONMaQi52cLQecwyH_S
> IHxrAuOmMYlc6mR9d9rhGxg_OtQjib6ZG8F1wAwDcLX7L3PuzzQ7HSw3PO
> RbIh6pk4zjCf82u_iftEUSCG3OQrrwYYOZkdGhTM592FLJ4VHMfK-
> 4eLpWYyI9-34iNLgu-RMpKedB_9X7prQsOgeQIvH-9jN6T4OyOQeh-
> o00JBr6kYjJXpNaIaUfWYo1GjkxmdtxeLK4brTdhhPD2BpC1Q9t_YpQBoP6s
> 1eRu6EjgQZ7KQ%3D%3D&u=https%3A%2F%2Fpki.goog%2F) - Does not
> check CAA
>
> Identrust (https://clicktime.symantec.com/a/1/-
> hcYCELwi2ejxzoC9hWCgVYMAFr-ZM4ljorelCgIGqk=?d=zu-
> OWyaepWo9aCiMKjwr_Mpk4cgBKZV809pQKiSOuM3HCRZv0YTyzv9-
> gtKYjE_ERhEPC5j03wspJwAD4li2UOxAGHhETJWCGtzKlfXxGQLL2HNwx5Xqij
> SYUlRc5C1CkmOZFwcAwAZvkRfXUWHpJfR33lZYK3iYtpD8t39Q7rqXydnBQ
> BL618AIpfNXYKPDaQJCqQlYMht4TC2jgbN3Rjgop8ONMaQi52cLQecwyH_S
> IHxrAuOmMYlc6mR9d9rhGxg_OtQjib6ZG8F1wAwDcLX7L3PuzzQ7HSw3PO
> RbIh6pk4zjCf82u_iftEUSCG3OQrrwYYOZkdGhTM592FLJ4VHMfK-
> 4eLpWYyI9-34iNLgu-RMpKedB_9X7prQsOgeQIvH-9jN6T4OyOQeh-
> o00JBr6kYjJXpNaIaUfWYo1GjkxmdtxeLK4brTdhhPD2BpC1Q9t_YpQBoP6s
> 1eRu6EjgQZ7KQ%3D%3D&u=https%3A%2F%2Fsecure.identrust.com%2Fc
> ertificates%2Fpolicy%2Fts%2F) - Does not check CAA
>
> Izenpe
> (https://clicktime.symantec.com/a/1/rYqUc_qRKY4blxAGv9xFxvih7S63pYA
> eLinge-EcDwc=?d=zu-
> OWyaepWo9aCiMKjwr_Mpk4cgBKZV809pQKiSOuM3HCRZv0YTyzv9-
> gtKYjE_ERhEPC5j03wspJwAD4li2UOxAGHhETJWCGtzKlfXxGQLL2HNwx5Xqij
> SYUlRc5C1CkmOZFwcAwAZvkRfXUWHpJfR33lZYK3iYtpD8t39Q7rqXydnBQ
> BL618AIpfNXYKPDaQJCqQlYMht4TC2jgbN3Rjgop8ONMaQi52cLQecwyH_S
> IHxrAuOmMYlc6mR9d9rhGxg_OtQjib6ZG8F1wAwDcLX7L3PuzzQ7HSw3PO
> RbIh6pk4zjCf82u_iftEUSCG3OQrrwYYOZkdGhTM592FLJ4VHMfK-
> 4eLpWYyI9-34iNLgu-RMpKedB_9X7prQsOgeQIvH-9jN6T4OyOQeh-
> o00JBr6kYjJXpNaIaUfWYo1GjkxmdtxeLK4brTdhhPD2BpC1Q9t_YpQBoP6s
> 1eRu6EjgQZ7KQ%3D%3D&u=http%3A%2F%2Fwww.izenpe.eus%2Fs15-
> content%2Fen%2Fcontenidos%2Finformacion%2Fdescarga_certificados%
> 2Fes_url%2Findex.shtml)

> - Does not specify issuer domain names
>
> PROCERT

> (https://clicktime.symantec.com/a/1/7xdOIzVW4boEbcHOOcsSGdvozW55
> uoAXAljTofZmAuI=?d=zu-
> OWyaepWo9aCiMKjwr_Mpk4cgBKZV809pQKiSOuM3HCRZv0YTyzv9-
> gtKYjE_ERhEPC5j03wspJwAD4li2UOxAGHhETJWCGtzKlfXxGQLL2HNwx5Xqij
> SYUlRc5C1CkmOZFwcAwAZvkRfXUWHpJfR33lZYK3iYtpD8t39Q7rqXydnBQ
> BL618AIpfNXYKPDaQJCqQlYMht4TC2jgbN3Rjgop8ONMaQi52cLQecwyH_S
> IHxrAuOmMYlc6mR9d9rhGxg_OtQjib6ZG8F1wAwDcLX7L3PuzzQ7HSw3PO
> RbIh6pk4zjCf82u_iftEUSCG3OQrrwYYOZkdGhTM592FLJ4VHMfK-
> 4eLpWYyI9-34iNLgu-RMpKedB_9X7prQsOgeQIvH-9jN6T4OyOQeh-
> o00JBr6kYjJXpNaIaUfWYo1GjkxmdtxeLK4brTdhhPD2BpC1Q9t_YpQBoP6s
> 1eRu6EjgQZ7KQ%3D%3D&u=https%3A%2F%2Fwww.procert.net.ve%2Fe
> ng%2Fca.html) - No mention of CAA

>
> Symantec / GeoTrust
> (https://www.geotrust.com/resources/repository/legal/)
> - Does not specify issuer domain names
>

> Trustis (https://clicktime.symantec.com/a/1/Vk89t9pNBDlkAVCPqcKrLK0-
> hPifAuLS3kKdvI0AR4g=?d=zu-
> OWyaepWo9aCiMKjwr_Mpk4cgBKZV809pQKiSOuM3HCRZv0YTyzv9-
> gtKYjE_ERhEPC5j03wspJwAD4li2UOxAGHhETJWCGtzKlfXxGQLL2HNwx5Xqij
> SYUlRc5C1CkmOZFwcAwAZvkRfXUWHpJfR33lZYK3iYtpD8t39Q7rqXydnBQ
> BL618AIpfNXYKPDaQJCqQlYMht4TC2jgbN3Rjgop8ONMaQi52cLQecwyH_S
> IHxrAuOmMYlc6mR9d9rhGxg_OtQjib6ZG8F1wAwDcLX7L3PuzzQ7HSw3PO
> RbIh6pk4zjCf82u_iftEUSCG3OQrrwYYOZkdGhTM592FLJ4VHMfK-
> 4eLpWYyI9-34iNLgu-RMpKedB_9X7prQsOgeQIvH-9jN6T4OyOQeh-
> o00JBr6kYjJXpNaIaUfWYo1GjkxmdtxeLK4brTdhhPD2BpC1Q9t_YpQBoP6s
> 1eRu6EjgQZ7KQ%3D%3D&u=https%3A%2F%2Fwww.trustis.com%2Fpki%
> 2Ftrustis-ssl%2Fstandard%2Findex.htm) - No mention of CAA
>
> Visa
> (https://clicktime.symantec.com/a/1/mvNLT7xKtkanc1YM0_r9UaxeWkwn
> 2kTSosynf1ug0W8=?d=zu-
> OWyaepWo9aCiMKjwr_Mpk4cgBKZV809pQKiSOuM3HCRZv0YTyzv9-
> gtKYjE_ERhEPC5j03wspJwAD4li2UOxAGHhETJWCGtzKlfXxGQLL2HNwx5Xqij
> SYUlRc5C1CkmOZFwcAwAZvkRfXUWHpJfR33lZYK3iYtpD8t39Q7rqXydnBQ
> BL618AIpfNXYKPDaQJCqQlYMht4TC2jgbN3Rjgop8ONMaQi52cLQecwyH_S
> IHxrAuOmMYlc6mR9d9rhGxg_OtQjib6ZG8F1wAwDcLX7L3PuzzQ7HSw3PO
> RbIh6pk4zjCf82u_iftEUSCG3OQrrwYYOZkdGhTM592FLJ4VHMfK-
> 4eLpWYyI9-34iNLgu-RMpKedB_9X7prQsOgeQIvH-9jN6T4OyOQeh-
> o00JBr6kYjJXpNaIaUfWYo1GjkxmdtxeLK4brTdhhPD2BpC1Q9t_YpQBoP6s
> 1eRu6EjgQZ7KQ%3D%3D&u=http%3A%2F%2Fwww.visa.com%2Fpki%2F)

> - 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-secur...@lists.mozilla.org

> https://clicktime.symantec.com/a/1/wZ_VElpAabP9B_4iDGV0AGxwpR0i4zx
> QTmS25XXGbgU=?d=zu-
> OWyaepWo9aCiMKjwr_Mpk4cgBKZV809pQKiSOuM3HCRZv0YTyzv9-
> gtKYjE_ERhEPC5j03wspJwAD4li2UOxAGHhETJWCGtzKlfXxGQLL2HNwx5Xqij
> SYUlRc5C1CkmOZFwcAwAZvkRfXUWHpJfR33lZYK3iYtpD8t39Q7rqXydnBQ
> BL618AIpfNXYKPDaQJCqQlYMht4TC2jgbN3Rjgop8ONMaQi52cLQecwyH_S
> IHxrAuOmMYlc6mR9d9rhGxg_OtQjib6ZG8F1wAwDcLX7L3PuzzQ7HSw3PO
> RbIh6pk4zjCf82u_iftEUSCG3OQrrwYYOZkdGhTM592FLJ4VHMfK-
> 4eLpWYyI9-34iNLgu-RMpKedB_9X7prQsOgeQIvH-9jN6T4OyOQeh-
> o00JBr6kYjJXpNaIaUfWYo1GjkxmdtxeLK4brTdhhPD2BpC1Q9t_YpQBoP6s
> 1eRu6EjgQZ7KQ%3D%3D&u=https%3A%2F%2Flists.mozilla.org%2Flistinfo
> %2Fdev-security-policy

[Liddle, Alan]

On Friday, September 8, 2017 at 3:25:20 PM UTC-4, Andrew Ayer wrote:

> 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_

> certificados/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

The Trustis policy referred to :-
https://www.trustis.com/pki/trustis-ssl/standard/index.htm

Is for a service that was retired some while ago. It is no longer issuing certificates.


Regards
Alan Liddle

[richm...@gmail.com]

I suspect many smaller CAs are non-compliant too, for example gandi's CPS hasn't changed since 2009 according to its changelog.

https://www.gandi.net/static/docs/en/gandi-certification-practice-statement.pdf

Cheers

Rich.

[Gervase Markham]

On 15/09/17 09:38, richm...@gmail.com wrote:
> I suspect many smaller CAs are non-compliant too, for example gandi's CPS hasn't changed since 2009 according to its changelog.
>
> https://www.gandi.net/static/docs/en/gandi-certification-practice-statement.pdf

Thank you for bringing this to my attention; I have emailed Comodo to
ask them what the situation is here.

Gerv

[Rob Stradling]

On 08/09/17 20:24, Andrew Ayer via dev-security-policy wrote:
> 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:

<snip>

> Comodo (https://www.comodo.com/about/comodo-agreements.php) - Does not
> specify issuer domain names

Andrew, thanks for bringing this to our attention.

Our CPS has now been updated.

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

[richm...@gmail.com]

On Thursday, September 21, 2017 at 10:13:56 AM UTC+1, Rob Stradling wrote:
> Our CPS has now been updated.

Will you be ensuring that CAs like Gandi who are chaining back to your roots also update their CPS?

Regards

Rich.

[Rob Stradling]

On 21/09/17 22:56, richmoore44--- via dev-security-policy wrote:
> On Thursday, September 21, 2017 at 10:13:56 AM UTC+1, Rob Stradling wrote:

>> Our CPS has now been updated.
>

> Will you be ensuring that CAs like Gandi who are chaining back to your roots also update their CPS?

Gandi are a managed CA. We are chasing them up and will get them to
link through to Comodo's legal repository.

https://www.gandi.net/static/docs/en/gandi-certification-practice-statement.pdf
is a deprecated document. A different CPS URL (that takes you to
Comodo's CPS) is being included in new certificates. See
https://crt.sh/?Identity=%25&iCAID=1593 and
https://crt.sh/?Identity=%25&iCAID=1575 for examples.

[Richard Moore]

I see, the one I saw in the wild was issued from the intermediate below and
linked to the Gandi document however it was from 2014. That said, I don't
see the intermediate in crt.sh though that could just be me failing to use
the site properly!

Cheers

Rich.

Certificate:
Data:
Version: 3 (0x2)
Serial Number:
5a:b6:1d:ac:1e:4d:a2:06:14:c7:55:3d:3d:a9:b2:dc
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=UT, L=Salt Lake City, O=The USERTRUST Network, OU=
http://www.usertrust.com, CN=UTN-USERFirst-Hardware
Validity
Not Before: Oct 23 00:00:00 2008 GMT
Not After : May 30 10:48:38 2020 GMT
Subject: C=FR, O=GANDI SAS, CN=Gandi Standard SSL CA
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:b6:54:3d:a5:db:0d:22:78:50:6a:5a:23:89:3f:
97:a1:d4:07:1a:a9:58:08:9b:a0:15:c3:32:b6:b7:
f1:e8:b9:a5:6f:ad:37:f6:6e:71:1b:b4:75:2d:48:
5e:9f:c6:15:aa:81:ef:e5:c4:88:95:8a:3a:6c:77:
cc:b5:cd:65:e4:67:e5:73:c9:50:52:94:c1:27:49:
3e:a0:6b:41:16:41:b6:94:99:41:ae:3e:cb:e2:06:
46:09:e9:4d:be:c9:4c:55:a9:18:7e:a6:df:6e:fd:
4a:b2:cc:6c:4e:d9:c8:50:15:93:b3:f2:e9:e3:c2:
6a:ad:3a:d5:fb:c3:79:50:9f:25:79:29:b2:47:64:
7c:20:3e:e2:08:4d:93:29:14:b6:34:6e:cf:71:46:
7e:76:10:f4:fd:6c:aa:01:d2:c2:06:de:92:83:cc:
58:90:2e:92:de:1e:65:b7:63:2f:3d:b2:eb:70:8c:
4c:e0:be:15:9d:de:c1:4d:56:f8:0b:c6:8e:07:b9:
5d:df:95:f0:7b:40:1f:1a:2c:d7:9c:2b:4b:76:f4:
59:f5:43:c1:2c:66:10:9e:9e:66:96:60:9d:1c:74:
1b:4e:18:5c:08:b0:6e:6c:ca:69:1a:02:e9:bb:ca:
78:ef:66:2e:e3:32:fd:41:5c:95:74:81:4d:f4:da:
fe:4b
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Authority Key Identifier:

keyid:A1:72:5F:26:1B:28:98:43:95:5D:07:37:D5:85:96:9D:4B:D2:C3:45

X509v3 Subject Key Identifier:
B6:A8:FF:A2:A8:2F:D0:A6:CD:4B:B1:68:F3:E7:50:10:31:A7:79:21
X509v3 Key Usage: critical
Certificate Sign, CRL Sign
X509v3 Basic Constraints: critical
CA:TRUE, pathlen:0
X509v3 Certificate Policies:
Policy: 1.3.6.1.4.1.6449.1.2.2.26

X509v3 CRL Distribution Points:

Full Name:
URI:http://crl.usertrust.com/UTN-USERFirst-Hardware.crl

Authority Information Access:
CA Issuers - URI:
http://crt.usertrust.com/UTNAddTrustServer_CA.crt
OCSP - URI:http://ocsp.usertrust.com

Signature Algorithm: sha1WithRSAEncryption
19:53:bf:03:3d:9b:e2:6b:5a:fd:ba:49:1f:4f:ec:e1:c6:82:
39:3c:d2:03:04:0f:ab:7b:3e:82:a9:85:10:1f:f4:de:32:af:
58:3f:ff:70:f3:30:1d:97:2d:4c:9a:e2:ec:0c:3e:14:2d:2f:
98:48:9d:ae:16:6a:ac:2d:42:aa:b5:64:a4:70:bb:eb:73:94:
7b:46:4c:e7:7a:14:76:5b:4c:1d:84:a1:20:74:1f:2e:4b:5c:
70:88:dc:bd:f7:19:3d:ed:59:0d:e2:3f:26:e2:9c:ac:a4:3c:
95:1c:f8:be:8c:03:ae:f0:e5:9c:4d:bc:c7:9b:58:00:bf:af:
ad:fa:37:6e:71:6d:18:34:0e:c1:ea:6a:f8:0d:df:69:54:56:
15:f2:28:b3:fe:a4:63:ec:c5:04:64:60:bb:fe:2a:f0:f4:87:
a1:b0:ae:bd:aa:e4:2f:e3:03:0b:2f:66:5f:85:a4:32:7b:46:
ed:25:0c:e7:f1:b7:e7:19:fd:60:ba:5f:87:77:de:98:07:96:
e4:5e:ea:63:7d:a8:de:55:da:61:5c:3c:90:83:43:04:07:3c:
dd:f3:f8:9f:06:52:0a:de:c7:b6:7b:8f:e1:11:f7:04:7a:35:
ff:6a:bc:5b:c7:50:49:08:70:6f:94:43:cd:9e:c7:70:f1:db:
d0:6d:da:8f
-----BEGIN CERTIFICATE-----
MIIEozCCA4ugAwIBAgIQWrYdrB5NogYUx1U9Pamy3DANBgkqhkiG9w0BAQUFADCB
lzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2Ug
Q2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExho
dHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xHzAdBgNVBAMTFlVUTi1VU0VSRmlyc3Qt
SGFyZHdhcmUwHhcNMDgxMDIzMDAwMDAwWhcNMjAwNTMwMTA0ODM4WjBBMQswCQYD
VQQGEwJGUjESMBAGA1UEChMJR0FOREkgU0FTMR4wHAYDVQQDExVHYW5kaSBTdGFu
ZGFyZCBTU0wgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC2VD2l
2w0ieFBqWiOJP5eh1AcaqVgIm6AVwzK2t/HouaVvrTf2bnEbtHUtSF6fxhWqge/l
xIiVijpsd8y1zWXkZ+VzyVBSlMEnST6ga0EWQbaUmUGuPsviBkYJ6U2+yUxVqRh+
pt9u/UqyzGxO2chQFZOz8unjwmqtOtX7w3lQnyV5KbJHZHwgPuIITZMpFLY0bs9x
Rn52EPT9bKoB0sIG3pKDzFiQLpLeHmW3Yy89sutwjEzgvhWd3sFNVvgLxo4HuV3f
lfB7QB8aLNecK0t29Fn1Q8EsZhCenmaWYJ0cdBtOGFwIsG5symkaAum7ynjvZi7j
Mv1BXJV0gU302v5LAgMBAAGjggE+MIIBOjAfBgNVHSMEGDAWgBShcl8mGyiYQ5Vd
BzfVhZadS9LDRTAdBgNVHQ4EFgQUtqj/oqgv0KbNS7Fo8+dQEDGneSEwDgYDVR0P
AQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwGAYDVR0gBBEwDzANBgsrBgEE
AbIxAQICGjBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5j
b20vVVROLVVTRVJGaXJzdC1IYXJkd2FyZS5jcmwwdAYIKwYBBQUHAQEEaDBmMD0G
CCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVROQWRkVHJ1c3RT
ZXJ2ZXJfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3Qu
Y29tMA0GCSqGSIb3DQEBBQUAA4IBAQAZU78DPZvia1r9ukkfT+zhxoI5PNIDBA+r
ez6CqYUQH/TeMq9YP/9w8zAdly1MmuLsDD4ULS+YSJ2uFmqsLUKqtWSkcLvrc5R7
RkznehR2W0wdhKEgdB8uS1xwiNy99xk97VkN4j8m4pyspDyVHPi+jAOu8OWcTbzH
m1gAv6+t+jducW0YNA7B6mr4Dd9pVFYV8iiz/qRj7MUEZGC7/irw9IehsK69quQv
4wMLL2ZfhaQye0btJQzn8bfnGf1gul+Hd96YB5bkXupjfajeVdphXDyQg0MEBzzd
8/ifBlIK3se2e4/hEfcEejX/arxbx1BJCHBvlEPNnsdw8dvQbdqP
-----END CERTIFICATE-----


On 22 September 2017 at 15:59, Rob Stradling <rob.st...@comodo.com>
wrote:

> On 21/09/17 22:56, richmoore44--- via dev-security-policy wrote:
>
>> On Thursday, September 21, 2017 at 10:13:56 AM UTC+1, Rob Stradling wrote:
>>

>>> Our CPS has now been updated.
>>>
>>

>> Will you be ensuring that CAs like Gandi who are chaining back to your
>> roots also update their CPS?
>>
>
> Gandi are a managed CA. We are chasing them up and will get them to link
> through to Comodo's legal repository.
>
> https://www.gandi.net/static/docs/en/gandi-certification-pra
> ctice-statement.pdf is a deprecated document. A different CPS URL (that
> takes you to Comodo's CPS) is being included in new certificates. See
> https://crt.sh/?Identity=%25&iCAID=1593 and https://crt.sh/?Identity=%25&i
> CAID=1575 for examples.
>

[Rob Stradling]

On 22/09/17 17:07, Richard Moore via dev-security-policy wrote:
> I see, the one I saw in the wild was issued from the intermediate below and
> linked to the Gandi document however it was from 2014. That said, I don't
> see the intermediate in crt.sh though that could just be me failing to use
> the site properly!

<snip>

That intermediate is https://crt.sh/?id=931

[Richard Moore]

On 22 September 2017 at 17:22, Rob Stradling <rob.st...@comodo.com>
wrote:

> On 22/09/17 17:07, Richard Moore via dev-security-policy wrote:
>
>> I see, the one I saw in the wild was issued from the intermediate below
>> and
>> linked to the Gandi document however it was from 2014. That said, I don't
>> see the intermediate in crt.sh though that could just be me failing to use
>> the site properly!
>>
> <snip>
>
> That intermediate is https://crt.sh/?id=931
>
>

​Thanks Rob

Rich.​