<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 2, 2015 at 12:36 PM, Geoff Keating <span dir="ltr"><<a href="mailto:geoffk@apple.com" target="_blank">geoffk@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On 2 Sep 2015, at 7:43 AM, Ben Laurie <<a href="mailto:benl@google.com">benl@google.com</a>> wrote:<br>
><br>
> It seems to me that this is a problem that should be solved at the OS level...<br>
<br>
</span>At the OS level, a solution would be for each CA to create an app, one for each OS, which runs the certificate enrollment process and installs the certificate at the end.  Is that the kind of solution people are expecting?<br></blockquote><div><br></div><div>Well, not necessarily a permutation of apps at the dimension of OS x CA </div><div><br></div><div>To the extent that every OS (and key store) is a special snowflake, with non-common idioms (from enrollment to naming to ACLs), the idea of a browser providing a common API to paper over these differences is... unlikely. As anyone who has seen the abysmal reality of key provisioning :)</div><div><br></div><div>Ben's point was more to the idea that, at the OS level, support for various enrollment schemes can (and, perhaps, should) exist. For example, both Microsoft and Apple support SCEP (in admittedly differing forms). And while there's other enrollment protocols (CMC, EST, and, more recently, ACME), and there's vendor specific protocols (as SCEP ostensibly was/is, and for which several CAs have their own schemes), somewhere at the level, the integration of "OS providing secure key management" and "CA wishing to leverage secure key management" should be solved at that intersection, rather than introducing the browser to (incompletely, insufficiently) mediate the two.</div><div><br></div><div>As I'm sure most of the CAs on the list are painfully aware, <keygen> doesn't really provide the level of controls needed for business cases (such as Rob's example of code signing). While CertEnroll (nee XEnroll) offers much greater flexibility, it does so in a way that is intrinsically tied to the OS and OS concepts, and doesn't offer a solution viable either cross-browser or cross-platform. Similarly, attempts from other browsers in the space (c.f. window.crypto.generateCRMFRequest) were naturally tied to the platform. Even iOS's support for SCEP is gated behind the MDM Profile that handles much of the platform & SCEP integration.</div><div><br></div><div>But ultimately, assuming that the key store itself (which is generally, but not necessarily, a function of the OS) can't solve or agree upon interfaces for provisioning and loading keys, then yes, I think the world in which each CA creates a per-OS app that does what the CA needs is a far better, more realistic, and, counter-intuitively, more managable solution than attempting to find a workable intersection of (key store providers, browsers, secure element vendors, CAs, users). And I say that having watched multiple "one enrollment scheme to solve them all" attempts in the IETF explode the standards conflagration that naturally results from a 'one size fits all, standardize ALL the things' approach.</div></div><br></div></div>