Dear Ryan, I really appreciate your time and the constructive feedback you provided. Really encouraging that after your in-deep analysis there aren't "red flags".
Please allow us to prepare a comprehensive answer to your comments and we'll come back to this ASAP. Thanks and regards, Pedro 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: > > WISeKey has applied to include the "OISTE WISeKey Global Root GB CA" > > root certificate, turn all all three trust bits, and enable EV > > treatment. This SHA-256 root cert will eventually replace WISeKey's > > SHA-1 root cert that was included in NSS via Bugzilla Bug #371362. > > > > WISeKey provides worldwide eSecurity services based or related to > > electronic identities and digital certificates. Thereâ EURO (tm)s no focus > > on a > > particular region or customer profile. > > > > The request is documented in the following bug: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1172819 > > > > And in the pending certificates list: > > https://wiki.mozilla.org/CA:PendingCAs > > > > Summary of Information Gathered and Verified: > > https://bugzilla.mozilla.org/attachment.cgi?id=8640737 > <SNIP> > > This begins the discussion of the request from WISeKey to include the > > "OISTE WISeKey Global Root GB CA" root certificate, turn all all three > > 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, > > 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. > > 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. > * Sections 4.4.3, 4.6.7, and 4.7.7 may be interpreted as prohibitions > against WISeKey publishing certificate information via Certificate > Transparency > * 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. > * Section 11 (throughout) treats the subjectAlternativeName as part of the > Subject naming, rather than as an X.509v3 extension > * Section 11.4.1 Policy Qualifier Info contains User Notices which may > unnecessarily increase the size of certificates for no technical benefit. > * 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) > > == 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. > * Section 11 (throughout) calls the Extended Key Usages extension > "Enhanced Key Usages" > * Section 11.3.1 lacks a description of the Extended Key Usages employed > * 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. > * 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. > > == 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? > * 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? > * 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. > * 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) > * 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. > * 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. > * 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. > * 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. > * 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. > * 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. > > 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. > > > 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. > * 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 > ) _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
