Subordinate-CAs from trusted roots for 'managing encrypted traffic'

[Patrick Tate]

Trustwave recently posted an update on their CPS page:

https://ssl.trustwave.com/CA/

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

[David E. Ross]

I have argued for this several times in the past.

--

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 by David E. Ross

[Stephen Schultze]

On 2/2/12 10:29 AM, Patrick Tate wrote:
> Trustwave recently posted an update on their CPS page:
>
> https://ssl.trustwave.com/CA/
>
> "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?

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

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.

[Robin Alden]

> From: Patrick Tate

>
> Trustwave recently posted an update on their CPS page:
>
> https://ssl.trustwave.com/CA/
>
> "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.

Kathleen 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
Mozilla products,
either:

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)

OR

b) Send a complete list of all third parties along with links to
each of
their corresponding Certificate Policy and/or Certification
Practice
Statement and provide public attestation of their conformance to
the
stated verification requirements and other operational criteria
by a
competent independent party or parties with access to details of
the
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.

Regards
Robin Alden
Comodo

[Tom Ritter]

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
issued
for google.com from such a MITM proxy. I was asked by the contributor
not to
reveal any details on it because it contains the name and other info
on the
intermediate CA that issued it, but it's a cert for google.com used
for deep
packet inspection on a MITM proxy. I also have a bunch of certs from
private-
label CAs that chain directly up to big-name public CAs, there's no
technical
measure I can see in them anywhere that would prevent them from
issuing certs
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,
you'd
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
30
years have I seen such an audit performed. There is no reason to
audit:
when you buy a sub-CA, the public CA's rep will work out a contract
that
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
contract.

Lastly, a brief comment on cost: some posts in this thread mentioned
an
annual rate of USD 50k for a sub-CA. That number is indeed the rack
rate
for an in-house sub-CA with unlimited cert issuance. (Well,
technically
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
year.
At that time the rep will give you an unlimited certs sub-CA renewal
at
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
(stated
approximately as "whenever someone tells a horror story about PKI,
someone
else will come along with 'if you think that's bad...'") and mention a
trusted
root CA that went out of business (I tracked its root key through
three
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
who
actually knew how to issue a CRL. So if you had a cert from them you
could pretty
much do whatever you wanted with it (until it expired naturally)
because there
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.

-tom

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

[Steve Roylance]

Hi Patrick,

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

Steve Roylance
Business Development Director.

On 03/02/2012 00:29, "Patrick Tate" <in...@eishundo.com> wrote:

>Trustwave recently posted an update on their CPS page:
>
>https://ssl.trustwave.com/CA/
>
>"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.

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

[Stephen Schultze]

Steve,

Is there any technical constraints, audit, or public disclosure of
SubCAs issued as part of your "Trusted Root for Inhouse PKI /
Certificate Authority" product?

http://www.globalsign.com/certificate-authority-root-signing/internal-pki/

On 2/2/12 6:43 PM, Steve Roylance wrote:
> 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
> client network.

[ArkanoiD]

Do we have a definition of "inhouse PKI"?
Does it mean signing company's own externally visible resources or what?

On Fri, Feb 03, 2012 at 08:30:25AM -0500, Stephen Schultze wrote:
> Steve,
>
> Is there any technical constraints, audit, or public disclosure of
> SubCAs issued as part of your "Trusted Root for Inhouse PKI /
> Certificate Authority" product?
>
> http://www.globalsign.com/certificate-authority-root-signing/internal-pki/
>
> On 2/2/12 6:43 PM, Steve Roylance wrote:

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

> >On 03/02/2012 00:29, "Patrick Tate"<in...@eishundo.com> wrote:
> >>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.
>
>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

> email protected and scanned by AdvascanTM - keeping email useful -
> www.advascan.com
>

[ArkanoiD]

BTW it is quite funny that Google does not have their own intermediate CA, while Yandex has.

On Fri, Feb 03, 2012 at 08:30:25AM -0500, Stephen Schultze wrote:
> Steve,
>
> Is there any technical constraints, audit, or public disclosure of
> SubCAs issued as part of your "Trusted Root for Inhouse PKI /
> Certificate Authority" product?
>
> http://www.globalsign.com/certificate-authority-root-signing/internal-pki/
>
> On 2/2/12 6:43 PM, Steve Roylance wrote:

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

> >On 03/02/2012 00:29, "Patrick Tate"<in...@eishundo.com> wrote:
> >>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.
>
>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Steve Roylance]

Hi Stephen,

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

We plan on having all customers transitioned by July.

Thanks and I hope that helps clarify our position.

Steve





On 03/02/2012 13:30, "Stephen Schultze" <sjschult...@gmail.com>

[Jean-Marc Desperrier]

On 03/02/2012 20:42, ArkanoiD wrote:
> BTW it is quite funny that Google does not have their own intermediate CA, while Yandex has.

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

[ArkanoiD]

Ah, so I missed that. Last time I checked it wasn't true -- google certificates
were signed by some roots directly.

On Sun, Feb 05, 2012 at 12:21:28AM +0100, Jean-Marc Desperrier wrote:
> On 03/02/2012 20:42, ArkanoiD wrote:

> >BTW it is quite funny that Google does not have their own intermediate CA,
> >while Yandex has.
>

> 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

[Stephen Schultze]

Those of you wishing to follow along at home may be interested in the bug:

Remove Trustwave Certificate(s) from trusted root certificates
https://bugzilla.mozilla.org/show_bug.cgi?id=724929

[Kathleen Wilson]

On 2/7/12 4:37 PM, Stephen Schultze wrote:
> Those of you wishing to follow along at home may be interested in the bug:
>
> Remove Trustwave Certificate(s) from trusted root certificates
> https://bugzilla.mozilla.org/show_bug.cgi?id=724929
>
> On 2/2/12 1:03 PM, Tom Ritter wrote:
>> 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.

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

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?

http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html
--
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 Statement

and provide public attestation of the subordinate CA's conformance to

the stated verification requirements and other operational criteria by a
competent independent party or parties with access to details of the

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

Kathleen

[Jan Schejbal]

Am 2012-02-08 19:15, schrieb Kathleen Wilson:
>
> 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?

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

Kind regards,
Jan



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

[Stephen Schultze]

On 2/8/12 4:23 PM, Jan Schejbal wrote:
> I would suggest an explicit statement by Mozilla that

[...]

> 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

Jan, quick question. Are you suggesting public disclosure or
confidential disclosure to Mozilla? I of course favor the former.

[Jan Schejbal]

Am 2012-02-08 22:43, schrieb Stephen Schultze:
>
> Jan, quick question. Are you suggesting public disclosure or
> confidential disclosure to Mozilla? I of course favor the former.

I am suggesting disclosure to the potentially affected audience, i.e.
all Mozilla users, i.e. the public.

[ianG]

On 9/02/12 08:23 AM, Jan Schejbal wrote:

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

IMHO, the policy requires disclosure. There are two counts here, being
issuing MITMs deliberately, and failing to disclose this in published
documentation.

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.

> It might also be worth requiring all CAs to issue Third-party Sub-CAs
> from a separate intermediate.

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 :)



iang

[Stephen Schultze]

On 2/8/12 7:41 PM, ianG wrote:
> On 9/02/12 08:23 AM, Jan Schejbal wrote:
>
>> 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.
>
>
> IMHO, the policy requires disclosure. There are two counts here, being
> issuing MITMs deliberately, and failing to disclose this in published
> documentation.
>
> 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.

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:

https://bugzilla.mozilla.org/show_bug.cgi?id=724929#c41

Unfortunately, not all SubCAs are disclosed:

https://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/bed934bffdbf30de/50e0744dfa5fdf70#50e0744dfa5fdf70

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

[Peter Gutmann]

Jan Schejbal <jan.sche...@gmx.de> writes:

> a) this sort SubCA is strictly not allowed

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?

Peter.

[ArkanoiD]

And nothing may prevent Mozilla from dropping the root afterwards -- and it *is* the proper
action.

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.

[Jan Schejbal]

Am 2012-02-09 15:59, schrieb Peter Gutmann:
> 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.

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.

> Put another way, what do you think will win out for a CA, Mozilla's CA Policy
> or a National Security Letter?

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"