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

EKR <ekr@networkresonance.com> Sun, 31 December 2006 19:08 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1632-0000p1-Rw; Sun, 31 Dec 2006 14:08:44 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1632-0000ow-36 for tls@ietf.org; Sun, 31 Dec 2006 14:08:44 -0500
Received: from c-69-181-78-47.hsd1.ca.comcast.net ([69.181.78.47] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H162v-0000So-N1 for tls@ietf.org; Sun, 31 Dec 2006 14:08:44 -0500
Received: by delta.rtfm.com (Postfix, from userid 1001) id 5AB141CC61; Sun, 31 Dec 2006 11:07:21 -0800 (PST)
To: home_pw@msn.com
Subject: Re: [TLS] TLS1.2: focus on non X.509 certs, cert URLs, authoirzation spaces, registration practices
References: <BAY103-DAV10609A530D84AA68BD08B792C40@phx.gbl>
From: EKR <ekr@networkresonance.com>
Date: Sun, 31 Dec 2006 11:07:21 -0800
In-Reply-To: <BAY103-DAV10609A530D84AA68BD08B792C40@phx.gbl> (home pw's message of "Sun, 31 Dec 2006 10:56:22 -0800")
Message-ID: <86ac1328ba.fsf@delta.rtfm.com>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.2 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Cc: tls@ietf.org
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: EKR <ekr@networkresonance.com>
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org

<home_pw@msn.com> 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@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls