ICANN CRL expired and not updated yet
All, We've had registrars come to us with complaints of inability to submit sunrise applications and it turns out that the ICANN CRL (http://crl.icann.org/tmch.crl) has expired, since there's been a number of seemingly unrelated issues over the past months our sunrises have been suffering. We are now waiting for an update while validating any SMD is failing. Best, David DAVID KRIZANIC Famous Four Media - Head of Technology 2nd Floor, Leisure Island Business Centre Ocean Village, Gibraltar Phone: +350 216 50006 Email: dkrizanic@famousfourmedia.com
Recently published https://tools.ietf.org/html/draft-lozano-tmch-func-spec-10 still lists the distribution point you mentioned. openssl crl -text -in tmch.crl Certificate Revocation List (CRL): Version 2 (0x1) Signature Algorithm: sha256WithRSAEncryption Issuer: /C=US/O=Internet Corporation for Assigned Names and Numbers/CN=ICANN Trademark Clearinghouse CA Last Update: Jul 24 00:00:00 2013 GMT => Next Update: Jul 23 23:59:59 2015 GMT CRL extensions: X509v3 Authority Key Identifier: keyid:5C:C0:F1:96:2C:CA:4C:5B:29:F1:40:74:D3:1B:36:3E:47:D4:6E:04 X509v3 CRL Number: 1 No Revoked Certificates. Signature Algorithm: sha256WithRSAEncryption 69:81:a2:0e:df:20:11:2f:9c:30:95:d4:f9:1a:8a:8b:22:6e: 7c:69:a7:c7:77:13:d3:50:44:94:41:97:22:d2:34:92:93:07: b9:b0:71:19:72:56:5f:ea:9c:02:6b:3d:9c:ba:77:4d:6f:e7: c2:a9:be:b2:cb:61:11:e4:6e:c1:c2:fa:a5:a8:9b:ad:53:bb: cb:2c:55:f1:93:ac:de:91:7b:f0:98:f1:6b:4f:42:28:86:8e: d0:c5:65:00:4b:82:68:d1:1a:c5:19:f2:be:4b:f4:38:c1:40: d1:c4:42:61:0c:5d:83:22:57:b9:88:77:6f:b4:f0:60:47:4f: 54:03:81:4c:3b:e1:15:cc:aa:c0:fc:07:37:85:06:a4:b2:34: 9c:31:53:3b:82:79:4e:f1:2b:8c:51:12:b9:ee:ae:c5:d9:a3: 57:ea:80:47:3f:cd:fa:a6:f4:08:c9:c7:67:eb:16:67:3f:69: 76:2f:bf:0d:77:cf:e6:4f:3c:fb:0f:01:e3:03:50:ef:cb:04: 21:99:24:07:f6:f0:b5:0a:9f:93:66:55:c5:17:85:89:31:a6: b8:cb:b8:bb:bb:78:cb:de:46:7e:cb:02:22:ba:2c:32:8b:e1: 25:cb:00:3e:a8:b9:83:c2:c7:cd:9f:2e:72:7c:a3:ed:ab:ea: d1:d4:1d:29 -----BEGIN X509 CRL----- MIIB8DCB2QIBATANBgkqhkiG9w0BAQsFADB2MQswCQYDVQQGEwJVUzE8MDoGA1UE ChMzSW50ZXJuZXQgQ29ycG9yYXRpb24gZm9yIEFzc2lnbmVkIE5hbWVzIGFuZCBO dW1iZXJzMSkwJwYDVQQDEyBJQ0FOTiBUcmFkZW1hcmsgQ2xlYXJpbmdob3VzZSBD QRcNMTMwNzI0MDAwMDAwWhcNMTUwNzIzMjM1OTU5WqAvMC0wHwYDVR0jBBgwFoAU XMDxlizKTFsp8UB00xs2PkfUbgQwCgYDVR0UBAMCAQEwDQYJKoZIhvcNAQELBQAD ggEBAGmBog7fIBEvnDCV1Pkaiosibnxpp8d3E9NQRJRBlyLSNJKTB7mwcRlyVl/q nAJrPZy6d01v58KpvrLLYRHkbsHC+qWom61Tu8ssVfGTrN6Re/CY8WtPQiiGjtDF ZQBLgmjRGsUZ8r5L9DjBQNHEQmEMXYMiV7mId2+08GBHT1QDgUw74RXMqsD8BzeF BqSyNJwxUzuCeU7xK4xRErnursXZo1fqgEc/zfqm9AjJx2frFmc/aXYvvw13z+ZP PPsPAeMDUO/LBCGZJAf28LUKn5NmVcUXhYkxprjLuLu7eMveRn7LAiK6LDKL4SXL AD6ouYPCx82fLnJ8o+2r6tHUHSk= -----END X509 CRL----- BTW, shouldn't this be made https ? Rubens
Em 27/07/2015, à(s) 12:29:000, David Krizanic <dkrizanic@famousfourmedia.com> escreveu:
All,
We've had registrars come to us with complaints of inability to submit sunrise applications and it turns out that the ICANN CRL (http://crl.icann.org/tmch.crl) has expired, since there's been a number of seemingly unrelated issues over the past months our sunrises have been suffering. We are now waiting for an update while validating any SMD is failing.
Best, David
DAVID KRIZANIC Famous Four Media - Head of Technology 2nd Floor, Leisure Island Business Centre Ocean Village, Gibraltar Phone: +350 216 50006 Email: dkrizanic@famousfourmedia.com
Rubens, Comments inline. On 7/27/15, 18:00, "gtld-tech-bounces@icann.org on behalf of Rubens Kuhl" <gtld-tech-bounces@icann.org on behalf of rubensk@nic.br> wrote:
BTW, shouldn't this be made https ?
RFC 5280 says: * When certificates include a cRLDistributionPoints extension with an https URI or similar scheme, circular dependencies can be introduced... * CAs SHOULD NOT include URIs that specify https, ldaps, or similar schemes in extensions... * Relying parties that choose to validate the server's certificate when obtaining information pointed to by an https URI in the cRLDistributionPoints, authorityInfoAccess, or subjectInfoAccess extensions MUST be prepared for the possibility that this will result in unbounded recursion.... While drafting draft-lozano-tmch-func-spec, I verified that the leading CAs use http in the cRLDistrubitionPoint, therefore security libraries may not be as well tested for https as for http in the extension. In addition, I did not know if the TMCH CA would be used for something else creating a circular dependency, therefore the decision was to follow the advice in RFC5280. Regards, Gustavo
Gustavo, I think that's fine. If I do: curl -O http://crl.icann.org/tmch.crl curl -O https://ca.icann.org/tmch.crt And then: openssl crl -text -in tmch.crl -CAfile tmch.crt I get: verify OK So even if the .crl download was tampered, it would fail to validate. Perhaps 5.2.3.2 should be updated to include such checking, or http://www.icann.org/en/resources/registries/tmch-requirements should include a normative reference specifying such ? Rubens
Em 28/07/2015, à(s) 16:16:000, Gustavo Lozano <gustavo.lozano@icann.org> escreveu:
Rubens,
Comments inline.
On 7/27/15, 18:00, "gtld-tech-bounces@icann.org on behalf of Rubens Kuhl" <gtld-tech-bounces@icann.org on behalf of rubensk@nic.br> wrote:
BTW, shouldn't this be made https ?
RFC 5280 says:
* When certificates include a cRLDistributionPoints extension with an https URI or similar scheme, circular dependencies can be introduced...
* CAs SHOULD NOT include URIs that specify https, ldaps, or similar schemes in extensions...
* Relying parties that choose to validate the server's certificate when obtaining information pointed to by an https URI in the cRLDistributionPoints, authorityInfoAccess, or subjectInfoAccess extensions MUST be prepared for the possibility that this will result in unbounded recursion....
While drafting draft-lozano-tmch-func-spec, I verified that the leading CAs use http in the cRLDistrubitionPoint, therefore security libraries may not be as well tested for https as for http in the extension. In addition, I did not know if the TMCH CA would be used for something else creating a circular dependency, therefore the decision was to follow the advice in RFC5280.
Regards, Gustavo
Rubens, This validation is covered in 5280 and draft-lozano-tmch-func-spec already references 5280. I will add a general advice that implementers must review 5280 in detail. The good news is that programming libraries implement 5280, that is the reason of why registries were having issues with the expired CRL. Regards, Gustavo On 7/28/15, 13:02, "Rubens Kuhl" <rubensk@nic.br> wrote:
Gustavo,
I think that's fine. If I do: curl -O http://crl.icann.org/tmch.crl curl -O https://ca.icann.org/tmch.crt
And then: openssl crl -text -in tmch.crl -CAfile tmch.crt
I get: verify OK
So even if the .crl download was tampered, it would fail to validate. Perhaps 5.2.3.2 should be updated to include such checking, or http://www.icann.org/en/resources/registries/tmch-requirements should include a normative reference specifying such ?
Rubens
Em 28/07/2015, à(s) 16:16:000, Gustavo Lozano <gustavo.lozano@icann.org> escreveu:
Rubens,
Comments inline.
On 7/27/15, 18:00, "gtld-tech-bounces@icann.org on behalf of Rubens Kuhl" <gtld-tech-bounces@icann.org on behalf of rubensk@nic.br> wrote:
BTW, shouldn't this be made https ?
RFC 5280 says:
* When certificates include a cRLDistributionPoints extension with an https URI or similar scheme, circular dependencies can be introduced...
* CAs SHOULD NOT include URIs that specify https, ldaps, or similar schemes in extensions...
* Relying parties that choose to validate the server's certificate when obtaining information pointed to by an https URI in the cRLDistributionPoints, authorityInfoAccess, or subjectInfoAccess extensions MUST be prepared for the possibility that this will result in unbounded recursion....
While drafting draft-lozano-tmch-func-spec, I verified that the leading CAs use http in the cRLDistrubitionPoint, therefore security libraries may not be as well tested for https as for http in the extension. In addition, I did not know if the TMCH CA would be used for something else creating a circular dependency, therefore the decision was to follow the advice in RFC5280.
Regards, Gustavo
participants (3)
-
David Krizanic -
Gustavo Lozano -
Rubens Kuhl