Re: [TLS] Implementation survey: Client Certificate URL extension

Martin Rex <Martin.Rex@sap.com> Thu, 03 April 2008 16:12 UTC

Return-Path: <tls-bounces@ietf.org>
X-Original-To: tls-archive@ietf.org
Delivered-To: ietfarch-tls-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6284728C696; Thu, 3 Apr 2008 09:12:29 -0700 (PDT)
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D06E228C6D0 for <tls@core3.amsl.com>; Thu, 3 Apr 2008 09:12:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.75
X-Spam-Level:
X-Spam-Status: No, score=-4.75 tagged_above=-999 required=5 tests=[AWL=1.499, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1I1Ea1ZHK7oM for <tls@core3.amsl.com>; Thu, 3 Apr 2008 09:12:21 -0700 (PDT)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 738C328C6B1 for <tls@ietf.org>; Thu, 3 Apr 2008 09:10:50 -0700 (PDT)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id m33GAVm2028652; Thu, 3 Apr 2008 18:10:36 +0200 (MEST)
From: Martin Rex <Martin.Rex@sap.com>
Message-Id: <200804031610.m33GAJ6V004192@fs4113.wdf.sap.corp>
To: Pasi.Eronen@nokia.com
Date: Thu, 03 Apr 2008 18:10:19 +0200
In-Reply-To: <1696498986EFEC4D9153717DA325CB7223A82C@vaebe104.NOE.Nokia.com> from "Pasi.Eronen@nokia.com" at Mar 18, 8 01:39:49 pm
MIME-Version: 1.0
X-Scanner: Virus Scanner virwal06
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] Implementation survey: Client Certificate URL extension
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
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.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tls-bounces@ietf.org
Errors-To: tls-bounces@ietf.org

If you read the news, you probably noticed the following paper
today or these days:

https://www.cynops.de/techzone/http_over_x509.html

Although this Papers describes a serious design flaw in the
rfc3280 suggestion to put URLs of intermediate CAs into X.509v3
cert extensions and have peers use them in order to be able
to build a certification path, the very same problem will
apply to every concept that a communication peer can be
coerced to access one or more arbitrary URLs prior to
authentication, and the Client Certificate URL extension
appears to suffer the same vulnerabilities and security
problems.

-Martin
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls