Terminology and policy in relation to subordinate CAs
Frank Hecker
now. Unfortunately since leaving Mozilla a combination of work and
family responsibilities has prevented me from doing anything related to
Mozilla CA policy and approvals (or anything else unrelated to my work
or family, for that matter). However Kathleen asked me to comment on
this "internal" vs. "external" subordinate CA issue, so I'm going to try
to clarify my own position on the matter and what I think the Mozilla
position has been and should be.
Before I do that though, I think we need to be more clear on what we're
actually talking about. In particular, there are two separate senses in
which we've used the words "internal" and "external", which I think has
contributed to the confusion around these issues.
The first distinction is whether a particular subordinate CA is operated
by the same organization operating the root CA or by a third party
external to the root CA organization. This distinction came up in
relation to audits, and in particular in relation to the question of the
scope of the audit of the root CA organization. (In other words, to what
extent does or should the root CA audit cover subordinate CAs not
operated by the organization running the root CA?)
In retrospect I think better terms for these two cases would have been
"in-house" subordinate CAs vs. "third-party" subordinate CAs. I'll use
those terms below to avoid confusion.
The second distinction is whether or not a particular subordinate CA
issues certificates to entities otherwise unaffiliated with the CA
organization. Here I think that instead of "internal" vs. "external"
better terms would be "private" (or "enterprise") vs. "public".
A public subordinate CA is a subordinate CA that issues certificates to
organizations and individuals who are otherwise unaffiliated with the
organization running the subordinate CA, for use in transactions with
arbitrary individuals and organizations.
A private (or enterprise) subordinate CA is a subordinate CA that issues
certificates only to organizations and individuals formally affiliated
with the organization running the subordinate CA (e.g., the
organization's employees or contractors), for use in private
transactions among those organizations and individuals.
We then have four possible combinations:
1. In-house public subordinate CAs. This is the typical case where a
commercial CA establishes one or more internally-operated subordinates
to offer certificates of a particular type (e.g., EV vs. non-EV
certificates, or SSL certificates vs. email certificates) to the general
public.
2. Third-party public subordinate CAs. This is the situation we've seen
with some government-sponsored root CAs (and perhaps in other cases as
well -- I can't recall exactly) where the organization running the root
CA delegates to other organizations the task of issuing end entity
certificates to the general public. For example, there might be a
separate organization authorized to issue certificates for general
business purposes, another organization issuing certificates
specifically within a vertical industry sector like financial services,
a third organization to issue certificates to individuals, and so on.
3. In-house private subordinate CAs. This case would cover CA
organizations that establish subordinate CAs for internal testing or
other internal purposes.
4. Third-party private (or enterprise) subordinate CAs. This is the
typical case where a commercial CAs has enterprise customers who want to
operate their own CAs for internal purposes, e.g., to issue SSL server
certificates to systems running intranet applications, to issue
individual SSL client certificates for employees or contractors for use
in authenticating to such applications, and so on.
Having clarified the terminology (I hope), here are my own opinions on
the policy issues related to these various cases:
1. In-house public subordinate CAs. This in IMO a non-controversial
case. We've traditionally encouraged CA organizations to use
internally-operated subordinate CAs as a way to partition issuance of
certificates of different types, as opposed to issuing end-entity
certificates directly from the root. Such in-house subordinate CAs
should be covered under audits associated with the corresponding root CA.
2. Third-party public subordinate CAs. From the point of view of the
typical Mozilla user this case is similar to the case of in-house public
subordinate CAs, since a typical Mozilla is likely to encounter
certificates issued by these third parties in the course of typical
activities like web browsing. Hence just as with in-house public
subordinate CAs we want and need assurances that the third parties are
under an acceptable audit regime. There's also a strong case for
requiring disclosure of the identity of these third parties, since in
effect they're functioning as public CAs just as are typical commercial
CAs that happen to have their own root CA infrastructure and apply to
Mozilla for inclusion.
3. In-house private subordinate CAs. This is also IMO a
non-controversial case. As noted above I think this primarily covers
test CAs and intranet CAs for the CA organization's internal use, and
such subordinate CAs (to the extent they exist) should be addressed by
the standard audit(s) performed against the CA organization.
4. Third-party private subordinate CAs. In comparison with third-party
public subordinate CAs, here IMO the case is less strong for requiring
disclosure of the identity of these third parties, since they're not
functioning as public CAs and typical Mozilla users would not encounter
certificates issued by these CAs in their normal Internal activities.
However we want some assurance that third-party private CAs are not
going to start functioning as public CAs, so IMO there's a strong case
for requiring that the third parties be under an acceptable legal
framework and audit regime, just as we'd require for third-party public
subordinate CAs.
So the bottom line is that as a matter of policy I don't think we need
to or should be requiring CA organization to disclose the identities of
their enterprise customers operating third-party private subordinate
CAs. We traditionally have not done this, and I don't think either the
subordinate CA checklist or the problematic practices document were
intended to be read that way. In the subordinate CA checklist my
interpretation is that the section "Subordinate CAs Operated by Third
Parties For Internal Use" covers what I'm calling third-party private
subordinate CAs, and it requires only a "general description of the
sub-CAs operated by third parties" and not actual disclosure of the
third parties' identities.
However... having said the above, I don't dismiss out-of-hand the
concerns expressed by Stephen Schultze and others. There is a trade-off
here between the rights of organizations and individuals to engage in
private business transactions under conditions of confidentiality, and
the right of the public to have information about the nature of those
transactions and the identities of the parties engaging in them. Like
most cases of conflicting rights, there is no one "correct" answer; you
have to make a judgment call, and people can have legitimate
disagreements on what that judgment should be.
Brian Krebs (whose blog I highly recommend, incidentally) published a
story a few days ago that I think is highly germane to this discussion:
http://krebsonsecurity.com/2010/04/isp-privacy-proposal-draws-fire/
The subject at issue is whether ISPs should be required to disclose the
identities of (and contact information for) their business customers. At
first glance this issue seems very analogous to the issue we're
discussing here, and the cases for (or against) disclosure would
presumably would be the same: If you favor requiring ISPs to disclose
the identities of their business customers, presumably logic would
dictate that you'd also favor requiring CAs to disclose the identities
of their third-party customers running subordinate CAs (whether public
or private).
However IMO the cases are not exactly analogous, for at least three reasons:
First, in the ISP case the information in question is already public,
and the newly-introduced proposal is to allow the information to be kept
private at the ISP's or customer's discretion. In the subordinate CA
case the reverse is true: CAs have traditionally treated their lists of
enterprise customers as confidential information not subject to public
disclosure. In general I think a proposal to change the status quo
should have a higher barrier to adoption than the counterproposal to
maintain the status quo.
In the case of ISPs, both the ISPs and their customers have known that
the information in question would be public, and they freely entered
into their business arrangements under that expectation. However
traditionally CAs and their customers have had a reasonable expectation
that they could do business in confidence, especially in cases where
their transactions had no public impact (as for enterprise/intranet
CAs). IMO to violate that expectation requires a good justification.
Second: Getting an assigned IP address range from an ISP by its very
nature has implications for the public Internet, since the only reason
to get such addresses is to communicate with other systems on the
Internet. If organizations want to engage in purely private internal
networking then they can and do use private IP address spaces (e.g.,
192.168.x.x) with minimal or no inconvenience to themselves.
However third-party private CAs operated by enterprises are by their
nature private affairs that do not normally entail any impact on the
public Internet. (They could have an impact, if certificates issued by
those CAs were to be used on the public internet contrary to whatever
agreements existed between the CA and the enterprise, but that would be
an exception to the general rule.) Enterprises could do purely private
CAs, but they'd incur the additional inconvenience of having to
distribute and install their own root certificates.
Third, and finally: There have been and most likely will continue to be
many known cases of ISPs allowing their networks to be used for
activities that have an adverse impact on general Internet users:
spamming, hosting controllers for botnets, etc. The nature and extent of
these activities is such that one can make a strong case that the public
interest in disclosure overrides the right of ISPs and their customers
to engage in private business transactions.
However in the case of CAs, unless I missed something in my time away,
the concerns here seem to be mainly theoretical -- that bad things could
potentially happen, not necessarily that they're happening now. Given
that, I'm willing to give CAs and their customers a greater "presumption
of innocence", and allow them to continue the current practice of
engaging in private business transactions without disclosure of customer
identities, as long as the activities associated with those transactions
are private in nature (as they would be for third-party private CAs as
defined above) and as long as we have reasonable assurances that legal
and audit frameworks are in place to ensure that those activities don't
impact typical Mozilla users on the public Internet.
If things change then I'm open to reconsidering this, but that's my
opinion for now, for what it's worth.
Frank
--
Frank Hecker
hec...@hecker.org
Frank Hecker
> 1. In-house public subordinate CAs. This in IMO a non-controversial
> case.
"This is IMO ..."
> 4. Third-party private subordinate CAs. In comparison with third-party
> public subordinate CAs, here IMO the case is less strong for requiring
> disclosure of the identity of these third parties, since they're not
> functioning as public CAs and typical Mozilla users would not encounter
> certificates issued by these CAs in their normal Internal activities.
"... in their normal Internet activities."
David E. Ross
I agree thoroughly. I like your terminology and recommend that all
policies and other documentation (e.g., at the various Wikis) adopt that
terminology.
I think it should be sufficient that the root CA make public whether or
not it has any third-party private subordinate CAs and what contractual
restrictions it imposes on such subordinate CAs. This does not require
identifying those subordinate CAs. However, the root CA must also make
public how it monitors and enforces the contractual restrictions that
prohibit a third-party private subordinate CA from becoming a
third-party public subordinate CA.
--
David E. Ross
<http://www.rossde.com/>.
Anyone who thinks government owns a monopoly on inefficient, obstructive
bureaucracy has obviously never worked for a large corporation. © 1997
Stephen Schultze
> 4. Third-party private subordinate CAs. In comparison with third-party
> public subordinate CAs, here IMO the case is less strong for requiring
> disclosure of the identity of these third parties, since they're not
> functioning as public CAs and typical Mozilla users would not encounter
> certificates issued by these CAs in their normal Internal activities.
While this is true, the threat model involves something not normal
happening: specifically that the end user is undergoing normal
browsing but a third party do something very abnormal.
> However we want some assurance that third-party private CAs are not
> going to start functioning as public CAs, so IMO there's a strong case
> for requiring that the third parties be under an acceptable legal
> framework and audit regime, just as we'd require for third-party public
> subordinate CAs.
Do we have a definition of what an acceptable legal regime consists
of? We have clear definition of what constitutes an acceptable audit,
but I'm not aware of the same for the legal regime. Would such a
definition take into account jursidiction? I would hope so, because
the effectiveness of any legal regime depends fundamentally on
jurisdiction and enforceability.
> So the bottom line is that as a matter of policy I don't think we need
> to or should be requiring CA organization to disclose the identities of
> their enterprise customers operating third-party private subordinate
> CAs.
There are two basic problems with this approach:
1. There is no way to know whether "enterprise customers operating
third-party private subordinate CAs" will continue to be "enterprise
customers operating third-party private subordinate CAs" unless
there's some major improvement in accountability and enforceability.
Even then, whatever solution you come up with will probably be outside
of the technical domain, so there's nothing in the core cryptography
enforcing this. As Dan Kaminsky put more bluntly at 26 C3:
"You can just walk up to a certificate authority and say, 'Yeah, so I
spent a lot of money on my CA and it doesn't work with anyone outside
my company. Um, here's a pile of money and I promise to be good.' No
really, you can just buy a root certificate, effectively. It's not
expensive, it's not that difficult, and there's an unknown number of
companies out there -- not just the certificate authorties but all of
the companies that have intermediate certificates -- they can all
issue certificates for your domain."
http://events.ccc.de/congress/2009/Fahrplan/events/3658.en.html
2. No amount of audit or legal liability resolves the dilemma that the
Mozilla CA security model ultimately defers to user control, and users
cannot control what they do not know. If I decide that regardless of
whatever purported private or public law constraints are on a CA, I
don't trust them to operate their "private" CA privately, there is
nothing I can do to distrust them in this model.
> However... having said the above, I don't dismiss out-of-hand the
> concerns expressed by Stephen Schultze and others. There is a trade-off
> here between the rights of organizations and individuals to engage in
> private business transactions under conditions of confidentiality, and
> the right of the public to have information about the nature of those
> transactions and the identities of the parties engaging in them. Like
> most cases of conflicting rights, there is no one "correct" answer; you
> have to make a judgment call, and people can have legitimate
> disagreements on what that judgment should be.
I am not persuaded that this gets down to a question of competing
rights. Companies wishing to do engage in root delegation are asking
everybody to do them a favor. They haven't found a technically secure
way of doing this process, so they are asking us to trust them and
their business partners not to do the wrong thing. The least we can
do is ask to know who those entities are.
At the end of the day, they have other options too. They can go
through the steps in order to get their own employees to add their
self-signed cert to their database (aka: the way it is supposed to
work). They can also apply for a CA cert directly. There is nothing
about disclosure that fundamentally prevents them from doing
business... even confidentally. They just couldn't rely on blind
trust (hope).
> I think a proposal to change the status quo
> should have a higher barrier to adoption than the counterproposal to
> maintain the status quo.
I wouldn't frame this so much as a change to the status quo, as a more
informed implementation of an existing trust model. True, in the past
so-called "enterprise" customers haven't had to disclose, but I don't
think the community has been entirely aware of the extent to which
these Sub-CAs are technically equivalent to "public" CAs, which do
have that requirement.
> Second: Getting an assigned IP address range from an ISP by its very
> nature has implications for the public Internet, since the only reason
> to get such addresses is to communicate with other systems on the
> Internet. If organizations want to engage in purely private internal
> networking then they can and do use private IP address spaces (e.g.,
> 192.168.x.x) with minimal or no inconvenience to themselves.
Getting a signed Sub-CA cert from a root CA by its very nature has
implications for the public Internet, since all Sub-CAs have the power
to sign certs for public web sites. If organizations want to engage
in purely private internal certification, they can and do use private
self-signed CAs. This might require a bit of inconvenience (as you
note) but that inconvenience does not outweigh the public's need for a
reasonable trust model.
> However in the case of CAs, unless I missed something in my time away,
> the concerns here seem to be mainly theoretical -- that bad things could
> potentially happen, not necessarily that they're happening now.
We are dealing with unknown unknowns. Disclosure would mean we'd deal
with known unknowns, which could be more diligently monitored. For
instance, we could build a simple certificate-checking extension that
warns and reports any time a supposedly "private" CA shows up in a
public cert chain. Trust violations of the I've described in the past
are not evident in the current system. A bad actor might do a one-off
forging against a targeted individual. This is highly unlikely to be
detected. So, you're right that we haven't detected abuses so far,
but if they existed we might not be able to detect them.
As a side-note, have we made absolutely clear that our definition of
internal/private/enterprise Sub-CAs does not include companies which
obtain a Sub-CA cert for use on their own domain but visible to the
public internet? For example, let's say Facebook wants a Sub-CA cert
in order to dynamically sign keys for many of its sub-domains. What
category is that in?
Eddy Nigg
> My apologies for not commenting on this and other discussions before now.
Hi Frank....nice to see you around ;-)
>
> Having clarified the terminology (I hope),
The terminology is correct also in my opinion.
And all up to and including your four points.
>
> However third-party private CAs operated by enterprises are by their
> nature private affairs that do not normally entail any impact on the
> public Internet. (They could have an impact, if certificates issued by
> those CAs were to be used on the public internet contrary to whatever
> agreements existed between the CA and the enterprise, but that would
> be an exception to the general rule.) Enterprises could do purely
> private CAs, but they'd incur the additional inconvenience of having
> to distribute and install their own root certificates.
Indeed...and not issued by or chained to a public CA root.
> However in the case of CAs, unless I missed something in my time away,
> the concerns here seem to be mainly theoretical -- that bad things
> could potentially happen, not necessarily that they're happening now.
> Given that, I'm willing to give CAs and their customers a greater
> "presumption of innocence", and allow them to continue the current
> practice of engaging in private business transactions without
> disclosure of customer identities, as long as the activities
> associated with those transactions are private in nature (as they
> would be for third-party private CAs as defined above) and as long as
> we have reasonable assurances that legal and audit frameworks are in
> place to ensure that those activities don't impact typical Mozilla
> users on the public Internet.
>
And the last is probably the key and most important. This is what should
be enforced and required, the disclosure is far less important in my
opinion.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Frank Hecker
I can right now, and come back to the others later, as opposed to trying
to address everything at once.)
On 4/12/10 2:29 PM, Stephen Schultze wrote:
> On Apr 10, 11:49 am, Frank Hecker<hec...@hecker.org> wrote:
>> 4. Third-party private subordinate CAs. In comparison with third-party
>> public subordinate CAs, here IMO the case is less strong for requiring
>> disclosure of the identity of these third parties, since they're not
>> functioning as public CAs and typical Mozilla users would not encounter
>> certificates issued by these CAs in their normal Internal activities.
>
> While this is true, the threat model involves something not normal
> happening: specifically that the end user is undergoing normal
> browsing but a third party do something very abnormal.
True, however you're conditioning your concern primarily on a
hypothetical scenario. Given that, I think it's fair to ask how likely
that scenario actually is, and to what extent it makes more sense to
address it after the fact (via detection and response) as opposed to
before the fact (via prevention).
> Do we have a definition of what an acceptable legal regime consists
> of? We have clear definition of what constitutes an acceptable audit,
> but I'm not aware of the same for the legal regime. Would such a
> definition take into account jursidiction? I would hope so, because
> the effectiveness of any legal regime depends fundamentally on
> jurisdiction and enforceability.
What I really meant was not so much "legal framework" as "contractual
framework". In other words, if CAs are going to engage in private
transactions with enterprises who want to operate third-party private
subordinate CAs, then my first interest is in what types of contractual
provisions are in place to regulate the behavior of the enterprises, and
ensure that they do not go beyond the limits of what they're authorized
to do by the CA.
That contractual framework is in turn embedded in a larger legal and
regulatory framework that determines the types and forms of contracts,
how they can be enforced, and so on. That's where jurisdictional issues,
etc., would come in. But everything starts with the actual contracts, so
IMO that's where we should start as well.
(I have to go to a doctor's appointment now, I'll come back to the other
points later.)
Eddy Nigg
> What I really meant was not so much "legal framework" as "contractual
> framework". In other words, if CAs are going to engage in private
> transactions with enterprises who want to operate third-party private
> subordinate CAs, then my first interest is in what types of
> contractual provisions are in place to regulate the behavior of the
> enterprises, and ensure that they do not go beyond the limits of what
> they're authorized to do by the CA.
>
Contractual requirements is just one form of controls the CA may
implements. I'm far more interested in those controls and how they live
up to the Mozilla CA Policy (e.g. how users are going to be protected).
Especially the validation requirements for server and email
certificates. And finally, if and how those controls are audited.
For example, I believe it's ridiculous to perform site visits by the
auditors at the parent CA and not doing the same at the externally
operated CAs. We ought to receive assurances (through CP disclosure)
that all external installations and controls are audited by the
auditors. And I believe this is where we haven't agreed with Kathleen.
Stephen Schultze
> True, however you're conditioning your concern primarily on a
> hypothetical scenario. Given that, I think it's fair to ask how likely
> that scenario actually is, and to what extent it makes more sense to
> address it after the fact (via detection and response) as opposed to
> before the fact (via prevention).
Fair enough, but you are creating a bit of a Catch-22. It's very hard
to gauge the likeliness of the scenario without studying it
empirically... which itself would require disclosure (because we
currently have no comprehensive list of current "third-party public
CAs"). The other relevant question is, "what is the cost of requiring
disclosure immediately?" As far as I can tell, it's zero cost to the
Mozilla community. It appears that in some cases CAs have signed NDAs
with sub-CAs, but it's unclear why, and it's unclear whether requiring
such disclosure presents any real cost/harm to them. Perhaps you're
interested in this from a rights issue, which I presume you'll address
when you come back and finish the second half of your response. As I
noted above, I find this angle unpersuasive.
> But everything starts with the actual contracts, so
> IMO that's where we should start as well.
Sure, no problem as long as we don't also end there.
Eddy Nigg
> On Apr 13, 8:58 am, Frank Hecker<hec...@hecker.org> wrote:
>
>> True, however you're conditioning your concern primarily on a
>> hypothetical scenario. Given that, I think it's fair to ask how likely
>> that scenario actually is, and to what extent it makes more sense to
>> address it after the fact (via detection and response) as opposed to
>> before the fact (via prevention).
>>
> Fair enough, but you are creating a bit of a Catch-22. It's very hard
> to gauge the likeliness of the scenario without studying it
> empirically... which itself would require disclosure (because we
> currently have no comprehensive list of current "third-party public
> CAs"). The other relevant question is, "what is the cost of requiring
> disclosure immediately?" As far as I can tell, it's zero cost to the
> Mozilla community. It appears that in some cases CAs have signed NDAs
> with sub-CAs, but it's unclear why, and it's unclear whether requiring
> such disclosure presents any real cost/harm to them. Perhaps you're
> interested in this from a rights issue, which I presume you'll address
> when you come back and finish the second half of your response. As I
> noted above, I find this angle unpersuasive.
>
Generally speaking, any information stated in any certificate issued by
the CA is not considered private. It can't be private because this
information is included for the benefit of the third parties relying on
it. Hence I'm not sure what exactly should and can be protected.
I assume that any intermediate CA, any of the four variations Frank
listed previously, must be thoroughly verified and those details are
correctly stated in the intermediate CA certificate.
Further, any CA claiming that details stated in the certificate are not
meant to be used by relying parties basically provide no benefit for
users of Mozilla software and shouldn't be included. But again, this is
only one part of the story.
Stephen Schultze
> Generally speaking, any information stated in any certificate issued by
> the CA is not considered private. It can't be private because this
> information is included for the benefit of the third parties relying on
> it. Hence I'm not sure what exactly should and can be protected.
>
> I assume that any intermediate CA, any of the four variations Frank
> listed previously, must be thoroughly verified and those details are
> correctly stated in the intermediate CA certificate.
>
> Further, any CA claiming that details stated in the certificate are not
> meant to be used by relying parties basically provide no benefit for
> users of Mozilla software and shouldn't be included. But again, this is
> only one part of the story.
I'm not sure I understand the implication of what you described. Can
you spell it out? Does this mean that you believe there is no right
of non-disclosure, or something else?
Eddy Nigg
Personally I don't care about disclosure by CAs, but I'm just stating
the facts. Those are, that content published in the certificates are
deemed to be public and not private. Assuming that intermediate CA
certificates must have correctly identifying details which are obviously
validated, those details can't be private (non-disclosed).
CA which don't validate their intermediate CAs most likely have nothing
lost in NSS either.
Ben Wilson
Reasonable contractual controls between third-party public/private
subordinate CAs and public root CAs (that provide legal and audit
frameworks) can adequately protect the Mozilla user community.
"Reasonableness" of legal and audit burdens is a call for open debate
between those who provide the CA services and those who are concerned for
the consumers of those services. Sensitive portions of agreements between
public root CAs and their enterprise customers can be redacted. Also, a
certificate policy could require that CAs include a provision in their CPS
that, "all agreements with subordinate CAs include a provision substantially
similar to the following: x, y and z." Again, x, y and z would need to be
adopted after careful consideration of the costs and benefits involved.
Benjamin T. Wilson, JD CISSP
General Counsel and SVP Industry Relations
DigiCert, Inc.
Online: www.DigiCert.com
Email: b...@digicert.com
Toll Free: 1-800-896-7973 (US & Canada)
Direct: 1-801-701-9678
Fax: 1-866-842-0223 (Toll Free if calling from the US or Canada)
--
Regards
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Frank Hecker
> Generally speaking, any information stated in any certificate issued by
> the CA is not considered private. It can't be private because this
> information is included for the benefit of the third parties relying on
> it. Hence I'm not sure what exactly should and can be protected.
A hopefully quick comment on this:
Unless I'm missing something, what's at issue is whether or not to
require CAs to disclose their full customer lists for those customers
operating third-party private subordinate CAs. In other words, if a
customer Acme Inc wishes to contract with the CA TrustUS Corp to be
authorized to operate a third-party private subordinate CA under the
TrustUS root, e.g., for use by Acme's employees and intranet
applications, then under the proposal advanced previously TrustUS would
be required to publicly disclose that Acme was a customer, as opposed to
Acme and TrustUS being able to treat this as a private business
relationship.
Now, assume the business relationship between Acme and TrustUS were not
disclosed, and also assume that the contract between Acme and the CA
restricts certificate issuance to Acme's own employees, contractors, and
other affiliated entities. If Acme indeed uses its subordinate CA
capability only to issue certificates for private use, then none of
these certificates will show up on he public Internet, and no one
outside of TrustUS, Acme and (possibly) Acme's business partners will
ever encounter one of these certs or know of their existence. There will
be no impact on typical Mozilla users.
However, suppose instead that Acme decides to violate its contract with
TrustUS and use its subordinate CA capability to issue certificates to
others, for use on the public Internet in contexts where they might
impact typical Mozilla users. For example, Acme might issue a
certificate to Foobar Corp to run a public ecommerce site. If Acme does
this then they are in effect disclosing their ability to act as a CA,
since they'll be listed as the issuer for Foobar's TLS cert, and also
disclosing their relationship with TrustUS, since the intermediate CA
certificate issued by TrustUS to Acme would have to be part of the cert
chain presented to browsers by Foobar's servers in order for the whole
scheme to work.
So the whole thing is like a self-enforcing protocol: If a CA and a
third-party operating a private subordinate CA wish to establish and
maintain a confidential business relationship, then they both have every
incentive to conduct themselves such that the intermediate CA
certificate and end entity certificates issued as a result of that
relationship never get used in transactions where they might be
encountered by typical Mozilla users. The CA has an incentive to create
whatever contractual and technical restrictions it can to prevent the
third-party from acting as a public CA, and the third-party has an
incentive to abide by those restrictions. Otherwise they both lose the
confidentiality they ostensibly desired.
I might add that this applies doubly to cases where the third party
might be tempted to use its CA capability for malicious purposes, for
example issuing a TLS certificate to a malicious individual or
organization to help them mount a MITM attack. If this occurs then there
will exist digitally-signed evidence of the third party's involvement
(i.e., the end entity certificate) and also of the CA's (i.e., the
intermedia CA certificate). So again the third party has an incentive to
refrain from such behavior and to institute sufficient controls to
prevent its happening, and the CA has an incentive to prohibit such
behavior before the fact and punish it after the fact.
Stephen Schultze
> There will be no impact on typical Mozilla users.
What I hear you saying is that there is no potential benefit to
Mozilla users, but if the trust is violated there is potential harm.
If that's the case, why wouldn't we want to curtail the practice of
undisclosed private Sub-CAs? It's all upside from the perspective of
the users.
> If Acme does
> this then they are in effect disclosing their ability to act as a CA
Only after the fact, to users that have already visited a site that
makes use of an Acme-issued cert, and only silently without warning to
the user.
> So the whole thing is like a self-enforcing protocol: If a CA and a
> third-party operating a private subordinate CA wish to establish and
> maintain a confidential business relationship, then they both have every
> incentive to conduct themselves such that the intermediate CA
> certificate and end entity certificates issued as a result of that
> relationship never get used in transactions where they might be
> encountered by typical Mozilla users.
A third-party that wishes to use its delegated power for evil has
every incentive to avoid disclosure of its CA cert to the general
public. Obtaining it as merely a "private" cert, perhaps even backed
up by an NDA, serves that purpose.
> The CA has an incentive to create
> whatever contractual and technical restrictions it can to prevent the
> third-party from acting as a public CA, and the third-party has an
> incentive to abide by those restrictions. Otherwise they both lose the
> confidentiality they ostensibly desired.
You are assuming well-intentioned actors that honestly wish to
establish private business transactions, which is not what the threat
model assumes.
> I might add that this applies doubly to cases where the third party
> might be tempted to use its CA capability for malicious purposes, for
> example issuing a TLS certificate to a malicious individual or
> organization to help them mount a MITM attack. If this occurs then there
> will exist digitally-signed evidence of the third party's involvement
> (i.e., the end entity certificate) and also of the CA's (i.e., the
> intermedia CA certificate). So again the third party has an incentive to
> refrain from such behavior and to institute sufficient controls to
> prevent its happening, and the CA has an incentive to prohibit such
> behavior before the fact and punish it after the fact.
Why would an evil third-party have such incentives? I grant that they
don't want to get caught, and it certainly is nice that if you happen
to catch an evil cert it is easy to prove after the fact that it was
issued with malice, but I don't see how this checks the action. The
risk of getting caught is still fairly low if such a thing is done in
targeted fashion. These incentives are even less of a factor in the
case of state-induced bad certs.
Christopher Soghoian
I've been lurking on this group for a while, and it seems like a good
time to chime in.
On Apr 13, 2:12 pm, Frank Hecker <hec...@hecker.org> wrote:
> Unless I'm missing something, what's at issue is whether or not to
> require CAs to disclose their full customer lists for those customers
> operating third-party private subordinate CAs. In other words, if a
> customer Acme Inc wishes to contract with the CA TrustUS Corp to be
> authorized to operate a third-party private subordinate CA under the
> TrustUS root, e.g., for use by Acme's employees and intranet
> applications, then under the proposal advanced previously TrustUS would
> be required to publicly disclose that Acme was a customer, as opposed to
> Acme and TrustUS being able to treat this as a private business
> relationship.
Essentially, we are talking about the "Third-party private (or
enterprise) subordinate CAs" situation that you described in your
first email on this thread.
The position that you are putting forth is that because the private
entity (which you call Acme Inc in your example) has promised that it
will only use the certificates it creates for internal purposes, you
have some sympathy to the argument that there is no need to make
public Acme's name (and the rest of TrustUS Corp's other third party
private subordinate CA clients). You have also argued that while these
firms could, at a technological level, perform an effective man in the
middle attack against millions of users around the web, that they have
economic and legal incentives not to do so.
You have also suggested that since we have no evidence that nefarious
things are happening, that it is not worth worrying about theoretical
worst case scenario threats.
Steve Schultze and others seem to be arguing that because Acme (and
every other subordinate CA) has the technical capability to do nasty
things to millions of Mozilla users, that _at the very least_, Mozilla
should be able to compile a list of every entity with a subordinate CA
cert.
The problem here, as I see it, is that the current technical system
provides the browser vendors with no means to technically limit the
capability of so called Third-party private (or enterprise)
subordinate CAs to only use their certificate issuing powers for
internal uses. We are, as a result, all left trusting a number of
entities whose identities we don't even know.
Rather than try to pressure the Root CAs to reveal their confidential,
NDA protected list of clients to whom they have bestowed subordinate
CA powers, surely it would make more sense to fix the technical trust
issue that plagues this problem -- namely, locking down this class
(Third-party private) of subordinate certificates so that they really
can only be used for private, internal uses.
This related thread (http://groups.google.com/group/
mozilla.dev.tech.crypto/browse_thread/thread/c0edf8ec534537bf#), which
is just a week or two old, seems to directly address the issue.
I suggest that our energies would be far better spent limiting the
technical capabilities of these subordinate CAs, to the specific
domain/subdomain that they control. If we can get that fix in place,
then most of us won't care how many subordinate CAs are out there,
since their ability to do nefarious things will be quite limited.
Cheers
Chris
(These opinions are my own)
Kurt Seifried
> third-party operating a private subordinate CA wish to establish and
> maintain a confidential business relationship, then they both have every
> incentive to conduct themselves such that the intermediate CA certificate
> and end entity certificates issued as a result of that relationship never
> get used in transactions where they might be encountered by typical Mozilla
> users. The CA has an incentive to create whatever contractual and technical
That is assuming a user notices that the certificate is signed by the
intermediary and not the root. They would not notice this unless they
verify the certificate chain by examining the certificate, so
realistically this is unlikely to be noticed (since it presents as a
properly signed and trusted certificate). Which I think is sort of why
a lot of us are freaked out about this mystery sub CAs.
-Kurt
Frank Hecker
> That is assuming a user notices that the certificate is signed by the
> intermediary and not the root. They would not notice this unless they
> verify the certificate chain by examining the certificate, so
> realistically this is unlikely to be noticed (since it presents as a
> properly signed and trusted certificate). Which I think is sort of why
> a lot of us are freaked out about this mystery sub CAs.
Actually I'm not assuming that (typical) users notice anything at all; I
certainly don't assume that they'll be checking certificate chains
andnoticing who issued what cert. In practice any checking of certs is
likely to be done either by security experts doing investigations by
hand, or by automated systems.
(For example, there are companies like Netcraft doing collection of web
server certificates used on the public web, and I think Johnathan
Nightingale of Mozilla did something like this as well. There's also the
idea of instrumenting Firefox and other browsers to detect and report
certificates that appear to be dodgy in some way, for example showing up
with a different CA than the last time the user went to the site.)
My point was simply that a third-party private subordinate CA that
decided to violate any contractual restrictions on acting as a public CA
(whether with good intentions or ill) was vulnerable to leaving behind
clear and definitive public evidence of its misbehavior, and it's not
clear to me why in practice they would risk doing so.
Stephen Schultze
> Actually I'm not assuming that (typical) users notice anything at all; I
> certainly don't assume that they'll be checking certificate chains
> andnoticing who issued what cert. In practice any checking of certs is
> likely to be done either by security experts doing investigations by
> hand, or by automated systems.
But the threat model assumes that security experts and automated
systems aren't the targets of exploits and are therefore unlikely to
detect them.
> There's also the
> idea of instrumenting Firefox and other browsers to detect and report
> certificates that appear to be dodgy in some way, for example showing up
> with a different CA than the last time the user went to the site.
That is not a present-day reality, and the solutions are inevitably
more limited than solutions that work with the set of information
provided by full disclosure.
> My point was simply that a third-party private subordinate CA that
> decided to violate any contractual restrictions on acting as a public CA
> (whether with good intentions or ill) was vulnerable to leaving behind
> clear and definitive public evidence of its misbehavior, and it's not
> clear to me why in practice they would risk doing so.
They would do so because:
1. They are unlikely to be caught
2. The consequence of being caught is only the ability to commit
future exploits (but in a poorly disclosed system, even this is not
certain)
and/or
3. They are compelled to do so, thus they aren't doing this cost/
benefit analysis at all
Eddy Nigg
> On 4/13/10 2:58 PM, Eddy Nigg wrote:
>> Generally speaking, any information stated in any certificate issued by
>> the CA is not considered private. It can't be private because this
>> information is included for the benefit of the third parties relying on
>> it. Hence I'm not sure what exactly should and can be protected.
>
> A hopefully quick comment on this:
>
> Unless I'm missing something, what's at issue is whether or not to
> require CAs to disclose their full customer lists for those customers
> operating third-party private subordinate CAs.
I think it's less a concern or specific interest in which customers a CA
may have, than the concern what exactly happens with them. There are
probably two sides of the coin...
> In other words, if a customer Acme Inc wishes to contract with the CA
> TrustUS Corp to be authorized to operate a third-party private
> subordinate CA under the TrustUS root, e.g., for use by Acme's
> employees and intranet applications, then under the proposal advanced
> previously TrustUS would be required to publicly disclose that Acme
> was a customer, as opposed to Acme and TrustUS being able to treat
> this as a private business relationship.
Well, there might be some other problems with "intranet" and I've
blogged about it here: http://blog.startcom.org/?p=221
We ought to consider the various practices in this respect and get clear
about what exactly the Mozilla CA Policy calls for and where public CAs
don't benefit "internal" enterprise scenarios. Kathleen already sent out
a message to the CAs regarding particular practices, so far I haven't
heard about any changes in practice.
>
> Now, assume the business relationship between Acme and TrustUS were
> not disclosed, and also assume that the contract between Acme and the
> CA restricts certificate issuance to Acme's own employees,
> contractors, and other affiliated entities. If Acme indeed uses its
> subordinate CA capability only to issue certificates for private use,
> then none of these certificates will show up on he public Internet,
> and no one outside of TrustUS, Acme and (possibly) Acme's business
> partners will ever encounter one of these certs or know of their
> existence. There will be no impact on typical Mozilla users.
And then they shouldn't be part of the public CAs either I'd say. There
is no benefit for a typical relying party. The CAs providing such PKI
services should perhaps use a root which isn't trusted by the browsers.
>
> However, suppose instead that Acme decides to violate its contract
> with TrustUS and use its subordinate CA capability to issue
> certificates to others, for use on the public Internet in contexts
> where they might impact typical Mozilla users.
Assuming that this would be a violation of the CAs requirements, however
I haven't seen such disclosure in the CP/CPS, lets say at the CA where
this thread started. They are not restricted in this respect, so I
believe your assumptions aren't entirely correct.
> So the whole thing is like a self-enforcing protocol: If a CA and a
> third-party operating a private subordinate CA wish to establish and
> maintain a confidential business relationship, then they both have
> every incentive to conduct themselves such that the intermediate CA
> certificate and end entity certificates issued as a result of that
> relationship never get used in transactions where they might be
> encountered by typical Mozilla users. The CA has an incentive to
> create whatever contractual and technical restrictions it can to
> prevent the third-party from acting as a public CA, and the
> third-party has an incentive to abide by those restrictions. Otherwise
> they both lose the confidentiality they ostensibly desired.
I don't buy into this, basically because no such limitations have been
disclosed. The CP/CPS would have to define that specifically. This isn't
the case and perhaps that's why there is some opposition. My interest is
in auditing those sub-ordinate external to the CA entities running CAs.
Others apparently want full disclosure about who they are.
>
> I might add that this applies doubly to cases where the third party
> might be tempted to use its CA capability for malicious purposes, for
> example issuing a TLS certificate to a malicious individual or
> organization to help them mount a MITM attack.
I don't believe we have to go that far. But what about the site and key
security? Where they audited? How to prevent unintentional misuse?
Matt McCutchen
of your points.
--
Matt
Matt McCutchen
> the rights of organizations and individuals to engage in
> private business transactions under conditions of confidentiality
That is nonsense. Issuing an intermediate certificate signed by a
public root is an act that has consequences for the security of the
entire public CA system. It can hardly be entitled to
confidentiality.
Here's a counterproposal:
Every entity that is technically capable of issuing certificates that
Mozilla products will accept for domains the entity does not own
should be subject to the same standards of (1) audit, to satisfy
Mozilla that it is trustworthy enough that the benefits of enabling it
by default outweigh the risks, and (2) disclosure, so that individual
users can make an informed decision of whether they personally trust
the entity, as it has been stated repeatedly in this newsgroup that it
is their duty to do.
--
Matt
Eddy Nigg
> Every entity that is technically capable of issuing certificates that
> Mozilla products will accept for domains the entity does not own
> should be subject to the same standards of (1) audit, to satisfy
> Mozilla that it is trustworthy enough that the benefits of enabling it
> by default outweigh the risks, and (2) disclosure, so that individual
> users can make an informed decision of whether they personally trust
> the entity, as it has been stated repeatedly in this newsgroup that it
> is their duty to do.
>
Amen to that, well said Mr. McCutchen!
David E. Ross
> On 04/18/2010 08:57 PM, Matt McCutchen:
>> Every entity that is technically capable of issuing certificates that
>> Mozilla products will accept for domains the entity does not own
>> should be subject to the same standards of (1) audit, to satisfy
>> Mozilla that it is trustworthy enough that the benefits of enabling it
>> by default outweigh the risks, and (2) disclosure, so that individual
>> users can make an informed decision of whether they personally trust
>> the entity, as it has been stated repeatedly in this newsgroup that it
>> is their duty to do.
>>
>
> Amen to that, well said Mr. McCutchen!
>
When a root certificate authority (CA) signs an intermediate certificate
for a third-party private (enterprise) subordinate CA -- for an outside
entity that supposedly will use the intermediate certificate only for
its own intranet use -- the root CA should use a root certificate that
is NOT one of those contained in Mozilla's NSS database. The outside
entity can either install the intermediate certificate in its intranet
or download the root certificate to install in the intranet.
Thus, Mozilla should not consider any root certificate that is used by
intranets. CAs should separate their root certificates between Internet
(public) use and intranet (private) use and only submit requests to
include the former in the NSS database.
Stephen Schultze
> When a root certificate authority (CA) signs an intermediate certificate
> for a third-party private (enterprise) subordinate CA -- for an outside
> entity that supposedly will use the intermediate certificate only for
> its own intranet use -- the root CA should use a root certificate that
> is NOT one of those contained in Mozilla's NSS database. The outside
> entity can either install the intermediate certificate in its intranet
> or download the root certificate to install in the intranet.
>
> Thus, Mozilla should not consider any root certificate that is used by
> intranets. CAs should separate their root certificates between Internet
> (public) use and intranet (private) use and only submit requests to
> include the former in the NSS database.
As much as I would like this, it largely defeats the purpose of
chaining to one of these CAs. The whole reason these "buy your own
sub-root" products exist is because purchasing third-parties want to
be automatically trusted by the browser. What you propose removes
that. However, it occurs to me that it would be interesting if there
were some mechanism for nevertheless segregating the operations as you
suggest. If those subordinate-CA-granting roots could be included in
Mozilla but flagged in a special way, then users could be warned that
a given site chains to them (probably via a Sub-CA). Now all we need
to do is invent the standard, implement it in NSS, and get the CAs to
cooperate.
In the interim, I am in favor of Matt's 2-part proposal.
David E. Ross
In an intranet, it should not be difficult to provide and even install
root certificates that are not in the publicly-distributed versions of
browsers.
Stephen Schultze
> In an intranet, it should not be difficult to provide and even install
> root certificates that are not in the publicly-distributed versions of
> browsers.
Agreed, that's why I said above, "If organizations want to engage in
purely private internal certification, they can and do use private
self-signed CAs. This might require a bit of inconvenience (as you
note) but that inconvenience does not outweigh the public's need for a
reasonable trust model."
However, the fact is the at the business model exists today. Until we
can get some sort of universal compliance with your suggestion
(something I would welcome but see unlikely to happen) I suggest that
the least these entities can do is follow Matt's proposal of audit and
disclosure.
Stephen Schultze
https://bugzilla.mozilla.org/show_bug.cgi?id=561024
Bug 561024 - Require disclosure of the identities of external private
sub-CAs
Stephen Schultze
Matt and I have been discussing whether or not the Globalsign
inclusion request should be subject to any of conclusions here about
the external private Sub-CA disclosure question, and he has appealed
to your authority:
http://groups.google.com/group/mozilla.dev.security.policy/msg/f989cad3413ec645
Do you have an opinion on the matter?
Frank Hecker
On 4/12/10 2:29 PM, Stephen Schultze wrote:
> On Apr 10, 11:49 am, Frank Hecker<hec...@hecker.org> wrote:
<snip>
>> So the bottom line is that as a matter of policy I don't think we need
>> to or should be requiring CA organization to disclose the identities of
>> their enterprise customers operating third-party private subordinate
>> CAs.
>
> There are two basic problems with this approach:
> 1. There is no way to know whether "enterprise customers operating
> third-party private subordinate CAs" will continue to be "enterprise
> customers operating third-party private subordinate CAs" unless
> there's some major improvement in accountability and enforceability.
That's why we're raising the issue of having root CAs have an
appropriate audit and contractual framework that covers third-party
subordinate CAs, whether public or private. I don't think anyone here
seriously disagrees with that. The discussion here is really about
whether or not we need to in addition mandate disclosure of all
third-party private subordinate CAs operating under that framework.
> Even then, whatever solution you come up with will probably be outside
> of the technical domain, so there's nothing in the core cryptography
> enforcing this.
There are technical ways to address the issue of restricting the actions
of third-party subordinate CAs (e.g., domain name constraints), but IIRC
from earlier comments they are neither implemented nor implementable for
the general case we're concerned with. As I understand it there are also
technical ways to detect misbehavior on the part of third-party
subordinate CAs after the fact (e.g., distributed checking of issued
server certs encountered on the public Internet), and I think those are
worth exploring.
However you are correct that we do rely on non-technical means for a lot
of the stuff we do with respect to CAs. I don't necessarily see that as
a bad thing, because root and subordinate CAs are embedded in a
legal/contractual/economic framework that IMO makes it less likely that
misbehavior will occur in practice.
> 2. No amount of audit or legal liability resolves the dilemma that the
> Mozilla CA security model ultimately defers to user control, and users
> cannot control what they do not know.
I disagree with the first part of this statement. The Mozilla CA policy
is concerned with typical Mozilla users, and typical Mozilla users are
relying on Mozilla to make reasonable decisions on their behalf in terms
of the default security configuration of Firefox, Thunderbird, and other
products. If Mozilla were really deferring to user control then it
wouldn't preload any root CA certificates at all.
Now, as to the second part of your statement: Whether we're making
decisions for others or for ourselves, there are always things we don't
know. For example, we don't have total visibility into the operations of
CAs, root or otherwise, and therefore we rely on audits and similar
mechanisms. So I don't find your argument above to be a compelling
general argument that automatically forces a particular answer to the
question of disclosing identities of third-party subordinate CAs.
> I am not persuaded that this gets down to a question of competing
> rights. Companies wishing to do engage in root delegation are asking
> everybody to do them a favor. They haven't found a technically secure
> way of doing this process, so they are asking us to trust them and
> their business partners not to do the wrong thing. The least we can
> do is ask to know who those entities are.
I will (partially) concede the point on the "rights" question. These
third-party private subordinate CAs are primarily if not exclusively run
by large enterprises. I don't believe corporations have rights
equivalent to human persons, and so I don't think there's an exact
analogy with any personal right to privacy.
However... as a matter of practice in most advanced economies and
democracies corporations are generally free to enter into private
business arrangements, with government-mandated disclosure of such
arrangements requiring some clear demonstration that the public interest
requires it. This is turn typically depends on both the nature and
severity of the problem to be addressed, both in isolation and in
comparison with other problems which government regulators might be
called upon to address.
I think this analogy is more applicable in this case. CAs historically
have had these private business arrangements with third-party private
subordinate CAs, and neither we nor any of the other browser vendors
have objected. I understand the nature of the potential problem people
are concerned about, but unless I'm mistaken there's no clear evidence
that the problem has been or is currently a problem in practice -- and I
noted previously I don't see any intrinsic motivation for third-party
private subordinates to engage in the hypothesized misbehavior, and some
motivation for them not to do so.
Apart from any burden a disclosure policy would have on CAs, there would
be a burden on Mozilla to implement and enforce the policy across the
board, not just on CAs newly applying for inclusion, but also for CAs
already included (in the interest of fairness). Given that any time
dealing with this policy implementation is time not spent pursuing other
policy improvements, and given the apparent lack of any real problems up
to now, I can't justify our adopting this disclosure policy at this
time. I'd rather we adopt the general requirement that CAs have a
reasonable audit and contractual framework in place for third-party
private subordinates, and revisit the disclosure issue later if there's
evidence of a pattern of problems in this area.
> We are dealing with unknown unknowns. Disclosure would mean we'd deal
> with known unknowns, which could be more diligently monitored. For
> instance, we could build a simple certificate-checking extension that
> warns and reports any time a supposedly "private" CA shows up in a
> public cert chain.
I think an extension of this type is worth thinking about, though I
don't think it needs to be tied to the exact details of the disclosure
policy, and doesn't necessarily have to have a concept of "public" vs.
"private" CA. The extension could just report the cert chain back to a
central system, which could then build up a database and run analyses
against it. Sort of like the Herdict idea applied to CAs, and like
Herdict it could be useful even if only a relatively small fraction of
people install and run it.
> As a side-note, have we made absolutely clear that our definition of
> internal/private/enterprise Sub-CAs does not include companies which
> obtain a Sub-CA cert for use on their own domain but visible to the
> public internet? For example, let's say Facebook wants a Sub-CA cert
> in order to dynamically sign keys for many of its sub-domains. What
> category is that in?
A good question. It's sort of a category in-between: not a full "public
CA" because (assuming normal operation) there's no intent to offer
certificates to other entities, but as with a public CA there is an
intent that typical users of the public Internet would encounter such
certificates in normal operation. I can't imagine there's any
expectation of confidentiality here in terms of concealing the
third-party subordinate's having a business relationship with the root
CA -- it's right there for anyone to see who connects to the site. So it
might be worth asking (root) CAs if they have third-party subordinates
of this type and (if so) who they are.
Stephen Schultze
On Apr 24, 7:33 pm, Frank Hecker <hec...@hecker.org> wrote:
> However you are correct that we do rely on non-technical means for a lot
> of the stuff we do with respect to CAs. I don't necessarily see that as
> a bad thing, because root and subordinate CAs are embedded in a
> legal/contractual/economic framework that IMO makes it less likely that
> misbehavior will occur in practice.
To be sure, the legal/contractual/economic framework that you describe
makes it less likely. The question is whether it makes it unlikely to
the point that the system is reasonably trustworthy. I don't think
there's any argument that disclosure of private Sub-CAs would, in any
case, make the system more trustworthy.
> On 4/12/10 2:29 PM, Stephen Schultze wrote:
> > 2. No amount of audit or legal liability resolves the dilemma that the
> > Mozilla CA security model ultimately defers to user control, and users
> > cannot control what they do not know.
>
> I disagree with the first part of this statement. The Mozilla CA policy
> is concerned with typical Mozilla users, and typical Mozilla users are
> relying on Mozilla to make reasonable decisions on their behalf in terms
> of the default security configuration of Firefox, Thunderbird, and other
> products. If Mozilla were really deferring to user control then it
> wouldn't preload any root CA certificates at all.
I don't think our statements are at odds. I agree that the policy is
tailored to provide reasonable *default* settings for typical users.
However, the policy assumes that users can tailor those settings to
those particular needs rather than make an all-or-nothing decision on
root CAs. Kathleen's answer to the CNNIC issue made clear that in the
context of the CA approval process Mozilla assumes that users have
such flexibility:
Without disclosure of all Sub-CAs (private or public) users do not
have the ability to tailor their CA roots based on their unique trust
of different entities.
> However... as a matter of practice in most advanced economies and
> democracies corporations are generally free to enter into private
> business arrangements, with government-mandated disclosure of such
> arrangements requiring some clear demonstration that the public interest
> requires it. This is turn typically depends on both the nature and
> severity of the problem to be addressed, both in isolation and in
> comparison with other problems which government regulators might be
> called upon to address.
I have some trouble with this analogy, both because we aren't talking
about government entities and because there's nothing inherent about
the proposed disclosure requirements that limits their ability to
enter into private business arrangements. The only thing it affects
is whether or not the public at large blindly trusts that relationship
by default.
> I think this analogy is more applicable in this case. CAs historically
> have had these private business arrangements with third-party private
> subordinate CAs, and neither we nor any of the other browser vendors
> have objected. I understand the nature of the potential problem people
> are concerned about, but unless I'm mistaken there's no clear evidence
> that the problem has been or is currently a problem in practice -- and I
> noted previously I don't see any intrinsic motivation for third-party
> private subordinates to engage in the hypothesized misbehavior, and some
> motivation for them not to do so.
Are you implying that we should defer debate on the merits to the
status quo?
As I noted earlier, evidence of abuse is unlikely to have been
detected, so it is an unknown unknown. I also explained why, despite
your description of the incentives, these third-parties would
nevertheless be motivated to engage in this behavior:
I don't think it's fair to characterize it as a "potential problem"
when there is clearly a hole in the trust model. The question is
whether or not this actual problem is likely to be exploited.
> Apart from any burden a disclosure policy would have on CAs, there would
> be a burden on Mozilla to implement and enforce the policy across the
> board, not just on CAs newly applying for inclusion, but also for CAs
> already included (in the interest of fairness). Given that any time
> dealing with this policy implementation is time not spent pursuing other
> policy improvements, and given the apparent lack of any real problems up
> to now, I can't justify our adopting this disclosure policy at this
> time. I'd rather we adopt the general requirement that CAs have a
> reasonable audit and contractual framework in place for third-party
> private subordinates, and revisit the disclosure issue later if there's
> evidence of a pattern of problems in this area.
But what is the significant additional burden to Mozilla, given that
the approval process already requires disclosure of third-party
_public_ Sub-CAs? If anything, the proposed change eliminates some of
the confusion over how a Sub-CA is categorized and the ambiguity over
whether it needs to be disclosed (hopefully eliminating some of the
back-and-forth required to clear up such confusion).
> I think an extension of this type is worth thinking about, though I
> don't think it needs to be tied to the exact details of the disclosure
> policy, and doesn't necessarily have to have a concept of "public" vs.
> "private" CA. The extension could just report the cert chain back to a
> central system, which could then build up a database and run analyses
> against it. Sort of like the Herdict idea applied to CAs, and like
> Herdict it could be useful even if only a relatively small fraction of
> people install and run it.
Perhaps, but you are describing an imperfect way of patching around
something which could be done far better using complete information.
Varga Viktor
> From: dev-security-policy-bounces+varga_v=netlo...@lists.mozilla.org
> [mailto:dev-security-policy-bounces+varga_v=netlo...@lists.mozilla.org] On
> Behalf Of Frank Hecker
> Sent: Saturday, April 10, 2010 5:50 PM
> To: dev-secur...@lists.mozilla.org
> Subject: Terminology and policy in relation to subordinate CAs
> 4. Third-party private (or enterprise) subordinate CAs. This is the
> typical case where a commercial CAs has enterprise customers who want to
> operate their own CAs for internal purposes, e.g., to issue SSL server
> certificates to systems running intranet applications, to issue
> individual SSL client certificates for employees or contractors for use
> in authenticating to such applications, and so on.
[...]
> 4. Third-party private subordinate CAs. In comparison with third-party
> public subordinate CAs, here IMO the case is less strong for requiring
> disclosure of the identity of these third parties, since they're not
> functioning as public CAs and typical Mozilla users would not encounter
> certificates issued by these CAs in their normal Internet activities.
> However we want some assurance that third-party private CAs are not
> going to start functioning as public CAs, so IMO there's a strong case
> for requiring that the third parties be under an acceptable legal
> framework and audit regime, just as we'd require for third-party public
> subordinate CAs.
I have read the whole thread, but i stopped at the first letter.
Don't forget, that those enterprises mostly get subCA because they want to give SMIME signer certificates for their users and/or partners, to make the communication more legal between them.
Those signer certificates can sign mails, and a sigend mail can landed in an external mail client.
Its not an option for an organization, to create, follow the laiglsation, audit yearly, physical protection of those servers, etc, to have more easily some SSL certificates.
If it wants more than one certificate, maybe gets a wildcard SSL for this purpose, much more cheaper.
And you forgot the 5. case too. :) ( The hungarian way. :) )
In Hungary there was the CA market established, when the goverment found out, that it needs another root.
They created a root, and requested from CAs already on the market, if they would like to issue some certificate for govermental use, they should generate new keypair, and a subCA was issued from them.
No steps were done to put the govermental root into the Firefox, so EE certs from those subCAs are uncomfortable for users.
Will be possible to include only the subCA too? :Dű
Üdvözlettel/Regards,
Varga Viktor
Üzemeltetési és Vevőszolgálati Vezető
IT Service and Customers Service Executive
Netlock Kft.
_______________________________________________________________________
Ezt az e-mailt virus- es SPAM-szuresnek vetettuk ala a filter:mail MessageLabs rendszerrel. Tovabbi informacio: http://www.filtermax.hu
This email has been scanned for viruses and SPAM by the filter:mail MessageLabs System. More information: http://www.filtermax.hu ________________________________________________________________________________________
Steve Schultze
> On 5/26/10 8:17 PM, David E. Ross wrote:
>> On 5/26/10 11:26 AM, Kathleen Wilson wrote:
>>> https://wiki.mozilla.org/CA:SubordinateCA_checklist
>>
>> The page should suggest that root certificate authorities use a separate
>> and distinct root to sign third-party private subordinate certificates
>> and that such roots not be submitted for inclusion in the NSS database.
>
> Added, see "Recommendation" just after the list of combinations.
>
> Thanks,
> Kathleen
You guys do realize that as a "recommendation" nobody will ever do this,
right? The whole reason that "third-party public subordinate CAs" exist
is that a trusted root can resell its trust to third parties. If the
root signs a Sub-CA cert for a third-party but that root cert is not
trusted, it's no better for the third-party than a self-signed CA cert.
Steve Schultze
s/public/private/
Kathleen Wilson
>
> I have updated the Subordinate CA Checklist wiki page to reflect the
> suggested terminology and other items that have been raised in this
> discussion.
>
> https://wiki.mozilla.org/CA:SubordinateCA_checklist
>
> I will appreciate your feedback on the updated page.
>
> Kathleen
>
>
I just made further updates to
https://wiki.mozilla.org/CA:SubordinateCA_checklist#Terminology
under "Third-party private (or enterprise) subordinate CAs" I added two
sub-bullet points:
* In Bug #394919 NSS is being updated to apply dNSName constraints to
the CN, in addition to the SANs.
* We plan to update our policy to require CAs to constrain third-party
private (or enterprise) subordinate CAs so they can only issue
certificates within a specified domain. See section 4.2.1.10 of RFC 5280.
This is draft text, so feedback will be appreciated.
Kathleen