info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
LuxTrust Root Inclusion Request
857 views
Skip to first unread message
Kathleen Wilson
Feb 11, 2015, 7:58:14 PM2/11/15
to mozilla-dev-s...@lists.mozilla.org
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 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.
In the particular case of EV SSL Certificates, RAs operating under the
LuxTrust SSL CA shall determine whether the organizational identity,
legal existence, physical existence, operational existence, and domain
name provided with a LuxTrust EV SSL Certificate Application are
consistent with the requirements set forth in the EV Guidelines [10]
published by the CA/Browser Forum. The information and sources used for
the verification of LuxTrust EV SSL Certificate Applications may vary
depending on the jurisdiction of the Applicant or Subscriber.
In addition, for EV SSL Certificates, for organisations registered for
less than 3 years, a document from a regulated financial institution
proving the existence of a current account is also required for the
identification of the organisation.
Moreover, LuxTrust does not issue certificates for private IP addresses
or internal domains.
* EV Policy OID: 1.3.171.1.1.10.5.2
* Root Cert URL: https://www.luxtrust.lu/downloads/root/LTGRCA_der.cer
* Test Site: https://www.trustme.lu/
* CRL
http://crl.luxtrust.lu
http://crl.luxtrust.lu/LTSSLCA4.crl
http://crl.luxtrust.lu/LTGRCA.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
* Audit: Annual audits are performed by LSTI, according to the ETSI TS
102 042 v2.4.1 criteria.
http://www.lsti-certification.fr/images/fichiers/11085.pdf
* Potentially Problematic Practices
(http://wiki.mozilla.org/CA:Problematic_Practices)
** None Noted.
This begins the discussion of 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. At the conclusion of this
discussion I will provide a summary of issues noted and action items. If
there are outstanding issues, then an additional discussion may be
needed as follow-up. If there are no outstanding issues, then I will
recommend approval of this request in the bug.
Kathleen
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 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.
In the particular case of EV SSL Certificates, RAs operating under the
LuxTrust SSL CA shall determine whether the organizational identity,
legal existence, physical existence, operational existence, and domain
name provided with a LuxTrust EV SSL Certificate Application are
consistent with the requirements set forth in the EV Guidelines [10]
published by the CA/Browser Forum. The information and sources used for
the verification of LuxTrust EV SSL Certificate Applications may vary
depending on the jurisdiction of the Applicant or Subscriber.
In addition, for EV SSL Certificates, for organisations registered for
less than 3 years, a document from a regulated financial institution
proving the existence of a current account is also required for the
identification of the organisation.
Moreover, LuxTrust does not issue certificates for private IP addresses
or internal domains.
* EV Policy OID: 1.3.171.1.1.10.5.2
* Root Cert URL: https://www.luxtrust.lu/downloads/root/LTGRCA_der.cer
* Test Site: https://www.trustme.lu/
* CRL
http://crl.luxtrust.lu
http://crl.luxtrust.lu/LTSSLCA4.crl
http://crl.luxtrust.lu/LTGRCA.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
* Audit: Annual audits are performed by LSTI, according to the ETSI TS
102 042 v2.4.1 criteria.
http://www.lsti-certification.fr/images/fichiers/11085.pdf
* Potentially Problematic Practices
(http://wiki.mozilla.org/CA:Problematic_Practices)
** None Noted.
This begins the discussion of 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. At the conclusion of this
discussion I will provide a summary of issues noted and action items. If
there are outstanding issues, then an additional discussion may be
needed as follow-up. If there are no outstanding issues, then I will
recommend approval of this request in the bug.
Kathleen
David Keeler
Feb 12, 2015, 4:27:37 PM2/12/15
to dev-secur...@lists.mozilla.org
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.
...
> 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.
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
LuxTrust CA
Feb 26, 2015, 7:51:19 AM2/26/15
to mozilla-dev-s...@lists.mozilla.org
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.
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.
LuxTrust CA
Feb 26, 2015, 7:51:44 AM2/26/15
to mozilla-dev-s...@lists.mozilla.org
Jesus F
Feb 26, 2015, 9:58:02 AM2/26/15
to mozilla-dev-s...@lists.mozilla.org
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 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF and 00) (BR Section 13.2.6)
Cheers,
J
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 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF and 00) (BR Section 13.2.6)
Cheers,
J
LuxTrust CA
Mar 19, 2015, 4:36:35 AM3/19/15
to mozilla-dev-s...@lists.mozilla.org
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
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).
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 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 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).
Matt Palmer
Mar 19, 2015, 5:31:21 AM3/19/15
to dev-secur...@lists.mozilla.org
On Thu, Mar 19, 2015 at 09:35:20AM +0100, LuxTrust CA wrote:
> Regarding issue #2 : OCSP responds "good" to a non-issued certificate
> Regarding issue #2 : OCSP responds "good" to a non-issued certificate
> (serials FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 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
> 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
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
Ryan Sleevi
Mar 19, 2015, 5:47:06 AM3/19/15
to LuxTrust CA, mozilla-dev-s...@lists.mozilla.org
On Thu, March 19, 2015 1:35 am, LuxTrust CA wrote:
> Regarding issue #2 : OCSP responds "good" to a non-issued certificate
> Regarding issue #2 : OCSP responds "good" to a non-issued certificate
> (serials FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 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
> an alternative solution / technical improvements.
> Pending a technical alternative, LuxTrust would like to underline that the
> 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.
> is compliant with RFC 5280, section 6.1 Basic path validation).
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.
Erwann Abalea
Mar 19, 2015, 2:42:48 PM3/19/15
to mozilla-dev-s...@lists.mozilla.org
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:
> 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.
OCSP req
-> Base64 (may contain '/', '+', and '=' chars)
-> URL-encoded (changes those into '%2F', '%2B', and '%3D' respectively)
David Keeler
Mar 31, 2015, 1:15:55 PM3/31/15
to dev-secur...@lists.mozilla.org, luxtr...@gmail.com
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
> On Thu, March 19, 2015 1:35 am, LuxTrust CA wrote:
>> Regarding issue #2 : OCSP responds "good" to a non-issued certificate
>> (serials FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF and 00) (BR Section
LuxTrust have an update on their progress in resolving this issue?
Thanks,
David
LuxTrust CA
Apr 10, 2015, 3:16:41 AM4/10/15
to mozilla-dev-s...@lists.mozilla.org
With regards to the issues raised by Matt Palmer and Ryan Sleevi, please
allow us to clarify some aspects :
For certificates signed by intermediate CAs which chain to LuxTrust Global
Root CA, LuxTrust’s OCSP responder provides accurate responses :
- “good” for valid certificates
- “revoked” for revoked certificates.
The inadequate “good” response only concerns certificates which are not
issued by CAs under LuxTrust Global Root CA chain. As mentioned, this topic
is under review and treatment.
In addition, regarding the other failures you reminded, LuxTrust implemented
several security controls on its CA servers, i.e. LuxTrust Global Root CA
(offline server) and LuxTrust SSL CA (online server) in order to prevent
compromises as the ones you mentioned :
1) the operations performed on the CA servers are logged
2) the integrity of the logging processes and the configuration changes
on these servers are monitored
The controls environment implemented by LuxTrust, allows to account for the
tests which also came to the results that the OCSP responder application
does not support URL-encoded requests.
LuxTrust assessed this situation and to correct the bug, the application
needs to be upgraded. We have immediately taken the measures and plan the
upgrade by end of May 2015 latest.
We request to move forward with the public discussion while tracking the
correction of the abovementioned bug.
allow us to clarify some aspects :
For certificates signed by intermediate CAs which chain to LuxTrust Global
Root CA, LuxTrust’s OCSP responder provides accurate responses :
- “good” for valid certificates
- “revoked” for revoked certificates.
The inadequate “good” response only concerns certificates which are not
issued by CAs under LuxTrust Global Root CA chain. As mentioned, this topic
is under review and treatment.
In addition, regarding the other failures you reminded, LuxTrust implemented
several security controls on its CA servers, i.e. LuxTrust Global Root CA
(offline server) and LuxTrust SSL CA (online server) in order to prevent
compromises as the ones you mentioned :
1) the operations performed on the CA servers are logged
2) the integrity of the logging processes and the configuration changes
on these servers are monitored
The controls environment implemented by LuxTrust, allows to account for the
records of validly signed certificates.
Following the issues raised by Erwann Abalea, we have proceeded to further
tests which also came to the results that the OCSP responder application
does not support URL-encoded requests.
LuxTrust assessed this situation and to correct the bug, the application
needs to be upgraded. We have immediately taken the measures and plan the
upgrade by end of May 2015 latest.
We request to move forward with the public discussion while tracking the
correction of the abovementioned bug.
kwi...@mozilla.com
Apr 24, 2015, 7:58:20 PM4/24/15
to mozilla-dev-s...@lists.mozilla.org
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?
>
> We request to move forward with the public discussion while tracking the
> correction of the abovementioned bug.
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
Ryan Sleevi
May 4, 2015, 8:34:02 PM5/4/15
to kwi...@mozilla.com, mozilla-dev-s...@lists.mozilla.org
On Fri, April 24, 2015 4:58 pm, kwi...@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
> 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 as such in browsers such as Google Chrome, they will need
to be publicizing their certificates in an appropriate Certificate
Transparency Log.
This creates a potential issue for policy non-compliance, so I raise it
now as a potential issue for LuxTrust to examine when examining their
policies as a result of this discussion.
===== Trademarks =====
It appears that Page 22, Section 3.1.6 suffers from the same confusion
with respect to trademarks in the names of certificates.
===== Revocation Requirements =====
To begin, I'd like to applaud LuxTrust for making it clear the process for
requesting revocation in Page 35, Section 4.9.2. In particular, providing
appropriate URLs and contact information for parties to request
revocation.
That said, it appears this section is incomplete with respect to non-EV
certificates and the ability of relying parties to notify LuxTrust of
potential non-conformance to the Baseline Requirements or to LuxTrust's
CPS. It appears this section needs further work to describe the process
and provide appropriate information for such parties.
[1]
https://www.luxtrust.lu/upload/data/repository/LuxTrust%20Global%20Root%20CA%20-%20Certificate%20Profiles%20v1.20.pdf
[2]
https://www.luxtrust.lu/upload/data/repository/LuxTrust_Global_Root%20CA_Certification_Practice_Statements_v1_08.pdf
[3]
https://www.luxtrust.lu/upload/data/repository/LuxTrust%20SSL%20CA%20CPS%20v1.2.pdf
[4]
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
Kathleen Wilson
Aug 20, 2015, 1:05:30 PM8/20/15
to mozilla-dev-s...@lists.mozilla.org
On 5/4/15 5:33 PM, Ryan Sleevi wrote:
> On Fri, April 24, 2015 4:58 pm, kwi...@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
> On Fri, April 24, 2015 4:58 pm, kwi...@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.
>
request from LuxTrust to include the "LuxTrust Global Root" root
certificate, turn on the Websites and Code Signing trust bits, and
enable EV treatment.
certificate, turn on the Websites and Code Signing trust bits, and
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
LuxTrust CA
Dec 8, 2015, 2:24:19 PM12/8/15
to Kathleen Wilson, mozilla-dev-s...@lists.mozilla.org
Please find below our answer to the three actions items:
I) Resolve the concerns that were raised about CRL and OCSP. Also
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
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:
“Concatenation of given name(s) and surname(s) separated by the space
character”.
- For the profile described in section 3.3.19, LuxTrust updated the
value of the “CommonName” attribute: “Name commonly used by the subject
to represent itself as stated in ETSI TS 119 412-3, the name should not
be domain-shaped”.
===== 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.
4) LuxTrust chose on purpose to duplicate the instances in the column
“Value” of the fields “SubjAltName-dNSName” and “SubjAltName-URL”, the
objective being to reflect that up to 10 values are accepted for these
fields.
===== Typos =====
Both Page 93, Section 3.3.21 and Page 99, Section 3.3.22 contain a typo
of "streedAddress" rather than "streetAddress"
5) LuxTrust corrected the typos in the LTGRCA CP v1.22 as described in
the sections 3.3.21 and 3.3.22.
=== Global Root CA CPS ===
===== Copyright =====
Similar to the above issues, Page 7 contains a somewhat restrictive
copyright clause.
6) LuxTrust proposes the same answer as answer 1).
===== 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.
7) As mentioned in the section “1.1.4. The present document” of the
LTGRCA CPS v1.09, LuxTrust will ensure that cross-signed CAs comply with
strict security and audit requirements at least equivalent to those
applied to LuxTrust CAs, thus in respect of the sections 8, 9 and 10 of
Mozilla CA Certificate Inclusion Policy [4].
===== 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.
8) LuxTrust clarified the contents of the section “3.1.4. Recognition,
authentication, and role of trademarks” in the LTGRCA CPS v1.09 and the
section “3.1.6. Recognition, authentication, and role of trademarks” in
the LTSSLCA CPS v1.3.
===== 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.
9) LuxTrust clarified the content of the section “4.9.2. Who can request
revocation” in the new version of the LTGRCA CPS v1.09.
=== SSL CA CPS ===
===== Copyright =====
Already said this one twice :)
10) LuxTrust proposes the same answer as answer 1).
===== 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? :)
11) LuxTrust clarified the content of the section “1.7. Relationship
with the ETSI specifications” in the new version of the LTSSLCA CPS v1.3.
===== 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 as such in browsers such as Google Chrome, they
will need to be publicizing their certificates in an appropriate
Certificate Transparency Log.
This creates a potential issue for policy non-compliance, so I raise it
now as a potential issue for LuxTrust to examine when examining their
policies as a result of this discussion.
12) LuxTrust is aware of the requirements raised by Google in the
context of Certificate Transparency and will examine them accordingly at
the appropriate time.
===== Trademarks =====
It appears that Page 22, Section 3.1.6 suffers from the same confusion
with respect to trademarks in the names of certificates.
13) LuxTrust proposes the same answer as answer 8).
===== Revocation Requirements =====
To begin, I'd like to applaud LuxTrust for making it clear the process
for requesting revocation in Page 35, Section 4.9.2. In particular,
providing appropriate URLs and contact information for parties to
request revocation.
That said, it appears this section is incomplete with respect to non-EV
certificates and the ability of relying parties to notify LuxTrust of
potential non-conformance to the Baseline Requirements or to LuxTrust's
CPS. It appears this section needs further work to describe the process
and provide appropriate information for such parties.
14) LuxTrust clarified the content of the section “4.9.3 Procedure for
revocation request” in the new version of the LTSSLCA CPS v1.3.
Considering the actions taken for each of the points mentioned above
(allowing to close the bugs), we propose to move forward with the second
public discussion.
I) Resolve the concerns that were raised about CRL and OCSP. Also
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."
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.
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.
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:
“Concatenation of given name(s) and surname(s) separated by the space
character”.
- For the profile described in section 3.3.19, LuxTrust updated the
value of the “CommonName” attribute: “Name commonly used by the subject
to represent itself as stated in ETSI TS 119 412-3, the name should not
be domain-shaped”.
===== 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.
“Value” of the fields “SubjAltName-dNSName” and “SubjAltName-URL”, the
objective being to reflect that up to 10 values are accepted for these
fields.
===== Typos =====
Both Page 93, Section 3.3.21 and Page 99, Section 3.3.22 contain a typo
of "streedAddress" rather than "streetAddress"
the sections 3.3.21 and 3.3.22.
=== 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.
LTGRCA CPS v1.09, LuxTrust will ensure that cross-signed CAs comply with
strict security and audit requirements at least equivalent to those
applied to LuxTrust CAs, thus in respect of the sections 8, 9 and 10 of
Mozilla CA Certificate Inclusion Policy [4].
===== 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.
authentication, and role of trademarks” in the LTGRCA CPS v1.09 and the
section “3.1.6. Recognition, authentication, and role of trademarks” in
the LTSSLCA CPS v1.3.
===== 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.
revocation” in the new version of the LTGRCA CPS v1.09.
=== 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? :)
with the ETSI specifications” in the new version of the LTSSLCA CPS v1.3.
===== 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 as such in browsers such as Google Chrome, they
will need to be publicizing their certificates in an appropriate
Certificate Transparency Log.
This creates a potential issue for policy non-compliance, so I raise it
now as a potential issue for LuxTrust to examine when examining their
policies as a result of this discussion.
context of Certificate Transparency and will examine them accordingly at
the appropriate time.
===== Trademarks =====
It appears that Page 22, Section 3.1.6 suffers from the same confusion
with respect to trademarks in the names of certificates.
===== Revocation Requirements =====
To begin, I'd like to applaud LuxTrust for making it clear the process
for requesting revocation in Page 35, Section 4.9.2. In particular,
providing appropriate URLs and contact information for parties to
request revocation.
That said, it appears this section is incomplete with respect to non-EV
certificates and the ability of relying parties to notify LuxTrust of
potential non-conformance to the Baseline Requirements or to LuxTrust's
CPS. It appears this section needs further work to describe the process
and provide appropriate information for such parties.
revocation request” in the new version of the LTSSLCA CPS v1.3.
Considering the actions taken for each of the points mentioned above
(allowing to close the bugs), we propose to move forward with the second
public discussion.
0 new messages