DRAFT CA Communication, Feb 2012

[Kathleen Wilson]

All,

Here is a proposed DRAFT of a CA Communication that I would like to send
soon. I will greatly appreciate your constructive feedback.

Note that the “<date TBD>” is proposed because any such customers are
probably very large enterprise customers who likely will have to bring
up a corporate certificate infrastructure and deploy a new root to tens
of thousands of heterogeneous devices, and their corporate network may
include WiFi access points, and therefore also mobile devices. I am
thinking that the date should be something between 2 and 3 months after
the official communication is sent.

==
Subject: Mozilla Communication: Action requested by <date 2 weeks out>

Dear Certification Authority,

This note requests a set of immediate actions on your behalf, as a
participant in the Mozilla root program.

Please reply by <date 2 weeks out> to confirm completion of the
following actions or state when these actions will be completed.

1) Subordinate CAs chaining to CAs in Mozilla’s root program may not be
used for MITM purposes, regardless of whether it is in a closed and
controlled environment or not. Please review all of your subordinate CAs
to make sure that they may not be used for MITM purposes. Any existing
subordinate CAs that may be used for that purpose must be revoked and
any corresponding HSMs destroyed by <date TBD>. For each subordinate CA
that is revoked, send me:
a) The certificate that signed the subCA. If it is a root certificate in
NSS, then the root certificate's subject and SHA1 fingerprint.
b) The Serial Number of the revoked certificate.
c) The CRL that contains the serial number of the revoked certificate.

As a CA in Mozilla’s root program you are ultimately responsible for
certificates issued by you and your subordinate CAs. After <date TBD> if
it is found that a subordinate CA is being used for MITM, we will remove
the corresponding root certificate. Based on Mozilla’s assessment, we
may also remove any of your other root certificates, and root
certificates from other organizations that cross-sign your certificates.

2) Please add a statement to your CP/CPS committing that you will not
issue a subordinate certificate that may be used for MITM or traffic
management of domain names or IPs that the party does not legitimately
own or control. Send me the URL to the updated document(s) and the
impacted sections or page numbers.

3) It has come to our attention that there may still be EV SSL
certificates that do not comply with all of the requirements of the EV
guidelines. Please review all of your EV SSL certificates and revoke any
that do not meet the EV requirements. This includes, but is not limited
to maximum validity period of the certificate, subject naming, minimum
key sizes, required extensions, and maximum expiration time of OCSP
responses.

4) Certificates chaining to root certificates in Mozilla’s root program
should not have 512-bit keys or MD5 algorithms. Please scan the
certificates chaining to your root certificates in NSS, and revoke any
certificates that contain small key sizes or MD5 algorithms.

5) The CA/Browser Forum has released the "Baseline Requirements for the
Issuance and Management of Publicly Trusted Certificates,” which is
available here: http://www.cabforum.org/. Discussions are in progress in
the mozilla.dev.security.policy forum to update Mozilla’s CA Certificate
Policy to require that CAs meet these baseline requirements for issuance
of SSL/TLS certificates. Please contribute to the discussions in the
mozilla.dev.security.policy forum, and update your operations and
documentation as needed to meet the baseline requirements by the
effective date of July 1, 2012.

Participation in Mozilla's root program is at our sole discretion, and
we will take whatever steps are necessary to keep our users safe.
Nevertheless, we believe that the best approach to safeguard that
security is to work with CAs as partners, to foster open and frank
communication, and to be diligent in looking for ways to improve. Thank
you for your participation in this pursuit.

Regards,
Kathleen Wilson
Module Owner of Mozilla's CA Certificates Module

===

[Eddy Nigg]

Hi Kathleen,

On 02/13/2012 12:33 AM, From Kathleen Wilson:

> 2) Please add a statement to your CP/CPS committing that you will not
> issue a subordinate certificate that may be used for MITM or traffic
> management of domain names or IPs that the party does not legitimately
> own or control. Send me the URL to the updated document(s) and the
> impacted sections or page numbers.

I think this requirement is wrong in that if a CPS doesn't have a
stipulation for that, the CA supposedly isn't doing it. E.g. The CA must
have a clear policy under which circumstances a certificate may be
issued, which incidentally should be compliant to the Mozilla CA Policy.
(For example the StartCom CA Policy has clear disclosure about the
validation requirements and it's almost an insult to me to have such a
statement as the above included in the policy - as if there was ever a
policy that could have allowed that or would even be considered).

Rather, I suggest to require FULL public disclosure of all CP/CPS within
the responsibility of any CA root and if any of them has a stipulation
other than the Mozilla CA Policy, to eliminate them within XXX time.
Should Mozilla or any other party (Google's Chrome certificate pinning)
find such certificates, Mozilla would be forced to act accordingly.

> 3) It has come to our attention that there may still be EV SSL
> certificates that do not comply with all of the requirements of the EV
> guidelines. Please review all of your EV SSL certificates and revoke
> any that do not meet the EV requirements. This includes, but is not
> limited to maximum validity period of the certificate, subject naming,
> minimum key sizes, required extensions, and maximum expiration time of
> OCSP responses.

I'm not sure if this issue should be dealt with separately, it appears
to drown between all the rest. Also if you know about such certificates,
you should draw the attention of that CA and maybe also open a bug for
each of them.

>
> 4) Certificates chaining to root certificates in Mozilla’s root
> program should not have 512-bit keys or MD5 algorithms.

Didn't you meant to say 1024bit? Shouldn't the required minimum supposed
to be 2048 bit these days?

>
> 5) The CA/Browser Forum has released the "Baseline Requirements for
> the Issuance and Management of Publicly Trusted Certificates,” which
> is available here: http://www.cabforum.org/. Discussions are in
> progress in the mozilla.dev.security.policy forum to update Mozilla’s
> CA Certificate Policy to require that CAs meet these baseline
> requirements for issuance of SSL/TLS certificates. Please contribute
> to the discussions in the mozilla.dev.security.policy forum, and
> update your operations and documentation as needed to meet the
> baseline requirements by the effective date of July 1, 2012.

Again, don't mix apples with oranges. I suggest to invite the community
not within such a publication (a serious issue in itself).

--
Regards

Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg

[David E. Ross]

In #5, after the sentence

> Discussions are in progress in
> the mozilla.dev.security.policy forum to update Mozilla’s CA Certificate
> Policy to require that CAs meet these baseline requirements for issuance
> of SSL/TLS certificates.

insert the additional sentence: "Mozilla reserves the right to impose in
its policy revision requirements beyond those Baseline Requirements."

After all, the CA/Browser Forum established BASELINE (i.e., minimal)
requirements, not maximal requirements.

--

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

[Jan Schejbal]

Am 2012-02-12 23:33, schrieb Kathleen Wilson:
>
> Here is a proposed DRAFT of a CA Communication that I would like to
> send soon. I will greatly appreciate your constructive feedback.

Thank you!

