Nelson Bolyard wrote: > Ian G wrote, On 2008-09-24 05:12: >> Nelson B Bolyard wrote: >>> Ian G wrote: >>>> Nelson B Bolyard wrote: >>>> The curiosity here is that the Certificate Policies extension may >>>> not be shown prominently by software. As the point of the cert is >>>> to make some claim to the user, and the essence of that claim is >>>> somehow pertinent to the user's choice, it is understandable that >>>> issuers have been frustrated in the past by lack of display of the >>>> nature of the claim.... >>> For PKI to work with ordinary mom-N-pop users, there must be a small >>> set of claims common to all CAs honored by a browser. >> Um. Can you point to that small set of claims? > > I think that, presently, there are essentially 3 different sets of claims > commonly used for SSL servers, and another small number of sets of claims > commonly used for S/MIME certs. > > The 3 sets of claims used for SSL servers have names "DV", "OV" and "EV". > Of those, EV is well defined and documented. DV is pretty well understood > but I don't know of any document that defines it very well.
Ah, thanks Nelson.
That's not a pretty sight! I see three things going on here.
Caveat, this is just my view, others may have other views.
1. This decision to suppress the CA's claims has a lot of
ramifications:
* liabilities are passed from the CA to the browser.
* there is little point in imposing strong independent audit
requirements over the CA, because what matters is the "small set of
claims".
* The "policy" approach won't work to keep things on an even
keel, because of the conscious decision to override the protections
requested at policy level. Actions override words.
It may be then that if you are convinced you want this "one set of
claims" approach then the policy should be rewritten to reflect the
liabilities situation. This will help to reduce overall liabilities
to everyone.
2. the situation is made a lot worse by the absence of the
documentation on what these claims are. from a liabilities point of
view, the absence of doco means either they don't exist, or that the
set you get imposed in a dispute is not the set you expected.
So they should be documented. For the CAs this would be useful.
For Mozilla, to put it delicateley, this would more than useful!
3. The final issue is whether this works, whether it helps anyone,
or whether it just results in a race to the bottom. In the past, we
have seen that the desire to have "one set of claims" perhaps allied
with the "simple UI for users" pressures ... has meant that there is
a race to the bottom.
To address that, some thought to define it in EV. To the extent
that EV has set itself up in the same game -- passing the
responsibility around, and obscuring the liabilities, possibly
handing them back to Mozo -- it also will now feel the pressure to
race to the bottom. And then the game will start another round.
To the extent that EV has broken out of the liability trap, it could
work. (I don't know which it is.... We'd have to read it and
figure out what it does with these specific liabilities. Not my
job, for the moment :)
Then, one way forward is to step sideways and define OV as being
different to the "minimal set of claims" approach. Or another way
is to adopt the "small set of claims" through the DV direction.
I suppose then the question for the Mozilla risks team is:
a. does Mozilla ever entertain putting the CA's policies
(in any form) before the user?
Or, in the alternate,
b. is Mozilla always going to suppress
the CA's protections of the user and other parties?
If the former (a) then we could re-define OV that way (given that it
is currently greenfield and therefore means whatever we want it to
mean, perhaps with a change of title...). And then the liabilities
could be dealt with. To the extent that the brower can bring the
user and the CA together, then there are protections that the CA can
extend to the user.
If (b) we should rewrite the Mozo policy to reflect that by writing
the CA out of the user's equations, Mozo takes on the liabilities
for any protections that a CA might offer but are otherwise
unavailable. We should also reduce the audit requirements to be
primarily simpler and on the resultant DV document, because that is
what is being asked of the CA, not anything else. We should remove
contradictions because it really raises legal risks, and they simply
give nobody any benefit. Plus Mozo is first in the firing line
because the CA's hands are clean.
This would imply creating a sort of minimal DV/AV "set of claims"
and agreement and an audit to that set of claims, so a new
simplified mini-criteria.
What do people feel about this choice of a. versus b? Is there a c?
iang
Disclosure: I feel a lot of conflicts emerging here. As auditor
for CAcert, I am minded to the DRC, which pin the CA down to looking
after the user, and to a lesser extent, other parties. DRC is very
fierce on this, and this has presented a massive challenge to
CAcert. One it has surmounted, IMO.
Now, this is complicated immensely by the browser suppressing the
protections of the CA. I'm not sure I can in one simple email (!)
describe all the variations here...
Not to mention, this is the tech-dev list, not a risks management
list. Understanding liabilities and contracts is key to following
all this. If I was a tech, I wouldn't want to know, I'd just want
to know what the decision was. Sadly, those days may be gone for
me, but it seems fair to raise the red flag that we are talking
governance not tech.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dev-tech-crypto mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-crypto
