Re: [TLS] Verifying X.509 Certificate Chains out of order

pgut001@cs.auckland.ac.nz (Peter Gutmann) Thu, 16 October 2008 07:00 UTC

Return-Path: <tls-bounces@ietf.org>
X-Original-To: tls-archive@ietf.org
Delivered-To: ietfarch-tls-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8A143A6A78; Thu, 16 Oct 2008 00:00:40 -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 F13043A6A78 for <tls@core3.amsl.com>; Thu, 16 Oct 2008 00:00:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.599
X-Spam-Level:
X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 uauxr4x8PC3Q for <tls@core3.amsl.com>; Thu, 16 Oct 2008 00:00:39 -0700 (PDT)
Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by core3.amsl.com (Postfix) with ESMTP id E769B3A6952 for <tls@ietf.org>; Thu, 16 Oct 2008 00:00:37 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id DFA699D4D5; Thu, 16 Oct 2008 20:00:41 +1300 (NZDT)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYzM7gkm6rEV; Thu, 16 Oct 2008 20:00:41 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id C24FF9D5F8; Thu, 16 Oct 2008 20:00:41 +1300 (NZDT)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 6C13F19EC0BA; Thu, 16 Oct 2008 20:00:41 +1300 (NZDT)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <pgut001@wintermute01.cs.auckland.ac.nz>) id 1KqMqf-0000Ce-9X; Thu, 16 Oct 2008 20:00:41 +1300
From: pgut001@cs.auckland.ac.nz
To: pgut001@cs.auckland.ac.nz, simon@josefsson.org
In-Reply-To: <87bpxlxcr0.fsf@mocca.josefsson.org>
Message-Id: <E1KqMqf-0000Ce-9X@wintermute01.cs.auckland.ac.nz>
Date: Thu, 16 Oct 2008 20:00:41 +1300
Cc: tls@ietf.org
Subject: Re: [TLS] Verifying X.509 Certificate Chains out of order
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tls-bounces@ietf.org
Errors-To: tls-bounces@ietf.org

Simon Josefsson <simon@josefsson.org> writes:

>If someone really wants to solve this privacy problem, add a certificate
>extension that tells browsers to never announce a particular end-entity
>certificate except to particular hosts, and make browsers support it.

This probably needs to go to a list like hcisec to get HCI peoples' input, but
what about treating it like cookies, if people are concerned about privacy and
turn off cookies (which, if you include session cookies, may well make most of
the web unusable, but that's their decision) then your UI would pop up a
dialog before handing over the cert, otherwise keep the existing behaviour of
silently sending the cert.  If the concern is user tracking then give cert-
usage the same user interaction as cookie-usage.  The browser already has the
UI and whatnot there and users are, well, at least somewhat educated about
cookies, so just extend the existing mechanism to cover new cookie-equivalents
(including things like Flash cookies and the other odds and ends I mentioned,
which currently aren't handled well at all).

>I suspect you'll have trouble convincing everyone to implement the feature,
>and the IETF to standardize it, because people will question whether the
>privacy problem is a serious problem.

PKIX (the WG responsible for this) will standardise anything with an ASN.1 
syntax (there's an RFC for adding theme music to certificates, for example), I 
doubt you'll have any problems there :-).

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