Subject: [TLS] Server behavior when client certificate does not match the request ?

From: Fabrice Gautier <[email-masked]>
Date: Tue, 12 Jan 2016 13:07:16 -0800

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
?

Thanks

-- Fabrice

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 12 Jan 2016 13:13:52 -0800

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

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

> Thanks
>
> -- Fabrice
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Fabrice Gautier <[email-masked]>
Date: Tue, 12 Jan 2016 13:30:47 -0800

> requirements for CertificateRequest that is actually stricter than what they

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?"

> is, I suspect, quite common. For instance, you might advertise an empty

Right,
And I guess servers may also advertise empty hash/sig list, and empty
certificate_types list, although that would be violating the RFC.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 12 Jan 2016 13:41:59 -0800

> "How do TLS libraries/server applications act when such requirements

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

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 12 Jan 2016 23:11:12 +0000

Fabrice Gautier <[email-masked]> writes:

>"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?"

This has already been discussed in the past, it's not up to TLS to constrain
what a CA can do, and more to the point if you've paid a CA a small fortune
for a cert you don't want some TLS implementation to reject it because of some
minor disagreement over what colour the cert frame is painted.

Redde Caesari quae sunt Caesaris, the PKI code decides whether a cert chain is
acceptable or not, not the TLS code.  

Which is exactly what my code does.

Peter.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 12 Jan 2016 23:53:32 +0000

> empty cert or an invalid cert ? Fail the handshake ?

With TLS 1.0/1.1, in which the server cannot indicate support for
a list signature algorithms, the logical conclusion is that the
client MUST NOT use a public key algorithm that is different from
the agreed cipher-suite.  It can accomplish this by only advertising
cipher suites compatible with the client certificate it will (can
be tricky if it has more than one).

With TLS 1.0/1.1 there is no reason to expect that the server will
understand signatures made with a public key algorithm other than
the one used in the the server certificate (which agrees with the
ciphersuite in the server HELLO).

With TLS 1.2, where the server does send a supported_signature_algorithms
list, clients that use signatures other than those listed should
expect to run into servers that reject this with a fatal alert.
The server's TLS stack (not its X.509 chain verification code) has
to check the signature in the client's "Certifice Verify" message.

The server's list of CA's on the other hand is largely a hint, and
clients often just ignore it entirely.  If the server can verify
the certificate, it generally does not matter whether the CA was
listed in the certificate request message or not.  For many servers
client certificates are optional anyway, or they verify them without
reference to any particular PKI.

-- 
	Viktor.

---

From: Fabrice Gautier <[email-masked]>
Date: Tue, 12 Jan 2016 16:13:42 -0800

> ciphersuite in the server HELLO).

Hum, the client certificate type would theoretically defined by the
"certificate_types" list in the CertificateRequest message, not the
cipher suite.

So you can have RSA client cert with EC ciphersuites and server certs
and vice-versa, even in TLS 1.0/1.1

> to check the signature in the client's "Certifice Verify" message.

Which does raise another interesting question when certificate_types
and supported_signature_algorithms conflicts.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 12 Jan 2016 16:20:00 -0800

> and supported_signature_algorithms conflicts.

It's the intersection:

https://tools.ietf.org/html/rfc5246#section-7.4.4

   -  Any certificates provided by the client MUST be signed using a
      hash/signature algorithm pair found in
      supported_signature_algorithms.

   -  The end-entity certificate provided by the client MUST contain a
      key that is compatible with certificate_types.  If the key is a
      signature key, it MUST be usable with some hash/signature
      algorithm pair in supported_signature_algorithms.

However, it's confusing, and so we removed certificate_types in 1.3.

-Ekr