|Subordinate-CAs from trusted roots for 'managing encrypted traffic'||Patrick T||2/2/12 7:29 AM|
Trustwave recently posted an update on their CPS page:
"It has been common practice for Trusted CAs to issue subordinate
roots for enterprises for the purpose of transparently managing
encrypted traffic. In the past, Trustwave, like many of our peers in
the industry, has enabled organizations to perform this activity. Due
to events of the past year, Trustwave has decided to revoke all
subordinate roots issued for this purpose."
Does anyone else read this that they have previously issued trusted
subordinate-CAs from their public roots, specifically to allow
interception and MITM of SSL traffic?
Wouldn't that mean that they've been allowing 'enterprises' to
purposefully mis-issue certificates - like Diginotar, only condoned,
and with the consent of the CA?
I understand they're now revoked (supposedly), but why should Mozilla
still maintain trusted root CAs for Trustwave and '...peers in the
industry...' who do this?
I know there was discussion about disclosure of subordinate CAs from
the trusted CAs, but I see no reason why Mozilla should maintain any
trusted CA that isn't willing to disclose a list of all subordinate
CAs that are *not* hosted with the trusted CA or under a sufficient
Mozilla-approved audit scheme audited infrastructure.
|Re: Subordinate-CAs from trusted roots for 'managing encrypted traffic'||David E. Ross||2/2/12 7:40 AM|
I have argued for this several times in the past.
David E. Ross
Anyone who thinks government owns a monopoly on inefficient, obstructive
bureaucracy has obviously never worked for a large corporation.
© 1997 by David E. Ross
|Re: Subordinate-CAs from trusted roots for 'managing encrypted traffic'||Stephen Schultze||2/2/12 8:27 AM|
On 2/2/12 10:29 AM, Patrick Tate wrote:It's not clear what "transparently managing encrypted traffic" means.
Perhaps you should ask them that, and for a list of all revoked Sub-CAs
(to be publicly disclosed to this list).
I wholeheartedly agree.
Of course, the current policy does not require this. All the more
reason to adopt updates to the policy in the near future.
Of course, there is a difference between third-party CAs that use their
CA certs only for issuing certs for domains they control and third-party
CAs that issue certs for domains that they do not control. Which
practice a given entity is undertaking is entirely cryptographically
opaque to Mozilla, and is governed by, at best, contract (under the
current policy). This is the heart of the problem with trying to make
policy based on a distinction between promised practices versus
disclosed and cryptographically demonstrable controls.
|RE: Subordinate-CAs from trusted roots for 'managing encrypted traffic'||Robin Alden||2/2/12 9:05 AM|
> From: Patrick Tate
> I understand they're now revoked (supposedly), but why should MozillaKathleen asked (back in September) of all CAs in the program:
5) For each external third party (CAs and RAs) that issues
certificates or can directly cause the issuance of certificates within
the hierarchy of the root certificate(s) that you have included in
a) Implement technical controls to restrict issuance to a
specific set of domain names which you have confirmed that the third
party has registered or has been authorized to act for (e.g. RFC5280
x509 dNSName name constraints, marked critical)
b) Send a complete list of all third parties along with links to
their corresponding Certificate Policy and/or Certification
Statement and provide public attestation of their conformance to
stated verification requirements and other operational criteria
competent independent party or parties with access to details of
subordinate CA's internal operations.
so Mozilla presumably already has this information.
For information, we at Comodo have not issued subordinate CA
certificates to enterprises for the purpose of transparently managing
encrypted traffic - or for any other activity contrary to Mozilla's CA
policy - although we received (and rejected) a request through normal
commercial channels for such sub-CA certificates to be issued.
|Re: Subordinate-CAs from trusted roots for 'managing encrypted traffic'||Tom Ritter||2/2/12 10:03 AM|
I accidentally replied to author instead of list earlier.
This discussion came up on another list under the topics "really sub-
CAs for MitM deep packet inspectors? (Re: Auditable CAs)" and "if MitM
via sub-CA is going on, need a name-and-shame catalog".
Yes, it's done, and yes it's actually common. Here's some choice
excerpts from those threads:
>Start of the thread was that Greg and maybe others claim they've seen a cert
>in the wild doing MitM on domains the definitionally do NOT own.
It's not just a claim, I've seen them too. For example I have a cert
for google.com from such a MITM proxy. I was asked by the contributor
reveal any details on it because it contains the name and other info
intermediate CA that issued it, but it's a cert for google.com used
packet inspection on a MITM proxy. I also have a bunch of certs from
label CAs that chain directly up to big-name public CAs, there's no
measure I can see in them anywhere that would prevent them from
under any name.
>The real question again is can we catch a boingo or corp lan or government
>using a MitM sub-CA cert, and then we'll know which CA is complicit in issuing
>it, and delist them.
Given that some of the biggest CAs around sell private-label CA certs,
end up shutting down half the Internet if you did so.
- Peter Gutmann
> Actually, more surprisingly, I've been told by those who manage
> something like this for our company, that even the reported
> number of padlocks that they issue and are expected to
> compensate the CA for is kept on the honor systemm--at least
> for the CA with whom we interact. (Or course, I'm assuming that
> the this CA retains the right to periodically do audits, etc.)
Concur. The standard sub-CA contracts contain a right to audit the
number of certs issued, like any enterprise-wide software license
agreement does include a right to audit used seats. Not once in over
years have I seen such an audit performed. There is no reason to
when you buy a sub-CA, the public CA's rep will work out a contract
gives you the right to use as many certs and more as you conceivably
could use given the application to which you plan to put the sub-CAs.
Keeping count of actual certs issued would only add cost to both the
sub-CA customer and the root CA provider. There is simply no business
case for auditing the number of certs issued.
Presumably, if you bought a sub-CA for in-house use and then started
selling SSL server certs on the Internet, the root CA would complain,
but I have never seen such a silly violation of a sub-CA contract. If
you wanted to issue certs to the world, just execute a reseller
Lastly, a brief comment on cost: some posts in this thread mentioned
annual rate of USD 50k for a sub-CA. That number is indeed the rack
for an in-house sub-CA with unlimited cert issuance. (Well,
the contract will have a limit of the sum total of your employees,
servers, plus a generous buffer).
The smart purchasing manager will pay less than USD 50k. My advice to
customers that operate in-house sub-CAs has long been to renew in
mid-December or otherwise towards the end of the root CA's fiscal
At that time the rep will give you an unlimited certs sub-CA renewal
USD 35k per year. If he balks, threaten to switch to one of the
competing root CAs. Depending on how far behind quota the rep is,
similar discounts might be had in the last week of each quarter.
- Lucky Green
>Matches my observations, especially when looking at CRLs of some small CAs
>(company internal). I had a hunch some of those revocations could be due to
>CA compromise, but from my point of view it is be only a speculation. I
>appreciate sharing your experience working with CAs, it gives me a bit more
>understanding in my guesswork how they operate internally :-)
So I'm going to invoke the Carl Ellison "if you think that's bad" rule
approximately as "whenever someone tells a horror story about PKI,
else will come along with 'if you think that's bad...'") and mention a
root CA that went out of business (I tracked its root key through
resales but I have no idea who has it now) where not only did no-ne
who was left know how to put reason codes in CRLs, there was no-one
actually knew how to issue a CRL. So if you had a cert from them you
much do whatever you wanted with it (until it expired naturally)
was no way to revoke it.
- Peter Gutmann
Practically, things seems to hinge on "What the buyer does with the
white-label CA". If one of those certs gets out into the wild, or is
used on people the company doesn't have control over (e.g. it's used
in an airport hotspot instead of internally at the large company) -
then shit will hit the fan. But noone I know of has seen that
happen. If they have, they kept their mouth shut, probably because of
contract or NDA.
I think Trustwave revoking these certs is a great sign*, and trust
their root cert more because of it. Likewise, I'm pleased with the
statement from Comodo.
* the catch is, they probably revoked them because something bad did
happen, and they went "Oh shit, we're never going to let something
like this happen again."
|Re: Subordinate-CAs from trusted roots for 'managing encrypted traffic'||Steve Roylance||2/2/12 3:43 PM|
Over the last couple of years GlobalSign has received several requests
from large enterprises who run services such as Websense with a need for
this type of CA. We have declined in all cases. We've always recommended
for enterprises to create their own internal CA and seed those to their
Business Development Director.
>dev-security-policy mailing list
|Re: Subordinate-CAs from trusted roots for 'managing encrypted traffic'||Stephen Schultze||2/3/12 5:30 AM|
Is there any technical constraints, audit, or public disclosure of
SubCAs issued as part of your "Trusted Root for Inhouse PKI /
Certificate Authority" product?
> On 03/02/2012 00:29, "Patrick Tate"<in...@eishundo.com> wrote:
|Re: Subordinate-CAs from trusted roots for 'managing encrypted traffic'||ArkanoiD||2/3/12 11:42 AM|
Do we have a definition of "inhouse PKI"?
Does it mean signing company's own externally visible resources or what?
> _______________________________________________> email protected and scanned by AdvascanTM - keeping email useful -
|Re: Subordinate-CAs from trusted roots for 'managing encrypted traffic'||ArkanoiD||2/3/12 11:42 AM|
BTW it is quite funny that Google does not have their own intermediate CA, while Yandex has.
|Re: Subordinate-CAs from trusted roots for 'managing encrypted traffic'||Steve Roylance||2/4/12 6:27 AM|
We are working hard with all of our customers to migrate them to a
constrained issuing CA model. Some have decided that they are better
moving to a managed service as this is now a viable option for them. It
wasn't back in 2002/2003 when some of these customers first needed these
We plan on having all customers transitioned by July.
Thanks and I hope that helps clarify our position.
On 03/02/2012 13:30, "Stephen Schultze" <sjschult...@gmail.com>
|Re: Subordinate-CAs from trusted roots for 'managing encrypted traffic'||Jean-Marc Desperrier||2/4/12 3:21 PM|
On 03/02/2012 20:42, ArkanoiD wrote:In which world is this true ?
CN = Google Internet Authority
O = Google Inc
C = US
issued on the 08/06/2009 20:43:27 GMT by
OU = Equifax Secure Certificate Authority
O = Equifax
C = US
|Re: Subordinate-CAs from trusted roots for 'managing encrypted traffic'||ArkanoiD||2/5/12 1:48 AM|
Ah, so I missed that. Last time I checked it wasn't true -- google certificates
were signed by some roots directly.
|Re: Subordinate-CAs from trusted roots for 'managing encrypted traffic'||Stephen Schultze||2/7/12 4:37 PM|
|Re: Subordinate-CAs from trusted roots for 'managing encrypted traffic'||Kathleen Wilson||2/8/12 10:15 AM|
On 2/7/12 4:37 PM, Stephen Schultze wrote:I keep hearing that it's common practice. I hope not.
If there are any other CAs with roots included in NSS that have this
type of subCA, then they should revoke those subCAs and destroy the HSMs
Does the proposed item #9 in the draft version of Mozilla's CA
Certificate Policy go far enough to make it clear that this sort of
subCA is not allowed?
9. The CA must do one of the following for each external third party
that issues certificates. (Any external third party that can directly
cause the issuance of a certificate must be treated as a subordinate CA,
meeting one of the following two requirements.)
- Implement technical controls to restrict the subordinate CA to only
issue certificates within a specific set of domain names which the CA
has confirmed that the subordinate CA has registered or has been
authorized by the domain registrant to act on the registrant's behalf.
Such technical controls must be documented in the CA's Certificate
Policy or Certification Practice Statement, and reviewed by a competent
independent party as part of the CA's annual audit. Acceptable technical
controls include but are not limited to X.509 dNSName Name Constraints
as specified in RFC 5280, which are marked as critical.
- Publicly disclose the subordinate CA along with the subordinate CA's
corresponding Certificate Policy and/or Certification Practice Statementand provide public attestation of the subordinate CA's conformance to
the stated verification requirements and other operational criteria by asubordinate CA's internal operations. The subordinate CA's verification
requirements and operational criteria must satisfy the requirements of
the Mozilla CA Certificate Policy. The CA's Certificate Policy or
Certification Practice Statement must indicate where the list of
publicly disclosed subordinate CAs may be found on the CA's website.
|Re: Subordinate-CAs from trusted roots for 'managing encrypted traffic'||Jan Schejbal||2/8/12 1:23 PM|
Am 2012-02-08 19:15, schrieb Kathleen Wilson:I would suggest an explicit statement by Mozilla that
a) this sort SubCA is strictly not allowed
b) there is a grace period of 14 days from the announcement to revoke
any such SubCAs, confirm to Mozilla that this has been done, and confirm
that no such SubCAs will be issued and third parties will be prevented
(by contract and revocation) from abusing their SubCAs for this purpose
c) there is a grace period of 30 days from the announcement to disclose
any such SubCAs that exists or existed in the past and confirm that the
list is complete
d) If a CA does not comply, Mozilla will proceed as per number 4 in the
Inclusion Policy, i.e. remove the root
I think that despite the violation of both common sense and probably
Mozilla Policy, Trustwave should not be punished for disclosing the
issue, iff their disclosure was voluntary. Admitting and ceasing bad
practice should not be punished.
It might also be worth requiring all CAs to issue Third-party Sub-CAs
from a separate intermediate. This would allow to explicity kill all
existing third-party Sub-CAs created by one CA without killing the CA
and breaking the internet. This would also allow Mozilla more choice
between "do absolutely nothing relevant" and "completely destroy the CA"
when a CA violates policy. Not being able to create SubCAs would
certainly be extremely painful to a CA, but probably not deadly. (Of
course the CA can start issuing Sub-CAs from their main root if Mozilla
removes their Sub-CA intermediate, but then they lose that too.)
For CAs that issue their end entitiy certs at the same depth as they
issue third-party intermediates (i.e. third-party intermediates are not
at the same depth as their own intermediates), implementing a forced
path length constraint on their root could have the same effect
(disabling third-party SubCAs without affecting regular certificates).
Please avoid sending mails, use the group instead.
If you really need to send me an e-mail, mention "FROM NG"
in the subject line, otherwise my spam filter will delete your mail.
Sorry for the inconvenience, thank the spammers...
|Re: Subordinate-CAs from trusted roots for 'managing encrypted traffic'||Stephen Schultze||2/8/12 1:43 PM|
On 2/8/12 4:23 PM, Jan Schejbal wrote:[...]
> c) there is a grace period of 30 days from the announcement to discloseJan, quick question. Are you suggesting public disclosure or
confidential disclosure to Mozilla? I of course favor the former.
|Re: Subordinate-CAs from trusted roots for 'managing encrypted traffic'||Jan Schejbal||2/8/12 2:50 PM|
Am 2012-02-08 22:43, schrieb Stephen Schultze:I am suggesting disclosure to the potentially affected audience, i.e.
all Mozilla users, i.e. the public.
|Re: Subordinate-CAs from trusted roots for 'managing encrypted traffic'||ianG||2/8/12 4:41 PM|
On 9/02/12 08:23 AM, Jan Schejbal wrote:IMHO, the policy requires disclosure. There are two counts here, being
issuing MITMs deliberately, and failing to disclose this in published
Which is to say, any requests for "new" disclosures are rather
non-novel. There is only the issue of enforcing the existing policy at
hand, there is no need for any changes.
Again, all IMHO.
Good idea! I'm interested to hear what CAs with the experience in
sub-CAs say about the idea here. Is it workable?
(Which is to say, if there are any private & confidential comments,
that's another black mark against :)
|Re: Subordinate-CAs from trusted roots for 'managing encrypted traffic'||Stephen Schultze||2/8/12 5:35 PM|
On 2/8/12 7:41 PM, ianG wrote:I'm not sure exactly what disclosure you're referring to, but enforcing
current policy requires the disclosure of all SubCAs. This is the only
way to check compliance -- ideally in automated fashion along the lines
of what was suggested here:
Unfortunately, not all SubCAs are disclosed:
"When people send me information in confidence I treat it as such and I
will not disclose it."
Which is why we need proposed update #9 to be adopted, implemented, and
required ASAP. I like Jan's timeline.
|Re: Subordinate-CAs from trusted roots for 'managing encrypted traffic'||Peter Gutmann||2/9/12 6:59 AM|
Jan Schejbal <jan.sche...@gmx.de> writes:This implies that the CA knows that such a sub-CA exists. Serve a National
Security Letter on an employee with access to the cert-issuing process and the
CA (meaning its management) will be able to say with a straight face that
nothing like this exists, while still having sub-CAs out there.
Having said that, given lawful, targeted use of the SSL MITM capability it's
no worse than a standard wiretap, so having a CA say "we'll cooperate with
LEA's in response to a court order" (if they don't already do that anyway)
would be an acceptable alternative.
Put another way, what do you think will win out for a CA, Mozilla's CA Policy
or a National Security Letter?
|Re: Subordinate-CAs from trusted roots for 'managing encrypted traffic'||ArkanoiD||2/9/12 7:56 AM|
And nothing may prevent Mozilla from dropping the root afterwards -- and it *is* the proper
I wonder if it is against the law to <strike>commit seppuku</strike> notify peers immediately if
you are forced to obey such an order.
|Re: Subordinate-CAs from trusted roots for 'managing encrypted traffic'||Jan Schejbal||2/9/12 10:46 AM|
Am 2012-02-09 15:59, schrieb Peter Gutmann:1. This requires a National Security Letter (and maybe even that is not
sufficient, see below), i.e. the government must be the attacker.
My suggestion would also not prevent by technical means abuse of Sub-CAs
meant for legitimate purposes, only require the CA to react to such
abuse. However, currently, it seems that any private corporation can get
such a cert, officially, for the explicit purpose of performing MitM
attacks, and that this is being done. This is the problem my suggestions
are trying to address.
According to Wikipedia, a NSL can be fought in court and is limited to
the disclosure of transactional records etc., i.e. probably does not
cover "issue us a fake CA now". Mozilla's CA Policy alone will certainly
not win out for a CA. The threat of being completely put out of
business, however, might have some influence on the willingnes to fight
such a request instead of blindly complying.
Currently the deal is "Comply with government request and in the
worst-case get a 'do not do that again' from Mozilla each time they do
it" vs. "Fight government request and risk some trouble". I would like
this to be changed to "Comply with government request and risk being
completely destroyed" vs. "Fight government request and risk some trouble"