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

[Stephen Checkoway <[e-mail]>]

On Nov 27, 2014, at 3:13 AM, Yoav Nir <[e-mail]> wrote:

> Seeing as the 18th has come and gone, can I take the near silence as confirmation that I can resubmit as a WG draft?

I support adopting this draft.

Maybe this isn't the right time to ask, but I think I'm misunderstanding a part of it.

   Note that while the ECDH_ECDSA, ECDHE_ECDSA, ECDH_RSA, and ECDHE_RSA
   key exchange algorithms require the server's certificate to be signed
   with a particular signature scheme, this specification (following the
   similar cases of DH_DSS, DHE_DSS, DH_RSA, and DHE_RSA in the TLS base
   documents) does not impose restrictions on signature schemes used
   elsewhere in the certificate chain.

Why should we require that the certificate be signed with the signature scheme corresponding to the public key? It's easy to produce working certificates that don't meet this:

$ openssl genrsa -out ca.key 2048
$ openssl req -new -x509 -days 2 -key ca.key -out ca.crt -sha256

$ openssl ecparam -out server.key -name prime256v1 -genkey
$ openssl req -new -sha256 -key server.key -out server.csr
$ openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -out server.crt -days 1 -sha256 -CAserial ca.seq -CAcreateserial

Now I have a cert with a P-256 public key that is signed with signature algorithm sha256WithRSAEncryption. That is, this does not meet the MUSTs in your draft.

Using openssl s_server and s_client, I get a connection using ECDHE-ECDSA-AES256-GCM-SHA384.

Is my reading correct that this is disallowed by the draft? If so, can you explain why that's the case?

-- 
Stephen Checkoway