Re: [keyassure] Bare keys again

[Eric Rescorla <[e-mail]>]

On Sun, Mar 20, 2011 at 6:10 PM, Paul Hoffman <[e-mail]> wrote:
> On Mar 20, 2011, at 5:40 PM, Paul Wouters wrote:
>> Yes, we could make a TLS extension for "public_key" that works like server_name,
>> or we could extend server_name to take a new type "public_key", but there
>> is simply no need for such an extension, as the server does not need this
>> information and cannot do anyting with this information that is not already
>> covered with trusted_ca_keys.
>
> We fully disagree about what the TLS 1.2 spec says. I'm happy to be wrong about this if folks in the TLS WG agree with you, but your interpretation seems novel, to say the least. I understand you not wanting to spend the effort to do this properly with an extension to TLS; however, this WG cannot just say that we don't care about the requirements in TLS 1.2.


[Speaking as an individual]
IMO the requirements of 5246 are fairly clear here:


7.4.2.  Server Certificate

   When this message will be sent:

      The server MUST send a Certificate message whenever the agreed-
      upon key exchange method uses certificates for authentication
      (this includes all key exchange methods defined in this document
      except DH_anon).  This message will always immediately follow the
      ServerHello message.

   Meaning of this message:

      This message conveys the server's certificate chain to the client.

      The certificate MUST be appropriate for the negotiated cipher
      suite's key exchange algorithm and any negotiated extensions.

   Structure of this message:

      opaque ASN.1Cert<1..2^24-1>;

      struct {
          ASN.1Cert certificate_list<0..2^24-1>;
      } Certificate;

   certificate_list
      This is a sequence (chain) of certificates.  The sender's
      certificate MUST come first in the list.  Each following
      certificate MUST directly certify the one preceding it.  Because
      certificate validation requires that root keys be distributed
      independently, the self-signed certificate that specifies the root
      certificate authority MAY be omitted from the chain, under the
      assumption that the remote end must already possess it in order to
      validate it in any case.


In other words, when using any of the ordinarily certificate-based cipher suites
(i.e., all the ones that everyone actually uses), it is not
permissible either to omit the
Certificate message or to have it be empty. This is not to say, of
course, that you
could not design an extension which would modify this behavior, but in the
absence of such an extension, any server which does not send its certificate
would not comply with RFC 5246.




[Speaking as TLS WG Chair]
An extension along the lines indicated would change basic properties of TLS and
IMO would need to go through the TLS WG, and certainly is outside the remit
of this WG.

-Ekr