On 09/09/2011 11:48 AM, Marcus Reid wrote:

On Wed, Sep 07, 2011 at 09:17:10AM -0700, Network IP Dog wrote:

...

FYI!!!

http://seattletimes.nwsource.com/html/microsoftpri0/2016132391_microsoft_dee ms_all_diginotar_certificates_untrust.html

Google and Mozilla have also updated their browsers to block all DigiNotar certificates, while Apple has been silent on the issue, a emblematic zombie response! Apple has sent out a notification saying that they are removing DigiNotar from their list of trusted root certs.

I like this response; instant CA death penalty seems to put the incentives about where they need to be.

Marcus

Instant? This has been going on for over a week, and a lot of damage could have been done in that time, especially given certs for *.*.com were signed against Diginotar. Most cell phones are unable to update their certificates without an upgrade and you know how long it takes to get them through Cell Phone carriers. A number of alternative android builds are adding the ability to control accepted root certs to their builds in the interest of speeding this up. The CA system is fundamentally flawed. Paul

On 09/09/11 20:06 -0700, Michael DeMan wrote:

Sorry for being ignorant here - I have not even been aware that it is possible to buy a '*.*.com' domain at all.

I though wildcards were limited to having a domain off a TLD - like '*.mydomain.tld'.

Is it true that the my browser on a windows, mac, or linux desktop may have listed as trusted authorities, an outfit that sells '*.*.tld' ?

The issue is that a trusted third party's (Diginotar) trusted signing certificate was stolen, allowing the holder to create and sign whatever certificates he wished, which don't necessarily need to be wildcard certs to be effective. Certificate signers are not restricted to any domain hierarchy (a design feature of x.509 pki), which means that *any* trusted stolen signing certificate can wreak havok on the trusted nature of x.509. Even the hint that the claimed Diginotar cracker has gotten her hands on several other signing certificates may be significant motivation to find a replacement for the existing x.509 based pki.

On Sep 9, 2011, at 2:54 PM, Paul wrote:

...

On 09/09/2011 11:48 AM, Marcus Reid wrote:

...

On Wed, Sep 07, 2011 at 09:17:10AM -0700, Network IP Dog wrote:

...

FYI!!!

http://seattletimes.nwsource.com/html/microsoftpri0/2016132391_microsoft_dee ms_all_diginotar_certificates_untrust.html

Google and Mozilla have also updated their browsers to block all DigiNotar certificates, while Apple has been silent on the issue, a emblematic zombie response! Apple has sent out a notification saying that they are removing DigiNotar from their list of trusted root certs.

I like this response; instant CA death penalty seems to put the incentives about where they need to be.

Marcus

Instant? This has been going on for over a week, and a lot of damage could have been done in that time, especially given certs for *.*.com were signed against Diginotar. Most cell phones are unable to update their certificates without an upgrade and you know how long it takes to get them through Cell Phone carriers. A number of alternative android builds are adding the ability to control accepted root certs to their builds in the interest of speeding this up. The CA system is fundamentally flawed.

Paul

-- Dan White

On Sat, Sep 10, 2011 at 3:47 AM, Heinrich Strauss <heinrich@hstrauss.co.za> wrote:

On 2011/09/10 05:06, Michael DeMan wrote:

...

I though wildcards were limited to having a domain off a TLD - like '*.mydomain.tld'. The root CAs are have no technical limitation in regards to what kind of certificates they can issue. There is no inherent reason that technical limitations cannot be imposed... there are mechanisms available to do this, if the original CA certificates were issued with restrictions: http://tools.ietf.org/html/rfc3280#section-4.2.1.11

Special limitations or "security warnings" can be raised by individual browsers above and beyond the certificate validation rules. I would be in favor of each root CA certificate being name constrained to CNs of one TLD per CA certificate, so that root CA orgs would need a separate CA cert and separate private key for each TLD that CA is authorized to issue certificates in. It would be useful if the name restriction would be extended further to allow 2nd level wildcards to be prohibited such as "CN=*.com" or "CN=*.*.com" Browsers will honor "*" in hostname components of the CN field as required by the RFCs.. however a "*.mydomain.tld" certificate does not match www.mydomain.tld, "*.*.mydomain.tld" does. Some CAs have partaken in problematic practices such as issuing SSL certificates with RFC1918 IP addresses, or "unofficial" TLDs in the CN or subject alternative names section. see https://wiki.mozilla.org/CA:Problematic_Practices#Issuing_SSL_Certificates_f... If all the root CA certificates become name constrained, such problematic practices should cease. -- -JH

