Removal of generateCRMFRequest

classic Classic list List threaded Threaded
41 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Removal of generateCRMFRequest

Brian Smith-31
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
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Removal of generateCRMFRequest

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

/ Jonas

On Mon, Apr 1, 2013 at 2:46 PM, Brian Smith <[hidden email]> 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? 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
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Removal of generateCRMFRequest

Robert Relyea
In reply to this post by Brian Smith-31
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



--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Removal of generateCRMFRequest

Anders Rundgren
In reply to this post by Brian Smith-31
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
>

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Removal of generateCRMFRequest

Jürgen Brauckmann
In reply to this post by Brian Smith-31
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



--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Removal of generateCRMFRequest

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.
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Removal of generateCRMFRequest

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

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

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Removal of generateCRMFRequest

helpcrypto helpcrypto
On Mon, Apr 8, 2013 at 12:10 PM, Anders Rundgren
<[hidden email]> 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?
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Removal of generateCRMFRequest

Anders Rundgren
On 2013-04-08 15:21, helpcrypto helpcrypto wrote:

> On Mon, Apr 8, 2013 at 12:10 PM, Anders Rundgren
> <[hidden email]> 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?

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.


--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Removal of generateCRMFRequest

Brian Smith-19
In reply to this post by helpcrypto helpcrypto
On Mon, Apr 8, 2013 at 2:52 AM, helpcrypto helpcrypto
<[hidden email]> 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)
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Removal of generateCRMFRequest

Eddy Nigg (StartCom Ltd.)
In reply to this post by helpcrypto helpcrypto
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:    [hidden email]
Blog:   http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Removal of generateCRMFRequest

Jürgen Brauckmann
In reply to this post by Brian Smith-19
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
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Removal of generateCRMFRequest

Kai Engert-4
In reply to this post by Brian Smith-19
On Thu, 2013-09-26 at 16:29 -0700, Brian Smith wrote:

> On Mon, Apr 8, 2013 at 2:52 AM, helpcrypto helpcrypto
> <[hidden email]> 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


--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Removal of generateCRMFRequest

Brian Smith-19
In reply to this post by Eddy Nigg (StartCom Ltd.)
On Fri, Sep 27, 2013 at 2:31 AM, Eddy Nigg <[hidden email]> 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?"

Cheers,
Brian
--
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Removal of generateCRMFRequest

Eddy Nigg (StartCom Ltd.)
In reply to this post by Eddy Nigg (StartCom Ltd.)
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.

--
Regards

Signer:  Eddy Nigg, StartCom Ltd.
XMPP:    [hidden email]
Blog:   http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Removal of generateCRMFRequest

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?

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Removal of generateCRMFRequest

Eddy Nigg (StartCom Ltd.)
In reply to this post by Eddy Nigg (StartCom Ltd.)
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.

--
Regards

Signer:  Eddy Nigg, StartCom Ltd.
XMPP:    [hidden email]
Blog:   http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Removal of generateCRMFRequest

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:    [hidden email]
>  Blog:   http://blog.startcom.org/
>  Twitter: http://twitter.com/eddy_nigg
>
>  --
>  dev-tech-crypto mailing list
>  [hidden email]
>  https://lists.mozilla.org/listinfo/dev-tech-crypto
>


--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Removal of generateCRMFRequest

Eddy Nigg (StartCom Ltd.)
In reply to this post by Eddy Nigg (StartCom Ltd.)
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.

--
Regards

Signer:  Eddy Nigg, StartCom Ltd.
XMPP:    [hidden email]
Blog:   http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Removal of generateCRMFRequest

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.

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
123