Subject: Re: [TLS] WG adoption: draft-nir-tls-rfc4492bis

From: Peter Gutmann <[email-masked]>
Date: Wed, 3 Dec 2014 07:40:36 +0000

Stephen Checkoway <[email-masked]> writes:

>That seems wrong. In practice, a client connects and says I'm willing to
>communicate using protocol parameters X, Y, and Z. If the server can't
>accommodate the client, it closes the connection. How is the signature
>algorithm any different from the cipher suite in this respect?

TLS conflates the algorithms used with TLS with the algorithms used for
certificates.  As others have pointed out, a server has control over the
algorithms used for TLS, but no control over what's used in certificates.
Those are dictated by the CA.  So it's OK for the client to say "I would like
one of the above for TLS", but it has no business saying "I expect your CA,
and every CA above it up to the root, to also use the algorithm(s) I've asked
for".

Peter.

---

From: Jeffrey Walton <[email-masked]>
Date: Wed, 3 Dec 2014 11:49:52 -0500

On Wed, Dec 3, 2014 at 2:40 AM, Peter Gutmann <[email-masked]> wrote:
> Those are dictated by the CA...

Wouldn't that put certificate parameters (like signing algorithms)
under the purview of PKIX WG?

---

From: [email-masked] (Martin Rex)
Date: Fri, 19 Dec 2014 18:10:48 +0100 (CET)

> and every CA above it up to the root, to also use the algorithm(s) I've asked

I hadn't previously realized that the TLS WG has _already_ retroactively
deprecated the relevant paragraph about the algorithm that was used to
sign the server certificate from rfc4492 (rfc5246,Appendix A.7,3rd paragraph)

https://tools.ietf.org/html/rfc5246#appendix-A.7

   A.7.  Changes to RFC 4492

 [...]

   As described in Sections 7.4.2 and 7.4.6, the restrictions on the
   signature algorithms used to sign certificates are no longer tied to
   the cipher suite (when used by the server) or the
   ClientCertificateType (when used by the client).  Thus, the
   restrictions on the algorithm used to sign certificates specified in
   Sections 2 and 3 of RFC 4492 are also relaxed.  As in this document,
   the restrictions on the keys in the end-entity certificate remain.

-Martin