Dear all, please find bellow our responses to the "Meh" and "Bad" issues raised by Ryan. In respect to the points related to our auditors, we got their feedback and we're inserting also their responses here.
Some of the points implied a change in the CPS, which is going to be published in less than 24h in our site, but already available for your review at this link https://filevault.wisekey.com/f/c7b0d13153/ It was really good for us having some new eyes to review the document, so we really appreciate your contribution. Let us know if there's any other clarification required. Thanks and regards, Pedro El martes, 22 de mayo de 2018, 21:11:51 (UTC+2), Ryan Sleevi escribió: > Thanks for the reminder, Wayne. (...) > == 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. **** Checks for OV/EV are “Additional” to the ones done for DV, as explicitly mentioned in section 12.2.2 so domain validation of OV is done as for the DV, and then there are additional controls for the specifics of OV/EV. I’ll see maybe about making this more explicit in next versions. **** > * 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. **** Yes, we mention that these methods are still accepted, but as I explained in Bugzilla, this is for us always a complementary check, we never rely on this as a sole validation method, so being complementary we think that it was actually positive to keep it by now. **** > * 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 **** I understand you mean the PAA. As we say in the CPS “Minor versions only require the participation of a single member of the PAA in order to approve the publication of a new version.” This accelerates the process for quick amendments like the ones derived of your kind review (I’m myself member if the PAA). **** > * 3.2.6 notes an accreditation process for interoperating, but doesn't note > whether that includes audits consistent with section 8 of the BRs **** We set the requirements for audit and compliance and audit in section 8 of the CPS, and that has to be respected in any case. This particular section is just pointing some additional controls related to interoperation, but frankly speaking I don’t see of much relevance, I could easily change it to “No stipulation”. **** > * 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 **** Maybe is a problem of language or interpretation, but we say that once the certificate is properly validated and issued, we can’t control the ulterior correctness of the information (i.e. change in domain ownership) until a new validation round (I.e. for a renewal) is performed. I would appreciate more details in your concern and I’m afraid I couldn’t find the relationship with BR-4.9.11 which is related to revocation status. **** > * 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. **** Well… Instead of making an exercise to match here our wording and the BR, I just updated the CPS and copied literarily the BR. I can’t see any conflict and it won’t affect our operations, so I think it’s the cleanest solution. **** > * Section 5.2.2 / 5.2.4 don't detail the minimum number of people required > for certain activities. **** The fact of mandating separation of duties would imply a minimum of two persons, but I never saw these details on the number of people per task in other CPS… Is this really needed? **** > * Section 6.2.4 states that CA backup keys are "typically" store encrypted. > What protections are in place if they're not encrypted? **** Sorry, I just realized about this language problem… this has been edited to “always” in the new CPS update. We say in the same section that these backups are kept in hardware cryptographic modules, so obviously it can’t be in unencrypted form. **** > * 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]) **** Yes, we misunderstood this. I saw in the past that other CPS put here “No stipulation” so maybe I’ll do the same after studying this more carefully. **** > * 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 **** Thanks, I improved the CPS based in your comment. I moved that line to the extension group. The common name was set as optional, but I added the reference of matching one of the SAN. **** > > == 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" **** Yes, the EKU was missing for the Standard SSL (DV) section and and there were some formatting issues in the other tables that didn’t help to show this clearly. I solved these issues. **** > * 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 :) **** Yes, there’s no reason to keep this, as it’s been years we don’t use it. I removed it in the updated CPS **** > * Annex E, 14.1.4 / 14.2.4, notes the use of "Any Other Method" for IP > validation **** Actually we never use any other method, so I removed it of the edited CPS. **** > > == 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]. **** COMMENT FROM AUREN: These reports were generated around the time of publication and adoption period of the new templates, being this is the reason of some possible deviations. Auren is already adopting the new models for newer reports. COMMENT FROM WISEKEY: We get the Webtrust seals for annual audits, but not for point-in-time or first 3-month period audits. **** > * 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? **** COMMENT FROM AUREN: There are two types of reports, the “attestation engagement” and the “direct engagement”, as indicated in IN1.1 e IN 1.3 (http://www.webtrust.org/practitioner-qualifications/docs/item85204.pdf). Traditionally we always did the first one and it’s also the one that the rest of practitioners commonly adopt. **** > * [2] does not list the location of the CA services, although [4], oddly > enough, does. This is worth following up on. **** COMMENT FROM AUREN: This is related to the models used for each report, as the ones used previously for Webtrust 1.0 weren’t including this information. COMMENT FROM WISEKEY: Evidently, all operations for all Roots are done from the same site in Geneva, Switzerland. You’re invited to a Swiss cheese Fondue in the case you want to check out! **** > * 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. **** COMMENT FROM AUREN: This is also related to the model used for the reports, as this was not in previous versions. It’s confirmed that escrow was out of scope. COMMENT FROM WISEKEY: Regarding escrow... We left that open in the CPS, as it happened in the past that some technically constrained CAs that customers implemented with Microsoft Certificate Services implemented the native key escrow capability for encryption certificates and we allowed this for these customer-owned constrained CAs, but we, as WISeKey, we don’t provide escrow services to our certificate subscribers. **** > * 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]) **** COMMENTS FROM AUREN: This is an erratum coming from reusing the PiT report. Obviously all the tests on the controls were done, as we are providing our opinion on the period. **** > * 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? **** COMMENTS FROM WISEKEY: We had a pause period between the Root CA Ceremony and the creation of a first issuing CA, so actually there weren't operations to audit. That’s the reason of the “gap”, as the Root didn’t issue any certificate and was just left deactivated, so the first period audit started with the effective start of operations and verified a first three-month period after this start of operations, during which we only issued a few test certificates. **** > * 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. **** COMMENTS FROM AUREN: Same as above, this is related to the model used at the time of these reports. Newer reports are adapted to the new models. **** > * 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. ***** "OWGTM Root CA GC" is a short name for “OISTE WISeKey Global Root GC CA”, as stated in the CPS ***** > * 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? **** This was an unfortunate typo, thanks for catching this. The fingerprint of the certificate uploaded to the Bugzilla post and appearing int he audit reports is the correct one E0 11 84 5E 34 DE BE 88 81 B9 9C F6 16 26 D1 96 1F C3 B9 31 The one in the CPS had the typo and has been corrected. **** > * WISeKey CertifyID Advanced GC CA 1 is not disclosed in the CP/CPS **** As explained in Bugzilla, we don’t list the Issuing CAs in the CPS, but we reference https://www.wisekey.com/repository, were the updated list is maintained. Nevertheless, issuing CAs are always included in the audit reports. **** > > > [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
