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

<home_pw@msn.com> Sun, 31 December 2006 19:58 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H16ou-0005tG-NN; Sun, 31 Dec 2006 14:58:12 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H16os-0005t7-OC for tls@ietf.org; Sun, 31 Dec 2006 14:58:10 -0500
Received: from bay0-omc3-s35.bay0.hotmail.com ([65.54.246.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H16oq-00062v-SP for tls@ietf.org; Sun, 31 Dec 2006 14:58:10 -0500
Received: from hotmail.com ([65.54.174.75]) by bay0-omc3-s35.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sun, 31 Dec 2006 11:58:08 -0800
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 31 Dec 2006 11:58:08 -0800
Message-ID: <BAY103-DAV32C3E536342FDAC659EB992C40@phx.gbl>
Received: from 69.227.152.254 by BAY103-DAV3.phx.gbl with DAV; Sun, 31 Dec 2006 19:58:03 +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
Subject: Re: [TLS] TLS1.2: focus on non X.509 certs, cert URLs, authoirzation spaces, registration practices
Date: Sun, 31 Dec 2006 11:58:19 -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 19:58:08.0211 (UTC) FILETIME=[FDFCBA30:01C72D15]
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba
Cc:
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="===============1943840937=="
Errors-To: tls-bounces@lists.ietf.org

Concerning 7.4.5. Certificate request

           "A list of the distinguished names of acceptable certificate
           authorities. These distinguished names may specify a desired
           distinguished name for a root CA or for a subordinate CA;
           thus, this message can be used both to describe known roots
           and a desired authorization space. If the
           certificate_authorities list is empty then the client MAY
           send any certificate of the appropriate
           ClientCertificateType, unless there is some external
           arrangement to the contrary."


So, what does this all really mean, just staying within the traditional PKI world?

Rather than send a simple list of root DNs, we are now sending 2 different signals?

For a list of 4 DNs, Are we saying that element 1 might point to a root, but 2 to 
a CA within that root's certification domain? And then for 3 and 4 something
similar for a different certification domain?

If I understand what is being specified:

1. its up to the client to figure out which DN has which semantics; there is NO ordering  

2. its up to the client to figure out that a subordinate CA is indeed controlled by some root 
(e.g. name hierarchy, following hash chaining in PKIX cert extensions)

3. an intended model for "authorization space" (a subordinate CA) might be: the CA for 
;organizational' certs, vs the CA for "individual" certs (in a military messaging system context). 
However, this has nothing to do with "authorization certs", SAML authorization assertions, etc.

This text has been in this section since TLS 1.0.  So, Is this actually used widely in this 2 signal 
mode...as it seems it MUST?

I'm guessing at its intended application, in 3. The text in the standard on this 
is woefully inadequate. It could mean something entirely different: identify the 
BridgeCA as root, and then the Agency CA as "authorization space".

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