Re: Removal of generateCRMFRequest
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+mozi...@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. Anders Thanks, -NGK Cheers, Brian -- 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:17 PM, Brian Smith wrote: On Sat, Sep 28, 2013 at 7:52 AM, Sean Leonard dev+mozi...@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 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removal of generateCRMFRequest
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+mozi...@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 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removal of generateCRMFRequest
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 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removal of generateCRMFRequest
Do we have telemetry on how frequently these APIs are used? -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removal of generateCRMFRequest
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 -- 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:17 PM, Brian Smith wrote: On Sat, Sep 28, 2013 at 7:52 AM, Sean Leonard dev+mozi...@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 They are to several customers, who have been limping along despite their lack of support. and keygen exists. So CRMF exists to handle missing function in keygen (namely key archival). If you have a way of doing that in the current keygen, then it's probably not a problem to remove CRMF. 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. signText is probably the least used of the three you are talking about removing. 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 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.
--
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 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. -- 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 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 I agree with Bob Relyea's assessment. Many arguments have been advanced for why generateCRMFRequest, PKCS #11 smart card events, and other crypto features should *not* be removed, and I agree with them. In brief: if you have a better and more standardized way of doing things, then invent it and propagate it first before removing functionality that people depend upon for their livelihoods. We have an web app internally that listens to smart card events. There are many other web apps that you may not see on the Web Platform that still use this functionality--they just do not participate in these types of forums. 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 you will see that the Certificate Manager and the Device Manager use this event (and smartcard-remove) to refresh themselves. So even if you remove these events from the webpage, you cannot remove them from Firefox. Our Firefox extension makes use of these events (in addition to the other APIs) so that would directly impact us as well. 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. 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. 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. Removing things (that do not harm security) from the ecosystem goes in the wrong direction. Sean 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 Sat, Sep 28, 2013 at 7:52 AM, Sean Leonard dev+mozi...@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 -- 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 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: 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
Re: Removal of generateCRMFRequest
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. 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 dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removal of generateCRMFRequest
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 dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removal of generateCRMFRequest
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 dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removal of generateCRMFRequest
On Mon, Apr 8, 2013 at 12:10 PM, Anders Rundgren anders.rundg...@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? -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removal of generateCRMFRequest
On 2013-04-08 15:21, helpcrypto helpcrypto wrote: On Mon, Apr 8, 2013 at 12:10 PM, Anders Rundgren anders.rundg...@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? 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 dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removal of generateCRMFRequest
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 dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removal of generateCRMFRequest
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 dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removal of generateCRMFRequest
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 bsm...@mozilla.com 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 dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
