Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation
Fost1954
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
Kyle Hamilton
http://en.wikipedia.org/wiki/Certificate_signing_request provides a
very good overview of what it does.
2008/12/24 Fost1954 <fost...@googlemail.com>:
> _______________________________________________
> dev-tech-crypto mailing list
> dev-tec...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
>
Nelson B Bolyard
> 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.
Eddy Nigg
> 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: star...@startcom.org
Blog: https://blog.startcom.org
Michael Ströder
> 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="tURRaHXxYBDwCk58"><option>2048 (High
Grade)</option><option>1024 (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.
Kyle Hamilton
-Kyle H
xbcvb cvbcvbvcb
Michael Ströder
> 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.
>
>
> certificate generation process using Firefox (and Thawte) ?
>
> 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.
Nelson B Bolyard
> 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.
Brad Hards
> among other things, because <keygen> is not a standardized mechanism.
a set of test cases?
Brad
Fost1954
I think it is an essential and security-relevant question to be not "near 100%" but absolutely sure that there is no way of the private key to be transfered to Thawte or anyone!
My technical/programming knowledge is very limited compared to yours, but I am sure an answer to this question is of high value to all Thawte E-Mail certificate users (which I suppose are quite a few Million around the globe...).
Hence we would be grateful if you -being the experts here- came to a clear result at some point...
Thank you,
Yours,
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.
Michael Ströder
> Hence we would be grateful if you -being the experts here- came to a
> clear result at some point...
Did you actually read my two responses? What exactly do you not understand?
I personally don't know whether the current Mozilla implementation of
crypto.generateCRMFRequest includes the private key of an encryption
cert. But the CRMF standard defines a way for doing so (for CA-side key
recovery/escrow services). So if you want to be sure that
crypto.generateCRMFRequest is not used then turn off Javascript while
going through the cert enrollment web interface which triggers key
generation. Unfortunately Thawte's enrollment interface does not work
without Javascript.
So the answer is: The private key is currently not transferred but
Thawte could silently change the behaviour of the cert enrollment web
interface. So to be 100% sure you have to check that every time you go
through this enrollment process.
Ciao, Michael.
Subrata Mazumdar
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?
--
Subrata
Eddy Nigg
> 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?
Subrata, it's not possible to force the usage of smart cards as you can
with Microsoft cert/xenroll. Users can however select themselves the
appropriate security device and create the key in the smart card token.
Depending on the settings of the token, the private key is not extractable.
I wish such functionality would exist in NSS/PSM.
Kaspar Brand
> 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="tURRaHXxYBDwCk58"><option>2048 (High
> Grade)</option><option>1024 (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.
Michael Ströder
> 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="tURRaHXxYBDwCk58"><option>2048 (High
>> Grade)</option><option>1024 (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.
Fost1954
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,
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");
Only if you tell it do so, and only if it's a key-exchange-only key. [1]
> I personally don't know whether the current Mozilla implementation of
> crypto.generateCRMFRequest includes the private key of an encryption
> cert.
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="tURRaHXxYBDwCk58"><option>2048 (High
> Grade)</option><option>1024 (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.
Nelson B Bolyard
> 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.
Nelson B Bolyard
> *_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.
Eddy Nigg
> 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.
Now that's interesting. What are those additional arguments?
Michael Ströder
> 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.
Anders Rundgren
because they don't match today's needs anyway. You cannot even as an
issuer control PIN code settings (policy) unless you have a pre-configured crypto
container, i.e. these mechanisms are tools for toy PKIs.
Serious PKIs use smart cards and physical card/key/certificate distribution
because the on-line alternatives are more or less useless in addition to being
completely non-standard. The coming HTML5 standards work does not
even *try* to address this mess. I think they did the right thing; PKI standards
in browsers reached an "all-time-high" already 10 years ago.
PKIX are not aware of the problem because PKIX don't do browsers,
they do ASN.1.
Anders
+1
Which arguments are that?
Ciao, Michael.
Fost1954
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.
Michael Ströder
> I wouldn't spend much work on <keygen> and crypto.generateCRMFRequest
> because they don't match today's needs anyway.
Anders, does the word <keygen> trigger an automatic response in your
news bot? ;-}
Your comment is not relevant in this context. Off course the *existing*
implementation of <keygen> and crypto.generateCRMFRequest should be
fully *documented* as Nelson suggested.
Ciao, Michael.
Ian G
> PKIX are not aware of the problem because PKIX don't do browsers,
> they do ASN.1.
Who does browsers?
iang
Anders Rundgren
>Anders Rundgren wrote:
>> I wouldn't spend much work on <keygen> and crypto.generateCRMFRequest
> because they don't match today's needs anyway.
>Anders, does the word <keygen> trigger an automatic response in your
>news bot? ;-}
Well, some 1000h into its successor have left some traces :-) :-)
>Your comment is not relevant in this context. Off course the *existing*
>implementation of <keygen> and crypto.generateCRMFRequest should be
>fully *documented* as Nelson suggested.
Maybe, maybe not.
I assume that private key transfer is only allowed (if possible at all) for encryption keys.
It seems to me that this is a rather useless function since most organizations
are more concerned about sent data than received ditto. I.e. key escrow
doesn't work very well for organizations which is why Outlook has an entirely
different approach to message escrow which actually works (clear-text
message logging in parallell to encrypted messaging).
If the fear is rather that the CA could impersonate a user, it can do that
without notifying the user with warning dialogs.
If the goal is rather providing encryption key backup for consumers, I guess
we are back to the question if S/MIME encryption is for real or not.
Based on actual usage by consumers this issue is already settled.
That is, if private key transfer actually is enabled the correct solution [IMO]
is not to dicument it, but to disable it.
Anders
> ----- Original Message -----
> From: "Michael Ströder" <mic...@stroeder.com>
> Newsgroups: mozilla.dev.tech.crypto
> To: <dev-tec...@lists.mozilla.org>
> Sent: Sunday, December 28, 2008 13:38
> Subject: Re: Security-Critical Information (i.e. Private Key) transmittedby 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.
Nelson B Bolyard
> [...] most organizations are more concerned about sent data than received
> [...]
This is one reason (out of many) that Mozilla's S/MIME mail clients require
that the sender be an implicit recipient of any encrypted messages sent.
It ensures that the sender's private key is also able to decrypt the
messages he sends.
Kyle Hamilton
"REAL programmers do everything they can to point out flaws of things
that don't meet their needs, but are easier to use, older,
more-debugged, and sufficient for those cases that don't require the
ability to trust code running on the client machine to implement the
policy that the server asks for."
i.e., just because they don't meet YOUR needs of today doesn't mean
they don't meet MINE. And the requirements you have are more in line
with requiring DRM (and thus "Trusted Computing" where the user of the
machine doesn't have access to the trusted platform module) than
anything that can be implemented in user-land, anyway.
If I understand what you've been working with, you're encoding key
generation/request parameters into XML to be handled by the client.
If you're doing XML for the parameters-provision, why not break the
certificate request into XML too? Oddly enough, there is an ITU
standard for this -- it's called XML Encoding Rules for ASN.1, or XER.
I'm actually surprised nobody's started using XER for certificate
storage/examination. Since DER is a means of encoding ASN.1
structures into the minimum number of bits, and since XER is an
alternate encoding mechanism (though arguably into the MAXIMUM number
of bits) for the same data, it would work -- yes, the signature is
calculated over the DER encoding of the data, but that can be
reconstituted from the XER. (My understanding is that this is part of
what certificate validation is supposed to handle anyway -- all the
information split out and stuck in a database, then
reconstituted/revalidated as necessary.)
Yes, we'd need special tools to verify the signature, but we already
need special tools to parse DER. It would be a net win for
debuggability and understanding what is in each certificate without
having to load our DER parser every time we want to look at it.
-Kyle H
On Sun, Dec 28, 2008 at 6:47 AM, Anders Rundgren
<anders....@telia.com> wrote:
> I wouldn't spend much work on <keygen> and crypto.generateCRMFRequest
> because they don't match today's needs anyway. You cannot even as an
> issuer control PIN code settings (policy) unless you have a pre-configured crypto
> container, i.e. these mechanisms are tools for toy PKIs.
>
> Serious PKIs use smart cards and physical card/key/certificate distribution
> because the on-line alternatives are more or less useless in addition to being
> completely non-standard. The coming HTML5 standards work does not
> even *try* to address this mess. I think they did the right thing; PKI standards
> in browsers reached an "all-time-high" already 10 years ago.
>
> PKIX are not aware of the problem because PKIX don't do browsers,
> they do ASN.1.
>
> Anders
>
> ----- Original Message -----
> From: "Michael Ströder" <mic...@stroeder.com>
> Newsgroups: mozilla.dev.tech.crypto
> To: <dev-tec...@lists.mozilla.org>
> Sent: Sunday, December 28, 2008 13:38
> Subject: Re: Security-Critical Information (i.e. Private Key) transmittedby Firefox to CA (i.e.
> Thawte) during X.509 key/cert generation
>
>
Nelson B Bolyard
> 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.cpp&rev=1.49&mark=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 Size Curve
-------- -------------
High secp384r1
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.
Anders Rundgren
>(Note: this is almost completely off-topic as relates to the OP's message.)
>"REAL programmers do everything they can to point out flaws of things
>that don't meet their needs, but are easier to use, older,
>more-debugged, and sufficient for those cases that don't require the
>ability to trust code running on the client machine to implement the
>policy that the server asks for."
I don't completely get this. If we are talking about soft tokens of
the kind implemented in Mozilla, PKI-using services rely on keys stored
in containers using obfuscation and optional weak passwords as
the only protection. IMO, this trust in client code is above the
level of trust that PIN policy support requires since the former
enables key theft.
>i.e., just because they don't meet YOUR needs of today doesn't mean
>they don't meet MINE. And the requirements you have are more in line
>with requiring DRM (and thus "Trusted Computing" where the user of the
>machine doesn't have access to the trusted platform module) than
>anything that can be implemented in user-land, anyway.
The "big picture" of this project is establishing a practical HW-crypto
solution based on mobile phones with consumers/citizens as primary
target. I'm not aware of anything similar going on elsewhere unless
you consider EU eID projects as "practical". I don't because these
schemes are based on an all-mighty CA while my scheme is based
on a world of competing technlogies and issuers.
Unlike the existing schemes, KeyGen2 supports inside-of-container-
generation-attestation which I consider a valid requirement, otherwise
HW-crypto is a waste since the service cannot verify that a key really is
in HW.
>If I understand what you've been working with, you're encoding key
>generation/request parameters into XML to be handled by the client.
>If you're doing XML for the parameters-provision, why not break the
>certificate request into XML too? Oddly enough, there is an ITU
>standard for this -- it's called XML Encoding Rules for ASN.1, or XER.
If you look closely on <keygen>, generatecRMFRequest and CertEnroll,
certificate request is redundant (is thrown away by the CA), it is really a
key generation response you need and is implemented in KeyGen2.
>I'm actually surprised nobody's started using XER for certificate
>storage/examination. Since DER is a means of encoding ASN.1
>structures into the minimum number of bits, and since XER is an
>alternate encoding mechanism (though arguably into the MAXIMUM number
>of bits) for the same data, it would work -- yes, the signature is
>calculated over the DER encoding of the data, but that can be
>reconstituted from the XER. (My understanding is that this is part of
>what certificate validation is supposed to handle anyway -- all the
>information split out and stuck in a database, then
>reconstituted/revalidated as necessary.)
>Yes, we'd need special tools to verify the signature, but we already
>need special tools to parse DER. It would be a net win for
>debuggability and understanding what is in each certificate without
>having to load our DER parser every time we want to look at it.
According to a recent discussion in PKIX the only safe way dealing
with certificates is treating them as blobs because a lot of CAs do
not use proper DER encoding.
Anders
On Sun, Dec 28, 2008 at 6:47 AM, Anders Rundgren
<anders....@telia.com> wrote:
> I wouldn't spend much work on <keygen> and crypto.generateCRMFRequest
> because they don't match today's needs anyway. You cannot even as an
> issuer control PIN code settings (policy) unless you have a pre-configured crypto
> container, i.e. these mechanisms are tools for toy PKIs.
>
> Serious PKIs use smart cards and physical card/key/certificate distribution
> because the on-line alternatives are more or less useless in addition to being
> completely non-standard. The coming HTML5 standards work does not
> even *try* to address this mess. I think they did the right thing; PKI standards
> in browsers reached an "all-time-high" already 10 years ago.
>
> PKIX are not aware of the problem because PKIX don't do browsers,
> they do ASN.1.
>
> Anders
>
> ----- Original Message -----
> From: "Michael Ströder" <mic...@stroeder.com>
> Newsgroups: mozilla.dev.tech.crypto
> To: <dev-tec...@lists.mozilla.org>
> Sent: Sunday, December 28, 2008 13:38
> Subject: Re: Security-Critical Information (i.e. Private Key) transmittedby Firefox to CA (i.e.
> Thawte) during X.509 key/cert generation
>
>
Kyle Hamilton
<anders....@telia.com> wrote:
> Kyle Hamilton wrote:
>>(Note: this is almost completely off-topic as relates to the OP's message.)
>
> the kind implemented in Mozilla, PKI-using services rely on keys stored
> in containers using obfuscation and optional weak passwords as
> the only protection. IMO, this trust in client code is above the
> level of trust that PIN policy support requires since the former
> enables key theft.
You cannot trust client code to do what you ask it to do. You cannot
trust client code to do what your security policy requires it to do.
A client can take a request from a server to generate a key on a
hardware token and perform the possibility entirely in software, and
the server has no means of knowing about it.
This is one of the largest, most annoying, and most severely damaging
aspects of client-server programming. (We've been discussing this on
the openssl lists lately -- the requirement that the client run code
that does what the server expects it to is a DRM problem, in which
modifications to the behavior of the code can disable the client
application.)
>>i.e., just because they don't meet YOUR needs of today doesn't mean
>>they don't meet MINE. And the requirements you have are more in line
>>with requiring DRM (and thus "Trusted Computing" where the user of the
>>machine doesn't have access to the trusted platform module) than
>>anything that can be implemented in user-land, anyway.
>
> The "big picture" of this project is establishing a practical HW-crypto
> solution based on mobile phones with consumers/citizens as primary
> target. I'm not aware of anything similar going on elsewhere unless
> you consider EU eID projects as "practical". I don't because these
> schemes are based on an all-mighty CA while my scheme is based
> on a world of competing technlogies and issuers.
I'd love to have this world exist, but I'd also like to add the caveat
that not every issuer should be required to be audited to
financial-services grade.
> Unlike the existing schemes, KeyGen2 supports inside-of-container-
> generation-attestation which I consider a valid requirement, otherwise
> HW-crypto is a waste since the service cannot verify that a key really is
> in HW.
How is this attestation made?
(I'm asking because I cannot find your KeyGen2 submission, since you
withdrew it "[d]ue to IPR issues".)
If you're working with TPMs and relying on configuration registers,
they can be emulated. Everything can be emulated, really, and you're
still relying on the client computer to do what the server expects.
>>If I understand what you've been working with, you're encoding key
>>generation/request parameters into XML to be handled by the client.
>>If you're doing XML for the parameters-provision, why not break the
>>certificate request into XML too? Oddly enough, there is an ITU
>>standard for this -- it's called XML Encoding Rules for ASN.1, or XER.
>
> If you look closely on <keygen>, generatecRMFRequest and CertEnroll,
> certificate request is redundant (is thrown away by the CA), it is really a
> key generation response you need and is implemented in KeyGen2.
Not everything in a CSR is thrown away. Not everything in a CSR needs
to be thrown away. Perhaps it does for financial-services CAs, but
not for all CAs.
Mozilla software isn't solely used as a platform for financial services.
>> [suggestion of XER snipped]
>
> According to a recent discussion in PKIX the only safe way dealing
> with certificates is treating them as blobs because a lot of CAs do
> not use proper DER encoding.
And a lot of CAs do not abide by the requirement (from RFC 5280 nee
3280, but not RFC 2459) of a positive serial number, either (X.509
itself allows for 0, and openssl will implicitly use 00 with its
'x509' command).
If they don't use proper DER encoding, conforming software is required
to reject them. Mozilla reserves the right to reject CAs from the
trust program if they issue nonconforming certificates, for example.
The entire point of DER is that there's one-and-only-one true
encoding. (That's what separates DER from BER.)
-Kyle H
Ian G
> The "big picture" of this project is establishing a practical HW-crypto
> solution based on mobile phones with consumers/citizens as primary
> target.
Big picture: Yes, that's about where we are heading.
iang
Kaspar Brand
> Fost1954 wrote, On 2008-12-27 06:54:
>> My personal question: Is this warning dialog really ALWAYS the case ?
>
For a Web site - i.e. unprivileged JavaScript -, the answer is no. But
it's relatively easy to completely hide the dialog with an extension
(sorry, no demo this time...). For maximum reliability, you should
therefore run the browser in safe mode
(http://support.mozilla.com/en-US/kb/Safe+Mode).
> 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?
Yes. CAPS doesn't allow to filter on specific function arguments (such
as "escrowAuthorityCert", in the case of crypto.generateCRMFRequest).
Kaspar
Michael Ströder
> Michael Ströder wrote:
>> Anders Rundgren wrote:
>>> I wouldn't spend much work on <keygen> and crypto.generateCRMFRequest
>> because they don't match today's needs anyway.
>
>> implementation of <keygen> and crypto.generateCRMFRequest should be
>> fully *documented* as Nelson suggested.
>
> Maybe, maybe not.
Oh, come on! Like it or not: People are using that stuff and S/MIME. So
it should be documented in detail how it works.
Ciao, Michael.
Anders Rundgren
>> I don't completely get this. If we are talking about soft tokens of
>> the kind implemented in Mozilla, PKI-using services rely on keys stored
>> in containers using obfuscation and optional weak passwords as
>> the only protection. IMO, this trust in client code is above the
>> level of trust that PIN policy support requires since the former
>> enables key theft.
>You cannot trust client code to do what you ask it to do. You cannot
>trust client code to do what your security policy requires it to do.
Although this is of course correct, it is also essentially saying that you
cannot rely on anything in the client environment. I don't build on that
assumption because there is evidence of progress in this space. This
level of security should (at least) withstand trojans that try to modify
security code. If it will survive a physical attack is another thing.
Yes, there will surely be bugs but hopefully compartmentation,
virtualization, and trusted root keys will make this manageable.
Policy download and enforcement is in fact already a standard
feature in mobile devices so I'm not alone stepping on thin ice.
Enable "Remote Vipe" is such a policy.
Then there are some philosophical aspects that i would like to bring to
the table: If you require perfect solutions from day #1 you will most
likely end-up with nothing because 1) nobody knows how to build them
2) few are prepared to pay for them. By doing the opposite, creating a
"market" (demand) the time-line for a practical solution is much more
likely to be reasonable assuming that the goal is achievable. No matter
how smart (or dumb) I may be, I'm simply not able to specify a perfect
solution, only a path to "better" solutions. Suggestions are BTW welcome!
>A client can take a request from a server to generate a key on a
>hardware token and perform the possibility entirely in software, and
>the server has no means of knowing about it.
Using <keygen>, generateCRMFRequest and CertEnroll this is
undoubtedly true. That's one reason why I plot with a successor.
>This is one of the largest, most annoying, and most severely damaging
>aspects of client-server programming. (We've been discussing this on
>the openssl lists lately -- the requirement that the client run code
>that does what the server expects it to is a DRM problem, in which
>modifications to the behavior of the code can disable the client
>application.)
Agreed.
>> The "big picture" of this project is establishing a practical HW-crypto
>> solution based on mobile phones with consumers/citizens as primary
>> target. I'm not aware of anything similar going on elsewhere unless
>> you consider EU eID projects as "practical". I don't because these
>> schemes are based on an all-mighty CA while my scheme is based
>> on a world of competing technlogies and issuers.
>I'd love to have this world exist, but I'd also like to add the caveat
>that not every issuer should be required to be audited to
>financial-services grade.
Agreed. The core idea is giving issuers a tool that they can
use regardless the criticality of their services. It can be seen as a
response to:
http://www.mail-archive.com/dev-tec...@lists.mozilla.org/msg02109.html
>> Unlike the existing schemes, KeyGen2 supports inside-of-container-
>> generation-attestation which I consider a valid requirement, otherwise
>> HW-crypto is a waste since the service cannot verify that a key really is
>> in HW.
>How is this attestation made?
>(I'm asking because I cannot find your KeyGen2 submission, since you
>withdrew it "[d]ue to IPR issues".)
Such a mechanism has been defined by TrustedComputingGroup. I have
proposed a simpler variant but the principle is the same:
http://webpki.org/papers/keygen2/SubjectKeyAttestationEvidence-light__InventionDisclosure.pdf
>If you're working with TPMs and relying on configuration registers,
>they can be emulated. Everything can be emulated, really, and you're
>still relying on the client computer to do what the server expects.
This part is about trusted client code and is independent on key attestations
which cannot be emulated since they derive trust from a HW-protected key
that neither can be emulated nor forced to do something is wasn't programmed
for (i.e. a smart card).
>> If you look closely on <keygen>, generatecRMFRequest and CertEnroll,
>> certificate request is redundant (is thrown away by the CA), it is really a
>> key generation response you need and is implemented in KeyGen2.
>Not everything in a CSR is thrown away. Not everything in a CSR needs
>to be thrown away. Perhaps it does for financial-services CAs, but
>not for all CAs.
AFAIK a CSR is typically a signed object that as a minimum contains the
public key of the generated key-pair. A CA usually only needs the public
key since the cert data is already known anyway for browser-based provisionings
unless you work in a session-less mode. KeyGen2 can also work in
a session-less mode but it doesn't do that through clobbering the CSR
because some of the data may not have anything to do with what
you plan to have in the certificate. KeyGen2's solution is called
ServerCookie and is a universal way of including round-trip data.
<snip>
Anders
Fost1954
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).
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"...
Nelson B Bolyard
> On Sun, Dec 28, 2008 at 11:26 PM, Anders Rundgren wrote:
>>> [suggestion of XER snipped]
>> According to a recent discussion in PKIX the only safe way dealing
>> with certificates is treating them as blobs because a lot of CAs do
>> not use proper DER encoding.
> If they don't use proper DER encoding, conforming software is required
> to reject them. Mozilla reserves the right to reject CAs from the
> trust program if they issue nonconforming certificates, for example.
> And a lot of CAs do not abide by the requirement (from RFC 5280 nee
> 3280, but not RFC 2459) of a positive serial number, either (X.509
> itself allows for 0, and openssl will implicitly use 00 with its
> 'x509' command).
NSS has a rather strict DER decoder. So certs that don't conform to DER
are not very likely to be usable by NSS. But some of the requirements
of the IETF RFCs go beyond the requirements of DER, and NSS enforces
many (most?) but not all of those additional requirements. For example,
the certificate serial number is a DER INTEGER (primitive ASN.1 types are
always spelled in all CAPS), and DER INTEGERs can be positive, negative or
zero. NSS is happy with any correctly DER encoded integer, and doesn't
reject negative values (the RFC explicitly allows this, IIRC). On other
other hand, NSS does strictly enforce the rule that serial numbers must
be unique, and NSS requires that no two different certs share the same
serial number.
> The entire point of DER is that there's one-and-only-one true
> encoding. (That's what separates DER from BER.)
Well, yes and no. One area where that falls apart is Directory Names
(DNs, a.k.a. Distinguished Names). ASN.1 defines numerous different
overlapping character sets, and the X.50x definition of DNs allows
most attributes to be encoded in any of the character sets that are
capable of encoding them. So, given an attribute value that consists
entirely of ASCII alphanumeric characters, there are numerous different
ways to encode it, all valid. That defeats the "one true encoding" idea.
RFC 3280 attempted to solve that problem by requiring that one particular
encoding (UTF8) be used in any attribute that X.50x permits to be encoded in
any of several character sets. RFC 3280 said that conformant
implementations may ASSUME that attributes encoded in different character
sets are encodings of different values, and NSS does exactly that.
But now RFC 5280, the successor to RFC 3280, allows the use multiple
character sets again, and seems to require conformant implementations to
be able to compare and match attributes even in different character sets.
So the "one true encoding" idea is thoroughly ruined in the world of
X.509 certificates, IMO. In any case, NSS does not yet claim conformance
to RFC 5280, and probably will not for quite some time.
Kaspar Brand
> 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
Daniel Veditz
> 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.
Fost1954
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 ?
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,
Kaspar
Kaspar Brand
>> 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
Fost1954
1. Is there a dev-tech-crypto / Firefox developer/programmer who wants to confirm Kaspar Band's idea that "running Firefox in "Safe
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,
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
Robert Relyea
> 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
Fost1954
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
Thank you !
Michael Ströder
> 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.
Ian G
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
Kyle Hamilton
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 <fost...@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 <rre...@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:
>>
>>
Nelson B Bolyard
> 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.
Fost1954
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."
Thanky you,
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 !
Nelson B Bolyard
> 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.
All discussions in this list are very public. You can find this thread at
http://groups.google.com/group/mozilla.dev.tech.crypto/browse_frm/thread/e885d0624ab4ffe9
and
http://www.nabble.com/Security-Critical-Information-%28i.e.-Private-Key%29-transmitted-by-Firefox-to-CA-%28i.e.-Thawte%29-during-X.509-key-cert-generation-tc21170221.html
and probably elsewhere also.
I think you can cite those without any permissions.
Michael Ströder
> 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.
>
> 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.