info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: WISeKey Root Renewal Request
204 views
Skip to first unread message
Ryan Sleevi
Aug 28, 2015, 7:22:10 PM8/28/15
to Kathleen Wilson, mozilla-dev-s...@lists.mozilla.org
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’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
)
> 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’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
)
pfuen...@gmail.com
Sep 6, 2015, 5:39:54 PM9/6/15
to mozilla-dev-s...@lists.mozilla.org
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
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
David Keeler
Sep 9, 2015, 7:50:08 PM9/9/15
to dev-secur...@lists.mozilla.org
On 08/05/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 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.
> * Potentially Problematic Practices -- None noted
> (http://wiki.mozilla.org/CA:Problematic_Practices)
The following certificate with a validity period of Mar 06 2015 to Mar
06 2016 was signed with sha-1. It also has the nsCertType extension,
which is deprecated.
-----BEGIN CERTIFICATE-----
MIIFdzCCBF+gAwIBAgIKb8MVFQAAAAAfqjANBgkqhkiG9w0BAQUFADCBjjELMAkG
A1UEBhMCQ0gxEDAOBgNVBAoTB1dJU2VLZXkxIjAgBgNVBAsTGUNvcHlyaWdodCAy
MDExIFdJU2VLZXkgU0ExFjAUBgNVBAsTDUludGVybmF0aW9uYWwxMTAvBgNVBAMT
KFdJU2VLZXkgQ2VydGlmeUlEIEFkdmFuY2VkIFNlcnZpY2VzIENBIDIwHhcNMTUw
MzA2MTAxNDU2WhcNMTYwMzA2MTAxNDU2WjCBjjELMAkGA1UEBhMCQ0gxDzANBgNV
BAgTBkdlbmV2ZTEPMA0GA1UEBxMGR2VuZXZlMRswGQYDVQQKExJBbmRyZSBDaGV2
YWxsZXkgU0ExGzAZBgNVBAsTEkFuZHJlIENoZXZhbGxleSBTQTEjMCEGA1UEAxMa
YWNudDAyLmFuZHJlLWNoZXZhbGxleS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IB
DwAwggEKAoIBAQC5SXnzN/q9MkALKTZ1RnTt9prGXqeRCtT4+RLrvDPUaTdR5qXX
xwoMA0pkVDo5kSwPfXQehlTfhVc4rQ2WgfObTke1ImZ6MnbKDYCSzMc3RCzjUk1O
xhQQl/AhJQvX1587V+69SQRTXQ4eWYU2uIIpGhhZw15Cd003R3tMXvktAFgtVtM9
SDfbeoE8YwLx1hBTO0xBWKEWrz5sFF7hJHuMv661sN3H7ZxMIVAdambKf09uWE7f
NI++45O7S9Y0r6Qj6ZjhTe5gYisuDs4YqdPTw0XuSPQy89FxKagtgE9hapatUyuO
Lel4lL+CKlKPWbwqZQOAngZCD19P6x+EJ6P7AgMBAAGjggHTMIIBzzAdBgNVHQ4E
FgQURzpp2xDxM92c5L2+Fv7s7Z1+XaYwDgYDVR0PAQH/BAQDAgSwMB8GA1UdIwQY
MBaAFNcvL/MJ8VYhUx3nTC5IRErahv2YMDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6
Ly9wdWJsaWMud2lzZWtleS5jb20vY3JsL3djaWRhc2NhMi5jcmwwbQYIKwYBBQUH
AQEEYTBfMDcGCCsGAQUFBzAChitodHRwOi8vcHVibGljLndpc2VrZXkuY29tL2Ny
dC93Y2lkYXNjYTIuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC53aXNla2V5
LmNvbS8wHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMBMCcGCSsGAQQBgjcV
CgQaMBgwCgYIKwYBBQUHAwIwCgYIKwYBBQUHAwEwdQYDVR0RBG4wbIIXb3dhLmFu
ZHJlLWNoZXZhbGxleS5jb22CE0FuZHJlLUNoZXZhbGxleS5jb22CGmFjbnQwMi5h
bmRyZS1jaGV2YWxsZXkuY29tgiBhdXRvZGlzY292ZXIuQW5kcmUtQ2hldmFsbGV5
LmNvbTARBglghkgBhvhCAQEEBAMCAMAwDQYJKoZIhvcNAQEFBQADggEBAEvUcTR1
uBDGtgco3Zt1KW7eBi6E4/JfS63mK4gAUurAj/ItjJIaZqC/aY7VxdYZxEGIUcEX
OW3wrWsDpHkwKI1XkNFvJTKk+2IrgN9R6VDT9+d8hVxukQULWxBj61ge93jxY2kB
0FuPD1VPx0+B+/UKcNT9fEYWEqudguA3tQ3CuquZj+i0T8r9YiAwVx0OmQnwX62O
FXjXVJlZrQrmhi9EGzSODItkUU7NopkM81dn1BmFkIuqacU31Wcjd4neCfJPNApk
zSabFuhF0lcPZwFn7PW/9/TAELP5K270Guaj1gaBmkJ+Dk6hHYVd44SlgOuNRQSC
rnNj+hNsDI/uwJc=
-----END CERTIFICATE-----
The following certificate with a validity period of Nov 06 2014 to Nov
05 2017 has similar problems. In addition, the common name is expressed
as a wildcard ("*.hightrusted.com"). This will not work as expected in
Firefox because the wildcard is not expressed as an entry in the subject
alternative name extension.
-----BEGIN CERTIFICATE-----
MIIGvjCCBaagAwIBAgIKGXHdogAAAAAbcDANBgkqhkiG9w0BAQUFADCBjjELMAkG
A1UEBhMCQ0gxEDAOBgNVBAoTB1dJU2VLZXkxIjAgBgNVBAsTGUNvcHlyaWdodCAy
MDExIFdJU2VLZXkgU0ExFjAUBgNVBAsTDUludGVybmF0aW9uYWwxMTAvBgNVBAMT
KFdJU2VLZXkgQ2VydGlmeUlEIEFkdmFuY2VkIFNlcnZpY2VzIENBIDIwHhcNMTQx
MTA3MDMxNjMxWhcNMTcxMTA2MDMxNjMxWjBbMQswCQYDVQQGEwJDSDEPMA0GA1UE
CBMGR2VuZXZhMRAwDgYDVQQKEwdXSVNFS0VZMQ0wCwYDVQQLEwRURUNIMRowGAYD
VQQDDBEqLmhpZ2h0cnVzdGVkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBAOVHrrzUPZnGJ2LqYuM46fBNB8AwaVGPYKMCb6vCtpU7L+AGFlgelh2X
cn0idCn/wXba66efVmwJeKoSQH8jCb49Rb96gCvdka843NKIFjjh+kP2d/uPEAo3
DJkviPFsx4XwhFLWx4zsRJf9H8owvuFAb3St33YesI8T+t8s5jX/jL/ZFwvbbB9n
CsBHMGZ6ukhdP/hp8crUI8wILgD9He2db3CkpDUEbIDMWGtr97hav1A5gNW0+SmN
2DC05UCvAIIfN6h2gGFrMOE2yqrPUxwvB9uh3g8Zi3lXqWT8V7ypkcyJxcwBxx8H
h86cOWxGrfDLO4bVcFt4Os2N850MsekCAwEAAaOCA04wggNKMB0GA1UdDgQWBBRn
T9vIuCquQep+9FzH3eTG1Pew1DAfBgNVHSMEGDAWgBTXLy/zCfFWIVMd50wuSERK
2ob9mDA8BgNVHR8ENTAzMDGgL6AthitodHRwOi8vcHVibGljLndpc2VrZXkuY29t
L2NybC93Y2lkYXNjYTIuY3JsMG0GCCsGAQUFBwEBBGEwXzA3BggrBgEFBQcwAoYr
aHR0cDovL3B1YmxpYy53aXNla2V5LmNvbS9jcnQvd2NpZGFzY2EyLmNydDAkBggr
BgEFBQcwAYYYaHR0cDovL29jc3Aud2lzZWtleS5jb20vMAwGA1UdEwEB/wQCMAAw
HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMBMCcGCSsGAQQBgjcVCgQaMBgw
CgYIKwYBBQUHAwIwCgYIKwYBBQUHAwEwggHgBgNVHREEggHXMIIB04IPaGlnaHRy
dXN0ZWQuY29tghZjYXJsb3MuaGlnaHRydXN0ZWQuY29tghVvaXN0ZS5oaWdodHJ1
c3RlZC5jb22CF3dpc2VrZXkuaGlnaHRydXN0ZWQuY29tghx3aXNla2V5bGliZXIu
aGlnaHRydXN0ZWQuY29tghNzaXAuaGlnaHRydXN0ZWQuY29tghN3d3cuaGlnaHRy
dXN0ZWQuY29tghhiaWd0cnVzdC5oaWdodHJ1c3RlZC5jb22CFndpc2VpZC5oaWdo
dHJ1c3RlZC5jb22CF3dpc2ZhbnMuaGlnaHRydXN0ZWQuY29tghd3aXNlcGF5Lmhp
Z2h0cnVzdGVkLmNvbYITY2ExLmhpZ2h0cnVzdGVkLmNvbYISd3MuaGlnaHRydXN0
ZWQuY29tghhzZXJ2aWNlcy5oaWdodHJ1c3RlZC5jb22CFG1haWwuaGlnaHRydXN0
ZWQuY29tghJ3YS5oaWdodHJ1c3RlZC5jb22CE3Nzby5oaWdodHJ1c3RlZC5jb22C
FGF1dGguaGlnaHRydXN0ZWQuY29tghl3aXNlcGhvbmUuaGlnaHRydXN0ZWQuY29t
ghltZXNzZW5nZXIuaGlnaHRydXN0ZWQuY29tMA4GA1UdDwEB/wQEAwIEsDARBglg
hkgBhvhCAQEEBAMCAMAwDQYJKoZIhvcNAQEFBQADggEBAAWyChyBnIc/cQyXTF1i
tgSz3m1HRY+fEpiN+rva72IRD9UpAbgvdeZLA22NBYMoFkm3C2Fjk1V10WEPPKRz
QlGZjcBO695m7tO+sPZ6OYvj/f+UgSkrAqXNd/xGOJ0OxgbjM3062RueNZYRBAvA
uxqPkvxgRYoOzntyejFbWn4YQ+pmjHhk+TJAyi6mpk3SG3RV+J8/+k1ncqxcaqnd
0KV9oENApdNDxfWLtEM8NaGjy9zpeO1Kp6fL9FB7MasDTroAVvm/5wV+xg3XuOm8
q4CXdAKCZcP9SX5qY/KdEcjp/XvJ5CJyFZSARILniEdbJdRDvriHzkjNHLRO0ZdF
3GM=
-----END CERTIFICATE-----
Cheers,
David Keeler
pfuen...@gmail.com
Sep 17, 2015, 9:18:57 AM9/17/15
to mozilla-dev-s...@lists.mozilla.org
Thanks for this message.
Clarification: WISeKey, as verified during our last WebTrust audit for BR, since April 2015 is not issuing SHA-1 certificates with validity beyond 31-Dec-2105 and we're in the process to reissue or revoke any problematic certificate before the end of the year.
We also recently updated our RA solution to ensure consistency on the CN and SAN names, making mandatory the presence of the first SAN.
So, although this warning message is justified, WISeKey already put the required controls to ensure that no problematic practices occur.
Regards,
Pedro Fuentes
WISeKey SA
Clarification: WISeKey, as verified during our last WebTrust audit for BR, since April 2015 is not issuing SHA-1 certificates with validity beyond 31-Dec-2105 and we're in the process to reissue or revoke any problematic certificate before the end of the year.
We also recently updated our RA solution to ensure consistency on the CN and SAN names, making mandatory the presence of the first SAN.
So, although this warning message is justified, WISeKey already put the required controls to ensure that no problematic practices occur.
Regards,
Pedro Fuentes
WISeKey SA
pfuen...@gmail.com
Sep 17, 2015, 12:34:44 PM9/17/15
to mozilla-dev-s...@lists.mozilla.org
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
>
> 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
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.
> 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)
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.
> * 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.
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
> )
Thanks,
Pedro
kwi...@mozilla.com
Oct 1, 2015, 4:30:09 PM10/1/15
to mozilla-dev-s...@lists.mozilla.org
On 8/5/15 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's no focus on a
> 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
> 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
>
Thanks to all of you who reviewed and commented on this request from WISeKey to include the "OISTE WISeKey Global Root GB CA" root certificate, turn all all three trust bits, and enable EV treatment.
>
> 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
>
WISeKey intends to incorporate the feedback from this discussion into the next version of their CPS, and those updates are such that we may proceed with approval and inclusion of this root certificate. Also, I had indeed confirmed the authenticity of the audit statements by contacting the auditor directly.
I am not aware of any issues that would prevent us from moving forward with this request. Therefore, I will recommend approval in the bug.
https://bugzilla.mozilla.org/show_bug.cgi?id=1172819
Any further follow-up on this request should be added directly to the bug.
Thanks,
Kathleen
0 new messages