Removal of generateCRMFRequest

[Brian Smith]

See https://bugzilla.mozilla.org/show_bug.cgi?id=524664 (bug 524664) and
See https://developer.mozilla.org/en-US/docs/JavaScript_crypto/generateCRMFRequest

My understanding is that <keygen> is supposed to replace window.crypto.generateCRMFRequest.

I have no idea how common window.crypto.generateCRMFRequest is. Is it obsolete? Should it be removed? Does anybody have a link to a site that is using it for its intended purpose?

If it is obsolete, I would like to remove it ASAP.

More generally, I would like to remove all the Mozilla-proprietary methods and properties from window.crypto; i.e. all the ones athttps://developer.mozilla.org/en-US/docs/JavaScript_crypto. Some of them are actually pretty problematic. Are there any worth keeping?

Thanks,
Brian

[Jonas Sicking]

I know nothing about these APIs. Other than that some minimal version
of <keygen> is in the HTML5 spec.

/ Jonas

[Robert Relyea]

On 04/01/2013 02:46 PM, Brian Smith wrote:
> See https://bugzilla.mozilla.org/show_bug.cgi?id=524664 (bug 524664) and
> See https://developer.mozilla.org/en-US/docs/JavaScript_crypto/generateCRMFRequest
>
> My understanding is that <keygen> is supposed to replace window.crypto.generateCRMFRequest.

So keygen was first, window.crypto.generateCRMFRequest() was made to fix
some issues (and get some features like key-recovery). The new effort in
<keygen> I think was meant to address those issues.

>
> I have no idea how common window.crypto.generateCRMFRequest is. Is it obsolete? Should it be removed? Does anybody have a link to a site that is using it for its intended purpose?
>
> If it is obsolete, I would like to remove it ASAP.

I'm pretty sure it's still used by produces like this one:
http://pki.fedoraproject.org/wiki/PKI_Main_Page

I don't think you can remove it for a while. Server deployments lag
client features by quite a few years. Servers don't implement new
features supplied in clients until they are release. This type of
feature isn't quite like a normal html feature, where you can update a
.hmtl file or a content manager macro. These tags are usually tied more
closely to the servers that use them.

>
> More generally, I would like to remove all the Mozilla-proprietary methods and properties from window.crypto; i.e. all the ones athttps://developer.mozilla.org/en-US/docs/JavaScript_crypto. Some of them are actually pretty problematic. Are there any worth keeping?

I'd say you probably can't do that wholesale, but you probably can
review and cull this list, particularly if there are good replacements.
>
> Thanks,
> Brian

[Anders Rundgren]

On 2013-04-01 23:46, Brian Smith wrote:
> See https://bugzilla.mozilla.org/show_bug.cgi?id=524664 (bug 524664) and
> See https://developer.mozilla.org/en-US/docs/JavaScript_crypto/generateCRMFRequest
>
> My understanding is that <keygen> is supposed to replace window.crypto.generateCRMFRequest.
>

> I have no idea how common window.crypto.generateCRMFRequest is. Is it obsolete?

The entire certificate system (including soft token storage) is obsolete. All big consumer-PKIs
are deploying their own counterparts since ages ago.

Now with mobile devices with embedded security hardware like in most high-end
Android phones, there's a ocean-wide gap between the browser and platform.

> Should it be removed? Does anybody have a link to a site that is using it for its intended purpose?

You cannot remove until there is an established replacement that matches the
legitimate requirements people have on on-line certificate enrollment.

Anders

> If it is obsolete, I would like to remove it ASAP.
>

> More generally, I would like to remove all the Mozilla-proprietary methods and properties from window.crypto; i.e. all the ones athttps://developer.mozilla.org/en-US/docs/JavaScript_crypto. Some of them are actually pretty problematic. Are there any worth keeping?
>

> Thanks,
> Brian
>

[Jürgen Brauckmann]

Hi.

Brian Smith schrieb:

> See https://bugzilla.mozilla.org/show_bug.cgi?id=524664 (bug 524664) and
> See https://developer.mozilla.org/en-US/docs/JavaScript_crypto/generateCRMFRequest
>
> My understanding is that <keygen> is supposed to replace window.crypto.generateCRMFRequest.
>

> I have no idea how common window.crypto.generateCRMFRequest is. Is it obsolete? Should it be removed? Does anybody have a link to a site that is using it for its intended purpose?

>
> If it is obsolete, I would like to remove it ASAP.
>
> More generally, I would like to remove all the Mozilla-proprietary methods and properties from window.crypto; i.e. all the ones athttps://developer.mozilla.org/en-US/docs/JavaScript_crypto. Some of them are actually pretty problematic. Are there any worth keeping?

Some of these functions are quite useful (in special environments :-) ).

signText() is used heavily by us. It would be a pity to miss it... .
Juergen

[helpcrypto helpcrypto]

>> More generally, I would like to remove all the Mozilla-proprietary methods and properties from window.crypto; i.e. all the
>> ones athttps://developer.mozilla.org/en-US/docs/JavaScript_crypto. Some of them are actually pretty problematic.
>> Are there any worth keeping?
>>

> signText() is used heavily by us. It would be a pity to miss it... .

While awaiting to http://www.w3.org/TR/WebCryptoAPI/ Java applets for
client signning, signText and <keygen> are needed.
Also things like Handling smart card events or Loading PKCS #11
modules is being use by many.
So, you _CANT_ remove https://developer.mozilla.org/en-US/docs/JavaScript_crypto

If you want/need more detailed discussions, dont hesitate to ask me.

[Anders Rundgren]

On 2013-04-08 14:52, helpcrypto helpcrypto wr
ote:

>>> More generally, I would like to remove all the Mozilla-proprietary methods and properties from window.crypto; i.e. all the
>>> ones athttps://developer.mozilla.org/en-US/docs/JavaScript_crypto. Some of them are actually pretty problematic.
>>> Are there any worth keeping?
>>>
>> signText() is used heavily by us. It would be a pity to miss it... .
>
> While awaiting to http://www.w3.org/TR/WebCryptoAPI/ Java applets for
> client signning, signText and <keygen> are needed.

This seems to be out of scope:
http://lists.w3.org/Archives/Public/public-webcrypto/2013Apr/0072.html

[helpcrypto helpcrypto]

On Mon, Apr 8, 2013 at 12:10 PM, Anders Rundgren
<anders....@telia.com> wrote:
> This seems to be out of scope:
> http://lists.w3.org/Archives/Public/public-webcrypto/2013Apr/0072.html

Hi Anders.


As it scopes signning:
http://www.w3.org/TR/WebCryptoAPI/#Crypto-method-sign, I suppose you
mean smartcards are out of scope.

Until theres another alternative (dont you have one? :P), keygen and
smartcard handling could/should remain the same.
As you know, and as we have talked several times, we need something
new/better, but until then, we need to continue supporting this.

Maybe W3C Crypto Group should consider changing their scope to
adopt/propose a new standard for all this?

[Anders Rundgren]

I think there is too much prestige and IPR associated for this to be realistic.

Hordes of patent trolls are just waiting for suing the asses off Google and Microsoft.

[Brian Smith]

On Mon, Apr 8, 2013 at 2:52 AM, helpcrypto helpcrypto
<helpc...@gmail.com> wrote:
>
> While awaiting to http://www.w3.org/TR/WebCryptoAPI/ Java applets for
> client signning, signText and <keygen> are needed.

> Also things like Handling smart card events or Loading PKCS #11
> modules is being use by many.
> So, you _CANT_ remove
> https://developer.mozilla.org/en-US/docs/JavaScript_crypto
>
> If you want/need more detailed discussions, dont hesitate to ask me.

Hi,

Yes, I am interested in hearing why you think we cannot remove these functions.

I have met with several members of our DOM and web API teams and we've
tentatively agreed that we should remove these functions if at all
possible--as soon as 2014Q1. That is, we're hoping to remove all of
window.crypto.* except getRandomValues, and all of window.pkcs11.*
(smart card events). Mozilla's policy about web API removal is to make
an announcement that gives websites at least three releases (18 weeks)
of notice. This is not that announcement, but I hope to make such an
announcement soon.

We don't expect other browsers to ever implement this API, so they are
effectively a Mozilla-proprietary API. We are trying to avoid creating
our own proprietary APIs in the hopes that other browsers will do the
same. You can see some of the guidelines we are working on here:
https://wiki.mozilla.org/User:Overholt/APIExposurePolicy

If we were to try to standardize this functionality, we would almost
definitely have to make substantial changes to the APIs as part of the
standardization process. For example, the current APIs assume some
equivalence relation between RSA key sizes and ECC curve strength.

I think smart card events are especially problematic because they seem
to add additional privacy/fingerprinting exposure.

generateCRMFRequest seems like it can be replaced by some JavaScript +
<keygen> + server-side processing, and we suspect that sites that are
using GenerateCRMFRequest in Firefox must already do this for other
browsers. I understand that <keygen> is not the greatest thing in the
world either, but it has the benefit of at least having a
specification for browsers to follow.

signText seems to be the most difficult thing to remove because there
is no way to emulate its smart card access capabilities with standard
web APIs. At the same time, the way signText works is problematic
enough that I suspect no other browser will ever implement it.

We are working on creating a multi-process sandbox for web content,
similar to the sandboxes used in other web browsers. This is one of
the few remaining APIs that isn't implemented in a
multi-process-friendly manner, and given all the above issues we don't
want to spent time converting it to be multi-process-friendly.

Instead, I would like to figure out what, if any, alternative to
signText we can provide, and also what we need to do to enhance our
<kegen> implementation to help websites migrate away from
generateCRMFRequest.

I am very curious, in particular, what products that use
generateCRMFRequest and/or signText do for other browsers, especially
Chrome.

Cheers,
Brian
--
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)

[Eddy Nigg]

On 09/27/2013 02:29 AM, From Brian Smith:

> I have met with several members of our DOM and web API teams and we've
> tentatively agreed that we should remove these functions if at all
> possible--as soon as 2014Q1. That is, we're hoping to remove all of
> window.crypto.* except getRandomValues, and all of window.pkcs11.*
> (smart card events).

Just for the record, we are using the
window.crypto.enableSmartCardEvents and friends - also note that IE
provides a similar functionality for that.

--
Regards

Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg

[Jürgen Brauckmann]

Brian Smith schrieb:

> Yes, I am interested in hearing why you think we cannot remove these functions.

Well, it would be nice to have an alternative API. If you force us to
move from signText to some other stuff outside Firefox, I'll doubt we'll
switch to WebCryptoAPI again... .

http://www.w3.org/TR/WebCryptoAPI isn't even ready for implementation,
right?

Will there be a method signWithUserConfirmation?
(https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec)

> Instead, I would like to figure out what, if any, alternative to
> signText we can provide, and also what we need to do to enhance our
> <kegen> implementation to help websites migrate away from
> generateCRMFRequest.
>
> I am very curious, in particular, what products that use
> generateCRMFRequest and/or signText do for other browsers, especially
> Chrome.

signText:

CAPICOM.SignedData in IE.

"Not supported" in Chrome and Opera.


Juergen

[Kai Engert]

On Thu, 2013-09-26 at 16:29 -0700, Brian Smith wrote:
> On Mon, Apr 8, 2013 at 2:52 AM, helpcrypto helpcrypto
> <helpc...@gmail.com> wrote:
> >
> > While awaiting to http://www.w3.org/TR/WebCryptoAPI/ Java applets for
> > client signning, signText and <keygen> are needed.
> > Also things like Handling smart card events or Loading PKCS #11
> > modules is being use by many.
> > So, you _CANT_ remove
> > https://developer.mozilla.org/en-US/docs/JavaScript_crypto
> >
> > If you want/need more detailed discussions, dont hesitate to ask me.
>
> Hi,
>

> Yes, I am interested in hearing why you think we cannot remove these functions.

Because they serve a purpose. Removing them is unfriendly and
counterproductive.

Kai

[Brian Smith]

On Fri, Sep 27, 2013 at 2:31 AM, Eddy Nigg <eddy...@startcom.org> wrote:
> On 09/27/2013 02:29 AM, From Brian Smith:
>

>> I have met with several members of our DOM and web API teams and we've
>> tentatively agreed that we should remove these functions if at all
>> possible--as soon as 2014Q1. That is, we're hoping to remove all of
>> window.crypto.* except getRandomValues, and all of window.pkcs11.* (smart
>> card events).
>
>

> Just for the record, we are using the window.crypto.enableSmartCardEvents
> and friends - also note that IE provides a similar functionality for that.

Hi Eddy,

My question is not so much "Is anybody using this functionality" but
rather "What really terrible things, if any, would happen if we
removed them?"

[Brian Smith]

On Fri, Sep 27, 2013 at 2:31 AM, Eddy Nigg <eddy...@startcom.org> wrote:
> On 09/27/2013 02:29 AM, From Brian Smith:
>

>> I have met with several members of our DOM and web API teams and we've
>> tentatively agreed that we should remove these functions if at all
>> possible--as soon as 2014Q1. That is, we're hoping to remove all of
>> window.crypto.* except getRandomValues, and all of window.pkcs11.* (smart
>> card events).
>
>

> Just for the record, we are using the window.crypto.enableSmartCardEvents
> and friends - also note that IE provides a similar functionality for that.

Hi Eddy,

My question is not so much "Is anybody using this functionality" but
rather "What really terrible things, if any, would happen if we
removed them?"

[Eddy Nigg]

On 09/27/2013 08:12 PM, From Brian Smith:

> My question is not so much "Is anybody using this functionality" but
> rather "What really terrible things, if any, would happen if we
> removed them?"

We might have to look for alternatives because when the card is removed
or inserted with can trigger session termination and/or authentication.
Whereas without it the card could be removed and the session would stay
valid like any other session.

[Ryan Sleevi]

On Fri, September 27, 2013 10:29 am, Eddy Nigg wrote:
> On 09/27/2013 08:12 PM, From Brian Smith:

> > My question is not so much "Is anybody using this functionality" but
> > rather "What really terrible things, if any, would happen if we
> > removed them?"
>

> We might have to look for alternatives because when the card is removed
> or inserted with can trigger session termination and/or authentication.
> Whereas without it the card could be removed and the session would stay
> valid like any other session.
>

How do you deal with this in other browsers?

What are the specific features that you need?

Can you think of other ways that might be able to accomplish your goals
without introducing browser-specific APIs to the open web?

If so, what prevents/ed you from using them.

Have you considered approaching the WHATWG or W3C to actually see this
adopted as part of the Web Platform, rather than relying on legacy,
browser-specific solutions that are not standardized, interoperable
behaviour?

[Ryan Sleevi]

On Fri, September 27, 2013 10:29 am, Eddy Nigg wrote:
> On 09/27/2013 08:12 PM, From Brian Smith:

> > My question is not so much "Is anybody using this functionality" but
> > rather "What really terrible things, if any, would happen if we
> > removed them?"
>

[Eddy Nigg]

On 09/27/2013 08:52 PM, From Ryan Sleevi:

>
> How do you deal with this in other browsers?

Well, I don't...so far :-)

However I'm aware of similar capabilities with IE.

> What are the specific features that you need?

Detection of smart card removal or insertion.

> Can you think of other ways that might be able to accomplish your goals
> without introducing browser-specific APIs to the open web?

Maybe an extension, not sure.

> Have you considered approaching the WHATWG or W3C to actually see this
> adopted as part of the Web Platform, rather than relying on legacy,
> browser-specific solutions that are not standardized, interoperable
> behaviour?

No, since it works for us there was never a desire for such a
punishment. Besides that I'm not a browser vendor really.

[Ryan Sleevi]

On Fri, September 27, 2013 1:35 pm, Eddy Nigg wrote:
> On 09/27/2013 08:52 PM, From Ryan Sleevi:
> >

> > How do you deal with this in other browsers?
>

> Well, I don't...so far :-)
>
> However I'm aware of similar capabilities with IE.
>

> > What are the specific features that you need?
>

> Detection of smart card removal or insertion.

Let me try it differently: What actions do you take on this information?

As far as I know, IE doesn't provide the smart card insertion/removal
events, except perhaps through ActiveX.

Why should a web page care about a user's hardware state, given that there
exist no Web APIs to actually leverage this hardware state?

This would be akin to wanting to know about USB events, for which there is
no USB API for in the Web [putting extensions aside for a moment]. Or
wanting to know when the user plugs in a new keyboard or mouse; why should
it matter?

I enthusiastically welcome Brian's proposal to remove these non-standard
features from the Web Platform, and am trying to get a better
understanding about what the actual use case is for them (as I believe
Brian is as well), in order to understand what, if anything, should
replace them.

Note that I do not (at this point) believe a replacement needs to be
implemented before removing them, but I suppose that's contingent on
finding what the actual use case is.

>
> > Can you think of other ways that might be able to accomplish your goals
> > without introducing browser-specific APIs to the open web?
>

> Maybe an extension, not sure.
>

> > Have you considered approaching the WHATWG or W3C to actually see this
> > adopted as part of the Web Platform, rather than relying on legacy,
> > browser-specific solutions that are not standardized, interoperable
> > behaviour?
>

> No, since it works for us there was never a desire for such a
> punishment. Besides that I'm not a browser vendor really.
>
> --
> Regards
>
> Signer: Eddy Nigg, StartCom Ltd.
> XMPP: star...@startcom.org
> Blog: http://blog.startcom.org/
> Twitter: http://twitter.com/eddy_nigg
>

> --
> dev-tech-crypto mailing list
> dev-tec...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>

[Eddy Nigg]

On 09/27/2013 11:52 PM, From Ryan Sleevi:

> Let me try it differently: What actions do you take on this information?

Terminating a current session or triggering authentication to a new session.

> As far as I know, IE doesn't provide the smart card insertion/removal
> events, except perhaps through ActiveX.

Yes exactly.

> Why should a web page care about a user's hardware state, given that there
> exist no Web APIs to actually leverage this hardware state?

Consider a banking site or others like administrative sites that use
client certificates (provided on a smart card) .

> This would be akin to wanting to know about USB events, for which there is
> no USB API for in the Web [putting extensions aside for a moment]. Or
> wanting to know when the user plugs in a new keyboard or mouse; why should
> it matter?

Probably because we like to use a browser for such tasks instead of
implementing a dedicated UI. And client certificates (which may be used
on smart cards) are part of the browser capabilities.

[Ryan Sleevi]

On Fri, September 27, 2013 2:22 pm, Eddy Nigg wrote:
> On 09/27/2013 11:52 PM, From Ryan Sleevi:

> > Let me try it differently: What actions do you take on this information?
>

> Terminating a current session or triggering authentication to a new
> session.

When you define session, what do you mean here?

NSS already performs checking that the given smart card used to
authenticate is present whenever encrypting or decrypting data. This
includes cached session resumption as well.

This does not seem like it's a capability that needs to be or should be
exposed at the platform layer. At best, it seems like a proposal to change
how Firefox handles SSL in the browser, which may either be a feature
request or bug of PSM or NSS - but not a Web API.

If you're not relying on that client-authenticated SSL session, then it
sounds like an application design issue on your web apps side, rather than
something missing from the Web Platform.

>
> > As far as I know, IE doesn't provide the smart card insertion/removal
> > events, except perhaps through ActiveX.
>

> Yes exactly.

>
> > Why should a web page care about a user's hardware state, given that
> > there
> > exist no Web APIs to actually leverage this hardware state?
>

> Consider a banking site or others like administrative sites that use
> client certificates (provided on a smart card) .
>

> > This would be akin to wanting to know about USB events, for which there
> > is
> > no USB API for in the Web [putting extensions aside for a moment]. Or
> > wanting to know when the user plugs in a new keyboard or mouse; why
> > should
> > it matter?
>

> Probably because we like to use a browser for such tasks instead of
> implementing a dedicated UI. And client certificates (which may be used
> on smart cards) are part of the browser capabilities.

Yes, but a website has no knowledge about whether or not the given client
certificate is on a smart card (nor can it, at least without out of band
knowledge).

This certainly doesn't seem like a use case that fits the web security
model, so I'm still trying to refine and understand what you're discussing
here.

[Eddy Nigg]

On 09/28/2013 12:45 AM, From Ryan Sleevi:

> NSS already performs checking that the given smart card used to
> authenticate is present whenever encrypting or decrypting data. This
> includes cached session resumption as well.

Not SSL session of course, but on the web application layer.

> If you're not relying on that client-authenticated SSL session, then it
> sounds like an application design issue on your web apps side, rather than
> something missing from the Web Platform.

Of course, how can the web application know if a smart card is removed
otherwise? It must get that input from somewhere, doesn't it?

> Yes, but a website has no knowledge about whether or not the given

> client certificate is on a smart card.

The web site probably not, but the web site operator - there are banks,
health services and others (like us) that use smart cards knowing that
the client certificate exists only in a smart card.

> This certainly doesn't seem like a use case that fits the web security
> model, so I'm still trying to refine and understand what you're
> discussing here.

As explained - if a client certificate exists only on a smart card (by
design enforced) and that cert is used for authentication, if the card
is removed I want to trigger termination of the current session (call it
log out) and if the card is inserted again authentication is performed
again.

That's the functionality which window.crypto.enableSmartCardEvents
provides that is discussed here for removal. I assume it was put into
the capabilities of FF exactly for this purpose in first place.

[Ryan Sleevi]

On Fri, September 27, 2013 3:46 pm, Eddy Nigg wrote:
> On 09/28/2013 12:45 AM, From Ryan Sleevi:

> > NSS already performs checking that the given smart card used to
> > authenticate is present whenever encrypting or decrypting data. This
> > includes cached session resumption as well.
>

> Not SSL session of course, but on the web application layer.
>

> > If you're not relying on that client-authenticated SSL session, then it
> > sounds like an application design issue on your web apps side, rather
> > than
> > something missing from the Web Platform.
>

> Of course, how can the web application know if a smart card is removed
> otherwise? It must get that input from somewhere, doesn't it?
>

> > Yes, but a website has no knowledge about whether or not the given

> > client certificate is on a smart card.
>
> The web site probably not, but the web site operator - there are banks,
> health services and others (like us) that use smart cards knowing that
> the client certificate exists only in a smart card.
>

> > This certainly doesn't seem like a use case that fits the web security
> > model, so I'm still trying to refine and understand what you're
> > discussing here.
>

> As explained - if a client certificate exists only on a smart card (by
> design enforced) and that cert is used for authentication, if the card
> is removed I want to trigger termination of the current session (call it
> log out) and if the card is inserted again authentication is performed
> again.
>
> That's the functionality which window.crypto.enableSmartCardEvents
> provides that is discussed here for removal. I assume it was put into
> the capabilities of FF exactly for this purpose in first place.
>

I'm sorry, but what you just described seems entirely unnecessary.

If your site requires a client certificate, and you know that a client
certificate is stored in a smart card, then you also know that when using
Firefox, and the smart card is removed, Firefox will invalidate that
SSL/TLS session.

Because your site requires a client certificate, their current session is
thus terminated. When they attempt to establish a new SSL/TLS session,
your site will again require a client certificate, and they either insert
a smart card or they don't.

Such an API seems entirely unnecessary - 'it just works' like above.

It sounds like you're using a weaker security guarantee though - namely,
that you're not requiring SSL/TLS client certificate authentication, and
thus want some other out of band way to know when the user removed their
smart card. The interoperable solution is simple - don't do that. When the
user removes their smart card, the SSL/TLS session is invalidated, and the
user is 'logged out'.

[Eddy Nigg]

On 09/28/2013 01:59 AM, From Ryan Sleevi:

> If your site requires a client certificate, and you know that a client
> certificate is stored in a smart card, then you also know that when using
> Firefox, and the smart card is removed, Firefox will invalidate that
> SSL/TLS session.

Not really - except in case you require the cert authentication on every
exchange between the client and server. I don't believe that many do
this as it makes it incredible slow and some browser will prompt for the
certificate over an over again.

> When the user removes their smart card, the SSL/TLS session is invalidated, and the
> user is 'logged out'.

Kind of, he'll get the infamous ssl_error_handshake_failure_alert error
that nobody knows what it is, but that's not how such web apps are
usually implemented. They do the client authentication dance once and
continue with a application controlled session.

[Ryan Sleevi]

On Fri, September 27, 2013 4:09 pm, Eddy Nigg wrote:
> On 09/28/2013 01:59 AM, From Ryan Sleevi:

> > If your site requires a client certificate, and you know that a client
> > certificate is stored in a smart card, then you also know that when
> > using
> > Firefox, and the smart card is removed, Firefox will invalidate that
> > SSL/TLS session.
>

> Not really - except in case you require the cert authentication on every
> exchange between the client and server. I don't believe that many do
> this as it makes it incredible slow and some browser will prompt for the
> certificate over an over again.

But Firefox (and Chrome, IE, Safari, and Opera) won't.

I'm not sure FIrefox supporting some non-Web Platform feature on the basis
that some other browser makes it hard, especially when the number of
browsers that support the feature beyond Firefox is 0.

>
> > When the user removes their smart card, the SSL/TLS session is
> > invalidated, and the
> > user is 'logged out'.
>

> Kind of, he'll get the infamous ssl_error_handshake_failure_alert error
> that nobody knows what it is, but that's not how such web apps are
> usually implemented. They do the client authentication dance once and
> continue with a application controlled session.

And such webapps could presumably use iframes or XHRs with a background
refresh to a login domain, and when such a fetch fail, know the smart card
was removed, and thus treat it as the same. All without non-standard
features being exposed.

[Ryan Sleevi]

On Fri, September 27, 2013 4:09 pm, Eddy Nigg wrote:
> On 09/28/2013 01:59 AM, From Ryan Sleevi:

> > If your site requires a client certificate, and you know that a client
> > certificate is stored in a smart card, then you also know that when
> > using
> > Firefox, and the smart card is removed, Firefox will invalidate that
> > SSL/TLS session.
>

> Not really - except in case you require the cert authentication on every
> exchange between the client and server. I don't believe that many do
> this as it makes it incredible slow and some browser will prompt for the
> certificate over an over again.

But Firefox (and Chrome, IE, Safari, and Opera) won't.

