Mozilla Communication: Action requested by March 2, 2012

[Kathleen Wilson]

The CA Communication has been sent.
===
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 March 2, 2012, 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 April 27, 2012. 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 April 27, 2012, 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 or your CP/CPS permits
you to do so in the future, 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

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 cooperation in this pursuit.

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

===

[Kathleen Wilson]

On 2/17/12 2:10 PM, Kathleen Wilson wrote:
> The CA Communication has been sent.
> ===

Added here:
https://wiki.mozilla.org/CA:Communications

[Kai Engert]

On 17.02.2012 23:10, Kathleen Wilson wrote:
> 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.

I had failed to read the third draft in time, and I'm reading this
paragraph just now.

A CA could reply with (b) and claim
"SubCAs are contractually restricted... and specifically not allowed
to use subCAs for the purpose of MITM"

What if we will find that such a subCA was abused for MITM purposes?

Does the communication make it sufficiently clear, that statement (1b)
will not release the parent CA's responsibility, and that we want to
treat the parent CA as responsible, regardless of customer breaking a
contract?

Thanks,
Kai

[Kathleen Wilson]

That paragraph was added to inform CAs that I plan to create and publish
a list of CA responses.

Regardless of how a CA responds to the communication:

"After April 27, 2012, 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."

Kathleen

[ianG]

On 18/02/12 09:44 AM, Kai Engert wrote:

> A CA could reply with (b) and claim
> "SubCAs are contractually restricted... and specifically not allowed to
> use subCAs for the purpose of MITM"
>
> What if we will find that such a subCA was abused for MITM purposes?

Simple. One side will argue that it is ok, this time, and we'll do
another amnesty, another letter, another more clear and direct change to
the CPS.

The other side will argue to drop the root.

> Does the communication make it sufficiently clear, that statement (1b)
> will not release the parent CA's responsibility, and that we want to
> treat the parent CA as responsible, regardless of customer breaking a
> contract?

Words are always as clear as they are. Actions are clearer :)


iang

[Kai Engert]

On 17.02.2012 23:59, Kathleen Wilson wrote:
> Regardless of how a CA responds to the communication:
> "After April 27, 2012, 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."

Kathleen, thanks for clarifying!
Kai

[Stephen Schultze]

I too did not have time to review the third draft before it went out.

I have one major concern:

You using softer "contractually restricted" language than the (soon to
be implemented?) proposed Mozilla Cert Inclusion Policy item #9 (found
here:
https://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html)

When discussing item #9, we specifically decided that alleged
contractual restrictions were not sufficient to protect against the
risks of unconstrained SubCAs.

Your message allows CAs to simply reply that:
"SubCAs are technically and/or *contractually* restricted to only issue

certificates to domains that they legitimately own or control"

Item #9 says:
"The CA must do one of the following for each external third party that
issues certificates. (Any external third party that can directly cause
the issuance of a certificate must be treated as a subordinate CA,
meeting one of the following two requirements.) [1: Name Constraints. 2:
Disclosure]"

Our community consensus language in item #9 correctly sees this as a
matter of practical cryptographic or operational ability to issue certs,
whereas your "contractual restrictions" language is weaker. Contractual
measures are simply not enforceable from the perspective of Mozilla or
its users -- indeed, they are not even knowable if they are not publicly
disclosed (and your email does not require disclosure of them).

Is it in dispute that any entity that has the operational or technical
ability to issue certificates for any domain, regardless of claimed
contractual restrictions, is one that "can be used for that purpose"
(aka: MITM)?

Regardless of the interpretation of your email, can we simply adopt and
require the text in item #9 now? If we had done this months ago when
the language was first written, we likely would have identified and
resolved the current issue before now. There has been no dispute over
that language, as far as I am aware, since it was written.

This course of action would be complimentary to the email you just sent,
and I propose that it be done immediately.

Steve

[Kathleen Wilson]

On 2/17/12 7:47 PM, Stephen Schultze wrote:
> On 2/17/12 5:59 PM, Kathleen Wilson wrote:
>> On 2/17/12 2:44 PM, Kai Engert wrote:
>>> On 17.02.2012 23:10, Kathleen Wilson wrote:
>>>> 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.
>>>
>

