policy framework

[Peter Kurrasch]

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???

[Jeremy Rowley]

Very good points and well though-out, Peter. I do not think your points are
too idealistic.

I do disagree on point #7 as many implementations (particularly related to
s/MIME) require a key escrow or backup and recovery system. For example,
employees who will leave a company with encrypted records might need to
share that encryption key with other employees. For SSL certs, there are
times when a hosting provider for the entity named in a cert will actually
control the private keys and operate the website on behalf of the domain
owner. In these circumstances the CA must verify the organization's
authorization for the hosting provider to control the private keys. Instead,
the policy should be that end-entities cannot share keys except with
authorized agents or affiliates of the end-entity and only if that
authorization is verified with the entity identified as controlling the end
point.

I share your opinion that the NIST document contains too much of that simply
rehashes the policies already implemented by Mozilla. I suppose a browser
could go through the document and extract the wording choices they prefer
over current language, but I don't think the document, as a whole,
significantly improves security over the improvements already required by
the Mozilla policy this year. However, the version provided was just a
first public draft. I imagine the next draft will be an improvement and may
contain items that the CAB Forum Form or Mozilla might want to consider in
implementing. In that regard, I think it's wise to withhold judgment until
NIST releases a finalized version.

Jeremy

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

[Moudrick M. Dadashov]

I agree with Jeremy, not idealistic at all, especially your final point:

>(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.)

As we know the "Basic Requirements" has definition of "High Risk
Certificate Request" and I think similar approach can be taken here:
"High Risk Root inclusion Request". Within Peter's proposed framework,
I'd suggest to structure this into a few action/policy items. The
proposed structure might include:

1. DEFINE: what is considered a high risk request (entities that have
direct or indirect control over critical trust infrastructure
components: communication channels, high level network
control/management, hosting/data center services, DNS etc..)
2. DETECT: questions that every potentially risky requester can answer
(Do you or any other entities under your direct or indirect control
provide regional/backbone or last mile network services? are you a A
domain name registrar? Do you provide web site hosting services? etc.)
3. REQUIRE: disclosure of information about all entities that fall under
any of the listed in p.2.
4. COLLECT: more info for risk assessment (cross relationship between
the requester and all other entities under its control).
5. MAKE DECISION: publicly accepted decision or "/sole/ discretion".

Thanks,
M.D.

[Kathleen Wilson]

On 6/12/13 11:25 PM, Peter Kurrasch wrote:
> 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.
>

I won't be able to do this in the current version that we're working on
(version 2.2). So I've added this to
https://wiki.mozilla.org/CA:CertPolicyUpdates#Consider_for_Version_2.3
and included a link to this discussion thread.

Thanks,
Kathleen

[Peter Kurrasch]

Thanks for the feedback, Jeremy!

On 06.13.2013 6:58 AM, Jeremy Rowley wrote:
> I do disagree on point #7 as many implementations (particularly related to
> s/MIME) require a key escrow or backup and recovery system. For example,
> employees who will leave a company with encrypted records might need to
> share that encryption key with other employees. For SSL certs, there are

This is exactly the sort of input I was hoping people would provide, so
thank you for that. You make a good point that in the real world this
sort of thing will happen and there is really very little harm to that.
In fact I spent time trying to decide if I really cared about
individuals or just servers. I guess I decided to make a sweeping
statement just to get the conversation started.

> times when a hosting provider for the entity named in a cert will actually
> control the private keys and operate the website on behalf of the domain
> owner. In these circumstances the CA must verify the organization's
> authorization for the hosting provider to control the private keys. Instead,

Again, a very good point and probably a situation that warrants further
thought and attention. I don't have any data to support this but I
wouldn't be surprised if most web sites (and other services) are
actually hosted by someone else. It's probably more the exception that
the domain owner will also host...?

> the policy should be that end-entities cannot share keys except with
> authorized agents or affiliates of the end-entity and only if that
> authorization is verified with the entity identified as controlling the end
> point.

Perhaps another way to approach it is that there are "owners of private
keys" and "managers of private keys" with duties and responsibilities
inherent with each. The owner has to generate the private key, get it
signed, distribute as necessary, collect/reclaim as necessary. The
manager can not share it, must ensure its integrity/security, must
return it when necessary, and most importantly must report breaches
should they occur.

That last point is especially relevant when a web host serves multiple
domains on a single machine. Recently I came across a situation where
hackers were able to obtain the password file (most likely through SQL
injection) that compromised all users on a web-hosting machine. The
machine did not have virtualization in place so once the hackers had the
password file it was pretty easy for them to gain root access and,
therefore, access to all web sites and web data (databases, email
addresses, etc.). The attackers then went on to setup fake login pages
for free.fr and a few others, so while that was most likely their
principle objective one must nonetheless conclude that private keys had
been compromised and new ones should be re-issued. Obviously a good,
security-minded host will inform everyone that the compromise took place
but I don't assume this is normally the case.

> I share your opinion that the NIST document contains too much of that simply
> rehashes the policies already implemented by Mozilla. I suppose a browser
> could go through the document and extract the wording choices they prefer
> over current language, but I don't think the document, as a whole,
> significantly improves security over the improvements already required by
> the Mozilla policy this year. However, the version provided was just a
> first public draft. I imagine the next draft will be an improvement and may
> contain items that the CAB Forum Form or Mozilla might want to consider in
> implementing. In that regard, I think it's wise to withhold judgment until
> NIST releases a finalized version.

I hope they do issue another draft instead of going directly to a final
release. I considered providing comments on it but all I could really
come up with was "Dude! This document is like 3 years too late!" I
didn't think that would be overly helpful to the process! :-)

Again, thanks for taking the time to read my email and provide your
comments!
> Jeremy

>
> -----Original Message-----
> Sent: Thursday, June 13, 2013 12:25 AM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: policy framework
>

> 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.
>

[Peter Kurrasch]

Hi Moudrick--

Comments embedded below...

On 06.13.2013 3:08 PM, Moudrick M. Dadashov wrote:
> As we know the "Basic Requirements" has definition of "High Risk
> Certificate Request" and I think similar approach can be taken here:
> "High Risk Root inclusion Request". Within Peter's proposed
> framework, I'd suggest to structure this into a few action/policy
> items. The proposed structure might include:
>
> 1. DEFINE: what is considered a high risk request (entities that have
> direct or indirect control over critical trust infrastructure
> components: communication channels, high level network
> control/management, hosting/data center services, DNS etc..)

I think the idea of a "high risk inclusion" is a useful concept both in
terms of the potential for abuse (as you point out with the network
operator scenarios) but also the potential for wide-spread damage should
some sort of breach take place (think DigiNotar or a "too big to fail"
situation). So I think a definition should include both aspects.

Something I was thinking about before was how to address
government-owned CA's or CA's that are separate but operate on behalf of
the government. I think that situation invites all sorts of trouble
(and we have plenty of examples!) but should not be an automatic
disqualifier. For example, the Staat der Nederlanden seems to be okay
(as far as I know?).

> 2. DETECT: questions that every potentially risky requester can answer
> (Do you or any other entities under your direct or indirect control
> provide regional/backbone or last mile network services? are you a A
> domain name registrar? Do you provide web site hosting services? etc.)

Based on the above I think some questions about ties to government
authority include: are you a state government? are you owned (or
financially dependent?) on a government? do you do business with the
governments in multiple countries? do you issue certs on behalf of
government agencies (was thinking of some of the discussions we've had
here about US gov't CAs and/or the DoD)?

> 3. REQUIRE: disclosure of information about all entities that fall
> under any of the listed in p.2.
> 4. COLLECT: more info for risk assessment (cross relationship between
> the requester and all other entities under its control).

I think the "too big to fail" concerns could be addressed here
(maybe???). Since we do ask about technical constraints and gTLDs and
whatnot, I was wondering if there's a way to ascertain the scope that
the CA has in mind for a particular root/intermediate cert. For
example: Will the number of end-entity certificates that chain to your
certificate be less than 10,000? less than 1,000,000? less than
100,000,000? [Might want different granularity but I think you get the
idea.]

> 5. MAKE DECISION: publicly accepted decision or "/sole/ discretion".

Yes, that is *the* question! I would speculate that sole discretion is
too loose because I think Mozilla (the organization) needs something a
little more stringent that can stand up to legal scrutiny should that
arise. For example, we don't want Mozilla to get sued where an argument
is being made "you don't like me because I operate in Southern Elbonia"
or some such thing. I'm hoping that with further discussions on the
policy framework we can come up with standards and criteria that do hold
up to such scrutiny.


Thanks for reading my email and for providing this feedback!

Peter.