I'm not sure FIrefox supporting some non-Web Platform feature on the basis
that some other browser makes it hard, especially when the number of
browsers that support the feature beyond Firefox is 0.

>

> > When the user removes their smart card, the SSL/TLS session is
> > invalidated, and the
> > user is 'logged out'.
>

[Ryan Sleevi]

On Fri, September 27, 2013 5:51 pm, Robert Relyea wrote:

>
>
> On 09/27/2013 05:01 PM, Ryan Sleevi wrote:
> > On Fri, September 27, 2013 4:09 pm, Eddy Nigg wrote:
> >> On 09/28/2013 01:59 AM, From Ryan Sleevi:

> >>> If your site requires a client certificate, and you know that a client
> >>> certificate is stored in a smart card, then you also know that when
> >>> using
> >>> Firefox, and the smart card is removed, Firefox will invalidate that
> >>> SSL/TLS session.

> >> Not really - except in case you require the cert authentication on
> >> every
> >> exchange between the client and server. I don't believe that many do
> >> this as it makes it incredible slow and some browser will prompt for
> >> the
> >> certificate over an over again.
> > But Firefox (and Chrome, IE, Safari, and Opera) won't.
> >
> > I'm not sure FIrefox supporting some non-Web Platform feature on the
> > basis
> > that some other browser makes it hard, especially when the number of
> > browsers that support the feature beyond Firefox is 0.

> Ryan is correct. What FF does not do is reload the page when the smart
> card is removed. The most common use of smart card events is forcing the
> reloading the page.
>
> NOTE: there is still an issue that Firefox doesn't provide a way for the
> web page to flush it's own cache. If you've made a connection without a
> cert, there's no way to say try again with the cert. This doesn't affect
> removal, but it does affect insertion.

FWIW, Chrome does. We're working on refining this. But that's not a
standard behaviour, and if sites want to rely on that, they should rely on
standards-defined behaviours.

> >
> >>> When the user removes their smart card, the SSL/TLS session is
> >>> invalidated, and the
> >>> user is 'logged out'.

> >> Kind of, he'll get the infamous ssl_error_handshake_failure_alert
> >> error
> >> that nobody knows what it is, but that's not how such web apps are
> >> usually implemented. They do the client authentication dance once and
> >> continue with a application controlled session.
>

> Actually FF does a full handshake, what kind of error you get depends on
> what bits the server said. If you pass request not require, then the
> handshake completes with the server getting no cert for the connection.

> > And such webapps could presumably use iframes or XHRs with a background
> > refresh to a login domain, and when such a fetch fail, know the smart
> > card
> > was removed, and thus treat it as the same. All without non-standard
> > features being exposed.

> You still don't get the page refresh when the smart card is removed.

But you don't need that in the iframe/XHR situation. You can implement a
variety of techniques (hanging gets, COMET, meta refresh, etc) to
accomplish this.

>
> I don't have a problem with going for an industry standard way of doing
> all of these things, but it's certainly pretty presumptuous to remove
> these features without supplying the industry standard replacements and
> time for them to filter through the internet.
>
> bob

Bob,

The fact that these are problems that sites MUST solve for other browsers,
I don't see why it's necessary to find a replacement first.

I realize that some might find this functionality to make Firefox more
compelling. People found ActiveX compelling. That does not mean it's good
for the Internet at large, or the Web Platform.

I certainly am not one to make decisions about Firefox's goals for the Web
Platform, given what I work on, but I applaud efforts to remove
non-standard features and to standardize features. But I don't think one
must be held hostage to the other - the fact that these problems exist for
other UAs means that the only sites that will be affected are those coded
*specifically* to be Firefox only - and that does not a good Internet
make.

Cheers,
Ryan

[Eddy Nigg]

On 09/28/2013 03:51 AM, From Robert Relyea:

>
> Ryan is correct. What FF does not do is reload the page when the smart
> card is removed. The most common use of smart card events is forcing the
> reloading the page.

Correct - and the current session on the application level can be
invalidated. Something like this:

window.crypto.enableSmartCardEvents=true;
document.addEventListener("smartcard-insert",function () {
doLogin();
},false);
document.addEventListener("smartcard-remove",function () {
doLogout();
},false);
}

You can do all kind of interesting things then...

> NOTE: there is still an issue that Firefox doesn't provide a way for the
> web page to flush it's own cache. If you've made a connection without a
> cert, there's no way to say try again with the cert. This doesn't affect
> removal, but it does affect insertion.

That's a different issue, but it would be an interesting improvement if
the handshake failed, keep prompting for a (different) certificate
without having to restart the browser.

> Actually FF does a full handshake, what kind of error you get depends
> on what bits the server said. If you pass request not require, then
> the handshake completes with the server getting no cert for the
> connection.

Right, but I don't like this really.

[Eddy Nigg]

On 09/28/2013 04:14 AM, From Ryan Sleevi:

> I certainly am not one to make decisions about Firefox's goals for the
> Web Platform, given what I work on, but I applaud efforts to remove
> non-standard features and to standardize features. But I don't think
> one must be held hostage to the other - the fact that these problems
> exist for other UAs means that the only sites that will be affected
> are those coded *specifically* to be Firefox only - and that does not
> a good Internet make.

I'd agree,but the approach taken here is probably the wrong one - first
identify if there is a need for such a functionality, go to the
standards bodies and propose one, then implement and remove the
non-standard functions.

