Re: Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation
Ian G wrote: On 9/1/09 13:02, Michael Ströder wrote: Fost1954 wrote: I do not want to be offending, but a simple I think so-answer does not satisfy most of the Firefox-Thawte Users,... I also do not want to be offending but if you're asking questions like this you have to be prepared to understand the technical answers. Thinking about it, the way I would have gained confidence would be to have one tool generate the key and the CSR, and then use another tool to transmit the CSR and receive the cert. Feel free to use certutil at the command-line to generate a PKCS#10-formatted CSR and pass that into the CA's web interface. Most users will not be capable of doing so though. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation
Thank you, ecellent dickussion and conclusion we arrived to. I understand the general consensus is that the statement about unnotified key transmission to Thawte is correct, saying: I know of no way, rather than there is no way. (As Nelson Bolyard wrote). We are all aware that there is no 100% answer (as always in life), but I assume your knowledge has some weight. This answer I think is acceptable and worth posting in other Forums (e.g. Thunderbird and/or Firefox, where this answer yould not be given). If you allow me I would cite some of our conclusions given here. Are there any privacy-concerns about citations ? (I will not post any E-Mail Adress). Please let me know. I will not do any citation if you do not want it. Further: Nelson Bolyard wrote: Fost, You might be able to get some developer who works in a part of the browser unrelated to crypto to make a stronger statement about this. But those folks don't participate in this mailing list/newsgroup, so you'll have to ask the question elsewhere to get such an answer. Who else would you propose asking ? Thanky you, 2009/1/10 Robert Relyea rrel...@redhat.com Fost1954 wrote: Bob wrote: So it turns out even with crmf, escrow does not happen quietly. If the CA requests a key be escrowed, the user is notified: Sorry, Bob, but it becomes too technical for my knowledge, I do not know what crmf is, nor do I know what tokens etc.are, so speaking honestly: I do not understand your conclusion, even though the words escrow does not happen quietly sound positive. Could you or any Firefox developer/programmer answer to my question (see below): I had missed the other thread (catching up on vacation email). My technical answer is pretty much what was described in the thread. 1. Is there a dev-tech-crypto / Firefox developer/programmer who wants to confirm Kaspar Band's idea that running Firefox in Safe Mode when generating the key as well as requesting the Certificate with Thawte does securely prevent unnotified private key transmission ? As a crypto guy, I don't know what hooks Firefox gives pluggins and such. You are certainly safe with getting a certificate from Thawte, however. If they escrowed the key you would know it. In some sense there is little incentive for a CA to hide the fact that they are escrowing keys. They can certainly fake being you without any key you give them (they simply generate their own key and sign a certificate with your name in it). A CA that does escrowing would only do so if it's offering some key recovery service (if you loose your key you can recover it from us). CA's that try to escrow without being up front risk public exposure and loss of market share. Short answer: I personally would worry about it, but I can't give you a definative answer (since the code in question is well outside the crypto code). I do not want to be offending, I don't think asking questions, and trying to get clarification is offending. That's what the list is for. bob but a simple I think so-answer does not satisfy most of the Firefox-Thawte Users,... Thank you ! ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation
Fost1954 wrote: Bob wrote: So it turns out even with crmf, escrow does not happen quietly. If the CA requests a key be escrowed, the user is notified: Sorry, Bob, but it becomes too technical for my knowledge, I do not know what crmf is, nor do I know what tokens etc.are, so speaking honestly: I do not understand your conclusion, even though the words escrow does not happen quietly sound positive. Could you or any Firefox developer/programmer answer to my question (see below): 1. Is there a dev-tech-crypto / Firefox developer/programmer who wants to confirm Kaspar Band's idea that running Firefox in Safe Mode when generating the key as well as requesting the Certificate with Thawte does securely prevent unnotified private key transmission ? I do not want to be offending, but a simple I think so-answer does not satisfy most of the Firefox-Thawte Users,... I also do not want to be offending but if you're asking questions like this you have to be prepared to understand the technical answers. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation
On 9/1/09 13:02, Michael Ströder wrote: Fost1954 wrote: Bob wrote: So it turns out even with crmf, escrow does not happen quietly. If the CA requests a key be escrowed, the user is notified: Sorry, Bob, but it becomes too technical for my knowledge, I do not know what crmf is, nor do I know what tokens etc.are, so speaking honestly: I do not understand your conclusion, even though the words escrow does not happen quietly sound positive. Could you or any Firefox developer/programmer answer to my question (see below): 1. Is there a dev-tech-crypto / Firefox developer/programmer who wants to confirm Kaspar Band's idea that running Firefox in Safe Mode when generating the key as well as requesting the Certificate with Thawte does securely prevent unnotified private key transmission ? I do not want to be offending, but a simple I think so-answer does not satisfy most of the Firefox-Thawte Users,... I also do not want to be offending but if you're asking questions like this you have to be prepared to understand the technical answers. I actually appreciate the question, I stumbled across the very same thing a couple of months ago, when the UI gave no clear indication of what it had and had not done, including any security that the keys-security model had been followed. (I think the answer is no, but I'm wondering what others will say.) Thinking about it, the way I would have gained confidence would be to have one tool generate the key and the CSR, and then use another tool to transmit the CSR and receive the cert. I think it is fairly clear that the end-user has a great deal of trouble asking questions. And when they are on point as this one is, there is a great deal of trouble answering them! iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation
CRMF is the mechanism by which a CA can request escrow. It is the ONLY mechanism by which a CA can request escrow. Even when CRMF is not disabled, there is always a dialog that comes up when a CA requests escrow. This has been answered several times in this thread. -Kyle H 2009/1/8 Fost1954 fost19...@googlemail.com: Bob wrote: So it turns out even with crmf, escrow does not happen quietly. If the CA requests a key be escrowed, the user is notified: Sorry, Bob, but it becomes too technical for my knowledge, I do not know what crmf is, nor do I know what tokens etc.are, so speaking honestly: I do not understand your conclusion, even though the words escrow does not happen quietly sound positive. Could you or any Firefox developer/programmer answer to my question (see below): 1. Is there a dev-tech-crypto / Firefox developer/programmer who wants to confirm Kaspar Band's idea that running Firefox in Safe Mode when generating the key as well as requesting the Certificate with Thawte does securely prevent unnotified private key transmission ? I do not want to be offending, but a simple I think so-answer does not satisfy most of the Firefox-Thawte Users,... Thank you ! 2009/1/7 Robert Relyea rrel...@redhat.com Eddy Nigg wrote: On 12/27/2008 12:44 AM, Subrata Mazumdar: A related question: Is it possible to configure the NSS Soft-Token associated with the internal slot like smart-card based token so that the private key key cannot be exported out of the token? If not, would it be useful feature to support? Even in the token case, this is only true if the key was generated in the token. If 'key recovery' is turned on, NSS generates the key in softoken and writes it to the token (after wrapping it with the escrow key). So it turns out even with crmf, escrow does not happen quietly. If the CA requests a key be escrowed, the user is notified: http://mxr.mozilla.org/firefox/source/security/manager/ssl/src/nsCrypto.cpp#1905 bob ___ 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 ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation
Fost1954 wrote, On 2009-01-08 14:39: Could you or any Firefox developer/programmer answer to my question (see below): 1. Is there a dev-tech-crypto / Firefox developer/programmer who wants to confirm Kaspar Band's idea that running Firefox in Safe Mode when generating the key as well as requesting the Certificate with Thawte does securely prevent unnotified private key transmission ? The question being asked here is equivalent to asking some developer to go on record saying that there is ABSOLUTELY NO WAY for the escrow warning to be suppressed in a browser running without extensions (which is what safe mode does). I think no developer is willing to do that, for the simple reason that Firefox is a enormous body of code, and I doubt that anyone alive claims to know how every part of it works. (*) This question concerns a part of the browser code that is pretty far removed from the crypto code. It concerns the code that displays rendered messages in windows, and that is not where the crypto developers' expertise lies. But I think the strongest statement you're going to get from any developer will say I know of no way, rather than there is no way. I do not want to be offending, but a simple I think so-answer does not satisfy most of the Firefox-Thawte Users,... Kaspar is one of a very tiny number of Firefox developers who have a good understanding of both the crypto code and (some large part of) the general browser code. I interpret his answer as saying that he believes the statement to be true based on his knowledge of the product, but that he is mindful that (as with all Mozilla developers) his knowledge of Firefox may be incomplete, and so doesn't want to say with certainty that it is true. With that interpretation, Kaspar's answer is good enough for me. But that's only my interpretation. I'm trying not to put those words in Kaspar's mouth. Kaspar, feel free to correct my interpretation. Fost, You might be able to get some developer who works in a part of the browser unrelated to crypto to make a stronger statement about this. But those folks don't participate in this mailing list/newsgroup, so you'll have to ask the question elsewhere to get such an answer. (*): I know this is one of Ian's concerns. Ian, you're already on record about that, so I think that point need not be embellished in this thread. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation
Bob wrote: So it turns out even with crmf, escrow does not happen quietly. If the CA requests a key be escrowed, the user is notified: Sorry, Bob, but it becomes too technical for my knowledge, I do not know what crmf is, nor do I know what tokens etc.are, so speaking honestly: I do not understand your conclusion, even though the words escrow does not happen quietly sound positive. Could you or any Firefox developer/programmer answer to my question (see below): 1. Is there a dev-tech-crypto / Firefox developer/programmer who wants to confirm Kaspar Band's idea that running Firefox in Safe Mode when generating the key as well as requesting the Certificate with Thawte does securely prevent unnotified private key transmission ? I do not want to be offending, but a simple I think so-answer does not satisfy most of the Firefox-Thawte Users,... Thank you ! 2009/1/7 Robert Relyea rrel...@redhat.com Eddy Nigg wrote: On 12/27/2008 12:44 AM, Subrata Mazumdar: A related question: Is it possible to configure the NSS Soft-Token associated with the internal slot like smart-card based token so that the private key key cannot be exported out of the token? If not, would it be useful feature to support? Even in the token case, this is only true if the key was generated in the token. If 'key recovery' is turned on, NSS generates the key in softoken and writes it to the token (after wrapping it with the escrow key). So it turns out even with crmf, escrow does not happen quietly. If the CA requests a key be escrowed, the user is notified: http://mxr.mozilla.org/firefox/source/security/manager/ssl/src/nsCrypto.cpp#1905 bob ___ 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: Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation
Eddy Nigg wrote: On 12/27/2008 12:44 AM, Subrata Mazumdar: A related question: Is it possible to configure the NSS Soft-Token associated with the internal slot like smart-card based token so that the private key key cannot be exported out of the token? If not, would it be useful feature to support? Even in the token case, this is only true if the key was generated in the token. If 'key recovery' is turned on, NSS generates the key in softoken and writes it to the token (after wrapping it with the escrow key). So it turns out even with crmf, escrow does not happen quietly. If the CA requests a key be escrowed, the user is notified: http://mxr.mozilla.org/firefox/source/security/manager/ssl/src/nsCrypto.cpp#1905 bob ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation
Is there anybody to answer to my/Kaspar Band's statement below, as to get a final clarification ?: 1. Is there a dev-tech-crypto / Firefox developer/programmer who wants to confirm Kaspar Band's idea that running Firefox in Safe Mode when generating the key as well as requesting the Certificate with Thawte does securely prevent unnotified private key transmission ? I do not want to be offending, but a simple I think so-answer does not satisfy most of the Firefox-Thawte Users, who wish a final and secure response. I would not like to spread a possibly wrong information, as that would not be a benefit for any Firefox user. 2. You (Kaspar) are right, we are running code provided by someone else (Mozilla Corporation, in this case). To my knowledge this code run is open source, right ? If so, I would not know there to be a safer code to use than one openly viewable by the public. (Except of course the one which is completely written by ourself. But the latter is not subject of discussion, I believe...) Thank you, 2009/1/3 Kaspar Brand m...@velox.ch Daniel Veditz wrote: user_pref(capability.policy.default.Crypto.generateCRMFRequest, noAccess); That may work now, but capability control for individual DOM properties is gone in Firefox 3.1 betas for performance reasons. Dan, it's not a DOM property but a method of the Crypto object instead which gets blocked in this case - so your comment probably doesn't apply. I checked this configuration with both Firefox 3.1 (Beta) and trunk, where it worked as expected (throws an exception saying Permission denied for [...] to call method Crypto.generateCRMFRequest). Kaspar ___ 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: Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation
Daniel Veditz wrote: user_pref(capability.policy.default.Crypto.generateCRMFRequest, noAccess); That may work now, but capability control for individual DOM properties is gone in Firefox 3.1 betas for performance reasons. Dan, it's not a DOM property but a method of the Crypto object instead which gets blocked in this case - so your comment probably doesn't apply. I checked this configuration with both Firefox 3.1 (Beta) and trunk, where it worked as expected (throws an exception saying Permission denied for [...] to call method Crypto.generateCRMFRequest). Kaspar ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation
First: A succcessful, healthy and happy new Year ! 1. Is there a dev-tech-crypto / Firefox developer/programmer who wants to confirm Kaspar Band's idea that running Firefox in Safe Mode when generating the key as well as requesting the Certificate with Thawte does securely prevent unnotified private key transmission ? I do not want to be offending, but a simple I think so-answer does not satisfy most of the Firefox-Thawte Users, who wish a final and secure response. I would not like to spread a possibly wrong information, as that would not be a benefit for any Firefox user. 2. You (Kaspar) are right, we are running code provided by someone else (Mozilla Corporation, in this case). To my knowledge this code run is open source, right ? If so, I would not know there to be a safer code to use than one openly viewable by the public. (Except of course the one which is completely written by ourself. But the latter is not subject of discussion, I believe...) Thank you, 2008/12/31 Kaspar Brand m...@velox.ch Fost1954 wrote: 1. Can I spread the message into the world that Running Firefox in Safe Mode when generating the key as well as requesting the Certificate with Thawte does securely prevent unnotified private key transmission ? I think so. Note that Thawte still uses the keygen tag, so disabling crypto.generateCRMFRequest through prefs.js could also be considered sufficient (keygen doesn't provide any escrow mechanism). 2.What do you mean using the words maximum reliability in this context. I am aware that there is no 100% security in life, but the words you use (a maximum of what !?) can mean a broad spectrum from maximum, but poor reliability to maximum and really strong reliability... In the sense that it's the maximum achievable reliability given the fact that you're running code provided by someone else (Mozilla Corporation, in this case). In the end, it's always a question of whom you trust - but this would probably get us too much off-topic. Kaspar ___ 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: Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation
Kaspar Brand wrote: Michael Ströder wrote: I'd love to have an option to forbid CRMFRequest calls... Not too difficult to achieve, actually. Just add this line to your prefs.js: user_pref(capability.policy.default.Crypto.generateCRMFRequest, noAccess); That may work now, but capability control for individual DOM properties is gone in Firefox 3.1 betas for performance reasons. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation
Fost1954 wrote: 1. Can I spread the message into the world that Running Firefox in Safe Mode when generating the key as well as requesting the Certificate with Thawte does securely prevent unnotified private key transmission ? I think so. Note that Thawte still uses the keygen tag, so disabling crypto.generateCRMFRequest through prefs.js could also be considered sufficient (keygen doesn't provide any escrow mechanism). 2.What do you mean using the words maximum reliability in this context. I am aware that there is no 100% security in life, but the words you use (a maximum of what !?) can mean a broad spectrum from maximum, but poor reliability to maximum and really strong reliability... In the sense that it's the maximum achievable reliability given the fact that you're running code provided by someone else (Mozilla Corporation, in this case). In the end, it's always a question of whom you trust - but this would probably get us too much off-topic. Kaspar ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation
2008/12/29 Kaspar Brand m...@velox.ch Nelson B Bolyard wrote: Fost1954 wrote, On 2008-12-27 06:54: My personal question: Is this warning dialog really ALWAYS the case ? I think the question is: is there any way for a web site to suppress that dialog? [...] But it's relatively easy to completely hide the dialog with an extension For maximum reliability, you should therefore run the browser in safe mode (http://support.mozilla.com/en-US/kb/Safe+Mode). Thank you. The rest of the conversation here gets too technical for someone like me... BUT: 1. Can I spread the message into the world that Running Firefox in Safe Mode when generating the key as well as requesting the Certificate with Thawte does securely prevent unnotified private key transmission ? AND: 2.What do you mean using the words maximum reliability in this context. I am aware that there is no 100% security in life, but the words you use (a maximum of what !?) can mean a broad spectrum from maximum, but poor reliability to maximum and really strong reliability... Thank you, we are coming to a final answer to the initial question, I am happy about that ! ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation
Kaspar Brand wrote, On 2008-12-27 03:21: Michael Ströder wrote: I personally don't know whether the current Mozilla implementation of crypto.generateCRMFRequest includes the private key of an encryption cert. Only if you tell it do so, and only if it's a key-exchange-only key. [1] Additionally, an Encryption Key Copy warning dialog will be presented when key escrow is attempted - try the attached demo. [2] [1] https://developer.mozilla.org/en/GenerateCRMFRequest [2] Caveat: may leave you (or your cert DB, more precisely) with a lot of orphan keys, if used generously - i.e. it's probably better to use it with a separate profile. Kaspar, Thanks for this information and demo. I had been told that this dialog exists, but I had never seen it before your demo. I'd like to see this demo go into a page on a mozilla web site, such as (say) developer.mozilla.org. I also think we need a page or two on developer.mozilla.org that fully documents both the keygen tag and the crypto.generateCRMFRequest method. The existing documentation is very incomplete. The keygen tag, for example, accepts many more arguments than are now publicly documented. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation
Fost1954 wrote, On 2008-12-27 06:54: *_With other words (adapted from N. Bolyard):_* b) Is there any way for a Firefox user to detect that his CA has requested [the] private key [to be transmitted] ? _Possible Answer by Kaspar Band: _ ...an Encryption Key Copy warning dialog will be presented. My personal question: Is this warning dialog really ALWAYS the case ? I think the question is: is there any way for a web site to suppress that dialog? c) When requesting a certificate from a CA, what can a Firefox user do to prevent [transmission] of the newly generated private key? Possible Answer by kaspar Band: Not too difficult to achieve, actually. Just add this line to your prefs.js:[...] I think Kaspar's suggestion will disable the use of crypto.generateCRMFRequest entirely, not just for the case where key escrow has been requested. Is that right Kaspar? In any case, as long as the warning dialog cannot be suppressed, then I think it is both necessary and sufficient to address Fost's concerns. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation
On 12/28/2008 12:50 PM, Nelson B Bolyard: I also think we need a page or two on developer.mozilla.org that fully documents both thekeygen tag and the crypto.generateCRMFRequest method. The existing documentation is very incomplete. Thekeygen tag, for example, accepts many more arguments than are now publicly documented. Now that's interesting. What are those additional arguments? -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation
Nelson B Bolyard wrote: I also think we need a page or two on developer.mozilla.org that fully documents both the keygen tag and the crypto.generateCRMFRequest method. +1 The existing documentation is very incomplete. The keygen tag, for example, accepts many more arguments than are now publicly documented. Which arguments are that? Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation
2008/12/28 Nelson B Bolyard nel...@bolyard.me I think the question is: is there any way for a web site to suppress that [private key transmission warning-] dialog? Yes: this should be the point. Having the certainty, that a warning dialog cannot be suppressed when a private key is to be transferred, Firefox Users would feel (and be) on the safe side. ___ 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: Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation
Michael Ströder wrote, On 2008-12-28 04:38 PST: Nelson B Bolyard wrote: I also think we need a page or two on developer.mozilla.org that fully documents both the keygen tag and the crypto.generateCRMFRequest method. +1 The existing documentation is very incomplete. The keygen tag, for example, accepts many more arguments than are now publicly documented. Let me start by saying that there are very few documents known to me that are authoritative documentation of the keygen tag, and all are essentially archival copies of documentation developed at Netscape in a prior millennium. They are: http://devedge-temp.mozilla.org/library/manuals/1998/htmlguide/tags10.html#1615503 which is now 11 years old, and http://docs.sun.com/source/816-5535-10/index.html#DSA (6 years old) and https://developer.mozilla.org/En/HTML/HTML_Extensions/KEYGEN_Tag which seems to be the most complete, but is still not complete. Which arguments are that? Now, here's what's not documented. 1. The attribute name keyparams is a synonym for the attribute name pqg. Either name may be used for that attribute. 2. There are 3 recognized values for the keytype attribute. They are rsa, dsa and ec. 3. When the keytype is ec, the EC curve used in the generated key is selected by the value of the optional keyparams attribute, if - it is present and - it is one of the strings found in the table at http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/manager/ssl/src/nsKeygenHandler.cpprev=1.49mark=179-256#177 - and the indicated curve is supported in that browser. Otherwise, it is chosen by the user's choice from the key size choice box according to the following table Key SizeCurve - Highsecp384r1 Medium secp256r1 Low secp256r1 The documentation for crypto.generateCRMFRequest is found at https://developer.mozilla.org/en/JavaScript_crypto/generateCRMFRequest but it is also incomplete. The EC key generation documentation is missing. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation
Michael Ströder wrote: I'd love to have an option to forbid CRMFRequest calls... Not too difficult to achieve, actually. Just add this line to your prefs.js: user_pref(capability.policy.default.Crypto.generateCRMFRequest, noAccess); I personally don't know whether the current Mozilla implementation of crypto.generateCRMFRequest includes the private key of an encryption cert. Only if you tell it do so, and only if it's a key-exchange-only key. [1] Additionally, an Encryption Key Copy warning dialog will be presented when key escrow is attempted - try the attached demo. [2] But there is some Javascript and the HTML looks like this: select name=spkac challenge=tURRaHXxYBDwCk58option2048 (High Grade)/optionoption1024 (Medium Grade)/option/select What browser were you using in this case, and for what certificate were you applying? I still see keygen elements when enrolling for a new Thawte Freemail certificate with Firefox or Seamonkey (note that when saving an HTML page with the Web Page, complete option, the keygen tag is converted into a select element, so maybe that explains the effect you're seeing). Kaspar [1] https://developer.mozilla.org/en/GenerateCRMFRequest [2] Caveat: may leave you (or your cert DB, more precisely) with a lot of orphan keys, if used generously - i.e. it's probably better to use it with a separate profile. Title: CRMF Demo Create CRMF request with escrow Create CRMF request w/o escrow ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation
Kaspar Brand wrote: Michael Ströder wrote: I'd love to have an option to forbid CRMFRequest calls... Not too difficult to achieve, actually. Just add this line to your prefs.js: user_pref(capability.policy.default.Crypto.generateCRMFRequest, noAccess); I personally don't know whether the current Mozilla implementation of crypto.generateCRMFRequest includes the private key of an encryption cert. Only if you tell it do so, and only if it's a key-exchange-only key. [1] Additionally, an Encryption Key Copy warning dialog will be presented when key escrow is attempted - try the attached demo. [2] Good to know all that. But there is some Javascript and the HTML looks like this: select name=spkac challenge=tURRaHXxYBDwCk58option2048 (High Grade)/optionoption1024 (Medium Grade)/option/select What browser were you using in this case, and for what certificate were you applying? Seamonkey 1.1.14 I still see keygen elements when enrolling for a new Thawte Freemail certificate with Firefox or Seamonkey I used View Selection Source from the context menu. (note that when saving an HTML page with the Web Page, complete option, the keygen tag is converted into a select element, so maybe that explains the effect you're seeing). Uuurgs! Yes, that would be an explanation. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation
Thank you: […] Unfortunately Thawte's enrollment interface does not work without Javascript. […]Thawte could silently change the behaviour of the cert enrollment web interface. […] to be 100% sure [the private key is not transferred] you have to check that every time you go through this process. If this is the final and correct confirmatory response, I thank you very much. The questions, as Nelson B Bolyard stated them for Firefox users, who are not IT experts, but who do want to be 100% sure: What means do we have to check the [Javascript cert enrollment interface] every time [we] go through this process ? *With other words (adapted from N. Bolyard):* b) Is there any way for a Firefox user to detect that his CA has requested [the] private key [to be transmitted] ? *Possible Answer by Kaspar Band: * ...an Encryption Key Copy warning dialog will be presented. My personal question: Is this warning dialog really ALWAYS the case ? c) When requesting a certificate from a CA, what can a Firefox user do to prevent [transmission] of the newly generated private key? Possible Answer by kaspar Band: Not too difficult to achieve, actually. Just add this line to your prefs.js:[...] Is this still necessary (as for an average user this is not easy to achieve) ? Or can I be sure a warning dialog will always be presented by firefox ? A solution to these last two questions is essential if the user wants to be 100% sure and secure. Thank you, 2008/12/27 Kaspar Brand m...@velox.ch Michael Ströder wrote: I'd love to have an option to forbid CRMFRequest calls... Not too difficult to achieve, actually. Just add this line to your prefs.js: user_pref(capability.policy.default.Crypto.generateCRMFRequest, noAccess); I personally don't know whether the current Mozilla implementation of crypto.generateCRMFRequest includes the private key of an encryption cert. Only if you tell it do so, and only if it's a key-exchange-only key. [1] Additionally, an Encryption Key Copy warning dialog will be presented when key escrow is attempted - try the attached demo. [2] But there is some Javascript and the HTML looks like this: select name=spkac challenge=tURRaHXxYBDwCk58option2048 (High Grade)/optionoption1024 (Medium Grade)/option/select What browser were you using in this case, and for what certificate were you applying? I still see keygen elements when enrolling for a new Thawte Freemail certificate with Firefox or Seamonkey (note that when saving an HTML page with the Web Page, complete option, the keygen tag is converted into a select element, so maybe that explains the effect you're seeing). Kaspar [1] https://developer.mozilla.org/en/GenerateCRMFRequest [2] Caveat: may leave you (or your cert DB, more precisely) with a lot of orphan keys, if used generously - i.e. it's probably better to use it with a separate profile. Create CRMF request *with* escrow Create CRMF request w/o escrow ___ 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: Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation
Eddy Nigg wrote: I think Thawte uses the keygen tag as well. This is a signed public key and challenge (SPKAC). I also thought so. But there is some Javascript and the HTML looks like this: select name=spkac challenge=tURRaHXxYBDwCk58option2048 (High Grade)/optionoption1024 (Medium Grade)/option/select This is definitely not a keygen tag. If I disable Javascript and press [Next] it won't work. Hmm, strange. I've examined the data traffic exchanged with livehttpheaders. The data I've grabbed looks like a SPKAC blob but I really wonder why the hell they are not using keygen. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation
among other things, because keygen is not a standardized mechanism. -Kyle H On Thu, Dec 25, 2008 at 4:10 AM, Michael Ströder mich...@stroeder.com wrote: Eddy Nigg wrote: I think Thawte uses the keygen tag as well. This is a signed public key and challenge (SPKAC). I also thought so. But there is some Javascript and the HTML looks like this: select name=spkac challenge=tURRaHXxYBDwCk58option2048 (High Grade)/optionoption1024 (Medium Grade)/option/select This is definitely not a keygen tag. If I disable Javascript and press [Next] it won't work. Hmm, strange. I've examined the data traffic exchanged with livehttpheaders. The data I've grabbed looks like a SPKAC blob but I really wonder why the hell they are not using keygen. Ciao, Michael. ___ 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
Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation
Dear Firefox Developers, I understand that this should be the right place to ask: Using Firefox we would like to generate Thawte X.509 E-Mail Certificates. When generating the Private/Public key pair using Firefox as well as requesting the certificate, we are logged in on the Thawte Website. *Our security relevant question:* Which data is transmitted to Thawte during the Private/Public key pair and certificate generation process using Firefox (and Thawte) ? *Does Firefox send to Thawte any form of private key during this process, or not ?* If the private key was transmitted to Thawte, in theory a Thawte staff member –would he gain access to the private key at thawte- could decrypt emails encrypted by us, or sign an email in our names … We would be happy to understand better the key and certificate generation process using Firefox (and Thawte), considering the security critical point mentioned above. Thank you in advance, Proud Firefox users ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation
xbcvb cvbcvbvcb wrote: Using Firefox we would like to generate Thawte X.509 E-Mail Certificates. When generating the Private/Public key pair using Firefox as well as requesting the certificate, we are logged in on the Thawte Website. *Our security relevant question:* Which data is transmitted to Thawte during the Private/Public key pair and certificate generation process using Firefox (and Thawte) ? *Does Firefox send to Thawte any form of private key during this process, or not ?* I don't think so and I checked it today. The SPKAC blob with the public key seems to be transferred (examined it with livehttpheaders and dumpasn1). But as I wrote in my other posting they unfortunately seem to not use the static HTML keygen tag and the process does not function without Javascript. So they could silently change the behaviour of the enrollment interface to use the CRMFRequest Javascript call. IIRC the CRMFRequest could contain the private key. (Any good Javascript tracer for Seamonkey 1.1.x out there?) I'd love to have an option to forbid CRMFRequest calls... Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation
Kyle Hamilton wrote, On 2008-12-25 12:15: among other things, because keygen is not a standardized mechanism. True, but neither is crypto.generateCRMFRequest. There is no standardize html or JavaScript feature for this purpose. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation
Dear Firefox Developers, I understand that this should be the right place to ask: Using Firefox we would like to generate Thawte X.509 E-Mail Certificates. When generating the Private/Public key pair using Firefox as well as requesting the certificate, we are logged in on the Thawte Website. *Our security relevant question:* Which data is transmitted to Thawte during the Private/Public key pair and certificate generation process using Firefox (and Thawte) ? *Does Firefox send to Thawte any form of private key during this process, or not ?* If the private key was transmitted to Thawte, in theory a Thawte staff member –would he gain access to the private key at thawte- could decrypt emails encrypted by us, or sign an email in our names … We would be happy to understand better the key and certificate generation process using Firefox (and Thawte), considering the security critical point mentioned above. Thank you in advance, Proud Firefox users ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation
Firefox does not send any private key. http://en.wikipedia.org/wiki/Certificate_signing_request provides a very good overview of what it does. 2008/12/24 Fost1954 fost19...@googlemail.com: Dear Firefox Developers, I understand that this should be the right place to ask: Using Firefox we would like to generate Thawte X.509 E-Mail Certificates. When generating the Private/Public key pair using Firefox as well as requesting the certificate, we are logged in on the Thawte Website. Our security relevant question: Which data is transmitted to Thawte during the Private/Public key pair and certificate generation process using Firefox (and Thawte) ? Does Firefox send to Thawte any form of private key during this process, or not ? If the private key was transmitted to Thawte, in theory a Thawte staff member –would he gain access to the private key at thawte- could decrypt emails encrypted by us, or sign an email in our names … We would be happy to understand better the key and certificate generation process using Firefox (and Thawte), considering the security critical point mentioned above. Thank you in advance, Proud Firefox users ___ 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: Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation
Kyle Hamilton wrote, On 2008-12-24 13:49: Firefox does not send any private key. http://en.wikipedia.org/wiki/Certificate_signing_request provides a very good overview of what it does. The answer is not that simple. The cited wiki page explains PKCS#10 Certificate Signing Requests (CSRs). CSRs are ONE way in which certificates can be requested from a CA after generating a key pair, but they are not the only way. IIRC, FF implements two other ways, and one of those ways may include private key escrow capability. I think the relevant questions are: a) which of Firefox's methods does Thawte use to cause Firefox to generate a key pair and request a certificate? b) Is there any way for a Firefox user to detect that his CA has requested private key escrow? c) When requesting a certificate from a CA, what can a Firefox user do to prevent escrowing the newly generated private key? I think the answers to these questions will likely not be available until next month. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation
On 12/25/2008 12:40 AM, Nelson B Bolyard: The answer is not that simple. The cited wiki page explains PKCS#10 Certificate Signing Requests (CSRs). CSRs are ONE way in which certificates can be requested from a CA after generating a key pair, but they are not the only way. IIRC, FF implements two other ways, and one of those ways may include private key escrow capability. I think the relevant questions are: a) which of Firefox's methods does Thawte use to cause Firefox to generate a key pair and request a certificate? b) Is there any way for a Firefox user to detect that his CA has requested private key escrow? c) When requesting a certificate from a CA, what can a Firefox user do to prevent escrowing the newly generated private key? I think the answers to these questions will likely not be available until next month. I think Thawte uses the keygen tag as well. This is a signed public key and challenge (SPKAC). -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
