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
- [TLS] TLS1.2: focus on non X.509 certs, cert URLs… home_pw
- Re: [TLS] TLS1.2: focus on non X.509 certs, cert … EKR
- Re: [TLS] TLS1.2: focus on non X.509 certs, cert … home_pw
- Re: [TLS] TLS1.2: focus on non X.509 certs, cert … home_pw
- [TLS] server auth on renegoiate home_pw
- Re: [TLS] TLS1.2: focus on non X.509 certs, cert … Mike
- Re: [TLS] TLS1.2: focus on non X.509 certs, cert … home_pw
- Re: [TLS] TLS1.2: focus on non X.509 certs, cert … Martin Rex