> Note that the “<date TBD>” is proposed because any such customers
> are probably very large enterprise customers who likely will have to
> bring up a corporate certificate infrastructure and deploy a new root
> to tens of thousands of heterogeneous devices, and their corporate
> network may include WiFi access points, and therefore also mobile
> devices.

Everyone with any common sense had to know that such certificates are
not acceptable, and they should never have been issued. Not just the CAs
- system administrators who use such a model know very well that what
they are doing is nothing else than a MitM attack.

Allowing months to pass just to protect those that blatantly violate
policies and their customers who perform MitM attacks seems just wrong.

Unless someone actually uses the same CA for attacking SSL and
protecting their own network:
a) They do not need to roll this out immediately, they just need to
stop doing MitM attacks until they managed to roll it out
b) They only need to roll out to clients to be MitM-ed, i.e. not all
WiFi APs etc.

I do not see any reason why knowingly allowing MitM attacks would be a
good idea. Therefore, I think the date for the revocation should still
be 2 weeks at most.

> b) The Serial Number of the revoked certificate.

I would suggest the full certificate including information about who it
was issued to. In my opinion, this needs to be disclosed to the
potentially affected audience, i.e. users of Mozilla products, i.e. the
public. I am sure that, with sufficient motivation, the CAs will find a
way to make this possible. We wouldn't accept "a contract prevents us
from revoking the MitM CA" for an answer, either. I would consider it OK
to allow for some additional time for this, as this is where possibly
multiple legal departments may need to work together. This is why I
suggested (and still suggest) 1 month from the announcement for disclosure.

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

[Eddy Nigg]

On 02/13/2012 01:19 AM, From Eddy Nigg:

> Rather, I suggest to require FULL public disclosure of all CP/CPS
> within the responsibility of any CA root and if any of them has a
> stipulation other than the Mozilla CA Policy, to eliminate them within
> XXX time. Should Mozilla or any other party (Google's Chrome
> certificate pinning) find such certificates, Mozilla would be forced
> to act accordingly.

I was thinking about this some more and for various reasons I don't
think that this communication is either going to contribute much nor is
it really necessary.

Look, Mozilla has a policy, there is no reason to require something that
doesn't comply to the policy anyway. The policy hasn't changed and I'd
advise Mozilla to apply its own policy, simply as that.

When we were working on the baselines requirements, clear guidelines
have been defined under which circumstances server certificates can be
issued. The Mozilla CA Policy has also a clear definition for a while
now. The EV guidelines also have clear requirements set forth...

So what exactly do you want say? That CAs must comply to the policies or
else? Isn't this just a bit too little too late or simply not relevant
for the majority of CAs anyway? Wouldn't it be much better to apply your
policy now to the letter? Don't you know what your policy says and how
to enforce it?

I'm also concerned that yet another communication from Mozilla will
result in an inflation of such messages, eventually they'll not have the
desired effect. In the proposed communication there is nothing new,
nothing that wasn't require before. Instead what I however would propose is:

A) Require from now on disclosure of ALL policies and practices
statements that are related to a particular root
B) Disclosure of ALL CA certificates (sub or cross-signed) to a
particular root


at every new inclusion request and for every submitted yearly audit
statement that Mozilla requires to be submitted by the CAs. Within less
than a year, Mozilla should have all policies and CA certificates that
are chained to a root included in Mozilla software disclosed.

As to particular incidents, unexpected disclosures, non-compliance to
the various policies (Mozilla, Baselines, EV), Mozilla should have a
policy in place about what to do. Is your policy is to send out a
communication every time some CA doesn't comply to the requirements set
forth....?

[Dominik Schäfer]

Hi Kathleen,

12. Februar 2012 23:33:24 UTC+1 Kathleen Wilson:

> Note that the “<date TBD>” is proposed because any such customers are
> probably very large enterprise customers who likely will have to bring

> up a corporate certificate infrastructure [... ]I am

> thinking that the date should be something between 2 and 3 months after
> the official communication is sent.

While I would also prefer a much shorter time frame: what about at least a compromise if that is not possible? Require them to report the SHA1 fingerprint, subject, serial number within 2 weeks and publish the checksum somewhere. Then users could use an add-on to block them (although it would be nicer, if FF & Co already had a possibility to block certificates based on checksum, optional pinning etc.) and you might give the CA more time to officially revoke the certificate.
I would also suggest to publish the available information about the certificates once they have been revoked.
FTR: I strongly support Eddy's suggestion concerning full public disclosure of CP/CPS.

(Side note: it might be beneficial to work with the EFF SSL observatory (especially once they deployed their distributed approach in HTTPS Everywhere) to find suspicious certificates.)

Bye,
Dominik

[maniacmartin]

I share Jan's opinion on this.

Any company large enough to go to the hassle of getting a trusted
subordinate CA and have the knowledge necessary to deploy such a MITM
attack solution almost certainly knows what they're doing is wrong. I
don't see why they should be allowed to continue violating the policy
for months rather than switching off the interception until they have
another solution in place.

Given that subordinate CAs have the power to grant certificates for
any domain, I believe that our trusted root CA holders should have an
obligation to publicly publish a list of who they have granted
subordinate CAs to, and keep such a list up to date. (Although
ultimately, the root CA holder is responsible for the actions of their
subordinates).

[Dominik Schäfer]

Hi Kathleen,

12. Februar 2012 23:33:24 UTC+1 Kathleen Wilson:

> Note that the “<date TBD>” is proposed because any such customers are
> probably very large enterprise customers who likely will have to bring

> up a corporate certificate infrastructure [... ]I am

> thinking that the date should be something between 2 and 3 months after
> the official communication is sent.

[Kai Engert]

Kathleen, Eddy, Jan,

All,

the motivation for "give all CAs a grace period" is based on the
assumption "there are several other CAs who are involved in the
corporate-environment-MITM-business".

The assumption might be right or wrong. We don't know yet.

If we immediately execute the punishment, everyone will (morally
rightful) expect that we repeat the punishment for any future CA being
detected, with immediate effect - for all MITM activities that are
currently still ongoing and that we will learn about in the future. (Who
knows how many employees of such environments already made a backup copy
of such a MITM certificate, can proof that the cert hasn't been revoked
and is still valid as of today, and are waiting to submit until after we
made such an ultimate decision, knowing that their submission causes
end-of-business for such CAs?)

We don't know yet how many CAs would have to be punished. What if we'd
have to punish a set of major CAs that has certified more than 50% of
the secure web? If this unfortunate assumption were true, wouldn't we
cause an immediate shutdown of a large percentage of the secure web and
create lots of chaos? This is the dilemma we are facing. Under the
assumption that such MITM uses are indeed limited to closed corporate
environments, this immediate chaos, and the amount of potential
economical harm caused, might be worse than the immediate benefit of
shutting down the corporate internal watching. (Under the assumption
that MITM is indeed limited to corporate environments, I'm willing to
change my opinion 180° on the first proof of MITM outside of a corporate
network made possible by one of the CAs in the Mozilla CA program.)

The use of MITM CA certs in corporate networks is an unethical practice
and we should stop it as quickly as we can.

I still believe it's a good idea to grant a short grace period for CAs
to learn about the new guaranteed punishment, because we clarify that
MITM subCA behaviour is always absolutely unacceptable, even in
controlled corporate environments, and give them an opportunity to act
accordingly and stop it immediately.

I originally bought the argument that 2-3 months are a necessary period
of time to allow for transitioning.

However, I very much like Jan Schejbal's new argument:

> a) They do not need to roll this out immediately, they just need to
> stop doing MitM attacks until they managed to roll it out
> b) They only need to roll out to clients to be MitM-ed, i.e. not all
> WiFi APs etc.

I agree with Jan's argument that the internal "MITM needs" of corporate
environments aren't sufficient reason to allow for a long transition
period. I agree the transitioning argument shouldn't play a role when
making a decision for the length of the grace period. If a corporation
depends on MITM practices involving trusted public CAs (instead of the
cleaner solution of using a private CA), it's the coporation's problem
that they will temporarily be unable to watch all employee's traffic, it
doesn't matter for the public web community.

I still believe we need to give CAs a chance to investigate their list
of issued subCA and make decisions for themselves, which subCAs they are
willing to continue to trust (because they are 100% sure they have
strong control) and which subCAs are "too risky" from now on, because an
abuse performed by a customer could mean the immediate end of a major
part of their CA business.

Maybe one month should indeed be a sufficient amount of time for CAs to
make such assessment for their set of issued subCAs.

If, during this period of time, at least one more CA goes public,
consequently revokes such MITM subCAs certificates, and promises to not
do it again, then we have done something good for the security of the
web. I agree with the argument made earlier, this scenario is better
than having several large CAs decide that complete secrecy is the only
chance left to save their business.

However, I would like to make everyone aware of an additional potential
outcome.

After the grace period, what if we learn that Trustwave was actually the
only CA that participated in the corporate MITM business?

Maybe we will learn that no other CA has the need to come clean?

Maybe all the other CAs in the Mozilla root program decide they have
nothing to hide, and are not worried by the threat "Mozilla will remove
you from the Mozilla CA program if we discover any of your subCAs is
used by anyone for MITM practices"?

In my opinion, if this should happen, if we learn at the end of the
grace period that Trustwave was actually the only CA involved in the
corporate MITM business, because no other CA made use of the offer to
come clean, because all CAs accept the rule "MITM detected and you're
out", then we will still have the right to remove TrustWave, and under
such circumstances we should probably do so.

Kai

--
Sending me encrypted e-mail:
- get my S/MIME cert from https://kuix.de/smime-keyserver/
- get my GPG/PGP key from http://pgp.uni-mainz.de/

[Kai Engert]

On 13.02.2012 11:03, Dominik Schäfer wrote:
>
> Require them to report the SHA1 fingerprint, subject, serial number within 2 weeks and publish the checksum somewhere.

In general I agree, it would be good if CA published the "subject name"
of intermediate certificates. This means we'd learn who actually
deployed such intermediates.

But I'm worried that it might be a problem for CAs to publish that, they
might not be allowed to make customer relationships public because of
contracts.

I'm worried the requirement to make the "subject name"s public
immediately would unnecessarily delay the process of getting
intermediates revoked and announced, because CAs might argue they have
to check with lawyers first, etc.

I propose, our immediately call should be restricted to the details that
are sufficient for blocking such certificates, in order to allow for a
quick turnaround, and avoid giving CAs a legal argument for being unable
to comply with our request.

We don't strictly require the "subject name" of the intermediate CA for
blocking.

The "Issuer DN" and the "serial number" (binary encoding of both) are
the usual primary key to identify certificates (at least in the NSS
library) and should be sufficient for the purpose of blocking.

Kai

[Eddy Nigg]

On 02/13/2012 08:13 PM, From Kai Engert:

> The assumption might be right or wrong. We don't know yet.

I might be naive, but I don't expect it.

> The use of MITM CA certs in corporate networks is an unethical
> practice and we should stop it as quickly as we can.

That's not the issue (I don't have an opinion about ethics that much),
but it's not compliant to any stated policy, requirement and audit
criteria. You have a policy in place, you made a promise to your users
and you have to enforce your policy, that's all.

Is there really something to stop here? Where are the CA policies that
disclose such a practice? In fact, where is Trustwave's policy that
disclosed it? If there are CAs that violate their own polices and on
purpose violate the requirements Mozilla set forth, nuke them. Or define
a new set of requirements. Or do nothing.

But what you are really saying is that you believe there might be CAs
that have violated the Mozilla CA policy (amongst others obviously) and
you beg them to come in compliance with the policy. What if tomorrow yet
another CA comes forth with yet another practice that violates some
other aspects of the the policy? Beg them too? Send another
communication, another grace period? It's starting to become a joke really.

[Kai Engert]

Technical info:

Today I failed to post to this list via NNTP.
I had to switch to submission by email.

If you have attempted to send messages to this newsgroup by NNTP, then
please check that your posting went through. If not, please resubmit
using a different mechanism, e.g. by subscribing via
https://lists.mozilla.org/listinfo/dev-security-policy

Kai

(reference: bugzilla 726678)

[Gary Gapinski]

On 02/13/2012 01:39 PM, Kai Engert wrote:
> Technical info:
>
> Today I failed to post to this list via NNTP.
> I had to switch to submission by email.

I've had the same problem with this group and mozilla.dev.tech.crypto.

[Eddy Nigg]

On 02/13/2012 08:45 PM, From Gary Gapinski:

> I've had the same problem with this group and mozilla.dev.tech.crypto.

NNTP works just fine here.

[Gary Gapinski]

On 02/13/2012 01:39 PM, Kai Engert wrote:

> Technical info:
>
> Today I failed to post to this list via NNTP.
> I had to switch to submission by email.

[Kathleen Wilson]

On 2/12/12 2:33 PM, Kathleen Wilson wrote:

> All,
>
> Here is a proposed DRAFT of a CA Communication that I would like to send
> soon. I will greatly appreciate your constructive feedback.
>

All,

Thank you for your thoughtful and constructive feedback. Here is a
second draft of the CA Communication.

It sounds like “<date TBD>” should be 2 months after the official
communication is sent.

I thought about whether all of this should be included in one
communication, or separated out into multiple communications. I would
like to keep it as one communication with 5 action items to track for
each CA.

Thanks,
Kathleen
===

Subject: Mozilla Communication: Action requested by <date 2 weeks out>

Dear Certification Authority,

This note requests a set of immediate actions on your behalf, as a
participant in the Mozilla root program.

Please reply by <date 2 weeks out> to confirm completion of the
following actions or state when these actions will be completed.

1) Subordinate CAs chaining to CAs in Mozilla’s root program cannot be

used for MITM or traffic management of domain names or IPs that the

party does not legitimately own or control, regardless of whether it is

