<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, 2 Sep 2015 at 20:46 Ryan Sleevi <<a href="mailto:sleevi@google.com">sleevi@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><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><br>
> On 2 Sep 2015, at 7:43 AM, Ben Laurie <<a href="mailto:benl@google.com" target="_blank">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></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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></div></div></blockquote><div><br></div><div>Ryan has correctly channeled me. :-)</div><div><br></div><div>I would say that it would be more satisfactory to have a centrally managed (i.e. by the OS) credential store than one-per-credential-issuer (which obviously extends beyond CAs). Possibly some kind of plug-in architecture could allow for the per-issuer variances such as protocols, UI, etc? Per-issuer apps seem likely to lead to what is known as the NASCAR interface in the Identity world - i.e. every app ends up having to offer hooks to every credential-store and the user has to try to figure out which store is the right one to use.</div><div><br></div><div>Plus, of course, credential stores are a giant attractive nuisance and it would be good to have the security engineering (and updating!) all in one place (which is not to suggest a single security boundary, btw).</div><div><br></div><div>I realise I am proposing quite a large project here, but probably not larger than all the failed attempts to shoehorn the browser into this role. Plus it would be huge security boon.</div><div> </div></div></div>