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
