Re: [TLS] TLS document status update

[Mike <mike-list at pobox.com>]

>>> draft-ietf-tls-rfc4366-bis
>>>    
>>>    The only technical issue is whether (and how) to mandate
>>>    including the hash in certificate_url message. Everyone except
>>>    Nelson has supported making the hash mandatory.
>>
>> The client doesn't necessarily have ANY copy of its own cert.
>> The proposed requirement that the client MUST include a hash of the
>> cert it does not have presents a new problem for such implementations.
> 
> Given that the client is about to ask the server to download a copy,
> I don't really see why there's a problem with the client getting
> a copy first and sending the hash over.

There is the problem of the client knowing when its certificate is
updated and that it should retrieve a new copy to recalculate the
hash.  It could keep track of its own validity period, but that
complicates things, and wouldn't work if the CA decides to reissue
a certificate early.

>> White-listing of hosts from which the server is willing to fetch those
>> client cert URLs effectively solves the other problems without
>> necessitating any mandatory hashes.
> 
> No, it doen't solve the substitution attack.

But how could the substitution attack even succeed?  You would need
to create a valid CA signature on the replacement certificate, which
should not be possible.

Mike
_______________________________________________
TLS mailing list
TLS at ietf.org
https://www.ietf.org/mailman/listinfo/tls