Re: Debian Weak Key Problem
Gervase Markham: Rob Stradling wrote: That is now old news. I'm pleased to announce that... snip applause Gerv StartCom has concluded today the revocation of all vulnerable keys which were signed by any of our roots, respectively intermediate CA certificates. Several notifications were sent to the subscribers. (Gerv, no applause needed...thanks!) For the statistics: 1.57 % weak keys out of all currently valid certificates were forcefully revoked. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] 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: Debian Weak Key Problem
Eddy Nigg wrote: [...] StartCom has scanned and detected all vulnerable keys and informed the affected subscribers. We'll revoke all compromised keys within a short time. Can you tell how much it represented in percentage of the issued certificates ? ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Debian Weak Key Problem
Paul Hoffman: http://news.netcraft.com/archives/2008/06/12/ssl_certificates_vulnerable_to_openssl_flaw_on_debian.html The last paragraph says: = Although a number of certificate authorities have offered free replacement certificates to customers affected by the Debian OpenSSL vulnerability, it has been reported that they have not been getting a big response. Comodo is offering a free replacement SSL certificate to any affected business, regardless of their original provider, while VeriSign is offering free reissuance for both SSL certificates and code signing certificates. GeoTrust and Thawte also offer free SSL certificate reissuance, and RapidSSL certificates can be renewed for free at GeoTrust's website. = No mention of any CA actively contacting affected customers, much less revoking any certs. StartCom has scanned and detected all vulnerable keys and informed the affected subscribers. We'll revoke all compromised keys within a short time. We also updated our FAQ page https://www.startssl.com/?app=25#74 and will scan future submissions of CSRs for potential vulnerabilities and provide a tool to detect them beforehand at the StartSSL Control Panel. Even though we represent only a small share of the overall potentially affected certificates, the nagging of you all of you was not fruitless after all :-) -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] 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: Debian Weak Key Problem
Gervase Markham wrote: Jean-Marc Desperrier wrote: Well, CRL can also be made to scale properly to handle a large number of revocation, but this requires a few operationnal changes. ...which presumably have to be made before you issue the certs? Yes, but the reason why only 20% of the certs have an OCSP URL might largely being due to the operational constraint of being able to answer the number of OCSP requests that will come therafter. The alternative in order to avoid changing the CA constantly would be CRL splitting, changing the CRL distribution points, and setting the critical Issuing Distribution Point in the crl with an URL that matches the CRL DP. But this is not supported by all implementions, and especially maybe only by Fx 3 and not Fx 2. Fx 3 does not, as far as I know, support CRL DPs. They are two subtly different things here and I was in fact referring to the second : - First, the ability to make use of the CRL DP to download a CRL. PSM doesn't do that, even on Fx3. Which is a pity since it means in practice Fx users will not check crl when accessing sites. It could change if Fx were preconfigured to download the CRLs of all the CAs it trusts. - Second, being able to apply a CRL only for certs when the CRL's IDP extension content matches the CRL DP of the cert. I think libpkix must have added support for that in NSS 3.12 and Fx3. Older NSS version will reject the CRL because they'll see the critical IDP extension that they do not handle. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Debian Weak Key Problem
Jean-Marc Desperrier wrote: Well, CRL can also be made to scale properly to handle a large number of revocation, but this requires a few operationnal changes. ...which presumably have to be made before you issue the certs? The alternative in order to avoid changing the CA constantly would be CRL splitting, changing the CRL distribution points, and setting the critical Issuing Distribution Point in the crl with an URL that matches the CRL DP. But this is not supported by all implementions, and especially maybe only by Fx 3 and not Fx 2. Fx 3 does not, as far as I know, support CRL DPs. Gerv ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Debian Weak Key Problem
Michael Ströder wrote: Eddy Nigg (StartCom Ltd.) wrote: I could produce millions of keys in my free time and post them to some web site...I could tell you now that those are all compromised keys and all CAs should now scan their subscribers keys against the ones I posted. Should it find one, it should revoke it, right? Eddy, this is not comparable. We're talking about the likelihood of a key being in the range of what we now consider weak Debian keys. It is somehow comparable: if you have a bag of private key and say to a CA if any of your client are using on of those keys, they're broken, well they are. The CA MUST revoke any client cert that matches one of the keys. It's just that without a weakness like the debian one, the probability of any of the client of the CA using one of the keys is zero for practical needs. If the key space of the keys generated an any system is not big enough that the feasibility of generating the same key again on any another system is equivalent to zero for pratical needs, the said private keys are not usable for cryptography. When Eddy says free time, he should say millions of years of free time and millions of computers and still this would not be enough because here we talk about numbers like a probability of 1/2^480 of key collison happening at random. This is what makes CAcert.org's HashServer a really nice idea. Everytime you generate a key, you should upload the public part to this server and if anybody, anytime generates the same key, that means it's severly broken (not just the key, the key generation system you used). It would be nice to integrate this system to all popular key generation tools or scripts (one thing that's missing though is to protect the server against pollution by requiring to sign a challenge when sending the public key). ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Debian Weak Key Problem
Robert Relyea wrote: 1) work with CA's, in their existing infrastructures to get those certs revoked. 2) include that list of keys in the browser itself to detect this compromise. 3) build a parallel revocation scheme to phone home to mozilla (a.la. anti-phishing) to identify sites with revoked keys. In any event, the final result is websites with these keys need to be inaccessible. If 2 or 3 are chosen, we face the situation where mozilla will start (some argue continue) to believe that the CA infrastructure is irrelevant and push for non-PKI, bare key solutions. I don't think that quite follows. Incomplete rather than irrelevant, maybe. If we see cooperation from CA's in quickly revoking those certs which are vulnerable, that would be enough to convince mozilla the right way to solve the problem is to depend on option 1 and fix revocation in the existing browsers. This is an opportunity to show that PKI infrastructure really works. It is by far the best solution. The difficulty is that, according to initial reports and scans, only about 20% of the certs concerned have an OCSP URL. Gerv ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Debian Weak Key Problem
Gervase Markham wrote: [...] If we see cooperation from CA's in quickly revoking those certs which are vulnerable, that would be enough to convince mozilla the right way to solve the problem is to depend on option 1 and fix revocation in the existing browsers. This is an opportunity to show that PKI infrastructure really works. It is by far the best solution. The difficulty is that, according to initial reports and scans, only about 20% of the certs concerned have an OCSP URL. Well, CRL can also be made to scale properly to handle a large number of revocation, but this requires a few operationnal changes. - CA level change = CA splitting, don't issue too many certs under the same CA, use a new CA once it has issued too many certs (the threshold should be below 10 000 certs). The alternative in order to avoid changing the CA constantly would be CRL splitting, changing the CRL distribution points, and setting the critical Issuing Distribution Point in the crl with an URL that matches the CRL DP. But this is not supported by all implementions, and especially maybe only by Fx 3 and not Fx 2. - Client level change = Download CRL as you need them to check some certificate, not systematically. This would also require to automatically use the CRL DP to download certs, and not use manual configuration which would have became unmanageable. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Debian Weak Key Problem
Nelson B Bolyard wrote: It may be reasonable for a CA to assume that the subscriber has taken due care to generate a good key pair at the time that the certificate signing request is received, but at such time as the CA has evidence that the key is compromised (especially public evidence), then there can be no further true assurances for the binding, and the CA is responsible to act, IMO. I strongly agree. Especially in this particular case. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Debian Weak Key Problem
Nelson B Bolyard wrote: Agreed, and part of the discussion here is: is it acceptable to Mozilla to continue to trust certs from CAs who don't revoke timely in the presence of evidence? I hope not. Such CAs provide only security theater, IMO. Yupp. Actually, I think most of them already ARE more strident about this than I am. There is already HUGE distrust of CAs among the Mozilla community, especially developers. For a decade now there have been ongoing calls for Mozilla to ship a browser with an empty trusted CA list. There are STILL calls for removing Verisign certs from the trust list because of the issuance of some bogus Microsoft certs some years ago. The number one impediment to the acceptance of EV by the Mozilla community was that it was initially promoted by the very CA they most despised. Nelson, thanks for these clear words. CAs can use this as an opportunity to say Users of PKI with our certs don't need to carry around 3MB Key revocation lists. They don't need new software. They just use the OCSP revocation that is already built in to FF3 and IE7, and they're covered, because the CAs will do a competent job of revocation for them. That's real value that any Debian user can see. Yes! To CA staff lurking here: Prove your trustability now to save your own business! Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Debian Weak Key Problem
Eddy Nigg (StartCom Ltd.) wrote: I could produce millions of keys in my free time and post them to some web site...I could tell you now that those are all compromised keys and all CAs should now scan their subscribers keys against the ones I posted. Should it find one, it should revoke it, right? Eddy, this is not comparable. We're talking about the likelihood of a key being in the range of what we now consider weak Debian keys. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Debian Weak Key Problem
Aren't the people who send their credit card number on an https connexion where the private key of the server is public knowledge already screwed ? Yes, of course. The question for this thread is: who is responsible for each screwedness? I beg to differ. The question is: for what is the CA responsible? That's not much of a question, because it is answered in each CPS. Mozilla has reviewed each CPS. It seems we are spending a lot of time discussing theoretical considerations of liability and responsibility, which are important, but only one part of the true issue before us, which is practical. The issue is: through an mistake in a not insignificant generator of of private keys, a non-trivial number of web sites are now using keys that are compromised. Products like mozilla will have to do something to protect their customers. This can either be: 1) work with CA's, in their existing infrastructures to get those certs revoked. 2) include that list of keys in the browser itself to detect this compromise. 3) build a parallel revocation scheme to phone home to mozilla (a.la. anti-phishing) to identify sites with revoked keys. In any event, the final result is websites with these keys need to be inaccessible. If 2 or 3 are chosen, we face the situation where mozilla will start (some argue continue) to believe that the CA infrastructure is irrelevant and push for non-PKI, bare key solutions. Whether or not CAs have an obligation for timely revocation of these certificates, they have a vested interest in doing so. This mass compromise scenario was already planned for. For the last 10 years companies like Verisign have worked hard to bring the revocation infrastructure on line. Today that infrastructure is about 80% in place, where the missing pieces are actually browser pieces. If we see cooperation from CA's in quickly revoking those certs which are vulnerable, that would be enough to convince mozilla the right way to solve the problem is to depend on option 1 and fix revocation in the existing browsers. This is an opportunity to show that PKI infrastructure really works. It is by far the best solution. The use of certs limits the Web's exposure to the issue because These certs can be revoked and will eventually expire. This cannot be said of protocols like ssh, which is now basically vulnerable to MITM attacks with no real recourse than to either 1) hope everyone checks and fixes their own keys, or 2) carrying around a huge set of compromised keys basically forever. bob smime.p7s Description: S/MIME Cryptographic Signature ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Debian Weak Key Problem
At 7:50 PM -0700 6/9/08, Nelson B Bolyard wrote: Paul Hoffman wrote, On 2008-06-09 18:31 PDT: At 2:56 PM -0700 6/9/08, Nelson B Bolyard wrote: a CA that tries to save the customer by revoking the possibly-compromised domain's keys is overstepping its responsibility. The keys in question are not possibly compromised. They are compromised. Period. Until we see any evidence of this in the real world, we disagree. I think we have different definitions of compromised. I define it as: when the named party no longer has exclusive control over the corresponding private key, then the public key (and the cert bearing it) is compromised. You have conflated two things. We agree on the definition of a key compromise. Where we disagree is the and the cert bearing it part, which is the only part that the PKI part of Mozilla has control over. The certificate is not compromised when the key is *unless the CPS of the CA says it is*. It doesn't matter what Nelson or Paul thinks: the CPS trumps all. Otherwise, what is the value of Mozilla spending so much time evaluating CPSs against our standards? Now, it is fine if Mozilla wants to change our standards and say all CPSs must have a clause that says that in the case of a key compromise, the CA will revoke the certificate. That's perfectly within our rights. Saying they should already be doing that is bogus. If we wanted to say that, we could have said it long ago. We didn't. We can now. I claim that the binding of a name to a public key REQUIRES that the named party holds unique control over the private key. What other definition is meaningful? That the named party asserts that they hold unique control over the private key. That's the way many CPSs are written. Again, if you don't like that, get Mozilla to change their requirements for acceptable CPSs. What good is it to assert that When you encrypt with this public key, you can be confident that the decryption will be performed by the party named in this cert OR any of millions of others. ? What kind of binding is that? Typical? Of what value is it? Little, of course. c) What responsibilities does a CA have to relying parties? I have never signed a contract with any of them. A CA's responsibility to offer REAL assurances to its relying parties should be motivated by its own self interest. Note the should be. In the real world, it is just one aspect. Here's a hint: how may of the dozens of CAs that are in the Mozilla TA pile have acted yet? 50%? 10%? Any? How does your should be stand up to such a low response rate? It's value to subscribers is directly a function of the number of relying parties who trust it. For some value of trust. Analogous to broadcasters who measure the value of their airtime to advertisers by the number of eyeballs that watch their content. A CA who is not trusted (by virtue of not being in popular products) offers little value (in some markets) Yes... and finds few subscribers. No. I'm sorry, but I do not see how you can look at the competition in the CA market and say that perceived value is at all proportionate to the trust in the CA. It is probably safe to say that fewer than 1% of Mozilla users even recognize the names of more than 10% of the TAs in the pile. Saying that they trust them is just silly. They trust *us* to pick the TAs for them. Relying parties who find they can no longer trust the certified bindings of a certain CA stop trusting that CA. A CA whose base of relying parties is diminishing is a CA in decline. Sure. But essentially none of the relying parties in the world have any level of trust in the vast majority of the TAs in the pile, so this argument is specious. To be frank, browser vendors have more responsibilities to relying parties than CAs do. That's why the browser vendors carefully check CPSs and enforce rules about them. Agreed, and part of the discussion here is: is it acceptable to Mozilla to continue to trust certs from CAs who don't revoke timely in the presence of evidence? I hope not. Such CAs provide only security theater, IMO. Kumbaya! Now we are talking about walking the walk, not telling someone else to do so. The keys ARE compromised. A CA who refuses to timely revoke a cert with a known compromised key abrogates any public trust. Any? Do you really think that a typical Firefox user, even when this is all explained to them, would be as strident as you are here? Actually, I think most of them already ARE more strident about this than I am. There is already HUGE distrust of CAs among the Mozilla community, especially developers. Erm, I said user. I meant user. For a decade now there have been ongoing calls for Mozilla to ship a browser with an empty trusted CA list. There are STILL calls for removing Verisign certs from the trust list because of the issuance of some bogus Microsoft certs some years ago. The number one impediment to the acceptance of EV by the
Re: Debian Weak Key Problem
If the CPS doesn't define it as compromised in that circumstance, then the CA with that CPS has no business being trusted by me. Yet, I'm never given a choice. Not unless I go through each and every single entry in the root list and apply my own criteria to it. Better, for me, to not have to deal with the fact that someone I never gave fiduciary permission to has taken it upon itself/himself to make fiduciary decisions for me. Better, for me, to have a browser with zero trust anchors embedded. Because then at least I could take it on myself. I'm seriously starting to think that this is something I'll have to sue the Mozilla Foundation over, since it seems to be completely unresponsive to the feedback that I've left over the years. -Kyle H On Tue, Jun 10, 2008 at 1:55 PM, Paul Hoffman [EMAIL PROTECTED] wrote: At 7:50 PM -0700 6/9/08, Nelson B Bolyard wrote: Paul Hoffman wrote, On 2008-06-09 18:31 PDT: At 2:56 PM -0700 6/9/08, Nelson B Bolyard wrote: a CA that tries to save the customer by revoking the possibly-compromised domain's keys is overstepping its responsibility. The keys in question are not possibly compromised. They are compromised. Period. Until we see any evidence of this in the real world, we disagree. I think we have different definitions of compromised. I define it as: when the named party no longer has exclusive control over the corresponding private key, then the public key (and the cert bearing it) is compromised. You have conflated two things. We agree on the definition of a key compromise. Where we disagree is the and the cert bearing it part, which is the only part that the PKI part of Mozilla has control over. The certificate is not compromised when the key is *unless the CPS of the CA says it is*. It doesn't matter what Nelson or Paul thinks: the CPS trumps all. Otherwise, what is the value of Mozilla spending so much time evaluating CPSs against our standards? Now, it is fine if Mozilla wants to change our standards and say all CPSs must have a clause that says that in the case of a key compromise, the CA will revoke the certificate. That's perfectly within our rights. Saying they should already be doing that is bogus. If we wanted to say that, we could have said it long ago. We didn't. We can now. I claim that the binding of a name to a public key REQUIRES that the named party holds unique control over the private key. What other definition is meaningful? That the named party asserts that they hold unique control over the private key. That's the way many CPSs are written. Again, if you don't like that, get Mozilla to change their requirements for acceptable CPSs. What good is it to assert that When you encrypt with this public key, you can be confident that the decryption will be performed by the party named in this cert OR any of millions of others. ? What kind of binding is that? Typical? Of what value is it? Little, of course. c) What responsibilities does a CA have to relying parties? I have never signed a contract with any of them. A CA's responsibility to offer REAL assurances to its relying parties should be motivated by its own self interest. Note the should be. In the real world, it is just one aspect. Here's a hint: how may of the dozens of CAs that are in the Mozilla TA pile have acted yet? 50%? 10%? Any? How does your should be stand up to such a low response rate? It's value to subscribers is directly a function of the number of relying parties who trust it. For some value of trust. Analogous to broadcasters who measure the value of their airtime to advertisers by the number of eyeballs that watch their content. A CA who is not trusted (by virtue of not being in popular products) offers little value (in some markets) Yes... and finds few subscribers. No. I'm sorry, but I do not see how you can look at the competition in the CA market and say that perceived value is at all proportionate to the trust in the CA. It is probably safe to say that fewer than 1% of Mozilla users even recognize the names of more than 10% of the TAs in the pile. Saying that they trust them is just silly. They trust *us* to pick the TAs for them. Relying parties who find they can no longer trust the certified bindings of a certain CA stop trusting that CA. A CA whose base of relying parties is diminishing is a CA in decline. Sure. But essentially none of the relying parties in the world have any level of trust in the vast majority of the TAs in the pile, so this argument is specious. To be frank, browser vendors have more responsibilities to relying parties than CAs do. That's why the browser vendors carefully check CPSs and enforce rules about them. Agreed, and part of the discussion here is: is it acceptable to Mozilla to continue to trust certs from CAs who don't revoke timely in the presence of evidence? I hope not. Such CAs provide only security theater, IMO. Kumbaya! Now we are talking
Re: Debian Weak Key Problem
Paul Hoffman wrote: [...] Sure, but that's not the model most CAs have with their customers. I would bet that if a CA sent out a message saying we're revoking your cert tomorrow, here's a new one to all of its affected customers, fewer than 95% would have the new cert installed correctly. The remainder would be screwed, and the customer support lines (and I use that term very loosely) would be jammed. Aren't the people who send their credit card number on an https connexion where the private key of the server is public knowledge already screwed ? A better mechanism would be for the CAs to send out repeated letters saying that the keys are probably compromised and the certified party really really really should do an update. If they don't, it is now the responsibility of the certified party. Isn't the entity the users trust when they see a certificate foremost the CA that emitted it ? What conclusion should they reach if it's OK with that party if their connexion is not secure ? The argument against revocating all those certs I would think of as strong is more that it would break the CRL system. If there are tens of thousands of certs to revoke (and there's all reasons to think it's in that size range), the CRL become simply unmanageable at every level. Users would take ages to download and process it, and the providing site could no more handle the load. But if, as suggested, Firefox gets a list of the broken public keys, and reject them directly, it solves that problem. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Debian Weak Key Problem
At 11:22 AM +0200 6/9/08, Jean-Marc Desperrier wrote: Paul Hoffman wrote: [...] Sure, but that's not the model most CAs have with their customers. I would bet that if a CA sent out a message saying we're revoking your cert tomorrow, here's a new one to all of its affected customers, fewer than 95% would have the new cert installed correctly. The remainder would be screwed, and the customer support lines (and I use that term very loosely) would be jammed. Aren't the people who send their credit card number on an https connexion where the private key of the server is public knowledge already screwed ? Yes, of course. The question for this thread is: who is responsible for each screwedness? I assert that the end users with credit cards are screwed by the domain that has had its key compromised, particularly if the CA has tried to contact the domain. I assert that if the CA preemptively revokes a certificate, the domain is screwed by the CA. However, given that a CA cannot know whether or not a domain has been compromised, a CA that tries to save the customer by revoking the possibly-compromised domain's keys is overstepping its responsibility. The public key is still associated with the domain; it might be associated with Mallory as well, but that's unknown. If it becomes known to the CA that the key has been compromised, the CA's CPS might (cough cough) give it guidance about whether or not the CA can revoke the key without the domain asking. A better mechanism would be for the CAs to send out repeated letters saying that the keys are probably compromised and the certified party really really really should do an update. If they don't, it is now the responsibility of the certified party. Isn't the entity the users trust when they see a certificate foremost the CA that emitted it ? Yes. That trust hasn't been broken, unless the CA said to the users and we will revoke the certificate if we suspect that the key could likely be compromised. There may be CPSs that say that; I haven't studied them enough to know which do and which don't. What conclusion should they reach if it's OK with that party if their connexion is not secure ? No conclusion at all. The argument against revocating all those certs I would think of as strong is more that it would break the CRL system. If there are tens of thousands of certs to revoke (and there's all reasons to think it's in that size range), the CRL become simply unmanageable at every level. Users would take ages to download and process it, and the providing site could no more handle the load. See .gov and .mil. But if, as suggested, Firefox gets a list of the broken public keys, and reject them directly, it solves that problem. They keys are not broken, they are trivial to break if an attacker wants to. That's an important difference, and one that needs to be made in any warning we give to a user. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Debian Weak Key Problem
Paul Hoffman wrote: However, given that a CA cannot know whether or not a domain has been compromised, a CA that tries to save the customer by revoking the possibly-compromised domain's keys is overstepping its responsibility. Whether the CA is overstepping its responsibility is subject of the CPS. The public key is still associated with the domain; it might be associated with Mallory as well, but that's unknown. A CA usually also makes provisions about the strength of keys. So if the keys do not comply to a required key strength anymore (which is IMHO not only made up by the key's bit-length) then the CA should revoke the accompanying cert. They keys are not broken, they are trivial to break if an attacker wants to. That's an important difference, and one that needs to be made in any warning we give to a user. Yes. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Debian Weak Key Problem
Kyle Hamilton wrote, On 2008-06-08 13:28: My thought is that if there's any knowledge that a CA has that a key has been compromised, the CA can no longer verify the binding of the key to the subject -- which means that the certification should not exist, and thus must be revoked. On the points above, I agree with you completely, Kyle. Then again, I'm something of a 'purist' when it comes to viewing what a CA's responsibilities are. Me too. CAs are selling subscribers trusted credentials, not convenience. If the credentials are not trustworthy, then what is their value? ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Debian Weak Key Problem
Paul Hoffman wrote, On 2008-06-09 09:41: At 11:22 AM +0200 6/9/08, Jean-Marc Desperrier wrote: Aren't the people who send their credit card number on an https connexion where the private key of the server is public knowledge already screwed ? Yes, of course. The question for this thread is: who is responsible for each screwedness? I beg to differ. The question is: for what is the CA responsible? It is for assuring the certified binding of name and key. When that binding has no more assurances, the certificate becomes a false statement of assurance. However, given that a CA cannot know whether or not a domain has been compromised, A CA can know that a key has been compromised. Whether an actual exploit of that compromise exists for any user at any specific time may be unknowable, but is not the only factor in determining the CA's responsibility to the relying parties. a CA that tries to save the customer by revoking the possibly-compromised domain's keys is overstepping its responsibility. The keys in question are not possibly compromised. They are compromised. Period. Only the degree to which the compromised key has been exploited may be unknown. A CA who informs it relying parties that it can no longer assure the binding that it once certified is fulfilling its responsibility, not exceeding it. Isn't the entity the users trust when they see a certificate foremost the CA that emitted it ? Yes. That trust hasn't been broken, unless the CA said to the users and we will revoke the certificate if we suspect that the key could likely be compromised. The keys ARE compromised. A CA who refuses to timely revoke a cert with a known compromised key abrogates any public trust. They keys are not broken, they are trivial to break if an attacker wants to. They are compromised. There is no reason to believe that only the named subject holds the corresponding private key, (since I also hold it :). That's an important difference, and one that needs to be made in any warning we give to a user. It's the difference between Your drawer in the bank vault has been robbed and the bank vault door lock is now broken and the door is wide open. Both situations demand action. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Debian Weak Key Problem
Eddy Nigg (StartCom Ltd.) wrote, On 2008-06-09 15:23: Nelson B Bolyard: (quoting Paul Hoffman, quoting Jean Mark Desperrier) Aren't the people who send their credit card number on an https connexion where the private key of the server is public knowledge already screwed ? Yes, of course. The question for this thread is: who is responsible for each screwedness? I beg to differ. The question is: for what is the CA responsible? It is for assuring the certified binding of name and key. When that binding has no more assurances, the certificate becomes a false statement of assurance. For once I must slightly disagree with you, Nelson. (it doesn't happen a lot though :-) ) Responsibilities are shared (at least) or sometimes the full responsibility of the subscriber. If the subscriber insists on creating his own key and this is his perfect right, then he bears the responsibility for it. Most subscriber agreements and CA policies clearly define that. It may be reasonable for a CA to assume that the subscriber has taken due care to generate a good key pair at the time that the certificate signing request is received, but at such time as the CA has evidence that the key is compromised (especially public evidence), then there can be no further true assurances for the binding, and the CA is responsible to act, IMO. However, given that a CA cannot know whether or not a domain has been compromised, A CA can know that a key has been compromised. How? There are many ways. One of the most powerful is for someone who has come into possession of the compromised private key to stand in the doorway of the CA, hold up the key copy, and say See here in my hand, I have the public key for a cert that does not bear my name, a cert issued by this CA. I will give a copy of this key to anyone who wants one. Shall CAs now be in the business of trying to crack their subscribers keys? Just because there is now one popular and know flaw out there? Do you believe it's the only one? For which bugs and flaws shall the CA look for? Eddy, the issue here is not that CAs don't have omniscient knowledge of all compromised keys. The issue is their responsibility after the guy has waved copies of the compromised keys in their faces, especially if they've identified the certs bearing the compromised keys. The keys in question are not possibly compromised. They are compromised. Period. Only the degree to which the compromised key has been exploited may be unknown. All keys are compromised? In this case, the guy held up a bag of ~96 thousand private keys and said See, here are 96 thousand private keys that I possess. Anyone can have a copy of them. I can't imagine better proof of key compromise than that. For which possible exploits shall the CA look for? Perhaps you know exactly for which flaws and bugs should be scanned I'd say CAs should not ignore the guy handing out copies of the compromised keys, when he's doing it on their doorstep. The keys ARE compromised. A CA who refuses to timely revoke a cert with a known compromised key abrogates any public trust. Yes, once it's known to the CA it should revoke it immediately. No question. It's the difference between Your drawer in the bank vault has been robbed and the bank vault door lock is now broken and the door is wide open. Both situations demand action. The banks door locks are excellent, but the key to the safety deposit box was lost by the customer. Once the customer informs the bank that he lost his key, the bank will certainly replace the lock of the deposit box. It doesn't require the customer. If I walk into the bank and say See here in my hand, a copy of the key for Eddy's deposit box, exactly like the copies that I just gave to all those people in the bank lobby, the bank shouldn't need any more evidence or customer approval before acting. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Debian Weak Key Problem
At 2:56 PM -0700 6/9/08, Nelson B Bolyard wrote: Paul Hoffman wrote, On 2008-06-09 09:41: At 11:22 AM +0200 6/9/08, Jean-Marc Desperrier wrote: Aren't the people who send their credit card number on an https connexion where the private key of the server is public knowledge already screwed ? Yes, of course. The question for this thread is: who is responsible for each screwedness? I beg to differ. The question is: for what is the CA responsible? That's not much of a question, because it is answered in each CPS. Mozilla has reviewed each CPS. It is for assuring the certified binding of name and key. Fully agree. When that binding has no more assurances, the certificate becomes a false statement of assurance. If that's what the CPS says, sure. But if the CPS doesn't say that, then no. However, given that a CA cannot know whether or not a domain has been compromised, A CA can know that a key has been compromised. Whether an actual exploit of that compromise exists for any user at any specific time may be unknowable, but is not the only factor in determining the CA's responsibility to the relying parties. Fully agree, if the CPS lists more responsibilities (I have only read a few, but all of those did). a CA that tries to save the customer by revoking the possibly-compromised domain's keys is overstepping its responsibility. The keys in question are not possibly compromised. They are compromised. Period. Until we see any evidence of this in the real world, we disagree. Only the degree to which the compromised key has been exploited may be unknown. Of course. A CA who informs it relying parties that it can no longer assure the binding that it once certified is fulfilling its responsibility, not exceeding it. a) Let's be careful with our assertions. The CA can still assure the binding of the name to the public key; what they can't assure is the unique control over the private key. b) Does revoking a certificate inform a relying party of anything significant? For better or worse, revocation is a giant one-bit club. c) What responsibilities does a CA have to relying parties? I have never signed a contract with any of them. To be frank, browser vendors have more responsibilities to relying parties than CAs do. That's why the browser vendors carefully check CPSs and enforce rules about them. Isn't the entity the users trust when they see a certificate foremost the CA that emitted it ? Yes. That trust hasn't been broken, unless the CA said to the users and we will revoke the certificate if we suspect that the key could likely be compromised. The keys ARE compromised. A CA who refuses to timely revoke a cert with a known compromised key abrogates any public trust. Any? Do you really think that a typical Firefox user, even when this is all explained to them, would be as strident as you are here? They keys are not broken, they are trivial to break if an attacker wants to. They are compromised. There is no reason to believe that only the named subject holds the corresponding private key, (since I also hold it :). Understood. That's an important difference, and one that needs to be made in any warning we give to a user. It's the difference between Your drawer in the bank vault has been robbed and the bank vault door lock is now broken and the door is wide open. Both situations demand action. Yeah, right. Trust in SSL certificates is like a bank vault. Not in this universe. But, if you feel that way, why don't you get the people who the relying parties trust most, the browser vendors, to fix the problem? Why rely on the CAs, who have repeatedly shown themselves to be half-hearted at best? ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Debian Weak Key Problem
Eddy Nigg (StartCom Ltd.) wrote, On 2008-06-09 17:19: Nelson B Bolyard: In this case, the guy held up a bag of ~96 thousand private keys and said See, here are 96 thousand private keys that I possess. Anyone can have a copy of them. I can't imagine better proof of key compromise than that. Oh well, I could add another few thousands to those if you want, it itself isn't really useful, isn't it? You still have to find the right one, That takes a fraction of a second. Take the cert. Extract the public key, look up the public key in the list. If found, take the corresponding private key from the list. total time: less than one second. But merely waiving this bag of ~96 thousand private keys and actually potentially some more, doesn't go far enough to call it literally a key compromise. Every cert bearing a public key from that list is compromised. I could produce millions of keys in my free time and post them to some web site...I could tell you now that those are all compromised keys and all CAs should now scan their subscribers keys against the ones I posted. Should it find one, it should revoke it, right? Of we're talking about keys generated by a truly random process, then the chances of finding a cert with a public key you generated are very low. But for anyone relying on a cert whose key pair was generated on a debian system, the chances are very high, because the process was not at all random. One or more well known and large CAs have already found many certs whose public keys are in that list. There's no question that those keys are compromised, The question is: what are the CAs' responsibility regarding the certs with those compromised keys? Yes, if there is knowledge that you got my key then there is no doubt about that, however right now you are demanding that CAs scan all their subscribers keys against those 100,000 and potentially more keysit's like you coming up to the bank and saying, Look, I've got here 100,000 keys, one of which *might* match that of Eddy's. CAs are already doing this, Eddy. The issue is: what is the responsibility after this is done and the compromised certs are identified. It's an unlucky situation for certain and those using Debian should perhaps know about the problem. But I'm not sure if all CAs can afford to scan all subscriber keys. It's cheap and pretty fast. I'm sure most CAs who have kept copies of the unexpired certs they have issued could have done it already in the time that this issue has been publicly discussed. Perhaps the very biggest ones would take a little longer. I don't think a CA can retain credibility if it says We just won't examine the certs we issued for compromised keys, and that way we won't have any responsibility. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Debian Weak Key Problem
Andrews, Rick wrote: That strikes me as a policy that one might describe as attacker friendly. I suggest: revoke first, contact later. When you revoke the certs, you're protecting your relying parties, and you can count on your relying parties to contact the subjects whose certs have been revoked. :) That's a good question, and I don't know the answer. I'll bring it up with the business folks to decide what we should do. I fear that your business people will only look at the customers' (subscriber) side. But as a relying party I'd want that certs for weak keys are revoked in any case. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Debian Weak Key Problem
On Sun, Jun 8, 2008 at 5:21 AM, Michael Ströder [EMAIL PROTECTED] wrote: Andrews, Rick wrote: That strikes me as a policy that one might describe as attacker friendly. I suggest: revoke first, contact later. When you revoke the certs, you're protecting your relying parties, and you can count on your relying parties to contact the subjects whose certs have been revoked. :) That's a good question, and I don't know the answer. I'll bring it up with the business folks to decide what we should do. I fear that your business people will only look at the customers' (subscriber) side. But as a relying party I'd want that certs for weak keys are revoked in any case. My thought is that if there's any knowledge that a CA has that a key has been compromised, the CA can no longer verify the binding of the key to the subject -- which means that the certification should not exist, and thus must be revoked. Then again, I'm something of a 'purist' when it comes to viewing what a CA's responsibilities are. How much does it cost the CA to mint a new certificate? How much liability does the CA assume in the case where a subject's certificate is used by someone other than the subject through no real fault of the subject's? (This is one of the reasons why I don't believe it's viable to charge per-certificate, but rather per-timeperiod.) -Kyle H ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Debian Weak Key Problem
Kyle Hamilton: How much does it cost the CA to mint a new certificate? Not much...guess that part is covered by the standing run time costs of the CA. How much liability does the CA assume in the case where a subject's certificate is used by someone other than the subject through no real fault of the subject's? Key generation of EE certificates is usually covered in the CP/CPs to be the responsibility of the subscriber. In this respect the CA can't be liable, except if the trustworthy system the user is supposed to use was that of the CA and/or the key was provided by the CA. (This is one of the reasons why I don't believe it's viable to charge per-certificate, but rather per-timeperiod.) Or how about a per validation charge since this is really the real effort a CA does? ;-) Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Debian Weak Key Problem
At 1:28 PM -0700 6/8/08, Kyle Hamilton wrote: How much does it cost the CA to mint a new certificate? How much liability does the CA assume in the case where a subject's certificate is used by someone other than the subject through no real fault of the subject's? Zero and zero. How much hassle is it for a customer of the CA to have its certs all of a sudden be rejected by all the clients that do OCSP or CRL checking? (Hint: much greater than zero.) (This is one of the reasons why I don't believe it's viable to charge per-certificate, but rather per-timeperiod.) Sure, but that's not the model most CAs have with their customers. I would bet that if a CA sent out a message saying we're revoking your cert tomorrow, here's a new one to all of its affected customers, fewer than 95% would have the new cert installed correctly. The remainder would be screwed, and the customer support lines (and I use that term very loosely) would be jammed. A better mechanism would be for the CAs to send out repeated letters saying that the keys are probably compromised and the certified party really really really should do an update. If they don't, it is now the responsibility of the certified party. --Paul Hoffman ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Debian Weak Key Problem
Andrews, Rick wrote: I just wanted to mention that we've been working feverishly to automate checking of all valid certs in our databases. It's taking time because it's a huge task - we have hundreds of thousands of certs to check - but we intend to notify any customer who is using a weak key. That's good to know, Rick - thanks :-) Gerv ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Debian Weak Key Problem
Andrews, Rick wrote, On 2008-06-04 15:24: It seems that CAs are not bothering to contact their customers with weak keys[1], although they are of course revoking the keys of customers who ask, and reissuing certificates. Gerv, I just wanted to mention that we've been working feverishly to automate checking of all valid certs in our databases. It's taking time because it's a huge task - we have hundreds of thousands of certs to check - but we intend to notify any customer who is using a weak key. Rick, Does this mean that Verisign will not revoke the cert unless and until the customer agrees to it? If a customer doesn't agree, or doesn't respond, will the cert remain unrevoked until it expires? That strikes me as a policy that one might describe as attacker friendly. I suggest: revoke first, contact later. When you revoke the certs, you're protecting your relying parties, and you can count on your relying parties to contact the subjects whose certs have been revoked. :) ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Debian Weak Key Problem
Andrews, Rick wrote, On 2008-06-04 15:24: It seems that CAs are not bothering to contact their customers with weak keys[1], although they are of course revoking the keys of customers who ask, and reissuing certificates. Gerv, I just wanted to mention that we've been working feverishly to automate checking of all valid certs in our databases. It's taking time because it's a huge task - we have hundreds of thousands of certs to check - but we intend to notify any customer who is using a weak key. Rick, Does this mean that Verisign will not revoke the cert unless and until the customer agrees to it? If a customer doesn't agree, or doesn't respond, will the cert remain unrevoked until it expires? That strikes me as a policy that one might describe as attacker friendly. I suggest: revoke first, contact later. When you revoke the certs, you're protecting your relying parties, and you can count on your relying parties to contact the subjects whose certs have been revoked. :) Nelson, That's a good question, and I don't know the answer. I'll bring it up with the business folks to decide what we should do. -Rick -- Rick Andrews __oPhone: 650-426-3401 VeriSign, Inc. _ \,_ Fax: 650-426-5195 487 E. Middlefield Rd. ...(_)/ (_) URL: www.verisign.com Mountain View, CA 94043email: [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
