GlobalSign Root Inclusion Request
Kathleen Wilson
worldwide) has applied to add the �GlobalSign Root CA - R3� root
certificate, and to enable all three trust bits. The request is to also
enable EV.
The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=507360
And in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/#GlobalSign
Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=420152
* The CP and CPS documents are in English.
** CPS: http://www.globalsign.com/repository/GlobalSign_CPS_v6.5.pdf
** CP: http://www.globalsign.com/repository/GlobalSign_CA_CP_v3.4.pdf
Noteworthy points:
* This is a SHA256 version of the GlobalSign SHA1 root that is already
included in NSS.
** The �GlobalSign Root CA� root was approved in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=406794#c19
** The �GlobalSign Root CA - R2� root was approved in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=367245#c12
* The plan for the hierarchy under this new root is to have
internally-operated intermediate issuing CAs for each product type,
including EV.
** In the future, it is possible that this root will sign externally
operated sub-CAs. If this does happen then the rules followed today will
apply. Subordinate CA requirements are described in the CPS, including
following CPS and audits. See CPS section 1.10.7.3.
** There are no plans to cross sign another CA with this root.
* The request is to enable all three trust bits.
* Email: GlobalSign verifies that the entity submitting the request
controls the email account associated with the email address referenced
in the certificate, using an email-based challenge/response mechanism.
(CPS sections 1.3 to 1.7)
* SSL: GlobalSign verifies domain ownership/control as specified in the
CPS in sections 1.8 (OrganizationSSL), 1.9 (DomainSSL), 1.10
(ExtendedSSL), 1.11 (Eductational ServerSign), and 3.3.1 (Documents used
for subscriber registration).
* Code: GlobalSign verifies that the entity submitting the certificate
signing request is the same entity referenced in the certificate. (CPS
section 1.12)
* The request is to also enable EV. (CPS section 1.10)
** EV Policy OID: 1.3.6.1.4.1.4146.1.1
* Test Website: https://2029.globalsign.com
* The root has been created (A ceremony to WebTrust audited standards
witnessed by E&Y). However, this root is not yet active, so full CRL and
OCSP support have not yet been provided for it.
* CRL: http://crl.globalsign.net/root-r3.crl
** End-entity CRL: http://crl.globalsign.net/SHA256ExtendVal1.crl
** Currently NextUpdate 30 days, will change per CPS when root becomes
active.
** CPS section 7.2, CRL Profile: Next Update = Date of Issuance + 3 hours
* OCSP is not yet provided for this root.
** For the EV roots already in NSS the OCSP responder URL is:
http://evssl-ocsp.globalsign.com/responder
** OCSP will be provided on an 'as needed' basis. So any certificate
hierarchy that requires OCSP will have it. The root itself will be used
to sign OCSP responder certificates. OCSP responses for EV end entity
certificates will be compliant with CABForum guidelines.
* Audit: GlobalSign is audited annually by Ernst & Young. The 2009
audits are posted on the cert.webtrust.org website.
** WebTrust CA: https://cert.webtrust.org/SealFile?seal=928&file=pdf
** WebTrust EV: https://cert.webtrust.org/SealFile?seal=929&file=pdf
** Both of these audits cover the root CAs: �GlobalSign Root CA�,
GlobalSign Root CA � R2� and �GlobalSign CA for Adobe�.
** The 2010 audit is in progress, and will also include this new
GlobalSign Root CA � R3 root.
* Other
** DV certs are valid for one to five years. (CPS section 1.9.1)
** GlobalSign uses designated Registration Authorities. (CP section 2.3.2)
** GlobalSign provides the option for generating the private key. (CPS
section 1.9.6)
** IP addresses may be incorporated as a Subject Alternative Name
extension. (CPS section 1.9.4)
This begins a one-week discussion period. After that week, I will
provide a summary of issues noted and action items. If there are no
outstanding issues, then this request can be approved. If there are
outstanding issues or action items, then an additional discussion may be
needed as follow-up.
Kathleen
Stephen Schultze
> * The plan for the hierarchy under this new root is to have
> internally-operated intermediate issuing CAs for each product type,
> including EV.
Does one of these product types include their current "Trusted Root
for Inhouse PKI / Certificate Authority" product?
http://www.globalsign.com/certificate-authority-root-signing/internal-pki/
What is the complete list of all Subordinate CAs under their current
root? (Serial no: 04:00:00:00:00:01:0F:86:26:E6:0D)
> ** In the future, it is possible that this root will sign externally
> operated sub-CAs. If this does happen then the rules followed today will
> apply. Subordinate CA requirements are described in the CPS, including
> following CPS and audits. See CPS section 1.10.7.3.
What are "the rules followed today"? What is an example of how they
would apply in practice.
Section 1.10.7.3 appears to be speaking only to EV certs.
Johan Sys
I am representing GlobalSign. Please see answers inline.
On Apr 1, 4:30 am, Stephen Schultze <sjschultze.use...@gmail.com>
wrote:
> On Mar 31, 3:03 pm, Kathleen Wilson <kathleen95...@yahoo.com> wrote:
>
> > * The plan for the hierarchy under this new root is to have
> > internally-operated intermediate issuing CAs for each product type,
> > including EV.
>
> Does one of these product types include their current "Trusted Root
> for Inhouse PKI / Certificate Authority" product?http://www.globalsign.com/certificate-authority-root-signing/internal...
Currently not, but we would ideally migrate our Enterprise Trusted
Root customers to this new root in the future.
>
> What is the complete list of all Subordinate CAs under their current
> root? (Serial no: 04:00:00:00:00:01:0F:86:26:E6:0D)
>
The hierarchy includes Subordinate CAs under which GlobalSign issues
its own products, and one Trusted Root Partner CA under which the
inhouse PKI subca’s are issues. We cannot currently disclose all
Subordinate CAs as we are bound by NDA’s with the companies involved.
If this becomes a requirement of Mozilla, we will re-evaluate and take
measures.
> > ** In the future, it is possible that this root will sign externally
> > operated sub-CAs. If this does happen then the rules followed today will
> > apply. Subordinate CA requirements are described in the CPS, including
> > following CPS and audits. See CPS section 1.10.7.3.
>
> What are "the rules followed today"? What is an example of how they
> would apply in practice.
>
> Section 1.10.7.3 appears to be speaking only to EV certs.
TrustedRoot operation is further outlined in our Certificate Policy
(http://www.globalsign.com/repository/GlobalSign_CA_CP_v3.4.pdf) in
section 2.1.1, 2.1.2, 2.3, 2.4 and 2.5
All the best, Johan
Stephen Schultze
This new root request provides the Mozilla community the opportunity
to apply its Subordinate CA requirements, which have become more
stringent since the last time GlobalSign received a root CA approval.
As such, it also serves as an opportunity to examine GlobalSign
practices for already-issued roots and to consider whether practices
with those existing roots merit continued inclusion. David E. Ross
explained this in a post on an earlier thread:
> I believe that the certificate authorities for the roots added before 2009 are on notice that periodic audit reports are to be provided to the Mozilla organization. If so, it then becomes the responsibility of the reviewers of those reports to see if external sub-CAs are cited.
>
> Since this is likely to become a form of renewal of the approvals of those old CAs, such reviews provide the opportunity to question how external sub-CAs are themselves audited or at least reviewed and what policies they must follow.
>
> If a legacy CA stonewalls such questioning, it would be most appropriate to (1) removed that CA's root and (2) make a public statement as to why the root has been removed.
> > On Mar 31, 3:03 pm, Kathleen Wilson <kathleen95...@yahoo.com> wrote:
> > > * The plan for the hierarchy under this new root is to have
> > > internally-operated intermediate issuing CAs for each product type,
> > > including EV.
> On Apr 1, 4:30 am, Stephen Schultze <sjschultze.use...@gmail.com> wrote:
> > Does one of these product types include their current "Trusted Root
> > for Inhouse PKI / Certificate Authority" product?http://www.globalsign.com/certificate-authority-root-signing/internal...
On Apr 5, 2:51 am, Johan Sys <johan....@gmail.com> wrote:
> Currently not, but we would ideally migrate our Enterprise Trusted
> Root customers to this new root in the future.
> > What is the complete list of all Subordinate CAs under their current
> > root? (Serial no: 04:00:00:00:00:01:0F:86:26:E6:0D)
>
> The hierarchy includes Subordinate CAs under which GlobalSign issues
> its own products, and one Trusted Root Partner CA under which the
> inhouse PKI subca’s are issues. We cannot currently disclose all
> Subordinate CAs as we are bound by NDA’s with the companies involved.
> If this becomes a requirement of Mozilla, we will re-evaluate and take
> measures.
It is already a requirement that you disclose your Subordinate CAs.
There is no exception built into the requirements, but if you have an
exceptional case I'm sure the community would consider it. Kathleen
described it like this:
>"...the selection criteria for their sub-CAs and their sub-CAs will be a critical decision factor in the initial root inclusion. We ask CAs who issue or may issue externally operated sub-CAs to point us to the parts of the CP that clearly explain who can apply to operate a sub-CA (at any level), the selection/approval process for sub-CAs and their sub-CAs, the verification procedures applied to sub-CAs and their sub-CAs, what restrictions (legal and technical) are placed on all sub-CAs (eg constraints to issuing certs within certain domains)."
In addition, these requirements are spelled out in the
SubordinateCA_Checklist:
https://wiki.mozilla.org/CA:SubordinateCA_checklist
Here is an example of a properly completed Sub-CA checklist:
https://bugzilla.mozilla.org/show_bug.cgi?id=438825
In addition, these requirements are noted in the "Potentially
Problematic Practices" document:
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 list and 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.
> > On Mar 31, 3:03 pm, Kathleen Wilson <kathleen95...@yahoo.com> wrote:
> > > ** In the future, it is possible that this root will sign externally
> > > operated sub-CAs. If this does happen then the rules followed today will
> > > apply. Subordinate CA requirements are described in the CPS, including
> > > following CPS and audits. See CPS section 1.10.7.3.
> On Apr 1, 4:30 am, Stephen Schultze <sjschultze.use...@gmail.com> wrote:
> > What are "the rules followed today"? What is an example of how they
> > would apply in practice.
> >
> > Section 1.10.7.3 appears to be speaking only to EV certs.
On Apr 5, 2:51 am, Johan Sys <johan....@gmail.com> wrote:
> TrustedRoot operation is further outlined in our Certificate Policy
> (http://www.globalsign.com/repository/GlobalSign_CA_CP_v3.4.pdf) in
> section 2.1.1, 2.1.2, 2.3, 2.4 and 2.5
Your information gathering document states: "Subordinate CA
requirements are described in the CPS, including following CPS and
audits." At the very least, it should mention that the CP speaks to
these issues.
However, as far as I can tell, the CP doesn't say anything substantial
about your standards for approving CAs, requirements on their issuing
practices, or audits of them. Below is all of the relevant text that
I could find in the CP document. Can you point out the sections that
you think are informative in this regard?
> 2.1.1: "TrustedRoot certificates:
> - Are issued by GlobalSign to a third party CA that meets the contractual and policy requirements of GlobalSign TrustedRoot services with regard to operational practices and technical implementation. "
>
> 2.1.2: "Certain limitations apply to the use of GlobalSign TrustedRoot and TrustedRoot certificates which typically allow for authentication of the third party CA within an application environment in order to facilitate relying parties in establishing the identity of the CA.
>
> Any other use of GlobalSign TrustedRoot and TrustedRoot certificates is forbidden."
>
> 2.3.1: GlobalSign is also a Policy Authority while this Certificate Policy is a policy for the issuance of GlobalSign TrustedRoot certificates.
>
> [...] A subject of GlobalSign CA chaining services is a third party CA that successfully contracts with GlobalSign on the delivery of root services. Root certificates are issued for the purpose of authenticating the trust anchor of a hierarchy as well as the certification path prior to relying on a digital certificate issued by a lower hierarchically CA. Any other uses of root certificates are restricted.
>
> Root certificates can be used for any public purposes. As "public", this CP considers any use that takes place among CAs that is not restricted to uses governed by voluntary agreements under private law among participants. Closed user groups are also permitted to leverage on the GlobalSign hierarchy.
>
> The GlobalSign CA drafts and implements the policy prevailing in issuing a certain type or class of digital certificates.
>
> 2.3.3:
> Subscribers of GlobalSign TrustedRoot are third party CAs that seek to be issued with certificates within a hierarchy managed by GlobalSign. Subscribers of GlobalSign services are also natural persons or legal persons that successfully apply for a CA certificate. Subscribers use electronic signature services within the domain of the GlobalSign. Subscribers are parties that:
>
> - Set the framework of providing certification services with the GlobalSign CA to the benefit of the subject mentioned in a certificate.
> - Have ultimate authority over the private key corresponding to the public key that is listed in a subject certificate.
>
> Legal persons must be duly represented by an authorised agent (e.g. an authorised Director).
>
> Legal persons which are natural persons, are conditionally accepted as subscribers for CA chaining services. The relationship of these persons with the CA to be chained to has to be duly explained and justification must be provided to GlobalSign. If representation of a third party is desired, GlobalSign recommends alternative credentials might be required (e.g. attribute or role certificates), which, however, can be arranged on a case-by-case basis.
>
> Subscribers typically hold a valid identification document, such as an identity card, passport or equivalent, which is used as credential in order to issue electronic certificates. Additional identification of the applying organisation is also needed.
>
>
> 2.4.1 Appropriate certificate usage
> Root certificates issued under the GlobalSign CA can be used to issue digital certificates for public domain transactions that require:
> - Authentication
> - Assurance about the identity of a remote device
>
> Additional uses are specifically designated once they become available to end entities. Unauthorised use of GlobalSign CA certificates may result in an annulment of warranties offered by the GlobalSign CA to subscribers and relying parties.
>
> 2.4.2 Prohibited certificate usage
> End entity certificate use is restricted by using certificate extensions on key usage and extended key usage. Any usage of the certificate inconsistent with these extensions is not permitted.
>
>
> 2.4.4 Critical Extensions GlobalSign uses certain critical extensions in the certificates it issues such as:
> - A basic constraint in the key usage to show whether a certificate is meant for a CA or not.
> - To show the intended usage of the key.
> - To show the number of levels in the hierarchy under a CA certificate.
>
> 2.5.3 Acceptance of Updated Versions of the CP
> Upon approval of a CP update by the GlobalSign Policy Management Authority that CP is published in the GlobalSign online Repository at http://www.globalsign.com/repository.
>
> GlobalSign publishes a notice of such updates on its public web site at http://www.globalsign.com. The updated version is binding against all existing and future subscribers unless notice is received within 30 days after communication of the notice.
Stephen Schultze
issue.
GlobalSign has an office in Shanghai:
http://www.globalsign.com/company/press/022508-china-ssl.html
What is GlobalSign's policy with respect to complying with orders from
the Chinese government? If the government told GlobalSign that it
must issue a Subordinate CA certificate to it, would it do so? What
about an SSL certificate for a third-party site not controlled by the
Chinese government?
Why is GlobalSign's Chinese-language site inaccessible from the United
States? (results in connection reset)
http://cn.globalsign.com/
Kathleen Wilson
> There is no exception built into the requirements, but if you have an
> exceptional case I'm sure the community would consider it.
I would like to clarify this by pointing out some information in
https://wiki.mozilla.org/CA:SubordinateCA_checklist
There are two sections to the checklist:
1) The first section is called "Subordinate CAs Operated by Third
Parties for Internal Use", and only asks for a general description of
those sub-CAs -- not a list of the names of those sub-CAs. Therefore, we
do not ask that these types of sub-CAs be publicly disclosed. For these
types of sub-CAs we are primarily interested in the CP/CPS/audit
requirements that they are required to follow.
2) The second section is called "Subordinate CAs Operated by Third
Parties for External Use", this section applies to externally operated
sub-CAs that are used by Certificate Service Providers. This section
asks for the sub-CA company name, URL, CP/CPS, etc.
Kathleen
Stephen Schultze
> > It is already a requirement that you disclose your Subordinate CAs.
> > There is no exception built into the requirements, but if you have an
> > exceptional case I'm sure the community would consider it.
>
>
> There are two sections to the checklist:
>
> 1) The first section is called "Subordinate CAs Operated by Third
> Parties for Internal Use", and only asks for a general description of
> those sub-CAs -- not a list of the names of those sub-CAs. Therefore, we
> do not ask that these types of sub-CAs be publicly disclosed. For these
> types of sub-CAs we are primarily interested in the CP/CPS/audit
> requirements that they are required to follow.
>
> 2) The second section is called "Subordinate CAs Operated by Third
> Parties for External Use", this section applies to externally operated
> sub-CAs that are used by Certificate Service Providers. This section
> asks for the sub-CA company name, URL, CP/CPS, etc.
>
> Kathleen
Kathleen, is there any technical distinction between the two (ie:
specific x.509 constraints in the cert)?
If not, it seems that the only distinction would be some sort of
contract between the original CA and the Sub-CA. How does the
community feel about this? Is it truly a distinction, or are even
"internal use" certs effectively "external use"? If it is sufficient,
how much description of the policy for "internal use" certs is enough?
In this particular case, is it relevant that GlobalSign's CP states:
"Root certificates can be used for any public purposes"?
Eddy Nigg
> If not, it seems that the only distinction would be some sort of
> contract between the original CA and the Sub-CA. How does the
> community feel about this? Is it truly a distinction, or are even
> "internal use" certs effectively "external use"? If it is sufficient,
> how much description of the policy for "internal use" certs is enough?
>
> In this particular case, is it relevant that GlobalSign's CP states:
> "Root certificates can be used for any public purposes"?
>
I believe this really, really depends what the policy requirements are.
The sub CAs must be audited in my opinion and have the same requirements
(e.g. validations) as any other intermediate CA following their policy.
In particular this includes domain and email control validation, since
we've seen the very negative effects when these have been outsourced in
the past. Besides that, I believe it's fine to have such sub CAs....
again, provided that the Mozilla CA Policy requirements are upheld to
the letter (and not simply by some contractual arrangements). That's the
due diligence which the CAs must perform.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Stephen Schultze
> On 04/05/2010 09:54 PM, Stephen Schultze:
>
> > If not, it seems that the only distinction would be some sort of
> > contract between the original CA and the Sub-CA. How does the
> > community feel about this? Is it truly a distinction, or are even
> > "internal use" certs effectively "external use"? If it is sufficient,
> > how much description of the policy for "internal use" certs is enough?
>
> > In this particular case, is it relevant that GlobalSign's CP states:
> > "Root certificates can be used for any public purposes"?
>
> I believe this really, really depends what the policy requirements are.
> The sub CAs must be audited in my opinion and have the same requirements
> (e.g. validations) as any other intermediate CA following their policy.
>
> In particular this includes domain and email control validation, since
> we've seen the very negative effects when these have been outsourced in
> the past. Besides that, I believe it's fine to have such sub CAs....
> again, provided that the Mozilla CA Policy requirements are upheld to
> the letter (and not simply by some contractual arrangements). That's the
> due diligence which the CAs must perform.
What exactly do you mean by "such sub CAs"? Do you mean that it seems
acceptable to have "internal use" CAs that are not disclosed to the
Mozilla community? How would we have any assurance that any policies
are respected or audits are performed, other than taking the root-CA's
word for it?
Even if we were able to resolve concerns around policy and audits, the
CA trust model assumes that users can proactively police their own
cert database according to their unique security needs. Undocumented
sub-CAs subvert this model, regardless of whether they are
theoretically for "internal use" or not.
In fact, I might be more concerned about supposedly "internal use"
CAs, given the more lax oversight we've seen in SSL certificate
granting for supposedly internal domains (eg: the many domains that
were granted for ".int" to entities that did not own the domains in
question).
Eddy Nigg
What exactly do you mean by "such sub CAs"? Do you mean that it seems acceptable to have "internal use" CAs that are not disclosed to the Mozilla community?
Obviously only until you raise a concern that those requirements prove to be insufficient to guaranty the users security to a reasonable extend.
How would we have any assurance that any policies are respected or audits are performed, other than taking the root-CA's word for it?
Even if we were able to resolve concerns around policy and audits,
the CA trust model assumes that users can proactively police their own cert database according to their unique security needs.
Undocumented sub-CAs subvert this model, regardless of whether they are theoretically for "internal use" or not.
In fact, I might be more concerned about supposedly "internal use" CAs, given the more lax oversight we've seen in SSL certificate granting for supposedly internal domains (eg: the many domains that were granted for ".int" to entities that did not own the domains in question).
for a certificate to be used for SSL-enabled servers, the CA takes reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate or has been authorized by the domain registrant to act on the registrant's behalf;
Do you see here anywhere anything besides registered domain names? I don't, do you?
PS: A CA which issues certificates for IP addresses, non-qualified hostnames aka "server1" or non-registered domain names aka .int or .local, run risk of non-compliance to the Mozilla CA Policy. This would be valid concern to be raised.
David E. Ross
I did not ask for the CA to identify its external subsidiary CAs
although that was indeed added to the "Problematic Practices" under
"Allowing external entities to operate subordinate CAs" at
<https://wiki.mozilla.org/CA:Problematic_Practices#Allowing_external_entities_to_operate_subordinate_CAs>.
However, "Problematic Practices" is not a formal Mozilla policy and is
not grounds for denying a request to add a new root.
What I did ask was that the CA should indicate whether or not it does
have external subsidiary CAs. If so -- and most important -- how does
the CA ensure that its external subsidiary CAs operate appropriately.
This is clearly addressed in the second paragraph of "Allowing external
entities to operate subordinate CAs".
CAs are requested to review "Problematic Practices" and disclose if any
their their practices are contained therein. That disclosure should
also indicate how potential problems are mitigated. If, upon the public
review of a CA's request, mitigations are thought to be insufficient,
that should be grounds for rejecting the request.
Thus, a problematic practice in itself is not grounds for rejection; but
how such a practice is handled by the the CA can be grounds for rejection.
--
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
Stephen Schultze
> On 04/05/2010 11:26 PM, Stephen Schultze:
> > or audits are performed, other than taking the root-CA's word for it?
>
> The audit itself first and foremost, that's why the audit requirement
> exists in first place. We can't perform an audit instead of the
> auditors. Second, the policies must disclose the requirements for such
> sub CAs, besides all the rest of course...
Yes, but if there is a requirement for sub-CA audit but the audit
results are not disclosed, what good are they? Maybe I'm missing
something.
> > Even if we were able to resolve concerns around policy and audits,
>
> I believe there is no concern about the audit. But did you check what
> GlobalSign's policies say in this respect. This is the key for any
> further discussion I believe.
I did, and I posted any relevant portions of the CP that I could find
above and noted, "as far as I can tell, the CP doesn't say anything
substantial about your standards for approving CAs, requirements on
their issuing practices, or audits of them." I look forward to their
answer.
> > the CA trust model assumes that users can proactively police their own
> > cert database according to their unique security needs.
>
> I don't think so...and if this is what GlobalSign has disclosed as their
> requirements for sub CAs, we have something to discuss here ;-)
I do. The whole idea of a user-customizable CA list is that different
users will want to trust different roots. When undocumented sub-CAs
can appear and be trusted silently, that model breaks down.
My general argument is that if something behaves like a CA, it should
be held to the same standards as a CA, including public disclosure.
If an entity is given the technical power to create certificates for
any domain (which even "internal use" CAs are given), then they need
to be audited and the community needs to see the output of that
process.
Stephen Schultze
> Thus, a problematic practice in itself is not grounds for rejection; but
> how such a practice is handled by the the CA can be grounds for rejection.
Point taken, and we should go through that analysis.
However, I believe that the SubordinateCA_Checklist is indeed treated
as formal Mozilla policy, and that failure to satisfy its requirements
is direct cause for rejection. Correct me if I'm wrong.
Eddy Nigg
>> The audit itself first and foremost, that's why the audit requirement
>> exists in first place. We can't perform an audit instead of the
>> auditors. Second, the policies must disclose the requirements for such
>> sub CAs, besides all the rest of course...
>>
> Yes, but if there is a requirement for sub-CA audit but the audit
> results are not disclosed, what good are they? Maybe I'm missing
> something.
>
Perhaps. The audit confirms the disclosed policies and practice
statements. What's disclosed and if the sub CAs are covered are in the
CP/CPS.
> I did, and I posted any relevant portions of the CP that I could find
> above and noted, "as far as I can tell, the CP doesn't say anything
> substantial about your standards for approving CAs, requirements on
> their issuing practices, or audits of them." I look forward to their
> answer.
>
So the representative of GlobalSign will have to provide an answer why
it's not disclosed and what exactly the requirements are. It's not
uncommon that action items have to be performed by the CAs prior to
approval. This would be a deficiency which would have to be corrected if
proved to be correct.
> I do. The whole idea of a user-customizable CA list is that different
> users will want to trust different roots. When undocumented sub-CAs
> can appear and be trusted silently, that model breaks down.
>
Undocumented sub CAs are not part of the WebTrust audits nor of the
Mozilla CA policy. The CP/CPS must disclose sufficiently and to the
requirements of the Mozilla CA Policy. There is no other policy here
than this and you don't have to trust undisclosed sub CAs. Further if
you can provide evidence of CAs which did not disclose their requirement
of subordinate CAs and/or those disclosed don't conform to the Mozilla
CA Policy feel free to report it here.
Stephen Schultze
> On 04/06/2010 12:24 AM, Stephen Schultze:
> > users will want to trust different roots. When undocumented sub-CAs
> > can appear and be trusted silently, that model breaks down.
>
> Undocumented sub CAs are not part of the WebTrust audits nor of the
> Mozilla CA policy. The CP/CPS must disclose sufficiently and to the
> requirements of the Mozilla CA Policy. There is no other policy here
> than this and you don't have to trust undisclosed sub CAs.
I don't quite understand your phrasing. Are you saying that
undocumented Sub-CAs are not the subject matter of audits, or that
they are explicitly not permitted under the terms of the audits?
In any case, it seems clear that the WebTrust audits (and the like) do
not require Sub-CAs to be publicly disclosed. The Mozilla CA Policy
(going forward from 2009) requires them to be disclosed, but only if
they are granted for "external" use.
As a practical matter, users have no option but to trust undisclosed
CAs or disable all roots. Take for example the Entrust sub-CA for
CNNIC. If I am a user that does not trust CNNIC, I can remove the
trust bit on the main CNNIC root, but I cannot preemptively do so for
the CNNIC sub-CA that I don't know about. Furthermore, even if I know
about that sub-CA cert I can only disable it by removing the trust
bits for Entrust altogether. Now, under updated Mozilla policy that
cert would apparently have to be disclosed (except that exceptions
appear to be made from time to time). "Internal" CA certs are another
story, and because they apparently differ in no technical way from
"external" CA certs, I would argue that they are no different.
> Further if you can provide evidence of CAs which did not disclose their requirement
> of subordinate CAs and/or those disclosed don't conform to the Mozilla
> CA Policy feel free to report it here.
The best we can do is have a firm and universal disclosure requirement
so that we know that all sub-CAs really are supposed to be disclosed,
and so that when they are disclosed we can monitor them for CA Policy
conformance.
Eddy Nigg
> I don't quite understand your phrasing. Are you saying that
> undocumented Sub-CAs are not the subject matter of audits, or that
> they are explicitly not permitted under the terms of the audits?
>
The audits must cover the entire CA infrastructure and WebTrust and
Mozilla require disclosure of the requirements and controls for sub CAs.
> In any case, it seems clear that the WebTrust audits (and the like) do
> not require Sub-CAs to be publicly disclosed. The Mozilla CA Policy
> (going forward from 2009) requires them to be disclosed, but only if
> they are granted for "external" use.
>
I think there is a misunderstanding here. With "external" we mean ANY
intermediate CA certificate which is operated external to the parent CA
infrastructure. With "internal" we mean intermediate CA certificates
which are used by the CA itself for the issuing of end-user certificates.
> As a practical matter, users have no option but to trust undisclosed
> CAs or disable all roots.
That's not entirely correct.
> Take for example the Entrust sub-CA for CNNIC.
Actually this root is cross-signed, but yes, it appears like a sub CA.
You have to read the CA policies and practice statements of Entrust in
order to understand what their policies and requirements are for
cross-signing a different CA root.
> If I am a user that does not trust CNNIC, I can remove the
> trust bit on the main CNNIC root, but I cannot preemptively do so for
> the CNNIC sub-CA that I don't know about. Furthermore, even if I know
> about that sub-CA cert I can only disable it by removing the trust
> bits for Entrust altogether.
That's correct.
> Now, under updated Mozilla policy that
> cert would apparently have to be disclosed (except that exceptions
> appear to be made from time to time).
Yes.
> "Internal" CA certs are another
> story, and because they apparently differ in no technical way from
> "external" CA certs, I would argue that they are no different.
>
Again, internal sub CAs are intermediate CA certificates used by the CA
itself.
> The best we can do is have a firm and universal disclosure requirement
> so that we know that all sub-CAs really are supposed to be disclosed,
> and so that when they are disclosed we can monitor them for CA Policy
> conformance.
>
I believe it's even better to insist on disclosure that requires all CA
certificates subordinated to the root to comply to the Mozilla CA Policy.
Stephen Schultze
> On 04/06/2010 05:04 AM, Stephen Schultze:
> Mozilla require disclosure of the requirements and controls for sub CAs.
I don't believe that WebTrust requires disclosure. If that's the
case, how is it that existing CAs that are WebTrust certified do not
disclose Sub-CAs?
> > In any case, it seems clear that the WebTrust audits (and the like) do
> > not require Sub-CAs to be publicly disclosed. The Mozilla CA Policy
> > (going forward from 2009) requires them to be disclosed, but only if
> > they are granted for "external" use.
>
> I think there is a misunderstanding here. With "external" we mean ANY
> intermediate CA certificate which is operated external to the parent CA
> infrastructure. With "internal" we mean intermediate CA certificates
> which are used by the CA itself for the issuing of end-user certificates.
That's not how it is described here, although I wish it were the case:
https://wiki.mozilla.org/index.php?title=CA:SubordinateCA_checklist
> > As a practical matter, users have no option but to trust undisclosed
> > CAs or disable all roots.
>
> That's not entirely correct.
Why?
> > Take for example the Entrust sub-CA for CNNIC.
>
> Actually this root is cross-signed, but yes, it appears like a sub CA.
> You have to read the CA policies and practice statements of Entrust in
> order to understand what their policies and requirements are for
> cross-signing a different CA root.
Actually, there was a sub-CA cert signed by Entrust (serial
42:87:A2:A0) in 2007. There was a separate sub-CA cert (49:33:00:15)
signed by the CNNIC root (49:33:00:01), but that root was not accepted
into NSS until 2009. To make things more confusing, the two sub-CA
certs (both CN=CNNIC SSL) share the same key material, which means
that the same site can chain up via either sub-CA cert. In any case,
my original point remains.
> > The best we can do is have a firm and universal disclosure requirement
> > so that we know that all sub-CAs really are supposed to be disclosed,
> > and so that when they are disclosed we can monitor them for CA Policy
> > conformance.
>
> I believe it's even better to insist on disclosure that requires all CA
> certificates subordinated to the root to comply to the Mozilla CA Policy.
>
> --
> Regards
>
> Signer: Eddy Nigg, StartCom Ltd.
> XMPP: start...@startcom.org
Johan Sys
Thank you all for the lively discussion. Some points raised are more
discussion around Mozilla-policy instead of this root inclusion
request. GlobalSign is committed to follow Mozilla’s guidelines.
Below we address only the specific questions.
This root inclusion request is in support of current crypto standards
and best-practices.
Thank you for pointing to the CA SubordinateCA checklist. Our
TrustedRoot service falls within the Subordinate CAs operated by Third
Parties for Internal use.
1. General description of the sub-CAs operated by third parties.
GlobalSign Trusted Root extends the capability of an enterprise
inhouse PKI / Certificate Authority (CA) solution to issue SSL and S/
MIME Digital Certificates chained to GlobalSign’s pre-distributed Root
Certificate. After review and approval, GlobalSign digitally signs
customer CA’s with its own GlobalSign TrustedRoot PartnerCA which is
chained to the GlobalSign RootCA.
2. The CP/CPS that the sub-CAs are required to follow.
SubCA’s must follow the GlobalSign Certificate Policy (http://
www.globalsign.com/repository/GlobalSign_CA_CP_v3.4.pdf) and publish
towards their subscribers a CPS approved by GlobalSign. GlobalSign
provides a template CPS based on its own CPS (but limited to Client
and Server certificates) which 95% of our SubCA’s implement.
3. Requirements (technical and contractual) for sub-CAs in regards to
whether or not sub-CAs are constrained to issue certificates only
within certain domains, and whether or not sub-CAs can create their
own subordinates
GlobalSign has the following contractual and technical terms in place
with each subCA:
• GlobalSign allowed to enforce new requirements during contract terms
• Use of TrustedRoot by Company and Subsidiary (50%+ controlling
interest) only
• Non-commercial use only : certificates for own use, staff, and third
parties affiliated with Company for internal business use only. No
reselling allowed.
• Compliance with GS Certificate Policy
• Restricting of types of certificates issued as specified : Client
SSL, Server SSL.
• Requirement of CPS finalized within 2 months of Trusted Root
execution
• Requirement of disclosure of physical, personnel, logical and
operational controls in line with Industry standards. These are
reviewed by GlobalSign.
• Requirement of disclosure of CA hierarchy. By default SubCA’s are
not allowed to issue subordinates unless their architecture requires
it (for example with Microsoft ActiveDirectory forests). If this is
the case, SubCA must have separate offline and online HSM protected
keys and provide the security controls in place.
• Requirement to notify GlobalSign of changes in environment.
• Requirement for FIPS 140 level 3 security module
• No cross-signing allowed
• Annual reporting requirement for Customer
• GS has the right, but no obligation, to audit Customer
representation of TrustedRoot
• Export controls of certificates issued by Customer enforced
4. Requirements (typically in the CP or CPS) for sub-CAs to take
reasonable measures to verify the ownership of the domain name and
email address for end-entity certificates chaining up to the root, as
per section 7 of our Mozilla CA certificate policy.
This is implemented in the SubCA CPS, section 1.3.5 and 1.4.5 , and
section 3. These can be modified by customer after approval by
GlobalSign. This is also contractually enforced.
5. Description of audit requirements for sub-CAs (typically in the CP
or CPS)
GlobalSign has annual Webtrust audits. The auditors includes the
vetting of organizations which receives SubCA’s and if GlobalSign
followed its own procedures before allowing SubCA’s. GlobalSign has
the contractually right, but not obligation, to audit its SubCA’s. We
invoke this right if breaches against stated policies by SubCA are
suspected.
To answer Stephen’s questions: the Certificate Practice Statement and
Certificate Policy provide an overview of our polices. These policies
are implemented in internal processes which are audited by Webtrust.
We have disclosed above the process to allow/disallow SubCA’s in our
hierarchy. If the CP should provide more detail on this topic, please
let us know and we will amend.
GlobalSign has sales offices all over the world, including in
Shangai. Our CA operations are based in Japan and Belgium. We have no
SubCA’s issued in China as we cannot issue SubCA’s against our own
procedures. We had to refuse requests from a number of applicants in
a number of countries.
Johan
Kurt Seifried
> Shangai. Our CA operations are based in Japan and Belgium. We have no
> SubCA’s issued in China as we cannot issue SubCA’s against our own
> procedures. We had to refuse requests from a number of applicants in
> a number of countries.
Right but that doesn't answer the question from Stephen Schultze:
"What is GlobalSign's policy with respect to complying with orders from
the Chinese government? If the government told GlobalSign that it
must issue a Subordinate CA certificate to it, would it do so? What
about an SSL certificate for a third-party site not controlled by the
Chinese government?"
Refusing applicants in the past is nice, but what about the future? Is
there some form of legal/administrative/business firewall in place to
prevent potential abuse by the Chinese government of your root CA?
Once it's in Firefox the problem is getting it out takes time and
effort if there is a problem.
> Johan
-Kurt
Johan Sys
Fair comment but these should be answered country-agnostic. We do
have Business and legal firewalls in place against this possibility.
GlobalSign CA operations operate under Belgian law (CPS section 9.14,
9.15) and follows European Directive 95/94 on the protection of
individuals. GlobalSign could not comply with orders from any Foreign
Government to issue a SubordinateCA against processes ( the Soghoian/
Stamm paper premise) as per our Data Protection Policy (http://
www.globalsign.com/repository/GlobalSign_Data_Protection_Policy.pdf)
5.10 Legal Disclosure of personal Data and especially 5.12 No escrow.
We do issue SSL certificates in China, but only after they are
properly vetted according to procedures.
All the best, Johan
Eddy Nigg
> On Apr 5, 10:19 pm, Eddy Nigg<eddy_n...@startcom.org> wrote:
>
>> On 04/06/2010 05:04 AM, Stephen Schultze:
>> The audits must cover the entire CA infrastructure and WebTrust and
>> Mozilla require disclosure of the requirements and controls for sub CAs.
>>
> I don't believe that WebTrust requires disclosure. If that's the
> case, how is it that existing CAs that are WebTrust certified do not
> disclose Sub-CAs?
>
There is a difference between disclosing WHICH sub CAs exist and
disclosure of the requirements and controls for sub CAs. Always read
carefully :-)
>> I think there is a misunderstanding here. With "external" we mean ANY
>> intermediate CA certificate which is operated external to the parent CA
>> infrastructure. With "internal" we mean intermediate CA certificates
>> which are used by the CA itself for the issuing of end-user certificates.
>>
> That's not how it is described here, although I wish it were the case:
> https://wiki.mozilla.org/index.php?title=CA:SubordinateCA_checklist
>
I don't know where it comes from, but it might be a mistake. Or I simply
don't remember, either might be correct. However the requirements are
clear in either case regarding what we care most. As such, I don't
understand the difference between the two in respect to the controls
and usage by the relying parties.
>> That's not entirely correct.
>>
> Why?
>
Because policy and practice statements must be disclosed. They must be
audited, hence you know the root and its entire infrastructure is. At
least that's what's supposed to be.
> Actually, there was a sub-CA cert signed by Entrust (serial
> 42:87:A2:A0) in 2007. There was a separate sub-CA cert (49:33:00:15)
> signed by the CNNIC root (49:33:00:01), but that root was not accepted
> into NSS until 2009. To make things more confusing, the two sub-CA
> certs (both CN=CNNIC SSL) share the same key material, which means
> that the same site can chain up via either sub-CA cert.
>
That's called cross-signing (or bridge signing I also heard?).
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Eddy Nigg
> To answer Stephen’s questions: the Certificate Practice Statement and
> Certificate Policy provide an overview of our polices. These policies
> are implemented in internal processes which are audited by Webtrust.
> We have disclosed above the process to allow/disallow SubCA’s in our
> hierarchy. If the CP should provide more detail on this topic, please
> let us know and we will amend.
>
I believe there is some additional disclosure requirement as per
https://wiki.mozilla.org/CA:Problematic_Practices#Allowing_external_entities_to_operate_subordinate_CAs
Some CAs have already implemented and follow a strict auditing (by
WebTrust) requirement for sub CAs.
E.g. sub CAs should be audited together with the root CA (site visit and
all that). The concerns were raised in the past that basically
sub-ordinate CAs practically and effectively circumvent the audit
requirement of Mozilla (and other software vendors). A CA which would
not have been admitted to the NSS roots store, will be trusted through
another CA.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Stephen Schultze
> On 04/06/2010 05:46 AM, Stephen Schultze:
> > On Apr 5, 10:19 pm, Eddy Nigg<eddy_n...@startcom.org> wrote:
> > > intermediate CA certificate which is operated external to the parent CA
> > > infrastructure. With "internal" we mean intermediate CA certificates
> > > which are used by the CA itself for the issuing of end-user certificates.
> > That's not how it is described here, although I wish it were the case:
> > https://wiki.mozilla.org/index.php?title=CA:SubordinateCA_checklist
>
> I don't know where it comes from, but it might be a mistake. Or I simply
> don't remember, either might be correct. However the requirements are
> clear in either case regarding what we care most. As such, I don't
> understand the difference between the two in respect to the controls
> and usage by the relying parties.
What is it that you claim we care most about? I think we care about
two things: 1) requirement and disclosure of auditing practices 2)
disclosure of the identities of the sub-CAs themselves. They are each
important for their own reasons, and I am not convinced that either is
more important than the other.
If the SubordinateCA_Checklist does not match your understanding of
current practices, perhaps we need to address that discrepancy.
> > > > As a practical matter, users have no option but to trust undisclosed
> > > > CAs or disable all roots.
> > > That's not entirely correct.
> > Why?
> Because policy and practice statements must be disclosed. They must be
> audited, hence you know the root and its entire infrastructure is. At
> least that's what's supposed to be.
But if the identity of all Sub-CAs is not disclosed, then the entire
infrastructure is not disclosed, and by definition undisclosed Sub-CAs
exist... and there's no way to protect against them as an end user
other than to disable all roots.
Stephen Schultze
> the Chinese government? If the government told GlobalSign that it
> must issue a Subordinate CA certificate to it, would it do so? What
> about an SSL certificate for a third-party site not controlled by the
> Chinese government?
Your own site seals indicate that GlobalSign is a registered business
in the United States, Belgium, Japan, and China.
Common Name (URL) cn.globalsign.com
Validity Period (DD/MM/YYYY) 12/11/2009-13/11/2011
Validity Status Valid
Organization Name GlobalSign China Co.,Ltd.
Place of Business
Street Rm 401, Sheng Tian Di Business Bldg., No 1165 Jiangning Rd
City Shanghai
State/Province Shanghai
Country Code CN
ZIP Code 200060
Tel Number 86-21-51801549
Jurisdiction Information
Jurisdiction Country CN
Jurisdiction State/Province Shanghai
Incorporating agency registration number 310000400552481
Your CPS may indicate that "Each party, including GlobalSign partners,
subscribers and relying parties, irrevocably submit to the
jurisdiction of the district courts of Leuven, Belgium," but it is not
clear that GlobalSign China Co.,Ltd. warrants anything about the
scenario I raised or that the Chinese government would be considered
one of those parties described in the clause.
Perhaps your counsel can comment on whether being incorporated as a
business in a given jurisdiction, and having staff in that
jurisdiction, subjects you to law of that jurisdiction.
Where does European Directive 95/94 speak to the scenario I raised?
Here is a link to the text:
http://ec.europa.eu/justice_home/fsj/privacy/docs/95-46-ce/dir1995-46_part1_en.pdf
Likewise, so far as I can tell, your Data Protection Policy deals with
disclosure of personally identifiable information, not compelled
issuance of certificates.
If the Chinese police come to Rm 401, Sheng Tian Di Business Bldg., No
1165 Jiangning Rd and demand either a particular SSL certificate or a
Sub-CA certificate (for a third-party entity), what will be your
answer? If they persist, will you: a) comply with their request b)
allow your staff to go to jail c) close your office in Shanghai?
Michael Ströder
> On 04/05/2010 11:26 PM, Stephen Schultze:
>> What exactly do you mean by "such sub CAs"? Do you mean that it seems
>> acceptable to have "internal use" CAs that are not disclosed to the
>> Mozilla community?
>
> Obviously I'd prefer to have them disclosed, but if we get assurance
> that those have been audited
How do you want to check whether a sub-CA has been audited if you don't at
least know the existence of the sub-CA?
Ciao, Michael.
Eddy Nigg
> How do you want to check whether a sub-CA has been audited if you don't at
> least know the existence of the sub-CA?
>
We don't have to check that, the auditor does that. However the CP/CPS
must disclose that the sub CAs requirements are audited amongst other
things. E.g. the CP discloses that the sub CAs are part of the regular
yearly audit and not for example self-audited by the CA. The later would
constitute to a circumvention of the Mozilla auditing requirement.
Stephen Schultze
> On 04/07/2010 08:01 PM, Michael Ströder:
>
> > How do you want to check whether a sub-CA has been audited if you don't at
> > least know the existence of the sub-CA?
>
> We don't have to check that, the auditor does that. However the CP/CPS
> must disclose that the sub CAs requirements are audited amongst other
> things. E.g. the CP discloses that the sub CAs are part of the regular
> yearly audit and not for example self-audited by the CA. The later would
> constitute to a circumvention of the Mozilla auditing requirement.
I'd like to expand on my reasoning for why it is important that end
users know not only that Sub-CAs are audited, but that they know their
identities. The auditing requirement imposes a baseline level of
operational standards on CAs, which is a good thing. The
identification of Sub-CAs allows users to customize their trust
policies based on the identity of the authorities in question. This
is important, because different types of users will have different
levels of trust for different entities. For instance, when the CNNIC
debate first cropped up, one answer from the Mozilla community was
that although CNNIC evidently passed the baseline *operational*
requirements, users that did not trust CNNIC because of its *identity*
could disable the root. However, the reality of undocumented Sub-CAs
meant that users could not in fact preemptively block CNNIC because it
might also have undocumented Sub-CAs under existing trusted roots.
The only way for the "you can block them on your own if you don't
trust them" argument to work is for all Sub-CAs to be disclosed.
Kathleen Wilson
> GlobalSign (a commercial CA based in the U.S. and serving customers
> worldwide) has applied to add the �GlobalSign Root CA - R3� root
> certificate, and to enable all three trust bits. The request is to also
> enable EV.
>
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=507360
Thank you to all of you who have reviewed this request and added your
comments and feedback to this discussion. Your contributions are
greatly appreciated.
This discussion is in regards to the request from GlobalSign to add the
�GlobalSign Root CA - R3� root certificate, and to enable all three
trust bits. The request is to also enable EV.
Here is a summary of the discussion so far.
1) Disclosure of Externally Operated Subordinate CAs
There was extensive discussion about the externally operated subordinate
CAs that are active under current GlobalSign roots that may be moved to
this new root. There was also a request that the identities of the
externally operated sub-CAs be disclosed. It is not currently Mozilla
practice or policy to request that CAs publicly disclose their
externally operated subordinate CAs that are only used for internal
purposes. For these types of sub-CAs we are primarily interested in the
CP/CPS/audit requirements that they are required to follow.
Johan (the GlobalSign representative) stated: �Our TrustedRoot service
falls within the Subordinate CAs operated by Third Parties for Internal
use.� In his posting on April 5, he provided the relevant information as
per the Subordinate CA Checklist.
ACTION: None
2) Auditing of Externally Operated Subordinate CAs
Concern was raised that subordinate CAs may be practically and
effectively circumventing the audit requirement of Mozilla. In other
words, a CA which would not have been admitted to the NSS roots store,
could be trusted through another CA.
I believe that this concern was addressed in Johan�s posting on April 5
which summarized the sub-CA requirements and the auditing of the vetting
of the sub-CA organizations.
ACTION: None
3) Orders from Governments
Questions were asked about GlobalSign�s policy in respect to complying
with orders from governments.
Johan responded: GlobalSign could not comply with orders from any
Foreign Government to issue a SubordinateCA against processes (the
Soghoian/ Stamm paper premise) as per our Data Protection Policy
(http://
www.globalsign.com/repositor/GlobalSign_Data_Protection_Policy.pdf) 5.10
Legal Disclosure of personal Data and especially 5.12 No escrow. We do
issue SSL certificates in China, but only after they are properly vetted
according to procedures.
ACTION: None
There was also a significant amount of discussion about the current
practices and policy, and in particular the subordinate CA checklist.
Note that I would categorize the subordinate CA checklist as a practice,
because it is not officially part of the Mozilla CA Certificate Policy.
Rather, it is the byproduct of several intensive discussions that
happened previously.
I encourage you to continue those policy discussions in a separate
discussion thread.
My assessment is that nothing in this discussion has raised a concern
that should prevent the addition of the �GlobalSign Root CA - R3� root
certificate, and the enablement of all three trust bits. I also have not
seen a concern that should prevent this root from being enabled for EV.
It is my opinion that this discussion may be closed and that I should
proceed with recommending approval in the bug.
Kathleen
Michael Ströder
Frankly I fail to see why you treat these both cases differently. Both types
of sub-CAs are equally powerful. Especially in case 1) there's not even a
theoretical chance to ever conduct an audit independent from Globalsign or at
least check whether an audit happened at all...
Besides that I find the term "for Interal Use" quite blurry because it does
not specify the potential relying participants. I guess in both cases you
assume that the whole Mozilla user base is the set of RPs. Right?
Ciao, Michael.
Eddy Nigg
> Frankly I fail to see why you treat these both cases differently. Both types
> of sub-CAs are equally powerful. Especially in case 1) there's not even a
> theoretical chance to ever conduct an audit independent from Globalsign or at
> least check whether an audit happened at all...
>
> Besides that I find the term "for Interal Use" quite blurry because it does
> not specify the potential relying participants. I guess in both cases you
> assume that the whole Mozilla user base is the set of RPs.
>
I must agree and I fail to see the difference. Further I'm not sure when
this was decided. Is this something which has been discussed and agreed
upon? Again, maybe I'm getting old and my memory is failing :-)
Michael Ströder
Even worse: AFAIK you cannot technically just block a sub-CA (even if you know
the identity). And the root CA could also re-issue new sub-CA certs with
different serial number and / or subject name.
Ciao, Michael.
Kathleen Wilson
> On 04/08/2010 09:39 PM, Michael Ströder:
>> Frankly I fail to see why you treat these both cases differently. Both
>> types
>> of sub-CAs are equally powerful. Especially in case 1) there's not even a
>> theoretical chance to ever conduct an audit independent from
>> Globalsign or at
>> least check whether an audit happened at all...
>>
>> Besides that I find the term "for Interal Use" quite blurry because it
>> does
>> not specify the potential relying participants. I guess in both cases you
>> assume that the whole Mozilla user base is the set of RPs.
>
> I must agree and I fail to see the difference. Further I'm not sure when
> this was decided. Is this something which has been discussed and agreed
> upon? Again, maybe I'm getting old and my memory is failing :-)
>
Yes, but a long time ago, so I doubt I'll be able to find the source.
It's been this way in the subordinate CA checklist since I created it in
2008. I created this checklist as a direct result of the discussions
that were happening at that time, and we went through a few iterations
of discussing and editing the checklist at that time.
My recollection is that the sub-CAs that are used internally are
supposed to be limited either contractually or technically in regards
what their subCA can sign, and who they can issue certs to (employees,
internal systems, etc). The difference being that these subCAs are not
selling or issuing certs outside of their company. To my knowledge,
Mozilla has never required a CA to publicly disclose the names of this
type of subCA.
Kathleen
Eddy Nigg
> Yes, but a long time ago, so I doubt I'll be able to find the source.
> It's been this way in the subordinate CA checklist since I created it
> in 2008. I created this checklist as a direct result of the
> discussions that were happening at that time, and we went through a
> few iterations of discussing and editing the checklist at that time.
Thanks Kathleen, for trying to refresh my memory.... :-)
>
> My recollection is that the sub-CAs that are used internally are
> supposed to be limited either contractually or technically in regards
> what their subCA can sign, and who they can issue certs to (employees,
> internal systems, etc).
Alright - generally speaking we used the term "internal" for any
intermediate CA consumed by the CA itself, whereas "external" are those
that are controlled and operated by sub CAs external to the CA. I'm
fairly sure that this has always been (at least mine) interpretation.
> The difference being that these subCAs are not selling or issuing
> certs outside of their company.
But they are relied upon everywhere. So what difference does it make?
> To my knowledge, Mozilla has never required a CA to publicly disclose
> the names of this type of subCA.
I'm not sure about that. But it's not MY major concern, rather that
those are not audited. That, in addition to non-disclosure, really
leaves a big black hole about we simply know nothing. We ought to change
that.
Stephen Schultze
discussion so far.
Kathleen,
I have a fairly different impression of the discussion to date.
1) Disclosure of Externally Operated Subordinate CAs
There was extensive discussion about the externally operated
subordinate CAs that are active under current GlobalSign roots that
may be moved to this new root. There was also a request that the
identities of the externally operated sub-CAs be disclosed. It is
currently Mozilla policy that externally operated subordinate CAs that
are only used for internal purposes need not be disclosed. There was
concern raised that there is no meaningful distinction between
externally operated subordinate CAs that are used for internal
purposes vs. external purposes. There was also concern raised that
the current SubordinateCA_Checklist does not reflect the understanding
of the community regarding disclosure. These concerns were not
addressed.
ACTION: Require more disclosure.
2) Auditing of Externally Operated Subordinate CAs
Concern was raised that subordinate CAs may be practically and
effectively circumventing the audit requirement of Mozilla. In other
words, a CA which would not have been admitted to the NSS roots store,
could be trusted through another CA.
Johan's April 5 and April 6 emails do not address these concerns. All
he guaranteed was that "SubCA’s must follow the GlobalSign Certificate
Policy" (which does not speak to Sub-CA audits) and that "GS has the
right, but no obligation, to audit Customer representation of
TrustedRoot."
ACTION: Require more disclosure.
3) Orders from Governments
Questions were asked about GlobalSign's policy in respect to complying
with orders from governments.
Johann replied that GlobalSign could not comply with orders from any
Foreign Government to issue a SubordinateCA against processes due to
their Data Protection Policy (which does not appear to speak to the
matter), an EU Directive (which does not appear to speak to the
matter), and claimed choice of jurisdictional venue in Belgium and
Japan (which does not seem consistent with its operation of business
in China and the US).
ACTION: Require response.
There was also a significant amount of discussion about the current
practices and policy, and in particular the subordinate CA checklist.
The subordinate CA checklist is a practice, and it is therefore
reasonable to expect GlobalSign to comply with that practice. The
Problematic Practices document serves to highlight potentially
problematic practices that could stand in the way of approval, and
several community members identified practices that merit further
investigation.
My assessment is that the review process should be extended for at
least an additional week, and that it should not be closed until
GlobalSign addresses the outstanding issues raised in this thread. It
is also my opinion that this request should not be approved until the
Mozilla community reaches consensus on items #1 and #2, and GlobalSign
complies with the consensus.
Eddy Nigg
> On 3/31/10 12:03 PM, Kathleen Wilson wrote:> Here is a summary of the
> discussion so far.
>
> Kathleen,
>
> I have a fairly different impression of the discussion to date.
>
:-)
Thanks for your interpretation - and honestly I was a bit surprised
about Kathleen's summary.
Kathleen, I think you moved this one too fast forward...there were some
valid points raised which I believe are worth to be addressed properly.
Stephen Schultze
"Perhaps the policy should even go so far, as Kai has suggested, as to
require that whatever entity performs the verification of subject
identity for the CA must be audited."
I suggest that this is equally true for "internal" and "external" Sub-
CAs.
Eddy Nigg
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.
Here the description about what an external CA is, is very clear. Also the audit requirement has been there.
Just to make clear, the term "Internal" applies to intermediate CA certificates consumed and used by the CA itself. Obviously those CA certificates belong to the CA infrastructure and are not external and are audited.
Stephen Schultze
> Yes, it's nothing new
And to Eddy's credit, he's been raising this very issue for a long
time:
http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/2163ddbe4c104ea1
Let's deal with it properly.
Eddy Nigg
Incidentally exactly GlobalSign was mentioned by T-Systems. Just to
recall, T-Systems had to go back and revise their policies and auditing
requirements. And the thread is otherwise interesting too....
As such, you can probably go back even further in the archive and find
some more evidence regarding this requirement....
Stephen Schultze
> On 4/8/10 1:35 PM, Eddy Nigg wrote:
> > I must agree and I fail to see the difference. Further I'm not sure when
> > this was decided. Is this something which has been discussed and agreed
> > upon? Again, maybe I'm getting old and my memory is failing :-)
>
> Yes, but a long time ago, so I doubt I'll be able to find the source.
> It's been this way in the subordinate CA checklist since I created it in
> 2008. I created this checklist as a direct result of the discussions
> that were happening at that time, and we went through a few iterations
> of discussing and editing the checklist at that time.
That discussion doesn't appear to exist:
http://groups.google.com/group/mozilla.dev.security.policy/search?q=subordinate+checklist
http://groups.google.com/group/mozilla.dev.tech.crypto/search?q=subordinate+checklist
Michael Ströder
> On 04/09/2010 12:10 AM, Kathleen Wilson:
>> supposed to be limited either contractually or technically in regards
>> what their subCA can sign, and who they can issue certs to (employees,
>> internal systems, etc).
>
> Alright - generally speaking we used the term "internal" for any
> intermediate CA consumed by the CA itself, whereas "external" are those
> that are controlled and operated by sub CAs external to the CA. I'm
> fairly sure that this has always been (at least mine) interpretation.
Maybe my English is too bad. But that's not how I interpret it.
My interpretation:
1. "Internal sub-CA" is a CA issuing certs to an organization's "internal"
subscribers like e-mails certs for employees, server certs solely for DNS
names "owned" by this organization. In theory such an "internal sub-CA" has a
better chance to validate the subscriber's identity by organizational
information held in internal databases.
(In practice the processes "within" big organizations (100k+ employees) are
much more distributed than most people expect and the CA's validation
procedures are as blurry as for an "external sub-CA".)
2. "External sub-CA" is a CA issuing certs to any 3rd-party not strongly
affiliated to the CA's organization. All commonly known problems with
validatng the subscriber's identity apply.
>> The difference being that these subCAs are not selling or issuing
>> certs outside of their company.
>
> But they are relied upon everywhere. So what difference does it make?
I consider 1. and 2. to issue certs to be used by the whole Mozilla user base.
>> To my knowledge, Mozilla has never required a CA to publicly disclose
>> the names of this type of subCA.
>
> I'm not sure about that. But it's not MY major concern, rather that
> those are not audited. That, in addition to non-disclosure, really
> leaves a big black hole about we simply know nothing. We ought to change
> that.
I really wonder how the simple knowledge about auditing requirements in a
CP/CPS says anything about whether auditing happened at all...
Ciao, Michael.
Eddy Nigg
> My interpretation:
>
> 1. "Internal sub-CA" is a CA issuing certs to an organization's "internal"
> subscribers like e-mails certs for employees, server certs solely for DNS
> names "owned" by this organization. In theory such an "internal sub-CA" has a
> better chance to validate the subscriber's identity by organizational
> information held in internal databases.
> (In practice the processes "within" big organizations (100k+ employees) are
> much more distributed than most people expect and the CA's validation
> procedures are as blurry as for an "external sub-CA".)
>
> 2. "External sub-CA" is a CA issuing certs to any 3rd-party not strongly
> affiliated to the CA's organization. All commonly known problems with
> validatng the subscriber's identity apply.
>
Nononono....clearly from the CA perspective (but also the relying
parties), there are sub-ordinate CA certificates which are consumed by
the CA itself and those that are use by external (to the CA) third
parties. This is the only differentiation I've know that is relevant.
The validation procedures for external third entities may vary according
to the relevant CA policies of the CA, however those sub-ordinate CAs
are still external to the CA. And obviously those are treated
differently than the CA certificates used by the CA itself for their
end-user. Also in respect of the risk and REQUIRED validation procedures
there is no big difference for external CAs.
> I really wonder how the simple knowledge about auditing requirements in a
> CP/CPS says anything about whether auditing happened at all...
>
Well....simply if anything bad happens and the CP/CPS disclosed that all
sub-ordinate CAs must be part of the audit and/or audited by an auditor
independently and an audit was performed and confirmed, we can always
approach the auditor.
Eddy Nigg
> Also in respect of the risk and REQUIRED validation procedures there
> is no big difference for external CAs.
>
That should have rather been: ....there is no big difference between
external CAs.
Michael Ströder
Well, Kathleen should clarify what "internal" and "external" really means.
>> I really wonder how the simple knowledge about auditing requirements in a
>> CP/CPS says anything about whether auditing happened at all...
>
> Well....simply if anything bad happens and the CP/CPS disclosed that all
> sub-ordinate CAs must be part of the audit and/or audited by an auditor
> independently and an audit was performed and confirmed, we can always
> approach the auditor.
And I guess you know that it's hard to detect whether anything bad happened...
Ciao, Michael.
Eddy Nigg
> Well, Kathleen should clarify what "internal" and "external" really means.
>
No problem, however I'd like to see when and where this was defined (if
at all). Or maybe it was just a misunderstanding, after all there was a
huge amount of information to track back then. This can happen.
> And I guess you know that it's hard to detect whether anything bad happened...
>
You might be surprised, but bad practices surface every while :-)
Bernd Kirsig
Von: Bernd Kirsig
Gesendet: Freitag, 9. April 2010 15:58
An: 'dev-secur...@lists.mozilla.org'
Betreff: AW: dev-security-policy Digest, Vol 16, Issue 27
> Date: Fri, 09 Apr 2010 16:05:01 +0300
> From: Eddy Nigg <eddy...@startcom.org>
> To: dev-secur...@lists.mozilla.org
> Subject: Re: GlobalSign Root Inclusion Request
> Message-ID: <4BBF25FD...@startcom.org>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> On 04/09/2010 03:29 PM, Michael Str?der:
> > Well, Kathleen should clarify what "internal" and
> "external" really means.
> >
>
Hasn't that already been done in the CA:SubordinateCA checklist?
There is a diistinction between Subordinate CAs Operated by
Third Parties For Internal Use And Subordinate CAs Operated
by Third Parties For External Use.
Bernd
>
> --
> Regards
>
> Signer: Eddy Nigg, StartCom Ltd.
> XMPP: star...@startcom.org
> Blog: http://blog.startcom.org/
> Twitter: http://twitter.com/eddy_nigg
>
>
>
Bernd Kirsig Tel.: +49 (0)40 / 80 80 26-2 51
IT Security Fax.: +49 (0)40 / 80 80 26-1 26
TC TrustCenter GmbH
Sonninstraße 24-28 mailto: kir...@trustcenter.de
D-20097 Hamburg http://www.trustcenter.de
Geschaeftsfuehrung/Managing Directors: Dr. Sabine
Kockskaemper AG Hamburg, HRB 96168
Stephen Schultze
> > On 04/09/2010 03:29 PM, Michael Str?der:
> > > Well, Kathleen should clarify what "internal" and
> > "external" really means.
>
> Hasn't that already been done in the CA:SubordinateCA checklist?
>
> There is a diistinction between Subordinate CAs Operated by
> Third Parties For Internal Use And Subordinate CAs Operated
> by Third Parties For External Use.
CA:SubordinateCA_checklist conflicts somewhat with the
CA:Problematic_Practices#Allowing_external_entities_to_operate_subordinate_CAs,
as noted above. The latter page was updated most recently, and as
such is more likely to reflect current consensus. Nobody apparently
knows where the distinction on CA:SubordinateCA_checklist came from.
But even if you could make some definitional distinction, there is no
technical distinction between the Sub-CA certs issued to one or the
other. Their ability to subvert the trust model is the same.
Jean-Marc Desperrier
> 1) Disclosure of Externally Operated Subordinate CAs
>
> There was extensive discussion about the externally operated
> subordinate CAs that are active under current GlobalSign roots that
>
> ACTION: Require more disclosure.
Well, the problem is that they are many CAs with practice about
externally operated sub-CAs that are similar to GlobalSign.
I'm all for more disclosure about it, but it should be fair to
everybody, therefore applied to every CA.
And not just to GlobalSign as they happened to be the one CA with a new
root to get included just at the time the concern about that practice
rose higher.
Michael Ströder
> There is a difference between disclosing WHICH sub CAs exist and
> disclosure of the requirements and controls for sub CAs. Always read
> carefully :-)
But without knowing the existence of the sub CA you are not able to even ask
whether the requirements and controls for the sub CA are fulfilled.
Ciao, Michael.
David E. Ross
Knowing the existence is not the same as knowing the identity.
Yes, we should be informed of the existence. I'm not sure of the value
in knowing the identity, which is what started this lengthy discussion.
--
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
Eddy Nigg
> Knowing the existence is not the same as knowing the identity.
>
> Yes, we should be informed of the existence. I'm not sure of the value
> in knowing the identity, which is what started this lengthy discussion.
>
For what it's worth, it might perhaps reduce some surprises in the
future, however CAs are not obligated to notify Mozilla when issuing
more sub-ordinate CA certificates to external entities. Hence the
request for disclosure doesn't really provide a lot.
However I'm far more concerned about the circumvention of the audit
requirement by CAs. The problematic practice is the most relevant in
this context and this hasn't been dealt with. And therefore I'm a bit
surprised by Kathleen's assessment of the discussion. I suggest to
correct this.
Stephen Schultze
> > ACTION: Require more disclosure.
>
> Well, the problem is that they are many CAs with practice about
> externally operated sub-CAs that are similar to GlobalSign.
>
> I'm all for more disclosure about it, but it should be fair to
> everybody, therefore applied to every CA.
> And not just to GlobalSign as they happened to be the one CA with a new
> root to get included just at the time the concern about that practice
> rose higher.
Agreed, it should be applied to everyone. That's what I'm arguing...
that the existing practices in those documents be applied to
everyone. This particular request may be the first time we examine
the issue in depth, but someone has got to be first otherwise it
doesn't ever happen. Approval of new roots is the most convenient
time to do so, but there's nothing preventing a retroactive
application... or at least application each time we require updated
audit report documents (a practice that Kathleen says is now in
place).
On Apr 9, 2:10 pm, Eddy Nigg <eddy_n...@startcom.org> wrote:
> On 04/09/2010 08:46 PM, David E. Ross:
>
> > Knowing the existence is not the same as knowing the identity.
>
> > Yes, we should be informed of the existence. I'm not sure of the value
> > in knowing the identity, which is what started this lengthy discussion.
David, if that's your opinion can you reply to my argument for why it
is indeed important?
http://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/ecc83d8b64b17e1/25dfc9b8e7784146#e0f4b04a2565f3a5
> For what it's worth, it might perhaps reduce some surprises in the
> future, however CAs are not obligated to notify Mozilla when issuing
> more sub-ordinate CA certificates to external entities. Hence the
> request for disclosure doesn't really provide a lot.
It provides knowledge of all Sub-CAs at the time of disclosure, which
I think is a lot. It's certainly better than nothing, and if it's
followed up on at the time of periodic re-submission of audit
documents, then it is even better.
> However I'm far more concerned about the circumvention of the audit
> requirement by CAs. The problematic practice is the most relevant in
> this context and this hasn't been dealt with. And therefore I'm a bit
> surprised by Kathleen's assessment of the discussion. I suggest to
> correct this.
I think that the audit requirements and the identity disclosure are
both critical to the integrity trust model.
Michael Ströder
> On Apr 9, 11:10 am, Jean-Marc Desperrier <jmd...@gmail.com> wrote:
>> Stephen Schultze wrote:
>>> 1) Disclosure of Externally Operated Subordinate CAs [...]
>>> ACTION: Require more disclosure.
>>
>> Well, the problem is that they are many CAs with practice about
>> externally operated sub-CAs that are similar to GlobalSign.
>>
>> I'm all for more disclosure about it, but it should be fair to
>> everybody, therefore applied to every CA.
>> And not just to GlobalSign as they happened to be the one CA with a new
>> root to get included just at the time the concern about that practice
>> rose higher.
>
> Agreed, it should be applied to everyone. That's what I'm arguing...
> that the existing practices in those documents be applied to
> everyone.
+1
Ciao, Michael.
Kathleen Wilson
> On 3/31/10 12:03 PM, Kathleen Wilson wrote:> Here is a summary of the
> discussion so far.
>
> Kathleen,
>
> I have a fairly different impression of the discussion to date.
>
> 1) Disclosure of Externally Operated Subordinate CAs
>
> There was extensive discussion about the externally operated
> subordinate CAs that are active under current GlobalSign roots that
> may be moved to this new root. There was also a request that the
> identities of the externally operated sub-CAs be disclosed. It is
> currently Mozilla policy that externally operated subordinate CAs that
> are only used for internal purposes need not be disclosed. There was
> concern raised that there is no meaningful distinction between
> externally operated subordinate CAs that are used for internal
> purposes vs. external purposes. There was also concern raised that
> the current SubordinateCA_Checklist does not reflect the understanding
> of the community regarding disclosure. These concerns were not
> addressed.
>
> ACTION: Require more disclosure.
Please state clearly what additional information you think this CA needs
to disclose.
Note that Mozilla does not currently require CAs to publicly disclose
their list of "third-party private (or enterprise) subordinate CAs".
Changing this is a significant change in Mozilla's current practices,
and as such, the discussion belongs in a separate thread. Please
continue further discussion about this in the thread called "Terminology
and policy in relation to subordinate CAs".
The discussion about changing the the SubordinateCA_Checklist,also
belongs in a separate thread. Further discussion may continue in the
thread called "Terminology and policy in relation to subordinate CAs". I
plan to update the checklist to reflect Frank's recommended terminology,
and will post information about my changes in a separate thread.
>
> 2) Auditing of Externally Operated Subordinate CAs
>
> Concern was raised that subordinate CAs may be practically and
> effectively circumventing the audit requirement of Mozilla. In other
> words, a CA which would not have been admitted to the NSS roots store,
> could be trusted through another CA.
>
> Johan's April 5 and April 6 emails do not address these concerns. All
> he guaranteed was that "SubCA�s must follow the GlobalSign Certificate
> Policy" (which does not speak to Sub-CA audits) and that "GS has the
> right, but no obligation, to audit Customer representation of
> TrustedRoot."
>
> ACTION: Require more disclosure.
Please state clearly what additional information you think the CA should
disclose.
If you are proposing that the CA modify their CP/CPS/audit, please state
clearly what your proposal is.
>
> 3) Orders from Governments
>
> Questions were asked about GlobalSign's policy in respect to complying
> with orders from governments.
>
> Johann replied that GlobalSign could not comply with orders from any
> Foreign Government to issue a SubordinateCA against processes due to
> their Data Protection Policy (which does not appear to speak to the
> matter), an EU Directive (which does not appear to speak to the
> matter), and claimed choice of jurisdictional venue in Belgium and
> Japan (which does not seem consistent with its operation of business
> in China and the US).
>
> ACTION: Require response.
Please state clearly what additional information you would like the CA
to provide.
David E. Ross
>> Policy" (which does not speak to Sub-CA audits) and that "GS has the
>> right, but no obligation, to audit Customer representation of
>> TrustedRoot."
>>
>> ACTION: Require more disclosure.
>
> Please state clearly what additional information you think the CA should
> disclose.
>
> If you are proposing that the CA modify their CP/CPS/audit, please state
> clearly what your proposal is.
>
>>
>> 3) Orders from Governments
>>
>> Questions were asked about GlobalSign's policy in respect to complying
>> with orders from governments.
>>
>> Johann replied that GlobalSign could not comply with orders from any
>> Foreign Government to issue a SubordinateCA against processes due to
>> their Data Protection Policy (which does not appear to speak to the
>> matter), an EU Directive (which does not appear to speak to the
>> matter), and claimed choice of jurisdictional venue in Belgium and
>> Japan (which does not seem consistent with its operation of business
>> in China and the US).
>>
>> ACTION: Require response.
>
> Please state clearly what additional information you would like the CA
> to provide.
Referring to the thread "Terminology and policy in relation to
subordinate CAs" in this same newsgroup and my comment dated Sun, 18 Apr
2010 13:14:34 -0700:
If the GlobalSign root certificate under discussion is used for signing
intermediate certificates for a third-party private (enterprise)
subordinate CA -- for the internal use of a non-GlobalSign intranet --
this request should be denied. There is too much risk to end users if
the third-party discovers that it can use its intermediate certificate
as a profit center, signing certificates of other entities without the
knowledge or control of GlobalSign.
It appears that the undisclosed third-parties might indeed be private
subordinate CAs. Otherwise, why would they be subject to non-disclosure
agreements?
Stephen Schultze
> On 4/8/10 5:09 PM, Stephen Schultze wrote:
> > 1) Disclosure of Externally Operated Subordinate CAs
> > ACTION: Require more disclosure.
>
> Please state clearly what additional information you think this CA needs
> to disclose.
>
> Note that Mozilla does not currently require CAs to publicly disclose
> their list of "third-party private (or enterprise) subordinate CAs".
I have made the point in this thread and elsewhere that because there
is no technical distinction between the two, all certs fall into the
category of "third party public (or external) subordinate CAs. Others
have agreed with this. Until we have a satisfactory answer for why
they are in fact distinct (for example, some high level of legal
assurance that the contracts and jurisdiction prevent what is
otherwise technically possible in the case of "private" CA certs) I
don't think it is reasonable to maintain different standards.
> [...]
> Further discussion may continue in the
> thread called "Terminology and policy in relation to subordinate CAs".
That's fine, but as I noted in my initial summary, it is my opinion
that "this request should not be approved until the Mozilla community
reaches consensus on items #1 and #2, and GlobalSign complies with the
consensus." This includes consensus that you may consider a change in
current policy.
> > 2) Auditing of Externally Operated Subordinate CAs
>
> > Concern was raised that subordinate CAs may be practically and
> > effectively circumventing the audit requirement of Mozilla. In other
> > words, a CA which would not have been admitted to the NSS roots store,
> > could be trusted through another CA.
>
> > Johan's April 5 and April 6 emails do not address these concerns. All
> > he guaranteed was that "SubCA s must follow the GlobalSign Certificate
> > Policy" (which does not speak to Sub-CA audits) and that "GS has the
> > right, but no obligation, to audit Customer representation of
> > TrustedRoot."
>
> > ACTION: Require more disclosure.
>
> Please state clearly what additional information you think the CA should
> disclose.
What sections of the GlobalSign Certificate Policy specifically
address Sub-CA's (all of them, not just EV)?
What is the full text of all variations of Sub-CA contracts (with
sensitive information redacted, if necessary)?
What is the nature of audits performed by GlobalSign of its Sub-CAs,
and what generally is the practice about when/how these are performed?
And, given subsequent discussion in the other thread, in which we
reached consensus that all Sub-CAs must be audited in similar fashion
to root CAs, I would add the following:
ACTION: Require statement of valid Sub-CA audit requirements, and
disclosure of enforcement mechanisms.
> > 3) Orders from Governments
>
> > Questions were asked about GlobalSign's policy in respect to complying
> > with orders from governments.
>
> > Johann replied that GlobalSign could not comply with orders from any
> > Foreign Government to issue a SubordinateCA against processes due to
> > their Data Protection Policy (which does not appear to speak to the
> > matter), an EU Directive (which does not appear to speak to the
> > matter), and claimed choice of jurisdictional venue in Belgium and
> > Japan (which does not seem consistent with its operation of business
> > in China and the US).
>
> > ACTION: Require response.
>
> Please state clearly what additional information you would like the CA
> to provide.
To begin with, I want the CA to answer the questions raised in my
messages. That can be the beginning of a community discussion, but
the CA has not even responded on this issue.
Matt McCutchen
> That's fine, but as I noted in my initial summary, it is my opinion
> that "this request should not be approved until the Mozilla community
> reaches consensus on items #1 and #2, and GlobalSign complies with the
> consensus." This includes consensus that you may consider a change in
> current policy.
There's no "may consider". Requiring disclosure of private external
sub-CAs would be a change in current policy, period.
I'm not sure it's fair to block the GlobalSign request, out of all the
CA requests Mozilla processes, on adoption of a better policy.
Regardless, the work on fixing the policy should proceed as
expeditiously as possible.
--
Matt
Kurt Seifried
> sub-CAs would be a change in current policy, period.
>
> I'm not sure it's fair to block the GlobalSign request, out of all the
> CA requests Mozilla processes, on adoption of a better policy.
> Regardless, the work on fixing the policy should proceed as
> expeditiously as possible.
If there is even one root certificate for a CA that allows sub CA's
then the whole exercise of changing the standards is pointless as
anyone will simply be able to CA shop and go to GlobalSign rather then
a "new" CA that is required to disclose. Rendering the whole thing
just as bad as before.
-Kurt
Matt McCutchen
No, the idea is that we change the standards and then go back and apply
them to all CAs (ideally right away, but realistically on their next
audit cycle). What is pointless is picking on GlobalSign when there are
already many other CAs with the same problem.
--
Matt
Eddy Nigg
Errr...
https://wiki.mozilla.org/CA:Problematic_Practices#Issuing_SSL_Certificates_for_Internal_Domains
Matt McCutchen
> On 04/22/2010 12:47 AM, Matt McCutchen:
> > them to all CAs (ideally right away, but realistically on their next
> > audit cycle). What is pointless is picking on GlobalSign when there are
> > already many other CAs with the same problem.
> >
>
> Errr...
>
> https://wiki.mozilla.org/CA:Problematic_Practices#Allowing_external_entities_to_operate_subordinate_CAs
>
> https://wiki.mozilla.org/CA:Problematic_Practices#Delegation_of_Domain_.2F_Email_validation_to_third_parties
>
> https://wiki.mozilla.org/CA:Problematic_Practices#Issuing_SSL_Certificates_for_Internal_Domains
I was referring specifically to disclosure of the identities of the
external private CAs, which is not required by the current policy. I do
not think the request should be held up for that reason.
--
Matt
Eddy Nigg
>> Errr...
>>
>> https://wiki.mozilla.org/CA:Problematic_Practices#Allowing_external_entities_to_operate_subordinate_CAs
>>
>> https://wiki.mozilla.org/CA:Problematic_Practices#Delegation_of_Domain_.2F_Email_validation_to_third_parties
>>
>> https://wiki.mozilla.org/CA:Problematic_Practices#Issuing_SSL_Certificates_for_Internal_Domains
>>
> I was referring specifically to disclosure of the identities of the
> external private CAs, which is not required by the current policy. I do
> not think the request should be held up for that reason.
>
Ah right, I personally don't care about disclosure who they are, I care
about circumvention of the audit requirement applied to the complete CA
infrastructure. This includes sub or cross signed CAs.
Stephen Schultze
> On Mon, 2010-04-19 at 14:27 -0700, Stephen Schultze wrote:
> > That's fine, but as I noted in my initial summary, it is my opinion
> > that "this request should not be approved until the Mozilla community
> > reaches consensus on items #1 and #2, and GlobalSign complies with the
> > consensus." This includes consensus that you may consider a change in
> > current policy.
>
> There's no "may consider". Requiring disclosure of private external
> sub-CAs would be a change in current policy, period.
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"
Also, as I have noted, there is no technical distinction between
"private" and "public" CAs. That would also indicate that "private"
CAs should be subjected to the more stringent standard.
The final word on the policy is the policy statement itself, which
says:
"We reserve the right to not include a particular CA certificate in
our software products, to discontinue including a particular CA
certificate in our products, or to modify the "trust bits" for a
particular CA certificate included in our products, at any time and
for any reason. This includes (but is not limited to) cases where we
believe that including a CA certificate (or setting its "trust bits"
in a particular way) would cause undue risks to users' security"
If not disclosing Sub-CAs causes undue risks to users, regardless of
past approval practices, then it violates policy, period.
> I'm not sure it's fair to block the GlobalSign request, out of all the
> CA requests Mozilla processes, on adoption of a better policy.
> Regardless, the work on fixing the policy should proceed as
> expeditiously as possible.
Fairness is not the standard.
It's also not a matter of singling GlobalSign out. It is the current
application being considered as these issues are being more closely
scrutinized.
Matt McCutchen
> On Apr 21, 4:58 pm, Matt McCutchen <m...@mattmccutchen.net> wrote:
> > There's no "may consider". Requiring disclosure of private external
> > sub-CAs would be a change in current policy, period.
>
> 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"
Sorry, I was not precise. I meant the identities of the sub-CAs. The
policy requires disclosure of the existence of the sub-CAs and the
audit processes they undergo, but not their identities.
> Also, as I have noted, there is no technical distinction between
> "private" and "public" CAs. That would also indicate that "private"
> CAs should be subjected to the more stringent standard.
I agree that the current policy is inconsistent. It is still the
current policy.
> The final word on the policy is the policy statement itself, which
> says:
> "We reserve the right to not include a particular CA certificate in
> our software products, to discontinue including a particular CA
> certificate in our products, or to modify the "trust bits" for a
> particular CA certificate included in our products, at any time and
> for any reason. This includes (but is not limited to) cases where we
> believe that including a CA certificate (or setting its "trust bits"
> in a particular way) would cause undue risks to users' security"
>
> If not disclosing Sub-CAs causes undue risks to users, regardless of
> past approval practices, then it violates policy, period.
The Mozilla Foundation reserves that right, not you.
> > I'm not sure it's fair to block the GlobalSign request, out of all the
> > CA requests Mozilla processes, on adoption of a better policy.
> > Regardless, the work on fixing the policy should proceed as
> > expeditiously as possible.
>
> Fairness is not the standard.
>
> It's also not a matter of singling GlobalSign out. It is the current
> application being considered as these issues are being more closely
> scrutinized.
I didn't mean to suggest you chose GlobalSign for a reason other than
it being the current application. While one request may motivate an
improvement to policy, we should still make policy first and then
apply it.
--
Matt
Stephen Schultze
> On Wed, 2010-04-21 at 16:59 -0700, Stephen Schultze wrote:
> > On Apr 21, 4:58 pm, Matt McCutchen <m...@mattmccutchen.net> wrote:
> > > There's no "may consider". Requiring disclosure of private external
> > > sub-CAs would be a change in current policy, period.
>
> > "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"
>
> Sorry, I was not precise. I meant the identities of the sub-CAs. The
> policy requires disclosure of the existence of the sub-CAs and the
> audit processes they undergo, but not their identities.
Well, arguably that sentence requires disclosure of the identities...
at the very least it is a matter of interpretation, as evidenced by
discussion earlier in this thread:
http://groups.google.com/group/mozilla.dev.security.policy/msg/e0fef2e44a900410
And there is also ambiguity with respect to whether the Sub-CAs in
question are rightly defined as "external"/"public":
http://groups.google.com/group/mozilla.dev.security.policy/msg/4bd2d16da34dd3ac
Hence, I think my "may consider" is quite reasonable.
> > Also, as I have noted, there is no technical distinction between
> > "private" and "public" CAs. That would also indicate that "private"
> > CAs should be subjected to the more stringent standard.
>
> I agree that the current policy is inconsistent. It is still the
> current policy.
It's not necessarily that it is inconsistent, but that as written all
Sub-CAs should be subject to the "external" requirements. In that
case, the description of what policy applies to an "internal" Sub-CA
is irrelevant.
> > The final word on the policy is the policy statement itself, which
> > says:
> > "We reserve the right to not include a particular CA certificate in
> > our software products, to discontinue including a particular CA
> > certificate in our products, or to modify the "trust bits" for a
> > particular CA certificate included in our products, at any time and
> > for any reason. This includes (but is not limited to) cases where we
> > believe that including a CA certificate (or setting its "trust bits"
> > in a particular way) would cause undue risks to users' security"
>
> > If not disclosing Sub-CAs causes undue risks to users, regardless of
> > past approval practices, then it violates policy, period.
>
> The Mozilla Foundation reserves that right, not you.
Indeed, with the informed discussion of the community.
> > > I'm not sure it's fair to block the GlobalSign request, out of all the
> > > CA requests Mozilla processes, on adoption of a better policy.
> > > Regardless, the work on fixing the policy should proceed as
> > > expeditiously as possible.
>
> > Fairness is not the standard.
>
> > It's also not a matter of singling GlobalSign out. It is the current
> > application being considered as these issues are being more closely
> > scrutinized.
>
> I didn't mean to suggest you chose GlobalSign for a reason other than
> it being the current application. While one request may motivate an
> improvement to policy, we should still make policy first and then
> apply it.
As I noted, the policy is broad and permits for any number of concerns
about trust to be raised during the review process.
Matt McCutchen
wrote:
> On Apr 21, 9:24 pm, Matt McCutchen <m...@mattmccutchen.net> wrote:
>
> > On Wed, 2010-04-21 at 16:59 -0700, Stephen Schultze wrote:
> > > On Apr 21, 4:58 pm, Matt McCutchen <m...@mattmccutchen.net> wrote:
> > > > There's no "may consider". Requiring disclosure of private external
> > > > sub-CAs would be a change in current policy, period.
>
> > >https://wiki.mozilla.org/CA:Problematic_Practices#Allowing_external_e...
> > > "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"
>
> > Sorry, I was not precise. I meant the identities of the sub-CAs. The
> > policy requires disclosure of the existence of the sub-CAs and the
> > audit processes they undergo, but not their identities.
>
> Well, arguably that sentence requires disclosure of the identities...
> at the very least it is a matter of interpretation, as evidenced by
Frank Hecker already clarified the intent of that text:
https://groups.google.com/group/mozilla.dev.security.policy/msg/9697d2385a5884e8
=> So the bottom line is that as a matter of policy I don't think we
need
=> to or should be requiring CA organization to disclose the
identities of
=> their enterprise customers operating third-party private
subordinate
=> CAs. We traditionally have not done this, and I don't think either
the
=> subordinate CA checklist or the problematic practices document
were
=> intended to be read that way. In the subordinate CA checklist my
=> interpretation is that the section "Subordinate CAs Operated by
Third
=> Parties For Internal Use" covers what I'm calling third-party
private
=> subordinate CAs, and it requires only a "general description of
the
=> sub-CAs operated by third parties" and not actual disclosure of
the
=> third parties' identities.
So there is no point in arguing about it.
> > > Also, as I have noted, there is no technical distinction between
> > > "private" and "public" CAs. That would also indicate that "private"
> > > CAs should be subjected to the more stringent standard.
>
> > I agree that the current policy is inconsistent. It is still the
> > current policy.
>
> It's not necessarily that it is inconsistent, but that as written all
> Sub-CAs should be subject to the "external" requirements. In that
> case, the description of what policy applies to an "internal" Sub-CA
> is irrelevant.
What's your point? There is nothing in the current policy,
interpreted as intended, to suggest that the identities of external
private CAs must be disclosed.
> > > The final word on the policy is the policy statement itself, which
> > > says:
> > > "We reserve the right to not include a particular CA certificate in
> > > our software products, to discontinue including a particular CA
> > > certificate in our products, or to modify the "trust bits" for a
> > > particular CA certificate included in our products, at any time and
> > > for any reason. This includes (but is not limited to) cases where we
> > > believe that including a CA certificate (or setting its "trust bits"
> > > in a particular way) would cause undue risks to users' security"
>
> > > If not disclosing Sub-CAs causes undue risks to users, regardless of
> > > past approval practices, then it violates policy, period.
>
> > The Mozilla Foundation reserves that right, not you.
>
> Indeed, with the informed discussion of the community.
Where are you getting that? There is nothing to suggest that you can
compel the Mozilla Foundation to exercise that right in any particular
case.
> As I noted, the policy is broad and permits for any number of concerns
> about trust to be raised during the review process.
Raised, indeed, and dismissed at the discretion of the Mozilla
Foundation in view of the current policy.
If the other problems with the request are resolved (a big if), I
fully expect the approval to proceed over your objection. That's why
I would encourage you to focus on changing the policy instead.
--
Matt
Eddy Nigg
> Frank Hecker already clarified the intent of that text:
> https://groups.google.com/group/mozilla.dev.security.policy/msg/9697d2385a5884e8
>
>
Ohhom...that was part of the discussion. One is allowed to disagree with
Frank and myself has done some from time to time :-)
> Raised, indeed, and dismissed at the discretion of the Mozilla
> Foundation in view of the current policy.
>
The discussion is ongoing and there might be valid points raised here.
Your opinion is as valued as those of the other participants which
voiced theirs.
Stephen Schultze
> There is nothing in the current policy,
> interpreted as intended, to suggest that the identities of external
> private CAs must be disclosed.
I fear we are drifting into a debate over Mozilla Cert Policy
originalism theory. In any case, I suggest we take any further
discussion on this over to the sister thread:
http://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/9782ec0b32460edc
> Where are you getting that? There is nothing to suggest that you can
> compel the Mozilla Foundation to exercise that right in any particular
> case.
Huh? There's nothing to suggest that I suggested that (although I
don't even know what "right" you're referring to).
> Raised, indeed, and dismissed at the discretion of the Mozilla
> Foundation in view of the current policy.
Is that so?
Matt McCutchen
> On 04/22/2010 05:50 AM, Matt McCutchen:
> > Frank Hecker already clarified the intent of that text:
>
> > So there is no point in arguing about it.
>
> Ohhom...that was part of the discussion. One is allowed to disagree with
> Frank and myself has done some from time to time :-)
On questions of what the policy should say, sure. But I consider his
clarification of the intent of the current policy to be definitive,
since he is an official member of the CA review staff.
--
Matt
Matt McCutchen
wrote:
> On Apr 21, 10:50 pm, Matt McCutchen <m...@mattmccutchen.net> wrote:
>
> > There is nothing in the current policy,
> > interpreted as intended, to suggest that the identities of external
> > private CAs must be disclosed.
>
> I fear we are drifting into a debate over Mozilla Cert Policy
> originalism theory. In any case, I suggest we take any further
What is there to debate? You've seen Frank's clarification.
> > Where are you getting that? There is nothing to suggest that you can
> > compel the Mozilla Foundation to exercise that right in any particular
> > case.
>
> Huh? There's nothing to suggest that I suggested that (although I
> don't even know what "right" you're referring to).
The "right to not include a particular CA certificate in our software
products..." from the CA Policy. You quoted it to claim that
approving the request would violate the policy because it would cause
undue risks to users' security. But that is nonsense, since the text
only reserves a right that Mozilla can exercise as it wishes.
--
Matt
Eddy Nigg
> On questions of what the policy should say, sure. But I consider his
> clarification of the intent of the current policy to be definitive,
> since he is an official member of the CA review staff.
>
Nothing is definitive, just provide the right arguments in case you can.
Neither the policy existed at some point nor the problematic practices,
not even a clear inclusion process as we have it today. So it's clearly
a work in progress.
If a concern is raised with the right arguments it may impact inclusion,
approval, change of policy etc. Just for your knowledge ;-)
Johan Sys
support this root-inclusion request and we have been implementing
Mozilla's (and previous NS) policies the last 12 years.
Kathleen, Stephen, thanks for pointing to the specific action items.
To answer:
1. Disclosure : as per the discussions (and the terminology) this
doesn't seems baked yet as a policy. Could this be discussed in the
relevant thread please ?
2. Auditing of External operated Subordinate CAs : we are modifying
our CP to explicitly state the check and balances we have on our
SubCA's. This will include the requirements, nature of the audits,
frequency and enforcement mechanism.
3. Orders from the Government : we are adding a clear statement to the
CPS about our implicit position against compelled attacks by third
parties (not only governments) - that we will take legal action in
that case (thanks Matt for the suggestion). Stephen, I hope that that
answers your specific question ?
The CP and CPS updates should be out in a couple of weeks (we have to
go through a process to get them approved by the different internal
boards). Kathleen, could we freeze this root inclusion request until
publication ?
Thanks, Johan
On Apr 20, 6:27 am, Stephen Schultze <sjschultze.use...@gmail.com>
wrote:
Stephen Schultze
> GlobalSign is committed to address any specific questions/comments to
> support this root-inclusion request and we have been implementing
> Mozilla's (and previous NS) policies the last 12 years.
Great, I look forward to your updated CP and CPS and I imagine that
we'll all have a better idea of whether that clears up the questions
once they are updated and shared.
On the government compelled CA/cert issue, I doubt that it would be
satisfactory to just add something like "Globalsign intends to use all
reasonable legal defenses to avoid being compelled by a government
body or other party to issue certificates in violation of this CPS."
This doesn't get to the heart of my point, which is that when you are
subject to the laws of a given jurisdiction, and the government in
that jurisdiction has the ability to compel anything it wishes without
meaningful court oversight or legal defense, the trust model breaks
down. I would hope that whatever explanation you provide would
explain how you hope to address this, given that you appear to be
subject to Chinese law. A clarification of what constitutes
"reasonable" in such a jurisdiction would also be necessary.
Jean-Marc's clarifying questions in the other thread are helpful in
illustrating why such a sweeping general statement is insufficient.
johan sys
We can state our policy and that policy is audited with a public seal
attached to it. GlobalSign CA is subject to Belgian law which as legislation
and countries go is pretty neutral. If a third party, government or
otherwise, compels us to break the policy, we will address it with what we
can which is legal action (or do you want CA's to arm their employees for a
revolution ?). If this doesn't work, we will address it.
Stephen, you focus on china because of recent events If Mozilla policy or
US export (which we follow) forbids CA's to have a sales presence in china
and/or issue certificates there - Globalsign will evaluate that scenario, as
would most of the other CA's. But it should be a policy. And I would
argue that at that time other scenario's should also discussed : the
Patriot act in the US, anti-terror act in Israel, etc. All have secrecy
clauses which could lead to the (at the moment theoretical) scenario you
described. CA's can legally fight this, and if necessary draw their
conclusions or lose their accreditation and credibility. I believe this
is what GlobalSign expresses in the CPS - what else is required ?
Johan
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
sjschultze
> What do you want the CA's todo ? Seriously ?
Decide whether operations in given jurisdictions threatens the
trustworthiness of your CA. If there are threats that are unique to
given jurisdictions but you still wish to operate there, account for
those threats in such a way that reassures your relying parties.
> We can state our policy and that policy is audited with a public seal
> attached to it. GlobalSign CA is subject to Belgian law which as legislation
> and countries go is pretty neutral. If a third party, government or
> otherwise, compels us to break the policy, we will address it with what we
> can which is legal action (or do you want CA's to arm their employees for a
> revolution ?). If this doesn't work, we will address it.
I don't believe that GlobalSign China Co.,Ltd. is subject to Belgian
law. The legal action you could take under Chinese law seems
dubious. I believe the choices you would have are precisely those I
outlined here:
http://groups.google.com/group/mozilla.dev.security.policy/msg/30d9fa47fe17cfb1
Your relying parties deserve to know what choice you would make.
> Stephen, you focus on china because of recent events If Mozilla policy or
> US export (which we follow) forbids CA's to have a sales presence in china
> and/or issue certificates there - Globalsign will evaluate that scenario, as
> would most of the other CA's. But it should be a policy. And I would
> argue that at that time other scenario's should also discussed : the
> Patriot act in the US, anti-terror act in Israel, etc. All have secrecy
> clauses which could lead to the (at the moment theoretical) scenario you
> described. CA's can legally fight this, and if necessary draw their
> conclusions or lose their accreditation and credibility. I believe this
> is what GlobalSign expresses in the CPS - what else is required ?
I focus on China because it is one of the jurisdictions in which you
operate (one which, incidentally, was not documented in your
application materials). I also focus on it because of its unique
threats -- documented government willingness to compel internet
companies to disclose user data, wiretap, and the like without
meaningful judicial oversight.
You are correct that the standard should apply to all jurisdictions.
I follow such events in the US. The NSA warrantless wiretapping issue
is very real, but fortunately in this jurisdiction we have had
judicial oversight of that type of conduct (even if you don't agree
with the outcomes):
http://www.eff.org/issues/nsa-spying
That is not to say that similar concerns in the US or elsewhere
shouldn't be considered.
Kathleen Wilson
> On 3/31/10 12:03 PM, Kathleen Wilson wrote:
>> worldwide) has applied to add the “GlobalSign Root CA - R3” root
>> certificate, and to enable all three trust bits. The request is to also
>> enable EV.
>>
>> The request is documented in the following bug:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=507360
>
Thank you to all of you who have reviewed this request and added your
comments and feedback to this discussion. Your contributions are
greatly appreciated.
This discussion is in regards to the request from GlobalSign to add the
“GlobalSign Root CA - R3” root certificate, and to enable all three
trust bits. The request is to also enable EV.
Here is a summary of the discussion.
1) Disclosure of Externally Operated Subordinate CAs
There continues to be extensive discussion about the disclosure of
externally operated subordinate CAs. I encourage this discussion to
continue in the other related threads. Mozilla is seriously considering
the arguments that have been presented in the discussions, and may
decide to make some changes to the practices or policy in the future. I
plan to add clarifications to the wiki pages in regards to terminology
for our current practices in regards to externally operated subordinate
CAs.
Mozilla has decided not to require GlobalSign to publicly disclose the
names of their third-party private (or enterprise) subordinate CAs that
they plan to migrate from their existing root to this new root at this time.
ACTION: None
2) Auditing of Externally Operated Subordinate CAs
GlobalSign has stated that they will update their CP to more clearly
explain the checks and balances that they have on their SubCAs. This
will include the requirements, nature of the audits, frequency and
enforcement mechanism.
ACTION: GlobalSign to post links to the updated CP/CPS in the bug,
indicating how the CP/CPS have been modified to more clearly explain the
checks and balances that are in place for their subCAs.
3) Orders from Governments
GlobalSign has stated that they will update their policy about orders
from other organizations/governments. Current recommendation from the
discussions appears to be to provide information about which regulatory
and legal framework/jurisdiction GlobalSign is primarily beholden to;
and that the CA will duly verify that an order from a government or
other such organization is lawful before executing the order.
ACTION: GlobalSign to post links to the updated CP/CPS in the bug,
indicating how the CP/CPS have been modified to address concerns about
being compelled by third parties to inappropriately issue an
intermediate or end-entity certificate.
I will post a summary of the action items in the bug.
https://bugzilla.mozilla.org/show_bug.cgi?id=507360
After GlobalSign updates the bug with links to their modified policy
documentation, I will start a second round of discussion.
I am now closing this discussion. Any further follow-up on this request
from GlobalSign should be added directly to the bug. All other
discussion about practices and policies should continue in the relevant
discussion threads, or a new discussion may be started.
Thanks,
Kathleen
Stephen Schultze
different policy on disclosure of externally operated private/
enterprise Sub-CAs, but I appreciate your attentiveness to the
community discussion and I respect Mozilla's decision on this
inclusion request. I look forward to continuing to discuss this issue
on the other threads, and to the possibility that the policy can be
updated and clarified.