Re: [keyassure] Bare keys again

[Martin Rex <[e-mail]>]

Paul Wouters wrote:
> 
> On the contrary, that is *exactly* what the goal of 6066 is. It specifies as
> reason "memory starved clients" and "reducing bandwidth", but why is that
> list treated as an exclusive list?

The real purpose of rfc6066 is really only what the last paragraph
of the definition of this TLS extension says:

http://tools.ietf.org/html/rfc6066#section-6

   Servers that receive a client hello containing the "trusted_ca_keys"
   extension MAY use the information contained in the extension to guide
   their selection of an appropriate certificate chain to return to the
   client.  In this event, the server SHALL include an extension of type
   "trusted_ca_keys" in the (extended) server hello.  The
   "extension_data" field of this extension SHALL be empty.


The semantics of a "Server Certificate" handshake message with
no Certificates in it is UNDEFINED and therefore prohibited.

The semantics of a "Client Certificate" handshake message with
no Certificates is "NO client certificate" with _no_ slack.

The TLS requirement for the Certificate handshake message says this:

http://tools.ietf.org/html/rfc5246#section-7.4.2

   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.


There certainly are no "pre_agreed" semantics for the End-Entity(!)
certificate in the TLS Certificate handshake message.

What might be permissible (but is not an official part of the TLS spec)
is to send the certificate chain only up to a signer known to the
TLS peer.  The CertificateRequest handshake message conveys the
signer trusted by the Server to the client, so certificate path
validation should be possible for a cert chain up to one of the
announced trusted signers.


If the client uses the TrustedAuthorities TLS extension, then
personally, I would consider it permissible (but that is not
officially part of the spec!) for the server to send his own
cert chain only up to one of the trusted signers announced
by the client through the TrustedAuthorities TLS extension.



-Martin