I'm going to take a step back from the other thread about updates to
item #3 in the enforcement policy and propose a "policy framework".
Generally speaking, I like where that discussion is going and I think
the CA Certificate Policy has a lot of good rules and requirements but I
think it needs to have an explicit "statement of purpose" if you will.
Perhaps it's obvious why a policy is needed but I think the policy as a
whole would be strengthened if we explain why we're here, which can then
be used to explain why we have these rules and requirements--and,
ultimately, the enforcement and consequences.
Please note that I don't claim all these ideas as my own but think of it
as an attempt on my part to incorporate the many good ideas and comments
that have been brought up in this forum. I hope we can have some good
discussion on this, too!
Part 1: Chain of Trust
I think the first step to take is to acknowledge the chain of trust that
is implicit for Mozilla products; namely:
User --> Mozilla-owned software product --> Target data
And with regard to security policies and CA's and certificates, the
chain can be expanded as such:
User --> Mozilla --> Root CA --> Intermediate CA --> "Target
location" --> Target data
I would highlight a few details:
(1) Mozilla plays an important, critical role in establishing trust
for the user. Mozilla must therefore conduct itself with integrity and
transparency to ensure that confidence is maintained. (Hence the "we
reserve the right" language, and so forth.)
(2) Mozilla relies on outside entities to help establish that trust,
and therefore Mozilla places expectations on how those entities conduct
themselves (for example, the BR, RFCs, etc.). Mozilla also establishes
and enforces its own requirements per (1).
(3) The "target location" may typically be thought of as a web site or
other "end entity" embodiment. From my understanding I think
responsibility here gets pinned to the CA's (both root and intermediate)
but I would point out that sometimes other Mozilla features help out
here. Specifically, I'm thinking of "this email looks like spam"
warnings or "this site has been reported for phishing" and so forth. If
someone is not using Firefox or Thunderbird then those features may or
may not be available, so I think the takeaway here is that establishing
trust on the "target location" is a team effort between Mozilla and the CAs.
(4) Hopefully when all is said and done the target data can be
trusted: it was not corrupted or compromised; it reached the intended
destination without being subjected to spying or snooping; it will not
unleash a destructive virus; and will basically not result in the loss
of privacy or personal information (unless, of course, the user intended
to reveal something private or personal). Basically, *this* is why we
are here!
Part 2: Rules and Requirements
(5) CAs must not share or otherwise reveal their private keys--either
in part or in whole--to anyone, except a higher-order CA to which it
chains. Specifically this means a CA can not share it's key with a
government agent or agency, period. (There are no sacred cows here, so
a CA in the US that reveals a key to the NSA gets the same treatment as
anyone else! Also, I specifically chose to say "in part or in whole"
because if someone were to say "here are the first 500 bits of my key"
with the understanding that the remaining bits would then be cracked,
that is just as damaging as revealing the entire key.)
(6) CAs must not share or otherwise reveal those keys--either in part
or in whole--which are provided to them for the purpose of generating
new certificates. (Same issues as with (5) except that here if a CA
acts sloppy with other people's keys then it's the CA that bears the
consequences.)
(7) End-entities to whom a certificate is issued must not share or
otherwise reveal their private keys--either in part or in whole. This
rule gets tricky to enforce but I think a couple points are worth
mentioning:
(a) this probably applies to all keys you've generated and asked to
be signed, not just the "current" key;
(b) if someone's server gets hacked in a way that compromises the
private key, that key must be discarded immediately and a new key pair
generated and signed;
(c) people sometimes make mistakes or inexplicably reveal private
stuff, but a pattern of disregard to keeping private keys private is
quite another matter;
(d) I hope that anyone attempting to obtain EV status (or
equivalent) for a web site already understands the need to safeguard the
private key and certifies as much, which means that Mozilla and/or a CA
can take immediate action, if needed, should the private key be disclosed
(8) CAs must not issue certificates that were not explicitly requested
by a lower-order entity. This includes (and is not limited to) all
forms of the following: (Note: this is my attempt to dance around the
"knowingly or intentionally mis-issued" language we've been
discussing--which I think gets confusing.)
(a) issuing a cert that allows MITM-style attacks
(b) issuing a cert to aid someone else in "traffic management" or
similar purposes
(c) issuing a cert to enable spying on encrypted data/traffic
(d) issuing a cert to fraudulently represent a web site ("hey yeah,
I'm
google.com") or person ("sure, my name is Julian Assange")
(9) CAs will issue certs in accordance with specs in the latest BR
release. (I haven't kept up with this so my apologies if I've
duplicated some of that in the above. My thinking was just that this
rules section would cover stuff over and above what the BR mandates, but
still say that Mozilla recognizes it and expects it to be followed.
Note also I've chosen to ignore the NIST document since I personally
don't think it helps improve the security of anything.)
Part 3: Enforcement and Consequences
This email is already too long and I think the options here are fairly
obvious, so I won't say much. However, I would like to suggest 2
"softer" consequences for consideration:
(10) Mozilla may choose to allow a CA to remain in the Mozilla CA
certificate program but prohibit the CA from expanding its role.
Specifically this means that existing certs would remain in the trusted
store and may be updated as needed (e.g. push out the expiration date)
but requests to include additional certs will be denied.
(11) Mozilla may choose to "sunset" a CA's involvement in the program,
meaning that any certs already included in the trusted store may remain
and will be removed upon reaching the expiration date, if not sooner.
Requests by the CA for inclusion of additional certs will be denied.
And I have one last thing:
(12) Corporations and government entities that sell data networking
equipment and/or operate public data networks--in addition to issuing
certificates--are subject to increased scrutiny and possibly harsher
consequences. The desire to increase equipment sales or network access
can sometimes lead to compromising security, and such compromises will
not be tolerated. (And like I said before, no sacred cows! Personally
I think a similar statement could be made for web site operators who
also want to be CA's, a la Google or Go Daddy, but would like to hear
other people's thoughts.)
Too much? Too idealistic? Any thoughts or concerns???