I believe there are a few smart card related functions that could do
some good.

[Brian Smith]

On Sat, Sep 28, 2013 at 7:52 AM, Sean Leonard <dev+m...@seantek.com> wrote:

> On 9/27/2013 5:51 PM, Robert Relyea wrote:
>>
>> I don't have a problem with going for an industry standard way of doing
>> all of these things, but it's certainly pretty presumptuous to remove these
>> features without supplying the industry standard replacements and time for
>> them to filter through the internet. bob

Why isn't <keygen> good enough?

AFAICT, based on this discussion and others, smart card events are not
a must-have feature for any website. They are a nice-to-have, at best.
At worst, they are the wrong model altogether. Either way,
clearcutting them to make our sandboxing project easier and faster to
complete still seems to make sense for me. I understand that that
isn't the most friendly strategy towards the websites that are using
that feature, but it is extremely unfriendly (at best) of us toward
hundreds of millions of people to be giving them a browser without a
sandbox. Sandboxing is a must-have-ASAP feature.

> In addition, it would be a great shame to remove this set of APIs from
> Firefox because the Mozilla platform itself uses them for chrome-privileged
> purposes. If you search "smartcard-insert", for example:
> http://mxr.mozilla.org/mozilla-central/search?string=smartcard-insert

> Our
> Firefox extension makes use of these events (in addition to the other APIs)
> so that would directly impact us as well.

Good point. We can still keep them around in chrome-privileged
contexts because chrome-context stuff lives in the parent process and
so would not be affected by sandboxing. So, if we preserved the
chrome-context stuff, would your extensions still work?

> It is one thing to remove the <blink> tag, which most users have found
> annoying or harmful (epilepsy). Removing crypto functionality in contrast
> impacts critical security functionality for many users.

Again, smartcard events don't seem like critical functionality and
<keygen> exists. signText is the only API I can see where there is no
replacement and that would be difficult to go without. But, it is also
problematic because of its UI; I don't think its UI is sufficiently
clear and bulletproof that it is really effective at conveying exactly
what is being signed--especially when you consider
internationalization and localization issues.

> The Internet is made good when people can use it to do productive work.
> Removing functionality that is used by vendors and users for no reason other
> than "purity" is unproductive and costly.

My main motivation is to make the sandboxing project easier to
complete ASAP. The WebAPI team has the "purity" goal and it isn't my
place to judge that, as I don't know as much as they do about the web
API standardization situation.

> By the logic of "purity",
> XMLHttpRequest should have been removed a long time ago because it was an
> IE-proprietary feature. The "open web" is an ecosystem of server-side and
> client-side technologies where everyone can innovate by introducing new
> things. If it's a useful feature, you can copy it.

XHR became standardized. Which of the Mozilla-proprietary APIs in
window.crypto.* do you think has any chance at all of standardization?
Ryan Sleevi is on the Chrome team and works on the W3C Web Crypto API
spec., and based on what he's written, he seems to agree with me that
they don't.

I also agree with Ryan that we don't have to feel committed to these
APIs just because we implemented them back when we were trying to make
money selling the enterprise server software that these APIs were
created to support. So, I'm not going to predicate the removal of
these APIs on the creation of replacements. However, there's no reason
why this community can't help formulate, standardize, and even
implement the replacements before we ship a browser without these
APIs. In fact, everybody at Mozilla would love for that to happen.
But, also, I don't think we're going to be sad if we ship a sandboxed
browser without any such APIs.

Cheers,
Brian

[sst...@mozilla.com]

Do we have telemetry on how frequently these APIs are used?

[Brian Smith]

sst...@mozilla.com wrote:
> Do we have telemetry on how frequently these APIs are used?

I expect that, of the small percentage of people that are using these APIs, they are using them (except signText) very infrequently--like once a year. When I talked to Ehsan and Andrew Overholt about this, we agreed that the numbers would be pretty meaningless because telemetry is per browser session and we can't track users longitudinally. Also note that telemetry may under-count Red Hat's customers, as I imagine many of them are running in networks where administrators disable telemetry, and also they are all running the ESR release, I think. Finally, I suspect that any use of signText() is highly localized to specific reasons, which we also cannot capture with Telemetry, AFAICT.

Regardless, I am willing to add telemetry to verify that these APIs are not being used shockingly often. But first, let's decide on what the threshold for making a decision would be. For example, let's say the number comes back as less than 1/1000 of sessions are using these APIs. Would that be considered evidence in favor of removal?

Cheers,
Brian

[Nathan Kinder]

On 09/28/2013 12:17 PM, Brian Smith wrote:
> On Sat, Sep 28, 2013 at 7:52 AM, Sean Leonard <dev+m...@seantek.com> wrote:
>> On 9/27/2013 5:51 PM, Robert Relyea wrote:
>>>
>>> I don't have a problem with going for an industry standard way of doing
>>> all of these things, but it's certainly pretty presumptuous to remove these
>>> features without supplying the industry standard replacements and time for
>>> them to filter through the internet. bob
>
> Why isn't <keygen> good enough?

There is no support for key archival with <keygen>, which is supported
by generateCRMFRequest. We heavily rely on generateCRMFRequest in
Dogtag Certificate System (and Red Hat Certificate System), and key
archival is one of the features that we use.

I'm all for a standardized replacement, but it seems wrong to rip out
something that has been a nice functional feature that people have come
to rely on for many years before a replacement is available.

