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

Martin Rex <martin.rex@sap.com> Tue, 02 January 2007 16:31 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1mYM-0001ji-CI; Tue, 02 Jan 2007 11:31:54 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1mYL-0001jd-5O for tls@ietf.org; Tue, 02 Jan 2007 11:31:53 -0500
Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1mYJ-0002Wt-Pn for tls@ietf.org; Tue, 02 Jan 2007 11:31:53 -0500
Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id RAA17759; Tue, 2 Jan 2007 17:31:45 +0100 (MEZ)
From: Martin Rex <martin.rex@sap.com>
Message-Id: <200701021631.RAA20033@uw1048.wdf.sap.corp>
Subject: Re: [TLS] TLS1.2: focus on non X.509 certs, cert URLs,
To: home_pw@msn.com
Date: Tue, 02 Jan 2007 17:31:45 +0100
In-Reply-To: <BAY103-DAV32C3E536342FDAC659EB992C40@phx.gbl> from "home_pw@msn.com" at Dec 31, 6 11:58:19 am
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-SAP: out
X-SAP: out
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Cc: tls@ietf.org
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: martin.rex@sap.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 wrote:
> 
> 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?

This is *NOT* about PKI.
It is about X.509 certificates and certificate chains.

It means that the client should search his credentials and see
whether there is a match between one of the CAs from that list
of the Server and the issuer field of the certificate of
the clients credentials (itself, or of (one) of its chain(s)).

If there's at least one match, the client can use that credentials
for client authentication, including the certification path up
to at least the matching CA from the servers list.


X.509 certs must be DER-encoded, and there MUST be a binary/opaque
match of the CA name sent by the server with the issuer name in
the clients (end-entity or path) certificate, therefore all
the DNames in that list must be DER-encoded (or will likely not
match issuer names - except for broken CAs issuing defective certs
with non-DER encoded issuer names).

-Martin

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