GeoTrust EV Enablement Request

[Kathleen Wilson]

Symantec/GeoTrust has applied to enable EV for the “GeoTrust Primary
Certification Authority - G3” root certificate that is already included
in NSS.

GeoTrust is a subsidiary of Symantec. Symantec acquired the VeriSign
Authentication Services and root certificates, and is a major commercial
CA with worldwide operations and customer base.

The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=539255

And in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/#Symantec%20/%20GeoTrust

Information Gathering Document:
https://bugzilla.mozilla.org/attachment.cgi?id=608011

Noteworthy points:

* The CPS is provided in English.

http://www.geotrust.com/resources/cps/pdfs/GeoTrustCPS-Version1.1.6.pdf
http://www.geotrust.com/resources/repository/legal.asp

* This SHA256 root certificate is currently included in NSS. It will
have a separate internally-operated intermediate CA for signing EV SSL
certificates.

** CP/CPS Section 3.2.2, Authentication of Organization Identity:
Whenever an organization name is included in the Certificate, GeoTrust
or the RA will take reasonable steps to establish that a Certificate
request made on behalf of that Organization is legitimate and properly
authorized. … GeoTrust may
(a) verify the validity of the registration through the authority that
issued it, or
(b) verify the validity of the registration through a reputable third
party database or other resource, or
(c) verify the validity of the Organization through a trusted third
party, or
(d) confirm that the Organization exists if such Organization is not the
type that is typically registered or is capable of being verified under
clause (b).

** CPS Section 3.2.3, Authentication of Domain Name: When a domain name
is included in a Certificate together with an organization name,
GeoTrust or the RA will verify that the Subscriber had the right to use
the domain name submitted by the Subscriber at the time it submitted its
application. For instance, GeoTrust may perform this verification by
confirming that the Subscriber is the same person or entity that holds
the domain name registration from the relevant domain name registrar or
that the Subscriber is otherwise authorized to use such domain name. …
When a domain name is included in a Certificate without authentication
of the entity owning the domain name, GeoTrust or an RA will verify that
the Subscriber has control over such domain name at the time it
submitted its enrolment form by accessing a third party database of
domain names and their owners. To do this, GeoTrust will send an e-mail
message to one of the following e-mail addresses requesting confirmation
of the Certificate order and authorization to issue the Certificate in
the domain name:
(a) an e-mail address listed as the administrative or technical contact
for the domain name in an official InterNIC domain name registry that
includes the domain name,
(b) a limited list of the most commonly used generic e-mail addresses
for authorized persons at domain names (e.g., “ad...@domain.com,“ or
“hostm...@domain.com” for the domain name domain.com), or
(c) using a manual process of verification conducted by GeoTrust, to an
e-mail address identified as the registered owner of the domain per the
whois database. Optionally, a verification phone call may be substituted
to the domain owner phone number listed in the whois.

** CPS Section 3.2.4 states that GeoTrust requires the certificate
applicant to prove control over the Contact Address, which is the email
address to be included in the cert. GeoTrust’s process for proving
control over the email address is to send an email to the Contact
Address requiring the applicant to respond to a link and enter a PIN
that is also sent via email.

** CPS section 3.2.6, Validation of Authority: GeoTrust will take
reasonable steps to establish that a Certificate request made on behalf
of that Organization is legitimate and properly authorized. To prove
that a Certificate is duly authorized by the Organization, GeoTrust will
typically request the name of a contact person who is employed by or is
an officer of the Organization. GeoTrust will also typically require a
form of authorization from the Organization confirming its intent to
obtain a Certificate and will usually document the Organization's
contact person. GeoTrust normally confirms the contents of this
authorization with the listed contact person.

** GeoTrust’s EV SSL Verification Requirements are in Appendix A of the
CPS, which starts on page 47.
*** Sections 14 and 15: Verification of Applicant’s Legal Existence and
Identity (pages 60 – 62)
“To verify Applicant‟s legal existence and identity, GeoTrust verifies
that the Applicant is a legally recognized entity, in existence and
validly formed (e.g., incorporated) directly with the Incorporating or
Registration Agency in Applicant‟s Jurisdiction of Incorporation or
Registration, and designated on the records of the Incorporating or
Registration Agency …”
*** Section 16: Verification of Applicant’s Physical Existence (pages 62
– 64)
“To verify Applicant‟s physical existence and business presence,
GeoTrust verifies that the physical address provided by Applicant or a
Parent/Subsidiary Company is an address where Applicant conducts
business operations (e.g., not a mail drop or P.O. Box), and is the
address of Applicant‟s Place of Business. …”
*** Section 17: Verification of Applicant’s Operational Existence (page 64)
“If the records of the Incorporating or Registration Agency indicate
that the Applicant has been in existence for less than three (3) years,
and the Applicant is not listed in either the current version of one (1)
Qualified Independent Information Source or a Qualified Governmental Tax
Information Source, GeoTrust verifies that the Applicant has the ability
to engage in business. …”
*** Section 18: Verification of Applicant’s Domain Name (pages 64 - 65)
“…GeoTrust performs a WHOIS inquiry on the Internet for the domain name
supplied by the Applicant to verify that the Applicant is the entity to
whom the domain name is registered. Where the WHOIS record indicates
otherwise, GeoTrust will require the WHOIS record to be updated to
reflect the Applicant as the registered holder of the domain. …”

* EV Policy OID: 1.3.6.1.4.1.14370.1.6

* Test Website: https://ssltest21.bbtest.net/
Before actual approval, need test website whose EV SSL cert chains up to
the intermediate issuing CA, chaining up to this root.

* CRL: No CRL exists yet – GeoTrust is not yet actively issuing
certificates from these roots.
** CPS Section 4.9.7: GeoTrust shall post the CRL online at least weekly
(but no later than twenty-four (24) hours after revocation of a Certificate)

* OCSP: Not yet provided. Must be provided before actual approval to
enable EV.
** CPS Appendix A1, section 26: For EV Certificates: ... GeoTrust’s
Online Certificate Status Protocol (OCSP) is updated at least every four
(4) days, and with a maximum expiration time of ten (10) days.

* Audit: GeoTrust’s audits are performed by KPMG and posted on the
webtrust.org website:
https://cert.webtrust.org/SealFile?seal=650&file=pdf
This document contains two audit reports, one for WebTrust for CA and
one for WebTrust for EV.

Potentially Problematic Practices
(http://wiki.mozilla.org/CA:Problematic_Practices):

* CPS Section 1.4: GeoTrust may issue Wildcard Certificates, which are
X.509 Certificates with SSL Extensions that are vetted to a specified
level domain and may be used in connection with all next level higher
domains that contain the specified vetted level domain.
** CPS Appendix A1: “Wildcard certificates are not allowed for EV
certificates.”


This begins the discussion of the request from Symantec/GeoTrust to
enable EV for the “GeoTrust Primary Certification Authority - G3” root
certificate that is already included in NSS. At the conclusion of this
discussion I will provide a summary of issues noted and action items. If
there are outstanding issues, then an additional discussion may be
needed as follow-up. If there are no outstanding issues, then I will
track the action items to create the intermediate EV issuing
certificate, provide OCSP, and perform EV testing before recommending
approval in the bug.

Kathleen

[Stephen Schultze]

Is GeoTrust issuing any third-party CA-enabled certs off of its roots?
At least until recently, they were selling this as a product (and
perhaps still):

https://www.trustico.com/material/DS_GeoRoot_0205.pdf

What is the list of unconstrained SubCAs that they have issued in the past?

Steve

[Rick Andrews]

Sorry for the delay. I'm waiting to hear from Legal if our contracts with these companies allow us to make their SubCA public. I'll post as soon as I know.

[Rick Andrews]

[ianG]

On 3/04/12 06:49 AM, Rick Andrews wrote:
> Sorry for the delay. I'm waiting to hear from Legal if our contracts with these companies allow us to make their SubCA public. I'll post as soon as I know.

Seems like a YES to Steve's question. In the interim, would you be able
to confirm that these sub-CAs were not issued for MITM purposes, and are
not used to the company's knowledge for such?

Or are we waiting on legal for that too ;-)



iang

[Rick Andrews]

Yes, we've issued a small number of SubCAs to external parties. Our Legal department informs me that our contracts with these companies include confidentiality agreements, so I cannot reveal their names. However, I can attest that none of those SubCAs were signed under the “GeoTrust Primary Certification Authority - G3” that is the subject of this thread. Hence the question is irrelevant, in my opinion.

[Rick Andrews]

On Tuesday, April 3, 2012 5:52:27 AM UTC-7, ianG wrote:

[Stephen Schultze]