in a closed and controlled environment or not. Please review all of your

subordinate CAs to make sure that they cannot be used in this way. Any
existing subordinate CAs that can be used for that purpose must be
revoked and any corresponding HSMs destroyed as soon as possible, but no
later than <date TBD>. For each subordinate CA that is revoked, send me:

a) The certificate that signed the subCA. If it is a root certificate in
NSS, then the root certificate's subject and SHA1 fingerprint.
b) The Serial Number of the revoked certificate.
c) The CRL that contains the serial number of the revoked certificate.

As a CA in Mozilla’s root program you are ultimately responsible for
certificates issued by you and your subordinate CAs. After <date TBD> if

it is found that a subordinate CA is being used for MITM, we will take
action to mitigate, including and up to removing the corresponding root

certificate. Based on Mozilla’s assessment, we may also remove any of
your other root certificates, and root certificates from other
organizations that cross-sign your certificates.

2) If you issue subordinate CAs to third parties, please add a statement

to your CP/CPS committing that you will not issue a subordinate

certificate that can be used for MITM or traffic management of domain

names or IPs that the party does not legitimately own or control. Send
me the URL to the updated document(s) and the impacted sections or page
numbers.

3) Please scan all of your EV SSL certificates and revoke any that do

not meet the EV requirements. This includes, but is not limited to
maximum validity period of the certificate, subject naming, minimum key
sizes, required extensions, and maximum expiration time of OCSP responses.

4) Certificates chaining to root certificates in Mozilla’s root program

should not have MD5 algorithms or key sizes less than 1000. Please scan

the certificates chaining to your root certificates in NSS, and revoke
any certificates that contain small key sizes or MD5 algorithms.

5) The CA/Browser Forum has released the "Baseline Requirements for the
Issuance and Management of Publicly Trusted Certificates,” which is
available here: http://www.cabforum.org/. Discussions are in progress in
the mozilla.dev.security.policy forum to update Mozilla’s CA Certificate

Policy to add a requirement that CAs also meet these baseline

[ianG]

One thing that grated my nerves was there was this important issue
(MITMing) and this unimportant issue (small keys) all mixed in together.

Maybe easier to separate them out? Even put a note in to one saying
look out for the other?

iang


PS: yes, the irony of small keys being used for MITMing is non-escapable :)

On 13/02/12 21:03 PM, Dominik Schäfer wrote:
> Hi Kathleen,
>
> 12. Februar 2012 23:33:24 UTC+1 Kathleen Wilson:

>> Note that the “<date TBD>” is proposed because any such customers are
>> probably very large enterprise customers who likely will have to bring

>> up a corporate certificate infrastructure [... ]I am

>> thinking that the date should be something between 2 and 3 months after
>> the official communication is sent.

> While I would also prefer a much shorter time frame: what about at least a compromise if that is not possible? Require them to report the SHA1 fingerprint, subject, serial number within 2 weeks and publish the checksum somewhere. Then users could use an add-on to block them (although it would be nicer, if FF& Co already had a possibility to block certificates based on checksum, optional pinning etc.) and you might give the CA more time to officially revoke the certificate.

> I would also suggest to publish the available information about the certificates once they have been revoked.
> FTR: I strongly support Eddy's suggestion concerning full public disclosure of CP/CPS.
>
> (Side note: it might be beneficial to work with the EFF SSL observatory (especially once they deployed their distributed approach in HTTPS Everywhere) to find suspicious certificates.)
>
> Bye,
> Dominik

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

[Ondrej Mikle]

On 02/13/2012 07:37 PM, Eddy Nigg wrote:
> On 02/13/2012 08:13 PM, From Kai Engert:

>> The assumption might be right or wrong. We don't know yet.
>

> I might be naive, but I don't expect it.

I'm quite sure there are more of CAs that issued certs for "traffic
management" based on the discussions in various lists.

We could ask Peter Gutmann, if Trustwave was the one he was talking
about. If it wasn't, he'll likely say "no", because it probably won't be
breach of the NDA. In the worst case we'll get another "you must be
joking, right?" answer ;-)

>
>> The use of MITM CA certs in corporate networks is an unethical
>> practice and we should stop it as quickly as we can.
>

> That's not the issue (I don't have an opinion about ethics that much),
> but it's not compliant to any stated policy, requirement and audit
> criteria. You have a policy in place, you made a promise to your users
> and you have to enforce your policy, that's all.
>
> Is there really something to stop here? Where are the CA policies that
> disclose such a practice? In fact, where is Trustwave's policy that
> disclosed it?

I peeked shortly the other day into Trustwave's CPS, Relying Party
Agreement/Warranty, they state in capitals: "TRUSTWAVE MAKES NO
REPRESENTATION OR WARRANTY AS TO THE BUSINESS PRACTICES OF THE TRUSTWAVE
SUBSCRIBERS." (This specific clause likely only covers monetary
compensation, but I have no idea if it could be twisted in court.)

Also, who has all the past documents (though there are _some_ old
versions listed)? They can change them at any time (I despise this
widespread contractual practice: "New version will be posted in your
local planning department in Alpha Centauri. It will be on display in
the bottom of a locked filing cabinet stuck in a disused lavatory with a
sign on the door saying 'Beware of The Leopard'".)

By looking at "Last-Modified" headers, CPS was changed in March 2011 and
RP Warranty in April 2009.

Ondrej

[Ondrej Mikle]

On 02/13/2012 11:25 PM, Kathleen Wilson wrote:
>
> Thank you for your thoughtful and constructive feedback. Here is a
> second draft of the CA Communication.
>

> ===
>
> 1) Subordinate CAs chaining to CAs in Mozilla’s root program cannot be

> used for MITM or traffic management of domain names or IPs that the

> party does not legitimately own or control, regardless of whether it is

> in a closed and controlled environment or not. Please review all of your

> subordinate CAs to make sure that they cannot be used in this way. Any
> existing subordinate CAs that can be used for that purpose must be
> revoked and any corresponding HSMs destroyed as soon as possible, but no

> later than <date TBD>. For each subordinate CA that is revoked, send me:

> a) The certificate that signed the subCA. If it is a root certificate in
> NSS, then the root certificate's subject and SHA1 fingerprint.
> b) The Serial Number of the revoked certificate.
> c) The CRL that contains the serial number of the revoked certificate.

I'd add:

d) the validity period (notBefore and notAfter) of the revoked certificate

> As a CA in Mozilla’s root program you are ultimately responsible for
> certificates issued by you and your subordinate CAs. After <date TBD> if

> it is found that a subordinate CA is being used for MITM, we will take

> action to mitigate, including and up to removing the corresponding root

> certificate. Based on Mozilla’s assessment, we may also remove any of
> your other root certificates, and root certificates from other
> organizations that cross-sign your certificates.

I'd like this to become reality, but it has potential to get stuck in
legal departments. For example, the CPSs for cross-signing certificates
I've seen explicitly state not being responsible for the CA they cross-sign.

> 4) Certificates chaining to root certificates in Mozilla’s root program

> should not have MD5 algorithms or key sizes less than 1000. Please scan

> the certificates chaining to your root certificates in NSS, and revoke
> any certificates that contain small key sizes or MD5 algorithms.

We could add the link you mentioned pointing to section 8:

http://www.mozilla.org/projects/security/certs/policy/MaintenancePolicy.html



Great job.

Ondrej

[Ondrej Mikle]

On 02/13/2012 07:37 PM, Eddy Nigg wrote:
>

> But what you are really saying is that you believe there might be CAs
> that have violated the Mozilla CA policy (amongst others obviously) and
> you beg them to come in compliance with the policy. What if tomorrow yet
> another CA comes forth with yet another practice that violates some
> other aspects of the the policy? Beg them too? Send another
> communication, another grace period? It's starting to become a joke really.

I don't see it as begging. I see it as "last chance to come clean or
enjoy joining the Diginotar bankruptcy club". AFAIK the greatest issue
in the past when delisting a CA was the potential threat of lawsuit
(setting rules should mitigate that).

My reasoning is:

1) Should Trustwave and other MitM-cert-issuing CAs be punished? Yes.

2) Would the yet-unknown CAs try to cover up their MitM certs if
threatened to be delisted now? Almost definitely yes. (It should be
noted here, that the Comodo fiasco would go unnoticed by public were it
not for Appelbaum's crlwatch:
https://bugzilla.mozilla.org/show_bug.cgi?id=643056)

3) Does knowing and blacklisting the MitM certs offer better protection
for users than hunting the CAs one-by-one later? I think so.


Ondrej

[Rob Stradling]

On 14/02/12 13:13, Ondrej Mikle wrote:
<snip>

> (It should be noted here, that the Comodo fiasco would go unnoticed by public were it
> not for Appelbaum's crlwatch:
> https://bugzilla.mozilla.org/show_bug.cgi?id=643056)

Absolute rubbish!!!

Comodo made a quick decision that public disclosure was the right thing
to do, and we agreed a timeline with the major browser vendors to do
just that. The only reason to delay public disclosure for ~1 week was
to give the browsers time to patch.

Appelbaum just happened to discover independently what was going on
before the agreed ~1 week had elapsed.

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

[Ondrej Mikle]

On 02/14/2012 02:48 PM, Rob Stradling wrote:
> On 14/02/12 13:13, Ondrej Mikle wrote:
> <snip>
>> (It should be noted here, that the Comodo fiasco would go unnoticed by
>> public were it
>> not for Appelbaum's crlwatch:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=643056)
>
> Absolute rubbish!!!
>
> Comodo made a quick decision that public disclosure was the right thing
> to do, and we agreed a timeline with the major browser vendors to do
> just that. The only reason to delay public disclosure for ~1 week was
> to give the browsers time to patch.
>
> Appelbaum just happened to discover independently what was going on
> before the agreed ~1 week had elapsed.

In that case I apologize for the statement.

Ondrej

[Gervase Markham]

On 13/02/12 00:00, Jan Schejbal wrote:
> Everyone with any common sense had to know that such certificates are
> not acceptable, and they should never have been issued.

Those who don't live in the Internet/CA/crypto world may well not be
aware of this.

I can imagine the following logic at some big company:

- We have a problem. We need to either:
A) protect ourselves from data theft; or
B) comply with some regulatory requirement; or
C) know whether our employees are spending loads of time on Facebook
- We need a system which can analyse traffic
- This company sells them; buy one
- We need a thing called a certificate
- This company sells them; buy one
- Problem solved

I think it's unlikely that such companies know all the ramifications of
purchasing such a certificate.

> a) They do not need to roll this out immediately, they just need to
> stop doing MitM attacks until they managed to roll it out

If the system is in place for regulatory compliance (and I believe there
are circumstances where full monitoring of network traffic is necessary)
then turning it off isn't an option.

> I do not see any reason why knowingly allowing MitM attacks would be a
> good idea.

Perhaps we just fundamentally disagree on this, but I think that if a
company owns a network and wants to monitor all traffic on it, it has a
perfect right to do so. It's their network. Don't like it, don't use it
for secret stuff.

Gerv

[Eddy Nigg]

On 02/14/2012 03:13 PM, From Ondrej Mikle:

> I don't see it as begging. I see it as "last chance to come clean or
> enjoy joining the Diginotar bankruptcy club".

I didn't propose removing any CA root - but enforcing the policy. There
are various different ways and requirements that Mozilla can place on a
CA that doesn't comply to the policy before removing it as a last resort.

> AFAIK the greatest issue in the past when delisting a CA was the potential threat of lawsuit

BS

> 1) Should Trustwave and other MitM-cert-issuing CAs be punished?

No - "punishment" isn't how I would call it, but attach strings,
requirements and confirmations of whatever Mozilla wants to see
implemented by Trustwave.

What I've seen so far is yet another "communication" to the CAs -
however what I haven't seen is, which requirements it places on
Trustwave today and now.

And CAs would take note on that much more than yet on another
"communication".

[Ondrej Mikle]

On 02/14/2012 04:41 PM, Eddy Nigg wrote:
> On 02/14/2012 03:13 PM, From Ondrej Mikle:

>> I don't see it as begging. I see it as "last chance to come clean or
>> enjoy joining the Diginotar bankruptcy club".
>

> I didn't propose removing any CA root - but enforcing the policy. There
> are various different ways and requirements that Mozilla can place on a
> CA that doesn't comply to the policy before removing it as a last resort.

Maybe you could give some suggestions. I've seens using "comply to
policy" and "enforce policy" many times, but I have only really vague
idea about real meaning behind those phrases (aside from what was
mentioned in Kathleen's letter).

>> AFAIK the greatest issue in the past when delisting a CA was the
>> potential threat of lawsuit
>

> BS

Not my words
(https://lists.mozilla.org/newsportal/article.php?id=6172&group=mozilla.dev.security.policy):

"When we wrote the Mozilla policy, we inserted that Mozilla had the sole
right to decide when to pull a root. When I suggested that (yes, blame
me now) I knew that any suggestion to pull a root would immediately
cause a counter-balancing lawsuit by CAs with cashflow in mind. (Which
would win, ask your lawyer how to stop anything with an injunction.)"

>
>> 1) Should Trustwave and other MitM-cert-issuing CAs be punished?
>

> No - "punishment" isn't how I would call it, but attach strings,
> requirements and confirmations of whatever Mozilla wants to see
> implemented by Trustwave.

Just to be clear here, by "punishment" I wasn't insinuating pulling
Trustwave's (or other CA's root/trust anchor) just yet. Nevertheless all
the MitM subCA certs should be published.

I don't know what tools are available for Mozilla to "enforce policy".
How you prove non-existence of MitM cert anyway?