On Fri, Sep 9, 2011 at 11:33 PM, Jimmy Hess <mysidia@gmail.com> wrote:

On Fri, Sep 9, 2011 at 4:48 PM, Marcus Reid <marcus@blazingdot.com> wrote:

...

On Wed, Sep 07, 2011 at 09:17:10AM -0700, Network IP Dog wrote: I like this response; instant CA death penalty seems to put the incentives about where they need to be.

I wouldn't necessarily count them dead just yet; although their legit customers must be very unhappy waking up one day to find their legitimate working SSL certs suddenly unusable....

So DigiNotar lost their "browser trusted" root CA status. That doesn't necessarily mean they will be unable to get other root CAs to cross-sign CA certificates they will make in the future, for the right price.

A cross-sign with CA:TRUE is just as good as being installed in users' browser.

The problem here wasn't just that DigiNotar was compromised, but that they didn't have an audit trail and attempted a coverup which resulted in real harm to users. It will be difficult to re-gain the trust they lost. Because of that lost trust, any cross-signed cert would likely be revoked by the browsers. It would also make the browser vendors question whether the signing CA is worthy of their trust. Damian -- Damian Menscher :: Security Reliability Engineer :: Google

On Sep 10, 2011 11:38 PM, "Damian Menscher" <damian@google.com> wrote:

On Fri, Sep 9, 2011 at 11:33 PM, Jimmy Hess <mysidia@gmail.com> wrote:

...

On Fri, Sep 9, 2011 at 4:48 PM, Marcus Reid <marcus@blazingdot.com>

wrote:

...

...

On Wed, Sep 07, 2011 at 09:17:10AM -0700, Network IP Dog wrote: I like this response; instant CA death penalty seems to put the incentives about where they need to be.

I wouldn't necessarily count them dead just yet; although their legit customers must be very unhappy waking up one day to find their legitimate working SSL certs suddenly unusable....

So DigiNotar lost their "browser trusted" root CA status. That doesn't necessarily mean they will be unable to get other root CAs to cross-sign CA certificates they will make in the future, for the right price.

A cross-sign with CA:TRUE is just as good as being installed in users' browser.

The problem here wasn't just that DigiNotar was compromised, but that they didn't have an audit trail and attempted a coverup which resulted in real harm to users. It will be difficult to re-gain the trust they lost.

Because of that lost trust, any cross-signed cert would likely be revoked by the browsers. It would also make the browser vendors question whether the signing CA is worthy of their trust.

Yep. The CA business is one of trust. If the CA is not trusted, they are out of business. Cb

Damian -- Damian Menscher :: Security Reliability Engineer :: Google

On 9/10/11 23:30 , Damian Menscher wrote:

On Fri, Sep 9, 2011 at 11:33 PM, Jimmy Hess <mysidia@gmail.com> wrote:

...

On Fri, Sep 9, 2011 at 4:48 PM, Marcus Reid <marcus@blazingdot.com> wrote:

...

On Wed, Sep 07, 2011 at 09:17:10AM -0700, Network IP Dog wrote: I like this response; instant CA death penalty seems to put the incentives about where they need to be.

I wouldn't necessarily count them dead just yet; although their legit customers must be very unhappy waking up one day to find their legitimate working SSL certs suddenly unusable....

So DigiNotar lost their "browser trusted" root CA status. That doesn't necessarily mean they will be unable to get other root CAs to cross-sign CA certificates they will make in the future, for the right price.

A cross-sign with CA:TRUE is just as good as being installed in users' browser.

The problem here wasn't just that DigiNotar was compromised, but that they didn't have an audit trail and attempted a coverup which resulted in real harm to users. It will be difficult to re-gain the trust they lost.

Because of that lost trust, any cross-signed cert would likely be revoked by the browsers. It would also make the browser vendors question whether the signing CA is worthy of their trust.

