Dear Ryan and community, I really appreciate your feedback. It provided somehow a new perspective and will help us to improve with such constructive critics.
Please see inserted my answers in your message. Please feel free to ask for any further clarification. Regards, Pedro Fuentes WISeKey SA El sábado, 29 de agosto de 2015, 1:22:10 (UTC+2), Ryan Sleevi escribió: > On Wed, August 5, 2015 10:53 am, Kathleen Wilson wrote: > > (...) > > Kathleen, > > Thanks for organizing this information. I've completed a thorough > secondary review of WISeKey's relevant CPS. Overall, I'd like to commend > them for the adoption of RFC 3647 for their CPS at the beginning of this > year, and for the thoroughness and (general) attention to detail within > the CPS. Of those I've reviewed thoroughly, this was unquestionably the > easiest to review. Yes, this was a pending task which we could finally complete. We moved from a set of CP/CPS documents to a single CPS, which implies a big deal of changes and it's still subject to improvement. > > I've identified things I'd like to specifically call out as good practices > (as a benefit to other CAs), things that are Meh (not intrinsically > problematic, but good be improved), things that may be Bad (and may > require remediation), as well as a long series of follow-up questions and > clarifications. > > These remarks apply to the CPS v2.4, > https://cdn.wisekey.com/uploads/images/WKPKI.DE001-OWGTM-PKI-CPS.v2.4-CLEAN.pdf > > == Good == > * Section 1.3.1 is clear to call out the deprecation of SHA-1 (this is > later expressed in Section 6.1.5) > * Section 3.1.1 (and subsequent Sections 3.1.4, Section 3.1.4.2, and Annex > B) in describing and detailing the form that names take and are validated > * Section 4.6 and Section 4.7 for being explicit in that renewal and rekey > are treated as new certificate issuance > * Section 14.2.4 making it explicit that wildcard certificates may not be > validated using a URL-based demonstration of control > > == Meh == > * Section 3.4 (nor elsewhere in the CPS) appear to provide information for > how Relying Parties may notify WISeKey of potential issues with Subscriber > Certificates (such as Key Compromise) that may require revocation. We understood this topic to be addressed at "4.9.3 Procedure for revocation request". Nevertheless, we will improve this section. > * Sections 4.4.3, 4.6.7, and 4.7.7 may be interpreted as prohibitions > against WISeKey publishing certificate information via Certificate > Transparency We must study how to cover CT in a more explicit way in the CPS, nevertheless we don't consider these sections to be incompatible with CT. > * Section 6.1 suggests that sub-CAs ("Issuing CAs") may not follow the > same audit criteria as Root Keys. This may be due to ambiguity in the > Baseline Requirements, and may represent a conflict with the intent of the > Mozilla Inclusion Policy. At question is whether or not a Qualified > Auditor must be present for the issuance of Issuing CA certificates (which > I believe is desired), or whether an internal auditor suffices. We don't see conflict in this respect. The Root ceremony has been independently audited, and for the subordinate CA we follow BR and any applicable policy (so, no independent auditor is required, but to follow a formal ceremony process and internal audit). Nevertheless, we understand your comment as a need to improve the wording of this section and also adding some explicit comments in section 8. > * Section 11 (throughout) treats the subjectAlternativeName as part of the > Subject naming, rather than as an X.509v3 extension Yes, these tables can improved. > * Section 11.4.1 Policy Qualifier Info contains User Notices which may > unnecessarily increase the size of certificates for no technical benefit. Our Policy Approval Authority considered this as required. We never encountered a problem, even with hardware based certificates. > * Section 11.4.3 does not provide a comprehensive OCSP profile, either for > responder certificates or for the OCSP responses themselves. This makes it > difficult to, for example, look for the id-pkix-ocsp-nocheck extension, as > described in Section 4.9.9 of the Baseline Requirements, v1.3.0 > * There's a lot of cross-referencing to find out the appropriate name > types and associated validation procedures (Section 3.1 references Section > 7.1, which leads to Section 11.1 of Annex B, which leads to Section 12.2 > in Annex C, which ultimately leads to Section 14 in Annex E) We'll improve this in the next CPS version. > > == Bad == > * Section 4.3 specifies that the information used in a certificate may be > used up to a period of 39 months from gathering, but this would be > inconsistent with Section 11.14.3 of the EV Guidelines, Version 1.5.6. Actually, the fact that the EV certificates are limited to two years at the certificate profile (section 11.3.3), and that the renewal is treated as a new issuance, makes us think that this inconsistency wasn't occurring. We admit this can bring ambiguity, so we see to improve the wording. > * Section 11 (throughout) calls the Extended Key Usages extension > "Enhanced Key Usages" This will be amended in a new version of the CPS. > * Section 11.3.1 lacks a description of the Extended Key Usages employed This is an editing error. Will be corrected. > * Section 11.3.2 / 11.3.3 treats the EKU as part of the Key Usages > extension. As a result, it fails to indicate the criticality of the EKU > extension. This will be amended in a new version of the CPS. > * Section 14.1.3 / Section 14.2.3 refer to the catch-all method for IP > address validation, without specifying the CA's practices regarding this. > I believe this should either be removed, or the relevant practices and > procedures employed by the CA should be documented in the CP/CPS > explicitly so that the public may review and raise concerns. > * I could find no reference in your information gathering document, or the > relevant repositories, for the three test URLs required in accordance with > Section 2.2 of the Baseline Requirements, v1.3.0. Namely, test URLs for > valid, expired, and revoked certificates. We'll improve this section as per your recommendation. In our case the practice is always to use either control no. 1 or no. 2. > > == Questions == > * The CPS was updated on 8/17/2015 to clarify that EV certificates may be > issued up to two years. The information gathering document by Kathleen > indicates a validity period of 1 year. This inconsistency permeates the > CPS, in that Section 14.3.9 suggests EV for only 1 year, but that's > inconsistent with the profile of Section 11.3.3 of 2 years. Which is it? In the first version of the new CPS we limited this to one year, but we increased it to two in a second version. We'll correct the inconsistency you detected in the appendix. > * Section 1.1 includes the phrase "intended to serve as a common services > infrastructure for [CAs] worldwide" - would this imply that WISeKey is > operating as a meta-CA? No. This refers to our offering for external entities to operate a subordinated CA (technically constrained for both policies and names) under our Trust Model. > * Section 1.1 establishes that the OISTE Foundation is subject to the > supervision of the Swiss Federal Government, as it cannot be owned by any > individual or corporation. Does this represent any concern to the Mozilla > community with respect to discussions of Government CAs? I don't believe > it should, but I wanted to expressly highlight this during review. The OISTE Foundation, as controller of the Policy Approval Authority is adding an extra layer of supervision on the Trust Model. We don't see conflict in this case. > * Section 1.3.1 suggests that there may be externally-operated sub-CAs; > this would appear to be in conflict with Section 1.3.1.3 which suggests > that WISeKey handles the commercial and technical operation. Elsewhere in > the document, Issuing CAs are referred to as technically-constrained > subordinate CAs. Kathleen's information gathering document suggests these > are supported, but I couldn't find clear guidance on how such CAs would be > processed (and audited) WISeKey operates commercially and technically the Trust Model, and part of this operation is the capability to create subordinated CAs owned and operated by third parties. Regarding the audit, we understand this being explained at section 8.4. External SubCAs implementing name constraints are internally audited to verify compliance with BR and other applicable controls. External SubCAs not implementing constraints would require an independent audit (we don't have currently any unconstrained SubCA not owned by WISeKey). The verification of all the subordinated CA was part of the scope of our WebTrust audit. This verification checked that all the subordinated CAs enforce constraints. > * Section 3.2.4 suggests the common name may be controlled by the > subscriber, if it's a "Standard Personal Certificate". If Section 1.4.1.1 > is accurate, and it lacks the "TLS Server Authentication" EKU, this would > not represent a concern. However, Section 4.9.13 establishes that > "Standard Personal Certificates" may be suspended (a process forbidden for > TLS certificates via the Baseline Requirements), particularly if the > request came from an unauthenticated party (e.g. a Relying Party). > Consider a hypothetical where an SPC certificate was misissued with the > TLS Server Auth EKU. Is it conceivable that WISeKey, in accordance with > its policies, might temporarily suspend, rather than revoke this > certificate? If so, that would represent an action forbidden by the BRs. We must double-check this to look for the cause of your question, as the "Personal Certificates" aren't Server Certificates, therefore aren't concerned by BR. We'd appreciate a clarification on your side, as if you got this misunderstanding maybe others could do too. > * Section 5 supports the notion that externally-operated SubCAs may exist, > but leaves ambiguity with respect to Baseline Requirements audits being > required before issuance, as required by Mozilla's policy. As mentioned in a previous question, we understand this to be covered in section 8.4. Making a clear difference between constrained and unconstrained CA, we enforce the adequate Webtrust compliance, and therefore, this also ensures compliance with Mozilla's policy. > * Section 6.1.1 implies that sub-CAs may not always store private keys > within HSMs. While Section 6.2.1 may provide some clarity on the practice, > the wording within 6.1.1 leaves it ambiguous if this is the case, which > would be concerning if so. We'll consider a possible improvement in the wording. We understand that the references on the WebTrust and BR compliance removes any possible uncertainty. The fact is that we use HSMs. > * Section 7.2.2 does not indicate that the CRLs make use of the Issuing > Distribution Point extension. I want to explicitly confirm that WISeKey > only publishes a single, complete CRL - and, if that's the case, if that's > stated in the CPS and I missed it. The risk would be signing two different > CRLs that represent two different certificate populations, which, in the > absence of an IDP extension, may allow for CRL substitution attacks. We only issue complete CRL. We don't make specific reference to the IDP, so the CPS must be amended. > * Section 11.3 does not appear to constrain the subscriber common name to > a value within the SAN, as required by the BRs. This is later stated (in > Section 14.1.1.1), but it may help to provide the early clarity, and I > wanted to confirm this was the case. See my earlier "meh" remarks about > the naming cross-reference complexity. Yes, we'll improve this to avoid misunderstandings. As verified during the BR WebTrust audit, we enforce the right SAN usage and we fulfill this control. > * Section 14.1.2 suggests that URL-based proof of control may be accepted. > Can WISeKey provide additional details about the methods employed - e.g. > does any subscriber-provided path work? Is there some challenge response > employed? etc. This represents a real security risk (being resolved in the > CA/B Forum's Validation WG), but it would help to provide clearer > information to the Mozilla community about the methods employed here. I must say that we took this option from the BR requirements as a valid control that we could eventually use, but actually we never put this in practice and we rely on the other controls specified in this section. We'll follow the discussions of that workgroup and follow best practices if some day we decide to implement this in our validation procedure. > > Overall, I do not see significant red flags with this review, and would > recommend proceeding once WISeKey has had an opportunity to review this > feedback, to respond, and for the Mozilla community to review the > responses. This is really encouraging and appreciated. > > > In addition to the above remarks, though, which may also bear consideration: > * I was unable to independently verify the WebTrust Seal. While it appears > you (Kathleen) directly contacted the auditor, having the seal information > (which I could not find on WISeKey's website) would allow for the Mozilla > community to examine if the Seal is revoked, for example. We didn't purchased the seals, so Kathleen can confirm that she indeed contacted our auditors. I must say that the fact of relying on a commercial service, like the WT Seal is, which is not really mandatory is causing some conflicts in the industry. I wish there was more clarity in this respect. > * WISeKey has a Root CA Certificate Embedding agreement, which sets forth > stipulations on the usage and inclusion of certificates. Is this document > consistent with Mozilla's policies with respect to open source? > * The Redistribution Agreement provided on WISeKey's site prohibits > redistribution for commercial purposes (see > https://www.wisekey.com/Repository/CACertificates ) > * The IPR Rights in Section 6 from the Relying Party Agreement ( > https://www.wisekey.com/Repository/Documents/Relying-Party-Agreement-1.0-wk-signed.pdf?41cef1 > ) appear somewhat troubling, although kudos is due for the final bullet in > Section 5 of the Subscriber Agreement ( > https://www.wisekey.com/Repository/CertifyID%20Certificate%20Subscriber%20Agreement.pdf?41cef1 > ) As a final comment on the above issues. We are in the process to review other documents in our documentation framework, and our plan is to release new versions of these agreements in the next months. Thanks, Pedro _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
