<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 27, 2015 at 4:15 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br>
> Long-term, CAs should look outside browsers, period, for the means to handle certificate enrollment.<br>
<br>
</span>It’d be great if someone could write up what the recommended alternative is; and if there isn’t one, what one might look like.  For example, should this be done with JavaScript?</blockquote></div><br></div><div class="gmail_extra">It's been a perennial topic in the W3C's WebCrypto WG ( <a href="http://www.w3.org/2012/webcrypto/">http://www.w3.org/2012/webcrypto/</a> ), despite being explicitly and repeatedly out of scope :)</div><div class="gmail_extra"><br></div><div class="gmail_extra">Without speaking for other browsers, on the Chrome side, we're not keen to expose or explore any form of enrollment API that has effects beyond the Same Origin Policy. WebCrypto today respects that (by requiring all keys be stored/addressed via IndexedDB, which respects the SOP).</div><div class="gmail_extra"><br></div><div class="gmail_extra">Put differently, any form of API that makes keys available to other applications - or to other domains - is not one we're keen to explore. That form of systems management is best treated as just that - a systems management problem.</div><div class="gmail_extra"><br></div><div class="gmail_extra">For example, in the SSL/TLS space, there's a resurgence in exploring issuance protocols (of which ACME is just one).</div><div class="gmail_extra">For (web) client certificates, they've never worked well, and work even worse in the world of both TLS 1.3 and HTTP/2, so they shouldn't be seen as the future of hardware-bound web authentication. In this space, work such as that of the FIDO Alliance (of which both Google and Microsoft are members) may represent a viable alternative.</div><div class="gmail_extra">For e-mail encryption/authentication, I readily admit my ignorance, in part because it seems to be somewhat of a wasteland. There's the Google/Yahoo developed End-to-End, proving email encryption for the browser hosted through an extension. Native mail clients seem to be on the wane for the past decade, and even still a number don't support S/MIME (e.g. Android's native client)</div><div class="gmail_extra">For mobile certificate installation, PKCS#12 tends to remain the defacto format/enrollment scheme of choice, along with iOS MDM profiles (which, IIRC, use SCEP for enrollment)</div><div class="gmail_extra"><br></div><div class="gmail_extra">I think the take-away remains the same though - the notion of a browser being able to make persistent, cryptographically unique modifications, that directly affects the behaviour of other domains and applications (and, indeed, in the case of OS X, Android, and Linux, could lead to some quite pessimistic behaviours as DoS's) is one without much cachet these days.</div></div>