* To address some of the concerns expressed about CAs issuing "duff" certs, I'm considering expanding clause 4 to read as follows:
4. We reserve the right to not include a particular CA certificate in our software products, to discontinue including a particular CA certificate in our products, or to modify the "trust bits" for a particular CA certificate included in our products, at any time and for any reason.
This includes (but is not limited to) cases where we believe that including a CA certificate (or setting its "trust bits" in a particular way) might cause undue risks to users' security, for example, with CAs that
- knowingly issue certificates without the knowledge of the
entities whose information is referenced in the certificates; or
- knowingly issue certificates that appear to be intended for
fraudulent useThis also includes (but again is not limited to) cases where we believe that including a CA certificate (or setting its "trust bits" in a particular way) might cause technical problems with the operation of our software or be at variance with relevant standards, recommendations, and industry best practices, for example, with CAs that issue certificates that have
- duplicate issuer names and serial numbers;
- invalid public keys (e.g., DSA certificates with 2048-bit primes,
or RSA certificates with public exponent equal to 1);
- incorrect extensions (e.g., SSL certificates that exclude SSL
usage, or authority key IDs that include both the key ID and the
issuer's issuer name and serial number);
- invalid dates; or
- ASN.1 DER encoding errors.I'm proposing including this language in clause 4 rather than clause 6 (requirements on CAs) for a couple of reasons.
First, the basic concern as I understand it is that we keep out incompetent or dubious CAs; clause 4 is all about maintaining our freedom to reject or remove CAs, with the new language basically clarifying exactly why we might do this, so I think that's the appropriate place to put the new language.
Second, IMO at least some of the example reasons to reject/remove CAs could be problematic when interpreted as strict requirements per clause 6. For example, it's quite possible that a CA might knowingly issue a CA with false information in response to a legitimate request from a law enforcement agency or other government entity. If we happened to find out about this I wouldn't want the policy (as strictly interpreted) to always force us to remove the CA.
As another example, in some cases CAs might issue "confusing" certs for reasonably legitimate reasons, e.g., as in the "First Bank" example I previously gave. In other cases there might be a pattern of behavior indicating real problems, e.g., with a CA that appears to have been set up as mainly as a way for phishers to get certs for "paypa1.com", "micr0soft.com", etc. IMO the policy needs to provide us the freedom to make subjective judgements as to what indicates a real problem and what does not. The point of clause 4 is to provide that needed "wiggle room", which again is why I think the new language should go into clause 4.
* To address the concern about certificates of different assurance levels being issued under the same CA root (or intermediate), I'm proposing adding a new clause 13 as follows:
13. In addition to the requirements outlined above, we also recommend that CAs use different root CAs (or different intermediate CAs under a single root) when issuing certificates according to different Certificate Policies, so that we or others may selectively enable or disable acceptance of certificates issued according to a particular policy, or may otherwise treat such certificates differently (e.g., in our products' user interfaces). We reserve the right to make this a requirement in the future, and to not include a particular CA certificate in our software products, to discontinue including a particular CA certificate, or to modify the "trust bits" for a particular CA certificate, based on the CA's practices in this regard.
I'm proposing this as a recommendation (at present) rather than a requirement for the reasons I've previously stated: I don't think we should mandate this until it's clear how much of a problem this really is, how much it would affect the existing set of CAs already included in the products, and whether we're going to make UI and other changes that would depend on this. However I do think it's reasonable to put CAs on notice that we're thinking about this issue and may take stronger action at some point.
Also, note that I sidestepped the tricky issue of defining and determining certificate "assurance levels". I think a better approach (at least for now) is simply to recommend that all certs issued under a single CA (whether issued directly by a root CA or by an intermediate CA under a root CA) be issued according to the same policy.
As usual, comments are welcome and encouraged. I'll publish a formal draft 12 soon; I hope that draft 12 can be the final draft, because I think it would be unlucky to have a draft 13 :-)
Frank
-- Frank Hecker [EMAIL PROTECTED] _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
