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

[[e-mail] (Martin Rex)]

Peter Gutmann wrote:
> Stephen Checkoway <[e-mail]> 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".

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