On Thu, Jun 2, 2011 at 12:07 PM, Marsh Ray
<marsh <at> extendedsubset.com> wrote:
On 06/02/2011 08:45 AM, Phillip Hallam-Baker wrote:
At the end of the day buffer over-run exploits will still trump any
deficiencies in the CA infrastructure. But those don't have people
running round suggesting urgent remedies because they are too common to
bear notice. CAs and RAs are definitely not the weakest link in the
chain here. Anyone claiming that is either grandstanding or has failed
to pay attention.
Not everything that uses TLS or certificates is an unpatched web browser with Adobe plugins operated by an ignorant user for the purpose of securing nothing particularly important.
I hear you.
But lets be realistic here, we are currently actually doing worse for non browser security.
The weakest link in the TLS protocol is actually the end user who is for some bizarre reason expected to be looking for padlock icons and green bars and know when to look for which one.
This is even more problematic when applying TLS to Web services as there isn't even a user to make the decision and no real idea of what should do that instead.
CAA is not going to solve every problem associated with trust on the Internet and CA infrastructure. Nor is TLS and nor is strict security. But I do think that a combination of those three ideas can make a major step forward.
That is why CAA is designed to be arbitrarily extensible with a tag-value format even though there are only two property tags currently defined. I really like the work that Paypal and Jeff Hodges have been doing and would like to have a way to eventually bring CAA into alignment there.
But for the moment we have to avoid 'crossing the streams' as Stephen F. put it to me.
Lets work on the part of the problem that we can while the Web Security folk work on understanding the complexities of what strict security involves.
Perhaps a solution is to implement your own application-specific trust root that doesn't rely on the current profusion of CAs. But as an application developer I can attest to the fact that it's difficult to use standard platform TLS libraries without also trusting everything in the system root store, too. Some sites will insist on using their own in-house CAs too, which is fine, but it's further pressure on everything else to integrate/be vulnerable with the browser trust model.
Yes and that may well end up motivating a mechanism to allow for protocol specific path properties so that enterprises can have separate CAs authorized for separate protocols.
Web Services security is a big part of what I am interested in supporting here. We went into the Web Services world with certain interests promoting UDDI as the central directory to make it all work. So now we have a protocol stack predicated on the existence of a directory with no directory to work with.
I have some ideas there, but again, that would be crossing the streams at this point. I think the way to get traction there will be to propose a Web Service application with some pretty severe security requirements and make that the test application for a framework designed to 'do it right'.
RSS Feed