To pop up the stack a bit it's the fact that an organization willing to behave in that fashion was in my list of CA certs in the first place. Yes they're blackballed now, better late than never I suppose. What does that say about the potential for other CAs to behave in such a fashion?

Damian

Steinar, On Sun, Sep 11, 2011 at 8:12 PM, <sthaug@nethelp.no> wrote:

...

To pop up the stack a bit it's the fact that an organization willing to behave in that fashion was in my list of CA certs in the first place. Yes they're blackballed now, better late than never I suppose. What does that say about the potential for other CAs to behave in such a fashion?

I'd say we have every reason to believe that something similar *will* happen again :-(

Something similar, including use of purchased (not only limited to stolen certs), is ongoing already, all of the time. (I had a fellow IRC-chat-friend report from a certain very western-allied middle eastern country that there's ISP/state-scale SSL-MITM ongoing there, for all https traffic.) The comment on starting out with an empty /etc/ssl is valid. Most of the normally included CA's you almost never run into on the wild web anyway. There were some blog postings about this last time a CA was busted. Shave off 90% of them and you have at least come a bit on the way (goal 100%). The absence of proof is *not* proof of absence, and in this particular case it's pretty safe to assume some abuse is ongoing somewhere, 24/7. Cheers, Martin

...

Because of that lost trust, any cross-signed cert would likely be revoked by the browsers. It would also make the browser vendors question whether the signing CA is worthy of their trust.

To pop up the stack a bit it's the fact that an organization willing to behave in that fashion was in my list of CA certs in the first place. Yes they're blackballed now, better late than never I suppose. What does that say about the potential for other CAs to behave in such a fashion?

The average corporation much prefers to avoid the bad publicity and will downplay most bad things. Your favorite CA probably included. I think that it's hard to cope with SSL. It doesn't do the right things for the right reasons. Many of us, for example, operate local root CA's for signing of "internal" stuff; all our company gear trusts our local root CA and lots of stuff has certs issued by it. In an ideal world, this would mean that our gear talking to our gear is always secure, but with other root CA's able to offer certs for our CN's, that isn't really true. That's frustrating. The reality is that - for the average user - SSL doesn't work well unless about 99% of the CA's used by the general public are included as "trusted." If a popular site like Blooble has a cert by DigiNotar and the Firerox browser is constantly asking what to do, nothing really good comes out of that ... either people think Firerox blows, or they learn to click on the "ignore this" (or worse the "always trust this") button. In about 0.0% of the cases do they actually understand the underlying trust issues. So there's a great amount of pressure to just make it magically work. However, as the number of CA's accepted in most browsers increases, the security of the system as a whole decreases dramatically. Yet the market for $1000/year SSL certs is rather low, and the guys that are charging bargain rates for low quality certs are perhaps doing one good thing (enabling encryption) while simultaneously doing another bad thing (destroying any "quality" in the system). SSL is going to have these problems as long as we maintain the current model. In the long run, I expect all the CA's to behave something like this - especially the ones that have more to lose if they were to become suddenly "untrustworthy." ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.

On Mon, 12 Sep 2011 04:39:52 -0000, Marcus Reid said:

You don't have to have the big fat Mozilla root cert bundle on your machines. Some OSes "ship" with an empty /etc/ssl, nobody tells you who you trust.

And for those OS's (who are they, anyhow) that ship empty bundles, how many CAs do you end up trusting anyhow?

How about a TXT record with the CN string of the CA cert subject in it? If it exists and there's a conflict, don't trust it. Seems simple enough to implement without too much collateral damage.

Needs to be a DNSSEC-validated TXT record, or you've opened yourself up to attacks via DNS poisoning (either insert a malicious TXT that matches your malicious certificate, or insert a malicious TXT that intentionally *doesn't* match the vicitm's certificate)....

Subject: Re: Microsoft deems all DigiNotar certificates untrustworthy, releases Date: Mon, Sep 12, 2011 at 11:46:04AM +0200 Quoting fredrik danerklint (fredan-nanog@fredan.se):

...

...

How about a TXT record with the CN string of the CA cert subject in it? If it exists and there's a conflict, don't trust it. Seems simple enough to implement without too much collateral damage.

Needs to be a DNSSEC-validated TXT record, or you've opened yourself up to attacks via DNS poisoning (either insert a malicious TXT that matches your malicious certificate, or insert a malicious TXT that intentionally *doesn't* match the vicitm's certificate)....

And how do you validate the dnssec to make sure that noone has tampered with it.

Since you are from Sweden, and in an IT job, you probably have personal relations to someone who has personal relations to one of the swedes or other nationalities that were present at the key ceremonies for the root. Once you've established that the signatures on the root KSK are good (which -- because of the above -- should be doable OOB quite easily for you) you can start validating the entire chain of trust. Quite trivial, in fact. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Am I in GRADUATE SCHOOL yet?

...

...

...

How about a TXT record with the CN string of the CA cert subject in it? If it exists and there's a conflict, don't trust it. Seems simple enough to implement without too much collateral damage.

Needs to be a DNSSEC-validated TXT record, or you've opened yourself up to attacks via DNS poisoning (either insert a malicious TXT that matches your malicious certificate, or insert a malicious TXT that intentionally *doesn't* match the vicitm's certificate)....

And how do you validate the dnssec to make sure that noone has tampered with it.

Since you are from Sweden, and in an IT job, you probably have personal relations to someone who has personal relations to one of the swedes or other nationalities that were present at the key ceremonies for the root. Once you've established that the signatures on the root KSK are good (which -- because of the above -- should be doable OOB quite easily for you) you can start validating the entire chain of trust.

Quite trivial, in fact.

and how about a end user, who doesn't understand a computer at all, to be able verify the signatures, correctly? -- //fredan

fredrik danerklint <fredan-nanog@fredan.se> wrote:

and how about a end user, who doesn't understand a computer at all, to be able verify the signatures, correctly?

The current trust model for DNSSEC relies on the vendor of the validator to bootstrap trust in the root key. This is partly a matter of pragmatism since the validator is a black-box agent acting on the user's behalf, like any other software. It is also required by the root key management policies, since a root key rollover takes a small number of weeks, much shorter than the not-in-service shelf life of validating software and hardware. This means that a validator cannot simply use the root key as a trust anchor and expect to work: it needs some extra infrastructure supported by the vendor to authenticate the root key if there happens to have been a rollover between finalizing the software and deploying it. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Biscay, FitzRoy: Southwesterly 4 or 5, veering northerly or northwesterly 5 or 6, occasionally 7 later in southeast Fitzroy. Rough or very rough. Rain or showers. Good, occasionally poor.

*a random php programmer shows* He, I just want to self-sign my CERT's and remove the ugly warning that browsers shows. I don't want to pay 1000$ a year, or 1$ a year for that. I just don't want to use cleartext for internet data transfer. HTTP is like telnet, and HTTPS is like ssh. But with ssh is just can connect, with browsers theres this ugly warning and "fuck you, self-signed certificate" from the browsers. Please make the pain stop!. --Tei -- -- ℱin del ℳensaje.

On Tue, Sep 13, 2011 at 09:45:39AM -0500, Chris Adams wrote:

Once upon a time, Tei <oscar.vives@gmail.com> said:

...

He, I just want to self-sign my CERT's and remove the ugly warning that browsers shows.

SSL without some verification of the far end is useless, as a man-in-the-middle attack can create self-signed certs just as easily.

It protects against attacks where the attacker merely monitors the traffic between the two endpoints. As you suggest, it does not protect against MITM, but that's different from being useless. The value of protecting against the former but not the latter may vary by situation, but it's not always zero. Not all attackers/attacks that can sniff also have the capability and willingness to MITM. (And even SSL w/ endpoint verification isn't absolute security. For example, it doesn't protect against endpoint compromises. But that doesn't make it endpoint verification useless.) -- Brett

Really? You can "just connect" with SSH? root@somebox:~# ssh 1.2.3.4 The authenticity of host '1.2.3.4 (1.2.3.4)' can't be established. RSA key fingerprint is 03:26:2c:b2:cd:fd:05:fc:87:70:4b:06:58:40:e7:c3. Are you sure you want to continue connecting (yes/no)? That's no different that having to permanently accept a self-signed SSL cert... - Pete On 9/13/2011 10:29 AM, Tei wrote:

*a random php programmer shows*

He, I just want to self-sign my CERT's and remove the ugly warning that browsers shows. I don't want to pay 1000$ a year, or 1$ a year for that. I just don't want to use cleartext for internet data transfer. HTTP is like telnet, and HTTPS is like ssh. But with ssh is just can connect, with browsers theres this ugly warning and "fuck you, self-signed certificate" from the browsers. Please make the pain stop!.

--Tei

On Tue, 13 Sep 2011 16:29:30 +0200, Tei said:

He, I just want to self-sign my CERT's and remove the ugly warning that browsers shows. I don't want to pay 1000$ a year, or 1$ a year for that. I

The warning is there for a *reason* - namely that if you have a self-signed cert, a first time visitor has *zero* way to verify it's *your* self-signed cert and not some hijacker's self-signed cert.

just don't want to use cleartext for internet data transfer. HTTP is like telnet, and HTTPS is like ssh. But with ssh is just can connect, with browsers theres this ugly warning and "fuck you, self-signed certificate" from the browsers. Please make the pain stop!.

If you use SSH to connect, and either ignore the "host key has changed" or "authenticity can't be established, continue connecting?" messages, you get what you deserve - those are the *exact* same issues that your browser warns about self-signed certs. And if you *don't* ignore them on SSH - why do you want to ignore them on SSL? Note that there's another big difference between SSH and SSL - the number of people who are allowed to SSH to a given machine is (a) usually small and (b) pre-identified up front. So if Fred gets an "unknown host key" while SSH'ing to the server you just set up, that's probably not a big issue because you presumably know who Fred is and just created an account for him, so you can supply him with the footprint of the SSH host key to double-verify. That does *not* scale to Internet-facing web services. Of course, if you have a *private* *internal* webserver with limited users, you're free to use a self-signed cert and use your browser's handy "Add security exemption" dialog and check "Permanent".

The problem that I see with browser response to self-signed (or org generated) certs is not the warning(s) but the assertion that the cert is invalid. Not issued by one of the players in the Protection Racket does not make the cert invalid. It may be untrustable, unreliable, from an unknown and/or unverifiable source, but it IS a valid cert. Certs in a revocation list or malformed certs are invalid. After all, the Diginotar certs were 'valid', until revoked. Apparently the (arbitrary) inclusion or exclusion of a root cert by each browser creator or distributer is equated with validity. By removing the Diginotar root cert, suddenly ALL Diginotar certs are now reported to end users as Invalid? By refusing to include a CACert root certificate, no CACert certificate is 'valid'? I think not. -- -=[L]=- Hand typed on my Remington portable

On Wed, 2011-09-14 at 19:16 +0200, Jeroen Massar wrote:

And to end this thread as this effectively ends Diginotar troubles for the Interwebz:

Dutch official statement: http://www.opta.nl/nl/actueel/alle-publicaties/publicatie/?id=3469

Bedankt. Vertaling (my own translation, niet slecht voor een buitenlander) .... OPTA regulates the Dutch communications market including consumer protection. OPTA has now ended the registration of Diginotar as a supplier of authorised certificates for electronic signatures. An investigation by OPTA revealed the trustworthiness of approved certificates from Diginotar can no longer be guaranteed. This means the business of issuing authorised certificates must stop and no new authorised certificates must be issued. -- With best regards, Paul. England, EU.

On Tue, Sep 13, 2011 at 11:22 AM, Michiel Klaver <michiel@klaver.it> wrote:

At 22-07-28164 20:59, Tei wrote:

...

*a random php programmer shows*

He, I just want to self-sign my CERT's and remove the ugly warning that browsers shows. I don't want to pay 1000$ a year, or 1$ a year for that. I just don't want to use cleartext for internet data transfer.  HTTP is like telnet, and HTTPS is like ssh. But with ssh is just can connect, with browsers theres this ugly warning and "fuck you, self-signed certificate" from the browsers.  Please make the pain stop!.

--Tei

No need for (financial) pain, there are free of charge ssl certificates available, see for example:

http://www.startssl.com/?app=1

eddy stopped issuing

http://www.cacert.org/

these I hadn't seen... or I had and promptly forgotten about them since they don't get included in any browser/app/OS :( Affirmtrust is supposed to start issuing certs 'soon' though, free. -chris

On Tue, Sep 13, 2011 at 11:33 PM, Jima <nanog@jima.tk> wrote:

On 2011-09-13 20:26, Christopher Morrow wrote:

...

On Tue, Sep 13, 2011 at 11:22 AM, Michiel Klaver<michiel@klaver.it>  wrote:

...

No need for (financial) pain, there are free of charge ssl certificates available, see for example:

http://www.startssl.com/?app=1

eddy stopped issuing

 Huh?  I'm a bit lost here, since I had two StartSSL certs issued yesterday afternoon.

orly? wierd, they made a press release ~last-june (I think?) stating they were stopping issuance indefinitely. I do hope they are actually issuing again :) I like my random numbers to be free. -chris

On 14/09/11 13:44, Christopher Morrow wrote:

On Tue, Sep 13, 2011 at 11:33 PM, Jima <nanog@jima.tk> wrote:

...

Huh? I'm a bit lost here, since I had two StartSSL certs issued yesterday afternoon.

orly? wierd, they made a press release ~last-june (I think?) stating they were stopping issuance indefinitely. I do hope they are actually issuing again :)

I like my random numbers to be free.

As claimed by the DigiNotar hacker - He compromised their servers but Eddy was manually approving certs at the time and so no certs were signed. There was information about it on the site, but it seems to be gone now. Articles still show a screenshot of the message you're talking about [1] , but the site was back alive in July when I needed a certificate. "A separate notice on another part of the company's site says that its services would be unavailable until June 20, " [2] I've certainly been able to issue certificates for myself since then. [1] http://news.netcraft.com/archives/2011/06/22/startssl-suspends-services-afte... [2] http://threatpost.com/en_us/blogs/ca-startssl-compromised-says-certificates-...

...

I think that it's hard to cope with SSL. It doesn't do the right things for the right reasons. Many of us, for example, operate local root CA's for signing of "internal" stuff; all our company gear trusts our local root CA and lots of stuff has certs issued by it. In an ideal world, this would mean that our gear talking to our gear is always secure, but with other root CA's able to offer certs for our CN's, that isn't really true. That's frustrating.

You don't have to have the big fat Mozilla root cert bundle on your machines. Some OSes "ship" with an empty /etc/ssl, nobody tells you who you trust.

You don't have to have a web browser on your machines, either. Also solves the problem FSVO "solves." Users don't really want to figure out SSL, and we shouldn't *want* them to have to figure out SSL. When your grandfolks (or parents or whatever) connect up to the Internet with a PC, they just sort of expect that things will work. We should have found a way to make that happen - instead we gave them SSL. :-)

...

The reality is that - for the average user - SSL doesn't work well unless about 99% of the CA's used by the general public are included as "trusted." If a popular site like Blooble has a cert by DigiNotar and the Firerox browser is constantly asking what to do, nothing really good comes out of that ... either people think Firerox blows, or they learn to click on the "ignore this" (or worse the "always trust this") button. In about 0.0% of the cases do they actually understand the underlying trust issues. So there's a great amount of pressure to just make it magically work.

How about a TXT record with the CN string of the CA cert subject in it? If it exists and there's a conflict, don't trust it. Seems simple enough to implement without too much collateral damage.

I don't know. It may have some potential.

...

However, as the number of CA's accepted in most browsers increases, the security of the system as a whole decreases dramatically. Yet the market for $1000/year SSL certs is rather low, and the guys that are charging bargain rates for low quality certs are perhaps doing one good thing (enabling encryption) while simultaneously doing another bad thing (destroying any "quality" in the system). SSL is going to have these problems as long as we maintain the current model.

I like the added "chrome" that the new browsers have for EV certs, but users need to be stabbed in the face, green vs. blue doesn't really do it.

Perhaps what we need is to stab some Internet folks in the face too, though, for allowing the perpetuation of Much Badness(tm). We might really be better off, for example, if we could get a ".bank" TLD that was operated in a rational manner, where only the bank's proper name was registered, all websites had to run as subdomains, and SSL certs for .bank could only be issued by ... well maybe even just one CA, or at most two or three. I mean, there's still so much wrong with that model too, but it has some more-correct things built into it.

...

In the long run, I expect all the CA's to behave something like this - especially the ones that have more to lose if they were to become suddenly "untrustworthy."

Yes, how do you think Verisign/Thawte/Symantec would behave if they found that their keys were compromised? They might do the right thing, because they're not stupid enough to think they could get away with trying to cover it up.

Wow, you're ... pleasantly naive? (not meant as an insult AT ALL!) Or maybe I'm just hopelessly cynical. But I do see that as naive; I expect that at a minimum the spin machine would be running at full tilt and it would be downplayed as much as possible.

What would the browser vendors do in that case?

Interesting question.

I hope there's a contingency plan, and if there is it seems like it should be made public.

Okay. :-) ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.

