Gervase Markham:
> Rob Stradling wrote:
>> That is now old news. I'm pleased to announce that...
>
>
>
>
> 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
Rob Stradling wrote:
> That is now old news. I'm pleased to announce that...
Gerv
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
"Comodo is offering a free replacement SSL certificate to any affected
business, regardless of their original provider...No mention of any CA
actively contacting affected customers, much less revoking any certs."
That is now old news. I'm pleased to announce that...
1. Our systems will now use
Michael Ströder wrote:
> 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
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.or
Eddy Nigg wrote:
> 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 issu
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,
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 ?
__
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
>
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 r
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
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 b
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 oppo
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
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 fi
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 d
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
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:
On Sun, Jun 8, 2008 at 5:56 PM, Paul Hoffman <[EMAIL PROTECTED]> wrote:
> 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 su
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 al
KI 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.
Thi
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 i
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),
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 c
Nelson B Bolyard:
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?
That really depen
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
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
>>> alr
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 tho
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 ?
Nelson B Bolyard:
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 qu
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
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
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 subjec
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 custome
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 correctl
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 hass
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 fa
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
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
>> ce
> 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 b
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 fev
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 k
> 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
[Please respect the Followup-To header, set to mozilla.dev.security]
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 t
43 matches
Mail list logo
