Thanks for the reminder, Wayne. I've reviewed the CPS and Audit Reports and have the following comments. I will note that, due to having already had someone else look at it, I only focused on information validation related to domains and IPs, and did not examine the policies around OV and EV, as those are generally not applicable to trust on the Web.
Overall, I think this would be good to proceed, but there's certain discrepancies called out under Questions that I think should be resolved before doing so. I would suggest contacting WISeKey for follow-up on these, and not proceed until we've got a satisfactory response. With the upcoming CA/Browser Forum F2F, I think that effectively means a delay of approximately two weeks, to allow both WISeKey to respond and the community (and maintainers) to review for sufficiency. I think that, provided a response is provided, than barring any further feedback raising additional concerns, proceeding by June 14 would be a reasonable timeframe? Does that seem like a reasonable set of expectations and timing? == Good == * 2.1 notes that they make a public repository of issued certificates available, which is good to see positive affirmation of certificates being public * 3.1.4 and Annex B provide ample detail about the certificate fields and their validated context, which provides a reasonable basis for understanding their certificate profile and validation practices * 3.1.6 "In any event, the OWGTM will not attempt to intermediate nor resolve conflicts regarding ownership of names or trademarks." - It is good to CA recognize its role in not independently trying to determine trademark issues, and instead defer those to proper adjudication. I wish all CAs would recognize this. * 4.9.7 publishes CRLs in 3 days, effectively half the BR-required time (of 7 days), leading to more effective revocation distribution. * 7.2.2 notes a quality profile for CRLs * Note: It could be improved to document the maximum size (worst case) of CRLs or how sharding is done (across issuerDistributionPoint extensions), to ensure that the worst case CRL size (if all certs pointing to that CRL were revoked) is kept within a reasonable size limit, such as 64K. That's an opportunity for improvement, but admittedly requires more careful engineering design to implement. * 9.4.2 notes that "private information" does NOT include information contained within a certificate or CRL, which is the correct interpretation * 9.6.1 explicitly notes MITM is prohibited. While implicit, it's also encouraging to see this explicitly called out. * Annex E notes that they support IODEF, and the supported methods (this is a SHOULD, not a MUST, in the BRs) == Meh == * 1.4.1.2, which details the validation process for server certificates, explicitly calls out domain verification for DV, but not for OV/EV. * It's unclear if this implies the use of the (deprecated) 3.2.2.4.1 / 3.2.2.4.5 as demonstrations of domain "ownership" independent of domain "control" * Annex E makes it clear that .1 and .5 are in scope as validation methods, which should be phased out by August. * 1.5.4 requires a full meeting of the CAA to convene for updates, which may make it difficult to have the CPS (and the attendant CA policies) reflect the BRs * 3.2.6 notes an accreditation process for interoperating, but doesn't note whether that includes audits consistent with section 8 of the BRs * 4.3 states "The OWGTM is not responsible for monitoring, research or confirmation of the correctness of the information contained in a certificate during the intermediate period between its issuance and renewal, ", which in one read, is entirely consistent with 9.6.1 of the BRs (consistent in that it's at time of issuance), but in another read, could be seen as conflicting with 4.9.1.1 of the BRs * Section 4.9.1 lists 13 items, but there are 15 in the corresponding BRs. Item #4 from the BRs is combined with Item #3 in the CPS, and Item #7 is missing from the BRs as an explicit callout. #14 and #15 in the BRs are seemingly not present, as the place where they would be expected - #12 and #13 - from the CPS are different. * Section 5.2.2 / 5.2.4 don't detail the minimum number of people required for certain activities. * Section 6.2.4 states that CA backup keys are "typically" store encrypted. What protections are in place if they're not encrypted? * Section 7.3.2 misunderstands OCSP extensions as being about the certificates, rather than extensions within OCSP responses (such as CT extensions, should that be supported, or nonces, if that should unfortunately be supported [and it shouldn't]) * Annex B, 11.3.1, lists SAN in the base certificate profile, rather than as an X.509v3 extension, and doesn't explicitly list the CN as being one of the SAN values == Bad == * Annex B, 11.3.1, does not list the extendedKeyUsage in the profile for SSL certificates which is mandatory per the BRs 7.1.2.3. * Other profiles under Annex B do list it (under the misnamed "Enhanced Key Usage"), so this should be corrected to include id-kp-serverAuth (and optionally id-kp-clientAuth) * 11.3.2 lists it under "Key Usages" * Annex B, 11.3.2 / 11.3.3 lists the Netscape Certificate Type as optional. There's no reasonable need to support this extension. Let's let it die :) * Annex E, 14.1.4 / 14.2.4, notes the use of "Any Other Method" for IP validation == Questions == * I've confirmed that AUREN is a licensed WebTrust practitioner, as per [1]. When reviewing the audit report, I note that a WebTrust seal was not provided (which is not a requirement), but that may have masked other review items. In examining the report, [2], I noticed some deviations from the IASE 3000 illustrative reporting provided by WebTrust [3] for such reports, particularly IN1.1 (which is for WebTrust for CAs) in [3]. * In the illustrative reports, it calls out being engaged in a reasonable assurance audit, while in the AUREN report, it states it has audited management's assertion. Is there significance in the deviation of language? * [2] does not list the location of the CA services, although [4], oddly enough, does. This is worth following up on. * It notes that external RAs are used, but does not note that key escrow or certificate suspension are out of scope - meaning they are in scope. This is consistent with the CPS [5] in Section 4.9, which notes that non-SSL certificates may undergo suspension, and Section 4.12, which notes non-SSL end-entity certificates may undergo escrow. * In listing auditor responsibilities, it explicitly notes that it did not test the operating effectiveness of these controls (Item 3 in the illustrative report, which is explicitly called out as out of scope in [2]) * As noted, the key generation was performed in May, and this audit is a period of time audit beginning in September. This does mean that there is a gap in the audit coverage - from May through September - that's difficult to reason about. Are there any other supporting documents that would help assuage these concerns? * Similarly, comparing [4] with [3] produces some deviations for IN 2.1 (which is for SSL BRs): * Like [2], it calls out that testing operating effectiveness was not part of the scope, in this case, entirely omitting (2) from IN 2.1 and modifying (3) to exclude testing. * The hierarchy within the reports calls out the "OISTE WISeKey Global Root GC CA", which is presumably the "OWGTM Root CA GC" mentioned in the CPS [5], and the "WISeKey CertifyID Advanced GC CA 1", which tracks with the diagram on Page 13. * However, the fingerprints listed in the audit report differ from that in the CP/CPS for the root CA * E0:11:84:5E:34:DE:BE:88:81:B9:9C:F6:16:26:D1:96:1F:C3:B9:31 in the audit * E8 11 84 5E 34 DE BE 88 81 B9 9C F6 16 16 26 D1 96 1F C3 B9 31 in the CP/CPS * Note the two typos - E0 vs E8 and 26 vs 16. Which is correct? * WISeKey CertifyID Advanced GC CA 1 is not disclosed in the CP/CPS [1] http://www.webtrust.org/licensed-webtrust-practitioners-international/item64419.aspx [2] https://cdn.wisekey.com/uploads/images/Audit-Report-and-Management-Assertions-Webtrust-CA-GC.pdf [3] http://www.webtrust.org/practitioner-qualifications/docs/item85204.pdf [4] https://cdn.wisekey.com/uploads/images/Audit-Report-and-Management-Assertions-Webtrust-BR-GC.pdf [5] https://cdn.wisekey.com/uploads/images/WKPKI.DE001-OWGTM-PKI-CPS.v2.10-CLEAN.pdf On Tue, May 15, 2018 at 5:11 PM, Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Reminder: there is one week left in the discussion period for this > inclusion request. > > On Tue, May 1, 2018 at 12:02 PM Wayne Thayer <wtha...@mozilla.com> wrote: > > > This request is for inclusion of the OISTE WISeKey Global Root GC CA as > > documented in the following bug: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1403591 > > > > * BR Self Assessment is here: > > https://bugzilla.mozilla.org/attachment.cgi?id=8912732 > > > > * Summary of Information Gathered and Verified: > > https://bugzilla.mozilla.org/attachment.cgi?id=8955363 > > > > * Root Certificate Download URL: > > https://bugzilla.mozilla.org/attachment.cgi?id=8912737 > > > > CP/CPS: > > https://cdn.wisekey.com/uploads/images/WKPKI.DE001- > OWGTM-PKI-CPS.v2.10-CLEAN.pdf > > > > * This request is to turn on the Websites and Email trust bits. EV > > treatment is not requested. > > > > * EV Policy OIDs: Not EV > > > > * Test Websites > > https://gcvalidssl.hightrusted.com/ > > https://gcexpiredssl.hightrusted.com/ > > https://gcrevokedssl.hightrusted.com/ > > > > * CRL URL: http://public.wisekey.com/crl/wcidgcas1.crl > > > > * OCSP URL: http://ocsp.wisekey.com/ > > > > * Audit: Annual audits are performed by AUREN according to the WebTrust > > for CA and BR audit criteria. > > WebTrust: > > https://cdn.wisekey.com/uploads/images/Audit-Report- > and-Management-Assertions-Webtrust-CA-GC.pdf > > BR: > > https://cdn.wisekey.com/uploads/images/Audit-Report- > and-Management-Assertions-Webtrust-BR-GC.pdf > > EV: Not EV > > > > I’ve reviewed the CPS, BR Self Assessment, and related information for > the > > OISTE WISeKey Global Root GC CA inclusion request that are being tracked > in > > this bug and have the following comments: > > > > ==Good== > > * This root was created in May of 2017 and the intermediate appears to > > have only signed test certs since then. > > * Problem reporting mechanism is clearly labeled as such in the CPS. > > > > ==Meh== > > * The older OISTE WISeKey Global Root GA CA that is in our program has > > issued a few certs containing linting errors (some are false positives > for > > OCSP signing certs): > > https://crt.sh/?caid=15102&opt=cablint,zlint,x509lint& > minNotBefore=2010-01-01 > > Two notable concerns are: > > ** Valid wildcard certificate for a public suffix: > > https://crt.sh/?id=76535370&opt=cablint (BR 3.2.2.6 permits this only if > > “the applicant proves its rightful control of the entire Domain > Namespace“) > > ** Valid cert containing a non-printable string in the Subject : > > https://crt.sh/?id=308365498&opt=x509lint,ocsp > > * WISeKey was the subject of one misissuance bug for “invalid dnsNames” > > and “CN not in SAN” errors to which they responded promptly: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1391089 > > ** They also failed to respond to a problem report during this > > incident. > > Domain validations procedures are listed in an appendix instead of > section > > 3.2.2.4 of the CPS and they include the soon-to-be-banned 3.2.2.4.1 and > > 3.2.2.4.5 methods. A note indicates that 3.2.2.4.5 will be discontinued > > after August 1st. The reference to 3.2.2.4.1 appears to be a > documentation > > error. > > During my initial review, the CPS was missing CAA information and still > > referenced 3-year validity periods. WISeKey quickly made the needed > changes > > but indicated that they update their CPS during an annual review rather > > than regularly as new requirements come into effect. > > > > ==Bad== > > Nothing to report > > > > This begins the 3-week comment period for this request [1]. > > > > I will greatly appreciate your thoughtful and constructive feedback on > the > > acceptance of this root into the Mozilla CA program. > > > > - Wayne > > > > [1] https://wiki.mozilla.org/CA/Application_Process > > > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy