[cabfpub] Browsers & Enrollment (was Re: Edge Browser Can't View Certificate)

[Ryan Sleevi]

On Thu, Aug 27, 2015 at 4:15 PM, Geoff Keating <geoffk at apple.com> wrote:

>
> > Long-term, CAs should look outside browsers, period, for the means to
> handle certificate enrollment.
>
> 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?


It's been a perennial topic in the W3C's WebCrypto WG (
http://www.w3.org/2012/webcrypto/ ), despite being explicitly and
repeatedly out of scope :)

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).

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.

For example, in the SSL/TLS space, there's a resurgence in exploring
issuance protocols (of which ACME is just one).
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.
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)
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)

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20150827/8e242264/attachment-0003.html>