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

[Rob Stradling]

On 29/08/15 00:27, Ryan Sleevi wrote:
> On Fri, Aug 28, 2015 at 3:33 PM, Rob Stradlingwrote:
>
>     Perhaps, with your W3C hat on, you know more about Microsoft's plans
>     than I do.  However, if you don't mind, I'd like to hear from
>     Microsoft about whether or not Edge's non-support for certificate
>     enrolment is deliberate.
>
> No W3C hat required - from one of the Microsoft IE/Edge PMs -
> https://groups.google.com/a/chromium.org/d/msg/blink-dev/pX5NbX0Xack/UdqJdDsFAgAJ

Thanks Ryan.

It doesn't surprise me to hear that "Microsoft agrees with Google that 
keygen is not very useful anymore", since IE/Edge have never supported 
<keygen>.  And it doesn't surprise me to hear that Microsoft "believe" 
that "WebCrypto will play a role" and "the *future* direction...revolves 
around FIDO".

That's all great, but what I'm interested in right now is what is 
*currently* supposed to be supported w.r.t. certificate enrolment in 
Microsoft's browsers.  (That post says nothing about IE, Edge or 
CertEnroll).

>     If that's the case, then I suppose the simplest solution is for the
>     CA to generate the keypair, then issue the cert, and then send a
>     password-encrypted PKCS#12 file to the user.
>
>
> Or you can use WebCrypto to generate a keypair (which is constrained to
> that origin), perform whatever proof of possession dance is required
> (e.g. signing a CSR; again, using WebCrypto), submiting the CSR to the
> CA and using WebCrypto to 'export' the key from JavaScript into a
> PKCS#12 blob URL, which could then be invoked as a download.

Nice idea.  I can see that this approach would work for users that are 
happy to store their private keys "in software".

But would it support generating keypairs "in a FIPS 140-2 level 2 (or 
equivalent) crypto module", as required for EV Code Signing certs?

> The benefit to this is that the CA never need touch the key material. It
> could live entirely on the client, avoiding any pesky escrow/generation
> concerns. While a CA could, theoretically, access that private key (e.g.
> by serving JS that caused WebCrypto to post them the exported private
> key), it's no different a threat-model from a CA using a native
> enrollment technology to escrow their key.

I agree that it's best for CAs to never touch keys that they never need 
to use.

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