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

["Ben Wilson" <[e-mail]>]

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.

Cheers,

Ben

 

 

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

 

Ben,

 

I reviewed what I think is the latest draft at
https://tools.ietf.org/html/draft-wilson-wpkops-browser-processing-01, 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.

 

Added:

 

        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 

        certificates.  

 

and

 

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. 

 

and

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
these 

        extensions as part of certification path construction. Similarly, 

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

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

        anchor.  

 

 

 

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
the 

        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
algorithms.

 

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
behavior.

 

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.

 

Fixed

 

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 

        selected.  

 

 

-Rick

 

From: wpkops [mailto:[e-mail]] On Behalf Of Ben Wilson
Sent: Tuesday, May 27, 2014 2:13 PM
To: [e-mail]
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 [mailto:[e-mail]] On Behalf Of Ben Wilson
Sent: Tuesday, May 13, 2014 9:44 AM
To: [e-mail]
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.