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 mailing list [email protected] https://www.ietf.org/mailman/listinfo/wpkops
