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

[EKR <ekr@xxxxxxxxxxxxxxxxxxxx>]

<home_pw@xxxxxxx> writes:

> 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)?

The former.


> 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)).

Well, sort of.

TLS 1.0 had:
       enum {
           rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
           (255)
       } ClientCertificateType;

However, people were using other values. Those values are not standardized
by the IETF. So, we added them to the enum marked RESERVED to avoid reuse.


> 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).

Not really, no. RFC 2246 indicated that DistinguishedName was
derived from X509. I.e., it always had to contain a DistinguishedName.
4346 merely clarifies what was already standard practice, that it should
be encoded as DER (as opposed to, say, XER).

-Ekr

_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls