Until such time as ISP's are able to uniquely identify WHO did it and not just "well this guy owns the house where the service is terminated", prosecutors and plaintiffs should not be able to meet their burden of proof on such offences.

There. FYP.

Obligatory IANAL

Now, hmmm. Consider 2 situations:

Situation A
- Bad guy cracks your WPA / WEP key and uses your network to download copyrighted material.
- You are sued (civil case), and the burden of proof required is preponderence of the evidence / balance of probabilities.
- You live in a densely populated area where there are a large number of computer-unsophisticated users who regularly use somebody else's network because they left it open
- It is introduced into evidence that you secured your network to try to ensure that only you could use your network
- The only question of fact at trial is the identity of the infringer - your defense is that somebody else may have used your network to commit the act in question

Situation B
- Bad guy uses your open wireless network to download copyrighted material.
- You are sued (civil case), and the burden of proof required is preponderence of the evidence / balance of probabilities.
- You live in a densely populated area where there are a large number of computer-unsophisticated users who regularly use your network because you left it open
- The only question of fact at trial is the identity of the infringer - your defense is that somebody else may have used your network to commit the act in question

Do you feel that it is more likely that your defense (somebody else did it) is correct under Situation A or Situation B?
In a civil case, where allegations do not have to be proven beyond reasonable doubt, how do you feel this impacts a balance of probabilities test?

"Securing" your network could put you in a worse situation. DUCY?

Sir, your youth is showing ;-)

"Standalone" (ie single function) Cheque Guarantee Cards were common back in the 1980's.

--
They're from Mars. You do the English.

Our entire front end is ExtJS. This means MUCH EASIER porting a whole web app based (SIGH) on Grails to something less craptastic like Rails, Django, or anything else that is good at emitting JSON. It's not as easy to get started with... because you're starting with high-level widgets like controls, panels, and similar.

Yes. Because the Internet has reduced the friction of communication to the point where it is impossible to make a profit selling snake oil.

ummm... Okay... Only that's not what the story was talking about. The story was talking about a user using a different resolver from comcast, rather than their resolver. This has nothing to do with running a dns server. There are a number of reasons to want to use another resolver, including:

• Security - Switching resolvers to OpenDNS was one of the suggested protection methods for Kaminsky's DNS flaw.
• Avoid NXDOMAIN hijacking / forgery - All the net is not the web, and NXDOMAIN hijacking breaks everything except the web (and sometimes even breaks the web too).
• Avoid outages - Outages that are caused by the provider's inability to achieve a simple task - keeping their caching name-servers up, while connectivity is still there, shouldn't cause an outage of your net access
• Alternative DNS roots

Sorry... what does using a different resolver have to do with malware? Yeah. I thought so.

The reasons I've heard advanced most frequently to encourage the use of the ISP's caching nameserver are:

• Bandwidth - Though this will not impose a significant increase in bandwidth on the ISP, it can impose a somewhat larger load on the roots and TLDs. Though with the larger caching nameservers like OpenDNS this should not appreciably increase load
• Ad revenue - See above on NXDOMAIN hijacking / forgery. This is an inappropriate business practice that breaks everything except web and often breaks the web too

This detracts from their profitability only one one of their lines of business - the one where you are the product.

This comment looks sensible on the face of it, but I have to disagree with you. I have a pilot license and am familiar with the process of flying. I've never flown a fly-by-wire aircraft, but I've automated a radio broadcast desk - which might not look like it's relevant, but it taught me that "knowing when to trust the computer" is not an obvious state, not in a radio station and I seriously doubt in a cockpit.

For me the final "aha moment" came when the computer was attempting to tell me something useful, but because I was concentrating on a completely different aspect of interacting with it, I completely missed the information. In my case it caused a few seconds of dead air on a radio station, nothing life threatening, but not human obvious either.

The challenge is not "when to trust a computer and when not to" - the challenge is "how do you get the information that the computer is using to the human in such a way that they can manage that input stream in a timely fashion. Stick shakers are an example of making use of an extra input channel.

Accidents in planes are rarely just one thing going wrong, they generally are a whole string of things. A computer in the mix just exacerbates the issue.

I see. You are under the illusion that an SSL cert (ought to) assert(s) meatspace identity (or identity other than "one who controls domain xxx.com." Perhaps that identity assertions other than those contained in cn or altSubjectName ought to have some meaning. Kinda what EV intends to do... for corp's.

You are mixing / begging the question on a few concepts here, including:
- granularity of identification
- strength of identification verification
- reputation

Perhaps if these concepts were dealt with in an orderly, separate manner, the question of trust would be more easy to quantify and address.

Trust but verify. They publish a statement with respect to the policies and procedures that they follow. They are audited to ensure they follow those policies and procedures. It is up to us (and the browser makers [?]) to ensure that those policies are sufficient for our purposes.

Please name such a CA which "happily hand over valid certs to anyone with a credit card" and does not "take reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate or has been authorized by the domain registrant to act on the registrant's behalf" and which is trusted by the major browsers.

And then, perhaps, explain why you feel this is in _any_ way relevant to a discussion on DNSSEC.

Though, I suppose, this is Slashdot. Why post based on relevant facts rather than baseless, off-topic innuendo?

Umm... Perhaps, but probably not in quite the way you suggest. The current implementation doesn't allow the user to distinguish between certs issued by CAs with smart, rigorous CPS's (you do know what that is right), and certs issued by CAs that only check e-mail to admin@ postmaster@,...

Yeah. Which is why the major browsers require that the CAs be audited (and if they delegate to resellers the resellers too) to verify that they actually comply with what they say they'll do (their CPS), and that their CPS meets a minimal set of standards.

It seems your argument really boils down to: there has been a race to the bottom on the documented signing policies in order to minimize costs because higher cost, more rigorous validation mechanisms can't be used to differentiate a cert in the marketplace. (Except EV, but that's a whole other story)

And they can't do anything to stop the best from handing a phisher a cert. However, the browser producers require an audit (which serves as a detective and preventive control) to verify that appropriate and sufficient processes are in place to ensure that a) the CPS is followed and b) the CPS meets a (minimal) set of rules.

Now, all this means that when (as a user) you're presented with a cert [that is not EV], you can be strongly assured that at some point, that cert was issued to someone who could read and respond to mail at an administrative email account for that domain. Is this sufficient for the user? Maybe. If it's a forum site, or a blog site, then probably. If it's an eCommerce or online banking site, probably not.

The browser makers need to allow:
a) Certs with differing validation methods to be differentiated (on a finer granularity than EV / not EV)
b) Client-side policy to be implemented on the basis of that differentiation

In order to arrest this race for the bottom and competition solely on price by the CAs.

Incidentally, both of these can be achieved within the current CA infrastructure...

"Unless your going to pay the auditors to run a compliance check after every change you make"

Not relevant to the case at hand, but:

1.1.1 A formal process for approving and testing all network connections and changes to the firewall and router configurations ...

6.3.1 Testing of all security patches, and system and software configuration changes before deployment, including but not limited to the following:
6.3.1.1 Validation of all input (to prevent cross-site scripting, injection flaws, malicious file execution, etc.)
6.3.1.2 Validation of proper error handling
6.3.1.3 Validation of secure cryptographic storage
6.3.1.4 Validation of secure communications
6.3.1.5 Validation of proper rolebased access control (RBAC) ...
6.4 Follow change control
procedures for all changes to system
components. The procedures must
include the following:
6.4.1 Documentation of impact
6.4.2 Management sign-off by appropriate parties
6.4.3 Testing of operational functionality
6.4.4 Back-out procedures ...
6.6 For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods:
- Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes
- Installing a web-application firewall in front of public-facing web applications ...
11.2 Run internal and external network vulnerability scans at least quarterly and after any significant change in the network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades).
Note: Quarterly external vulnerability scans must be performed by an Approved Scanning Vendor (ASV) qualified by Payment Card Industry Security Standards Council (PCI SSC). Scans conducted after network changes may be performed by the companyâ(TM)s internal staff.
11.3 Perform external and internal penetration testing at least once a year and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a subnetwork added to the environment, or a web server added to the environment). These penetration tests must include the
following:
11.3.1 Network-layer penetration tests
11.3.2 Application-layer penetration tests

"If the banks [sic] implementation followed PCI-DSS and the auditor did its job with a generally accepted level of precision"

It did not and they did not. Unencrypted storage of PANs, for which a previous audit had failed.

And they failed to do that.

They knew the processor had previously failed an audit because of storage of unencrypted PANs and non-compliant firewalls.

They provided an audit report that said "fully compliant" with CISP.

In the aftermath of the breach, it was discovered that the processor still had non-compliant firewalls and was still storing unencrypted PANs.

It appears that Savvis did not do their job. This will not be the big question at the trial, though.

Merrick was not in contractual privity with Savvis. Savvis was contracted by CardSystems, not Merrick. The issue at trial will likely be whether Savvis owed a duty of care to others that relied on their report (rather than just their client).

I would suggest that if an audit scheme is to have any benefit at all, it must accrue to those that rely on the audit findings. If 3rd parties cannot rely on the audit findings, then there is no reason to conduct the audit in the first place.