Re: [TLS] AIA cert fetching seen as harmful

Nelson B Bolyard <nelson@bolyard.com> Fri, 11 April 2008 19:32 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 18F863A6881; Fri, 11 Apr 2008 12:32:53 -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 D42533A6A16 for <tls@core3.amsl.com>; Fri, 11 Apr 2008 12:32:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.722
X-Spam-Level:
X-Spam-Status: No, score=-1.722 tagged_above=-999 required=5 tests=[AWL=0.878, BAYES_00=-2.599]
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 GGrWSYA4Ypkg for <tls@core3.amsl.com>; Fri, 11 Apr 2008 12:32:50 -0700 (PDT)
Received: from smtprelay.hostedemail.com (smtprelay0065.hostedemail.com [216.40.44.65]) by core3.amsl.com (Postfix) with ESMTP id A48F43A682D for <tls@ietf.org>; Fri, 11 Apr 2008 12:32:50 -0700 (PDT)
Received: from emd2-omf05.hostedemail.com (ff-bigip1 [10.5.19.254]) by smtprelay03.hostedemail.com (Postfix) with ESMTP id E15BF106CC3; Fri, 11 Apr 2008 19:33:12 +0000 (UTC)
X-SpamScore: 50
X-Spamcatcher-Summary: 50, 0, 0, 09d4754af306cb85, 4f4e0b77b7fdf9f9, nelson@bolyard.com, -, RULES_HIT:152:355:379:599:601:945:967:973:988:989:1187:1260:1261:1277:1311:1313:1314:1345:1359:1437:1515:1516:1518:1534:1541:1593:1594:1676:1711:1730:1747:1766:1792:2194:2199:2393:2525:2560:2563:2682:2685:2857:2859:2892:2933:2937:2939:2942:2945:2947:2951:2954:3022:3027:3353:3622:3743:3865:3866:3867:3868:3869:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:4250:4321:4361:5007:6117:6119:6121:6122: 7652:7679:7875, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none
X-Spamcatcher-Explanation:
Received: from [192.168.2.5] (c-67-164-81-7.hsd1.ca.comcast.net [67.164.81.7]) (Authenticated sender: nelson@bolyard.com) by emd2-omf05.hostedemail.com (Postfix) with ESMTP; Fri, 11 Apr 2008 19:33:12 +0000 (UTC)
Message-ID: <47FFBC7B.1050600@bolyard.com>
Date: Fri, 11 Apr 2008 12:31:07 -0700
From: Nelson B Bolyard <nelson@bolyard.com>
Organization: Network Security Services
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9pre) Gecko/2008041001 NOT Firefox/2.0 SeaMonkey/2.0a1pre
MIME-Version: 1.0
To: Mike <mike-list@pobox.com>
References: <200804101549.m3AFnH5T008818@fs4113.wdf.sap.corp> <47FE39E7.2020209@pobox.com> <47FEB492.6020209@bolyard.com> <47FED914.7050609@pobox.com>
In-Reply-To: <47FED914.7050609@pobox.com>
Cc: tls@ietf.org
Subject: Re: [TLS] AIA cert fetching seen as harmful
X-BeenThere: tls@ietf.org
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." <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

Mike wrote, On 2008-04-10 20:20:
>>> This could be made safe with some help from PKIX (if X.509 doesn't
>>> already support it -- I haven't read RFC 3280 or -bis in a while).
>>> If root certificates listed constraints on what constitutes a valid
>>> URL for retrieving issued certificates, then a server could scan
>>> the combined list from each trusted root to determine if it is safe
>>> to fetch a client certificate.
>> Are you all aware of this paper, now making a stir?
>>
>>     https://www.cynops.de/techzone/http_over_x509.html
>>
>> It claims that fetching CA certs from URLs found in AIA extensions in certs
>> that have not yet been validated is a vulnerability.  At least one browser
>> organization known to me agrees.
> 
> What I suggested is that the information about which URL's are safe
> for the client certificate URL extension could be embedded in the
> -root- certificate, which you trust.  When a client sends you a URL
> in place of a certificate, you would compare it to the information
> in each of your root certificates.  If the URL matches one of them,
> you know it's safe to retrieve it; otherwise you best not. 

Please look at a diagram of the US Federal Bridge CA PKI, or the equivalent
bridged PKI in Japan or South Korea, and tell us how your proposal would
work in those environments.

Regards,
/Nelson
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls