Debian Weak Key Problem
Gervase Markham
Many of you will know about the problem with weak keys generated on
Debian or Debian-derivative systems between certain dates.[0] This
affects SSL certificates generated on those systems. CAs trusted by
Firefox have signed, and therefore endorsed, many such keys.
Once a hacker finds a server using a weak key, they can use the public
key to find the private key and so MITM or spy on traffic to that server
perfectly. All the relevant security indications will be present. This
negates all security in the SSL model.
Current data indicates that there may be up to 26,000 such keys out
there being used on public websites.[1] We are attempting, through
various channels, to get a firmer number and a list of vulnerable sites.
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.[2] Firefox 3 has caching OCSP turned on
by default (with "soft-fail") and so would detect the revocation of
these keys. Firefox 2 does not have OCSP turned on by default. Both
browsers support CRLs, but do not have the capability to download CRLs
from URLs listed in certificates.
Here are some possible options (not mutually exclusive) for what to do:
- Do nothing
Once Firefox 3 is released, many people will upgrade. This means they
will be using soft-fail OCSP, and so will detect attempts to use revoked
keys.
However, because CAs are not actively contacting their customers, many
weak keys will still be being used, and we'd have no way to tell if
there was an MITM going on in that case.
This might be a reason to try and expedite pushing Firefox 3 into the
Firefox 2 update channel.
- Modify NSS to detect weak keys
Lists of all the weak keys exist - we could create a database of the
first 8 bytes or so of the hash of each and get NSS to check it when it
sees a key. This would involve a code change to NSS and a security
update. We'd probably want to download the list of weak keys rather than
ship it with the update. NSS would then return an error to the
application if a weak key was found, and the connection would abort.[3]
- Modify NSS/Firefox to detect weak sites
If we can get a fairly complete list of vulnerable sites (which might be
smaller than the hashes of a large number of keys) and their key
fingerprints we could modify Firefox or NSS to refuse to connect to them
until the key changed.
- Add the sites to the malware or phishing feeds
Quite a drastic option, but we could even leverage existing code by
adding the vulnerable sites to the feeds of phishing or malware sites.
- Contact CAs to put pressure on for them to contact their customers
We could use our contacts with CAs to try and convince them to change
their position on customer contact.
- Publish a "CA hall of shame"
If and when we get good data on the extent of the problem, we could try
and shame CAs into doing something. "3% of FooCA-signed certificates are
totally insecure. Is yours one of them?"
- Attempt to contact site owners
But 26,000 sites is a lot. We could try cross-referencing the sites with
Alexa data to get a priority order.
- Turn on OCSP in the next Firefox 2 security release
This might help in the short term, with the same limitations as listed
under "Do Nothing" for the Firefox 3 update. But Firefox 2's OCSP
support is not as complete; it doesn't do caching, and it hard-fails. So
we might melt the OCSP servers, and that would severely degrade the user
experience because no-one could make SSL connections.
- Ship a Firefox 2 update with some built-in CRLs
If OCSP is not an option, the next Firefox update could include static
copies of the various different major CAs' revocation lists from the
period concerned. These would probably be of significant size.
- Something else
Suggestions?
Gerv
[0] http://www.us.debian.org/security/2008/dsa-1571
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=435082#c22
[2]
http://wiki.debian.org/SSLkeys#head-5450db0076b3d85650f72117a9884f89d2349032
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=435082
Andrews, Rick
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 Andrews
--
Rick Andrews __o Phone: 650-426-3401
VeriSign, Inc. _ \>,_ Fax: 650-426-5195
487 E. Middlefield Rd. ...(_)/ (_) URL: www.verisign.com
Mountain View, CA 94043 email: rand...@verisign.com
Gervase Markham
> 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
Nelson B Bolyard
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,
>
> 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. :)
Andrews, Rick
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
Michael Ströder
>> 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. :)
>
> 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.
Kyle Hamilton
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
Eddy Nigg (StartCom Ltd.)
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.)
| Regards | |
| Signer: | Eddy Nigg, StartCom Ltd. |
| Jabber: | star...@startcom.org |
| Blog: | Join the Revolution! |
| Phone: | +1.213.341.0390 |
Paul Hoffman
>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
Jean-Marc Desperrier
> [...]
> 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.
Paul Hoffman
>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.
Michael Ströder
>
> 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.
Nelson B Bolyard
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?
Nelson B Bolyard
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.
Eddy Nigg (StartCom Ltd.)
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.
If the CA provides a crappy utility for creating keys, than it would the CA's responsibility of course.
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.
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.
The keys ARE compromised. A CA who refuses to timely revoke a cert with a known compromised key abrogates any public trust.
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.
Nelson B Bolyard
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 ?
>>>>
>>> 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.
Eddy Nigg (StartCom Ltd.)
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.
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?
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.
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. Oh, and there are many other pressing problems which Mozilla ignores outright, for which you don't even need a private key in order to spoof a site and pretend to be someone else...MITM in plain text is still very affordable just in case somebody forgot.
Nelson B Bolyard
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 keys....it'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."
Paul Hoffman
>Paul Hoffman wrote, On 2008-06-09 09:41:
>> At 11:22 AM +0200 6/9/08, Jean-Marc Desperrier wrote:
>
>>> connexion where the private key of the server is public knowledge
>>> already screwed ?
>>
>> 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?
Eddy Nigg (StartCom Ltd.)
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?
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 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."
Nelson B Bolyard
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.
The relying parties then have only false assurances of the bindings.
>> 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.
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?
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? Of what value is it?
Similarly, what good is it to assert that "When you verify a signature
with this public key, you can be confident that the signature was
generated by the party named in this cert OR any of millions of others." ?
What kind of "binding" is that? Of what value is it?
> b) Does revoking a certificate inform a relying party of anything
> significant? For better or worse, revocation is a giant one-bit club.
Yes, it causes relying parties to stop relying on the no-longer assured
binding (if their software recognizes the revocation, which FF3 does,
and FF2 can if enabled).
> 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. It's value to subscribers
is directly a function of the number of relying parties who trust it.
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) and finds few subscribers.
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.
> 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.
>> 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. 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.
There are repeated calls for Mozilla to adopt an SSH-like KCM strategy of
"trust and store any cert, regardless of issuer, on first sight (if there is
not already a cert stored and trusted for that host name), and complain
when any host offers a cert different than that offered in the past."
That is the number one most frequently repeated request in Mozilla mailing
lists (private and public), newsgroups and bugs for years and years now.
There is a significant percentage of Mozilla leaders who are sympathetic
to that view. Many of them subscribe fully to the view that certs from any
OpenSSL user are just as trustworthy as certs from any institutional CA.
Of course, the Achilles-heel of KCM is absent revocation. The recent Debian
debacle has resulted in the creation of a 3 MB (compressed) key revocation
list (KRL) that people now propose to carry forward in perpetuity in all
software. That monstrosity offers CAs an opportunity to demonstrate some
real differentiation and value here, the value of revocation, something that
KCM will never offer. I believe the 3MB KRL that resulted from the Debian
debacle is the stake that the PKI community can finally drive through the
heart of KCM, if it has the will to do so.
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.
Any CA who, in light of this opportunity, chooses to demonstrate a desire to
"put his best foot forward" and "save face" for himself and his subscribers,
rather than showing his commitment to proactive revocation,
discredits himself (and perhaps the whole PKI community) to the people who
most want to see PKI fail and be supplanted by KCM in Mozilla products.
> 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?
That's actually what motivates me to participate in this thread.
> Why rely on the CAs, who have repeatedly shown themselves to be
> half-hearted at best?
The browser vendors can fix the problem by really enforcing trusted cert
policies that really protect their users. That means putting pressure
on CAs. A fear of enforcing policies (or having weak policies) due to
fear of lost market share, ultimately undermines trust in PKI.
Regards,
/Nelson B
Michael Ströder
> 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.
Michael Ströder
>> 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.
Oh, come on. With ready-to-use tools to scan for these weak keys the
evidence is there.
>> 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.
Yes. But being in the CA *business* I would take this case to attest my
trustability.
> b) Does revoking a certificate inform a relying party of anything
> significant?
Yes. It makes a cert invalid. (I know that CRLs are not checked in
practice very often.)
> c) What responsibilities does a CA have to relying parties? I have never
> signed a contract with any of them.
Paul, that's really a very poor argument! Well, exactly this leads to
the conclusion of PKI critics who pointed out that CAs are hiding behind
their CPSs and do not feel responsible for anything.
> 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.
This would mean kicking out all root CA certs of CA (chains) which do
not act on this particular "Debian Weak Key Problem". ;-)
>> 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?
The typical Firefox user trusts the PKI. It delegates security checks to
a trusted third party. The CA's *business* is to help this average user
to use SSL-enabled Internet securely.
Ciao, Michael.
Michael Ströder
> 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.
Michael Ströder
> 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.
Kyle Hamilton
> 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.
I was asking about the marginal cost. It may be 'zero' from the view
of "just tell the computer to do it", but it's certainly not zero from
the view of "pay someone to tell the computer to do it." (The precise
cost varies from CA to CA, but if there are two people who have to
authorize a certification then both need their salaries paid -- which
gets amortized over the amount of time they spend on authorizations
per year (i.e., not doing other useful work) and how many
certifications they authorize per year Add to that the cost of
auditing the recertifications, and you'll have a more realistic
amount.
Further, there is one type of liability that the CA cannot avoid or be
indemnified for: reputation. If I were to know that Verisign, for
example, did not revoke known-compromised keys' certificates, then my
opinion of Verisign -- its reputation with me -- would be negatively
impacted. I am also known for being rather vociferous about my
complaints; this would have the effect of negatively impacting their
reputation with the people who listen to me. (Sure, they might be
able to sue me -- though I'd simply be stating my opinion that I have
lost the respect for their 'most trusted name on the Internet' and
following it up with the true statement that it was because they made
a statement about what their relying parties could rely on without
backing it up through their actions. This would not be either slander
or libel.)
> 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.)
What, you're saying that Mozilla has a duty to the CAs that it has
accepted to minimize disruption based on those CAs' own (lack of)
action?
If this is true, then this would be 'collusion', possibly
'conspiracy', 'extortion', and 'racketeering'. It would also be
'fraud' on Mozilla's part toward its users, based on the fact that the
CAs are used in primarily fiscal transactions with the purpose of
allowing end users to positively identify who they're transacting
with. (This, incidentally, puts it squarely into the realm of
'fiduciary', and it's a blatant conflict of interest to owe a duty to
one side that violates that fiduciary relationship that the browser
vendor has with the browser user.)
The only effective recourse that Mozilla would have in this situation
to avoid such criminal charges and attendant civil liability would be
to remove the CA's certificate from the trust list. (I don't believe
that case law allows for fiduciaries to limit their liability, no
matter what language they try to use in their agreements.)
>>(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.
Er, unless the CA is in the practice of generating the private keys on
behalf of the customer, that's a completely infeasable concept. (If
not, the user has already gone through the process of enrolling at
least once.)
I daresay that if there's a problem generating and using CA-issued
certificates (and I agree, there generally is), then it's a problem
with the user interface of the software that's working with those
certificates, and the CAs and users need to lean on the software
vendors. (note: Firefox does not make it 'intuitive' or 'easy' to
interact with the certificates. This is absolutely a bug. Neither
does Microsoft Windows, but it's at least a bit easier. OSX is easier
still, but also still "difficult" for the average user.)
> 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.
*shakes his head* If the CA does not revoke known-compromised keys'
certifications, then why should the CA be trusted to make any
assertion? Why should I trust that I can rely on the certificate
without having to do additional checking (verifying the public key
against my own database of known-compromised keys, for instance)?
And why should I have to do that when I'm supposed to be able to trust the CA?
And if I can be burned by this, why shouldn't I bust the organization
that states it vets the CAs so that they can make a decision of trust
on my behalf, to trust that the organization is making statements that
I can trust?
-Kyle H
Paul Hoffman
>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.
>>>
>>> Period.
>>
>> Until we see any evidence of this in the real world, we disagree.
>
>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 Mozilla community was that it
>was initially promoted by the very CA they most despised.
We agree here. But that's not what I asked.
>There are repeated calls for Mozilla to adopt an SSH-like KCM strategy of
>"trust and store any cert, regardless of issuer, on first sight (if there is
>not already a cert stored and trusted for that host name), and complain
>when any host offers a cert different than that offered in the past."
>That is the number one most frequently repeated request in Mozilla mailing
>lists (private and public), newsgroups and bugs for years and years now.
>There is a significant percentage of Mozilla leaders who are sympathetic
>to that view. Many of them subscribe fully to the view that certs from any
>OpenSSL user are just as trustworthy as certs from any institutional CA.
I am sometimes in that camp, sometimes not.
>Of course, the Achilles-heel of KCM is absent revocation. The recent Debian
>debacle has resulted in the creation of a 3 MB (compressed) key revocation
>list (KRL) that people now propose to carry forward in perpetuity in all
>software. That monstrosity offers CAs an opportunity to demonstrate some
>real differentiation and value here, the value of revocation, something that
>KCM will never offer. I believe the 3MB KRL that resulted from the Debian
>debacle is the stake that the PKI community can finally drive through the
>heart of KCM, if it has the will to do so.
So far: nothing. No discussion of it in the PKI world.
>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.
Have you figured out how many of the TAs in the pile actually have
OCSP responders available? And, of those that do, how many have
revoked any of the certificates that have trivial-to-break keys?
Those numbers would be valuable to make or refute your argument here.
> > 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?
>
>That's actually what motivates me to participate in this thread.
Sorry, I don't see it. You keep advocating for CAs to revoke the
certificates. I am advocating for Firefox to fix the problem by
looking for bad keys first, then changing our policies about
acceptable CPSs.
> > Why rely on the CAs, who have repeatedly shown themselves to be
>> half-hearted at best?
>
>The browser vendors can fix the problem by really enforcing trusted cert
>policies that really protect their users. That means putting pressure
>on CAs.
We disagre. To me, that means acting on information that we know,
namely that "this cert I'm seeing has a weak key".
>A fear of enforcing policies (or having weak policies) due to
>fear of lost market share, ultimately undermines trust in PKI.
...that has, as you yourself argue, already been mostly undermined.
Kyle Hamilton
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
> _______________________________________________
> dev-tech-crypto mailing list
> dev-tec...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
Jean-Marc Desperrier
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).
Gervase Markham
> 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
Jean-Marc Desperrier
> [...]
>> 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.
Gervase Markham
> 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
Jean-Marc Desperrier
> 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.
Paul Hoffman
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.
Eddy Nigg
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: star...@startcom.org
Jean-Marc Desperrier
> [...]
> 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 ?
Eddy Nigg
Yes, I intended to do that later anyway, but I didn't had the final
information ready when I previously posted. I can't say for certain
right now how many *were* affected overall, because some subscribers
requested revocation beforehand and we didn't scanned expired or already
revoked keys, but out of all currently valid certificates 1.95 %
were/are affected by the Debian bug (Our initial estimates was about
1.66 %).
Revocation requests are trickling in due to the messages we sent and I
hope that the larger part will have their certificates revoked and
re-created during the next few days. The remaining certificates will be
revoked forcefully within a short time.
With this we took over the responsibilities of our subscribers according
to our CP/CPS and our share of approximately 3.5 % of overall legitimate
certificates will be "Debian-bug-free". Due to the relative short
lifetime of one year for end-user certificates which we issue, I expect
that even older browsers will be "safe" within a reasonable time
(another reason why not to issue certificates with a longer life-time
than one year - a good practice).
All certificate signing requests submitted to the StartCom CA are
scanned for this vulnerability and effectively since June 2008 no
certificates are signed with weak keys. Cheers!
Michael Ströder
> Jean-Marc Desperrier:
>> 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 ?
>
> Yes, I intended to do that later anyway, but I didn't had the final
> information ready when I previously posted. I can't say for certain
> right now how many *were* affected overall, because some subscribers
> requested revocation beforehand and we didn't scanned expired or already
> revoked keys, but out of all currently valid certificates 1.95 %
> were/are affected by the Debian bug (Our initial estimates was about
> 1.66 %).
Thanks for this numbers.
> Revocation requests are trickling in due to the messages we sent and I
> hope that the larger part will have their certificates revoked and
> re-created during the next few days. The remaining certificates will be
> revoked forcefully within a short time.
Thanks for your clear action. I'm pretty sure customers are also
appreciating this.
Ciao, Michael.
Gervase Markham
> Thanks for your clear action. I'm pretty sure customers are also
> appreciating this.
I don't know about customers. Relying parties certainly are, though :-)
Gerv
Rob Stradling
That is now old news. I'm pleased to announce that...
1. Our systems will now use the very latest blacklists from the
openssl-blacklist project to identify and reject CSRs with weak keys. This
will prevent us from issuing any further certificates with weak keys.
2. We have analyzed all of the unexpired, unrevoked certificates that we've
issued. Approximately 1.5% were found to contain weak keys.
3. We have emailed all of our affected customers to:
i. alert them to the security risk and to offer them a free replacement
certificate.
ii. advise them that we plan to revoke all certificates with weak keys soon.
4. We have been monitoring the rate at which customers are replacing their
installed certificates. 24 hours after emailing them, we estimate that 8%
had done so. We will continue to monitor this.
On Friday 13 June 2008 22:19:09 Paul Hoffman wrote:
> 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.
> _______________________________________________
> dev-tech-crypto mailing list
> dev-tec...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
--
Rob Stradling
Senior Research & Development Scientist
Comodo - Creating Trust Online
Office Tel: +44.(0)1274.730505
Fax Europe: +44.(0)1274.730909
www.comodo.com
Comodo CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ
This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender by replying
to the e-mail containing this attachment. Replies to this email may be
monitored by Comodo for operational or business reasons. Whilst every
endeavour is taken to ensure that e-mails are free from viruses, no liability
can be accepted and the recipient is requested to use their own virus checking
software.
Gervase Markham
> That is now old news. I'm pleased to announce that...
<applause>
Gerv
Eddy Nigg
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.