I agree that we need to finalize the proposed item #9 in
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html
and get it officially added to the policy soon.

It has also been brought to my attention that there is another problem
with option b in the communication:

"b) SubCAs are technically and/or contractually restricted to only issue

certificates to domains that they legitimately own or control..."

This cannot apply to subCAs that can issue end-entity certs to other
entities; e.g. Certificate Service Providers or government organizations.

I propose to add another option as a possible response to action #1,
such as:

"e) SubCAs are disclosed, audited, and technically and/or contractually
restricted to issue certificates in full compliance with the Mozilla CA
Certificate Policy. This includes not using their subordinate

certificates for the purpose of MITM.

I'd appreciate constructive feedback on this.

Kathleen

[Eddy Nigg]

On 02/18/2012 08:32 PM, From Kathleen Wilson:

> "e) SubCAs are disclosed, audited, and technically and/or
> contractually restricted to issue certificates in full compliance with
> the Mozilla CA Certificate Policy. This includes not using their
> subordinate certificates for the purpose of MITM.
>

If certificates must be issued in full compliance with the Mozilla CA
Policy, how can MITM'ing even be possible? Isn't this superfluous?

--
Regards

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

[Stephen Schultze]

On 2/18/12 1:32 PM, Kathleen Wilson wrote:
> I agree that we need to finalize the proposed item #9 in
> http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html
>
> and get it officially added to the policy soon.

I proposed that we do it immediately. Do you have a specific
counter-proposal? Why wait?

> It has also been brought to my attention that there is another problem
> with option b in the communication:
> "b) SubCAs are technically and/or contractually restricted to only issue
> certificates to domains that they legitimately own or control..."
>
> This cannot apply to subCAs that can issue end-entity certs to other
> entities; e.g. Certificate Service Providers or government organizations.
>
> I propose to add another option as a possible response to action #1,
> such as:
>
> "e) SubCAs are disclosed, audited, and technically and/or contractually
> restricted to issue certificates in full compliance with the Mozilla CA
> Certificate Policy. This includes not using their subordinate
> certificates for the purpose of MITM.
>
> I'd appreciate constructive feedback on this.

Sure, this sounds good and is complimentary to the proposed language in
item #9. I might slightly modify it for clarity to say:

"SubCAs are publicly disclosed to Mozilla, audited by a competent party
(per the Mozilla CA Certificate Policy) whose audit report has been
publicly disclosed to Mozilla, and technically and/or contractually

restricted to issue certificates in full compliance with the Mozilla CA
Certificate Policy."

I agree with Eddy that the MITM language may be superfluous, but on the
other hand it does make it absolutely clear what the interpretation of
the policy is... so I see no harm in including it.

[Eddy Nigg]

On 02/18/2012 09:34 PM, From Stephen Schultze:

> I agree with Eddy that the MITM language may be superfluous, but on
> the other hand it does make it absolutely clear what the
> interpretation of the policy is... so I see no harm in including it.

It probably does - but then, would you like to include XYZ additional
circumstances which aren't in compliance with the Mozilla CA Policy?
This could be never ending....

In the same manner I have a problem including in our own (StartCom) CA
Policy any reference to MITM or anything similar because it simply
doesn't exist. Meaning, that the policy clearly defines under which
circumstances a certificate may be issued, why should I include
something in the policy that has no relevance at all with the stated
policy and practice and which is EXCLUDED right from the outset?

[Kathleen Wilson]

On 2/18/12 11:34 AM, Stephen Schultze wrote:
> On 2/18/12 1:32 PM, Kathleen Wilson wrote:
>> I agree that we need to finalize the proposed item #9 in
>> http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html
>>
>>
>> and get it officially added to the policy soon.
>
> I proposed that we do it immediately. Do you have a specific
> counter-proposal? Why wait?
>

I'm still not fully satisfied with the wording, but perhaps we should go
ahead and make this version official, and then we can tighten the
wording in the next update to the policy.

Also, I needed to give official notice to all CAs in our program about
the proposed changes to the policy (e.g. send a CA Communication about
the draft updates, which has been done now), and allow time for any
further input/feedback after communicating the changes.

