[Really this is to the list, not so much Jon specifically]
On 12/07/2011 02:10 PM, Jon Callas wrote:
Let's figure out what we're trying to accomplish; after that, we
can try to figure out how to do it.
I think that's the central problem we're dealing with. There is scads
of mechanism and little policy.
I also don't think we're going to agree on what policy should be,
except within limited contexts.
We've discussed CAs, PKI, liability, policy, etc.
But conspicuously absent in this discussion has been the Relying Party
(i.e., the end user) and their software vendor.
As weird as this sounds, the RP is the party with the ultimate control.
With the notable exception of DRM, it is the end user and the software
they selected to operate on their behalf who takes the bits from various
sources, drops them into this Rube Goldberg contraption, turns the
crank, and receives a slip of paper as output. At that point, it is up
to the user (in coordination with their software vendor) to behave
differently according to their interpretation of the result.
So I would like to differ a little bit with this statement:
On 12/07/2011 01:34 PM, ianG wrote:
Revocation's purpose is one and only one thing: to backstop the
liability to the CA.
Maybe that's how it's design was originally motivated, but a facility
like revocation *is* precisely what users and their software vendors
make of it.
For example:
* There are operating systems that can and do apply regular updates on
root CAs and CRLs as part of their recommended regular patch channel.
* Microsoft implemented effectively CA pinning for certain Windows code
updates quite some time ago.
* A clueful Gmail user detected the otherwise-valid Iranian MitM cert
because Google implemented effectively CA pinning in Chrome, at least
for its own sites.
* Walled-garden app stores and DRM. Sure we all hate it and it's a
largely different threat model, but it's an example of something.
These examples have one thing in common: it is possible that something
can be widely deployed that's more effectively secure than we have now.
Yes, there will be difficulties. No, it will never be perfect. But boy
is there ever an opportunity for improvement.
It may upset some apple carts however, in particular one of my
favorites. It's called: "Wow PKI is really busted, let's make popcorn
and watch the slow motion train wreck play out on the tubes".
But I find this especially ridiculous because I know for a fact that
there are people on this list who working for and directly advising
every part of PKI: the big browsers, other client software vendors,
secure websites, CAs, cypherpunks, academic cryptographers, end users,
you name it!
Moxie gets this, his convergence proposal talk has > 33K views on
YouTube and he just sold his company to Twitter. What's up with that, hmm?
Google gets this, they have multiple proposals and implementation
projects going on for enhancements in this area. And they'll
nonchalantly deploy something into Chrome in some future unnumbered
update, Mozilla will follow soon after, and then the spec will be
submitted to IETF for copy editing.
CAs we will have with us always, but the current semantics of PKI
validation (trusted roots and spotty revocation checking) are on their
way out the door. Some products will rise, some will fall, some vendors
will feel some pressure, and yes even some users will get educated about
security in the process.
So, will you be making a contribution to the solution?
- Marsh
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
