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

[Gustavo Lozano]

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 at 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 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
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5045 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gtld-tech/attachments/20150728/2a9a3724/smime.p7s>