I have some very grave concerns with the release candidate of the Certificate Policy 1.0 (CP1RC), as posted on Frank Hecker's site.
My apologies for not responding to you before now; I was busy with work stuff and didn't have sufficient spare time at home to adequately consider your comments.
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:
<snip>
Thanks for providing this, incidentally. I like it when people make their views clear up front, because it gives me a feeling for what their key assumptions and values are. This is immensely helpful.
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.)
Incidentally, to my knowledge no one has proposed accepting non-X.509 certificates in the context of Firefox. (A side issue but I thought one worth commenting on; I'm not that familar with what OpenPGP is doing with TLS.)
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.
<snip>
Your summary is in line with accounts other have given, and we can accept it as true at least for the purposes of addressing your points.
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.'
This suggestion is consistent with proposals for a new SSL UI to distinguish various cases such as domain-validated certs vs. identity-validated certs, certs from known CAs vs. certs from unknown CAs, and so on.
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.
Right. This is an issue where I concede you may have a valid point, but not necessarily one I want to enshrine in the MF CA cert policy right now. I'd prefer to punt on this until we have a consensus for how we should move forward in terms of SSL UI (as noted above). At that point we'll have a more fine-grained way to enforce policy than just removing CA certs from the default list. For example, we can display warning messages, "demote" certificates from one type of UI to another, and so on.
(This ties back to Ian's point about how much we can really control what CAs do. I think we can certainly have some influence over CAs, albeit perhaps not as large as some would like, but removing a CA is too blunt an instrument of influence for many of the issues we'll encounter.)
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...
Again, this points to the issue of reworking the SSL UI to account for different types of certs.
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.
As noted above I don't want to enshrine this in policy, at least not until we have better ways to respond to violations.
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.)
Those more knowledgeable on this subject can correct me, but IIRC here we're talking primarily about extensions included in end-entity certificates. Ram originally proposed including this, and I believe his rationale was that if a CA was going to advertise the existence of a revocation service by including information in issued certificates, then the CA had an obligation to actually provide that service at least until the date/time at which the certs in question expired.
This requirement is to some degree outside my stated goals for the policy -- it doesn't affect typical users one way or the other because Firefox, etc., by default don't do revocation checking at present. However I thought it was a reasonable requirement, and one which might become relevant if in fact we decided to enable OCSP checking by default.
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[.]
IIRC you added this as a way to gauge interest in the CA's being added. I think this is unnecessarily restrictive. For example, I think Henrik Gemal suggested adding the Danish CA TDC OCES. I can't remember whether this was before or after Henrik went to work for TDC, but in any event I knew Henrik by reputation and was willing to accept based solely on his say-so that TDC was worth considering for inclusion.
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.
If you had made this suggestion prior to my formally submitting the policy I might have added it. However at this point I see it as something that can wait for the 1.0.1 or 1.1 version of the policy.
Comment: 'stated purpose(s) of the certificates' needs to be defined. Stated according to what standard? PKIX?
By "purposes" I meant those referenced in clauses 7 and 14: certs used for SSL web sites, S/MIME email, and object signing. I agree that this could be clarified, and this would be a worthy update for a 1.x policy revision.
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.
The problem is that the current policy proposal assumes (has to assume) the current state of affairs with regard to SSL UI, where the browser makes no distinction (has no way to make a distinction) between certs issued according to different CPs/CPSs. One of my cardinal principles in creating the policy was to avoid including language that assumed/required the implementation of new features, especially features on which there was no current consensus on how (or even whether) they should be implemented.
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)
And see my comments above in response to your comments. In summary, worth considering for policy 1.x, not IMO a show-stopper for policy 1.0.
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.
Actually, it's not WebTrust per se that meets the requirements, if you're saying what I think you're saying; rather it's the accounting firms and accounting professionals that have been authorized by WebTrust to conduct audits under the WebTrust for CAs program. This is what I was getting at with the language in clause 9 about "a person or other entity who is authorized to perform audits according to the stated criteria (e.g., by the organization responsible for the criteria or by a relevant government agency)". Here WebTrust = "the organization responsible for the criteria".
Since there may be some confusion on this point, I'll consider addressing this in a FAQ and/or a future policy version.
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.
I'm assuming from your response to Ian that by "fiscal identity" you mean simply the "true identity" of the party, i.e., who they are in real life, either as an individual person or an organization? If so, I think the identity of the party will be publicly disclosed in any case, since this will all be a public process and we will be relying on public information re the party's competence, etc.
The one "edge case" I can think of is when the party is actually known through a pseudonymous identity rather than a RL identity. (This is certainly conceivable given the historical use of nyms in the crypto/security hacker community.) If this were to happen (and in practice I suspect it won't) then it's not 100% clear to me that this is actually a problem: Our hypothetical "Lucky Unicorn" would have a public record and reputation associated with that nym, and if they botched a CA evaluation then that would have real consequences for their (presumably carefully nurtured) reputation.
In some ways I would be more worried about the problem of "revoking trust" in auditors in the case of organizations, since it's certainly possible for incompetent people to move from firm to firm, and we wouldn't necessarily know exactly which people within a firm are doing the work.
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.
I'll just refer to Ian G's response here: Clearly there is potential conflict of interest here: A CA could pay a volunteer's expenses, etc., and that could influence their judgement. (For example, maybe the CA is located in some exotic island location and the volunteer has to spend a month on-site :-) As Ian notes, I'm not smart enough to come up with a foolproof system for preventing conflicts of interest; however if we know what the relevant arrangements are then we collectively can apply the "smell test" to judge whether or not something funny is going on.
(I have to admit that my opinions in this area are colored by my experience living and working in the Washington DC area and being involved in Federal government activities. I've seen elaborate schemes for regulating contractors, lobbyists, etc., and I have concluded that all of them can be "gamed" in one way or another. IMO public disclosure accompanied by a motivated group of outside critics is just as effective as a deterrent to undesirable behaviors, and arguably more effective.)
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.
As I've stated previously, this is an area where IMO we need to think a bit before deciding which way to approach this.
14.
Comment: Separate 'SSL-enabled servers' from 'SSL-enabled servers which will obtain or transfer fiscal information'.
See my comments above; right now we have no way to make this distinction within the browser.
15.
Comment: Does the Mozilla Foundation even have a formal policy in place for ajudiciating these types of appeals?
Not at present. As it happens I think it would be a good idea for the MF to put more formality into things like the role of mozilla.org staff and how certain project decisions get made. But that is a problem for another day.
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.
This (or something like it) is worth considering for the next release of the policy. For 1.0 I think it's potentially useful but not essential.
...and thus ends my suggestions within this missive. Please comment.
And my comments end as well, except for this:
Again, thank you for your taking the time to read the proposed policy closely and write up a detailed set of comments. As noted above, I do not believe the concerns you've raised are "show-stoppers" for the 1.0 policy; however you've put forth some suggestions worth considering for the next version, and certainly your perspective is welcome as we consider whether and how to rework the browser security UI to address some of the issues you and others have raised.
I'm glad you found your way to the Mozilla security forums. To echo a comment you made in response to Ian, I can't vouch for how intellectual it is, but discourse we got plenty of :-)
Frank
-- Frank Hecker [EMAIL PROTECTED] _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
