Re: Questions about startTLS.

[Jeff.Hodges@stanford.edu]

> Kristianne Palmer <Kristianne.Palmer@entrust.com> said:
>
> So the way I read the excerpts you provided
> (draft-ietf-tls-protocol-05.txt 7.4.6 and 7.2) the server can be
> configured to 
> a) not request a client certificate
> b) request a client certificate but not require that one be sent
> c) require that a client certificate be sent

The way I read tls-protocol-05, it specifies behavior (a) and (c). It'd seem 
to me that any reasonable implementation would have to allow for (b) occuring. 
Perhaps "not require that one be sent" could be restated as "behave gracefully 
in the event a client cert is not sent upon request", though it (the server), 
could certainly be (or ought to be able to be) configured to not perform the 
requested operation if it isn't able to authenticate the client.


> > So, pkix-ipki-part1-11 does NOT presently say that a cert issued for
> > some 
> > server hosting a service like LDAP must have a filled-in
> > subjectAltName with a 
> > type of dNSName. BUT, Schiller was, according to RLBob, saying in
> > Chicago, if 
> > the server's cert has a subjectAltName with a type of dNSName, then
> > the client 
> > MUST do the check.
>
> While many clients may not care about verifying the server's identity I
> think that it is necessary that we have a way that the client can do
> this reliably if  desired. 
>
> (***)
> Even if the SHOULD is upgraded to a MUST there are still problems with
> using the dNSName. The DNS name which is returned in a referral and
> used to contact the directory may not be the same as the one in the
> server's certificate -- if the directory lies on the other side of a
> firewall or proxy then the DNS name may change. This means that the
> client needs to be configured in advance to know what subject name to
> use to verify the identity of various servers. Definitely a high
> maintenance solution.
>
> Ideally I think we should be addressing this by trying to get the PKIX
> docs to require the dNSName to be present for servers, and encourage
> placing all of the names by which a server may be contacted in the
> subjectAltName, however, knowing all of these names may be impractical. 

Yes, this entire bit of ensuring matching between the server's DNS name 
wielded by the client and the DNS name (perhaps) present in the server's cert 
is problematic. I'm not sure how its going to work out. We probably need to 
get more operational experience before something practical will fall out.

> > But, we don't seem to have complete agreement among apps folks what
> > behavior 
> > should of apps protocols (and the apps built on top of them) ought to
> > be when, 
> > either..
> > 
> > 1. the subjectAltName with a type of dNSName does not match the dns
> > name for 
> > the service/server that the client is wielding, or..
> > 
> > 2. there is not a subjectAltName with a type of dNSName in the cert. 
> > 
> > This is something that perhaps apps folks should get together and
> > discuss 
> > (doing so on the ietf-apps-tls@imc.org list comes to mind).
>
> I'll try raising this issue on the list. Thanks.

Ok, go for it by all means. Thanks,

Jeff

(***) I'm assuming Kristianne wrote this paragraph even tho the quoting in her 
msg implicitly attributed it to me.