I have some very grave concerns with the release candidate of the
Certificate Policy 1.0 (CP1RC), as posted on Frank Hecker's site. Many of
these are based on accounting and accountability, as well as knowledge of
what's occurring within the financial industry.
To be certain that I can properly explain where I'm coming from, I'll have
to provide an affirmation, and give a little bit of history:
- I believe that having more CAs in the world is an inevitability.
- I believe that restricting which CAs are allowed to embed their root
certificates beyond purely technical/interoperability concerns is
counterproductive.
- I believe that the current models that are used for determining how CAs
behave are broken, and have inhibited the adoption of cryptography beyond
merely the financial realm.
- I believe that X.500, as a concept, is a joke. Thus, I believe that
requiring certificates to only be issued with X.501 DNs is absolutely
intolerable.
- I believe that the history of Netscape, from 0.94 onward, shows a
willingness to extend the standards when necessary (the implementation of a
CN= attribute requirement for webservers which must match the server's DNS
name, for example).
On the flip side, however, I also have to frame my arguments within my
knowledge of accounting, business, and law. (I'm not a CPA, MBA, or lawyer
by any means, and my interpretations are my own. I have discussed these
concepts with legal professions in the past, and I continue to refine them
as appropriate, but these are the extents of my knowledge and authority.)
- Cryptography can be used to verify legal/fiduciary identity.
- People involved in a financial transaction are required to collect a
certain amount of information about each other -- running the gamut from
"the money's good" for cash transactions, to the verification that the
person giving a given CC number actually owns it ("the card verification
code matches", or as brick&mortar merchants were originally required to do,
"verify that the signature matches").
- It is not legal to sell a product without a warranty of merchantability.
The person paying must obtain information about the merchant in order to
take them to task for it, however.
- The Certifying Authority is required, because of these legal/fiduciary
reasons, to verify the legal/fiduciary identity of anyone who requests a
certificate. This is encoded as an international standard, part of the
X.500 series [I don't remember which one off the top of my head]. [minor
quibble: many of the X.500 series of 'recommendations' have been
standardized by the International Standards Organization, thus I use the
term 'standard'.]
Netscape, back when it created SSL, attempted to make it as
internationally-standard as possible, and thus implemented the restriction
that all certificates must be in X.509 format for identification. The SSL
standard went on to become an Internet standard, superseded by SSLv3, then
TLSv1, and now there are the (not yet standard) extensions to TLS which
finally started accepting non-X.509 certificates as peer identity
certificates. (Specifically, OpenPGP.)
For 10 years, customers have been taught that if there's a lock icon (in the
beginning of Netscape it was a 'solid key' icon and a blue bar), the
connection is secure. This is true as far as it goes -- nobody can
eavesdrop on it, certainly, but you still have to explicitly ask your
browser who it is who has been issued the certificate which has been
trusted. (When the only webserver operators who got certificates that would
work had to prove their identity to the CA, that made a bit of sense... it
made certain that you were only giving your credit card number or financial
information, which was Netscape's initial drive for implementation of SSL,
to someone who had had his legal identity verified. It provided for the
reduction of 'con men' in the game.)
However, there's some new issues in light of this. People are much more
willing to put their credit card number on any website that is 'secured'.
People even apply for credit cards over the net, across 'secured' websites.
Remove the requirement for identity proof to obtain a certificate, and you
suddenly remove the barrier, making con-men much more able to do their jobs
without interdiction.
Also, the VISA network recently started demanding much more stringent
control of customer information. In conjunction with identity, this imposes
a high degree of accountability... but only if the customer knows who they
give their credit card information to, and thus who to hold to account.
So, what I would propose is 'warn the user when submitting a form to a site
secured by a CA that does not provide for proper identity in its CPS, and
audited by (for example) the WebTrust auditing process.' Also, impose
policies on the certificates issued by those CAs [I'm explicitly thinking
Thawte, here], and require that they uphold the terms in their CPS as far as
can be verified.
(Thawte's CPS states that they will only issue web-server certificates to
entities with High Assurance of identity. Thawte has recently started
issuing, from the same root, certificates to entities with merely web
address verification, through its SSL123 program -- I will assume that you
all know this, and move on.)
CAs which have audited CPSs that state that they will only issue
certificates with O=, OU=, S=, L=, and C= attributes in the DN to entities
which have had their legal identity verified should have their issued
certificates validated as such, and only 'trusted' for forms submittal if
those attributes truly exist, otherwise warn in the same way as a
non-audited CA. (The idea is to ensure that the policy which is stated is
actually upheld.)
At issue is identity theft, and 'phishing'. I've installed the CACert root
in my browser, and have a webserver which has a certificate therefrom. I am
in the process of figuring out if the other redirection-warnings are
sufficient to provide at least a notice that there's some issue with the
connection, for other possible bug reports.
Now. As I said before, I'm all for the idea of alternate CAs, and I am all
for certificates being issued based on information available to those
alternate CAs. I believe that membership organizations (and even websites
with forums and such) should run their own CAs, issuing certificates to
people who prove possession of access credentials to accounts within those
realms. These CAs should /not/ be trusted for financial transactions,
because they don't prove fiscal identity... and eventually I'd like to see a
user-interface change in all browsers where the lock icon is joined by some
kind of 'fiscal verification' icon when the certificate is issued by an
audited fiscal CA in accordance with its CPS. (Get WebTrust to have its own
CA, which issues chained CA certificates to commercial CAs which it has
audited. Why it doesn't do that already is beyond me.)
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.
Strike:
- cRLDistributionPoints or OCSP authorityInfoAccess extensions for which no
operational CRL or OCSP service exists.
Rationale: The latter is for those who have operational issues with CRL or
OCSP services, decide to take them down, and no longer issue certificates
with those extensions embedded... but do not revoke prior certificates with
those extensions embedded. I may have missed some discussion on this topic.
(The CA certificate, itself, may be presented with OCSP/CRL information, and
then have it taken down for some reason. If that's the case, the CA
certificate can't really change.)
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]
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.
Comment: 'stated purpose(s) of the certificates' needs to be defined.
Stated according to what standard? PKIX?
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.
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.
(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.
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. 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.
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.
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.
14.
Comment: Separate 'SSL-enabled servers' from 'SSL-enabled servers which will
obtain or transfer fiscal information'.
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.
15.
Comment: Does the Mozilla Foundation even have a formal policy in place for
ajudiciating these types of appeals?
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.
...and thus ends my suggestions within this missive. Please comment.
Cordially,
Kyle A Hamilton
_______________________________________________
mozilla-crypto mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-crypto
