Re: [wpkops] Preliminary Next Version of Browser Behavior Draft

"Ben Wilson" <> Tue, 08 July 2014 00:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B190E1B2999 for <>; Mon, 7 Jul 2014 17:30:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.053
X-Spam-Status: No, score=-3.053 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3o-QMxU3wFeP for <>; Mon, 7 Jul 2014 17:30:05 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A677D1B2991 for <>; Mon, 7 Jul 2014 17:30:05 -0700 (PDT)
Received: from BWILSONL1 (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 28C587FA1E1 for <>; Mon, 7 Jul 2014 18:30:05 -0600 (MDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1404779405; bh=eFjC/i+EdnlNKA6Vz6dyAjDHqD1bpf5h/D7Eyery+jo=; h=From:To:References:In-Reply-To:Subject:Date; b=ZicRdn9e/ZpUQNdhTzgctAy2ecWh3keSefyjWQzagy0m3nai7sa6dfa3MYHtxVFAR wBy3q0C4ptaPCICKGzD4PyfipiLRvaFLW02ysQmMDy3aDFZ2lay0hL5HbCupmlxPuT ARbg/v3Mj8aWLAeJhBRYNemyKD2NaYS/Nmdu41dM=
From: "Ben Wilson" <>
To: <>
References: <001901cf6ec2$376461b0$a62d2510$> <059501cf79f0$69ba9060$3d2fb120$> <544B0DD62A64C1448B2DA253C011414607CC475E56@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
In-Reply-To: <544B0DD62A64C1448B2DA253C011414607CC475E56@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
Date: Mon, 7 Jul 2014 18:29:56 -0600
Message-ID: <053101cf9a43$befafd80$3cf0f880$>
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHAGq9YUAUY845vOYYDLXX689oZPAIbE3NYAoEjYvibj2tZsA==
Content-Language: en-us
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0529_01CF9A11.73CA40F0"
Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 08 Jul 2014 00:30:08 -0000

I guess the cut-off time for I-D submissions was 2014-07-05 and use of the
I-D submission tool is suspended until 2014-07-21 so I can't submit v. 02.
In any event, I've made Rick's suggested changes and have a new draft ready
to submit. 

Changes are in line below.





From: wpkops [] On Behalf Of Rick Andrews
Sent: Tuesday, June 10, 2014 6:04 PM
Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft




I reviewed what I think is the latest draft at, not
the Word doc attached to the previous message.


Section 2.1: Is it worth pointing out that root stores are not fixed? Not
only can they be extended via automatic download (as you pointed out), but
enterprises can add and remove roots (as often happens in Windows
environments) and browser users can manually add or remove roots or modify
trust bits. Document readers may not be aware of those other possibilities.




        Root stores are not fixed. Not only can they be extended via 

        automatic download, but enterprises can add and remove roots through

        group policies, and most end users can manually add or remove root 





Most systems also allow 

        users to further adjust trust anchors with other configuration 

        changes, such as allowing users to enable or disable potential key 

        usages by checking or unchecking them for each certificate found in 

        the root store. For instance, Firefox provides three options 

        (identify websites, identify mail users, and identify software 

        makers), while the Apple key chain provides ten key usages to select

        from, and Microsoft offers nearly fifty. 



Assuming that the browser has obtained a set of certificates that can 

        be used to form a certificate chain, section 4.2.1 of RFC 5280 sets 

        forth how the  authorityKeyIdentifier and the subjectKeyIdentifier 

        standard extensions can also be used to select appropriate 

        certificate when multiple choices exist.  Most browsers process

        extensions as part of certification path construction. Similarly, 

        most browsers also match the issuer name with the subject name of

        issuer's certificate as the chain is constructed up to the trust 





Section 2.2: It might be helpful to readers to explain here why Firefox does
not do "AIA chasing". In other words, they don't see it as a missing
feature; they choose to fail on incomplete chains, and a case can be made as
to why this behavior is preferable to the behavior of other browsers. Or do
we just want to point out differences among browsers without trying to
explain why those differences exist (where we understand why)?


Added:     It is the authors' understanding that the Mozilla 

        community intentionally chose this behavior instead of processing

        caIssuers AIA because Firefox will alert server administrators about

        defective chains and they can install missing CA certificates absent

        from certificate chains.


Section 3.1 The introduction says "This document reviews the current
processing behaviors...", but this Section is full of "should"s. I suggest
it needs to be rewritten to factually describe current behavior.


First few paragraphs of section 3.1 have been edited to read:


Browsers use one or more trust anchors from their root stores for
certification path validation.


The primary mechanism used to perform certification path validation in
accordance with Section 6 of RFC 5280 is verifying the signature on the
certificate.  Much has been written on the process of signature
verification, which requires processing the tbsCertificate and
signatureValue fields using the signature algorithm and issuer public key to
verify that the certificate was properly signed.  DSA, RSA, and ECDSA are
common digital signature algorithms used to sign certificates in conjunction
with hashing algorithms such as MD5, RIPEMD-160, SHA-1, SHA-256, SHA-384,
SHA-512, and Whirlpool. Thus, a browser might need to be able to perform the
signature verification process using a variety of signature and hashing


The following extensions described in RFC 5280 are also relevant to
certification path validation:


Section 3.4 seems speculative and not descriptive of current browser


Replaced with:


Potential threats to communications security to be considered include
whether allowing weak cryptography increases the risk that intercepted
communications will be decrypted, and whether an inability to handle
unexpected certificate data might cause a browser to fail in an insecure
way, for example, software failure that allows a connection to proceed
without encryption or enables other system misuse, e.g., a buffer overflow
due to excessive data in a certificate payload.  


Section 3.5 Header is not in bold.




Section 4.3 Shouldn't say "browsers should" ;^)


The first sentence now reads:


A server's public key can be used for key encryption, key agreement, 

        or digital signature verification depending on the TLS cipher suite 






From: wpkops [] On Behalf Of Ben Wilson
Sent: Tuesday, May 27, 2014 2:13 PM
Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft


Here is another draft with suggested changes from Santosh accepted, and the
addition of "Security Considerations" subsections, based on our discussions
of May 13th. 



From: wpkops [] On Behalf Of Ben Wilson
Sent: Tuesday, May 13, 2014 9:44 AM
Subject: [wpkops] Preliminary Next Version of Browser Behavior Draft


Here is a first pass through the browser behavior document that I sent to
Robin and Santosh yesterday.