Re: [wpkops] draft-housley-web-pki-problems-00

[Phillip Hallam-Baker <[e-mail]>]

On Tue, Jul 7, 2015 at 3:36 PM, Jeremy Rowley <[e-mail]>
wrote:

> This paper sounds like a wish list of select issues taken from the Mozilla
> forums.  I don't see why it would be published as informational RFC? Is the
> goal to make a list of issues that community members feel need to be
> discussed? I don't get it.
>
> The conclusions seem to be 1) Have a CAB Forum that is more transparent
> (which is out of scope of the IEFT - I'm not sure I've ever seen an IETF
> paper specifically call out to another industry body requesting a change in
> its membership?) and 2) Use Let's Encrypt - one specific member of the CA
> community.  Many CAs already offer free tools to automate issuance, making
> the call out to Let's Encrypt very odd in an IETF document, especially
> where the touted feature - new automated tools - already exist (
> https://www.digicert.com/express-install/).  I have a similar complaint
> about the reference to acme where PHB has been proposing something similar
> for a LONG time (
> https://tools.ietf.org/html/draft-hallambaker-omnibroker-06).
>
> I'm also not sure why you selected the specific issues for inclusion in
> the paper. For example, the paper doesn't mention inconsistencies in
> validation levels, which (imo) is a bigger issue than the "too big to fail"
> scenario. Cost also is a weird issue to include in the document since it's
> always relative.  It's also very difficult to discuss without running afoul
> of anti-trust laws.
>

I have a slightly different concern about the mention of CABForum.

CABForum was originally started to develop industry standards for
Organizational Validation certs which turned into EV certs over time. As
such I always regarded it as a successor in spirit to the ABA group that
Michael Baum used to run.

CABForum is not set up as a governance body. It does not manage a trust
store or decide on inclusion of trust roots. It isn't an industry
association either, there is a separate body that has that role.


I think that the problem the paper identifies is actually a more
fundamental issue with the WebPKI, the fact that browser providers are not
ideally placed to act as curators of trust stores because they have two
conflicting concerns: security and interoperability.

While browsers do their best to achieve a balance between those concerns,
they can't be expected to provide customized tradeoffs for different
purposes. It is inevitably one size fits all.


One of the ways I am looking to address this in the mesh is to provide a
mechanism that allows individual users more control of their network
environment by defining a custom network profile that can be easily
transferred from one device to another.

In ordinary circumstances, it is not practical for a user to manage a
custom set of WebPKI roots on each of their machines or for that matter to
delegate that configuration to a trusted party.