Re: [wpkops] Preliminary Next Version of Browser Behavior Draft
Gervase Markham <gerv@mozilla.org> Wed, 04 June 2014 21:38 UTC
Return-Path: <gerv@mozilla.org>
X-Original-To: wpkops@ietfa.amsl.com
Delivered-To: wpkops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91FAF1A032B for <wpkops@ietfa.amsl.com>; Wed, 4 Jun 2014 14:38:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level:
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pwCxtoSwoym for <wpkops@ietfa.amsl.com>; Wed, 4 Jun 2014 14:38:09 -0700 (PDT)
Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF961A0309 for <wpkops@ietf.org>; Wed, 4 Jun 2014 14:38:09 -0700 (PDT)
Received: from [192.168.1.119] (host86-131-197-101.range86-131.btcentralplus.com [86.131.197.101]) (Authenticated sender: gerv@mozilla.org) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 2E488F244C; Wed, 4 Jun 2014 14:38:00 -0700 (PDT)
Message-ID: <538F795F.3020008@mozilla.org>
Date: Wed, 04 Jun 2014 20:54:07 +0100
From: Gervase Markham <gerv@mozilla.org>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.0a2
MIME-Version: 1.0
To: ben@digicert.com, wpkops@ietf.org
References: <001901cf6ec2$376461b0$a62d2510$@digicert.com> <059501cf79f0$69ba9060$3d2fb120$@digicert.com>
In-Reply-To: <059501cf79f0$69ba9060$3d2fb120$@digicert.com>
X-Enigmail-Version: 1.7a1pre
OpenPGP: id=9DF43DBB
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/wpkops/nHhAWPSiqL64Nf0Q74rmvghpUSY
Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft
X-BeenThere: wpkops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <wpkops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/wpkops>, <mailto:wpkops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/wpkops/>
List-Post: <mailto:wpkops@ietf.org>
List-Help: <mailto:wpkops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/wpkops>, <mailto:wpkops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Jun 2014 21:38:11 -0000
Hi Ben, On 27/05/14 22:12, Ben Wilson wrote: > Here is another draft with suggested changes from Santosh accepted, and > the addition of “Security Considerations” subsections, based on our > discussions of May 13^th . Sorry if I'm missing context here, but the intro to the document suggests that it's documentation of observed browser behaviour (i.e. a record of reality), but then as early as section 1.4 it starts by saying browsers "should" do X or Y. E.g.: "A browser should only use its trust anchor store to determine the trust anchor for a Server’s certification path." Taking this particular statement as an example: what happens if the browser wants to use the OS store? Or both its own and the OSes? Or a remote store with auto-download such as Windows uses? To take another example from 1.4: "Specifically, the browser should be able to use unsecure HTTP and unsecure LDAP method." I can confidently say that we have no plans to reintroduce LDAP fetching to Firefox, and the publication of an RFC would be unlikely (British understatement) to change that. (We are also pretty unlikely to do caIssuers chasing, but I am 0.1% less adamant about that.) As more constructive input: many of the behaviours you note are features of the underlying SSL implementation rather than the browser. This is, I believe, why Chrome and Safari on OS X don't do name constraints (they use the system SSL library) but Firefox does (which uses NSS). I agree it's difficult because the exact user experience _is_ defined by the individual browsers. But the document might be easier to understand and follow if you acknowledged the connection with the library being used. Gerv
- [wpkops] Preliminary Next Version of Browser Beha… Ben Wilson
- Re: [wpkops] Preliminary Next Version of Browser … Ben Wilson
- Re: [wpkops] Preliminary Next Version of Browser … i-barreira
- Re: [wpkops] Preliminary Next Version of Browser … Gervase Markham
- Re: [wpkops] Preliminary Next Version of Browser … Tim Moses
- Re: [wpkops] Preliminary Next Version of Browser … Gervase Markham
- Re: [wpkops] Preliminary Next Version of Browser … Tim Moses
- Re: [wpkops] Preliminary Next Version of Browser … Ben Wilson
- Re: [wpkops] Preliminary Next Version of Browser … Ben Wilson
- Re: [wpkops] Preliminary Next Version of Browser … Tim Moses
- Re: [wpkops] Preliminary Next Version of Browser … i-barreira
- Re: [wpkops] Preliminary Next Version of Browser … i-barreira
- Re: [wpkops] Preliminary Next Version of Browser … Ben Wilson
- Re: [wpkops] Preliminary Next Version of Browser … i-barreira
- Re: [wpkops] Preliminary Next Version of Browser … Ben Wilson
- Re: [wpkops] Preliminary Next Version of Browser … Rick Andrews
- Re: [wpkops] Preliminary Next Version of Browser … Ben Wilson
- Re: [wpkops] Preliminary Next Version of Browser … Stephen Kent
- Re: [wpkops] Preliminary Next Version of Browser … Ben Wilson