>From my personal experience, telling a CA to revoke cert with 512-bit
that could be used for code-signing (had the "right" KU and EKU, trusted
by Mozilla and Microsoft) was akin to chatting with /dev/null. It was
around the time of the signed-malware case; those certs were not yet
known by anyone else (I sent the certs to Mozilla security team before
sending message to CA directly as well).

Ondrej

[Jan Schejbal]

Am 2012-02-14 16:06, schrieb Gervase Markham:
> I can imagine the following logic at some big company:
>
> - We have a problem. We need to either:
> A) protect ourselves from data theft; or
> B) comply with some regulatory requirement; or
> C) know whether our employees are spending loads of time on Facebook
> - We need a system which can analyse traffic
> - This company sells them; buy one
> - We need a thing called a certificate
> - This company sells them; buy one

I think this step will not be as simple, given that it involves a HSM
and a CA cert, which is not something you just buy like loaf of bread. I
do not consider it a believable scenario that noone who knows what SSL
and CAs do will be involved in such an act.

[Eddy Nigg]

On 02/14/2012 06:41 PM, From Ondrej Mikle:

> Maybe you could give some suggestions. I've seens using "comply to

> policy" and "enforce policy" many times...

I would have some ideas... ;-)

But I'm certain Mozilla could have theirs too.

> Not my words
> (https://lists.mozilla.org/newsportal/article.php?id=6172&group=mozilla.dev.security.policy):

As it happens I happen to disagree with 90% of what Ian has to say. I
got kind of used to it, but to you I suggest not to expect everything he
says to be actually correct either. It's his opinion, not actual facts.

> Just to be clear here, by "punishment" I wasn't insinuating pulling
> Trustwave's (or other CA's root/trust anchor) just yet.

Yep, at this time I don't think it's necessary as most likely Mozilla's
users aren't anymore in danger today. But we want to be really sure
about that, aren't we?! So here the policy has to bite and strong.

> Nevertheless all the MitM subCA certs should be published.

I believe that all CA certificates in every PKI that has roots in
Mozilla should be disclosed today. There is no other way around I'm afraid.

[ianG]

On 15/02/12 08:27 AM, Eddy Nigg wrote:
> On 02/14/2012 06:41 PM, From Ondrej Mikle:

>> Not my words
>> (https://lists.mozilla.org/newsportal/article.php?id=6172&group=mozilla.dev.security.policy):
>>
>

> As it happens I happen to disagree with 90% of what Ian has to say. I
> got kind of used to it, but to you I suggest not to expect everything he
> says to be actually correct either. It's his opinion, not actual facts.

Eddy's opinion on facts is recursive, to a 90% confidence level :)

Or is that, facts on opinion...

iang

[Eddy Nigg]

On 02/14/2012 11:27 PM, From Eddy Nigg:

> On 02/14/2012 06:41 PM, From Ondrej Mikle:
>> Maybe you could give some suggestions. I've seens using "comply to
>> policy" and "enforce policy" many times...
>
> I would have some ideas... ;-)
>
> But I'm certain Mozilla could have theirs too.

But here a practical suggestion nevertheless - require from from
Trustwave to update their policies to make crystal clear under which
circumstances a certificate may be issued and require an out-of-schedule
audit report (complete re-audit) by a different auditor than their
current one until end April 2012. Suggested are probably either KPMG,
Deloitte or E&Y.

If you go back to the inclusion request of Trustwave I recall that their
choice of auditor was raising my attention, you can see that audit
report here: https://cert.webtrust.org/SealFile?seal=359&file=pdf

[ianG]

On 15/02/12 03:41 AM, Ondrej Mikle wrote:
> On 02/14/2012 04:41 PM, Eddy Nigg wrote:
>> On 02/14/2012 03:13 PM, From Ondrej Mikle:

>>> AFAIK the greatest issue in the past when delisting a CA was the
>>> potential threat of lawsuit
>>

>> BS

>
> Not my words
> (https://lists.mozilla.org/newsportal/article.php?id=6172&group=mozilla.dev.security.policy):
>

> "When we wrote the Mozilla policy, we inserted that Mozilla had the sole
> right to decide when to pull a root. When I suggested that (yes, blame
> me now) I knew that any suggestion to pull a root would immediately
> cause a counter-balancing lawsuit by CAs with cashflow in mind. (Which
> would win, ask your lawyer how to stop anything with an injunction.)"

Onrej, you're possibly reading too much into that. Let me put some more
context on the table.

In those times it was also clear that the CAs were quite capable of
fighting, including subjecting the group with dominating volumes of
contributers and posting and specious arguments. As shown in recent times.

The choice in decision making was between trying to get a forum-voting
situation to work in an environment where CAs outnumbered those on the
user side, and some alternate. We wanted the former because it was
supposed to be an open-source project with open contributors.

We know that Mozilla as a single person won't do a better job than an
ideal crowd-sourced analysis. But we also know that when the CAs
outnumber the user-interested people, we wouldn't ever get the
crowd-analysis we wanted. It was a false hope.

The solution in the end therefore was a bit like Churchill's metric -
the best of several bad choices.



Now, in terms of "the biggest issue." No, the biggest issue wasn't so
much the injunction. The biggest issue was always how to identify the
right thing and then get that thing implemented. A limitation on both
systems - forum-voting and Mozilla dictatorship - was that if the
conclusion was signalled well in advance, a publically-listed company
would find itself needing to fight with e.g., an injunction. By law
they have to defend their assets, and "the right thing" is not to interfere.

So, giving Mozilla fiat in a dictatorship role at least allowed Mozilla
to play its cards close to its chest. Then, get it's decision
implemented in secret, then roll out the root revocation quickly. This
in simple terms reduces the impact of the injunction because an
injunction does not reverse, it generally maintains the current balance.
E.g., the injunction would say "don't drop that root." It wouldn't
say "put that root back."

Ask a lawyer for more on how this works, it's complicated and a lot of
fun if you are involved. There is game-playing as well. The thing here
is that the legal injunction was perhaps just the tip of the iceberg, it
was a signal solid thing that would bring the whole process to a
grinding halt. It was the symbol not the full story.



What we have now is this: Mozilla poses a problem. Everyone on the
forum argues about it. Mozilla takes in some or many private
representations. It privately weighs up the arguments and decides.
Then implements. Sometimes it announces ahead of time ...



iang

[Kathleen Wilson]

On 2/12/12 2:33 PM, Kathleen Wilson wrote:
> All,
>
> Here is a proposed DRAFT of a CA Communication that I would like to send
> soon. I will greatly appreciate your constructive feedback.
>


All,

Thanks again for your thoughtful and constructive feedback.

I am posting a third draft for review, because I think the changes are
big enough to warrant another round.

Changes:

1) Hopefully made it clear in action #1 that it’s not just the subCA
certs directly signed by the root that need to be checked, but any
intermediate certs in the chain.

2) Added a paragraph in action #1 to give notice that I am planning to
provide a publicly available list of the CA responses to each action
item in the communication, and to recommend specific responses to #1.

