Joe Orton wrote:
> I think it's better to aim to be ssh-like rather than browser-like...
>
> Indexing the cache by fingerprint is not particularly useful - the cache
> should really be indexed by (hostname, port) pair. On the first
> session, the user is prompted to accept <this> cert for <that> hostname,
> shown the fingerprint, expiry, and warned about hostname mismatches.
>
> For subsequent sessions, you just compare the presented cert against the
> cached cert for the hostname/port. It doesn't matter if the hostname in
> the subject DN is wrong, the user has already said the cert was valid
> first time round. (arguably expiry checking could be omitted too here)
This makes a lot of sense if you treat the cert as a ssh public key, but
since SSL certs are really different, I think it's the wrong way to go.
Subversion's ra_dav has a lot more in common with web browsers than ssh.
The public keys used in ssh are quite different from the certs used in
SSL/TLS. Perhaps the most obvious difference is the certificate
authorities handling. With SSL security, it is possible to verify the
authenticity of the remote host without user intervention. When that is
possible, the user should not be bothered.
The question is what to do when there is a problem. With the proposed
solution you choose to accept that the certificate is authentic, and
this is what web browsers do as well.
Accepting an incorrect hostname or an expired certificate is a different
matter. Consider what happens if you first accept a certificate and that
it at some time later expires. Surely you want a prompt at that time.
I'll answer David's email shortly regarding the ssl-ignore options which
is related to this.
/Tobias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 11 13:44:41 2003