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

===

Hi Kathleen,

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

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.

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.

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

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:    start...@startcom.org
Blog:    http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg

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

In #5, after the sentence
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

Am 2012-02-12 23:33, schrieb Kathleen Wilson:

Thank you!

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.

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

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

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

--
Regards

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

Hi Kathleen,

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

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

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

Hi Kathleen,

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

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

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:

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/

On 13.02.2012 11:03, Dominik Schäfer wrote:

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

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

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

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.

--
Regards

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

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)

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

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

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

NNTP works just fine here.

--
Regards

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

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

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

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

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

===

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:

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

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

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

On 02/13/2012 11:25 PM, Kathleen Wilson wrote:

I'd add:

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

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.

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

http://www.mozilla.org/projects/security/certs/policy/MaintenancePoli...

Great job.

Ondrej

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

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

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

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

On 02/14/2012 02:48 PM, Rob Stradling wrote:

In that case I apologize for the statement.

Ondrej

On 13/02/12 00:00, Jan Schejbal wrote:

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.

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.

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

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

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.

BS

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

--
Regards

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

On 02/14/2012 04:41 PM, Eddy Nigg wrote:

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

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

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

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?

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