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

[Rob Stradling]

On 02/09/15 20:46, Ryan Sleevi wrote:
> 
> On Wed, Sep 2, 2015 at 12:36 PM, Geoff Keating <geoffk at apple.com
> <mailto:geoffk at apple.com>> wrote:
> 
> 
>     > On 2 Sep 2015, at 7:43 AM, Ben Laurie <benl at google.com <mailto: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.

+1

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

"introducing"?

I don't think we're talking about introducing certificate enrolment into
browsers.  We're talking about whether or not it's a good idea to remove
existing certificate enrolment functionality from browsers before some
alternative solution(s) are actually available.

IMHO, <keygen> and CertEnroll are/were better than nothing.

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

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online