On 4/10/12 5:50 PM, Rick Andrews wrote:
> On Tuesday, April 3, 2012 5:52:27 AM UTC-7, ianG wrote:
>> On 3/04/12 06:49 AM, Rick Andrews wrote:
>>> Sorry for the delay. I'm waiting to hear from Legal if our contracts with these companies allow us to make their SubCA public. I'll post as soon as I know.
>>
>>
>> Seems like a YES to Steve's question. In the interim, would you be able
>> to confirm that these sub-CAs were not issued for MITM purposes, and are
>> not used to the company's knowledge for such?
>>
>> Or are we waiting on legal for that too ;-)
>>
>>
>>
>> iang
>
> Yes, we've issued a small number of SubCAs to external parties. Our
> Legal department informs me that our contracts with these companies
> include confidentiality agreements, so I cannot reveal their names.

As stated in the Mozilla "CA Problematic Practices" document:
"You must provide a clear description of the subordinate CAs that are
operated by external third parties, and an explanation as to how the
CP/CPS and audits ensure the third parties are in compliance with
Mozilla's CA Certificate Policy requirements as per the Subordinate CA
Checklist."
https://wiki.mozilla.org/CA:Problematic_Practices#Allowing_external_entities_to_operate_subordinate_CAs

I'm sure you're also aware that Mozilla is likely to adopt even more
stringent requirements on external SubCAs in the near future.

I don't think that this community is going to stand for your answer above.

> However, I can attest that none of those SubCAs were signed under the
> “GeoTrust Primary Certification Authority - G3” that is the subject of
> this thread. Hence the question is irrelevant, in my opinion.

“GeoTrust Primary Certification Authority - G3” is one of more than a
dozen roots covered by this audit statement (which also includes several
of the Equifax roots now owned by your parent company, Symantec):

https://cert.webtrust.org/SealFile?seal=650&file=pdf

By requesting EV enablement of one of those roots or renewal of any of
those roots, you've invited us to examine the practices covered in that
audit statement.

[ianG]

On 11/04/12 07:50 AM, Rick Andrews wrote:
> On Tuesday, April 3, 2012 5:52:27 AM UTC-7, ianG wrote:

> Yes, we've issued a small number of SubCAs to external parties.

Thanks for that! It helps enormously to get some solid facts on the table.

> Our Legal department informs me that our contracts with these companies include confidentiality agreements, so I cannot reveal their names.

Yes, this was as expected. It remains an open question with Mozilla as
to how we are going to deal with this challenge to policy. As Mozilla
is not party to these contracts, this is not our problem.

For my money, the CA - GeoTrust in this case - is totally responsible
for its roots, and is therefore totally responsible for these sub-CAs.
That's what the policy says, because it omits to carve out any exception.

However, I agree with others that there may be some bad actors out
there. Although we have no direct facts other than revealed breaches,
it is claimed that CAs could be sliding out of audit and other
responsibilities by claiming that that these sub-CAs aren't their
responsibility. The same sort of slide-pass logic seems to be prevalent
in the cross-signing discussion as well.

Coupled with the complete or near-complete absence of CAs standing forth
at the podium and debating these practices, and voluntarily providing
disclosures and bringing facts to bear, I find myself persuaded that we
should err on the side of caution: sub-CAs should be disclosed.

I don't like it, but I think the CAs have soiled the nest. CAs practice
& preach secrecy. This is dangerous to Mozilla users. Therefore we
must wind back such secrecy.

> However, I can attest that none of those SubCAs were signed under the “GeoTrust Primary Certification Authority - G3” that is the subject of this thread. Hence the question is irrelevant, in my opinion.

That's helpful but only partial. We here in the group also have to look
to future risks to Mozilla (and users). So we would need to be assured
that this won't effect future uses of that root. E.g., that the root
has CPS stipulations or similar against bad practices.

Further. Mozilla has recently changed its practices, and has by default
accepted a defacto grandfathering status for all CAs currently in the
root list. This is a 180 degrees change from original expectations from
when the policy reviews were started -- and an uncomfortable
discrimination that's worth a lot of money to those grandfathered CAs.

We may now be minded to expand reviews over new root
modifications/additions of existing grandfathered CAs to examine all
practices of the CA concerned, as we know there is no pending or other
avenue. IMHO only, it would be unacceptable and grossly negligent to
let current grandfathered CAs carry on issuing sub-CAs under other roots
outside our agreed policy restrictions, just because there was "no way"
to review such practices.



iang

[Rick Andrews]

I think we're at an impasse. The way I see it, we have duly-executed legal agreements with customers that must be respected. Those contracts will come up for renewal at some point, and at that time we will modify them to insist on compliance with the CA/Browser Forum's Baseline Requirements and Mozilla's MITM requirement.

AFAIK, we have no contract with Mozilla at this point. I don't see how Mozilla can force us to renegotiate these contracts out-of-band.

