Frank Hecker wrote:
Nelson B wrote:
Well, hoorah! as the marines say. That's a very
big admission by you - that WebTrust by itself may
not suffice.
I've been saying that since draft 10 or 11 came out. It's in several
of my posts.
Ian, Nelson is exactly right here, he did bring up the concern about
WebTrust audits simply auditing compliance to CA policies (e.g., as
outlined in the CP, CPS, etc.), and not necessarily evaluating those
policies as being good or bad in terms of security. I think that
particular concern is perfectly valid, and that's exactly why I added
more policy requirements to draft 11.
OK, I stand corrected!
...
"6. We require that all CAs whose certificates are distributed with our
software products:
...
* not issue certificates without the knowledge of the parties whose
identities, domain names, and/or email addresses are referenced
in the certificate
..."
If you wanted to cover this, perhaps creating a
FAQ with a question in there from a concerned
CA:
"Under what circumstances might MoFo reject
or remove our CA root key from the list?
* where it came to our attention that certs
were issued without the identified parties
explicitly and directly authorising it
* ...
I feel it is so egregious that it doesn't need
to be part of the policy, but that's not a strong
preference.
(However note this could lead to ambiguity if the info in the cert could
apply to multiple entities, i.e., the "John Smith" problem. Maybe that
wouldn't be a problem in practice, I don't know.)
Like the judge said, "I can't define it, but I
know it when I see it."
The contractual arrangement doesn't say the user has no right to keep
anything private. It merely says that the other party has the right
to do what it can to intercept. A mozilla user with a reasonable
root CA list is still protected.
Uh, what if the SSL MITM's installation procedure simply overwrites
libnssckbi.dll (and the CA cert list embedded in it) with a new version?
Wouldn't an SSL MITM implementor think of that?
I guess this leads down to the path of "you must
install our browser" eventually. Which is what
AOL used to do, I don't know if they still do
(and I have no clue if they were MITMing their
customers as the hypothetical case proposes).
I think Mozilla may need to be quite firm in this
case, because if it allows ISPs to trick users
into fiddling with the browser internals, then
support and confidence could suffer. But putting
it in the policy just seems to invite workarounds,
it's better off done in council as a "determination."
Nice problem. It would be fun to be in the hotseat
if it was ever discovered, I love playing with
fireworks.
iang
--
News and views on what matters in finance+crypto:
http://financialcryptography.com/
_______________________________________________
mozilla-crypto mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-crypto
