Re: [TLS] TLS document status update

[Eric Rescorla <ekr@xxxxxxxxxxxxxxxxxxxx>]

At Tue, 29 Apr 2008 09:24:24 -0700,
Mike wrote:
> 
> >>> 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.

Polling occasionally hardly seems like an insuperable barrier.


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

Why not? All you need is a CA which doesn't require technical
Proof of Possession of the private key.

-Ekr
_______________________________________________
TLS mailing list
TLS@xxxxxxxx
https://www.ietf.org/mailman/listinfo/tls