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

[Rob Stradling]

On 01/09/15 17:49, Ryan Sleevi wrote:
> On Tue, Sep 1, 2015 at 2:11 AM, Rob Stradling <rob.stradling at comodo.com
> <mailto:rob.stradling at comodo.com>> wrote:
> 
>     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).
> 
> 
> As of Edge, no enrollment is directly supported by the browser.
> ActiveX (therefore CertEnroll and XEnroll) was removed from Edge.
> <keygen> is not supported by Edge.
> 
> I can understand Jody's delays - multiple tweets to @MSEdgeDev and
> @jacobrossi and @frankoliver on the matter have gone unanswered, but the
> evidence remains :)

Ryan, I don't dispute that CertEnroll doesn't work in Edge right now.

What I want to know is:
Are Microsoft planning to do anything about that?

There seems little point in CAs attempting to engineer alternative
non-browser-based solutions if (for example) Microsoft might do a U-turn
and add ActiveX support to Edge.

Given that Microsoft's platform is arguably the primary user of EV and
non-EV Code Signing Certificates, ISTM that Microsoft might just
possibly like the idea that it should be a) possible and b) relatively
easy for software developers to obtain (EV) code signing certs from CAs!

Frankly, it baffles me that Microsoft are simultaneously a) pushing for
increased use of EV Code Signing Certificates for Win10 and b) making it
harder to obtain EV Code Signing Certificates using Win10.

>     But would it support generating keypairs "in a FIPS 140-2 level 2
>     (or equivalent) crypto module", as required for EV Code Signing certs?
> 
> <keygen> itself has never explicitly supported that.
> Chrome intentionally never will support that.

Sure.  But CertEnroll does/did.

> Only Firefox's implementation gave end users the choice of security
> module to use (e.g. software, hardware). However, <keygen> with
> virtually very COTS smart card would not work (due to vendor-specific
> provisioning schemes), so it only ever worked with FF with PKCS#15
> cards, which are also virtually non-existent except in niche open-source
> communities.
> 
> So I mean, even under today's/yesterday's regime, <keygen> didn't offer
> suitable control to allow a CA to generate such an EV Code Signing cert
> with the necessary assurances.

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