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

[Ben Laurie]

On Wed, 2 Sep 2015 at 20:46 Ryan Sleevi <sleevi at google.com> wrote:

> On Wed, Sep 2, 2015 at 12:36 PM, Geoff Keating <geoffk at apple.com> wrote:
>
>>
>> > On 2 Sep 2015, at 7:43 AM, Ben Laurie <benl at google.com> wrote:
>> >
>> > It seems to me that this is a problem that should be solved at the OS
>> level...
>>
>> 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?
>>
>
> Well, not necessarily a permutation of apps at the dimension of OS x CA
>
> 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 :)
>
> 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.
>
> 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.
>
> 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.
>

Ryan has correctly channeled me. :-)

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.

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

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