Thanks,
-NGK

>
> Cheers,
> Brian
>

[Anders Rundgren]

On 2013-10-10 01:36, Nathan Kinder wrote:
> On 09/28/2013 12:17 PM, Brian Smith wrote:

>> On Sat, Sep 28, 2013 at 7:52 AM, Sean Leonard <dev+m...@seantek.com> wrote:
>>> On 9/27/2013 5:51 PM, Robert Relyea wrote:
>>>>
>>>> I don't have a problem with going for an industry standard way of doing
>>>> all of these things, but it's certainly pretty presumptuous to remove these
>>>> features without supplying the industry standard replacements and time for
>>>> them to filter through the internet. bob
>>
>> Why isn't <keygen> good enough?
>
>

> There is no support for key archival with <keygen>, which is supported
> by generateCRMFRequest. We heavily rely on generateCRMFRequest in
> Dogtag Certificate System (and Red Hat Certificate System), and key
> archival is one of the features that we use.
>
> I'm all for a standardized replacement, but it seems wrong to rip out
> something that has been a nice functional feature that people have come
> to rely on for many years before a replacement is available.

Since keygen and generateCRMFRequest are 18 respective 12
years old this seems to be a rather reasonable request.

I.e. we can probably not expect a suitable replacement until 2020 or so.

Anders

>
> Thanks,
> -NGK
>
>>
>> Cheers,
>> Brian
>>
>

[Sean Leonard]

On 10/9/2013 4:36 PM, Nathan Kinder wrote:
>
> I'm all for a standardized replacement, but it seems wrong to rip out
> something that has been a nice functional feature that people have
> come to rely on for many years before a replacement is available.

Also (in support of preserving, NOT removing, generateCRMFRequest):

CRMF is in fact an Internet Standards Track format/protocol, documented
in both RFC 2511 and RFC 4211. See <http://tools.ietf.org/html/rfc4211>.
Anyone can implement it. So as to the argument that this format is
"Mozilla proprietary": no it's not, the format at least is a standard,
and there is no other widely deployed client-side method of generating
such requests.

-Sean

[Anders Rundgren]

On 2013-10-10 01:36, Nathan Kinder wrote:
> On 09/28/2013 12:17 PM, Brian Smith wrote:

>> On Sat, Sep 28, 2013 at 7:52 AM, Sean Leonard <dev+m...@seantek.com> wrote:
>>> On 9/27/2013 5:51 PM, Robert Relyea wrote:
>>>>
>>>> I don't have a problem with going for an industry standard way of doing
>>>> all of these things, but it's certainly pretty presumptuous to remove these
>>>> features without supplying the industry standard replacements and time for
>>>> them to filter through the internet. bob
>>
>> Why isn't <keygen> good enough?
>
>

> There is no support for key archival with <keygen>, which is supported
> by generateCRMFRequest. We heavily rely on generateCRMFRequest in
> Dogtag Certificate System (and Red Hat Certificate System), and key
> archival is one of the features that we use.
>

> I'm all for a standardized replacement, but it seems wrong to rip out
> something that has been a nice functional feature that people have come
> to rely on for many years before a replacement is available.

Since keygen and generateCRMFRequest are 18 respective 12
years old this seems to be a rather reasonable request.

I.e. we can not expect a suitable replacement until 2020 or so.

[helpcrypto helpcrypto]

Hi all


I will first apologize for the long delay on my answer, but i had surgery
so i need to recover. Im sure all of you will understand.

Just FYI:
<keygen> is used to generate keys for user certificates that have 3 year
expiration date (so telemetry shouldnt be significant without context).
Smartcard events are used to be "more confident" that the user has inserted
the card before keygen, otherwise keys will be stored on browser (anyway,
we cant be 100% sure the key was generated "inside" the card)
You can guess what we use signText to.

I'll lovely destroy, crash and smash and kill those interfaces as soon as
we have an alternative.
If the current alternative is Java (actually it is for signature, but a
headhache) ill pray/beg you to continue supporting keygen and signText

We all need Webcrypto (both signing but keydiscovery API).
I know Anders supports another approach, but can we have something better
than applets?

My two cents.

[helpcrypto helpcrypto]

On Tue, Oct 15, 2013 at 8:39 PM, Anders Rundgren <
anders.ru...@gmail.com> wrote:

> Anders does definitely not object to using WebCrypto but he just don't
> understand (he's probably a moron) how WebCrypto's key-discovery API can
> be used for smart cards and similar.
>

Damn guy!
I'll love a way to specify PKCS#11 module name (as stated in current
NSS/Secmod) to be able to keygen or retrieve keyhandles (not public keys,
regarding privacy issues) e.g.:
handle=selectCertDialog("MyPKCS11",<filter>) where filter specify a filter
like issuer="x", serial="x"...



>
> Maybe the Mozilla folks owe us an explanation?
>
> my two öres (about 0.3 cents)
>

Yet using gold? Stil a pirate?


>
> Anders
>
Thanks a lot!!!

PS: What happened to telia address?

[Anders Rundgren]

Anders does definitely not object to using WebCrypto but he just don't
understand (he's probably a moron) how WebCrypto's key-discovery API can
be used for smart cards and similar.

Maybe the Mozilla folks owe us an explanation?

my two öres (about 0.3 cents)

Anders

>
> My two cents.
>