Re: [websec] Fwd: New Version Notification for draft-ietf-websec-key-pinning-03.txt

Carl Wallace <carl@redhoundsoftware.com> Wed, 17 October 2012 17:04 UTC

Return-Path: <carl@redhoundsoftware.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAD7A21F8552 for <websec@ietfa.amsl.com>; Wed, 17 Oct 2012 10:04:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.37
X-Spam-Level:
X-Spam-Status: No, score=-4.37 tagged_above=-999 required=5 tests=[AWL=-0.771, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtaQ8eVKuOzy for <websec@ietfa.amsl.com>; Wed, 17 Oct 2012 10:04:15 -0700 (PDT)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 510F321F8587 for <websec@ietf.org>; Wed, 17 Oct 2012 10:04:15 -0700 (PDT)
Received: by mail-qc0-f172.google.com with SMTP id s14so7053068qcg.31 for <websec@ietf.org>; Wed, 17 Oct 2012 10:04:13 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=gvQ9f5T42UanvgANbxN06Bgs39o25Te9BXPHam9vCVk=; b=SL1QmMZnTEFkJtOe98EQzXnu9/phZqBuV3wysbTc5G1oT4fUrjODTGqLwibNKyQg0G qHY16tbmODfzbe+v2fQam29d0UWbpY6ytw6wO5WcBlqiU5+fBDn89goYEHqw74X+LtOn /7DO+mrxJKgXw2KwZ10hjR5XciexzQ1CvoNd3OKJ2m8sQfzDia3ciRhCyUIJGATiNk1t Sz0p8ZDLotVngvzw/Q5rZ1oxHv8kiYGhaB8jESrJ+HCRjSE8RjDQ0CRw/YrbsNx06R3t x6i41nx8bWAuHuYXjH0QmNmFrAwPrbYzm7rPR3AJjCzin7U2hX8TFTKtL77U5Lambm2q vAxA==
Received: by 10.224.207.8 with SMTP id fw8mr33061371qab.92.1350493452886; Wed, 17 Oct 2012 10:04:12 -0700 (PDT)
Received: from [192.168.2.8] (pool-72-66-83-116.washdc.fios.verizon.net. [72.66.83.116]) by mx.google.com with ESMTPS id a8sm20085159qew.11.2012.10.17.10.04.10 (version=SSLv3 cipher=OTHER); Wed, 17 Oct 2012 10:04:11 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.2.4.120824
Date: Wed, 17 Oct 2012 13:04:06 -0400
From: Carl Wallace <carl@redhoundsoftware.com>
To: <ryan-ietfhasmat@sleevi.com>, Tom Ritter <tom@ritter.vg>
Message-ID: <CCA45BB7.33DBE%carl@redhoundsoftware.com>
Thread-Topic: [websec] Fwd: New Version Notification for draft-ietf-websec-key-pinning-03.txt
In-Reply-To: <2a70aa074ea293a87a82b85febcfbd70.squirrel@webmail.dreamhost.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Gm-Message-State: ALoCoQnXtuPEohGWMAmZSn/V3162PT3ouPxZ5R0N/yMoWa7+wIFE5VUqupzBi0BywSMtVxj/3WbJ
Cc: IETF WebSec WG <websec@ietf.org>
Subject: Re: [websec] Fwd: New Version Notification for draft-ietf-websec-key-pinning-03.txt
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Oct 2012 17:04:16 -0000

On 10/17/12 12:36 PM, "Ryan Sleevi" <ryan-ietfhasmat@sleevi.com> wrote:

><large snip>
>This leaves the broader question of "How does the site operator know about
>CA_Alice and CA_Bob to begin with". One possible solution for this is a
>report-but-unenforced mode, where user agents could describe their
>observed chains to the site. As unseemly as this is, it's very likely that
>many site operators - even Very Large, High Value sites - may not have a
>full understanding of the PKI that they're a participant in.

A tool that builds all possible paths that the site operator can run
without involving any users would be good too.  The site operator mainly
needs to know where its certificate chains against public stuff and could
check that independently.  This should come close to relegating the user
report tool to oddball instances.

>Another solution is to rely on policy changes in root stores, such as
>Mozilla's recent proposed CA Certificate Store requirements change, which
>would encourage (by requiring, with only one acceptable alternative) the
>public disclosure of such CA hierarchies. As a result of such changes,
>there would be knowledge of the relationship between CA_Alice and CA_Bob,
>which under today's model, is actually quite hard for site operators to
>discover.

Even with disclosure a builder tool that illustrates possible chains would
be useful.