Kyle Hamilton wrote:
Because you're assuming that everything that occurs in this world
exists in a corporate environment, Eddy. That is the environment
where CAs flourish, where CAs thrive, where CAs can do what they're
best at -- *because all authority and trust trickles down from the
corporation, a tool used to help its workers which are acting on its
behalf*.
Kyle, if that were true, the PC wouldn't have defeated IBM and we'd
still be using proprietary networks like Minitel :) The reason
computing is as it is today is because of the success of peer
arrangements sans intermediation. Corporations benefit as much from
peer-to-peer as anyone else. The entire dotcom boom was about that
benefit... leading on to the current financial crisis, another elegant
proof that authority & trust in corporations does not trickle down ;)
... This is why X.509
doesn't allow a user to limit the policies that they're willing to
accept in certificate path validation. (To be fair, some minimal nod
toward this was put into the PKIX profiles, but realistically there's
no implementation. In PKIX, an end-user simply does not have a
certifying key, period. This means that literally everything that the
end-user wishes to do must start with a "CA, may I <blank>?" question,
just to get an assignation of authority -- a certificate, linking a
key that the user holds to that which the user wishes to do.
This part is deeply interesting. PKI was supposed to be about extending
meaning into contracts and certs, but that failed. That failure is
probably understandable (to me at least).
The part that is less easy to understand is "what is the meaning that
was left over when we stopped trying to put meanings in?" This question
is at the root of many symptomatic ills, such as the whole
EV-versus-non-EV thing, and the failure of S/MIME.
Once we isolate, align and fix these meanings, it should be possible to
unlock the potential in the code. This is a future challenge.
At this point, I don't know of any PKIX client that actually supports
policy evaluation. I'm pretty sure that NSS doesn't, and I'm also
pretty sure that OpenSSL doesn't (I can't speak for other open-source
projects) -- as well as being pretty sure that none of the
closed-source clients I'm aware of support it either.
"Policy evaluation" would probably reduce to "contracts in digital
form." The places where this has been looked at are things like my
Ricardian Contracts, Nick Szabo's smart contracts, and the like. There
is a link of related stuff here:
http://www.webfunds.org/guide/ricardian.html#alternates
Short summary: contracts are difficult to do in digital form!
This is where
focus needs to be placed, a means of identifying what policies are
being used to issue each certificate, as well as a means of policy
mapping
My view would be slightly different, although we may be looking at the
opposite sides of the same coin: We need to figure out what these
current practices are, as a starting point. Right now they are not
clear, as the practices are a combination of various claims spread
across various documents and various people at various times.
(I.e., they are not policies, just practices.)
E.g., although there is a practice of "all CAs are equal" there is no
real documentation that says that, nor examines just how equal they are
and what steps are taken to equalise the CAs. E.g., 2., there is no
clear description of what a signature in S/MIME means, a situation that
comes close all by itself to breaking S/MIME (any lawyer will tell you
not to sign something unless you intend to be bound by it ...).
(NSS could do this by creating a "web policy", an "email
policy", and a "software policy", then issuing a cross-certificate to
each of its included CAs that maps the individual policy OIDs to the
'master' web/email/software OIDs -- but nobody wants Mozilla to run a
CA, sigh).
Yes, there are fierce pressures on Mozilla to do the work of the CAs.
This is not the CAs fault, nor Mozilla's fault. But the forces still exist.
Question is, what to do about it?
iang
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
