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

<home_pw@msn.com> Sun, 31 December 2006 18:56 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H15qs-0005eR-Ek; Sun, 31 Dec 2006 13:56:10 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H15qr-0005eM-BH for tls@ietf.org; Sun, 31 Dec 2006 13:56:09 -0500
Received: from bay0-omc3-s15.bay0.hotmail.com ([65.54.246.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H15qp-00066g-P1 for tls@ietf.org; Sun, 31 Dec 2006 13:56:09 -0500
Received: from hotmail.com ([65.54.174.82]) by bay0-omc3-s15.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sun, 31 Dec 2006 10:56:07 -0800
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 31 Dec 2006 10:56:07 -0800
Message-ID: <BAY103-DAV10609A530D84AA68BD08B792C40@phx.gbl>
Received: from 69.227.152.254 by BAY103-DAV10.phx.gbl with DAV; Sun, 31 Dec 2006 18:56:06 +0000
X-Originating-IP: [69.227.152.254]
X-Originating-Email: [home_pw@msn.com]
X-Sender: home_pw@msn.com
From: home_pw@msn.com
To: tls@ietf.org
Date: Sun, 31 Dec 2006 10:56:22 -0800
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223
X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223
X-OriginalArrivalTime: 31 Dec 2006 18:56:07.0326 (UTC) FILETIME=[542ABBE0:01C72D0D]
X-Spam-Score: 0.3 (/)
X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac
Cc:
Subject: [TLS] TLS1.2: focus on non X.509 certs, cert URLs, authoirzation spaces, registration practices
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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>
Content-Type: multipart/mixed; boundary="===============2038626776=="
Errors-To: tls-bounces@lists.ietf.org

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

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