On Sun, 11 Sep 2011 10:19:39 PDT, Joel jaeggli said:

To pop up the stack a bit it's the fact that an organization willing to behave in that fashion was in my list of CA certs in the first place. Yes they're blackballed now, better late than never I suppose. What does that say about the potential for other CAs to behave in such a fashion?

I'm sure at least one of the other 250-odd certificates from 100-ish CA's trusted by most browsers now are actually trustworthy. There is no evidence at all that the average CA is any less trustworthy than the average DNS registrar. However, this isn't as big a problem as one might think - the *only* thing that an SSL sert gives you is "you reached the host your browser tried to reach". It does *not* validate "the host you intended to reach", or "whether you should trust this host with your data", or any of a long set of interesting security issues. And that one question - "did you reach the host your browser tried to reach" doesn't really mean much unless you have DNS and routing security in place as well. After all, if the IP you get for www.my-bank.com is incorrect, or the route has been hijacked, what the cert says is pretty meaningless. Considering that we seem to muddle along just fine with a DNS that doesn't really do DNSSEC yet(*), and a lot of black and grey hat registrars out there, and no real BGP security either, maybe it isn't the "sky is falling" scenario that a lot of people want to make it. Or maybe we should all be even more worried. ;) (*) Has anybody actually enabled "only accept DNSSEC-signed A records" on an end user system and left it enabled for more than a day before giving up in disgust? ;)