>> It has also been brought to my attention that there is another problem
>> with option b in the communication:
>> "b) SubCAs are technically and/or contractually restricted to only issue
>> certificates to domains that they legitimately own or control..."
>>
>> This cannot apply to subCAs that can issue end-entity certs to other
>> entities; e.g. Certificate Service Providers or government organizations.
>>
>> I propose to add another option as a possible response to action #1,
>> such as:
>>
>> "e) SubCAs are disclosed, audited, and technically and/or contractually
>> restricted to issue certificates in full compliance with the Mozilla CA
>> Certificate Policy. This includes not using their subordinate
>> certificates for the purpose of MITM.
>>
>> I'd appreciate constructive feedback on this.
>
> Sure, this sounds good and is complimentary to the proposed language in
> item #9. I might slightly modify it for clarity to say:
>
> "SubCAs are publicly disclosed to Mozilla, audited by a competent party
> (per the Mozilla CA Certificate Policy) whose audit report has been
> publicly disclosed to Mozilla, and technically and/or contractually
> restricted to issue certificates in full compliance with the Mozilla CA
> Certificate Policy."
>
> I agree with Eddy that the MITM language may be superfluous, but on the
> other hand it does make it absolutely clear what the interpretation of
> the policy is... so I see no harm in including it.

While I agree that the MITM language is superfluous, I am currently
under the impression that it is needed.

I have added the following to
https://wiki.mozilla.org/CA:Communications#February_17.2C_2012

"e) SubCAs are publicly disclosed to Mozilla, audited by a competent
party (per Mozilla’s CA Certificate Policy) whose audit result has been

publicly disclosed to Mozilla, and technically and/or contractually

restricted to issue certificates in full compliance with Mozilla's CA
Certificate Policy. SubCAs are specifically not allowed to use their
subordinate certificates for the purpose of MITM. (Note: This option was
added after the communication was sent.)"

Kathleen

[Kathleen Wilson]

On 2/18/12 11:46 AM, Eddy Nigg wrote:
> In the same manner I have a problem including in our own (StartCom) CA
> Policy any reference to MITM or anything similar because it simply
> doesn't exist. Meaning, that the policy clearly defines under which
> circumstances a certificate may be issued, why should I include
> something in the policy that has no relevance at all with the stated
> policy and practice and which is EXCLUDED right from the outset?
>

To Clarify action #2...

"2) If you issue subordinate CAs to third parties or your CP/CPS permits
you to do so in the future, 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."

This particular requirement only applies for external subCAs where the
parent CA doesn't directly control the certificate. So you only need to
do this action item if you currently have externally-operated subCAs or
your CP/CPS permits you to issue externally-operated subCAs. If that is
the case, then your CP/CPS needs to include a statement that such
externally-operated subCA certs cannot be used for MITM.

Kathleen

[Eddy Nigg]

On 02/21/2012 12:05 AM, From Kathleen Wilson:

> This particular requirement only applies for external subCAs where the
> parent CA doesn't directly control the certificate. So you only need
> to do this action item if you currently have externally-operated
> subCAs or your CP/CPS permits you to issue externally-operated subCAs.
> If that is the case, then your CP/CPS needs to include a statement
> that such externally-operated subCA certs cannot be used for MITM.
>

Thanks for the clarification, this makes sense.

[Tom Lowenthal]

Though I agree that the language prohibiting the use of (sub-)certs for
MitM is superfluous since the behavior is already prohibited, I agree
with Kathleen that specifying it in no uncertain terms in this
communication makes clear exactly what we're talking about here.

[ianG]

+1+1

iang

[Stephen Schultze]

On 2/20/12 4:55 PM, Kathleen Wilson wrote:
> On 2/18/12 11:34 AM, Stephen Schultze wrote:
>> On 2/18/12 1:32 PM, Kathleen Wilson wrote:
>>> I agree that we need to finalize the proposed item #9 in
>>> http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html
>>>
>>>
>>>
>>> and get it officially added to the policy soon.
>>
>> I proposed that we do it immediately. Do you have a specific
>> counter-proposal? Why wait?
>
>
> I'm still not fully satisfied with the wording, but perhaps we should go
> ahead and make this version official, and then we can tighten the
> wording in the next update to the policy.

