Re: Second Discussion of LuxTrust Root Inclusion Request
On Thursday, August 4, 2016 at 10:51:58 AM UTC-7, Kathleen Wilson wrote: > On Wednesday, March 23, 2016 at 2:08:19 PM UTC-7, Kathleen Wilson wrote: > > On 12/17/15 5:34 PM, Kathleen Wilson wrote: > > > The first discussion of LuxTrust's root inclusion request was here: > > > https://groups.google.com/d/msg/mozilla.dev.security.policy/47Jz7f8E4RI/sT1wTJ2RIEMJ > > > > > The CA has resolved the questions and concerns raised during the first > discussion, and has provided an updated root certificate with corresponding > updated documentation and audit statement. > > Please review this request from LuxTrust to include the "LuxTrust Global Root > 2" certificate, turn on the Websites trust bit, and enable EV treatment. > > The request is documented in the following bug: > https://bugzilla.mozilla.org/show_bug.cgi?id=944783 > > Summary of Information Gathered and Verified: > https://bugzilla.mozilla.org/attachment.cgi?id=8777892 > > This root signs internally-operated subordinate CAs that issue SSL and code > signing certificates. > > Documents are in French and English. > CA Document Repository: https://repository.luxtrust.lu > CP: > https://www.luxtrust.lu/upload/data/repository/LuxTrust%20Global%20Root%20CA%20-%20Certificate%20Profiles%20v1%2022.pdf > CPS: > https://www.luxtrust.lu/upload/data/repository/LuxTrust_Global_Root%20CA_Certification_Practice_Statements_v1_09.pdf > SSL CPS: SSL CPS: > https://www.luxtrust.lu/upload/data/repository/LuxTrust%20SSL%20CA%20CPS%20v1.3.pdf > Thanks again to those of you who participated in the discussions about LuxTrust's root inclusion request. The updated request is to include the "LuxTrust Global Root 2" certificate, turn on the Websites trust bit, and enable EV treatment. I am now closing this discussion and will recommend approval in the bug. https://bugzilla.mozilla.org/show_bug.cgi?id=944783 Any further follow-up on this request should be added directly to the bug. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Second Discussion of LuxTrust Root Inclusion Request
On Wednesday, September 21, 2016 at 9:04:53 PM UTC-7, Ryan Sleevi wrote: > I've reviewed this CP/CPS set again, keeping in mind the previous comments on > the first round of discussion, and I don't believe there's anything noted > that should prevent this inclusion from continuing. Thanks, Ryan! I plan to close this discussion and recommend approval in the bug. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Second Discussion of LuxTrust Root Inclusion Request
On Friday, September 16, 2016 at 1:13:38 PM UTC-7, Kathleen Wilson wrote: > On Thursday, September 8, 2016 at 9:07:33 AM UTC-7, Kathleen Wilson wrote: > > Does anyone have comments, questions, or concerns about this request from > > LuxTrust to include the "LuxTrust Global Root 2" certificate, turn on the > > Websites trust bit, and enable EV treatment? > > > > If not, I will close this discussion and recommend approval in the bug. > > > I am leaving this discussion open, due to a request for more time to review > and comment on this CA's updated CP/CPS. Hi Kathleen, I've reviewed this CP/CPS set again, keeping in mind the previous comments on the first round of discussion, and I don't believe there's anything noted that should prevent this inclusion from continuing. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Second Discussion of LuxTrust Root Inclusion Request
On Thursday, September 8, 2016 at 9:07:33 AM UTC-7, Kathleen Wilson wrote: > Does anyone have comments, questions, or concerns about this request from > LuxTrust to include the "LuxTrust Global Root 2" certificate, turn on the > Websites trust bit, and enable EV treatment? > > If not, I will close this discussion and recommend approval in the bug. I am leaving this discussion open, due to a request for more time to review and comment on this CA's updated CP/CPS. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Second Discussion of LuxTrust Root Inclusion Request
On Thursday, August 4, 2016 at 10:51:58 AM UTC-7, Kathleen Wilson wrote: > > The CA has resolved the questions and concerns raised during the first > discussion, and has provided an updated root certificate with corresponding > updated documentation and audit statement. > > Please review this request from LuxTrust to include the "LuxTrust Global Root > 2" certificate, turn on the Websites trust bit, and enable EV treatment. > > The request is documented in the following bug: > https://bugzilla.mozilla.org/show_bug.cgi?id=944783 > > Summary of Information Gathered and Verified: > https://bugzilla.mozilla.org/attachment.cgi?id=8777892 > > This root signs internally-operated subordinate CAs that issue SSL and code > signing certificates. > > Documents are in French and English. > CA Document Repository: https://repository.luxtrust.lu > CP: > https://www.luxtrust.lu/upload/data/repository/LuxTrust%20Global%20Root%20CA%20-%20Certificate%20Profiles%20v1%2022.pdf > CPS: > https://www.luxtrust.lu/upload/data/repository/LuxTrust_Global_Root%20CA_Certification_Practice_Statements_v1_09.pdf > SSL CPS: SSL CPS: > https://www.luxtrust.lu/upload/data/repository/LuxTrust%20SSL%20CA%20CPS%20v1.3.pdf > > SSL CPS section 3.2.2: In the particular case of SSL, RAs operating under the > LuxTrust SSL CA shall determine whether the domain referenced in the SSL > Certificate application is owned and controlled by the subscriber. > LuxTrust validates that the Subscriber has the right to control the domain > names using the following verification procedures: > [1] Communicating with the technical contact information provided by the > Subscriber in the order form. > [2] Communicating directly with the Domain Name Registrant using the contact > information listed in the WHOIS record’s “registrant”, “technical”, or > “administrative” field; > [3] Relying upon a Domain Authorization Document which contains the signature > of an authorized representative of the domain holder, a date that is on or > after the certificate request and a statement confirming the Subscriber’s > control over the domain names in the certificate. LuxTrust also relies on a > reliable third-party, the Chamber of Commerce of Luxembourg, to confirm the > authenticity of the Domain Authorization Document. > > Root Certificate Download URL: > https://ca.luxtrust.lu/LTGRCA2.crt > > Test Website: https://ltsslca5.trustme.lu/ > > EV Policy OID: 1.3.171.1.1.10.5.2 > > CRL: > http://crl.luxtrust.lu/LTGRCA2.crl > http://crl.luxtrust.lu/LTSSLCA5.crl > SSL CPS section 4.9.7: A CRL is issued each 4 hours, at an agreed time. > > OCSP: > http://ssl.ocsp.luxtrust.lu > http://ltgroot.ocsp.luxtrust.lu > > Annual audits are performed by LSTI, according to the ETSI TS 102 042 > criteria. > Audit Statement: https://bugzilla.mozilla.org/attachment.cgi?id=8777887 > http://www.lsti-certification.fr/images/liste_entreprise/Liste%20PSCe.pdf > > This continues the discussion of the request from LuxTrust to include the > "LuxTrust Global Root 2" certificate, turn on the Websites trust bit, and > enable EV treatment. At the conclusion of this discussion I will provide a > summary of issues noted and action items. If there are outstanding issues, > then additional discussion may be needed as follow-up. If there are no > outstanding issues, then I will recommend approval of this request in the bug. > > Kathleen Does anyone have comments, questions, or concerns about this request from LuxTrust to include the "LuxTrust Global Root 2" certificate, turn on the Websites trust bit, and enable EV treatment? If not, I will close this discussion and recommend approval in the bug. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Second Discussion of LuxTrust Root Inclusion Request
On Wednesday, March 23, 2016 at 2:08:19 PM UTC-7, Kathleen Wilson wrote: > On 12/17/15 5:34 PM, Kathleen Wilson wrote: > > The first discussion of LuxTrust's root inclusion request was here: > > https://groups.google.com/d/msg/mozilla.dev.security.policy/47Jz7f8E4RI/sT1wTJ2RIEMJ > > > > > > This discussion is currently on hold, because the CA would like to > request inclusion of the new 'LuxTrust Global Root 2' root certificate > instead of the previous 'LuxTrust Global Root CA' root cert. So, we are > awaiting their updated information. > > Kathleen The CA has resolved the questions and concerns raised during the first discussion, and has provided an updated root certificate with corresponding updated documentation and audit statement. Please review this request from LuxTrust to include the "LuxTrust Global Root 2" certificate, turn on the Websites trust bit, and enable EV treatment. The request is documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=944783 Summary of Information Gathered and Verified: https://bugzilla.mozilla.org/attachment.cgi?id=8777892 This root signs internally-operated subordinate CAs that issue SSL and code signing certificates. Documents are in French and English. CA Document Repository: https://repository.luxtrust.lu CP: https://www.luxtrust.lu/upload/data/repository/LuxTrust%20Global%20Root%20CA%20-%20Certificate%20Profiles%20v1%2022.pdf CPS: https://www.luxtrust.lu/upload/data/repository/LuxTrust_Global_Root%20CA_Certification_Practice_Statements_v1_09.pdf SSL CPS: SSL CPS: https://www.luxtrust.lu/upload/data/repository/LuxTrust%20SSL%20CA%20CPS%20v1.3.pdf SSL CPS section 3.2.2: In the particular case of SSL, RAs operating under the LuxTrust SSL CA shall determine whether the domain referenced in the SSL Certificate application is owned and controlled by the subscriber. LuxTrust validates that the Subscriber has the right to control the domain names using the following verification procedures: [1] Communicating with the technical contact information provided by the Subscriber in the order form. [2] Communicating directly with the Domain Name Registrant using the contact information listed in the WHOIS record’s “registrant”, “technical”, or “administrative” field; [3] Relying upon a Domain Authorization Document which contains the signature of an authorized representative of the domain holder, a date that is on or after the certificate request and a statement confirming the Subscriber’s control over the domain names in the certificate. LuxTrust also relies on a reliable third-party, the Chamber of Commerce of Luxembourg, to confirm the authenticity of the Domain Authorization Document. Root Certificate Download URL: https://ca.luxtrust.lu/LTGRCA2.crt Test Website: https://ltsslca5.trustme.lu/ EV Policy OID: 1.3.171.1.1.10.5.2 CRL: http://crl.luxtrust.lu/LTGRCA2.crl http://crl.luxtrust.lu/LTSSLCA5.crl SSL CPS section 4.9.7: A CRL is issued each 4 hours, at an agreed time. OCSP: http://ssl.ocsp.luxtrust.lu http://ltgroot.ocsp.luxtrust.lu Annual audits are performed by LSTI, according to the ETSI TS 102 042 criteria. Audit Statement: https://bugzilla.mozilla.org/attachment.cgi?id=8777887 http://www.lsti-certification.fr/images/liste_entreprise/Liste%20PSCe.pdf This continues the discussion of the request from LuxTrust to include the "LuxTrust Global Root 2" certificate, turn on the Websites trust bit, and enable EV treatment. At the conclusion of this discussion I will provide a summary of issues noted and action items. If there are outstanding issues, then additional discussion may be needed as follow-up. If there are no outstanding issues, then I will recommend approval of this request in the bug. Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Second Discussion of LuxTrust Root Inclusion Request
On 12/17/15 5:34 PM, Kathleen Wilson wrote: The first discussion of LuxTrust's root inclusion request was here: https://groups.google.com/d/msg/mozilla.dev.security.policy/47Jz7f8E4RI/sT1wTJ2RIEMJ This discussion is currently on hold, because the CA would like to request inclusion of the new 'LuxTrust Global Root 2' root certificate instead of the previous 'LuxTrust Global Root CA' root cert. So, we are awaiting their updated information. Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Second Discussion of LuxTrust Root Inclusion Request
The first discussion of LuxTrust's root inclusion request was here: https://groups.google.com/d/msg/mozilla.dev.security.policy/47Jz7f8E4RI/sT1wTJ2RIEMJ The discussion resulted in 3 action items, and LuxTrust has responded to those action items here: https://groups.google.com/d/msg/mozilla.dev.security.policy/47Jz7f8E4RI/erw3ToheAQAJ To summarize: > 1) Resolve the concerns that were raised about CRL and OCSP. LuxTrust plans the implementation of ... solutions by the end of January 2016. We will need to check the new OCSP solution before closing this second discussion. But, we can review the updated CP/CPS documents in the meantime. > 2) Stop issuing certs with SHA-1 based signatures, and certs with "Netscape Cert Type" extension (especially in this CA hierarchy) LuxTrust confirms that no SSL and code-signing certificate issued under the LTGRCA hierarchy use the SHA-1 hash algorithm, as described in the SSL and code signing profiles of the LTGRCA CP v1.22. Netscape Cert Type: LuxTrust confirms that the certificates issued under the LTGRCA hierarchy do not contain the “Netscape Cert Type” extension, as described in the certificate profiles of the LTGRCA CP v1.22. > 3) Update the CPS documents to respond to Ryan's comments in the discussion To address these concerns, LuxTrust has updated their CP/CPS documents, and provided them on their website: Document Repository: https://repository.luxtrust.lu LTGRCA CP v1.22: https://www.luxtrust.lu/upload/data/repository/LuxTrust%20Global%20Root%20CA%20-%20Certificate%20Profiles%20v1%2022.pdf LTGRCA CPS v1.09: https://www.luxtrust.lu/upload/data/repository/LuxTrust_Global_Root%20CA_Certification_Practice_Statements_v1_09.pdf LTSSLCA CPS v1.3: https://www.luxtrust.lu/upload/data/repository/LuxTrust%20SSL%20CA%20CPS%20v1.3.pdf The updated documents look good to me, and I believe the updates address the concerns that were raised in the first discussion, here: https://groups.google.com/d/msg/mozilla.dev.security.policy/47Jz7f8E4RI/ACHCpG2KCpYJ So, please review their updated CP/CPS documents, and respond in this discussion if you have any further questions or concerns about this request to include the "LuxTrust Global Root" root certificate, turn on the Websites trust bit**, and enable EV treatment. Thanks, Kathleen ** The original request was to enable the Code Signing trust bit too, but Mozilla is no longer enabling the Code Signing trust bit because we plan to remove that trust bit in the next version of Mozilla's CA Certificate Policy. https://wiki.mozilla.org/CA:CertificatePolicyV2.3 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: LuxTrust Root Inclusion Request
Please find below our answer to the three actions items: I) Resolve the concerns that were raised about CRL and OCSP. Also resolve all errors listed here: https://certificate.revocationcheck.com/www.trustme.lu With regards to the issues raised about the OCSP application (either raised in the public discussion or on the certificate revocation check page), after detailed analysis and due to the technical limitations of the current solution, LuxTrust decided to implement a new OCSP application. In addition, with regards to the absence of the “OCSP No Check” extension in the LTGROOT OCSP signing certificate, as raised on the certificate revocation check page, LuxTrust will implement a new certificate profile for the OCSP signing certificate supporting the no check extension. Considering the timelines related to the choice of the new OCSP solution and its implementation by the provider and in accordance with LuxTrust’s internal change management procedures and non-regression testing, LuxTrust plans the implementation of the above-mentioned solutions by the end of January 2016 latest (update in the bug report 944783 will be made). II) Stop issuing certs with SHA-1 based signatures, and certs with "Netscape Cert Type" extension (especially in this CA hierarchy) SHA-1 based signatures: According to Mozilla’s policy regarding the use of SHA-1 algorithm (cf. https://blog.mozilla.org/security/2014/09/23/phasing-out-certificates-with-sha-1-based-signature-algorithms/), LuxTrust confirms that no SSL and code-signing certificate issued under the LTGRCA hierarchy use the SHA-1 hash algorithm, as described in the SSL and code signing profiles of the LTGRCA CP v1.22. Netscape Cert Type: LuxTrust confirms that the certificates issued under the LTGRCA hierarchy do not contain the “Netscape Cert Type” extension, as described in the certificate profiles of the LTGRCA CP v1.22. III) Update the CPS documents to respond to Ryan's comments === Certificate Profile === = Copyright = Similar to the issues highlighted with Certinomis, LuxTrust prohibits duplication or redistribution of the CA's CP or CPS documents. This is not strictly required for inclusion, however, as noted in Section 10 of [4], "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." 1) As mentioned in the sections “ Intellectual Property Rights” of the LTGRCA CP v1.22, the LTGRCA CPS v1.09 and the LTSSLCA CPS v1.3, LuxTrust confirms that the above-mentioned documents are disclosed and freely available and may be reproduced, stored in or introduced into a retrieval system, or transmitted, in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise) with prior written permission of LuxTrust S.A, thus in respect of the section 10 of Mozilla CA Certificate Inclusion Policy [4]. = basicConstraints = Rather than highlight an issue, I'd like to commend LuxTrust for ensuring that all of their subordinate CA certificate have a basicConstraint with a pathLen of 0 (as shown on Page 29, Section 3.2). This helps ensure that even in the event of software failure, no subscriber certificates capable of issuing certificates can be issued. 2) As mentioned in the descriptions of the subordinate CA’s profiles in the LTGRCA CP v1.22, LuxTrust confirms that all subordinate CAs under the LTGRCA hierarchy have the field basicConstraints with a pathLenConstraint of 0. = Names in non-SSL certificates = While the majority of the certificate profiles indicate a combination of names with a space character, several non-SSL types do not provide this proviso. Because these certificate profiles also lack an extendedKeyUsage X.509v3 extension, and because they have the necessary keyUsage bits, it may be possible to use these certificates as part of TLS servers with Mozilla applications. Mitigation for this is to ensure that no "domain-shaped" name can be issued for these types, and to specify this explicitly in the policies. For example, ensuring a space character is used as a joiner, as some of the profiles explicitly call out, is one way to do this. This applies to Page 73, Section 3.3.15, Page 76, Section 3.3.16, Page 78, Section 3.3.17, and Page 81, Section 3.3.18. Similarly, Page 83, Section 3.3.19 does not prohibit the commonName from being "domain shaped", as a result, may be used for TLS. 3) LuxTrust confirms that no “domain-shaped” common name can be issued for the profiles described in the sections 3.3.15, 3.3.16, 3.3.17, 3.3.18 and 3.3.19. LuxTrust added provisions in the LTGRCA CP v1.22 so that the “commonName” attributes for these profiles cannot be domain-shaped. - For the profiles described in sections 3.3.15, 3.3.16, 3.3.17 and 3.3.18, LuxTrust updated the value of the “CommonName” attribute:
Re: LuxTrust Root Inclusion Request
On 5/4/15 5:33 PM, Ryan Sleevi wrote: On Fri, April 24, 2015 4:58 pm, kwil...@mozilla.com wrote: Other than the concerns that have been raised about CRL and OCSP, are there any further questions or comments about this request from LuxTrust to include the "LuxTrust Global Root" root certificate, turn on the Websites and Code Signing trust bits, and enable EV treatment? Hi Kathleen, I've completed a review of the LuxTrust Global Root CA certificate profile [1], the Global Root CA CPS [2], and the LuxTrust SSL CA CPS [3]. Similar with Certinomis, I found nothing of serious concern, but do want to higlight several issues that may be worth discussion or consideration. I do think that the inclusion request should not proceed until the modifications to the revocation system have been completed. It is also somewhat concerning that this was not raised during audit, since it is incorporated into the appropriate ETSI requirements that LuxTrust was audited to. Thanks to all of you who contributed to this discussion about the request from LuxTrust to include the "LuxTrust Global Root" root certificate, turn on the Websites and Code Signing trust bits, and enable EV treatment. I am now closing this discussion, and I will track the following three action items in the bug. https://bugzilla.mozilla.org/show_bug.cgi?id=944783 1) Resolve the concerns that were raised about CRL and OCSP. Also resolve all errors listed here: https://certificate.revocationcheck.com/www.trustme.lu 2) Stop issuing certs with SHA-1 based signatures, and certs with "Netscape Cert Type" extension (especially in this CA hierarchy) 3) Update the CPS documents to respond to Ryan's comments. After I have confirmed completion of these action items, I will start a second round of discussion about this request. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: LuxTrust Root Inclusion Request
On Fri, April 24, 2015 4:58 pm, kwil...@mozilla.com wrote: > Other than the concerns that have been raised about CRL and OCSP, are > there any further questions or comments about this request from LuxTrust > to include the "LuxTrust Global Root" root certificate, turn on the > Websites and Code Signing trust bits, and enable EV treatment? Hi Kathleen, I've completed a review of the LuxTrust Global Root CA certificate profile [1], the Global Root CA CPS [2], and the LuxTrust SSL CA CPS [3]. Similar with Certinomis, I found nothing of serious concern, but do want to higlight several issues that may be worth discussion or consideration. I do think that the inclusion request should not proceed until the modifications to the revocation system have been completed. It is also somewhat concerning that this was not raised during audit, since it is incorporated into the appropriate ETSI requirements that LuxTrust was audited to. I have not examined the technical content of any of the certificates to ensure compliance with these policies. === Certificate Profile === = Copyright = Similar to the issues highlighted with Certinomis, LuxTrust prohibits duplication or redistribution of the CA's CP or CPS documents. This is not strictly required for inclusion, however, as noted in Section 10 of [4], "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." = basicConstraints = Rather than highlight an issue, I'd like to commend LuxTrust for ensuring that all of their subordinate CA certificate have a basicConstraint with a pathLen of 0 (as shown on Page 29, Section 3.2). This helps ensure that even in the event of software failure, no subscriber certificates capable of issuing certificates can be issued. = Names in non-SSL certificates = While the majority of the certificate profiles indicate a combination of names with a space character, several non-SSL types do not provide this proviso. Because these certificate profiles also lack an extendedKeyUsage X.509v3 extension, and because they have the necessary keyUsage bits, it may be possible to use these certificates as part of TLS servers with Mozilla applications. Mitigation for this is to ensure that no "domain-shaped" name can be issued for these types, and to specify this explicitly in the policies. For example, ensuring a space character is used as a joiner, as some of the profiles explicitly call out, is one way to do this. This applies to Page 73, Section 3.3.15, Page 76, Section 3.3.16, Page 78, Section 3.3.17, and Page 81, Section 3.3.18. Similarly, Page 83, Section 3.3.19 does not prohibit the commonName from being "domain shaped", as a result, may be used for TLS. = Names in SSL certificates = It's unclear why the significant duplication in Page 87, Section 3.3.20 for the dNSName subjectAltNames. It would seem sufficient to dictate the policies for validating the dNSName, however many instances occur. = Typos = Both Page 93, Section 3.3.21 and Page 99, Section 3.3.22 contain a typo of "streedAddress" rather than "streetAddress" === Global Root CA CPS === = Copyright = Similar to the above issues, Page 7 contains a somewhat restrictive copyright clause. = Cross-signing = Page 11 makes it clear that LuxTrust reserves the right to cross-sign other CAs. LuxTrust should be aware of Sections 8, 9, and 10 of [4]. Elsewhere in the policy, it seems clear they understand the obligation to disclose, but it's worth re-emphasizing that if LuxTrust does engage in a cross-signing engagement, they will ultimately be held responsible. = Trademarks = It looks like there's some confusion with respect to Page 28, Section 3.1.4 as to what this section is meant to contain. I would refer LuxTrust to the Certinomis discussion for an example section, as well as the issues that may arise. = Revocation Requests = Similar to Certinomis, Page 34, Section 4.9.2 contains some issues with respect to who can request revocation. The SSL CP seems to do better at addressing the needs for relying parties to be able to request revocation for certificates that fail to comply with LuxTrust's stated policies, and there may be area to improve this section. === SSL CA CPS === = Copyright = Already said this one twice :) = ETSI status = Page 19 notes an ongoing expectation of compliance with appropriate ETSI criteria, with an expected completion of March 2014. I believe this section needs to be updated, since that's quite some time ago? :) = Publication of Certificates / Certificate Transparency = Page 20, Section 2.3.1, Page 32, Section 4.4.2, and Page 32, Section 4.4.3 all list various claims that the issuance of certificates will not be publicized. However, as LuxTrust operates an EV-capable CA, if they wish to be recognized
Re: LuxTrust Root Inclusion Request
On Friday, April 10, 2015 at 12:16:41 AM UTC-7, LuxTrust CA wrote: > > We request to move forward with the public discussion while tracking the > correction of the abovementioned bug. Other than the concerns that have been raised about CRL and OCSP, are there any further questions or comments about this request from LuxTrust to include the "LuxTrust Global Root" root certificate, turn on the Websites and Code Signing trust bits, and enable EV treatment? Would you all be OK with tracking the action items to fix CRL and OCSP in the bug, and approving the request after those are shown to be resolved? The action item can include making sure that no more errors are shown here: http://certificate.revocationcheck.com/www.trustme.lu Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: LuxTrust Root Inclusion Request
On 03/19/2015 02:45 AM, Ryan Sleevi wrote: > On Thu, March 19, 2015 1:35 am, LuxTrust CA wrote: >> Regarding issue #2 : OCSP responds "good" to a non-issued certificate >> (serials and 00) (BR Section >> 13.2.6) : >> LuxTrust’s OCSP application currently does not support this feature >> (technical limitation). LuxTrust is currently analyzing the possibility of >> an alternative solution / technical improvements. >> Pending a technical alternative, LuxTrust would like to underline that the >> risks raised by the “good� response to a non-issue certificate are >> mitigated >> by compensatory controls: even if LuxTrust’s OCSP responder provides an >> inadequate “good� response, the certificate will not pass the step of >> validation of the CA information (trust anchor) because the certificate is >> not signed by LuxTrust’s CA (provided that the certificate validation >> check >> is compliant with RFC 5280, section 6.1 Basic path validation). > > This is not an accurate representation of the security risks. > > The Baseline Requirements incorporated this change in part due to the > compromise of Diginotar, in which the issuing CA was unable to account for > or present records of validly signed certificates. This failure, combined > with a failure to monitor its OCSP logs, allowed for the scope of the > compromise to be significantly underestimated. > > So the description of why this is not an issue is not correct, nor would > it be compliant with the Baseline Requirements. > > This has been a requirement of the CA/Browser Forum since 2013-08-01, or 1 > year and 7 months. This seems to have been ample time to evaluate > alternative solutions or technical improvements to comply with this > requirement, which itself predates LuxTrust's request for inclusion. > > This does seem to be an item that needs remedying. According to 7.3.6 of > ETSI TS 102 042 (which you have been audited to), Item h, PTC-BR > certificates must conform to the BRG Section 13.2, which establishes this > as a requirement in Section 13.2.5. > > So this is non-complying with the ETSI TS 102 042 criteria to which you've > been audited, in addition to the Mozilla Root Inclusion Policy > requirements of BRG conformance. I'm still seeing "good" responses to non-issued certificates. Does LuxTrust have an update on their progress in resolving this issue? Thanks, David ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: LuxTrust Root Inclusion Request
Le jeudi 19 mars 2015 09:36:35 UTC+1, LuxTrust CA a écrit : > With regards to the issues raised by Jesus F., LuxTrust proposes the > following answers : > Regarding issue #1: OCSP do not respond using GET method (BR section 13.2.2) > : > The feature is operational since 11th march 2015. We successfully made OCSP > requests using the GET method. It still doesn't work. Your OCSP responder doesn't accept properly URL-encoded requests: OCSP req -> Base64 (may contain '/', '+', and '=' chars) -> URL-encoded (changes those into '%2F', '%2B', and '%3D' respectively) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: LuxTrust Root Inclusion Request
On Thu, March 19, 2015 1:35 am, LuxTrust CA wrote: > Regarding issue #2 : OCSP responds "good" to a non-issued certificate > (serials and 00) (BR Section > 13.2.6) : > LuxTrustâs OCSP application currently does not support this feature > (technical limitation). LuxTrust is currently analyzing the possibility of > an alternative solution / technical improvements. > Pending a technical alternative, LuxTrust would like to underline that the > risks raised by the âgoodâ response to a non-issue certificate are > mitigated > by compensatory controls: even if LuxTrustâs OCSP responder provides an > inadequate âgoodâ response, the certificate will not pass the step of > validation of the CA information (trust anchor) because the certificate is > not signed by LuxTrustâs CA (provided that the certificate validation > check > is compliant with RFC 5280, section 6.1 Basic path validation). This is not an accurate representation of the security risks. The Baseline Requirements incorporated this change in part due to the compromise of Diginotar, in which the issuing CA was unable to account for or present records of validly signed certificates. This failure, combined with a failure to monitor its OCSP logs, allowed for the scope of the compromise to be significantly underestimated. So the description of why this is not an issue is not correct, nor would it be compliant with the Baseline Requirements. This has been a requirement of the CA/Browser Forum since 2013-08-01, or 1 year and 7 months. This seems to have been ample time to evaluate alternative solutions or technical improvements to comply with this requirement, which itself predates LuxTrust's request for inclusion. This does seem to be an item that needs remedying. According to 7.3.6 of ETSI TS 102 042 (which you have been audited to), Item h, PTC-BR certificates must conform to the BRG Section 13.2, which establishes this as a requirement in Section 13.2.5. So this is non-complying with the ETSI TS 102 042 criteria to which you've been audited, in addition to the Mozilla Root Inclusion Policy requirements of BRG conformance. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: LuxTrust Root Inclusion Request
On Thu, Mar 19, 2015 at 09:35:20AM +0100, LuxTrust CA wrote: > Regarding issue #2 : OCSP responds "good" to a non-issued certificate > (serials and 00) (BR Section > 13.2.6) : > LuxTrust’s OCSP application currently does not support this feature > (technical limitation). LuxTrust is currently analyzing the possibility of > an alternative solution / technical improvements. > Pending a technical alternative, LuxTrust would like to underline that the > risks raised by the “good” response to a non-issue certificate are mitigated > by compensatory controls: even if LuxTrust’s OCSP responder provides an > inadequate “good” response, the certificate will not pass the step of > validation of the CA information (trust anchor) because the certificate is > not signed by LuxTrust’s CA Unless, of course, the certificate *is* signed by an intermediate CA's private key which chains to the LuxTrust root. That is one of the reasons for requiring accuracy of OCSP responses -- to demonstrate that you have a record of every certificate that has been issued. One of the (many) problems with DigiNotar was that they didn't know what they'd issued. It would be nice if that didn't happen again. - Matt -- I was punching a text message into my phone yesterday and thought, "they need to make a phone that you can just talk into." -- Major Thomb ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: LuxTrust Root Inclusion Request
With regards to the issues raised by Jesus F., LuxTrust proposes the following answers : Regarding issue #1: OCSP do not respond using GET method (BR section 13.2.2) : The feature is operational since 11th march 2015. We successfully made OCSP requests using the GET method. Regarding issue #2 : OCSP responds "good" to a non-issued certificate (serials and 00) (BR Section 13.2.6) : LuxTrust’s OCSP application currently does not support this feature (technical limitation). LuxTrust is currently analyzing the possibility of an alternative solution / technical improvements. Pending a technical alternative, LuxTrust would like to underline that the risks raised by the “good” response to a non-issue certificate are mitigated by compensatory controls: even if LuxTrust’s OCSP responder provides an inadequate “good” response, the certificate will not pass the step of validation of the CA information (trust anchor) because the certificate is not signed by LuxTrust’s CA (provided that the certificate validation check is compliant with RFC 5280, section 6.1 Basic path validation). ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: LuxTrust Root Inclusion Request
After some quick test of the OCSP Service I detect the following issues related to the conformity with CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates (hereinafter BR) as required by section 12 of Mozilla CA Certificate Inclusion Policy v2.2: Test site: https://www.trustme.lu/ Ocsp: http://ssl.ocsp.luxtrust.lu #1: OCSP do not respond using GET method. (BR section 13.2.2) #2: OCSP respond "good" to a non-issued certifcate (serials and 00) (BR Section 13.2.6) Cheers, J El jueves, 12 de febrero de 2015, 22:27:37 (UTC+1), David Keeler escribió: > On 02/11/2015 04:57 PM, Kathleen Wilson wrote: > > LuxTrust has applied to include the "LuxTrust Global Root" root > > certificate, turn on the Websites and Code Signing trust bits, and > > enable EV treatment. > > ... > > > * Potentially Problematic Practices > > (http://wiki.mozilla.org/CA:Problematic_Practices) > > ** None Noted. > > In the certificate transparency log, I've noted a few problems with > certificates as currently issued by "C=LU, O=LuxTrust S.A., CN=LuxTrust > Qualified CA". > > * They all appear to be signed with sha1WithRSAEncryption. This > algorithm is deprecated - sha256WithRSAEncryption should be used instead. > * Many do not have the Subject Alternative Names extension and instead > use the Subject Common Name field to identify a DNS name or IP address. > This behavior is also deprecated. > * At least one certificate was issued for a 1024 bit RSA key. The > minimum should be 2048 bits for RSA. > * The "Netscape Cert Type" extension appears to be common. This is not > part of rfc 5280 and shouldn't be used. > > Here are some example certificates that illustrate these issues: > > -BEGIN CERTIFICATE- > MIIFjDCCBHSgAwIBAgIDBmRtMA0GCSqGSIb3DQEBBQUAMEUxCzAJBgNVBAYTAkxV > MRYwFAYDVQQKEw1MdXhUcnVzdCBTLkEuMR4wHAYDVQQDExVMdXhUcnVzdCBRdWFs > aWZpZWQgQ0EwHhcNMTUwMTMwMDk0ODUwWhcNMTYwMTMwMDk0ODUwWjCBkDELMAkG > A1UEBhMCTFUxEzARBgNVBAgTCkx1eGVtYm91cmcxEzARBgNVBAcTCkx1eGVtYm91 > cmcxITAfBgNVBAoTGEFyY2hldmVjaGUgZGUgTHV4ZW1ib3VyZzEWMBQGA1UEAxMN > d3d3LmNhdGhvbC5sdTEcMBoGCSqGSIb3DQEJARYNc2NwQGNhdGhvbC5sdTCCASIw > DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMpuN3DMSGzZpom8PBa3TwnJKUXd > V2muUkKhpcy2wOZuksI+Aka0JQxn9YujP9fhkHsWug+1C+RVKb4DfljRwgc4Kfbw > 5Bejtmw3DsrMKQxDZPljuf7qXnW7S7K3cCCtwJJcyJbzoPhnaJF7grVXgaduLAP8 > WSsewkqMAj32dFOo1dR2G7Jtlg1Kb5h1DtGthrPumH1BIz9INQ9ewX+/f2cYRLTn > Ql1fwCToNrzwVaL4oEPeWjlVvzCXi2KrmNDSnsCcU1lnuBn3pjhV9asgTbTirPyc > zp3eXAzF7t+84qfv7uqLTj61QY2wvPA7QEOw7o5zm+RFReAuUQzKRHXUiNMCAwEA > AaOCAjcwggIzMAwGA1UdEwEB/wQCMAAwYAYIKwYBBQUHAQEEVDBSMCMGCCsGAQUF > BzABhhdodHRwOi8vb2NzcC5sdXh0cnVzdC5sdTArBggrBgEFBQcwAoYfaHR0cDov > L2NhLmx1eHRydXN0Lmx1L0xUUUNBLmNydDCCAQAGA1UdIASB+DCB9TCB6AYIK4Er > AQECBgEwgdswga0GCCsGAQUFBwICMIGgGoGdTHV4VHJ1c3QgU2VydmVyIENlcnRp > ZmljYXRlLiBOb3Qgc3VwcG9ydGVkIGJ5IFNTQ0QsIEtleSBHZW5lcmF0aW9uIGJ5 > IFN1YnNjcmliZXIuIEdUQywgQ1AgYW5kIENQUyBvbiBodHRwOi8vcmVwb3NpdG9y > eS5sdXh0cnVzdC5sdS4gU2lnbmVkIGJ5IGEgUXVhbGlmaWVkIENBLjApBggrBgEF > BQcCARYdaHR0cDovL3JlcG9zaXRvcnkubHV4dHJ1c3QubHUwCAYGBACPegEDMBEG > CWCGSAGG+EIBAQQEAwIF4DAOBgNVHQ8BAf8EBAMCBLAwJwYDVR0lBCAwHgYIKwYB > BQUHAwEGCCsGAQUFBwMCBggrBgEFBQcDBDAfBgNVHSMEGDAWgBSNkKMH3RoTd5lM > kqtNQ94/zSlkBTAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLmx1eHRydXN0 > Lmx1L0xUUUNBLmNybDAdBgNVHQ4EFgQU3T0x0fyh2toW9B/kYF+LjOGcMYYwDQYJ > KoZIhvcNAQEFBQADggEBALJFjVrAuSU3pZuCGQ7sVM8hDVfDrt9slpziu2yQoBKg > VKblu3yK4+Rs8DgcNvPB38fOKRYU1MZBhLSUMkt90jfUJJXiMHxxZt3Av5el4mNX > VdYw57hcoyHbBHWqjKgIGCKN8blAOk08VD7s614wNA0DChXL+SqnrhkKPRlTmVa/ > /T9iGqA2agX6RNTdCt2E0DalAUcFM6mRIhMIS+xyuB29wdZce+q8N5zFW6mZQi7W > WYlrZvYBKQdWhaeZMaQAuAo11gtG8p0QtrIZmR/pBhzBiOfVVMh6Co7M0u3xI1T0 > RW/C6hxMRAomcYKW4OpUtrr2ImQUmQgustSK0uhqdMM= > -END CERTIFICATE- > > -BEGIN CERTIFICATE- > MIIE3zCCA8egAwIBAgIDBiXvMA0GCSqGSIb3DQEBBQUAMEUxCzAJBgNVBAYTAkxV > MRYwFAYDVQQKEw1MdXhUcnVzdCBTLkEuMR4wHAYDVQQDExVMdXhUcnVzdCBRdWFs > aWZpZWQgQ0EwHhcNMTQwNjI1MTQxODMxWhcNMTYxMDE4MTA0MDM0WjB8MQswCQYD > VQQGEwJMVTETMBEGA1UECBMKTHV4ZW1ib3VyZzERMA8GA1UEBxMIQ2FwZWxsZW4x > FjAUBgNVBAoTDUx1eFRydXN0IFMuQS4xFTATBgNVBAsTDEFwcGxpY2F0aW9uczEW > MBQGA1UEAxMNMTk0LjM2LjIyNy42NjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC > gYEApdjys8GcCORTGqltPf7cvXTsD/PjSjHFvVyYWQclgDHjnOVVXHAZFMCE76MD > 76Er3Egfg5vFQYFh8NHbNQKlUCc3Ljn6S/i1FhYBV4tYvqaGbX8z9Xyh+V7sOUL4 > poqKQ/LPoZ7smpVIXlAHHSmWiWPHTY9HHaEBpWLmgJsSad0CAwEAAaOCAiMwggIf > MAwGA1UdEwEB/wQCMAAwYAYIKwYBBQUHAQEEVDBSMCMGCCsGAQUFBzABhhdodHRw > Oi8vb2NzcC5sdXh0cnVzdC5sdTArBggrBgEFBQcwAoYfaHR0cDovL2NhLmx1eHRy > dXN0Lmx1L0xUUUNBLmNydDCCAQAGA1UdIASB+DCB9TCB6AYIK4ErAQECBgEwgdsw > ga0GCCsGAQUFBwICMIGgGoGdTHV4VHJ1c3QgU2VydmVyIENlcnRpZmljYXRlLiBO > b3Qgc3VwcG9ydGVkIGJ5IFNTQ0QsIEtleSBHZW5lcmF0aW9uIGJ5IFN1YnNjcmli > ZXIuIEdUQywgQ1AgYW5kIENQUyBvbiBodHRwOi8vcmVwb3NpdG9yeS5sdXh0cnVz > dC5sdS4gU2lnbmVkIGJ5IGEgUXVhbGlmaWVkIENBLjApBggrBgEFBQcCARYdaHR0 > cDovL3JlcG9zaXRvcnkubHV4dHJ1c3QubHUwCAYGBACPegEDMBEGCWCGSAGG+EIB
Re: LuxTrust Root Inclusion Request
For clarification purposes and as described in the bug report 1060863 (see https://bugzilla.mozilla.org/show_bug.cgi?id=1060863), LuxTrust would like to mention that the Root CA for which inclusion in Mozilla’s trust store is requested is LuxTrust Global Root CA. The topics raised by David Keeler concern LuxTrust Qualified CA and its child certificates which are not related to LuxTrust Global Root CA. Nevertheless, we provide feedback with regards to the second certificate which is given as an example with a 1024 bit RSA key length (serial number 0625ef): this certificate is revoked since 18th December 2014, as referred in the LuxTrust Qualified CA CRL available on http://crl.luxtrust.lu/LTQCA.crl and as committed in the bug report 1060863. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: LuxTrust Root Inclusion Request
For clarification purposes and as described in the bug report 1060863 (see https://bugzilla.mozilla.org/show_bug.cgi?id=1060863), LuxTrust would like to mention that the Root CA for which inclusion in Mozilla’s trust store is requested is LuxTrust Global Root CA. The topics raised by David Keeler concern LuxTrust Qualified CA and its child certificates which are not related to LuxTrust Global Root CA. Nevertheless, we provide feedback with regards to the second certificate which is given as an example with a 1024 bit RSA key length (serial number 0625ef): this certificate is revoked since 18th December 2014, as referred in the LuxTrust Qualified CA CRL available on http://crl.luxtrust.lu/LTQCA.crl and as committed in the bug report 1060863. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: LuxTrust Root Inclusion Request
On 02/11/2015 04:57 PM, Kathleen Wilson wrote: > LuxTrust has applied to include the "LuxTrust Global Root" root > certificate, turn on the Websites and Code Signing trust bits, and > enable EV treatment. ... > * Potentially Problematic Practices > (http://wiki.mozilla.org/CA:Problematic_Practices) > ** None Noted. In the certificate transparency log, I've noted a few problems with certificates as currently issued by "C=LU, O=LuxTrust S.A., CN=LuxTrust Qualified CA". * They all appear to be signed with sha1WithRSAEncryption. This algorithm is deprecated - sha256WithRSAEncryption should be used instead. * Many do not have the Subject Alternative Names extension and instead use the Subject Common Name field to identify a DNS name or IP address. This behavior is also deprecated. * At least one certificate was issued for a 1024 bit RSA key. The minimum should be 2048 bits for RSA. * The "Netscape Cert Type" extension appears to be common. This is not part of rfc 5280 and shouldn't be used. Here are some example certificates that illustrate these issues: -BEGIN CERTIFICATE- MIIFjDCCBHSgAwIBAgIDBmRtMA0GCSqGSIb3DQEBBQUAMEUxCzAJBgNVBAYTAkxV MRYwFAYDVQQKEw1MdXhUcnVzdCBTLkEuMR4wHAYDVQQDExVMdXhUcnVzdCBRdWFs aWZpZWQgQ0EwHhcNMTUwMTMwMDk0ODUwWhcNMTYwMTMwMDk0ODUwWjCBkDELMAkG A1UEBhMCTFUxEzARBgNVBAgTCkx1eGVtYm91cmcxEzARBgNVBAcTCkx1eGVtYm91 cmcxITAfBgNVBAoTGEFyY2hldmVjaGUgZGUgTHV4ZW1ib3VyZzEWMBQGA1UEAxMN d3d3LmNhdGhvbC5sdTEcMBoGCSqGSIb3DQEJARYNc2NwQGNhdGhvbC5sdTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMpuN3DMSGzZpom8PBa3TwnJKUXd V2muUkKhpcy2wOZuksI+Aka0JQxn9YujP9fhkHsWug+1C+RVKb4DfljRwgc4Kfbw 5Bejtmw3DsrMKQxDZPljuf7qXnW7S7K3cCCtwJJcyJbzoPhnaJF7grVXgaduLAP8 WSsewkqMAj32dFOo1dR2G7Jtlg1Kb5h1DtGthrPumH1BIz9INQ9ewX+/f2cYRLTn Ql1fwCToNrzwVaL4oEPeWjlVvzCXi2KrmNDSnsCcU1lnuBn3pjhV9asgTbTirPyc zp3eXAzF7t+84qfv7uqLTj61QY2wvPA7QEOw7o5zm+RFReAuUQzKRHXUiNMCAwEA AaOCAjcwggIzMAwGA1UdEwEB/wQCMAAwYAYIKwYBBQUHAQEEVDBSMCMGCCsGAQUF BzABhhdodHRwOi8vb2NzcC5sdXh0cnVzdC5sdTArBggrBgEFBQcwAoYfaHR0cDov L2NhLmx1eHRydXN0Lmx1L0xUUUNBLmNydDCCAQAGA1UdIASB+DCB9TCB6AYIK4Er AQECBgEwgdswga0GCCsGAQUFBwICMIGgGoGdTHV4VHJ1c3QgU2VydmVyIENlcnRp ZmljYXRlLiBOb3Qgc3VwcG9ydGVkIGJ5IFNTQ0QsIEtleSBHZW5lcmF0aW9uIGJ5 IFN1YnNjcmliZXIuIEdUQywgQ1AgYW5kIENQUyBvbiBodHRwOi8vcmVwb3NpdG9y eS5sdXh0cnVzdC5sdS4gU2lnbmVkIGJ5IGEgUXVhbGlmaWVkIENBLjApBggrBgEF BQcCARYdaHR0cDovL3JlcG9zaXRvcnkubHV4dHJ1c3QubHUwCAYGBACPegEDMBEG CWCGSAGG+EIBAQQEAwIF4DAOBgNVHQ8BAf8EBAMCBLAwJwYDVR0lBCAwHgYIKwYB BQUHAwEGCCsGAQUFBwMCBggrBgEFBQcDBDAfBgNVHSMEGDAWgBSNkKMH3RoTd5lM kqtNQ94/zSlkBTAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLmx1eHRydXN0 Lmx1L0xUUUNBLmNybDAdBgNVHQ4EFgQU3T0x0fyh2toW9B/kYF+LjOGcMYYwDQYJ KoZIhvcNAQEFBQADggEBALJFjVrAuSU3pZuCGQ7sVM8hDVfDrt9slpziu2yQoBKg VKblu3yK4+Rs8DgcNvPB38fOKRYU1MZBhLSUMkt90jfUJJXiMHxxZt3Av5el4mNX VdYw57hcoyHbBHWqjKgIGCKN8blAOk08VD7s614wNA0DChXL+SqnrhkKPRlTmVa/ /T9iGqA2agX6RNTdCt2E0DalAUcFM6mRIhMIS+xyuB29wdZce+q8N5zFW6mZQi7W WYlrZvYBKQdWhaeZMaQAuAo11gtG8p0QtrIZmR/pBhzBiOfVVMh6Co7M0u3xI1T0 RW/C6hxMRAomcYKW4OpUtrr2ImQUmQgustSK0uhqdMM= -END CERTIFICATE- -BEGIN CERTIFICATE- MIIE3zCCA8egAwIBAgIDBiXvMA0GCSqGSIb3DQEBBQUAMEUxCzAJBgNVBAYTAkxV MRYwFAYDVQQKEw1MdXhUcnVzdCBTLkEuMR4wHAYDVQQDExVMdXhUcnVzdCBRdWFs aWZpZWQgQ0EwHhcNMTQwNjI1MTQxODMxWhcNMTYxMDE4MTA0MDM0WjB8MQswCQYD VQQGEwJMVTETMBEGA1UECBMKTHV4ZW1ib3VyZzERMA8GA1UEBxMIQ2FwZWxsZW4x FjAUBgNVBAoTDUx1eFRydXN0IFMuQS4xFTATBgNVBAsTDEFwcGxpY2F0aW9uczEW MBQGA1UEAxMNMTk0LjM2LjIyNy42NjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEApdjys8GcCORTGqltPf7cvXTsD/PjSjHFvVyYWQclgDHjnOVVXHAZFMCE76MD 76Er3Egfg5vFQYFh8NHbNQKlUCc3Ljn6S/i1FhYBV4tYvqaGbX8z9Xyh+V7sOUL4 poqKQ/LPoZ7smpVIXlAHHSmWiWPHTY9HHaEBpWLmgJsSad0CAwEAAaOCAiMwggIf MAwGA1UdEwEB/wQCMAAwYAYIKwYBBQUHAQEEVDBSMCMGCCsGAQUFBzABhhdodHRw Oi8vb2NzcC5sdXh0cnVzdC5sdTArBggrBgEFBQcwAoYfaHR0cDovL2NhLmx1eHRy dXN0Lmx1L0xUUUNBLmNydDCCAQAGA1UdIASB+DCB9TCB6AYIK4ErAQECBgEwgdsw ga0GCCsGAQUFBwICMIGgGoGdTHV4VHJ1c3QgU2VydmVyIENlcnRpZmljYXRlLiBO b3Qgc3VwcG9ydGVkIGJ5IFNTQ0QsIEtleSBHZW5lcmF0aW9uIGJ5IFN1YnNjcmli ZXIuIEdUQywgQ1AgYW5kIENQUyBvbiBodHRwOi8vcmVwb3NpdG9yeS5sdXh0cnVz dC5sdS4gU2lnbmVkIGJ5IGEgUXVhbGlmaWVkIENBLjApBggrBgEFBQcCARYdaHR0 cDovL3JlcG9zaXRvcnkubHV4dHJ1c3QubHUwCAYGBACPegEDMBEGCWCGSAGG+EIB AQQEAwIF4DAOBgNVHQ8BAf8EBAMCBLAwEwYDVR0lBAwwCgYIKwYBBQUHAwEwHwYD VR0jBBgwFoAUjZCjB90aE3eZTJKrTUPeP80pZAUwMQYDVR0fBCowKDAmoCSgIoYg aHR0cDovL2NybC5sdXh0cnVzdC5sdS9MVFFDQS5jcmwwHQYDVR0OBBYEFC6CkFWd BU3pDGMs/bVZTOYhv3nDMA0GCSqGSIb3DQEBBQUAA4IBAQBAXcMLB8O63dMT+AvY LzkeCWh16MjoILjDJnP7wwHGZ/GzDFCF1EYk/OIaWd3bGHTbT8hg/00EGe+zp2o+ mW60A+lebl7b5+vSboSzR4miUk81FdgbxbX8BH7JNirJvVGUilHYv745VB90ZvQD TutJeI+KigtHblptG4WkBddLNshOa+TvS/i05aQsZJL32PWTOnaj93/0ZRVlOTub ejKTHwSGXsDxeIVF0k1+gzhJ5HbHvCEQ00MZ1gOsW6Ea7ONe0cJAFnBP8j3rL654 uTH98HONHId/KBIUlDPD4sl6mbk5pAqCz+iLsvXS2VB76E1zjYTt/PBBpu5+EKb8 Myum -END CERTIFICATE- Cheers, David ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
LuxTrust Root Inclusion Request
LuxTrust has applied to include the "LuxTrust Global Root" root certificate, turn on the Websites and Code Signing trust bits, and enable EV treatment. LuxTrust S.A. provides PKI services for the whole economic marketplace in Luxembourg, for both private and public organisations. LuxTrust S.A. provides PKI services to the Financial Sector, and therefore is under regulation of the Luxembourg's financial regulator: CSSF (Commission de Surveillance du Secteur Financier). LuxTrust aims to provide its subscribers with certificates for HTTP over SSL, code signing, and communications within banking systems. End-entity certificates are issued to: - Natural persons, in compliance with EU directive 1999/93/EC - Organisations (incl. SSL and code signing). LuxTrust's previous Root CA was cross signed by Baltimore CyberTrust Root CA. In order for LuxTrust to provide a National Certification Authority service and in accordance with the Grand Duchy of Luxembourg's strategy, LuxTrust decided to generate and deploy its own trusted Root CA (LuxTrust Global Root CA). The request is documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=944783 And in the pending certificates list: http://www.mozilla.org/projects/security/certs/pending/ Summary of Information Gathered and Verified: https://bugzilla.mozilla.org/attachment.cgi?id=8559339 Noteworthy points: * The primary documents are in French and English. Document Repository: https://repository.luxtrust.lu CP: https://www.luxtrust.lu/upload/data/repository/LuxTrust%20Global%20Root%20CA%20-%20Certificate%20Profiles%20v1.20.pdf CPS: https://www.luxtrust.lu/upload/data/repository/LuxTrust_Global_Root%20CA_Certification_Practice_Statements_v1_08.pdf Qualified Certs CPS: https://www.luxtrust.lu/upload/data/repository/LuxTrust_Global_Qualified_CA_Certification_Practice_Statements_v1_06.pdf SSL CPS: https://www.luxtrust.lu/upload/data/repository/LuxTrust%20SSL%20CA%20CPS%20v1.2.pdf * CA Hierarchy: LuxTrust Global Root CA signs internally-operated intermediate certificates which sign end-entity certificates. The current subCAs are: LuxTrust Global Qualified CA, LuxTrust SSL CA, and LuxTrust TSA CA. * This request is to turn on the Websites and Code Signing trust bits and enable EV treatment. ** SSL CPS section 3.2.2: The rules concerning the identification of the Subscriber's organisation shall be compliant with the legal rules applied to naming and identification of organisation in the Grand-Duchy of Luxembourg. RAs operating under the LuxTrust SSL CA shall perform a verification of any organizational identities that are submitted by an Applicant or Subscriber. The following documents are required for the identification of Subscriber’s organisation (legal person) and/or to validate the relationship of a physical person with a legal person: 1. Recent constitutive act, or recent extract of the commercial register (or the foreign equivalent for foreign companies registered under foreign law; 2. A recent official document or a recent original and certified mandate stating the split of responsibilities or disposition powers within the organs of the legal person (board of directors, delegated administrator, CEO, manager, etc.); 3. When the legal person runs financial sector activities involving third party funds management, the copy of the required authorisation or the mention that such authorisation is not required; 4. A copy of the identity evidence (identity card, passport or Luxembourg residency card) of one of the physical persons who is a legal representative of the legal person 5. The information about their legal address, civil state, and profession; 6. In case a company established in a non-Luxembourg jurisdiction is found as founder or administrator or signatory in the LuxTrust registration process, LuxTrust S.A. reserves right to ask for constitutive documents of this company (points 1 & 2 above), the declaration of the commercial beneficiary and the origin of the funds of the company, as well as an explanatory description of structure of the proposed company; 7. In case the relationship of a physical person with a legal person is to be validated and certified in the Certificate, the person identified in (4) shall sign the appropriate guarantee as provided in the applicable Certificate application form (Purchase Order). In the particular case of Object signing Certificates, RAs operating under the LuxTrust SSL CA shall verify the subscriber's identity and authority, and the organization’s identity and existence. In the particular case of SSL, RAs operating under the LuxTrust SSL CA shall determine whether the domain referenced in the SSL Certificate application is owned and controlled by the subscriber. LuxTrust validates that the Subscriber has the right to control the domain names using the following verification procedures: [1] Communicating with the technical contact information prov
