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

Martin Rex <> Thu, 03 April 2008 16:12 UTC

Return-Path: <>
Received: from (localhost []) by (Postfix) with ESMTP id 6284728C696; Thu, 3 Apr 2008 09:12:29 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id D06E228C6D0 for <>; Thu, 3 Apr 2008 09:12:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.75
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1I1Ea1ZHK7oM for <>; Thu, 3 Apr 2008 09:12:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 738C328C6B1 for <>; Thu, 3 Apr 2008 09:10:50 -0700 (PDT)
Received: from by (26) with ESMTP id m33GAVm2028652; Thu, 3 Apr 2008 18:10:36 +0200 (MEST)
From: Martin Rex <>
Message-Id: <>
Date: Thu, 3 Apr 2008 18:10:19 +0200 (MEST)
In-Reply-To: <> from "" at Mar 18, 8 01:39:49 pm
MIME-Version: 1.0
X-Scanner: Virus Scanner virwal06
X-SAP: out
Subject: Re: [TLS] Implementation survey: Client Certificate URL extension
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

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

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

TLS mailing list