I think that this makes the most sense. If there is something specific
you can articulate about what you don't like about the wording, then
perhaps we can help improve it. Otherwise, we should move forward.

> Also, I needed to give official notice to all CAs in our program about
> the proposed changes to the policy (e.g. send a CA Communication about
> the draft updates, which has been done now), and allow time for any
> further input/feedback after communicating the changes.

This feedback would be sent by the CAs publicly to this list, right?

At this point, what's the timeline for getting #9 formally adopted? Can
you give us a specific schedule?

Steve

[Franck Leroy]

Hello

On 17 fév, 23:10, Kathleen Wilson <kwil...@mozilla.com> wrote:
> The CA Communication has been sent.
> ===
> Dear Certification Authority,
>
>

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

Certinomis does not issue subCA to third parties and doesn’t provide
certificates for MITM for TLS traffic management.

>
> ===

Best regards
Franck Leroy

[Kathleen Wilson]

I have posted a summary of the CA responses here:
https://wiki.mozilla.org/CA:Communications#Responses

Kathleen

[Andy Isaacson]

On Mon, Mar 05, 2012 at 12:04:22PM -0800, Kathleen Wilson wrote:
> On 2/17/12 2:15 PM, Kathleen Wilson wrote:

> I have posted a summary of the CA responses here:
> https://wiki.mozilla.org/CA:Communications#Responses

Kathleen,

Thanks very much for publishing this summary.

This table is indexed by CA name. Is there a mapping from CA key in NSS
to the CA name? Some of the O= OU= fragments are ... a bit opaque.

Do we have positive certification from the CAs that their answers apply
affirmatively to all of their roots in NSS?

(I started composing this mail when I missed "TDC" in the list, but now
I see that it is there; the fact that I had to manually cross-check is
definitely a sign of the problem.)

-andy

[Kathleen Wilson]

On 3/5/12 3:08 PM, Andy Isaacson wrote:
> On Mon, Mar 05, 2012 at 12:04:22PM -0800, Kathleen Wilson wrote:
>> On 2/17/12 2:15 PM, Kathleen Wilson wrote:
>>> On 2/17/12 2:10 PM, Kathleen Wilson wrote:
>>>> The CA Communication has been sent.
>>>> ===
>>>
>>> Added here:
>>> https://wiki.mozilla.org/CA:Communications
>>
>> I have posted a summary of the CA responses here:
>> https://wiki.mozilla.org/CA:Communications#Responses
>
> Kathleen,
>
> Thanks very much for publishing this summary.
>
> This table is indexed by CA name. Is there a mapping from CA key in NSS
> to the CA name? Some of the O= OU= fragments are ... a bit opaque.

I updated https://wiki.mozilla.org/CA:Communications#Responses to point
to a new version which has two spreadsheets in it, see links at the top
called "Responses" and "Owner, O, OU, CN".

>
> Do we have positive certification from the CAs that their answers apply
> affirmatively to all of their roots in NSS?
>

I believe all have been accounted for, except for the Equifax roots,
which I am following up with Symantec on.

Kathleen

[Ned Ulbricht]

On 03/05/2012 07:06 PM, Kathleen Wilson wrote:
> On 3/5/12 3:08 PM, Andy Isaacson wrote:

>> This table is indexed by CA name. Is there a mapping from CA key in NSS
>> to the CA name? Some of the O= OU= fragments are ... a bit opaque.
>
>

> I updated https://wiki.mozilla.org/CA:Communications#Responses to point
> to a new version which has two spreadsheets in it, see links at the top
> called "Responses" and "Owner, O, OU, CN".

Thanks for preparing both spreadsheets.

At the risk of stating the obvious, Mozilla has a fair number of people
skilled with sqlite3.

>From my vantage point, the canonical database is currently:
nss/lib/ckfw/builtins/certdata.txt

Perhaps this should be transitioned to a relational database?
--
Ned Ulbricht
mailto:ne...@netscape.net