Third-Party Private SubCAs
Kathleen Wilson
Policy, I would like to have a focused discussion on third-party private
(enterprise) subordinate CAs. This item is the last bullet point in
https://wiki.mozilla.org/CA:CertPolicyUpdates#RAs_and_Subordinate_CAs
Suggestions that have been offered regarding third-party private
(enterprise) subordinate CAs are:
1) Don’t allow such subCAs to chain up to roots included in NSS.
2) Require CAs to provide a list of all of their subordinate CAs.
3) Require CAs to constrain such subCAs so they can only issue certs
within a specified domain.
Are there any other suggestions that should be considered for
third-party private (enterprise) subordinate CAs?
I’ve been thinking about #1, and wondering if it is feasible and
enforceable in the foreseeable future. I’m not convinced that it is. (I
think it's the direction that we want to go, and we should encourage CAs
to move to this model.)
That leaves us with #2 and #3. I believe that regardless of the decision
about #2, we must figure out #3.
Therefore, I think it would be most worthwhile to focus this discussion
on identifying how to constrain third-party private subCAs (both
technical and contractual), and how to enforce those constraints. What
RFEs need to be submitted and/or implemented? What requirements should
be added to the Mozilla CA Certificate Policy? What other tools could be
used?
I look forward to your constructive contributions to this discussion. I
request that everyone focus on the ideas and concepts, and not add
personal comments that refer to a person’s competence or degrades a
person’s opinion. Please do not discourage any of our participants from
sharing their opinions.
Kathleen
PS: I have updated https://wiki.mozilla.org/CA:Glossary to include a
section about Registration Authority Terminology, and a section about
Subordinate CA Terminology.
Steve Schultze
> Suggestions that have been offered regarding third-party private
> (enterprise) subordinate CAs are:
>
> 1) Don’t allow such subCAs to chain up to roots included in NSS.
>
> 2) Require CAs to provide a list of all of their subordinate CAs.
>
> 3) Require CAs to constrain such subCAs so they can only issue certs
> within a specified domain.
>
> Are there any other suggestions that should be considered for
> third-party private (enterprise) subordinate CAs?
>
> I’ve been thinking about #1, and wondering if it is feasible and
> enforceable in the foreseeable future. I’m not convinced that it is. (I
> think it's the direction that we want to go, and we should encourage CAs
> to move to this model.)
Can you describe your concerns? I would imagine that it is easily
enforceable because NSS can simply refuse to accept any SubCA not on the
disclosed list. That of course assumes #2.
> That leaves us with #2 and #3. I believe that regardless of the decision
> about #2, we must figure out #3.
#1 and #2 are fairly straightforward, assuming we think that disclosure
is important.
> Therefore, I think it would be most worthwhile to focus this discussion
> on identifying how to constrain third-party private subCAs (both
> technical and contractual), and how to enforce those constraints. What
> RFEs need to be submitted and/or implemented? What requirements should
> be added to the Mozilla CA Certificate Policy? What other tools could be
> used?
Don't we just have to wait until the patch in bug 394919 makes its way
into shipped trunk via libPKIX? The notes on that bug say this will
happen for FF5, so... a couple years?
https://bugzilla.mozilla.org/show_bug.cgi?id=394919
Ian G
> To continue with our discussions for updating the Mozilla CA Certificate
> Policy, I would like to have a focused discussion on third-party private
> (enterprise) subordinate CAs. This item is the last bullet point in
>
> https://wiki.mozilla.org/CA:CertPolicyUpdates#RAs_and_Subordinate_CAs
>
> (enterprise) subordinate CAs are:
>
> 1) Don’t allow such subCAs to chain up to roots included in NSS.
>
> 2) Require CAs to provide a list of all of their subordinate CAs.
>
> 3) Require CAs to constrain such subCAs so they can only issue certs
> within a specified domain.
> Are there any other suggestions that should be considered for
> third-party private (enterprise) subordinate CAs?
4) Require all CAs to be clearly within the domain of audit and contract
responsibility, *OR* to be clearly disclosed as outside and etc etc.
5) Require all contracts to be disclosed. (That is, not the names of
who meets the contracts, but the contract that is met.)
> I’ve been thinking about #1, and wondering if it is feasible and
> enforceable in the foreseeable future. I’m not convinced that it is. (I
> think it's the direction that we want to go, and we should encourage CAs
> to move to this model.)
Well, it's a big change. And I don't as yet see any evidence it will
improve things. I see a lot of angst, but no clear indication that it
is good to wind back on the use of sub-CAs for firewalling distinct
contractual areas.
> That leaves us with #2 and #3. I believe that regardless of the decision
> about #2, we must figure out #3.
#2 doesn't give you anything, other than a "now what?" We would then
need to go out and check those CAs. As has been shown many many times
over, we have no real ability to do that.
#3 is plausible. But it may well clobber some viable business models
when there is no real call for it.
> Therefore, I think it would be most worthwhile to focus this discussion
> on identifying how to constrain third-party private subCAs (both
> technical and contractual), and how to enforce those constraints. What
> RFEs need to be submitted and/or implemented? What requirements should
> be added to the Mozilla CA Certificate Policy? What other tools could be
> used?
I would tend towards ensuring that all under the root is covered by the
lead audit, and any exceptions are clearly marked, and include pointers
to equivalent-standard audits.
I'd also like to see the contracts. When people can see the contracts
and understand the liabilities, it's a million times easier... But I
recognise that asking for the third-party sub-CA contracts isn't going
to be so easy on the first ask.
> I look forward to your constructive contributions to this discussion. I
> request that everyone focus on the ideas and concepts, and not add
> personal comments that refer to a person’s competence or degrades a
> person’s opinion. Please do not discourage any of our participants from
> sharing their opinions.
Thanks!
> PS: I have updated https://wiki.mozilla.org/CA:Glossary to include a
> section about Registration Authority Terminology, and a section about
> Subordinate CA Terminology.
I made a tiny change: "Third-party public (or reseller) RA:..." Very
unwindable...
iang
Steve Schultze
> On 9/04/11 10:43 AM, Kathleen Wilson wrote:
>> To continue with our discussions for updating the Mozilla CA Certificate
>> Policy, I would like to have a focused discussion on third-party private
>> (enterprise) subordinate CAs. This item is the last bullet point in
>>
>> https://wiki.mozilla.org/CA:CertPolicyUpdates#RAs_and_Subordinate_CAs
>>
>> Suggestions that have been offered regarding third-party private
>> (enterprise) subordinate CAs are:
>>
>> 1) Don’t allow such subCAs to chain up to roots included in NSS.
>>
>> 2) Require CAs to provide a list of all of their subordinate CAs.
>>
>> 3) Require CAs to constrain such subCAs so they can only issue certs
>> within a specified domain.
>
>> Are there any other suggestions that should be considered for
>> third-party private (enterprise) subordinate CAs?
>
>
> 4) Require all CAs to be clearly within the domain of audit and contract
> responsibility, *OR* to be clearly disclosed as outside and etc etc.
A good requirement that is made more enforceable by #2.
> 5) Require all contracts to be disclosed. (That is, not the names of who
> meets the contracts, but the contract that is met.)
Also a good requirement that is currently being done as part of the root
inclusion process for so-called "public" SubCAs. Presuming we decide to
do #2 there is no need to have a bifurcated process for "public" and
"private" SubCAs.
>> I’ve been thinking about #1, and wondering if it is feasible and
>> enforceable in the foreseeable future. I’m not convinced that it is. (I
>> think it's the direction that we want to go, and we should encourage CAs
>> to move to this model.)
>
> Well, it's a big change. And I don't as yet see any evidence it will
> improve things. I see a lot of angst, but no clear indication that it is
> good to wind back on the use of sub-CAs for firewalling distinct
> contractual areas.
>
>> That leaves us with #2 and #3. I believe that regardless of the decision
>> about #2, we must figure out #3.
>
> #2 doesn't give you anything, other than a "now what?" We would then
> need to go out and check those CAs. As has been shown many many times
> over, we have no real ability to do that.
It works in tandem with audit requirements. Software can trivially
prevent use of non-disclosed certs, and can also notify Mozilla of
non-disclosed SubCAs for subsequent enforcement.
> #3 is plausible. But it may well clobber some viable business models
> when there is no real call for it.
If, in Kathleen's language, "The subordinate CA issues certificates only
to entities affiliated with the sub-CA organization," is it not
reasonable to expect that the domains will be known ahead of time and
thus reasonably constrainable?
If a business model relies on the cryptographic ability to issue certs
for any domain, then perhaps it is not a business model we wish to
encourage.
Steve Schultze
> Don't we just have to wait until the patch in bug 394919 makes its way
> into shipped trunk via libPKIX? The notes on that bug say this will
> happen for FF5, so... a couple years?
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=394919
Actually, upon closer inspection I believe the bug that mentions Firefox
5 as the target for this is here:
https://bugzilla.mozilla.org/show_bug.cgi?id=479393
Nelson or Kai can probably correct me if I'm wrong.
Jean-Marc Desperrier
> On 4/8/11 8:56 PM, Steve Schultze wrote:
>> Don't we just have to wait until the patch in bug 394919 makes its way
>> into shipped trunk via libPKIX? The notes on that bug say this will
>> happen for FF5, so... a couple years?
>>
>> https://bugzilla.mozilla.org/show_bug.cgi?id=394919
>
> Actually, upon closer inspection I believe the bug that mentions Firefox
> 5 as the target for this is here:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=479393
If you haven't followed, Mozilla's plan is for significant change in the
release process, and much, much shorter release (with less
functionalities added of course). There was no chance for a functional
change before Firefox 5, and Firefox 5 should come pretty soon.
The trunk has just branched for Firefox 5, which means that pre-beta
releases of Firefox 5 already are been built every night.
Steve Schultze
That's great news. In that case, we should be able to achieve
Kathleen's #1, #2, and #3 relatively quickly. They each seem to provide
unique benefits to user security.
Gervase Markham
> Can you describe your concerns? I would imagine that it is easily
> enforceable because NSS can simply refuse to accept any SubCA not on the
> disclosed list. That of course assumes #2.
Are you suggesting that NSS would include all the SubCA intermediates?
Or that we would have some sort of DN list of approved companies?
Disclosure of a list of RAs is a very different thing to programmatic
enforcement of that list. Trying to keep all versions of Firefox current
with such a large and rapidly-changing body of information would be
very, very difficult.
> Don't we just have to wait until the patch in bug 394919 makes its way
> into shipped trunk via libPKIX? The notes on that bug say this will
> happen for FF5, so... a couple years?
3 months for Firefox 5 - release date is June 21st/22nd.
However, it looks like we are not yet ready, technically, to use libpkix
for everything (we currently use it for EV). This was identified as a
high priority at the recent meeting, and we very much hope to get it
into Firefox 6 (3 months after 5).
Gerv
Gervase Markham
> To continue with our discussions for updating the Mozilla CA Certificate
> Policy, I would like to have a focused discussion on third-party private
> (enterprise) subordinate CAs. This item is the last bullet point in
>
> https://wiki.mozilla.org/CA:CertPolicyUpdates#RAs_and_Subordinate_CAs
>
> Suggestions that have been offered regarding third-party private
> (enterprise) subordinate CAs are:
>
> 1) Don’t allow such subCAs to chain up to roots included in NSS.
This basically means banning CAs from creating such subCAs, and totally
removing the point of them anyway - because if they have to include
their own root, they might as well be their own CA.
> 2) Require CAs to provide a list of all of their subordinate CAs.
>
> 3) Require CAs to constrain such subCAs so they can only issue certs
> within a specified domain.
....or domains. This seems to me to be entirely sensible.
I would be interested in the group's comments on the following assertion:
"If we have 3), there is no need for 2), because the only entity a
compromise can hurt is the company itself."
> Therefore, I think it would be most worthwhile to focus this discussion
> on identifying how to constrain third-party private subCAs (both
> technical and contractual), and how to enforce those constraints. What
> RFEs need to be submitted and/or implemented? What requirements should
> be added to the Mozilla CA Certificate Policy? What other tools could be
> used?
Is this not simply Name Constraints, which are in libpkix?
The policy would say something like:
"CAs which issue intermediate certificates to private third parties for
them to create their own leaf certificates must use name constraints to
restrict issuance of certificates under that intermediate to domains
which the CA has verified as being under the ownership of that company."
Gerv
Stephen Schultze
> On 09/04/11 01:43, Kathleen Wilson wrote:
>> To continue with our discussions for updating the Mozilla CA Certificate
>> Policy, I would like to have a focused discussion on third-party private
>> (enterprise) subordinate CAs. This item is the last bullet point in
>>
>> https://wiki.mozilla.org/CA:CertPolicyUpdates#RAs_and_Subordinate_CAs
>>
>> Suggestions that have been offered regarding third-party private
>> (enterprise) subordinate CAs are:
>>
>> 1) Don’t allow such subCAs to chain up to roots included in NSS.
>
> This basically means banning CAs from creating such subCAs, and totally
> removing the point of them anyway - because if they have to include
> their own root, they might as well be their own CA.
Precisely.
>> 2) Require CAs to provide a list of all of their subordinate CAs.
>>
>> 3) Require CAs to constrain such subCAs so they can only issue certs
>> within a specified domain.
>
> ....or domains. This seems to me to be entirely sensible.
>
> I would be interested in the group's comments on the following assertion:
>
> "If we have 3), there is no need for 2), because the only entity a
> compromise can hurt is the company itself."
A counter-assertion: "Without #2, #3 simply relies on blind trust to
ensure that SubCA's are appropriately constrained."
Imagine that a user encounters a cert that chains through an
intermediate cert to a trusted root. The intermediate cert does not
constrain the domain. Should the user trust the intermediate cert or not?
If, on the other hand, the user has an inclusive list of all permitted
SubCAs, the determination is trivial.
Stephen Schultze
> On 09/04/11 01:56, Steve Schultze wrote:
>> Can you describe your concerns? I would imagine that it is easily
>> enforceable because NSS can simply refuse to accept any SubCA not on the
>> disclosed list. That of course assumes #2.
>
> Are you suggesting that NSS would include all the SubCA intermediates?
> Or that we would have some sort of DN list of approved companies?
The former.
> Disclosure of a list of RAs is a very different thing to programmatic
> enforcement of that list. Trying to keep all versions of Firefox current
> with such a large and rapidly-changing body of information would be
> very, very difficult.
I don't see how it would be that difficult, given that Mozilla already
has a process for maintaining roots, and already tracks "public" SubCAs.
It seems that all that is lacking is to maintain the certs of SubCAs
in a slightly more structured form, and to implement some logic.
It would have the benefit of allowing users to look at the list of
trusted SubCAs within the PSM user interface, where one would logically
look for it (rather than in a PDF attached to one of hundreds of related
bugzilla entries).
Eddy Nigg
> The former.
That's not feasible - you know I support having added checks for
functions delegated to others by the CAs, but this wouldn't be
supportable. Neither for the CAs nor for Mozilla.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Stephen Schultze
> On 4/12/11 9:51 AM, Stephen Schultze wrote:
>> On 4/12/11 6:56 AM, Gervase Markham wrote:
>>> On 09/04/11 01:56, Steve Schultze wrote:
>>>> Can you describe your concerns? I would imagine that it is easily
>>>> enforceable because NSS can simply refuse to accept any SubCA not on the
>>>> disclosed list. That of course assumes #2.
>>>
>>> Are you suggesting that NSS would include all the SubCA intermediates?
>>> Or that we would have some sort of DN list of approved companies?
>>
>> The former.
>
> functions delegated to others by the CAs, but this wouldn't be
> supportable. Neither for the CAs nor for Mozilla.
Feel free to explain why you think this is the case.
Eddy Nigg
>
> Feel free to explain why you think this is the case.
I believe that Mozilla can't manage any more CA certificates than it
does currently, already today it takes a very long time to push CAs
through the process until the CA root is finally shipped in a product.
Also there are situations where the CA wants to roll-over a CA
certificate it uses or issue a new product line or whatever, having to
wait more than one year is simply not going to work.
Stephen Schultze
> On 04/12/2011 05:50 PM, From Stephen Schultze:
>>
>> Feel free to explain why you think this is the case.
>
> I believe that Mozilla can't manage any more CA certificates than it
> does currently, already today it takes a very long time to push CAs
> through the process until the CA root is finally shipped in a product.
> Also there are situations where the CA wants to roll-over a CA
> certificate it uses or issue a new product line or whatever, having to
> wait more than one year is simply not going to work.
You mean roll-over a SubCA?
If the solution to "Mozilla doesn't have the capacity to review all of
the CA requests" is "Mozilla doesn't review some CAs, or even notify
users of their existence," then we have a seriously flawed model... or
perception of what that model provides.
Eddy Nigg
> You mean roll-over a SubCA?
For example that. Or add another product (some CAs have structures and
intermediate CAs divided into purpose, verification level, etc).
>
> If the solution to "Mozilla doesn't have the capacity to review all of
> the CA requests"
That's not the case, but it takes a long time to get through the process
currently. If there would be more requests and each request would become
even more complex, I guess that would become a problem.
Stephen Schultze
>> If the solution to "Mozilla doesn't have the capacity to review all of
>> the CA requests"
>
> That's not the case, but it takes a long time to get through the process
> currently. If there would be more requests and each request would become
> even more complex, I guess that would become a problem.
Sure, but the effect today is that Mozilla doesn't review all CA
requests because due to SubCAs many of these requests go to root CAs
rather than Mozilla. All that my suggestion would do is make requests
explicitly go through Mozilla. If that overloads the process, then we
have a larger process issue.
Ian G
> On 4/12/11 11:01 AM, Eddy Nigg wrote:
>>>
>>> Feel free to explain why you think this is the case.
>>
>> I believe that Mozilla can't manage any more CA certificates than it
>> does currently, already today it takes a very long time to push CAs
>> through the process until the CA root is finally shipped in a product.
>> Also there are situations where the CA wants to roll-over a CA
>> certificate it uses or issue a new product line or whatever, having to
>> wait more than one year is simply not going to work.
>
>
> users of their existence," then we have a seriously flawed model... or
> perception of what that model provides.
Yes, but most people here are so used to it, they've forgotten it :)
The last time I saw it discussed, there was a 40 week delay from
application to public discussion. Then there's a quarter or so waiting
for a release. So, a year, at least.
(Update?)
One of the reasons for dropping sub-CAs completely from the root list
was to speed that process up.
So, that was a decision to make the CAs more responsible, and Mozilla
less responsible... It is painfully obvious that any proposal that
involves more work for Mozilla has less chance of succeeding.
iang
Gervase Markham
> I don't see how it would be that difficult, given that Mozilla already
> has a process for maintaining roots, and already tracks "public" SubCAs.
"Tracks" in what sense? I don't think we ask for a list of all
intermediates when we accept a root, do we?
There would be one or two orders of magnitude more SubCA certs than
roots. As well as the massive management overhead, the size of Firefox
would increase significantly.
> It would have the benefit of allowing users to look at the list of
> trusted SubCAs within the PSM user interface,
And what would 99.999% of users do with that information, even if they
saw it?
The model as 'designed' has the relevant characteristic that users
should be able to trust entities they do not know, either end-entities
or intermediate issuers, by delegating trust to the browser, which
trusts certain CAs, who trust certain intermediate organizations. This
is what allows the system to scale.
This only works if CAs are responsible for all issuances which take
place under their root. If that is currently not true, and we want to
keep the scaling ability, the fix is not to replace it with something
that doesn't scale, the fix is to make it true again.
Gerv
Gervase Markham
>> "If we have 3), there is no need for 2), because the only entity a
>> compromise can hurt is the company itself."
>
> A counter-assertion: "Without #2, #3 simply relies on blind trust to
> ensure that SubCA's are appropriately constrained."
A) Not blind trust - audited.
You can argue that audit is an ineffective way of constraining CA
operations if you like. But that has a whole bunch of ramifications.
> Imagine that a user encounters a cert that chains through an
> intermediate cert to a trusted root. The intermediate cert does not
> constrain the domain. Should the user trust the intermediate cert or not?
Given that not all intermediates need to be so constrained, there is no
extra reason on the information given for the user to distrust the cert.
> If, on the other hand, the user has an inclusive list of all permitted
> SubCAs, the determination is trivial.
Hey, why don't we just ship all validly-issued certificates with
Firefox? Then, there would be no need for delegated trust at all, and
determining whether a certificate is valid or not would be trivial.
Gerv
Steve Schultze
> On 12/04/11 14:51, Stephen Schultze wrote:
>> I don't see how it would be that difficult, given that Mozilla already
>> has a process for maintaining roots, and already tracks "public" SubCAs.
>
> "Tracks" in what sense? I don't think we ask for a list of all
> intermediates when we accept a root, do we?
Yes, you already ask for a list of all "public" SubCAs. Re-read my
previous messages if you are not familiar with this fact, or ask Kathleen.
> There would be one or two orders of magnitude more SubCA certs than
> roots. As well as the massive management overhead, the size of Firefox
> would increase significantly.
Yes, the number of SubCAs is the reason why it is a security problem for
Mozilla users in the first place.
The management overhead is undoubtedly higher, although it is already
being done for "public" intermediates without "an order of magnitude"
more work. I don't buy the "size of Firefox" argument. These certs are
not large in comparison to the rest of Firefox and the security value
for users.
>> It would have the benefit of allowing users to look at the list of
>> trusted SubCAs within the PSM user interface,
>
> And what would 99.999% of users do with that information, even if they
> saw it?
Benefit from the attention of .001% of users who help keep CAs honest
and inform the rest of the population of issues. This is precisely what
could have happened in the case of the CNNIC SubCA under Entrust. The
only way that users can, in your words, "deactivate certs from entities
they don't trust", is to know what entities they are implicitly trusting
and have a user interface for doing so.
> The model as 'designed' has the relevant characteristic that users
> should be able to trust entities they do not know, either end-entities
> or intermediate issuers, by delegating trust to the browser, which
> trusts certain CAs, who trust certain intermediate organizations. This
> is what allows the system to scale.
>
> This only works if CAs are responsible for all issuances which take
> place under their root. If that is currently not true, and we want to
> keep the scaling ability, the fix is not to replace it with something
> that doesn't scale, the fix is to make it true again.
I dispute the scaling argument, but if you want CAs to be truly
"responsible" for all issuances which take place under their root, you
need to prohibit all sub-CAs that are not directly controlled by the CA.
Perhaps that would indeed be easier, but Mozilla hasn't shown the will
to do something like that.
Steve Schultze
> On 12/04/11 14:32, Stephen Schultze wrote:
>>> "If we have 3), there is no need for 2), because the only entity a
>>> compromise can hurt is the company itself."
>>
>> A counter-assertion: "Without #2, #3 simply relies on blind trust to
>> ensure that SubCA's are appropriately constrained."
>
> A) Not blind trust - audited.
They aren't necessarily audited today, and in any case undisclosed
audits fail to adequately inform users of the identity of the entities
they are trusting regardless of those entities' audited operational
practices.
>> Imagine that a user encounters a cert that chains through an
>> intermediate cert to a trusted root. The intermediate cert does not
>> constrain the domain. Should the user trust the intermediate cert or not?
>
> Given that not all intermediates need to be so constrained, there is no
> extra reason on the information given for the user to distrust the cert.
>
>> If, on the other hand, the user has an inclusive list of all permitted
>> SubCAs, the determination is trivial.
>
> Hey, why don't we just ship all validly-issued certificates with
> Firefox? Then, there would be no need for delegated trust at all, and
> determining whether a certificate is valid or not would be trivial.
No need for sarcasm. You know well that EE certs are fundamentally
different from CA certs such that your proposal is absurd (but mine is
not), and you evidently don't know all of the current Mozilla practices
for disclosure of SubCA certs.
Gervase Markham
> The management overhead is undoubtedly higher, although it is already
> being done for "public" intermediates without "an order of magnitude"
> more work. I don't buy the "size of Firefox" argument. These certs are
> not large in comparison to the rest of Firefox and the security value
> for users.
What about the ubiquity problem? Despite our best efforts, people
continue to use versions of Firefox which we no longer support. We
wouldn't ship root store updates for them (that's what "no longer
support" means). But no CA is going to try issuing certs off roots which
don't work in as many as 5-10% of browsers.
>>> It would have the benefit of allowing users to look at the list of
>>> trusted SubCAs within the PSM user interface,
>>
>> And what would 99.999% of users do with that information, even if they
>> saw it?
>
> Benefit from the attention of .001% of users who help keep CAs honest
> and inform the rest of the population of issues.
But why does the information have to be _in_ Firefox for that to be true?
> I dispute the scaling argument, but if you want CAs to be truly
> "responsible" for all issuances which take place under their root, you
> need to prohibit all sub-CAs that are not directly controlled by the CA.
I don't think that premise warrants that conclusion. To produce a
counter-example: if a CA said "we will shut down all operations
worldwide if this independent third party to whom we have given an
intermediate ever has a security breach", then they would be
responsible, but the third party would not be directly controlled.
No CA would say that. But the question arises: how responsible is
"responsible enough" (no CA would shut down their entire worldwide
operations if they had any security breach themselves, let alone at a
third party). For example, is being under the same audit (and therefore
the CA fails if the 3rd party fails) responsible enough?
Gerv
Gervase Markham
> On 4/13/11 6:38 AM, Gervase Markham wrote:
>> On 12/04/11 14:32, Stephen Schultze wrote:
>>>> "If we have 3), there is no need for 2), because the only entity a
>>>> compromise can hurt is the company itself."
>>>
>>> A counter-assertion: "Without #2, #3 simply relies on blind trust to
>>> ensure that SubCA's are appropriately constrained."
>>
>> A) Not blind trust - audited.
>
> They aren't necessarily audited today, and in any case undisclosed
> audits fail to adequately inform users of the identity of the entities
> they are trusting regardless of those entities' audited operational
> practices.
Let me be more clear. I mean, the CA is audited to make sure that all of
the intermediates it issues to private SubCAs have name constraints. Due
to the name constraints, the private SubCAs would not need an audit.
Gerv
Stephen Schultze
> On 13/04/11 14:39, Steve Schultze wrote:
>> The management overhead is undoubtedly higher, although it is already
>> being done for "public" intermediates without "an order of magnitude"
>> more work. I don't buy the "size of Firefox" argument. These certs are
>> not large in comparison to the rest of Firefox and the security value
>> for users.
>
> What about the ubiquity problem? Despite our best efforts, people
> continue to use versions of Firefox which we no longer support. We
> wouldn't ship root store updates for them (that's what "no longer
> support" means). But no CA is going to try issuing certs off roots which
> don't work in as many as 5-10% of browsers.
I don't understand how this is not also a problem for *any* update of
the Moz root store... yet it seems to not have held Moz back from
adding/removing roots.
>>>> It would have the benefit of allowing users to look at the list of
>>>> trusted SubCAs within the PSM user interface,
>>>
>>> And what would 99.999% of users do with that information, even if they
>>> saw it?
>>
>> Benefit from the attention of .001% of users who help keep CAs honest
>> and inform the rest of the population of issues.
>
> But why does the information have to be _in_ Firefox for that to be true?
It doesn't have to be, but it would be more enforceable if it were.
However, for end users to be able to block unwanted sub-CAs there needs
to be a UI for doing so. Right now there is none. Furthermore, if the
Sub-CAs are already there in the UI, it is more intuitive.
>> I dispute the scaling argument, but if you want CAs to be truly
>> "responsible" for all issuances which take place under their root, you
>> need to prohibit all sub-CAs that are not directly controlled by the CA.
>
> I don't think that premise warrants that conclusion. To produce a
> counter-example: if a CA said "we will shut down all operations
> worldwide if this independent third party to whom we have given an
> intermediate ever has a security breach", then they would be
> responsible, but the third party would not be directly controlled.
>
> No CA would say that. But the question arises: how responsible is
> "responsible enough" (no CA would shut down their entire worldwide
> operations if they had any security breach themselves, let alone at a
> third party). For example, is being under the same audit (and therefore
> the CA fails if the 3rd party fails) responsible enough?
If it is under the same audit *and* additional Moz requirements, and if
it is disclosed if it's not name constrained, then I think it would be
acceptable (but that's just my opinion of what "responsible enough" is).
Of course, in this case, the requirements are almost identical to the
requirements for direct root inclusion.
Stephen Schultze
As I noted in my earlier message, this is a compromise I could probably
live with. I'm curious what others think.
Another nice feature of this approach is that we no longer have
ambiguity between what is a "public" and what is a "private" SubCA.
It's more a matter of name constraints or not. If no name constraints,
disclosure.
Eddy Nigg
> The management overhead is undoubtedly higher, although it is already
> being done for "public" intermediates without "an order of magnitude"
> more work. I don't buy the "size of Firefox" argument. These certs
> are not large in comparison to the rest of Firefox and the security
> value for users.
Well, I must disagree here - there is a vast difference between
disclosure and inclusion of intermediate CA certificates into NSS.
> I dispute the scaling argument, but if you want CAs to be truly
> "responsible" for all issuances which take place under their root, you
> need to prohibit all sub-CAs that are not directly controlled by the CA.
I don't agree with that either, instead I was poking for a auditing
requirements for any and all entities in the same PKI for years *.
Including RAs. Something I believe has received now sufficient support
by most players including the CAs.
* I'm sure Frank and some others can recall.
Jean-Marc Desperrier
> Despite our best efforts, people continue to use versions of Firefox
> which we no longer support. We wouldn't ship root store updates for them
> (that's what "no longer support" means). But no CA is going to try
> issuing certs off roots which don't work in as many as 5-10% of browsers.
So, maybe the solution is to have an update mechanism for the trusted CA
list that is checked everytime Firefox starts, similar to Microsoft.
If you add that, it could also automatically update a certificate black
list => two birds, one stone.
Eddy Nigg
> As I noted in my earlier message, this is a compromise I could
> probably live with. I'm curious what others think.
>
> Another nice feature of this approach is that we no longer have
> ambiguity between what is a "public" and what is a "private" SubCA.
> It's more a matter of name constraints or not. If no name
> constraints, disclosure.
Works for me.
Kyle Hamilton
On Wed, Apr 13, 2011 at 3:35 AM, Gervase Markham <ge...@mozilla.org> wrote:
>
> The model as 'designed' has the relevant characteristic that users should be
> able to trust entities they do not know, either end-entities or intermediate
> issuers, by delegating trust to the browser, which trusts certain CAs, who
> trust certain intermediate organizations. This is what allows the system to
> scale.
This only works if the browser is willing to be flexible on what it's trusted with. Unfortunately, none are.
The problem with Internet security in general is that there are far too many impedance mismatches between the various standards, the current practices, and the proposed solutions.
The specific problem with Mozilla security is that it's a huge blockade put in front of a cesspit mockery of "concern for the user".
Until the CA trust process and model are fixed, there is no security that Mozilla can provide to the end consumer user.
-Kyle H
Kyle Hamilton
On Wed, Apr 13, 2011 at 8:22 AM, Gervase Markham <ge...@mozilla.org> wrote:
> On 13/04/11 14:39, Steve Schultze wrote:
>>
>> The management overhead is undoubtedly higher, although it is already
>> being done for "public" intermediates without "an order of magnitude"
>> more work. I don't buy the "size of Firefox" argument. These certs are
>> not large in comparison to the rest of Firefox and the security value
>> for users.
>
> What about the ubiquity problem? Despite our best efforts, people continue
> to use versions of Firefox which we no longer support. We wouldn't ship root
> store updates for them (that's what "no longer support" means). But no CA is
> going to try issuing certs off roots which don't work in as many as 5-10% of
> browsers.
The ubiquity problem would be solved by having Mozilla run its own cross-certification CA.
As was proposed on this group many years ago, before Kathleen took the reins.
>>>> It would have the benefit of allowing users to look at the list of
>>>> trusted SubCAs within the PSM user interface,
>>>
>>> And what would 99.999% of users do with that information, even if they
>>> saw it?
>>
>> Benefit from the attention of .001% of users who help keep CAs honest
>> and inform the rest of the population of issues.
>
> But why does the information have to be _in_ Firefox for that to be true?
...where else would you have people find it? ...where else would you expect them to get the pointer? ...where and how else would/could you expect them to get it? It took me -months- to figure out Mozilla's development process, and where to interact with those who are providing Firefox's security.
>> I dispute the scaling argument, but if you want CAs to be truly
>> "responsible" for all issuances which take place under their root, you
>> need to prohibit all sub-CAs that are not directly controlled by the CA.
>
> I don't think that premise warrants that conclusion. To produce a
> counter-example: if a CA said "we will shut down all operations worldwide if
> this independent third party to whom we have given an intermediate ever has
> a security breach", then they would be responsible, but the third party
> would not be directly controlled.
That's the only counter-example that's worth demanding.
> No CA would say that. But the question arises: how responsible is
> "responsible enough" (no CA would shut down their entire worldwide
> operations if they had any security breach themselves, let alone at a third
> party). For example, is being under the same audit (and therefore the CA
> fails if the 3rd party fails) responsible enough?
No.
Is being your child enough to let your child forge your signature?
-Kyle H
Eddy Nigg
> The ubiquity problem would be solved by having Mozilla run its own
> cross-certification CA.
>
And at time it was already determined that NSS is in fact the root for
CA roots. The method is not really important in this respect.
Kyle Hamilton
On Wed, Apr 13, 2011 at 1:56 PM, Eddy Nigg <eddy...@startcom.org> wrote:
> On 04/13/2011 11:46 PM, From Kyle Hamilton:
>>
>> The ubiquity problem would be solved by having Mozilla run its own
>> cross-certification CA.
>>
>
> And at time it was already determined that NSS is in fact the root for CA
> roots. The method is not really important in this respect.
This may be the case, but if it is the limitations imposed by the model can been adequately described thus: Root CA with no revocation.
Mozilla needs to follow its own policy. It's a root of trust, it needs to start acting like it.
-Kyle H
Eddy Nigg
> This may be the case, but if it is the limitations imposed by the
> model can been adequately described thus: Root CA with no revocation.
I rather think that no root was revoked without consent of the
certificate holder (some unused or older roots with 1024 keys and less
have been removed). It still acts like a root for CA roots.
Kyle Hamilton
On Wed, Apr 13, 2011 at 2:04 PM, Eddy Nigg <eddy...@startcom.org> wrote:
> On 04/13/2011 11:59 PM, From Kyle Hamilton:
>>
>> This may be the case, but if it is the limitations imposed by the model
>> can been adequately described thus: Root CA with no revocation.
>
> I rather think that no root was revoked without consent of the certificate
> holder (some unused or older roots with 1024 keys and less have been
> removed). It still acts like a root for CA roots.
"What about the ubiquity problem? Despite our best efforts, people continue to use versions of Firefox which we no longer support. We wouldn't ship root store updates for them (that's what "no longer support" means). But no CA is going to try issuing certs off roots which don't work in as many as 5-10% of browsers."
The point is: If Firefox had originally shipped with a central cross-certifying root (and checked revocation), the "ubiquity problem" would not be the problem that it is today. Mozilla should consider it as a future root suspension/revocation/admission/readmission mechanism. It would have the added bonus of allowing Mozilla to add CAs for non-current browsers, without forcing a full upgrade.
But no, Mozilla doesn't want to run one.
Mozilla's "best efforts" seem to constantly and consistently make the browser grow ever larger and ever slower. I have a backup Firefox 2 install because it's a lot faster than 4, and I can use it when speed is of the essence. Remember, this isn't an experiment, this is real life.
-Kyle H
Ian G
> No CA would say that. But the question arises: how responsible is
> "responsible enough" (no CA would shut down their entire worldwide
> operations if they had any security breach themselves, let alone at a
> third party). For example, is being under the same audit (and therefore
> the CA fails if the 3rd party fails) responsible enough?
I don't know how y'all measure responsibility, but typically in the
business world it is measured in terms of money. How much do you pay
out if it goes wrong?
The buck is the only language understood by any corporation larger than
25 people. Put it in dollar terms and you'll have their attention
because fundamentally, all decisions come back to NPVs. Alternatively,
put it in green, koala-friendly, touchy-feely, stakeholder, democratic,
save-the-children/planet/whale/amazon terms, and the corporation will
sell you another resource, sliced to perfection. Yum, gimme two.
That's why governments typically add fines to acts considered bad. And
why contracts have liability clauses.
(This message worth $0.02 of responsibility :)
iang
Gervase Markham
> I don't understand how this is not also a problem for *any* update of
> the Moz root store... yet it seems to not have held Moz back from
> adding/removing roots.
It is a problem. CAs currently have a long lead time (years) to get in
business. Ask Eddy about what browser versions don't support StartCom -
it's probably not many now, but it's taken time.
>> But why does the information have to be _in_ Firefox for that to be true?
>
> It doesn't have to be, but it would be more enforceable if it were.
>
> However, for end users to be able to block unwanted sub-CAs there needs
> to be a UI for doing so. Right now there is none.
That could be fixed without including them in the product. "Click this
link [to the cert]; uncheck the trust boxes [on the presented dialog];
click OK to import".
This is arguably more intuitive than diving into Advanced security
preferences.
Gerv
Kyle Hamilton
On Thu, Apr 14, 2011 at 6:42 AM, Gervase Markham <ge...@mozilla.org> wrote:
> That could be fixed without including them in the product. "Click this link
> [to the cert]; uncheck the trust boxes [on the presented dialog]; click OK
> to import".
Why should the user have to do anything at all? This is an infrastructure problem, it shouldn't impact the user aside from "detour" signs.
> This is arguably more intuitive than diving into Advanced security
> preferences.
I don't believe that there's any concept of "intuitive" where people haven't been specifically trained.
Instead of embedding them, how about a blacklisted set of certificate hashes, both SHA-1 and SHA-256 variants? That would be 52 bytes per subCA, and the chances of finding (much less running into) a preimage of SHA-1 that is also a preimage of SHA-256 are vanishingly small.
-Kyle H