GlobalSign Root Inclusion Request Round 2
Kathleen Wilson
resulted in two action items, which GlobalSign has completed.
Here is a summary of the previous discussion and the resulting action items.
Please refer to the first discussion for details.
First discussion topic: "GlobalSign Root Inclusion Request"
Discussion started: 3/31/10
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
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
Below are the action items that were identified in the first round of
discussion, and the resulting actions that GlobalSign has taken.
ACTION GlobalSign: Update GlobalSign's CP/CPS to more clearly explain
the checks and balances that are in place for SubCAs. This should
include the requirements, nature of the audits, frequency and
enforcement mechanism. GlobalSign to post links to the updated CP/CPS
in this bug, indicating how the CP/CPS have been modified to more
clearly explain the checks and balances that are in place for their subCAs.
RESULT: GlobalSign has updated their Certificate Policy, and attached
the updated document to the bug:
CP v3.5: https://bugzilla.mozilla.org/attachment.cgi?id=448344
The changes are in section 10 and other small udpates across the document.
ACTION GlobalSign: Update GlobalSign's CP/CPS to address concerns about
being compelled by third parties to inappropriately issue an
intermediate or end-entity certificate. Post the links to the updated
CP/CPS in this bug. Current recommendation from the discussions appears
to be to provide information about which regulatory and legal
framework/jurisdiction GlobalSign is primarily beholden to; and add a
statement that GlobalSign will duly verify that an order from a
government or other such organization is lawful before executing the order.
RESULT: GlobalSign has updated their CP and CPS, and attached the
updated documents to the bug.
CP v3.5: https://bugzilla.mozilla.org/attachment.cgi?id=448344
CPS v6.7: https://bugzilla.mozilla.org/attachment.cgi?id=448343
See section 11.16 of the CP, and section 9.16 of the CPS.
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.
Thanks,
Kathleen
Kathleen Wilson
> The first round of discussion for GlobalSign's root inclusion request
> resulted in two action items, which GlobalSign has completed.
>
> Here is a summary of the previous discussion and the resulting action
> items.
>
> Please refer to the first discussion for details.
> First discussion topic: "GlobalSign Root Inclusion Request"
> Discussion started: 3/31/10
>
> GlobalSign (a commercial CA based in the U.S. and serving customers
> 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
>
>
> * This is a SHA256 version of the GlobalSign SHA1 root that is already
> included in NSS.
> 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
>
>
> Below are the action items that were identified in the first round of
> discussion, and the resulting actions that GlobalSign has taken.
>
Is this discussion quiet because the action items have been
satisfactorily completed?
Shall I move forward with proposing that this request be approved?
Kathleen
Steve Schultze
> Is this discussion quiet because the action items have been
> satisfactorily completed?
>
> Shall I move forward with proposing that this request be approved?
Sadly, no. I'm working on a reply.
Eddy Nigg
>
> Is this discussion quiet because the action items have been
> satisfactorily completed?
>
> Shall I move forward with proposing that this request be approved?
Sorry, I had no time so far. I'm interested to read Steve's reply though.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Steve Schultze
questions about GlobalSign China Co.,Ltd. as an example of an entity
which is not clearly described in the CP/CPS. I also give a one-line
summary response to each of the action items.
I'm sorry this took so long. It took awhile to review the new documents.
=== CP 3.5 ===
> 2.1 Overview:
> GlobalSign TrustedRoot subscribers have their own Certificate
Practice Statement, which is based on, or equivalent to, the TrustedRoot
Template CPS available on http://www.globalsign.com/repository.
No such document appears to exist.
> 2.1.1 GlobalSign TrustedRoot
> Are issued to CAs only. [v3.4] -> Are issued only to Enterprise
inhouse CA’s to issue client and server SSL and/or S/MIME certificates
for use under its own brand towards their target audience. [v3.5]
>
> 2.3.3 Subscribers
> "Subscribers of GlobalSign TrustedRoot [...] are parties that: [...]
Can only be Enterprise in-house PKI’s. No public PKI services are allowed."
It is nice to see an attempt to narrow the allowed usage of TrustedRoot
certificates, but "Enterprise" and "inhouse" are not defined in the
document except perhaps:
> 10.1 CA Chaining Agreement
> Use of TrustedRoot by Subscriber’s enterprise and subsidiaries (50+%
controlling interest) only.
However, this definition of "enterprise" is not sufficiently narrow to
meet the description of "Third-party private (or enterprise) subordinate
CAs" in the SubordinateCA checklist document:
https://wiki.mozilla.org/CA:SubordinateCA_checklist
Incidentally, section 10.1 now allows revocation of chained CAs if the
following is breached:
> Acceptance of Subscriber that GlobalSign might publish Subscriber CA
in a GlobalSign repository.
I'd be curious to know whether GlobalSign intends to establish this
publishing system for all new TrustedRoot subscribers.
> 2.3.2 GlobalSign Registration Authorities
> An RA requests the issuance and revocation of a certificate under
this CP.
> [...] A GlobalSign RA: - Accepts, evaluates, approves or rejects the
registration of certificate applications.
What are some examples of GlobalSign RAs? Am I correct in understanding
that none of these entities necessarily undergoes a WebTrust audit, and
that they may be located in jurisdictions other than Belgium or Japan?
> The GlobalSign RA acts locally on approval and authorisation by the
GlobalSign CA. The GlobalSign RA acts in accordance with the approved
practices and procedures of the GlobalSign CA including this CP and
documented GlobalSign RA procedures."
What are the documented GlobalSign RA procedures other than the CP and CPS?
> 11.16 Compelled Attacks (CPS section 9.16)
> GlobalSign CA is subject to Belgium jurisdiction and regulatory
framework. GlobalSign’s CA infrastructure is based in Belgium, and RA
infrastructure is based in Belgium and Japan. GlobalSign’s sales offices
and/or strategic partners have no access to any part of GlobalSign’s CA
infrastructure. GlobalSign will use all reasonable legal defense against
being compelled by a third party to issue certificates in violation of
the CPS.
I believe that the relevant jurisdiction is where the entities with the
ability to approve certificates operate. Even if GlobalSign Inc (or is
it Globalsign NV?) is based in Brussels, there is still a compelled
creation threat if that legal entity has effectively delegated control
to entities in other jurisdictions (either via a SubCA or RA).
======
=== CPS ===
From CPS v6.5:
> 1.15.1.2 Roles of GlobalSign
> GlobalSign operates an international network of Trusted Third Parties
(TTP‟s) sharing the GlobalSign procedures and using suitable brand name
to issue high quality and highly trusted digital certificates to public
and private entities. Such partners include GlobalSign accredited
Certification Authorities and RAs that operate under an agreement with
GlobalSign. This role is typically limited to the issuance of
certificates to other certification authorities, which seek to inherit
trust that is usually vested in the GlobalSign CA root and brand name.
Why was this removed in version v6.7?
> 4.8.1:
> GlobalSign will revoke a certificate it has issued upon the
occurrence of any of the following events:
> GlobalSign has been compelled through illegal means by Subscriber or
third parties to issue the certificate;
Illegal under which jurisdiction? How would GlobalSign know if this
occurred?
> 8.1.1.1 Business Partnerships
> [...] GlobalSign may co-operate with appropriately selected business
partners to deliver certain services associated with PKI, including
certification and registration. GlobalSign may outsource in part or
whole certain aspects of the delivery of its
services. Regardless of the partner or agent selected to manage certain
parts of the certificate life cycle or operations, GlobalSign remains
ultimately in charge of the whole process.
If certification is delegated to third-parties, is GlobalSign really in
charge?
> GlobalSign will ensure that compliance audits are also applied to
such outsourced services. GlobalSign limits its responsibility thereof
according to the conditions in this CPS and the GlobalSign CP.
What is the nature of such audits?
> 9.14 Governing Law
> This CPS is governed, construed and interpreted in accordance with
the laws of Belgium. This choice of law is made to ensure uniform
interpretation of this CPS, regardless of the place of residence or
place of use of GlobalSign digital certificates or other products and
services and regardless of the venue, country and legal > entity
offering and selling the GlobalSign certificates. [...] Each party,
including GlobalSign partners, subscribers and relying parties,
irrevocably submit to the jurisdiction of the district courts of Leuven,
Belgium.
My jurisdiction comment from above applies here as well. To the extent
that such a clause were enforceable in that jurisdiction, the
hypothetical compelling entity would not necessarily be a partner,
subscriber, or relying party.
======
=== GlobalSign China Co.,Ltd. ===
Can you explain whether GlobalSign China Co.,Ltd. is a unit of
"Globalsign CA" as identified by the CP/CPS, or if it is something else?
Johan noted earlier:
> 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.
Is this not marketing SubCAs to Chinese customers?
http://cn.globalsign.com/pki/pkiPKI/
Is this the same thing for RAs?
http://cn.globalsign.com/pki/pkiRA/
======
> On 6/16/10 4:33 PM, Kathleen Wilson wrote:
> ACTION GlobalSign: Update GlobalSign's CP/CPS to more clearly explain
the checks and balances that are in place for SubCAs. This should
include the requirements, nature of the audits, frequency and
enforcement mechanism. GlobalSign to post links to the updated CP/CPS in
this bug, indicating how the CP/CPS have been modified to more clearly
explain the checks and balances that are in place for their subCAs.
>
> RESULT: GlobalSign has updated their Certificate Policy, and attached
the updated document to the bug: CP v3.5:
https://bugzilla.mozilla.org/attachment.cgi?id=448344 The changes are in
section 10 and other small udpates across the document.
It does not appear that the new CP/CPS provide any more detail on the
"nature of the audits, frequency and enforcement mechanism." It also
appears that RAs in diverse jurisdictions may possess enough authority
to issue certificates without day-to-day supervision of GlobalSign
(although GlobalSign clearly retains revocation capabilities). It seems
that more disclosure of RA practices might be a good idea.
> ACTION GlobalSign: Update GlobalSign's CP/CPS to address concerns
about being compelled by third parties to inappropriately issue an
intermediate or end-entity certificate. Post the links to the updated
CP/CPS in this bug. Current recommendation from the discussions appears
to be to provide information about which regulatory and legal
framework/jurisdiction GlobalSign is primarily beholden to; and add a
statement that GlobalSign will duly verify that an order from a
government or other such organization is lawful before executing the order.
>
> RESULT: GlobalSign has updated their CP and CPS, and attached the
updated documents to the bug. CP v3.5:
https://bugzilla.mozilla.org/attachment.cgi?id=448344 CPS v6.7:
https://bugzilla.mozilla.org/attachment.cgi?id=448343 See section 11.16
of the CP, and section 9.16 of the CPS.
The CP/CPS reinforce Globalsign's claim that the only controlling law is
that of Belgium or Japan, but this argument seems unlikely to prevail in
the case where SubCAs or RAs operate in a different jurisdiction.
Johan Sys
All the best, Johan
=== CP 3.5 ===
> 2.1 Overview:
> GlobalSign TrustedRoot subscribers have their own Certificate
Practice Statement, which is based on, or equivalent to, the
TrustedRoot Template CPS available on http://www.globalsign.com/repository.
No such document appears to exist.
Answer GS : Apologies : http://www.globalsign.com/repository/TrustedRoot%20Template%20CPS.pdf
has the template cps.
> 2.1.1 GlobalSign TrustedRoot
> Are issued to CAs only. [v3.4] -> Are issued only to Enterprise
inhouse CA's to issue client and server SSL and/or S/MIME certificates
for use under its own brand towards their target audience. [v3.5] >
> 2.3.3 Subscribers > "Subscribers of GlobalSign TrustedRoot [...]
are parties that: [...] Can only be Enterprise in-house PKI's. No
public PKI services are allowed."
It is nice to see an attempt to narrow the allowed usage of
TrustedRoot certificates, but "Enterprise" and "inhouse" are not
defined in the document except perhaps:
> 10.1 CA Chaining Agreement
> Use of TrustedRoot by Subscriber's enterprise and subsidiaries (50+
% controlling interest) only.
However, this definition of "enterprise" is not sufficiently narrow to
meet the description of "Third-party private (or enterprise)
subordinate CAs" in the SubordinateCA checklist document:
https://wiki.mozilla.org/CA:SubordinateCA_checklist
Answer GS : The Subsidiaries clause is the difference between the
Mozilla definition and ours. This is purely for practical reasons:
bigger companies have an overall IT infrastructure across their
different legal entities. Can I ask Mozilla board to make a judgment
on acceptability please ?
Incidentally, section 10.1 now allows revocation of chained CAs if the
following is breached:
> Acceptance of Subscriber that GlobalSign might publish Subscriber
CA in a GlobalSign repository.
I'd be curious to know whether GlobalSign intends to establish this
publishing system for all new TrustedRoot subscribers.
Answer GS : We leave this option open. I believe that required
disclosure is not mandatory at this time.
> 2.3.2 GlobalSign Registration Authorities > An RA requests the
issuance and revocation of a certificate under this CP.
> [...] A GlobalSign RA: - Accepts, evaluates, approves or rejects
the registration of certificate applications.
What are some examples of GlobalSign RAs? Am I correct in
understanding that none of these entities necessarily undergoes a
WebTrust audit, and that they may be located in jurisdictions other
than Belgium or Japan?
Answer GS : GlobalSign has obviously its own RA's operated by people
employed by GS and audited by Webtrust. We have corporate RA's :
employees within an enterprise can issue certificates towards their
own audience : this is for client certificates only and the
certificate profile is constrained and vetted by us (no certificates
outside a fixed profile which includes company O information and
country can be issued).
We have two public RA's, both in Europe, where partners do vetting
tasks for us. The contract specifies Belgium law. These
organizations are not included in WebTrust audits. WebTrust auditors
have verified that the resulting certificates were correctly validated
to GlobalSign's procedures/documents. GlobalSign is in negotiation
with the WebTrust auditors to take advantage of the additional work
that is carried out on these external RAs as currently the industry
standard is to make an exception for external RAs. i.e. All WebTrust
assertions state "Our examination did not extend to the controls of
the external registration authorities" which has been a standard
sentence from the first days of PKI. https://cert.webtrust.org/baltimore.html
. GlobalSign is working directly with the CICA to ensure that the
forthcoming amendments to the "Trust Services Principles and Criteria
for Certification Authorities" has sufficient provisions to force
external RAs to be included rather than excluded by default.
> The GlobalSign RA acts locally on approval and authorisation by the
GlobalSign CA. The GlobalSign RA acts in accordance with the approved
practices and procedures of the GlobalSign CA including this CP and
documented GlobalSign RA procedures."
What are the documented GlobalSign RA procedures other than the CP and
CPS?
Answer GS: We have a full body of processes, documentation, training
etc. This is what Webtrust for CA principle 2 audits.
> 11.16 Compelled Attacks (CPS section 9.16) > GlobalSign CA is
subject to Belgium jurisdiction and regulatory framework. GlobalSign's
CA infrastructure is based in Belgium, and RA infrastructure is based
in Belgium and Japan. GlobalSign's sales offices and/or strategic
partners have no access to any part of GlobalSign's CA infrastructure.
GlobalSign will use all reasonable legal defence against being
compelled by a third party to issue certificates in violation of the
CPS.
I believe that the relevant jurisdiction is where the entities with
the ability to approve certificates operate. Even if GlobalSign Inc
(or is it Globalsign NV?) is based in Brussels, there is still a
compelled creation threat if that legal entity has effectively
delegated control to entities in other jurisdictions (either via a
SubCA or RA).
Answer GS : the CA and RA infrastructure operate under these
jurisdiction. Another jurisdiction can try todo a compelled attack,
but these will be logged and blocked. Eg if a foreign government
tries to compel us to issue a SubCA (as per original premise), the
SubCA creation (offline ceremony) cannot be performed on that foreign
government soil as our private key material is not present there.
======
=== CPS ===
From CPS v6.5:
> 1.15.1.2 Roles of GlobalSign
> GlobalSign operates an international network of Trusted Third
Parties
(TTP"s) sharing the GlobalSign procedures and using suitable brand
name to issue high quality and highly trusted digital certificates to
public and private entities. Such partners include GlobalSign
accredited Certification Authorities and RAs that operate under an
agreement with GlobalSign. This role is typically limited to the
issuance of certificates to other certification authorities, which
seek to inherit trust that is usually vested in the GlobalSign CA root
and brand name.
Why was this removed in version v6.7?
Answer GS: Because this has not been our practice anymore since 2002.
> 4.8.1:
> GlobalSign will revoke a certificate it has issued upon the
occurrence of any of the following events:
> GlobalSign has been compelled through illegal means by Subscriber
or third parties to issue the certificate;
Illegal under which jurisdiction? How would GlobalSign know if this
occurred?
Answer GS: We are running in circles I believe : as specified illegal
under GlobalSign CA jurisdiction eg Belgium. All actions on the CA
are logged and audited which notifies us of a party trying a compelled
attack.
> 8.1.1.1 Business Partnerships
> [...] GlobalSign may co-operate with appropriately selected
business partners to deliver certain services associated with PKI,
including certification and registration. GlobalSign may outsource in
part or whole certain aspects of the delivery of its services.
Regardless of the partner or agent selected to manage certain parts of
the certificate life cycle or operations, GlobalSign remains
ultimately in charge of the whole process.
If certification is delegated to third-parties, is GlobalSign really
in charge?
Answer GS : We use for example D&T for certification (Webtrust does
not allow self-certification).
> GlobalSign will ensure that compliance audits are also applied to
such outsourced services. GlobalSign limits its responsibility thereof
according to the conditions in this CPS and the GlobalSign CP.
What is the nature of such audits?
Answer GS : Webtrust for CA includes these services in its compliance
audits.
> 9.14 Governing Law
> This CPS is governed, construed and interpreted in accordance with
the laws of Belgium. This choice of law is made to ensure uniform
interpretation of this CPS, regardless of the place of residence or
place of use of GlobalSign digital certificates or other products and
services and regardless of the venue, country and legal > entity
offering and selling the GlobalSign certificates. [...] Each party,
including GlobalSign partners, subscribers and relying parties,
irrevocably submit to the jurisdiction of the district courts of
Leuven, Belgium.
My jurisdiction comment from above applies here as well. To the
extent that such a clause were enforceable in that jurisdiction, the
hypothetical compelling entity would not necessarily be a partner,
subscriber, or relying party.
Answer GS: I believe this is answered above.
======
=== GlobalSign China Co.,Ltd. ===
Can you explain whether GlobalSign China Co.,Ltd. is a unit of
"Globalsign CA" as identified by the CP/CPS, or if it is something
else?
Answer GS : I am not sure what the question is here ? GlobalSign has
a sales office in China which is majority (90%+) owned by us .
Certificiates we issue are under the GlobalSign CA and subject to the
CPS/CP. A lot of companies have offices in China. We have not issued
subca's to chinese partners.
Johan noted earlier:
> 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 .
Is this not marketing SubCAs to Chinese customers?
http://cn.globalsign.com/pki/pkiPKI/
Is this the same thing for RAs?
http://cn.globalsign.com/pki/pkiRA/
Answer GS: this is marketing to Chinese speaking customers incl
Singapore and Hongkong. We only sell certificates and services if the
procedures can be implemented.
Steve Schultze
>>> 2.1.1 GlobalSign TrustedRoot
>>> Are issued to CAs only. [v3.4] -> Are issued only to Enterprise
>>> inhouse CA's to issue client and server SSL and/or S/MIME certificates >
>>> for use under its own brand towards their target audience. [v3.5]
>>>
>>> 2.3.3 Subscribers
>>> "Subscribers of GlobalSign TrustedRoot [...]
>>> are parties that: [...] Can only be Enterprise in-house PKI's. No
>>> public PKI services are allowed."
>>
>> It is nice to see an attempt to narrow the allowed usage of
>> TrustedRoot certificates, but "Enterprise" and "inhouse" are not
>> defined in the document except perhaps:
>>
>>> 10.1 CA Chaining Agreement
>>> Use of TrustedRoot by Subscriber's enterprise and subsidiaries (50+
>>> % controlling interest) only.
>>
>> However, this definition of "enterprise" is not sufficiently narrow to
>> meet the description of "Third-party private (or enterprise)
>> subordinate CAs" in the SubordinateCA checklist document:
>> https://wiki.mozilla.org/CA:SubordinateCA_checklist
>
> Answer GS : The Subsidiaries clause is the difference between the
> Mozilla definition and ours. This is purely for practical reasons:
> bigger companies have an overall IT infrastructure across their
> different legal entities. Can I ask Mozilla board to make a judgment
> on acceptability please ?
The difference I was referring to was that "enterprise" in the checklist
explicitly describes that users from the public internet should not
encounter the certs. Specifically:
"internal purposes, e.g., to issue SSL server certificates to systems
running intranet applications, to issue individual SSL client
certificates for employees or contractors for use in authenticating to
such applications, and so on."
This is different from "for use under its own brand towards their target
audience," because that definition could include public use (eg:
subdomain1.facebook.com).
> We have corporate RA's :
> employees within an enterprise can issue certificates towards their
> own audience : this is for client certificates only and the
> certificate profile is constrained and vetted by us (no certificates
> outside a fixed profile which includes company O information and
> country can be issued).
> We have two public RA's, both in Europe, where partners do vetting
> tasks for us. The contract specifies Belgium law. These
> organizations are not included in WebTrust audits. WebTrust auditors
> have verified that the resulting certificates were correctly validated
> to GlobalSign's procedures/documents. GlobalSign is in negotiation
> with the WebTrust auditors to take advantage of the additional work
> that is carried out on these external RAs as currently the industry
> standard is to make an exception for external RAs. i.e. All WebTrust
> assertions state "Our examination did not extend to the controls of
> the external registration authorities" which has been a standard
> sentence from the first days of PKI. https://cert.webtrust.org/baltimore.html
> . GlobalSign is working directly with the CICA to ensure that the
> forthcoming amendments to the "Trust Services Principles and Criteria
> for Certification Authorities" has sufficient provisions to force
> external RAs to be included rather than excluded by default.
I certainly agree that this is a good idea, and I don't understand why
Mozilla isn't already demanding this in light of the Comodo RA fiasco.
>>> 4.8.1:
>>> GlobalSign will revoke a certificate it has issued upon the
>>> occurrence of any of the following events:
>>> GlobalSign has been compelled through illegal means by Subscriber
>>> or third parties to issue the certificate;
>
> Illegal under which jurisdiction? How would GlobalSign know if this
> occurred?
>
> Answer GS: We are running in circles I believe : as specified illegal
> under GlobalSign CA jurisdiction eg Belgium. All actions on the CA
> are logged and audited which notifies us of a party trying a compelled
> attack.
I feel better about the compelled SubCA risk given that you described
how it occurs offline in Belgian jurisdiction.
I feel better about the unconstrained RA risk given that you described
that RAs are constrained. However, it seems important that they are all
constrained on the CN and SAN fields, given that these are essentially
the only identity fields that matter for non-EV certs.
It's still not clear to me how you would detect a compelled client cert
creation based only on audits of logs, given that they appear no
different than legitimate cert creation commands. Your local staff (or
the RA staff) in the hostile jurisdiction could act in compliance with
local law in requesting an illegitimate cert, and you would have no way
of knowing unless they told you (thus likely violating local law or at
least angering local authorities).
I'll let the rest of the community chime in on this thread to say
whether any of this should be blocking for the approval, but it doesn't
seem realistic that we could improve the disclosure or practices on this
request much more. I do think that this approval request has helped to
highlight several deficiencies in the current trust model in general.
Johan, thanks for your patience.
Steve
Eddy Nigg
> The difference I was referring to was that "enterprise" in the
> checklist explicitly describes that users from the public internet
> should not encounter the certs. Specifically:
>
> "internal purposes, e.g., to issue SSL server certificates to systems
> running intranet applications, to issue individual SSL client
> certificates for employees or contractors for use in authenticating to
> such applications, and so on."
>
> This is different from "for use under its own brand towards their
> target audience," because that definition could include public use
> (eg: subdomain1.facebook.com).
>
> Mozilla isn't already demanding this in light of the Comodo RA fiasco.
The above issues have been mentioned partially in the Problematic
Practices, see
https://wiki.mozilla.org/CA:Problematic_Practices#Delegation_of_Domain_.2F_Email_validation_to_third_parties
and
https://wiki.mozilla.org/CA:Problematic_Practices#Allowing_external_entities_to_operate_subordinate_CAs
Additionally I've been poking on a full audit requirement for RAs and
sub ordinate CAs. I think this should be a requirement, period.
Kathleen Wilson
> On 07/13/2010 12:32 AM, From Steve Schultze:
>> The difference I was referring to was that "enterprise" in the
>> checklist explicitly describes that users from the public internet
>> should not encounter the certs. Specifically:
>>
>> "internal purposes, e.g., to issue SSL server certificates to systems
>> running intranet applications, to issue individual SSL client
>> certificates for employees or contractors for use in authenticating to
>> such applications, and so on."
>>
>> This is different from "for use under its own brand towards their
>> target audience," because that definition could include public use
>> (eg: subdomain1.facebook.com).
>>
>> I certainly agree that this is a good idea, and I don't understand why
>> Mozilla isn't already demanding this in light of the Comodo RA fiasco.
>
> The above issues have been mentioned partially in the Problematic
> Practices, see
> https://wiki.mozilla.org/CA:Problematic_Practices#Delegation_of_Domain_.2F_Email_validation_to_third_parties
> and
> https://wiki.mozilla.org/CA:Problematic_Practices#Allowing_external_entities_to_operate_subordinate_CAs
>
>
> Additionally I've been poking on a full audit requirement for RAs and
> sub ordinate CAs. I think this should be a requirement, period.
>
Steve and Eddy, Thank you for your thorough review of this request from
GlobalSign to include the “GlobalSign Root CA - R3” root certificate,
which is the SHA256 version of the GlobalSign SHA1 root that is already
included in NSS. Your feedback and recommendations are greatly appreciated!
In regards to the full audit requirement for RAs, this is a good
direction to go in, though it's not currently a requirement. Currently
we check: "The CA must demonstrate clear and efficient controls
attesting the performance of its RAs." It looks to me like GlobalSign
has demonstrated this and is taking appropriate action to further
improve the auditing of their RAs.
My interpretation of this discussion is that the questions have been
reasonably answered.
I do not see any follow-up action items that need to be tracked for this
request.
It appears to me that this request is ready for me to recommend approval.
Kathleen
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
>
> 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
>
Thank you to those of you who have reviewed this request and provided
your feedback in the discussions. Your participation in this process is
greatly appreciated.
The results of the discussion of this request are as follows.
GlobalSign updated their CP and CPS to further clarify their practices
in regards to questions that were raised during the discussions. The
updated versions of these documents are available on their website:
http://www.globalsign.com/repository/GlobalSign_CPS_v6.7.pdf
http://www.globalsign.com/repository/GlobalSign_CA_CP_v3.5.pdf
This concludes the public discussion about GlobalSign’s request to add
the “GlobalSign Root CA - R3” root certificate, and to enable all three
trust bits. The request is to also enable EV.
I will post my recommendation for approval of this request in the bug.
https://bugzilla.mozilla.org/show_bug.cgi?id=507360
All follow-ups on this request should be posted directly in the bug.
Thanks,
Kathleen