[TLS] TLS1.2: focus on non X.509 certs, cert URLs, authoirzation spaces, registration practices

Some more comments per the call on TLS 1.2 I-D.

These are getting a bit more practical.

1. DSS SIGNED RSA IK

Is TLS 1.2 introducing the idea that DSS signed cert can contain an RSA IK?

We read that in the enhanced Certificate Request that

           "Certificate types rsa_sign and dss_sign SHOULD contain
           certificates signed with the same algorithm. However, this is
           not required. This is a holdover from TLS 1.0 and 1.1."

Is the "holdover" that TLS 1.2 still may have to accommodate DSSsignedRSAIKs (from

earlier eras),

Or is the holdover the opposite: TLS1.2 MAY now process DSSsignedRSAIKs (that wont work

well with systems from earlier eras)?

2. CLIENT CERTS: ClientCertificateType, authorization spaces

In summary the value encoding of each element of certificate_authorities should

be a function of certificate_types. This will help the client choose the appropriate

type of certificate (X.509 or not ), when populating the value of certCertChainType

when using certificate URL message.

Background follows in a) and b)

a) TLS 1.0 ClientCertificateType removed some SSL3 enum values. TLS1.1 put them back (along with

the scheme denoting ranges of types, each controlled by different authorities (including private)).

In TLS 1.1 however, we suddenly get constrained in 2006 re the encoding of the DNs. The field has to

be DER encoded, now. In SSL and TLS1.0 it was an opaque type (I.e. the format/encoding is defined

by the ClientCertificateType). (Tell Peter DER, and he assumes he has to type check it, now, as DER,

raising an exception if it fails the encoding rules for each attribute type's value; this is a lot of code!)

Given certificate URL in TLS1.2, the CA field need refer to X.509 no longer. Thus, the pre-TLS1.1 convention

should be put back: DistinguisedName values can be encoded in a manner suitable for the cert type.

(In the SAML world, we may encode a DN as a URI, for example.)

b) Given the major change in semantics due to TLS for these CA DNs (which got more and more

onerous, if you chart them), the DN is no longer cert selector: it’s a signal of "desired authorization space".

Given this change, we even more clearly need non-DER-encoded DNs for CAs. SAML2 and WS-Fed Federation

ids constitute the type of authorization spaces being implied, and don’t get described in terms of

DER-encoded DNs. Whilst they use X.509 certs behind the scenes, the trust model underlying

these authorization spaces is unlinked from KMI, PKI, CA roots etc.

I don’t mind keeping the name certificate_authorities. its just a field name in a spec; it doesn’t

go on the wire.

3. REGISTERING CertChainType

      enum {
             individual_certs(0), pkipath(1), (255)
         } CertChainType;

Can we do for CertChainType what was done earlier, for ClientCertificateType

I.e. SUGGESTED TEXT OF " CertChainType values are divided into three groups:

              1. Values from 0 (zero) through 63 decimal (0x3F) inclusive are
                 reserved for IETF Standards Track protocols.

              2. Values from 64 decimal (0x40) through 223 decimal (0xDF)
                 inclusive are reserved for assignment for non-Standards
                 Track methods.

              3. Values from 224 decimal (0xE0) through 255 decimal (0xFF)
                 inclusive are reserved for private use.

           Additional information describing the role of IANA in the
           allocation of CertChainType code points is described
           in Section 11."