On Tue, Jul 7, 2015 at 3:36 PM, Jeremy Rowley <[email protected]> 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.
_______________________________________________ wpkops mailing list [email protected] https://www.ietf.org/mailman/listinfo/wpkops