3) Updated action #4 again… “RSA keys shorter than 1024 bits long”

Thanks,
Kathleen
===
Subject: Mozilla Communication: Action requested by <date 2 weeks out>

Dear Certification Authority,

This note requests a set of immediate actions on your behalf, as a
participant in the Mozilla root program.

Please reply by <date 2 weeks out> to confirm completion of the
following actions or state when these actions will be completed.

1) Subordinate CAs chaining to CAs in Mozilla’s root program cannot be
used for MITM or “traffic management” of domain names or IPs that the

certificate holder does not legitimately own or control, regardless of

whether it is in a closed and controlled environment or not. Please

review all of the subordinate CAs that chain up to your root
certificates in NSS to make sure that they cannot be used in this way.

Any existing subordinate CAs that can be used for that purpose must be
revoked and any corresponding HSMs destroyed as soon as possible, but no
later than <date TBD>. For each subordinate CA that is revoked, send me:
a) The certificate that signed the subCA. If it is a root certificate in
NSS, then the root certificate's subject and SHA1 fingerprint.
b) The Serial Number of the revoked certificate.
c) The CRL that contains the serial number of the revoked certificate.

As a CA in Mozilla’s root program you are ultimately responsible for

certificates issued by you and any intermediate CAs that chain up to
your roots. After <date TBD> if it is found that a subordinate CA is

being used for MITM, we will take action to mitigate, including and up
to removing the corresponding root certificate. Based on Mozilla’s
assessment, we may also remove any of your other root certificates, and
root certificates from other organizations that cross-sign your
certificates.

I am planning to publish a compiled list of CA responses to all of the
action items in this communication. Therefore, I recommend responding to
action item #1 with one of the following choices:
a) Does not apply, because we do not issue subCA certificates to third
parties.
b) SubCAs are technically and/or contractually restricted to only issue
certificates to domains that they legitimately own or control, and they
are specifically not allowed to use their subordinate certificates for
the purpose of MITM.
c) We are reviewing all of our subCAs and will take the necessary action
by <date>.
d) We have revoked such subCA certificates, and here is the requested
information.

2) If you issue subordinate CAs to third parties, please add a statement
to your CP/CPS committing that you will not issue a subordinate

certificate that can be used for MITM or “traffic management” of domain
names or IPs that the certificate holder does not legitimately own or

control. Send me the URL to the updated document(s) and the impacted
sections or page numbers.

3) Please scan all of your EV SSL certificates and revoke any that do
not meet the EV requirements. This includes, but is not limited to
maximum validity period of the certificate, subject naming, minimum key
sizes, required extensions, and maximum expiration time of OCSP responses.

4) Certificates chaining to root certificates in Mozilla’s root program

should not have MD5 algorithms or RSA keys shorter than 1024 bits long.

Please scan the certificates chaining to your root certificates in NSS,
and revoke any certificates that contain small key sizes or MD5 algorithms.

5) The CA/Browser Forum has released the "Baseline Requirements for the
Issuance and Management of Publicly Trusted Certificates,” which is
available here: http://www.cabforum.org/. Discussions are in progress in
the mozilla.dev.security.policy forum to update Mozilla’s CA Certificate
Policy to add a requirement that CAs also meet these baseline
requirements for issuance of SSL/TLS certificates. Please contribute to
the discussions in the mozilla.dev.security.policy forum, and update
your operations and documentation as needed to meet the baseline
requirements by the effective date of July 1, 2012.

The currently proposed updates to Mozilla’s CA Certificate Policy are here:
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress

[Jeffrey Walton]

On Feb 13, 10:26 pm, ianG <i...@iang.org> wrote:
> One thing that grated my nerves was there was this important issue
> (MITMing) and this unimportant issue (small keys) all mixed in together.
>
> Maybe easier to separate them out?  Even put a note in to one saying
> look out for the other?
>

I tend to agree with Ian here. Perhaps two separate, concurrent
actions should be posted.

[Jeffrey Walton]

On Feb 12, 5:33 pm, Kathleen Wilson <kwil...@mozilla.com> wrote:
> All,
>
> Here is a proposed DRAFT of a CA Communication that I would like to send
> soon. I will greatly appreciate your constructive feedback.
>

> Note that the “<date TBD>” is proposed because any such customers are
> probably very large enterprise customers who likely will have to bring

> up a corporate certificate infrastructure and deploy a new root to tens
> of thousands of heterogeneous devices, and their corporate network may
> include WiFi access points, and therefore also mobile devices. I am

> thinking that the date should be something between 2 and 3 months after
> the official communication is sent.
>

> ==
> Subject: Mozilla Communication: Action requested by <date 2 weeks out>
>
> Dear Certification Authority,
>
> This note requests a set of immediate actions on your behalf, as a
> participant in the Mozilla root program.
>
> Please reply by <date 2 weeks out> to confirm completion of the
> following actions or state when these actions will be completed.
>

> 1) Subordinate CAs chaining to CAs in Mozilla’s root program may not be
> used for MITM purposes, regardless of whether it is in a closed and
> controlled environment or not. Please review all of your subordinate CAs
> to make sure that they may not be used for MITM purposes. Any existing
> subordinate CAs that may be used for that purpose must be revoked and
> any corresponding HSMs destroyed by <date TBD>. For each subordinate CA

> that is revoked, send me:
> a) The certificate that signed the subCA. If it is a root certificate in
> NSS, then the root certificate's subject and SHA1 fingerprint.
> b) The Serial Number of the revoked certificate.
> c) The CRL that contains the serial number of the revoked certificate.

This pertains to CA and law enforcement cooperation (which the
subordinate CA/MitM is one vector). I can imagine scenarios where a CA
will claim this sort of thing was done for law enforcement purposes.
Should there be an item specifically stating "law enforcement
requests" are not acceptable (versus "court order").

I've been to a few meetings with XXX and YYY. Fussion centers are hot
because it allows the US government to side step privacy laws since
the government can request information from corporate america without
judicial oversight. I'm concerned CAs will use "law enforcement
cooperation" as a blanket defense, when its really just a voluntary
cooperation (which should be subject to Mozilla administraive
actions).

Jeff

[Charles Reiss]

On 2/13/12 2:25 PM, Kathleen Wilson wrote:
> On 2/12/12 2:33 PM, Kathleen Wilson wrote:
>> All,
>>
>> Here is a proposed DRAFT of a CA Communication that I would like to send
>> soon. I will greatly appreciate your constructive feedback.
>>
>
>
> All,
>
> Thank you for your thoughtful and constructive feedback. Here is a
> second draft of the CA Communication.
>
> It sounds like “<date TBD>” should be 2 months after the official
> communication is sent.
>
> I thought about whether all of this should be included in one
> communication, or separated out into multiple communications. I would
> like to keep it as one communication with 5 action items to track for
> each CA.
>
> Thanks,
> Kathleen
> ===
> Subject: Mozilla Communication: Action requested by <date 2 weeks out>

