[gtld-tech] ICANN CRL expired and not updated yet

[Rubens Kuhl]

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 at icann.org> escreveu:
> 
> Rubens,
> 
> Comments inline.
> 
> On 7/27/15, 18:00, "gtld-tech-bounces at icann.org on behalf of Rubens Kuhl"
> <gtld-tech-bounces at icann.org on behalf of rubensk at 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
> 
> 
> 
> 
> 
> 
> 
>