On Sun, Sep 11, 2011 at 1:30 AM, Damian Menscher <damian@google.com> wrote:

On Fri, Sep 9, 2011 at 11:33 PM, Jimmy Hess <mysidia@gmail.com> wrote: Because of that lost trust, any cross-signed cert would likely be revoked by the browsers.  It would also make the browser vendors question whether the

I am not engaging in speculation that DigiNotar plans to continue to operate, they have already stated so much. http://www.vasco.com/company/press_room/news_archive/2011/news_diginotar_rep... "VASCO does not expect that the DigiNotar security incident will have a significant impact on the company’s future revenue or business plans." So long as DigiNotar can show what they are required to show when they would request re-signing, and another CA can legitimately cross-sign their cert, following that CA's official correct certification practices; it's unlikely to lead to the signer being revoked. As far as we know, DigiNotar is not dead, it is just a really great example showing how broken TLS security model is. The trust model hard-coded into the protocol is much weaker than the cryptography. Since the browsers already approved that root CA's certification practices. Particularly not if the cross-signer is one of the larger CAs such as Thawte or Verisign --- the browser might as well remove SSL support altogether, if they will perform a revokation that renders 40% of internet web server SSL certs invalid. -- -JH

somewhat rhetorically... On Sun, Sep 11, 2011 at 2:30 AM, Damian Menscher <damian@google.com> wrote:

Because of that lost trust, any cross-signed cert would likely be revoked by the browsers.  It would also make the browser vendors question whether the signing CA is worthy of their trust.

given a list of ca's and certs to invalidate ... how large a list would be practical in a browser? (baked in I mean) (not very, relative to the size of the domain system today) Is this scalable? (no) Is this the only answer we have left? (no) -chris (I'm not sure what better answers there are to the situation we are in today, I do like the work in DANE-WG though... it'll be a while before it's practical to use though, I fear)