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:
“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.
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
