Re: Removal of generateCRMFRequest
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:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removal of generateCRMFRequest
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 dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removal of generateCRMFRequest
On Thu, 2013-09-26 at 16:29 -0700, Brian Smith wrote: On Mon, Apr 8, 2013 at 2:52 AM, helpcrypto helpcrypto helpcry...@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 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removal of generateCRMFRequest
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:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removal of generateCRMFRequest
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 dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removal of generateCRMFRequest
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:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removal of generateCRMFRequest
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:start...@startcom.org Blog: http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removal of generateCRMFRequest
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:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: DetecTor - client side detection of MITM, server impersonation, CA compromise
On Mon, 2013-09-16 at 22:47 +0200, Kai Engert wrote: DetecTor is an open source project to implement client side SSL/TLS MITM detection, compromised CA detection and server impersonation detection, by making use of the Tor network. The integration of transparent client side probing into the NSS SSL library code will take more time (and of course will trigger additional future discussion, whether it actually should be integrated at all, or how). However, I've made progress regarding the server monitoring proposal. I've updated the sphere-probe utility to support continuous probing of services for unexpected certificates, and calling a user defined script for alerting. It's still an early version of the software and I'm looking for feedback and testing. The tool could be used to monitor your own server for network level attacks, such as: - an attacker being close to your server and intercepting requests to your server - global DNS manipulation to redirect requests to a server controlled by an adversary. The tool uses the existing Tor network for probing from multiple remote network locations (Tor exit nodes), and compare the certificate used by a server against a local list of one or multiple expected certificates. The sphere-probe utility (beta) is based on NSS and is available for download from the http://detector.io project page. (Tested on Linux, only, and you'll have to build it yourself, step by step instructions available in the README.) I'm looking forward to your feedback! There's also a new mailing list available, for discussing the project. I'll do most future announcements and project updates on the new list. Regards Kai -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removal of generateCRMFRequest
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 dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removal of generateCRMFRequest
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. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removal of generateCRMFRequest
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'. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removal of generateCRMFRequest
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. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removal of generateCRMFRequest
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. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removal of generateCRMFRequest
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. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removal of generateCRMFRequest
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. 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. 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 smime.p7s Description: S/MIME Cryptographic Signature -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removal of generateCRMFRequest
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 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
