On Tue, Jan 12, 2016 at 1:30 PM, Fabrice Gautier <fabrice.gaut...@gmail.com> wrote:
> On Tue, Jan 12, 2016 at 1:13 PM, Eric Rescorla <e...@rtfm.com> wrote: > > > > > > On Tue, Jan 12, 2016 at 1:07 PM, Fabrice Gautier < > fabrice.gaut...@gmail.com> > > wrote: > >> > >> Hi, > >> > >> TLS 1.2 RFC says that a a client certificate MUST be compatible the > >> parameters specified in the Certificate Request: key type, > >> hash/signature algorithm and CA. > >> If a client does not have such a compatible cert, it MUST send an > >> empty Certificate message. > >> > >> In practice, what is a common behavior for Servers in the case where > >> the client sends an incompatible cert ? Treat it as if there was an > >> empty cert or an invalid cert ? Fail the handshake ? > >> > >> In practice, is it okay for a client to send a cert that may not be > >> compatible with the CertificateRequest, knowing that the client cert > >> might be selected by user action, or by an application layer above the > >> TLS layer, and knowing that on the server side, the client cert > >> verification might also be done a different layer, that may actually > >> have a different idea of what an acceptable cert is than the TLS layer > >> ? > > > > > > Would a fair rephrase of this be "How many servers advertise some set of > > requirements for CertificateRequest that is actually stricter than what > they > > would accept"? [0] > > Yes, that's another way to put it. > > Other related questions: > "Do TLS libraries act strictly on those requirements, or do they leave > it to the application layers?" > "How do TLS libraries/server applications act when such requirements > are not respected?" > I know NSS isn't used in a lot of servers, but at this point I believe that to a first order it enforces the same rules that it advertises. -Ekr > > > -Ekr > > > > [0] The case of "I advertise requirements that are looser than I would > > accept" > > is, I suspect, quite common. For instance, you might advertise an empty > > CA list. > > Right, > And I guess servers may also advertise empty hash/sig list, and empty > certificate_types list, although that would be violating the RFC. > > > > >> > >> Thanks > >> > >> -- Fabrice > >> > >> _______________________________________________ > >> TLS mailing list > >> TLS@ietf.org > >> https://www.ietf.org/mailman/listinfo/tls > > > > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
