Kyle Hamilton wrote:
So, now for the actual changes I would like to suggest about the RC for the
CA Certificate Policy:
Section 4:
Add (first line of criteria):
- knowingly and intentionally issue certificates in ways or manners that are
not consistent with their CPS.
The trouble with this is that MoFo has to now make a judgment
on what is consistent with the CPS. Not wishing to get into
this can of worms, the notion that I preferred was that MoFo
said "for any reason whatsoever" and this covered it, then
it was up to the guy in the hot seat to do what he saw fit.
That is, my view is that no amount of words in the policy would
do much; on the day, it all depends on the circumstances. The
downside is that any words can also limit actions which will
carry costs.
This was of course only my view. In the end, a certain amount
of caveats were added, and they went forward as discussed. I
am not sure there is much point in adding more.
Section 5:
[We will consider adding certificates for additional CAs to the default
certificate set upon request] of either at least three users of the CA, or
the (one) entity responsible for the operation of the CA[.]
Note: [bracketed sections are wording that already exists]
Please explain that one further. You seem to be suggesting
that three users of a CA's certs could also independently
seek to request addition? Why? Why bother?
Section 6:
Modify: [publicly disclose information about their policies and business
practices (e.g., in a Certificate Policy and Certification Practice
Statement] which generally conforms to the structure of RFC2527 or its
successors[);]
Rationale: If the structure of a document is familiar, it's MUCH easier to
verify conformance to the criteria for CA operations specified in section 8.
Not needed. If the guy in the hot seat is not familiar,
it will take longer. No other feedback is needed.
Comment: 'stated purpose(s) of the certificates' needs to be defined.
Stated according to what standard? PKIX?
I think this was readily assumed to be the 3 well known
purposes. I don't think this needs to be nailed down.
Section 8:
These CA operation criteria are only acceptable if there's any kind of
financial underpinning. If there's financial underpinning, SSL domain
certificates are NOT acceptable, for the reasons I got into at the beginning
of this email.
I would state that the currently-stated criteria within the CP1RC to be 'CA
operations which operate within a financial/fiscal context'.
I would create another set of criteria for 'CA operations which operate in a
community/non-fiscal/non-financial context', with much lower entrance
requirements.
?!? What happens when a charity uses a free CACert
certificate to request credit card donations?
There is no way that MoFo can set itself up as the
net's fiscal policeman. This concept doesn't work;
Firefox is a browser, that's all. It simply cannot
know what a FORM is being used for.
However, for all CAs, I would add:
- The Certification Practice Statement structure generally conforms to
RFC2527 ("Internet X.509 Public Key Infrastructure Certificate Policy and
Certification Practices Framework") or its successors.
As an addition, if it helps, maybe. I think there are
so many ways to run CAs that it is best to be open here.
(see rationale in my comments for section 6)
Section 9:
Comment: Explicitly include WebTrust (http://www.webtrust.org) as an example
of an organization which explicitly meets these requirements -- again, I
would stress that these are for financial/fiscal contexts, and not for
general community-type contexts.
I wouldn't trust WebTrust over any other, especially for
finance. So I'm not sure of your point here.
Section 10:
Comment: Explicitly require the fiscal identity of the competent,
independent party be disclosed to everyone who asks, so that their
credentials may be independently verified.
? Define fiscal identity. Why are you *requiring*
this? What's wrong with showing a user a cert and
saying "if you want fiscal identity, and you see it
here, use it, if you want. If you don't see it,
don't use that cert. As you want!"
> After the huge accounting
> scandal associated with Enron, it's almost required that the auditor be able
> to have trust revoked from their previously-performed audits, and re-audits
> required when necessary.
We happen to know who the people are who "did" Enron.
They happened to bypass all the supposed checks in
place which were way way stronger than for Internet
certs.
Section 11:
Modify:
[We reserve the right to designate our own representative(s) to act as the
competent independent party or parties described above, should that prove to
be necessary and appropriate.] The cost of this operation shall be borne
equally by the Mozilla Foundation and the CA operator, the CA operator shall
pay its share to the Mozilla Foundation, and the Mozilla Foundation shall
pay both shares to its chosen representative. In no circumstances shall the
CA operator make any payment directly to the Mozilla Foundation's chosen
representative, nor shall any items of value be gifted or any preference in
future dealings be offered. In any case, the CA operator shall grant audit
capability of its CA operations to Mozilla's chosen representative to the
full extent determined by the chosen representative, limited to its CA
operations and financial dealings thereof, and shall not as a condition of
this access require any affirmation of confidentiality or non-disclosure
which shall prevent our representative from providing us any information not
otherwise protected under law.
Rationale: Asking someone to volunteer is one thing (I'll gladly volunteer
my time finding bugs, commenting on policies, auditing for compliance, etc),
but asking someone to volunteer money for plane trips, hotels, etc is
tantamount to demanding that they donate that much money to the Mozilla
Foundation. Some people have it, some people don't. The rest of my
proposed addition is designed to reduce the chances that the CA operator
could influence the performance of the independent competent party... and to
ensure that the Mozilla Foundation can actually get the story directly from
its chosen representative.
OK, here's where the policy gets subtle. It says that expenses
should be declared. What that means is that you are free to
negotiate this with the parties concerned.
But it also means that if any "gifts" are ppaid, then you should
declare that too. If so declared then the market will judge.
MoFo is a small honest techie organisation. Naive, some would
say. There is no way known on this planet or the next that it
will be able to detect ths sort of connivery that you are trying
to stop in the above paragraphs.
So the policy is subtle. It doesn't try and *stop* bad behaviour
or force good behaviour. It trys to encourage the disclosure of
all behaviour. And, then the market will judge. Or not. The
thing is that it recognises that some things are just beyond its
power.
Note: This procedure may need to be separated out into a separate "Mozilla
Foundation-designated Representatives for Audit of CA Compliance" document.
If it is, a reference to the document will need to be inserted.
13.
Comment: I think this (chained roots) is a REALLY good policy, and I think
it should be implemented as a requirement ASAP. Thawte used to do this with
its SSL123 certificates, but these certificates have now started to be
issued directly from their root without a chained CA.
Yeah. But nothing much happens there until the CA brand is
put on the chrome. Until CAs have a reason to care, they
won't care.
14.
Comment: Separate 'SSL-enabled servers' from 'SSL-enabled servers which will
obtain or transfer fiscal information'.
Define fiscal. Be prepared to have that definition tested ;-)
Comment: It should be explicit in this clause that everything which is
submitted must adhere to the then-current CP, else the request will be
denied.
! So any mistakes means that ... we can drop Verisign?
This wouldn't pass the reality test. Once a CA is in,
it's in for a goodly period. They will make mistakes
and they will push the limits.
15.
Comment: Does the Mozilla Foundation even have a formal policy in place for
ajudiciating these types of appeals?
Well spotted! No they do not. The policy is I think
"it goes to the executive committee, sometimes known as
"staff"." Now that's not all bad, there is I gather at
least one person on the exec who has some legal training
and could stand in as arbitrator.
I think this is something that should be ironed out in
time; but I'd suggest it be left until a dispute arises.
That way, there is some experience to show just how much
effort is needed.
16:
Add:
Each approved policy shall be numbered sequentially, in a vM.N manner. If
additional classes of CAs are permitted under the new CP, the M portion
shall increment. If clarifications of existing policy are necessary, the N
portion shall increment.
Rationale: Giving some kind of guidance as to how much scrutiny a
security-conscious person [including security officers] must give any new
revision of the document is probably a good thing. The tricky part is
ensuring that it is adhered to.
I didn't understand this part.
...and thus ends my suggestions within this missive. Please comment.
Thanks! I hope you keep up the comments.
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
