IETF Logo Mail Archive

Re: [TLS] AIA cert fetching seen as harmful

Mike <mike-list@pobox.com> Sat, 12 April 2008 02:59 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 B2F0E3A6AA4; Fri, 11 Apr 2008 19:59:31 -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 AEC623A68C4 for <tls@core3.amsl.com>; Fri, 11 Apr 2008 19:59:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.505
X-Spam-Level:
X-Spam-Status: No, score=-1.505 tagged_above=-999 required=5 tests=[AWL=1.094, 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 p4y0huU23EJv for <tls@core3.amsl.com>; Fri, 11 Apr 2008 19:59:27 -0700 (PDT)
Received: from sasl.smtp.pobox.com (a-sasl-fastnet.sasl.smtp.pobox.com [207.106.133.19]) by core3.amsl.com (Postfix) with ESMTP id 417E63A6AA4 for <tls@ietf.org>; Fri, 11 Apr 2008 19:59:26 -0700 (PDT)
Received: from localhost.localdomain (localhost [127.0.0.1]) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTP id EACED2618 for <tls@ietf.org>; Fri, 11 Apr 2008 22:59:49 -0400 (EDT)
Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTP id 9290D2617 for <tls@ietf.org>; Fri, 11 Apr 2008 22:59:49 -0400 (EDT)
Message-ID: <48002592.3010802@pobox.com>
Date: Fri, 11 Apr 2008 19:59:30 -0700
From: Mike <mike-list@pobox.com>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: tls@ietf.org
References: <200804101549.m3AFnH5T008818@fs4113.wdf.sap.corp> <47FE39E7.2020209@pobox.com> <47FEB492.6020209@bolyard.com> <47FED914.7050609@pobox.com> <47FFBC7B.1050600@bolyard.com>
In-Reply-To: <47FFBC7B.1050600@bolyard.com>
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

> 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.

I don't know the specifics of any PKI, but I think the answer is
the same for any one of them.  A server can not blindly retrieve
any URL presented by a client, so it needs to be configured as to
what URL's are acceptable.  One way to accomplish that is to put
the information in the CA certificates as I suggested.

If your question was meant to say that this would be difficult
to do for those PKI's because servers don't know all of the
intermediate CA's and don't have all of their certificates, then
the answer is that they either need to be configured with those
missing certificates, or they can't safely support the client
certificate URL extension for those clients.  This seems to be
a case where you can't have your cake and eat it too.

Mike

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

v2.23.0 | Report a Bug | By Email