Furthermore, this is a public forum not limited to Mozilla employees. Maybe there's some legal way we can disclose to Mozilla executives, but doing so in this form is equivalent to disclosing to the entire world.

[Rick Andrews]

[ianG]

Hi Rick,

On 12/04/12 07:47 AM, Rick Andrews wrote:
> I think we're at an impasse. The way I see it, we have duly-executed legal agreements with customers that must be respected. Those contracts will come up for renewal at some point, and at that time we will modify them to insist on compliance with the CA/Browser Forum's Baseline Requirements and Mozilla's MITM requirement.

I'll let others discuss the MITM issue.

> AFAIK, we have no contract with Mozilla at this point.

FWIW, that will not help, and may get you into a world of trouble. It
may be possible to assert that you have no contract, but in practice you
will be asserting that you don't know what the contract is. This may be
a valid and truthful assertion - but it isn't one that is helpful *to you*.

Contracts are formed by agreement, not by pieces of paper with the word
"CONTRACT" at the top. When there is no one easy document, the court
looks at the wider documents. In this case, (imho) the contract will be
found in the Policy, wiki pages, submissions, bugzillas, emails sent
back & forth and so forth. It will also look to the other elements of
contract - parties, offer and accept, value exchanged - and will
establish them from the record.

Basically, Mozilla's legal position will be (likely something like) that
you agree to the Policy and surrounding documents, and that the Policy
is the lead document in the contract. In any test, Mozilla will present
evidence such as any emails whereby you have (implicitly) accepted
and/or agreed. For one example only, as the Policy is published and it
references public discussion, your post today evidences that you agree
because you are taking part in the public discussion that is required of
that Policy.

A note for Americans and the IANAL crowd - I'm not, either. So it may
be that, being immune to that illness, I can help cut through the crap
of "talk to the lawyers" by stating the home truths up front. Please
feel free to take this post to your legal counsel and ask him to clarify
or explain.

> I don't see how Mozilla can force us to renegotiate these contracts out-of-band.

I don't see how this falls out either :) but I do know that the lawyers
will be laughing all the way to the bank if they get to try opposing
contracts.

> Furthermore, this is a public forum not limited to Mozilla employees. Maybe there's some legal way we can disclose to Mozilla executives, but doing so in this form is equivalent to disclosing to the entire world.

This is a very good point. Under the Policy:

"2. We will make such decisions through a public process, based on
objective and verifiable criteria as described below."

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

I'd speculate that the body of users here are very much opposed to
private negotiations.

But, let's speculate that this might be possible: you might be able to
enter into private discussions with Mozilla executives. According to 2.
above, whatever decision you negotiate will be taken through this public
forum. E.g., it may be that you can negotiate private disclosures, but
that will probably need to be sufficiently described to appeal to the
body of users here, including to the extent of creating a precedent.

That's all speculation on my part of course.



iang

[Gervase Markham]

On 11/04/12 22:47, Rick Andrews wrote:
> I think we're at an impasse. The way I see it, we have duly-executed
> legal agreements with customers that must be respected. Those
> contracts will come up for renewal at some point, and at that time we
> will modify them to insist on compliance with the CA/Browser Forum's
> Baseline Requirements and Mozilla's MITM requirement.
>
> AFAIK, we have no contract with Mozilla at this point. I don't see
> how Mozilla can force us to renegotiate these contracts out-of-band.

Rick,

You should not take statements by people other than Kathleen in this
forum as attempts by Mozilla to force you to do anything. If either
Kathleen or our adopted policy states that you must do something that
you do not feel legally able to do, then (if you haven't already) the
next step would be to email her about it.

Gerv

[Stephen Schultze]

And I would expect Kathleen to engage in public discussion here about
potential solutions, minimizing the off-list emails to only those
conversations that contain confidential information that cannot be sent
to the list. The whole point of her initial email to the list was to
launch a public discussion on all issues related to the request.

As to the "we don't have a contract with Mozilla" point... precisely.
GeoTrust/Verisign/Symantec has no contract that compels Mozilla to do
anything, including approval of an EV enablement request. If they want
to be enabled, they have to comply with Mozilla's requirements. Mozilla
has no obligation to perpetuate potentially harmful industry practices
by making exceptions that run against industry best practices.

Perhaps GeoTrust/Verisign/Symantec should approach the entities to which
it sold unconstrained SubCAs and seek permission to disclose their
identities, or otherwise find a way to terminate those contracts.

[Rick Andrews]

I'm really not trying to be confrontational. We fully intend to cooperate with Mozilla to the greatest extent possible. I'm just trying to point out that other contractual obligations prohibit us from being completely open. Also, I don't think it's reasonable for Mozilla to state a policy and insist on immediate compliance. I'll follow up with Kathleen offline.

[Rick Andrews]

[Kathleen Wilson]

> https://www.trustico.com/material/DS_GeoRoot_0205.pdf
>
> What is the list of unconstrained SubCAs that they have
> issued in the past?

We don’t currently have official policy that requires a CA to publicly
disclose their list of externally-operated subCAs.

We are working to add policy along these lines, as per item #9 of
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html

However, even the proposed policy allows that the externally-operated
subCAs may either be technically constrained (as specifically described)
or be audited and publicly disclosed.

When the proposed policy is finalized and made official, at that point
all CAs will be given a certain amount of time to comply with the
updated policy. That time frame is still to be discussed. When that
happens, for each externally-operated subCA compliance may take the form
of having their intermediate certificate(s) updated to have appropriate
EKU and Name Constraints, or having an audit and being publicly
disclosed. At that point in time, we will expect Symantec to comply,
along with all of the other CAs currently in Mozilla’s program.

Therefore, I do not think it is reasonable to require that GeoTrust
publicly disclose their customer list today.

> As stated in the Mozilla "CA Problematic Practices" document:
> "You must provide a clear description of the subordinate CAs that are
> operated by external third parties, and an explanation as to how the
> CP/CPS and audits ensure the third parties are in compliance with
> Mozilla's CA Certificate Policy requirements as per the Subordinate
> CA Checklist."

GeoTrust has contractual agreements in place with these subCAs that
restricts the domain names that may be used in the certificates that
they issue. To my knowledge, such contractual agreements have not
failed, but consensus is that such contractual agreements are no longer
sufficient and we are working to update our policy to address this.
However, the policy today still allows for such contractual agreements.

In regards to https://wiki.mozilla.org/CA:SubordinateCA_checklist
These GeoTrust subCAs fall into the category of “Third-party private (or
enterprise) subordinate CAs”

> Further. Mozilla has recently changed its practices, and has by
> default accepted a defacto grandfathering status for all CAs
> currently in the root list. This is a 180 degrees change from
> original expectations from when the policy reviews were started --
> and an uncomfortable discrimination that's worth a lot of money to
> those grandfathered CAs.
>

Huh?

Which changes to our practices are you talking about?

When we make new policy official we allow for existing CAs to have a
certain amount of time to comply with the new policy. Is that what you
mean by “defacto grandfathering”?

> We may now be minded to expand reviews over new root
> modifications/additions of existing grandfathered CAs to examine all
> practices of the CA concerned, as we know there is no pending or
> other avenue. IMHO only, it would be unacceptable and grossly
> negligent to let current grandfathered CAs carry on issuing sub-CAs
> under other roots outside our agreed policy restrictions, just
> because there was "no way" to review such practices.
>

I am fine with including review of already-included roots when a CA
requests a change or inclusion of a new root inclusion. We have done
this in the past, and I expect we will continue to do so.

However, the requirements that we place on those CAs should be
consistent with existing policy and timelines for allowing CAs to comply
with new policy.

> Perhaps GeoTrust/Verisign/Symantec should approach the entities to
> which it sold unconstrained SubCAs and seek permission to disclose
> their identities, or otherwise find a way to terminate those
> contracts.

Many CAs have already begun working with such customers regarding
technical constraints, or moving their SSL cert issuance to a
CA-managed-service, or moving towards an external audit and public
disclosure. Symantec is also aware of the direction that Mozilla's
policy is moving, and is encouraged to have those discussions with their
customers as soon as possible.

GeoTrust/Symantec will indeed need to take appropriate action when the
new policy becomes official and the timeline determined. They will have
the same timeline as provided for all CAs currently in Mozilla’s program.

Since policy update discussions about externally-operated subCAs are
happening in other threads, I would like to ask that this discussion
re-focus on reviewing this request to enable EV for the “GeoTrust

Primary Certification Authority - G3” root certificate that is already

included in NSS, and does not currently have externally-operated subCAs.

There are some potential action items that would be more reasonable to
require before enabling EV for this root. For example...

a) Add text to the GeoTrust CPS stating that this root will not be
allowed to issue subCAs to external third parties that will operate the
private key.

and/or

b) Complete the action item #2 from the recent CA Communication: "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."

Kathleen

[ianG]

Just on the one issue that might have been addressed to me.

On 13/04/12 06:19 AM, Kathleen Wilson wrote:

