Re: [keyassure] Bare keys again

[Paul Wouters <[e-mail]>]

On Sun, 20 Mar 2011, Matt McCutchen wrote:

>> That difference is muddy anyway, isn't it? Isn't a self-signed certificate a CA?
>
> It is not used to sign any certificates (except itself, but that is
> irrelevant because no one ever relies on the self signature), so no.

So if instead, I would send a list of 1 trusted_root_ca with the selfsigned
Ca, then thatwould be "in spirit" or 6066?

>> The client sends its hello message saying "I have all the CA root trust
>> anchors I need from pre-agreement".  Whether that means it got information
>> from DNSSEC/DANE or elsewhere does not matter. What matters is, is that
>> the client can start the TLS handshake without the server sending any
>> PKIX certs.
>
> How does this look at the message level?  The server sends a Certificate
> message containing a zero-length sequence of certificates?

No, it sends an Hello TLS extension of type "trusted_ca_keys" containing
in its "extension_data" a 'struct' TrustedAuthorities containing one
"TrustedAuthority" that has an "IdentifierType" of "agreed" which is
'struct {}'

>  This is not
> at all what is envisioned by RFC 6066.  To say that your scheme involves
> no TLS protocol changes is a little misleading: you are using existing
> messages but dramatically repurposing them.

Not at all! According to 6066:

6. Trusted CA Indication


    Constrained clients that, due to memory limitations, possess only a
    small number of CA root keys may wish to indicate to servers which
    root keys they possess, in order to avoid repeated handshake
    failures.

    In order to indicate which CA root keys they possess, clients MAY
    include an extension of type "trusted_ca_keys" in the (extended)
    client hello.  The "extension_data" field of this extension SHALL
    contain "TrustedAuthorities" where:

       struct {
           TrustedAuthority trusted_authorities_list<0..2^16-1>;
       } TrustedAuthorities;

       struct {
           IdentifierType identifier_type;
           select (identifier_type) {
               case pre_agreed: struct {};
               case key_sha1_hash: SHA1Hash;
               case x509_name: DistinguishedName;
               case cert_sha1_hash: SHA1Hash;
           } identifier;
       } TrustedAuthority;

       enum {
           pre_agreed(0), key_sha1_hash(1), x509_name(2),
           cert_sha1_hash(3), (255)
       } IdentifierType;

       opaque DistinguishedName<1..2^16-1>;

    Here, "TrustedAuthorities" provides a list of CA root key identifiers
    that the client possesses.  Each CA root key is identified via
    either:

    -  "pre_agreed": no CA root key identity supplied.

> IMO, this scheme should be
> standardized and subjected to the attendant level of scrutiny before we
> consider supporting it in DANE.

The only thing that is different here is that I am using a client contraint
that is different from the examples listed at the start of section 6. Was that
list supposed to be an all encompassing list?

I did not even add "pre_agreed". It is already there!

Paul