Re: [websec] #53: Clarify status of pin validation when used with private trust anchors

Tobias Gondrom <tobias.gondrom@gondrom.org> Tue, 28 May 2013 11:35 UTC

Return-Path: <tobias.gondrom@gondrom.org>
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 5399521F8930 for <websec@ietfa.amsl.com>; Tue, 28 May 2013 04:35:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -93.873
X-Spam-Level:
X-Spam-Status: No, score=-93.873 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQ7RmT22yafV for <websec@ietfa.amsl.com>; Tue, 28 May 2013 04:35:52 -0700 (PDT)
Received: from lvps176-28-13-69.dedicated.hosteurope.de (lvps176-28-13-69.dedicated.hosteurope.de [176.28.13.69]) by ietfa.amsl.com (Postfix) with ESMTP id DB2C821F885A for <websec@ietf.org>; Tue, 28 May 2013 04:35:51 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=FxLP7PozMu7kzUq2jC32yPTLlcLmhBM1rykxsHLP8G/vyb/Y4fVchKV91sSy305U2m5aDH24oJOw5mYbft0ehN2Hc2aPU/kz55xRTwQ8rfNianXQms0SaW85/NxGQcPk; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding;
Received: (qmail 11421 invoked from network); 28 May 2013 13:35:49 +0200
Received: from 188-222-173-238.zone13.bethere.co.uk (HELO ?192.168.1.94?) (188.222.173.238) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 28 May 2013 13:35:49 +0200
Message-ID: <51A49695.9080200@gondrom.org>
Date: Tue, 28 May 2013 12:35:49 +0100
From: Tobias Gondrom <tobias.gondrom@gondrom.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: websec@ietf.org
References: <058.27d97f66ed18f6f7f41e08788db76253@trac.tools.ietf.org> <073.7596c49c42f63bc38fe20a2ed8c59450@trac.tools.ietf.org>
In-Reply-To: <073.7596c49c42f63bc38fe20a2ed8c59450@trac.tools.ietf.org>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [websec] #53: Clarify status of pin validation when used with private trust anchors
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: Tue, 28 May 2013 11:35:57 -0000

Hi Chris,

I think so. (but am not 100% sure.)
Any other comments on this issue before we close it?

Thanks, Tobias


On 25/05/13 02:41, websec issue tracker wrote:
> #53: Clarify status of pin validation when used with private trust anchors
>
>
> Comment (by palmer@google.com):
>
>  The current draft has this text:
>
>   578 <t>If the connection has no errors, then the UA will determine
>  whether to
>   579 apply a new, additional correctness check: Pin Validation. A UA
>  SHOULD
>   580 perform Pin Validation whenever connecting to a Known Pinned Host,
>  but MAY
>   581 allow Pin Validation to be disabled for Hosts according to local
>  policy. For
>   582 example, a UA may disable Pin Validation for Pinned Hosts whose
>  validated
>   583 certificate chain terminates at a user-defined trust anchor, rather
>  than a
>   584 trust anchor built-in to the UA. However, if the Pinned Host Metadata
>   585 indicates that the Pinned Host is operating in "strict mode" (see
>   586 <xref target="strict"/>), then the UA MUST perform Pin
>  Validation.</t>
>
>  I believe this is the result of previous consensus. Is that correct, and
>  can I therefore close this issue?
>