> > Further. Mozilla has recently changed its practices, and has by
> > default accepted a defacto grandfathering status for all CAs
> > currently in the root list. This is a 180 degrees change from
> > original expectations from when the policy reviews were started --
> > and an uncomfortable discrimination that's worth a lot of money to
> > those grandfathered CAs.
> >
>

> Huh?
>
> Which changes to our practices are you talking about?
>
> When we make new policy official we allow for existing CAs to have a
> certain amount of time to comply with the new policy. Is that what you
> mean by “defacto grandfathering”?

No, that's not what I meant. I'll try to explain. When the policy was
written in or around 2005, it was expected that every CA would be
reviewed under the policy.

When it was finally approved, however, there was already a long queue of
new CAs that wanted to ascend to the root list. So the thought at the
time was that those new CAs would be reviewed first, and when we got to
the end of that list, we would then start on the ones that were there
pre-policy.

As we know now, they list of newcomers never got shorter.

The new split into two lists - updates & new CAs - means as a
side-effect that existing CAs will not be reviewed according to the
policy. (That's in addition to the possibility of expediting.)

This is not in accordance with 1, 2 of the policy. At the time, it was
quite controversial that all the existing CAs were not to be reviewed in
public. Indeed, one of the main driving forces was that many of us
suspected that some on root list were not fit to be there - that's what
the policy was written for, to tighten up bad standards, in incumbents
as much as newcomers. The expectation of reviewing those CAs was
therefore seen as quite a strong issue.

(This is mostly from memory. Someone could go back in the archives and
dig out a better version I guess.)

iang

> > We may now be minded to expand reviews over new root
> > modifications/additions of existing grandfathered CAs to examine all
> > practices of the CA concerned, as we know there is no pending or
> > other avenue. IMHO only, it would be unacceptable and grossly
> > negligent to let current grandfathered CAs carry on issuing sub-CAs
> > under other roots outside our agreed policy restrictions, just
> > because there was "no way" to review such practices.
> >
>

[ianG]

Hi Rick,

I understand the bit about non-disclosure of the customer's name in
contracts, and I guess we all understand that expectations of NDAs here
are changing. A couple of points:

What triggered my alarm bells is this:


> ...we will modify them to insist on compliance with the CA/Browser

> Forum's Baseline Requirements and Mozilla's MITM requirement.

_____________________________________^^^^^^^^^^^^^^^^^^^^^^^^^^

Is there a conflict between your contracts and Mozilla's requirement for
no MITMs?

More specifically, is there any reason to believe that your sub-CAs are
vulnerable to deliberate MITM purposes?

Or is this an accident of conflation?

Secondly, what is likely also a confusion - confrontational ? - is if a
CA believed it could "contract out" of the Policy by means of some
contract+NDA with some sub-CA customer. That's a non-starter.

That's kind of where we are heading with the question of whether Mozilla
can "force" an issue or not: It's the wrong question. Either the CA
agrees to the Policy or not. Once a CA agrees to the Policy (and we
assume that every CA has otherwise they wouldn't be here) then the CA
will organise its contracts and other things into alignment.

iang

[Rick Andrews]

I guess it's an accident of conflation. I know of no external SubCA customers that are doing MITM. We believe none of them are engaged in MITM. But I was not involved in any of the contracts and have never read them. They all pre-date this discussion, hence I doubt that there is a "no MITM" clause in them. We'll address that when the contracts are renegotiated.

We will not "contract out" of the BR or Mozilla requirements; those take precedence over new or renewed contracts. I was just trying to point out that the BR and Mozilla requirements can't override existing contracts.

[Rick Andrews]

[David E. Ross]

By posting to both the mozilla.dev.security.policy newsgroup and the
mozilla-dev-s...@lists.mozilla.org mailing list, all of your
replies appear twice. Please post to only one of those.

--

David E. Ross
<http://www.rossde.com/>.

Anyone who thinks government owns a monopoly on inefficient, obstructive
bureaucracy has obviously never worked for a large corporation.
© 1997 by David E. Ross

[Stephen Schultze]

On 4/16/12 9:25 AM, Rick Andrews wrote:
> I guess it's an accident of conflation. I know of no external SubCA
> customers that are doing MITM. We believe none of them are engaged in
> MITM. But I was not involved in any of the contracts and have never
> read them. They all pre-date this discussion, hence I doubt that
> there is a "no MITM" clause in them. We'll address that when the
> contracts are renegotiated.

So, who from GeoTrust/Symantec replied to Kathleen's February 17 request
to assert whether or not SubCAs have the ability to MITM?

https://wiki.mozilla.org/CA:Communications#Responses

Whatever the response was, Kathleen interpreted it to mean "(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."

[Rick Andrews]

On Wednesday, April 18, 2012 8:12:41 AM UTC-7, Stephen Schultze wrote:
> So, who from GeoTrust/Symantec replied to Kathleen's February 17 request
> to assert whether or not SubCAs have the ability to MITM?

I replied to Kathleen.

> Whatever the response was, Kathleen interpreted it to mean "(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."

Correct interpretation. Those SubCAs are contractually constrained to only issue certs to domains that they own or control. AFAIK, those contracts don't explicitly mention MITM, but I would argue that's covered by "domains they own or control".

[Kathleen Wilson]

CAs have been re-evaluated as they've gone through the change request
process (which is the same as for new root inclusion requests). The only
difference now is that there is a separate "queue" for discussion. They
will still go through discussion, but I will try to expedite getting
those discussions started.

The concern is that there may be legacy CAs that have not yet been
re-evaluated. Correct?

Kathleen

[Kathleen Wilson]

On 3/21/12 10:30 AM, Kathleen Wilson wrote:
> Symantec/GeoTrust has applied to enable EV for the “GeoTrust Primary
> Certification Authority - G3” root certificate that is already included
> in NSS.
>
> GeoTrust is a subsidiary of Symantec. Symantec acquired the VeriSign
> Authentication Services and root certificates, and is a major commercial
> CA with worldwide operations and customer base.
>
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=539255
>
> And in the pending certificates list here:
> http://www.mozilla.org/projects/security/certs/pending/#Symantec%20/%20GeoTrust
>
>
> Information Gathering Document:
> https://bugzilla.mozilla.org/attachment.cgi?id=608011
>
> Noteworthy points:
>
> * The CPS is provided in English.
>
> http://www.geotrust.com/resources/cps/pdfs/GeoTrustCPS-Version1.1.6.pdf
> http://www.geotrust.com/resources/repository/legal.asp
>
> * This SHA256 root certificate is currently included in NSS. It will
> have a separate internally-operated intermediate CA for signing EV SSL
> certificates.

Thanks to all of you who have reviewed this request and participated in
this discussion.

There were questions raised about GeoTrust issuing externally-operated
subCAs to enterprise customers under their other roots that are included
in NSS. While these are not currently technically constrained, they are
constrained by contract to only issue certs to domains that they own. As
with other CAs in Mozilla’s program, GeoTrust will be expected to comply
with Mozilla’s updated policy according to the timeline that is
established when the updates to the policy become official.

There is one remaining action item that is relevant to this discussion,
but is already part of the recent CA Communication:

ACTION: Complete the action item #2 from the recent CA Communication:

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

My expectation is that this will be done at the same time that the
action item regarding updating the CP/CPS to conform with the CAB Forum
Baseline Requirements is done. (e.g. by July 1, 2012). Therefore, my
plan is to continue tracking both of these action items in regards to
the CA Communication Responses, and not duplicate the action item in
this bug.

If there are no further comments on this request to enable EV for the
“GeoTrust Primary Certification Authority - G3” root certificate, then I
will close this discussion and recommend approval in the bug.

Thanks,
Kathleen

[ianG]

On 25/04/12 04:33 AM, Kathleen Wilson wrote:

> There were questions raised about GeoTrust issuing externally-operated
> subCAs to enterprise customers under their other roots that are included
> in NSS. While these are not currently technically constrained, they are
> constrained by contract to only issue certs to domains that they own.

OK, I'm fine with that.



I note however the wider question of overall confidence in the CAs and
their participation or non-participation in MITM sub-CAs continues.

Many comments have been made and many seemed to be putting out fire with
gasoline (showing my age...).

In the context of all this, I think there is now a compelling case to
request publishing of sub-CAs. In the past I thought not, as
outsourcing should always be possible, and technically it shouldn't
matter. Now however it is clear that CAs will continue to shield behind
outsourcing as some sort of magic elixir that makes their disclosure
responsibilities go away, and vendors aren't in a position to stop them
supping of their kool-aid.

(nb, i am looking at events wider than this present thread.)

In the absence of any other compelling move by the CAs * to provide some
credibility, some substance on which to rely, I join with the broad
community of relying parties and users that demand the publication of
outsourced sub-CAs.

> As
> with other CAs in Mozilla’s program, GeoTrust will be expected to comply
> with Mozilla’s updated policy according to the timeline that is
> established when the updates to the policy become official.
>
> There is one remaining action item that is relevant to this discussion,
> but is already part of the recent CA Communication:
>
> ACTION: Complete the action item #2 from the recent CA Communication:
> "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."
>
> My expectation is that this will be done at the same time that the
> action item regarding updating the CP/CPS to conform with the CAB Forum
> Baseline Requirements is done. (e.g. by July 1, 2012). Therefore, my
> plan is to continue tracking both of these action items in regards to
> the CA Communication Responses, and not duplicate the action item in
> this bug.

OK. * By way of fantasy or example, CAs could simply propose that such
a statement be mandated in BR.

> If there are no further comments on this request to enable EV for the
> “GeoTrust Primary Certification Authority - G3” root certificate, then I
> will close this discussion and recommend approval in the bug.

OK

iang

[Stephen Schultze]

I still object to this approval on the grounds that GeoTrust has not
satisfied the requirement (request? suggestion?) found here:

https://wiki.mozilla.org/CA:Problematic_Practices#Allowing_external_entities_to_operate_subordinate_CAs

"Where a root from a CA signs an intermediate certificate used by an
external CA to then sign subsidiary intermediate certificates or
subscriber certificates, that situation needs to be disclosed. That
disclosure should include documentation of what requirements are imposed
by the CA owning the root upon the operations of external CAs. Further,
the public audit report for the CA owning the root must indicate how and
when the operations of the external CAs have been reviewed for
compliance with those documented requirements.

You must provide a clear description of the subordinate CAs that are
operated by external third parties, and an explanation as to how the
CP/CPS and audits ensure the third parties are in compliance with
Mozilla's CA Certificate Policy requirements as per the Subordinate CA
Checklist."

But it seems that there is not sufficient will within Mozilla to enforce
this.

Steve

[Kathleen Wilson]

On 4/25/12 7:28 AM, Stephen Schultze wrote:
> I still object to this approval on the grounds that GeoTrust has not
> satisfied the requirement (request? suggestion?) found here:
>
> https://wiki.mozilla.org/CA:Problematic_Practices#Allowing_external_entities_to_operate_subordinate_CAs
>

>...

> You must provide a clear description of the subordinate CAs that are
> operated by external third parties, and an explanation as to how the
> CP/CPS and audits ensure the third parties are in compliance with
> Mozilla's CA Certificate Policy requirements as per the Subordinate CA
> Checklist."
>

Subordinate CA Checklist:
https://wiki.mozilla.org/CA:SubordinateCA_checklist

Rick, please re-confirm that the externally-operated subCAs chaining up
to the GeoTrust roots in NSS are "Third-Party Private (or Enterprise)
Subordinate CAs", and then please supply the information as per the list
on that wiki page.

The list has:
"1. General description of the sub-CAs operated by third parties."
This is not the same as providing a list of all of the subCA customers.

Note that this particular request is to EV-enable a root that is already
included in NSS. This particular root does not have externally-operated
subCAs, and EV is not allowed for externally-operated subCAs. However,
as previously mentioned, this is an opportune time when the CA's
operations of all of their roots that are currently included in NSS may
be re-reviewed and discussed. Along these lines, Mozilla's current
policy/practices apply, such as
https://wiki.mozilla.org/CA:SubordinateCA_checklist.

Thanks,
Kathleen

[Tom Lowenthal]

I agree that this requirement does not appear to be satisfied. This
request should not proceed until it satisfies this requirement.

When there are sensible, coherent objections like Steve's that a pending
request does not satisfy our requirements, that Mozillian's objections
should be satisfied before the request moves forward.

[Rick Andrews]

We have provided a notice to our GeoRoot customers who maintain public subordinate CAs under a GeoTrust CA regarding the audit requirements specified in your webpage: https://wiki.mozilla.org/CA:SubordinateCA_checklist. GeoTrust will continue to work with our subordinate CA customers in good faith to provide the required information.

While we work through this process, which is expected to take several months, we request that Mozilla proceed on approval of https://bugzilla.mozilla.org/show_bug.cgi?id=539255.

[Steve Schultze]

What do you take those audit requirements to be? What was the text that
you sent to your third-party SubCA customers?

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

[Kathleen Wilson]

Thanks again to those of you who reviewed this request and participated
in this discussion.

I am now closing this discussion and will track the following action
item in the bug.

ACTION Symantec/GeoTrust: Provide the information listed in
https://wiki.mozilla.org/CA:SubordinateCA_checklist
for the GeoTrust root certificates that are currently included in NSS.

After this information is provided in the bug, I will start a new
discussion for this request.

Any further follow-up on this round of discussion should be added
directly to the bug.

https://bugzilla.mozilla.org/show_bug.cgi?id=539255

Thanks,
Kathleen