Re: CAs not compliant with CAA CP/CPS requirement

[Richard Moore via dev-security-policy]

On 22 September 2017 at 17:22, Rob Stradling 
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!
>>
> 
>
> That intermediate is https://crt.sh/?id=931
>
>
​Thanks Rob

Rich.​
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAs not compliant with CAA CP/CPS requirement

[Rob Stradling via dev-security-policy]

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!



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

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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAs not compliant with CAA CP/CPS requirement

[Richard Moore via dev-security-policy]

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

Re: CAs not compliant with CAA CP/CPS requirement

[Rob Stradling via dev-security-policy]

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=1593 and 
https://crt.sh/?Identity=%25=1575 for examples.


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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAs not compliant with CAA CP/CPS requirement

[richmoore44--- via dev-security-policy]

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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAs not compliant with CAA CP/CPS requirement

[Rob Stradling via dev-security-policy]

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:



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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAs not compliant with CAA CP/CPS requirement

[Gervase Markham via dev-security-policy]

On 15/09/17 09:38, richmoor...@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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAs not compliant with CAA CP/CPS requirement

[richmoore44--- via dev-security-policy]

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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAs not compliant with CAA CP/CPS requirement

[Liddle, Alan via dev-security-policy]

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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAs not compliant with CAA CP/CPS requirement

[identrust--- via dev-security-policy]

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

Updated IdenTrust TrustID CPS covering CAA record check can be found at 
https://secure.identrust.com/certificates/policy/ts/
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAs not compliant with CAA CP/CPS requirement

[info--- via dev-security-policy]

El viernes, 8 de septiembre de 2017, 21:25:20 (UTC+2), Andrew Ayer  escribió:
> 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

Izenpe has approbed and published the last version of CP, especifing the 
issuer domain name.
Best regards
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAs not compliant with CAA CP/CPS requirement

[Jeremy Rowley via dev-security-policy]

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  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 
> 
> 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
> 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAs not compliant with CAA CP/CPS requirement

[Gervase Markham via dev-security-policy]

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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAs not compliant with CAA CP/CPS requirement

[Kim Nguyen via dev-security-policy]

Am Freitag, 8. September 2017 21:25:20 UTC+2 schrieb 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

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAs not compliant with CAA CP/CPS requirement

[Jeremy Rowley via dev-security-policy]

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.

> On Sep 9, 2017, at 3:33 PM, Andrew Ayer via dev-security-policy 
>  wrote:
> 
> On Fri, 8 Sep 2017 15:22:52 -0700 (PDT)
> Andy Warner via dev-security-policy
>  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
> 
> ___
> 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

Re: CAs not compliant with CAA CP/CPS requirement

[Andrew Ayer via dev-security-policy]

On Fri, 8 Sep 2017 15:22:52 -0700 (PDT)
Andy Warner via dev-security-policy
 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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAs not compliant with CAA CP/CPS requirement

[identrust--- via dev-security-policy]

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

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
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAs not compliant with CAA CP/CPS requirement

[Andy Warner via dev-security-policy]

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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: CAs not compliant with CAA CP/CPS requirement

[Ryan Hurst via dev-security-policy]

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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: CAs not compliant with CAA CP/CPS requirement

[Ben Wilson via dev-security-policy]

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 
Cc: mozilla-dev-security-pol...@lists.mozilla.org; Andrew Ayer

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

RE: CAs not compliant with CAA CP/CPS requirement

[Jeremy Rowley via dev-security-policy]

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

Re: CAs not compliant with CAA CP/CPS requirement

[Peter Bowen via dev-security-policy]

On Fri, Sep 8, 2017 at 12:24 PM, 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:
>
> 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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAs not compliant with CAA CP/CPS requirement

[Jeremy Rowley via dev-security-policy]

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

> On Sep 8, 2017, at 1:25 PM, 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:
> 
> 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
> ___
> 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