[snip]

> including and up to removing the corresponding root
> certificate.

Suggest "including but not limited to" or similar for consistency with
the following sentence.

> Based on Mozilla’s assessment, we may also remove any of
> your other root certificates, and root certificates from other
> organizations that cross-sign your certificates.

[snip]

> 4) Certificates chaining to root certificates in Mozilla’s root program
> should not have MD5 algorithms or key sizes less than 1000.

Presumably you mean to specify that "1000" is in bits and don't mean to
apply this limit to elliptic curve certificates.

[snip]

- Charles

[Jeffrey Walton]

The problem is they [some company] don't own all segments of the
network in all cases. They may be able to do it if all traffic is
intrasite, but I find it hard to believe for general traffic destined
for hosts on the internet. For example, if the MitM certificate is
issued for Gmail, Hotmail, Stock Broker, etc, then the CA is knowingly
and willingly circumventing a computer security system and tampering
with communications (unless of course, Google, Microsoft, et al agreed
to be monitored). Rewriting the bits of a certificate (ie, issuing a
certificate for a domain not under control) to read the message is
clearly circumventing the security system, and its also tampering with
the communication. Circumventing computer security systems and
tampering with communications are federal crimes in the US.

Jeff

[Jeffrey Walton]

Regarding NSS and Firefox, they are Mozilla's toys. They should be
able to play with them however they like. I usually don't have a big
problem because they are generally concerned about thier users, and
not serving the interests of involved parties.

Jeff

[ianG]

On 15/02/12 13:11 PM, Jeffrey Walton wrote:

> This pertains to CA and law enforcement cooperation (which the
> subordinate CA/MitM is one vector). I can imagine scenarios where a CA
> will claim this sort of thing was done for law enforcement purposes.
> Should there be an item specifically stating "law enforcement
> requests" are not acceptable (versus "court order").
>
> I've been to a few meetings with XXX and YYY. Fussion centers are hot
> because it allows the US government to side step privacy laws since
> the government can request information from corporate america without
> judicial oversight. I'm concerned CAs will use "law enforcement
> cooperation" as a blanket defense, when its really just a voluntary
> cooperation (which should be subject to Mozilla administraive
> actions).

Right. Now we go to court, US government asserts state secrets, case
gets dropped.

Each time this happens, the world looks at Mozilla and asks why it lets
the US government ... but not other governments ... intercept our
communications? And why this seems to give carte blanche to other
governments to simply break it?

There is only one way out of this mess - never.

Even for the USG. The other way, an exception for the government we
happen to like, is a continuous spiral of anti-trust, as we find that
95% of the population don't actually have the same affiliation, and the
remaining 5% aren't so sure they wanted that result either.

This of course is fundamental to the design of PKI. Always was, always
will be.

iang

[Jeffrey Walton]

On Feb 17, 5:23 pm, ianG <i...@iang.org> wrote:
> On 15/02/12 13:11 PM, Jeffrey Walton wrote:
>

> > This pertains to CA andlbawbenforcementbcooperation (which the

> > subordinate CA/MitM is one vector). I can imagine scenarios where a CA
> > will claim this sort of thing was done for law enforcement purposes.
> > Should there be an item specifically stating "law enforcement
> > requests" are not acceptable (versus "court order").
>

> > I've been to a few meetings with XXX and YYY. Fusion centers are hot

> > because it allows the US government to side step privacy laws since
> > the government can request information from corporate america without
> > judicial oversight. I'm concerned CAs will use "law enforcement
> > cooperation" as a blanket defense, when its really just a voluntary

> > cooperation (which should be subject to Mozilla administrative

> > actions).
>
> Right.  Now we go to court, US government asserts state secrets, case
> gets dropped.

No problem, as long as the CA gets dropped also. This is about trust
and protecting [Mozilla] users, not protecting corporate america or
protecting a government.

Here's how I envision it:

* CA cooperates with law enforcement
(issues subordinate CA or by participates by other means)
* Mozilla asks for court order
* CA Refuses
* Mozilla drops CA

Another scenario:

* CA complies with court order
* Mozilla asks for court order
* CA Refuses
* Mozilla drops CA

And yet another:

* CA complies with court order
* Mozilla asks for court order
* CA provide Mozilla legal with court order
* Mozilla attempts to validate, finds order is fraudulent
* Mozilla drops CA

And even another (so there's no ambiguity):

* CA complies with court order
* Mozilla asks for court order
* CA provide Mozilla legal with valid court order
* Mozilla validates the court order
* No action taken

> Each time this happens, the world looks at Mozilla and asks why it lets
> the US government ... but not other governments ... intercept our
> communications?  And why this seems to give carte blanche to other
> governments to simply break it?

This applies to all governments and their pocket CAs - not just the
US.

> There is only one way out of this mess - never.

Right - Mozilla cannot stop government, but it can take decisive
action against CAs.

> Even for the USG.  The other way, an exception for the government we
> happen to like, is a continuous spiral of anti-trust, as we find that
> 95% of the population don't actually have the same affiliation, and the
> remaining 5% aren't so sure they wanted that result either.

Don't trust any government or any corporation. Period. I avoid PKI
like the plague.

> This of course is fundamental to the design of PKI.  Always was, always
> will be.

Right. Mozilla is in the envious position of being able to make a real
difference.

Speaking from experience, I had a clearance yanked because I would not
comply with actions that would have been illegal for me to perform as
a regular citizen. Doing illegal stuff for the government is still
illegal. For what its worth, the US Supreme Court has upheld the same
(not that its had any deterrence on the government).

Do you think Mozilla would have the courage to make those hard
decisions? How about if the US Government threatened the foundation
with revoking their tax exempt status?

Jeff

[Jan Schejbal]

Am 2012-02-23 05:34, schrieb Jeffrey Walton:
> * CA complies with court order
> * Mozilla asks for court order
> * CA provide Mozilla legal with valid court order
> * Mozilla validates the court order

* Mozilla drops CA and all other CAs from that country?

[Jan Schejbal]

Am 2012-02-26 17:07, schrieb Jan Schejbal:
> * Mozilla drops CA and all other CAs from that country?

Also note that by having a policy to drop a CA in such a case, the CA
would have a good argument in court why it shouldn't be forced to issue
such a certificate. Thus, the mere existence of such a policy may
protect users from wiretapping.

[ianG]

On 27/02/12 03:09 AM, Jan Schejbal wrote:
> Am 2012-02-26 17:07, schrieb Jan Schejbal:

>> * Mozilla drops CA and all other CAs from that country?
>

> Also note that by having a policy to drop a CA in such a case, the CA
> would have a good argument in court why it shouldn't be forced to issue
> such a certificate. Thus, the mere existence of such a policy may
> protect users from wiretapping.

Yes. Once a decision is established it can be signalled to others, who
can then use it in their defence.

Signalling and actions are very useful, when combined together. Either
apart have some flaws tho. First we require that decision :)

iang