Closed Bug 662259 Opened 14 years ago Closed 11 years ago

SG Trust services Root certificate

Categories

(CA Program :: CA Certificate Root Program, task)

Product:
CA Program
Component:
CA Certificate Root Program
Platform:
x86
Windows 7
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: sylvain.rossi, Assigned: kathleen.a.wilson)

References

Details

(Whiteboard: Approved - in FF 27)

Attachments

(13 files, 6 obsolete files)

Root Certificate CP
579.00 KB, application/octet-stream
Details
Initial CA Information Document
68.09 KB, application/pdf
Details
End entity users' certificate examples
19.20 KB, application/octet-stream
Details
Updated CA Information Document
79.86 KB, application/pdf
Details
Root site of SG Trust Services
260.22 KB, image/png
Details
Import CRL into Firefox
38.27 KB, image/png
Details
Import end entity certificaate and CRL
651.75 KB, application/pdf
Details
Root certificate - Key in 4096 and SHA-256
1.53 KB, application/octet-stream
Details
English Translation of CP's paragraphs attended
51.00 KB, application/octet-stream
Details
Annual public attestation ETSI 102042
212.90 KB, application/pdf
Details
Completed Information Gathering Document
89.48 KB, application/pdf
Details
Audit Statement 2013
237.74 KB, application/pdf
Details
UpdatedAuditStatement.pdf
1.92 MB, application/pdf
Details
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0) Build Identifier: CA's presentation : 1) The certificate data (or links to the data) for the CA certificate(s) requested for inclusion : The CA deliver certificates for e-Gov and banks users in France. Usages are e-signature and authentication. You can find more information by cliking the following link : http://www.sgtrustservices.com/entreprise/pc/index.htm 2) For each CA certificate requested for inclusion, whether or not the CA issues certificates for each of the following purposes within the CA hierarchy associated with the CA certificate: SSL-enabled servers, 3) For each CA certificate requested for inclusion, whether the CA issues Extended Validation certificates within the CA hierarchy associated with the CA certificate and, if so, the EV policy OID associated with the CA certificate NA 4) A Certificate Policy and Certification Practice Statement (or links to a CP and CPS) or equivalent disclosure document(s) for the CA or CAs in question; Included below Can be provided 5) Information as to how the CA has fulfilled the requirements stated above regarding its verification of certificate signing requests and its conformance to a set of acceptable operational criteria. ETSI 102042 level NCP conformance, delivering by LSTI. The conformance certificate can be provided Reproducible: Always
Attached file Root Certificate CP —
Attached file Root certificate (DER format) (obsolete) —
Accepting this bug. I'll begin review as per https://wiki.mozilla.org/CA:How_to_apply#Information_Verification
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Whiteboard: Information incomplete
The attached document summarizes the information that has been verified. The items highlighted in yellow indicate where further information or clarification is needed. Please review the full document for accuracy and completeness.
Hi Kathleen, We find below the answers of the items higlighted in yellow in your document : - Organizational type : CA is opérated by a private corporation, SG Trust services is a french bank organization (Societe Generale) - Primark Market / Customer Base : Customers are general publics who make e-Services with banks and french government third parties. - Impact to Mozilla Users : General public in France - CA Contact information : Sgtrust.Services@socgen.com, 01 42 14 54 63, Chief of SG Trust Services CA - Certificate Issuer Field : "Groupe SG" is the high level entity of all subsidiaries of SG - Certificate summary : CA certificate is the root certificate of SG Trust Services. Root CA has two sub-CA, one for authentication certificate and another for signing certificate. - SSL Verification Procedures : NA, CA doesn't sign this kind of certificates - Email Address Verification Procedures : Subscribers must provide complete registration information. To obtain a cryptographic support and install their certificate, they must meet a registration operator who checks the identity paper of the subscriber. - Code Signing Subscriber Verification Procedures : NA, CA doesn't sign this kind of certificates - Response to Mozilla's CA Recommended Practices : SG Trust Services CA had been audited by a French accreditate corporation, LSTI. SG has obtained a conformity certificate, we join in attachment. This conformity certificate attests that SG Trust Services CA respect the ETSI 102042 and the CA is qualified due to RGS level two stars. You can find the CA Certificate Policy by following this link : http://www.sgtrustservices.com/entreprise/pc/index.htm We attached you users' certificate (authentication and singing) : the private key password is : #SGTS2011. You can contact us if you want more information. Can you tell us the effetive date the SG Trust Services CA can be integrated to the Mozilla Root certificate program ? Best Regards, Sylvain
(In reply to comment #6) > - Organizational type : CA is opérated by a private corporation, SG Trust > services is a french bank organization (Societe Generale) > - CA Contact information : Sgtrust.Services@socgen.com > - Certificate Issuer Field : "Groupe SG" is the high level entity of all > subsidiaries of SG Is Groupe SG the organization behind the following website? http://www.societegenerale.com/ Is SG Trust Services an organization within Société Générale (as per the above website)? Are you the official representative for the CA services offered by SG Trust Services? > - Certificate summary : CA certificate is the root certificate of SG Trust > Services. Root CA has two sub-CA, one for authentication certificate and > another for signing certificate. > - SSL Verification Procedures : NA, CA doesn't sign this kind of certificates > - Email Address Verification Procedures : Subscribers must provide complete > registration information. To obtain a cryptographic support and install > their certificate, they must meet a registration operator who checks the > identity paper of the subscriber. > - Code Signing Subscriber Verification Procedures : NA, CA doesn't sign this > kind of certificates To be clear, your request is to include the "SG TRUST SERVICES RACINE" root certificate and only enable the email trust bit. Correct? > - Response to Mozilla's CA Recommended Practices : SG Trust Services CA had > been audited by a French accreditate corporation, LSTI. SG has obtained a > conformity certificate, we join in attachment. This conformity certificate > attests that SG Trust Services CA respect the ETSI 102042 and the CA is > qualified due to RGS level two stars. OK, I found SG Trust Services in the list on the LSTI website: http://www.lsti-certification.fr/images/stories/listergs_07032011.pdf > Can you tell us the effetive date the SG Trust Services CA can be integrated > to the Mozilla Root certificate program ? https://wiki.mozilla.org/CA:How_to_apply#Timeline
(In reply to comment #8) > (In reply to comment #6) > > > - Organizational type : CA is opérated by a private corporation, SG Trust > > services is a french bank organization (Societe Generale) > > - CA Contact information : Sgtrust.Services@socgen.com > > - Certificate Issuer Field : "Groupe SG" is the high level entity of all > > subsidiaries of SG > > > Is Groupe SG the organization behind the following website? > http://www.societegenerale.com/ > Yes and SG Trust Services is a subsidiary from Groupe SG > Is SG Trust Services an organization within Société Générale (as per the > above website)? > Yes see below > Are you the official representative for the CA services offered by SG Trust > Services? > No, the official representative for CA services is : Joël Dupont SG TRUST SERVICES Responsable de l'Offre Certificats Electroniques tel : 01 42 14 54 63 Mobile : 06 77 85 17 58 joel.dupont@socgen.com > > > - Certificate summary : CA certificate is the root certificate of SG Trust > > Services. Root CA has two sub-CA, one for authentication certificate and > > another for signing certificate. > > - SSL Verification Procedures : NA, CA doesn't sign this kind of certificates > > - Email Address Verification Procedures : Subscribers must provide complete > > registration information. To obtain a cryptographic support and install > > their certificate, they must meet a registration operator who checks the > > identity paper of the subscriber. > > - Code Signing Subscriber Verification Procedures : NA, CA doesn't sign this > > kind of certificates > > > To be clear, your request is to include the "SG TRUST SERVICES RACINE" root > certificate and only enable the email trust bit. Correct? > Certificate issued by "SG TRUST SERVICES RACINE" root certificate are for authentication and signature usages. So we only need the email trust bit to be active. > > > - Response to Mozilla's CA Recommended Practices : SG Trust Services CA had > > been audited by a French accreditate corporation, LSTI. SG has obtained a > > conformity certificate, we join in attachment. This conformity certificate > > attests that SG Trust Services CA respect the ETSI 102042 and the CA is > > qualified due to RGS level two stars. > > OK, I found SG Trust Services in the list on the LSTI website: > http://www.lsti-certification.fr/images/stories/listergs_07032011.pdf > > > > Can you tell us the effetive date the SG Trust Services CA can be integrated > > to the Mozilla Root certificate program ? > > https://wiki.mozilla.org/CA:How_to_apply#Timeline Thx
(In reply to comment #9) > > Are you the official representative for the CA services offered by SG Trust > > Services? > > > No, the official representative for CA services is : > Joël Dupont > SG TRUST SERVICES > Responsable de l'Offre Certificats Electroniques Is Joël Dupont aware that you are requesting the inclusion of the SG Trust Services root certificate in Mozilla products? Has SG Trust Services officially requested your assistance in getting their root certificate included in Mozilla products? Who will be the ongoing point-of-contact regarding this root certificate (both during the inclusion process and after)? http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html "15. To request that its certificate(s) be added to the default set a CA should submit a formal request by submitting a bug report into the mozilla.org Bugzilla system,... The request must be made by an authorized representative of the subject CA"
(In reply to comment #10) > (In reply to comment #9) > > > Are you the official representative for the CA services offered by SG Trust > > > Services? > > > > > No, the official representative for CA services is : > > Joël Dupont > > SG TRUST SERVICES > > Responsable de l'Offre Certificats Electroniques > > > Is Joël Dupont aware that you are requesting the inclusion of the SG Trust > Services root certificate in Mozilla products? > Of course. He's project manager and the official representative for the CA services and he delegates us the administrative request to reference "SG TRUST SERVICES CA" into Mozilla products. > Has SG Trust Services officially requested your assistance in getting their > root certificate included in Mozilla products? > Yes we have sign contract and non-disclosure agreement with SG Trust Services to make administrative requests for root certification programs > Who will be the ongoing point-of-contact regarding this root certificate > (both during the inclusion process and after)? > Mr Joel Dupont is and will be the point of contact. > http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html > "15. To request that its certificate(s) be added to the default set a CA > should submit a formal request by submitting a bug report into the > mozilla.org Bugzilla system,... The request must be made by an authorized > representative of the subject CA" It's right and SG Trust Services (Joel Dupont) contract with us to do that. We can add Joël Dupont in the CC email list of the bugtrack ? Will it be convenient on your side ? Regards, Sylvain
(In reply to comment #11) Thank you for the clarification. From https://wiki.mozilla.org/CA:How_to_apply "Having a root included in NSS is not a one-time effort. After a CA has a root included in NSS, it is expected that the CA will continue to be aware of ongoing discussions and updates to the Mozilla CA Certificate Policy. The CA is required to send regular updated audits to Mozilla. The CA is required to update their policies as the Mozilla CA Certificate Policy is updated." > > Who will be the ongoing point-of-contact regarding this root certificate > > (both during the inclusion process and after)? > > > Mr Joel Dupont is and will be the point of contact. > > > http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html > > "15. To request that its certificate(s) be added to the default set a CA > > should submit a formal request by submitting a bug report into the > > mozilla.org Bugzilla system,... The request must be made by an authorized > > representative of the subject CA" > It's right and SG Trust Services (Joel Dupont) contract with us to do that. > We can add Joël Dupont in the CC email list of the bugtrack ? Will it be > convenient on your side ? Yes, I believe that Joël Dupont should be added to the CC list of this bug.
The items highlighted in yellow indicate where further information or clarification is needed.
Hi Kathleen, Due to your last answers, we have lauch the following actions : - English translation of several paragraph of the CPS - Asking a modification of CRL profile to allow integration inf Firefox keystore. I try also to add Joel Dupont to the CC liste of this bugtrack but I have the following answer : Bugzilla was unable to make any match at all for one or more of the names and/or email addresses you entered on the previous page. Please go back and try other names or email addresses. -------------------------------------------------------------------------------- CC: joel.dupont@socgen.fr did not match anything How can I add Joel to this bugtrack ? Thanks, Sylvain (In reply to Kathleen Wilson from comment #13) > Created attachment 547493 [details] > Updated CA Information Document > > The items highlighted in yellow indicate where further information or > clarification is needed.
> I try also to add Joel Dupont to the CC liste of this bugtrack but I have > the following answer : > > Bugzilla was unable to make any match at all for one or more of the names > and/or email addresses you entered on the previous page. > > Please go back and try other names or email addresses. > ----------------------------------------------------------------------------- > --- > CC: joel.dupont@socgen.fr did not match anything > > How can I add Joel to this bugtrack ? > Joel will need to create a Bugzilla account before you can add him to the CC list of this bug. See the first point in #2 of https://wiki.mozilla.org/CA:How_to_apply#Creation_and_submission_of_the_root_CA_certificate_inclusion_request
Hi Kathleen, Joel Dupont was added to the CC list of this bugtrack and he can follow it now. Concerning the CRL endpoints, we have changed the format and you should now integrate them into Mozilla browser. We have done a success test with Mozilla Firefox. The CRL could be downloaded here : http://crl.sgtrustservices.com/racine-GroupeSG/LatestCRL http://crl.sgtrustservices.com/SGTS-2Etoiles/LatestCRL Thanks, Sylvain
(In reply to Sylvain Rossi from comment #16) > Concerning the CRL endpoints, we have changed the format and you should now > integrate them into Mozilla browser. We have done a success test with > Mozilla Firefox. > > The CRL could be downloaded here : > > http://crl.sgtrustservices.com/racine-GroupeSG/LatestCRL > http://crl.sgtrustservices.com/SGTS-2Etoiles/LatestCRL I just tried both of those urls, and I got an error saying that my browser could not establish a connection to the server at crl.sgtrustservices.com.
(In reply to Kathleen Wilson from comment #17) > (In reply to Sylvain Rossi from comment #16) > > Concerning the CRL endpoints, we have changed the format and you should now > > integrate them into Mozilla browser. We have done a success test with > > Mozilla Firefox. > > > > The CRL could be downloaded here : > > > > http://crl.sgtrustservices.com/racine-GroupeSG/LatestCRL > > http://crl.sgtrustservices.com/SGTS-2Etoiles/LatestCRL > > > I just tried both of those urls, and I got an error saying that my browser > could not establish a connection to the server at crl.sgtrustservices.com. Hi, It's really curious because when : - I write crl.sgtrustservices.com, I can established a connection to the root site of SG Trust Services - I write http://crl.sgtrustservices.com/SGTS-2Etoiles/LatestCRL, I can import the CRL into my browser. See attachment. Thanks, Sylvain
Attached image Import CRL into Firefox —
Hi Kathleen, You can find a new attachment containing english translations of the Certificate Policy's paragraphs you attend. Thanks, Sylvain
Hi Kathleen, We haven't got anymore news since our last post. Could you tell us if the process is going on well. Best Regards, Sylvain
> > Concerning the CRL endpoints, we have changed the format and you should now > > integrate them into Mozilla browser. We have done a success test with > > Mozilla Firefox. > > > > The CRL could be downloaded here : > > > > http://crl.sgtrustservices.com/racine-GroupeSG/LatestCRL > > http://crl.sgtrustservices.com/SGTS-2Etoiles/LatestCRL > I am able to import both of these CRLs into my Firefox browser.
Please review the CA Communication that was sent on September 8, and is available here: https://wiki.mozilla.org/CA:Communications Please add a comment to this bug to provide your response to the action items listed in the CA Communication. For more information about action items #1 and #3, please see items #6 and #7 of https://wiki.mozilla.org/CA:Information_checklist#Verification_Policies_and_Practices
(In reply to Sylvain Rossi from comment #21) > Created attachment 560318 [details] > English Translation of CP's paragraphs attended > > Hi Kathleen, > > You can find a new attachment containing english translations of the > Certificate Policy's paragraphs you attend. > > Thanks, > Sylvain Please provide the url to the original document that this is the translation of.
(In reply to Kathleen Wilson from comment #24) > Please review the CA Communication that was sent on September 8, and is > available here: https://wiki.mozilla.org/CA:Communications > > Please add a comment to this bug to provide your response to the action > items listed in the CA Communication. For more information about action > items #1 and #3, please see items #6 and #7 of > https://wiki.mozilla.org/CA: > Information_checklist#Verification_Policies_and_Practices Hi Kathleen, You can see below answers to the CA Communication : 1) Audit your PKI and review your systems to check for intrusion or compromise. This includes all third party CAs and RAs. The LSTI conformance certificate (in attachment) is the result of external audit which permit SG Trust Services to have ETSI 102023 (NCP+ level) certification. 2) Send a complete list of CA certificates from other roots in our program that your roots (including third party CAs and RAs) have cross-signed. A listing of all root certificates in Mozilla's products is here: http://www.mozilla.org/projects/security/certs/included No cross-certification 3) Confirm that multi-factor authentication is required for all accounts capable of directly causing certificate issuance. Yes, it's detailed on Certificate Policy (paragraph 2.4) 4) Confirm that you have automatic blocks in place for high-profile domain names (including those targeted in the DigiNotar and Comodo attacks this year). Please further confirm your process for manually verifying such requests, when blocked. Only CA trusted by SG Trust Services are implemented in their applications. We confirm that DigiNotar and Comodo CA are not yet anymore allowed. Manually process consist to explicit block domains from a reverse-proxy which threats all transactions to SG Trust Services Applications. 5) For each external third party (CAs and RAs) that issues certificates or can directly cause the issuance of certificates within the hierarchy of the root certificate(s) that you have included in Mozilla products, either: No external third party, CA and RA are operated internally by SG Trust Services team. a) Implement technical controls to restrict issuance to a specific set of domain names which you have confirmed that the third party has registered or has been authorized to act for (e.g. RFC5280 x509 dNSName name constraints, marked critical) OR b) Send a complete list of all third parties along with links to each of their corresponding Certificate Policy and/or Certification Practice Statement and provide public attestation of their conformance to the stated verification requirements and other operational criteria by a competent independent party or parties with access to details of the subordinate CA's internal operations.
(In reply to Kathleen Wilson from comment #25) > (In reply to Sylvain Rossi from comment #21) > > Created attachment 560318 [details] > > English Translation of CP's paragraphs attended > > > > Hi Kathleen, > > > > You can find a new attachment containing english translations of the > > Certificate Policy's paragraphs you attend. > > > > Thanks, > > Sylvain > > > Please provide the url to the original document that this is the translation > of. You can find the original CP to the link below : http://www.sgtrustservices.com/entreprise/pc/SGTS-2Etoiles/authentification/index.htm Regards, Sylvain
(In reply to Sylvain Rossi from comment #27) > You can find the original CP to the link below : > http://www.sgtrustservices.com/entreprise/pc/SGTS-2Etoiles/authentification/ > index.htm I can browse to http://www.sgtrustservices.com/entreprise/pc/index.htm but I get an error when I try to browse to http://www.sgtrustservices.com/entreprise/pc/SGTS-2Etoiles/authentification/index.htm Is that the correct url?
Hello Kathleen, I make a mistake into the URL. In fact the correct CP is downloadable at the following link : https://www.sgts.rgs2e.sgtrustservices.com/doc/PC/SG_TS_2E_PC_Authentification.pdf Thanks, Sylvain
Hello Kathleen, Have yout got anymore trouble to validate the SG Trust Services Root CA into the Mozilla Root CA Program ? Best Regards, Sylvain
Thank you for the information. In the CP for 2-Star Certificates section 3.2.3.3, there is a description of how the Certificate Manager (the Customer) is verified. Is the Certificate Manager always a member of Groupe SG, or can the Certificate Manager be a member of a different company? Please provide translations into English of the section of the CP that describes who can apply to be a Customer. In the CP for 2-Star Certificates section 3.2.3.4, there is a description of how a certificate subscriber is registered. It is clear that the identity of the certificate subscriber is verified, but I do not see how the email address to be included in the certificate is verified. Who provides the email address to be included in the certificate? Who verifies the email address? How? (In reply to Sylvain Rossi from comment #26) > 3) Confirm that multi-factor authentication is required for all accounts > capable of directly causing certificate issuance. > > Yes, it's detailed on Certificate Policy (paragraph 2.4) > Please translate section 2.4 into English. Who can approve and issue a certificate? The Certificate Manager? The Customer Account Manager?
Hello Kathleen, We are agreeing that integrate a root CA into Mozilla products is a secure process but we are extremely surprised to have to answer to all these questions. We have made a PKI conformance to the ETSI 102042 NCP+ and we have obtained a conformance certificate delivered by an external and neutral auditor, LSTI. All points you want to explain or confirm have been already audited and we make this process annually. However, you can find our answers below: > In the CP for 2-Star Certificates section 3.2.3.3, there is a description of > how the Certificate Manager (the Customer) is verified. Is the Certificate > Manager always a member of Groupe SG, or can the Certificate Manager be a > member of a different company? Please provide translations into English of the > section of the CP that describes who can apply to be a Customer. Registration service is a group of person of SG Trust Services. Certificate Manager is a person into a client company of SG Trust Services who can: - Collect the registration document (Individual Subscriber Request) of the Subscriber; - Valid the registration documents before sending to registration service; - Make sign Disclosure Statement to the Subscriber; Each Certificate Manager meets the registration service of SG Trust Service in face to face. The Legal Representative must provide the future Manager with a "K-bis” certifying the company’s registration with a French trade and companies register (or any similar trade register for foreign entities) or an identification certificate from the “Répertoire National des Entreprises et de leurs Établissements” database. Legal Representatives of an association must provide a copy of the “Journal Officiel” containing the mention of their organization as well as a copy of its articles of association and the minutes of the last Annual General Meeting during which an executive was appointed. Registration Service validates each subscriber’s registration demand by: - Validating that the Certificate Manager who provide the registration documents are well-known; - Validating the completion of registration documents; - Validating the copy of the subscriber’s identity card; - Compare signature of disclosures statements and signature of the identity card. > In the CP for 2-Star Certificates section 3.2.3.4, there is a description of > how a certificate subscriber is registered. It is clear that the identity of > the certificate subscriber is verified, but I do not see how the email address > to be included in the certificate is verified. Who provides the email address > to be included in the certificate? Who verifies the email address? How? The email address is provided by subscriber into the documents registration. The Certificate Manager verifies that the email is correct and is attached to his organization before sending to Registration Service. In technical process, only the subscriber can receive into the email declared on registration documents the install URL of his certificate. > Please translate section 2.4 into English. Published datas are accessible in read mode to all people concerning by certificates signed by SG Trust Services (Internet Access). Adding, deleting and modifications are limited only to authorized persons defining by Head of the CA. Registration Operators and PKI’s administrators can access data, including status of certificates (adding, deleting or modification process) by personal authentication certificate stored on SSCD, after obtaining a particular accreditation. Technical administrators of the publication web site can access data, including status of certificates (adding, deleting or modification process) by personal two-factor authentication, after obtaining a particular accreditation. Data transfer from PKI’s administrators to Technical administrators of the publication web site is done throw a secured channel to maintain data’s integrity. > Who can approve and issue a certificate? The Certificate Manager ? The Customer > Account Manager? Registration Operator, into the Registration Service (group of person of SG Trust Services formerly identified by Head of the CA) can approve the certificate issuance by validating: - The Individual Subscriber Request (ISR) form dated less than 3 months prior, completed and signed both by the future Subscriber and the CM. - The ISR form includes personal information on the future Subscriber required for creating the certificate. o The ISR form includes the General Terms and Conditions of Use (Disclosures Statements). o The photocopy of the Certificate Subscriber's ID card, signed by the Certificate Manager and the Subscriber. Best Regards, Sylvain
Hello Kathleen, Could you have any feedbacks of our Root CA integration process ? Our client, SG Trust Service, want to know if there was any difficulties and if the initial rules needed by the Mozilla have changed. In this case, could you explain the impact for SG Trust Services and what we want to do ? Best Regards, Sylvain
(In reply to Sylvain Rossi from comment #33) > Our client, SG Trust Service, want to know if there was any difficulties and > if the initial rules needed by the Mozilla have changed. What is your relation to this CA? Who will be the ongoing point-of-contact if this root certificate is included in Mozilla products? Why does this CA want to include their root certificate directly in Mozilla products? Has this CA considered working with another CA who currently has root certificates included in Mozilla products, rather than trying to get their certificate included directly? A description of Mozilla's root inclusion process is here: https://wiki.mozilla.org/CA This request is currently at step #3: A representative of Mozilla verifies the information provided by the CA. I have two things remaining to verify. Perhaps you can have someone test these in a Mozilla product, such as Thunderbird? 1) Import the example certificate into a Mozilla product. I have tried unsuccessfully to import the certificates into Thunderbird. I think it is because I don't have the full certificate chain. I imported the root, and imported what I think is the appropriate intermediate certificate, but I have not been able to import one of the user certificates that was provided as an attachment: https://bugzilla.mozilla.org/attachment.cgi?id=544773 2) Import the CRL (without error) into a Mozilla product. I have tried unsuccessfully to import these two CRLs into both Firefox and Thunderbird: http://crl.sgtrustservices.com/racine-GroupeSG/LatestCRL http://crl.sgtrustservices.com/SGTS-2Etoiles/LatestCRL It appears that I cannot connect to the crl.sgtrustservices.com server.
(In reply to Kathleen Wilson from comment #34) > (In reply to Sylvain Rossi from comment #33) > > Our client, SG Trust Service, want to know if there was any difficulties and > > if the initial rules needed by the Mozilla have changed. > > What is your relation to this CA? Who will be the ongoing point-of-contact > if this root certificate is included in Mozilla products? > See comment 9. Joel Dupont, chief of SG Trust PKI services is the point-of-contact. He's in copy of the bugtrack > Why does this CA want to include their root certificate directly in Mozilla > products? To authenticate SSL sessions and sign email. > Has this CA considered working with another CA who currently has > root certificates included in Mozilla products, rather than trying to get > their certificate included directly? > No > A description of Mozilla's root inclusion process is here: > https://wiki.mozilla.org/CA > > This request is currently at step #3: > A representative of Mozilla verifies the information provided by the CA. > > I have two things remaining to verify. Perhaps you can have someone test > these in a Mozilla product, such as Thunderbird? > > 1) Import the example certificate into a Mozilla product. I have tried > unsuccessfully to import the certificates into Thunderbird. I think it is > because I don't have the full certificate chain. I imported the root, and > imported what I think is the appropriate intermediate certificate, but I > have not been able to import one of the user certificates that was provided > as an attachment: > https://bugzilla.mozilla.org/attachment.cgi?id=544773 > We have tried successfully to import certificate in comment 7 into Firefox (see new attachment) > 2) Import the CRL (without error) into a Mozilla product. I have tried > unsuccessfully to import these two CRLs into both Firefox and Thunderbird: > http://crl.sgtrustservices.com/racine-GroupeSG/LatestCRL > http://crl.sgtrustservices.com/SGTS-2Etoiles/LatestCRL > It appears that I cannot connect to the crl.sgtrustservices.com server. The new CRL link is described into comment 23. Thanks, Sylvain
Hello, Have you got any news after our two last comments ? Regards, Sylvain
Dear all, I am the manager of the Certificate Authority SG TRUST SERVICES.SG TRUST is a 100% subsidiary of SOCIETE GENERALE GROUP, one of the first bank in Europ. SG TRUST has a CA, conforming to ETSI 102042 level NCP.and with the help of Sylvain Rossi (Sealweb company) we are trying to integrate our root CA certificate in your Certificate program. We began this process six months ago, and currently, it seems to be in stand by on your side, and we have no feedback. So, we do would like to continue because this step is very important in our project of having our Root CA integrated into your Root CA Program. This step was announced like an IT needs of SOCIETE GENERAL GROUP. We are in a difficult situation because we had announced to our internal department that the integration would be done before end of 2011. We know now that we will not be able to fill our commitments but we hope it will be possible to 1st quarter of 2012. So, it would be kind of you to provide us feedback about our request and if it is possible we would like to set a conference call with Sylvain and you in order to go ahead. You can give us a tel number and a slot at your convenience. Thanks a lot for answering Best regards Joël Dupont SG TRUST SERVICES Digital Certificates Product Manager tel : 33 (0)1 42 14 54 63 Mobile : 33 (0)6 77 85 17 58 joel.dupont@socgen.com
(In reply to Kathleen Wilson from comment #34) > I have two things remaining to verify. Perhaps you can have someone test > these in a Mozilla product, such as Thunderbird? > > 1) Import the example certificate into a Mozilla product. I have tried > unsuccessfully to import the certificates into Thunderbird. I think it is > because I don't have the full certificate chain. I imported the root, and > imported what I think is the appropriate intermediate certificate, but I > have not been able to import one of the user certificates that was provided > as an attachment: > https://bugzilla.mozilla.org/attachment.cgi?id=544773 > The attachment in Comment #36 shows that the sample certs import correctly into Firefox. > 2) Import the CRL (without error) into a Mozilla product. I have tried > unsuccessfully to import these two CRLs into both Firefox and Thunderbird: > http://crl.sgtrustservices.com/racine-GroupeSG/LatestCRL > http://crl.sgtrustservices.com/SGTS-2Etoiles/LatestCRL > It appears that I cannot connect to the crl.sgtrustservices.com server. These CRL urls are working for me now. The CRLs import into my Firefox browser without error.
(In reply to joel.dupont from comment #38) > step was announced like an IT needs of SOCIETE GENERAL GROUP. We are in a > difficult situation because we had announced to our internal department that > the integration would be done before end of 2011. We know now that we will > not be able to fill our commitments but we hope it will be possible to 1st > quarter of 2012. Please see https://wiki.mozilla.org/CA for a description of Mozilla's CA Certificate Inclusion process, and to get a better idea of the time that it takes to go through the process to get a root certificate included.
Attached file Completed CA Information Document (obsolete) —
This request has been added to the queue for public discussion: https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion Now that you have a request in the Queue for Public Discussion, you are directly impacted by the time it takes to work through the queue. The goal is to have each discussion take about two weeks. However, that time varies dramatically depending on the number of reviewers contributing to the discussion, and the types of concerns that are raised. If no one reviews and contributes to a discussion, then a request may be in the discussion for several weeks. When there are not enough people contributing to the discussions ahead of yours, then your request will sit in the queue longer. How can you help reduce the time that your request sits in the queue? You can help by reviewing and providing your feedback in the public discussions of root inclusion requests, or by asking a knowledgeable colleague to do so. Participating in other discussions is a great way to learn the expectations and be prepared for the discussion of your request. Please see: https://wiki.mozilla.org/CA:How_to_apply#Public_discussion
Whiteboard: Information incomplete → Information confirmed complete
Hello Kathleen, That is a good news ! When a new discussion about SG Trust services will be created into the mozilla.dev.security.policy newsgroup ? Regards, Sylvain
(In reply to Sylvain Rossi from comment #43) > When a new discussion about SG Trust services will be created into the > mozilla.dev.security.policy newsgroup ? It will be a few months: https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
3 problems spotted: 1. The example certificates don't chain to the supplied root. The root included in the .pfx example certificates is a RSA4096 one, named "commonName=SG TRUST SERVICES RACINE, organizationalUnitName=0002 43525289500022, organizationName=SG TRUST SERVICES, countryName=FR" The root supplied for Mozilla inclusion is a RSA2048 one, named "organizationName=GROUPE SG, organizationalUnitName=SG TRUST SERVICES, commonName=SG TRUST SERVICES RACINE". 2. The certificatePolicies extension of the "sign" example EE certificate show a policyId equal to 1.2.250.1.124.7.1.2.3.1. The CA that produced this certificate has been limited to allow only one policyId below, which is 1.2.250.1.124.7.1.1.1.1. Therefore, the intermediate CA doesn't respect the constraints imposed by its issuing CA (the root). Same logic applies to the other example certificates. 3. The intermediate CA has produced a CRL with an entry revoked for cACompromise reason. Since this CA can't produce CA certificates (based on its basicConstraints extension), we then can conclude that the issued (and revoked) certificate is not a CA one, and that the intermediate CA itself has been compromised. Therefore, it should cease its operations and be revoked. This is not the case. How do you explain that?
Kathleen, can you modifiy the root certificate to the bugtrack of SG Trust Services by this one. Thanks
Attachment #537544 - Attachment is obsolete: true
(In reply to Erwann Abalea from comment #45) > 3 problems spotted: > > 1. The example certificates don't chain to the supplied root. > The root included in the .pfx example certificates is a RSA4096 one, named > "commonName=SG TRUST SERVICES RACINE, organizationalUnitName=0002 > 43525289500022, organizationName=SG TRUST SERVICES, countryName=FR" > The root supplied for Mozilla inclusion is a RSA2048 one, named > "organizationName=GROUPE SG, organizationalUnitName=SG TRUST SERVICES, > commonName=SG TRUST SERVICES RACINE". Thanks to detect this mistake. See comment 46. > > 2. The certificatePolicies extension of the "sign" example EE certificate > show a policyId equal to 1.2.250.1.124.7.1.2.3.1. The CA that produced this > certificate has been limited to allow only one policyId below, which is > 1.2.250.1.124.7.1.1.1.1. Therefore, the intermediate CA doesn't respect the > constraints imposed by its issuing CA (the root). Same logic applies to the > other example certificates. > We are not sure to understand you : - 1.2.250.1.124.7.1.2.3.1 is the policyID of end entity certificate with the Non repudiation key usage. This is the CP's OID of "SG TS 2 ETOILES CA" for certificate signing profile - 1.2.250.1.124.7.1.2.2.1 is the policyID of end entity certificate with the DigitalSignature key usage.This is the CP's OID of "SG TS 2 ETOILES CA" for certificate with authentication profile - 1.2.250.1.124.7.1.1.1.1 is the policyID of the intermediate CA "SG TS 2 ETOILES". This is the CP's OID of "SG TRUST SERVICES RACINE CA". This chaining of policyID have been validated during the ETSI 102042 conformance audit. > 3. The intermediate CA has produced a CRL with an entry revoked for > cACompromise reason. Since this CA can't produce CA certificates (based on > its basicConstraints extension), we then can conclude that the issued (and > revoked) certificate is not a CA one, and that the intermediate CA itself > has been compromised. Therefore, it should cease its operations and be > revoked. This is not the case. How do you explain that? At the begining, the revocation raison was provided by the certificate's owner himself. Like you could conclude, revocations for cACompromise reason were a mistake. Concerned certificates were not CA certificate and the CA (and all chaining certificate) were not been compromised. Moreover, the revocation reason is no longer revealed by the CRL.
(In reply to Sylvain Rossi from comment #47) > (In reply to Erwann Abalea from comment #45) > > 2. The certificatePolicies extension of the "sign" example EE certificate > > show a policyId equal to 1.2.250.1.124.7.1.2.3.1. The CA that produced this > > certificate has been limited to allow only one policyId below, which is > > 1.2.250.1.124.7.1.1.1.1. Therefore, the intermediate CA doesn't respect the > > constraints imposed by its issuing CA (the root). Same logic applies to the > > other example certificates. > > > We are not sure to understand you : > - 1.2.250.1.124.7.1.2.3.1 is the policyID of end entity certificate with the > Non repudiation key usage. This is the CP's OID of "SG TS 2 ETOILES CA" for > certificate signing profile > - 1.2.250.1.124.7.1.2.2.1 is the policyID of end entity certificate with the > DigitalSignature key usage.This is the CP's OID of "SG TS 2 ETOILES CA" for > certificate with authentication profile > - 1.2.250.1.124.7.1.1.1.1 is the policyID of the intermediate CA "SG TS 2 > ETOILES". This is the CP's OID of "SG TRUST SERVICES RACINE CA". > > This chaining of policyID have been validated during the ETSI 102042 > conformance audit. Read X.509 recommandation (since the 2000/03 edition), clause 8.2.2.6 describing the certificatePolicies extension, and clause 10 describing the algorithm for certification path processing. The meaning of this extension is different if it is contained in a CA or an end-entity certificate. > > 3. The intermediate CA has produced a CRL with an entry revoked for > > cACompromise reason. Since this CA can't produce CA certificates (based on > > its basicConstraints extension), we then can conclude that the issued (and > > revoked) certificate is not a CA one, and that the intermediate CA itself > > has been compromised. Therefore, it should cease its operations and be > > revoked. This is not the case. How do you explain that? > > At the begining, the revocation raison was provided by the certificate's > owner himself. Like you could conclude, revocations for cACompromise reason > were a mistake. Concerned certificates were not CA certificate and the CA > (and all chaining certificate) were not been compromised. Thank you for the explanation. > Moreover, the revocation reason is no longer revealed by the CRL. Yes it is. I just downloaded the CRL and parsed it.
Updated as per Comment #46. Please let me know if there is anything else in this document that needs to be updated.
Attachment #579765 - Attachment is obsolete: true
Please also provide a response to Comment #48.
(In reply to Erwann Abalea from comment #48) > (In reply to Sylvain Rossi from comment #47) > > (In reply to Erwann Abalea from comment #45) > > > 2. The certificatePolicies extension of the "sign" example EE certificate > > > show a policyId equal to 1.2.250.1.124.7.1.2.3.1. The CA that produced this > > > certificate has been limited to allow only one policyId below, which is > > > 1.2.250.1.124.7.1.1.1.1. Therefore, the intermediate CA doesn't respect the > > > constraints imposed by its issuing CA (the root). Same logic applies to the > > > other example certificates. > > > > > We are not sure to understand you : > > - 1.2.250.1.124.7.1.2.3.1 is the policyID of end entity certificate with the > > Non repudiation key usage. This is the CP's OID of "SG TS 2 ETOILES CA" for > > certificate signing profile > > - 1.2.250.1.124.7.1.2.2.1 is the policyID of end entity certificate with the > > DigitalSignature key usage.This is the CP's OID of "SG TS 2 ETOILES CA" for > > certificate with authentication profile > > - 1.2.250.1.124.7.1.1.1.1 is the policyID of the intermediate CA "SG TS 2 > > ETOILES". This is the CP's OID of "SG TRUST SERVICES RACINE CA". > > > > This chaining of policyID have been validated during the ETSI 102042 > > conformance audit. > > Read X.509 recommandation (since the 2000/03 edition), clause 8.2.2.6 > describing the certificatePolicies extension, and clause 10 describing the > algorithm for certification path processing. The meaning of this extension > is different if it is contained in a CA or an end-entity certificate. > As you can see, the root certificate has been updated and is now correct. Normally, the OID's chain between Root CA and end-entity certificates would be correct. > > > 3. The intermediate CA has produced a CRL with an entry revoked for > > > cACompromise reason. Since this CA can't produce CA certificates (based on > > > its basicConstraints extension), we then can conclude that the issued (and > > > revoked) certificate is not a CA one, and that the intermediate CA itself > > > has been compromised. Therefore, it should cease its operations and be > > > revoked. This is not the case. How do you explain that? > > > > At the begining, the revocation raison was provided by the certificate's > > owner himself. Like you could conclude, revocations for cACompromise reason > > were a mistake. Concerned certificates were not CA certificate and the CA > > (and all chaining certificate) were not been compromised. > > Thank you for the explanation. > OK > > Moreover, the revocation reason is no longer revealed by the CRL. > > Yes it is. I just downloaded the CRL and parsed it. OK
(In reply to Sylvain Rossi from comment #51) [...] > As you can see, the root certificate has been updated and is now correct. The root certificate has been updated in this bug, yes. > Normally, the OID's chain between Root CA and end-entity certificates would > be correct. Still no. You haven't read the X.509 recommendation or didn't understand the certificatePolicies extension. This extension lists the different CP that are acceptable for the end-user certificates, *not* the CPS followed to deliver each certificate on the chain. The intermediate certificate (CN=SG TS 2 ETOILES) has a certificatePolicies extension containing only 1 policyId, which is "1.2.250.1.124.7.1.1.1.1". What this means precisely is that this CA has been restricted by its issuer (the root) so that the end-entity certificates can have only this exact policyId. The end-entity certificates presented have different policyIds (1.2.250.1.124.7.1.2.2.1, 1.2.250.1.124.7.1.2.3.1, and 1.2.250.1.124.7.1.2.4.1). So a PKIX compliant software will reject those certificates if policy checking is performed. Despite its name, this extension (certificatePolicies) is to be seen as a set of constraints.
(In reply to Erwann Abalea from comment #52) > (In reply to Sylvain Rossi from comment #51) > [...] > > As you can see, the root certificate has been updated and is now correct. > > The root certificate has been updated in this bug, yes. > > > Normally, the OID's chain between Root CA and end-entity certificates would > > be correct. > > Still no. You haven't read the X.509 recommendation or didn't understand the > certificatePolicies extension. This extension lists the different CP that > are acceptable for the end-user certificates, *not* the CPS followed to > deliver each certificate on the chain. > > The intermediate certificate (CN=SG TS 2 ETOILES) has a certificatePolicies > extension containing only 1 policyId, which is "1.2.250.1.124.7.1.1.1.1". > What this means precisely is that this CA has been restricted by its issuer > (the root) so that the end-entity certificates can have only this exact > policyId. The end-entity certificates presented have different policyIds > (1.2.250.1.124.7.1.2.2.1, 1.2.250.1.124.7.1.2.3.1, and > 1.2.250.1.124.7.1.2.4.1). So a PKIX compliant software will reject those > certificates if policy checking is performed. > > Despite its name, this extension (certificatePolicies) is to be seen as a > set of constraints. OK, we understand that the certificatePolicies extension in the end-entity certificate is correct but not in CA's certificates. Regarding the RFC 5280, we can read : "In a CA certificate, these policy information terms limit the set of policies for certification paths that include this certificate. When a CA does not wish to limit the set of policies for certification paths that include this certificate, it MAY assert the special policy anyPolicy, with a value of { 2 5 29 32 0 }" We are agree with you on this point and we add the folowing information : - The CA and the end-entity certificate have been qualified RGS** and have been declared conformed to the RFC 5280 - We could plan to change the certificatePolicies of the CA's certificate by putting the AnyPolicy value. At the moment, the key cermony had been done and we can't change the CA's certificate quickly.
(In reply to Sylvain Rossi from comment #53) [...] > Regarding the RFC 5280, we can read : "In a CA certificate, > these policy information terms limit the set of policies for > certification paths that include this certificate. When a CA does > not wish to limit the set of policies for certification paths that > include this certificate, it MAY assert the special policy anyPolicy, > with a value of { 2 5 29 32 0 }" > > We are agree with you on this point and we add the folowing information : > - The CA and the end-entity certificate have been qualified RGS** and have > been declared conformed to the RFC 5280 The content does conform to RFC5280, yes. You could have put a keyUsage with only keyAgreement bit, it would still be conformant, while completely wrong. At the same time. That's the power of audits. > - We could plan to change the certificatePolicies of the CA's certificate by > putting the AnyPolicy value. At the moment, the key cermony had been done > and we can't change the CA's certificate quickly. anyPolicy would have been a much better choice, if the intermediate CA key is controlled by the same entity controlling the root key. Here, if a RP wants to strictly check that a signature certificate has a policy OID equal to 1.2.250.1.124.7.1.2.3.1 under your root, following the X.509 (and RFC5280) normalized validation path algorithm will reject your certificates.
(In reply to Erwann Abalea from comment #54) > (In reply to Sylvain Rossi from comment #53) > [...] > > Regarding the RFC 5280, we can read : "In a CA certificate, > > these policy information terms limit the set of policies for > > certification paths that include this certificate. When a CA does > > not wish to limit the set of policies for certification paths that > > include this certificate, it MAY assert the special policy anyPolicy, > > with a value of { 2 5 29 32 0 }" > > > > We are agree with you on this point and we add the folowing information : > > - The CA and the end-entity certificate have been qualified RGS** and have > > been declared conformed to the RFC 5280 > > The content does conform to RFC5280, yes. You could have put a keyUsage with > only keyAgreement bit, it would still be conformant, while completely wrong. > At the same time. > That's the power of audits. > > > - We could plan to change the certificatePolicies of the CA's certificate by > > putting the AnyPolicy value. At the moment, the key cermony had been done > > and we can't change the CA's certificate quickly. > > anyPolicy would have been a much better choice, if the intermediate CA key > is controlled by the same entity controlling the root key. > Yes of course but the key ceremony was already done and we must wait the CA's certificate renewal to change this value. > Here, if a RP wants to strictly check that a signature certificate has a > policy OID equal to 1.2.250.1.124.7.1.2.3.1 under your root, following the > X.509 (and RFC5280) normalized validation path algorithm will reject your > certificates. Yes we are agreed
(In reply to Kathleen Wilson from comment #49) > Created attachment 620470 [details] > Completed Information Gathering Document > > Updated as per Comment #46. Thanks > > Please let me know if there is anything else in this document that needs to > be updated. No (In reply to Kathleen Wilson from comment #50) > Please also provide a response to Comment #48. Done
> (In reply to Kathleen Wilson from comment #50) > > Please also provide a response to Comment #48. > Done Erwann, have your questions been sufficiently addressed?
(In reply to Kathleen Wilson from comment #57) > > (In reply to Kathleen Wilson from comment #50) > > > Please also provide a response to Comment #48. > > Done > > Erwann, have your questions been sufficiently addressed? Yes, Kathleen. That end-users are allowed to specify themselves the revocation reason comes in conflict with what Google is doing with CRLSets, but as they're now hidden, it's OK. This raises more questions, but not specific to this inclusion request. The fact that some CAs start doing business and want to be referenced without having read X.509/RFC5280, with defective OCSP responders, without following good practices regarding cryptographic researches, I don't know, I find it a little disturbing. Anyway, my questions on this request have been answered.
Hello Kathleen, Is it OK to start the Phase 2 of public Discussion ? Regards, Sylvain
This request is still in the queue for discussion. https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
Hello Sylvain, I see in CPS that SG Trust Services is the Certificate Authority but I also noticed that the Certificate Authority is leaded by Societe Generale. Could you give us more detail on the organisation of this CA ? Regards, Giovanetti
Hello, You can see comment #9 to have more details. SG Trust Services is a 100% subsidiary from Groupe Societe Generale, a leader bank in Europe. "Societe Generale" is the organization defined into the Root CA Certificate and Joël Dupont is the representative of the root CA. Regards, Sylvain
This request is near the top of the queue for discussion, so I'm reviewing my notes to make sure the information is current. It looks like I just need a current audit statement. Please provide an audit statement regarding the annual surveillance audit for 2012. The statement that I have is from May, 2011.
Hello Kathleen, The last annual surveillance audit was done on november 2011 and the next one is planned to the month of december of this year. As soon as we will have the audit report we will add it to this bugtrack. Regards, Sylvain
While reviewing my notes it appears that I have not yet asked you to respond to the CA Communication that was sent in February. https://wiki.mozilla.org/CA:Communications#February_17.2C_2012 Based on my notes I expect that answers to items #1, #2, and #3 will be "Not Applicable" (N/A). Correct? So please provide answers to items #4 and #5.
Hello Kathleen, Effectively items #1, #2 and #3 is not applicable. 4) Certificates chaining to root certificates in Mozilla’s root program should not have MD5 algorithms or RSA keys shorter than 1024 bits long. Please scan the certificates chaining to your root certificates in NSS, and revoke any certificates that contain small key sizes or MD5 algorithms. All certificates issued by CA contain a 2048 key size and SHA-256 algortihms. 5) The CA/Browser Forum has released the "Baseline Requirements for the Issuance and Management of Publicly Trusted Certificates,” which is available here: http://www.cabforum.org/. Discussions are in progress in the mozilla.dev.security.policy forum to update Mozilla’s CA Certificate Policy to add a requirement that CAs also meet these baseline requirements for issuance of SSL/TLS certificates. Please contribute to the discussions in the mozilla.dev.security.policy forum, and update your operations and documentation as needed to meet the baseline requirements by the effective date of July 1, 2012. "SG Trust CAs" are conforming to RGS** which is equivalent to ETSI 102042 NCP+. SG Trust updates their operations and documentation each year to be conformed to the ETSI. Moreover SG Trust confirms that they will update their operations and documentation accordance by Cabforum baseline requirements if the new requirements are compatible with ETSI 102042. Regards, Sylvain
Attachment #620470 - Attachment is obsolete: true
I am now opening the first public discussion period for this request from SG Trust Services to add the “SG TRUST SERVICES RACINE” root certificate and turn on the Email trust bit. For a description of the public discussion phase, see https://wiki.mozilla.org/CA:How_to_apply#Public_discussion Public discussion will be in the mozilla.dev.security.policy discussion forum. http://www.mozilla.org/about/forums/#dev-security-policy The discussion thread is called “SG Trust Services Root Inclusion Request” Please actively review, respond, and contribute to the discussion. A representative of SG Trust Services must promptly respond directly in the discussion thread to all questions that are posted.
Whiteboard: Information confirmed complete → In public discussion
Sylvain, It appears that the sgtrustservices website has been re-organized, so the links I was using are broken. In particular: Document Repository: http://www.sgtrustservices.com/entreprise/pc/index.htm CP for Authentication and Encryption Certs: http://www.sgtrustservices.com/entreprise/pc/authentification/index.htm CP for Signing Certs: http://www.sgtrustservices.com/entreprise/pc/signature/index.htm CP for 2-Star Certs: https://www.sgts.rgs2e.sgtrustservices.com/doc/PC/SG_TS_2E_PC_Authentification.pdf Please provide the new links ASAP.
Hi Kathleen, You have right, the new link is the following http://www.sgtrustservices.com/home/web/guest/politiquecertifrgs2 Documents can be dowloaded by clicking here : "http://www.sgtrustservices.com/home/c/document_library/get_file?uuid=50b72e0c-4d9e-475d-b2e3-293335d3aa04&groupId=10157" All CP are the same. Regards, Sylvain
The old links I have are… Document Repository: http://www.sgtrustservices.com/entreprise/pc/index.htm CP for Authentication and Encryption Certs: http://www.sgtrustservices.com/entreprise/pc/authentification/index.htm CP for Signing Certs: http://www.sgtrustservices.com/entreprise/pc/signature/index.htm CP for 2-Star Certs: https://www.sgts.rgs2e.sgtrustservices.com/doc/PC/SG_TS_2E_PC_Authentification.pdf CP for 2-Star Certs (English translation of some sections): https://bugzilla.mozilla.org/attachment.cgi?id=560318 So then the new links are… Document Repository: http://www.sgtrustservices.com/home/web/guest/politiquecertifrgs2 CP for Authentication and Encryption Certs: http://www.sgtrustservices.com/home/c/document_library/get_file?uuid=50b72e0c-4d9e-475d-b2e3-293335d3aa04&groupId=10157 then open the file called “SGTS 2E_PC_Authentification_et_signature_V1.0.doc” CP for Signing Certs: http://www.sgtrustservices.com/home/c/document_library/get_file?uuid=50b72e0c-4d9e-475d-b2e3-293335d3aa04&groupId=10157 then open the file called “SG TS 2E_PC-Signature_V1.0.doc” CP for 2-Star Certs: http://www.sgtrustservices.com/home/c/document_library/get_file?uuid=50b72e0c-4d9e-475d-b2e3-293335d3aa04&groupId=10157 then open the file called “SG TS 2E_PC_Authentification_V1.0.doc” Do I have that correct? Why lump them all into one link/file that has to be downloaded/expanded in order to view one of the documents? Why not have a separate page individually listing them, as you do the "Politiques de Certification PRIS" link in the Download section at the bottom of the page? Please remind me of the relation between the CP documents listed above and the documents listed on http://www.sgtrustservices.com/home/politiquecertifpris and the RGS documents in the Download section at the bottom of the page.
Hello Kathleen, Yes, it's correct, all CP could be downloaded here : http://www.sgtrustservices.com/home/web/guest/politiquecertifrgs2 Now, on the new web site "sgtrustservices.com", CA's documents (PRIS or RGS) are zipped into a file. You can find into this zipped file the CP's root CA and CP's intermediate CA. "PRIS" and "RGS" are not linked directly. "PRIS" is the old PKI's labelisation in France and is now obsolete, but "SG Trust services" sells them to their clients because some applications need yet PRIS's certificate. PRIS's CA can't be referenced into root CA certification program. Since 2010, RGS is the new labelisation program in France and is more strict than ETSI 102042. When you are RGS 2-Stars compliant, you are automatically ETSI 102042 NCP+ compliant. Regards, Sylvain
The CP documents still have the old URLs in them: "Toutes ces informations sont publiées sur le site de publication: http://www.sgtrustservices.com. En particulier: - Politique de Certification : http://www.sgtrustservices.com/entreprise/pc/SGTS- 2Etoiles/authentification/index.htm ... - Certificats de l’AC SG TS 2 ETOILES et de l’AC Racine : http://www.sgtrustservices.com/sgts/ac/digitalidCenter.htm"
Hello Kathleen, You are right. CP have been updated and URLs are correct now. Thanks, Sylvain
(In reply to Sylvain Rossi from comment #21) > Created attachment 560318 [details] > English Translation of CP's paragraphs attended > Please explain the relation between these documents: SGTS_2E_PC_Signature 1.2.pdf, SGTS_2E_PC_Authentification 1.2.pdf, SGTS 2E_PC_Authentification_et_signature 1.2.pdf Also, which of these documents does attachment 560318 [details] correspond to? It looks like we need a new version of attachment 560318 [details] with updated section numbers. Please also check that the actual translations are complete and match the current version of the CP document.
In addition to responding to Comment #75, please also add a comment to this bug to provide your response to the action items listed in the CA Communication that was sent today, and is available here: https://wiki.mozilla.org/CA:Communications#January_10.2C_2013
Attachment #560318 - Attachment is obsolete: true
Attachment #537541 - Attachment is obsolete: true
Hello Kathleen, Response to comment 64 : You can see in attachment 702297 [details] the update of the ETSI 102042 certification attestation, delivered in december 2012. Response to comment 75 : Each CP describes a specific certificate's usage : - SGTS_2E_PC_Signature 1.2.pdf : NonRepudiation bit is positionned - SGTS_2E_PC_Authentification 1.2.pdf : DigitalSignature bit is positionned - SGTS 2E_PC_Authentification_et_signature 1.2.pdf : NonRepudiation and DigitalSignature bits are positionned Dans ces documents, toutes les exigences sont équivalentes à l'exception profil du certificat qui est différent selon le KeyUsage. Paragraphes translated in the attachment 560318 [details] are the same for all CP and have not changed. You can see an update document in attachment 702296 [details]. Response to comment 76 : 1) Review the proposed changes to Mozilla’s CA Certificate Policy, and assess the impact of those changes to your CA operations. 6 - We require that all CAs whose certificates are distributed with our software products: - enforce multi-factor authentication for all accounts capable of directly causing certificate issuance or implement technical controls operated by the CA to restrict certificate issuance through the account to a limited set of pre-approved domains or email addresses; The proposed updates to Mozilla’s CA Certificate Policy do not require further change to our CA operations, because our CA operations already comply with the proposed policy. ○ maintain a certificate hierarchy such that the included certificate does not directly issue end-entity certificates to customers (e.g., the included certificate signs intermediate issuing certificates), as described in CA/Browser Forum Baseline Requirement #12; The proposed updates to Mozilla’s CA Certificate Policy do not require further change to our CA operations, because our CA operations already comply with the proposed policy. 9 - All certificates that are capable of being used to issue new certificates, and which directly or transitively chain to a certificate included in Mozilla's CA Certificate Program, MUST be operated in accordance with Mozilla's CA Certificate Policy and MUST either be technically constrained or be publicly disclosed and audited. ○ A certificate is deemed as capable of being used to issue new certificates if it contains an X.509v3 basicConstraints extension, with the cA boolean set to true. The term "subordinate CA" below refers to any organization or legal entity that is in possession or control of a certificate that is capable of being used to issue new certificates. The proposed updates to Mozilla’s CA Certificate Policy do not require further change to our CA operations, because our CA operations already comply with the proposed policy. ○ These requirements include all cross-certified certificates which chain to a certificate that is included in Mozilla's CA Certificate Program. No cross-certified certificates. 10 - We encourage CAs to technically constrain all subordinate CA certificates. For a certificate to be considered technically constrained, the certificate MUST include an Extended Key Usage (EKU) extension specifying all extended key usages that the subordinate CA is authorized to issue certificates for. The anyExtendedKeyUsage KeyPurposeId MUST NOT appear within this extension. SG Trust CA certificates don't include EKU. 11 - We recognize that technically constraining subordinate CA certificates as described above may not be practical in some cases. All certificates that are capable of being used to issue new certificates, that are not technically constrained, and that directly or transitively chain to a certificate included in Mozilla's CA Certificate Program MUST be audited in accordance with Mozilla's CA Certificate Policy and MUST be publicly disclosed by the CA that has their certificate included in Mozilla's CA Certificate Program. The CA with a certificate included in Mozilla's CA Certificate Program MUST disclose this information before any such subordinate CA is allowed to issue certificates. All disclosure MUST be made freely available and without additional requirements, including, but not limited to, registration, legal agreements, or restrictions on redistribution of the certificates in whole or in part. The Certificate Policy or Certification Practice Statement of the CA that has their certificate included in Mozilla's CA Certificate Program must specify where on that CA's website all such public disclosures are located. For a certificate to be considered publicly disclosed and audited, the following information MUST be provided: ○ The full DER-encoded X.509 certificate (Each issuing CA should provide one .p7c, .zip, or .tgz file containing all of the non-technically-constrained intermediate certificates that it has signed.); ○ The corresponding Certificate Policy or Certification Practice Statement used by the subordinate CA; and ○ Annual public attestation of conformance to the stated certificate verification requirements and other operational criteria by a competent independent party or parties with access to the details of the subordinate CA's internal operations. The first two elements are present on the following websites : https://www.sgtrustservices.com. The annual public attestation of conformance could be ask to the point of contact identified into CP. 13 - CA operations and issuance of certificates to be used for SSL-enabled servers must also conform to version 1.1 of the CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. In the event of inconsistency between Mozilla's CA Certificate Policy requirements and the Baseline Requirements, Mozilla's CA Certificate Policy takes precedence. The items listed below will be accepted as reason for not following the Baseline Requirements. If you find an inconsistency that is not listed here, notify Mozilla by sending email to certificates@mozilla.org so the item can be considered. ○ Mozilla's CA Certificate Policy defining a competent and independent auditor takes precedence over Baseline Requirement #17.6, Auditor Qualifications. The proposed updates to Mozilla’s CA Certificate Policy do not require further change to our CA operations, because our CA operations already comply with the proposed policy. 2) Confirm compliance with the CA/Browser Forum’s Baseline Requirements. Our CA operations conform to the CA/Browser Forum’s Baseline Requirements for issuance of SSL certificates, and our next audit will include verification of this conformance. 3) Scan your certificate database for certificates that incorrectly have basicConstraints with the cA boolean set to true, or are incorrectly enabled with the keyCertSign Key Usage bit. We have scanned our certificate database, and confirm that there are no un-expired intermediate certificates in our CA hierarchy that should not be trusted. We have also checked our certificate database to confirm that all of the non-expired certificates have been issued in accordance with the listed practices. 4) Deprecate issuance of SSL certificates containing a Reserved IP Address or Internal Server Name. We do not issue SSL certificates that chain up to a root certificate that is included in Mozilla's CA Certificate Program and that contain Reserved IP Addresses or Internal Server Names. 5) For each root certificate or trust anchor you control that is included in Mozilla’s CA Certificate Program and has the SSL trust bit enabled by default, please provide a URL to a website (which may be a test site) whose SSL certificate chains up to it. https://www.sgts.rgs2e.sgtrustservices.com/sgts/client/TestCert Regards, Sylvain
Hello Kathleen, We have actually ETSI 102042 NCP+ certification for authentication and signature usage, so the only trust bit we need is S/MIME. The website cited in my last comment (https://www.sgts.rgs2e.sgtrustservices.com/sgts/client/TestCert) can to check an authentication or signature certificate. We confirm that we are just asking for the email (S/MIME) trust bit to be enabled for this root. Regards, Sylvain -----Original Message----- From: Kathleen Wilson [mailto:kwilson@mozilla.com] Sent: jeudi 28 février 2013 01:47 To: sylvain.rossi@sealweb.eu; sylvain.rossi@socgen.com Subject: Re: [Bug 662259] SG Trust services Root certificate Hello Sylvain, I apologize for my delayed response. I suspended my work on root inclusion/change requests for a while, and am now resuming that work. I am confused by your response to Mozilla's CA Communication. In particular, > 5) For each root certificate or trust anchor you control that is > included in Mozilla’s CA Certificate Program and has the SSL trust bit > enabled by default, please provide a URL to a website (which may be a > test site) whose SSL certificate chains up to it. > https://www.sgts.rgs2e.sgtrustservices.com/sgts/client/TestCert There are three trust bits that can be enabled for root certificates that are included in NSS: websites (SSL/TLS), email (S/MIME), and Code Signing. In https://bugzilla.mozilla.org/show_bug.cgi?id=662259#c9 you said: Certificate issued by "SG TRUST SERVICES RACINE" root certificate are for authentication and signature usages. So we only need the email trust bit to be active. Is that still correct? You only are asking for the email (S/MIME) trust bit to be enabled for this root? Regards, Kathleen
Attachment #672856 - Attachment is obsolete: true
(In reply to Kathleen Wilson from comment #68) > I am now opening the first public discussion period for this request from SG > Trust Services to add the “SG TRUST SERVICES RACINE” root certificate and > turn on the Email trust bit. > > For a description of the public discussion phase, see > https://wiki.mozilla.org/CA:How_to_apply#Public_discussion > > Public discussion will be in the mozilla.dev.security.policy discussion > forum. > http://www.mozilla.org/about/forums/#dev-security-policy > > The discussion thread is called “SG Trust Services Root Inclusion Request” > > Please actively review, respond, and contribute to the discussion. > > A representative of SG Trust Services must promptly respond directly in the > discussion thread to all questions that are posted. I have re-started this discussion in the mozilla.dev.security.policy forum.
The public comment period for this request is now over. This request has been evaluated as per Mozilla’s CA Certificate Policy at http://www.mozilla.org/projects/security/certs/policy/ Here follows a summary of the assessment. If anyone sees any factual errors, please point them out. To summarize, this assessment is for the request to add the “SG TRUST SERVICES RACINE” root certificate and turn on the Email trust bit. Section 4 [Technical]. I am not aware of instances where SG Trust Services has knowingly issued certificates for fraudulent use. If anyone knows of any such issues or instances, please note them in this bug. Section 6 [Relevance and Policy]. SG Trust Services appears to provide a service relevant to Mozilla users. It is a subsidiary of Groupe SG, which is the high level entity of all subsidiaries of Société Générale, one of the oldest and largest banks in France and is a major international financial services company. Customers are the general public who make e-Services with banks and French government third parties. Policies are documented in the documents published on their website and listed in the entry on the pending applications list; the main documents of interest are the CP for each specific certificate usage. The documents are in French, some sections were translated into English. Document Repository: http://www.sgtrustservices.com/home/en/web/guest/politiquecertifrgs2 On this page there is a link called “Download the RGS ** certificate policies” which provides a zip file that contains the related certificate policies. Each CP describes a specific certificate's usage. - SGTS 2E_PC_Authentification_et_signature 1.2.pdf (NonRepudiation and DigitalSignature bits are positioned) - SGTS_2E_PC_Signature 1.2.pdf (NonRepudiation bit is positioned) - SGTS_2E_PC_Authentification 1.2.pdf (DigitalSignature bit is positioned) - SGTS_2E_PC_Racine 1.2.pdf English translations: https://bugzilla.mozilla.org/attachment.cgi?id=702296 The paragraphs that have been translated are the same for all of the CP documents. Section 7 [Validation]. SG Trust Services appears to meet the minimum requirements for subscriber verification, as follows: * SSL: Not applicable. Not requesting the SSL trust bit. * Email: According to CP section 4.2.3, each customer client company of SG Trust Services has a Certificate Manager that verifies the identity of each certificate subscriber and verifies that the email to be included in the certificate is correct and is attached to his organization before sending the request to the Registration Service. The Registration Service validates each subscriber’s registration request by validating that the Certificate Manager who provided the registration documents is well-known; validating the completion of registration documents; validating the copy of the subscriber’s identity card; and comparing signature of disclosures statements and signature of the identity card. The URL to install the certificate is emailed to the email address that is included in the certificate. * Code: Not applicable. Not requesting the code signing trust bit. Section 15 [Certificate Hierarchy]. The “SG TRUST SERVICES RACINE” root certificate has two internally-operated intermediate certificates, one for authentication certificates and another for signing certificates. * EV Policy OID: Not applicable. * CRL http://crl.sgtrustservices.com/racine-GroupeSG/LatestCRL http://crl.sgtrustservices.com/SGTS-2Etoiles/LatestCRL (NextUpdate: 6 days) * OCSP: not provided (Note: This request is to turn on the Email trust bit only, so the CAB Forum Baseline requirements don’t apply.) Sections 9-11 [Audit]. Audits are performed against the ETSI TS 102 042 criteria by LSTI, and a list of the certified certificate providers is provided on the LSTI website. Annual surveillance audits are also performed. http://www.lsti-certification.fr/images/liste_entreprise/Liste_15_03_2013_S.pdf ETSI Certificate: https://bugzilla.mozilla.org/attachment.cgi?id=702297 Based on this assessment I intend to approve this request to add the “SG TRUST SERVICES RACINE” root certificate and turn on the Email trust bit.
Whiteboard: In public discussion → Pending Approval
As per the summary in Comment #83, and on behalf of Mozilla I approve this request from SG Trust Services to include the following root certificate: ** "SG TRUST SERVICES RACINE" (email) I will file the NSS bug for the approved changes.
Whiteboard: Pending Approval → Approved - awaiting NSS
Depends on: 860929
I have filed bug #860929 against NSS for the actual changes.
Whiteboard: Approved - awaiting NSS → Approved - in FF 27
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Attached file Audit Statement 2013 —
Product: mozilla.org → NSS
Product: NSS → CA Program
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: