1936279 - Add OISTE root certificates

Status: RESOLVED FIXED

(CA Program :: CA Certificate Root Program, task, P1)

Description

[Pedro Fuentes]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.0.1 Safari/605.1.15

Steps to reproduce:

We kindly request the inclusion of FOUR new Root CAs for the OISTE Foundation, that are intended to replace gradually our existing hierarchies.

The CCADB Case is 00001946

Names and details of the CAs:
Root 1:

• Subject: CN=OISTE Client Root ECC G1; O=OISTE Foundation; C=CH
• Fingerprint: D9A32485A8CCA85539CEF12FFFFF711378A17851D73DA2732AB4302D763BD62B

Root 2:

• Subject: CN=OISTE Client Root RSA G1; O=OISTE Foundation; C=CH
• Fingerprint: D02A0F994A868C66395F2E7A880DF509BD0C29C96DE16015A0FD501EDA4F96A9

Root 3:

• Subject: CN=OISTE Server Root ECC G1; O=OISTE Foundation; C=CH
• Fingerprint: EEC997C0C30F216F7E3B8B307D2BAE42412D753FC8219DAFD1520B2572850F49

Root 4:

• Subject: CN=OISTE Server Root RSA G1; O=OISTE Foundation; C=CH
• Fingerprint: 9AE36232A5189FFDDB353DFD26520C015395D22777DAC59DB57B98C089A651E6

Comment 1

[Ben Wilson]

Public discussion of this inclusion request began on June 30, 2025. https://groups.google.com/a/ccadb.org/g/public/c/io3FmmOI9Gw/m/7_85nn7QCQAJ and it ended on August 11, 2025 https://groups.google.com/a/ccadb.org/g/public/c/io3FmmOI9Gw/m/WwS4aFHEDAAJ.

Comment 2

[Ben Wilson]

Notice of pending approval and last-call for objections was sent to the Mozilla dev-security-list on August 22, 2025, with an end date of August 29, 2025. See https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/SJIHbT0Om5k/m/gHK-R-B5CgAJ

Comment 3

[Ben Wilson]

I will open the appropriate tickets to add the four roots to NSS and for PSM to EV-enable the two roots that will have the websites trust bit.

Comment 4

[Ben Wilson]

I've opened Bug #1988913 in NSS:CA Certificates Code to have the 4 root certificates added to NSS and Bug #1988916 in PSM to have the two TLS-issuing root CAs EV enabled.

Comment 5

[Ben Wilson]

Next Step: OISTE/WiseKey will need to have these root CA certificates enabled for CT logging and obtain the necessary SCTs for its test websites in order to comply with Mozilla's CT Policy.

Comment 6

[Rob Stradling]

Ben, is there a public document yet that describes Mozilla's CT Policy?

Comment 7

[Pedro Fuentes]

(In reply to Ben Wilson from comment #5)

Next Step: OISTE/WiseKey will need to have these root CA certificates enabled for CT logging and obtain the necessary SCTs for its test websites in order to comply with Mozilla's CT Policy.

Thanks for progressing with our request. We are in the process to get PROD CT Logs enabled for the new Roots.

Comment 8

[Ben Wilson]

(In reply to Rob Stradling from comment #6)

Ben, is there a public document yet that describes Mozilla's CT Policy?
Hi Rob,
Here is some helpful information: https://wiki.mozilla.org/SecurityEngineering/Certificate_Transparency#CT_Policy

Comment 9

[Rob Stradling]

Thanks Ben. If that's a policy that you're expecting CAs to be aware of and to comply with, please announce this on MDSP. Thanks!

Comment 10

[Ben Wilson]

Hi Pedro,
Do you have anything to report on efforts to get these roots into CT logs?
Thanks,
Ben

Comment 11

[Pedro Fuentes]

(In reply to Ben Wilson from comment #10)

Hi Pedro,
Do you have anything to report on efforts to get these roots into CT logs?
Thanks,
Ben

Hi Ben,
we have requested to several CT Logs operators the inclusion of the new Roots and we are waiting to have this done and with quorum enough to enable it in our certificate templates.
I hope it will not take much longer.
Thanks,
Pedro

Comment 12

[chrome-root-program]

Has OISTE considered issuing a cross-certificate from an existing trusted hierarchy (e.g., OISTE WISeKey Global Root GB CA) to the relevant applicant roots (e.g., OISTE Server Root RSA G1)?

Doing so would:

• allow leafs from the new hierarchy to chain to a root that's already accepted by many CT Logs, thereby enabling logging without needing to wait for additional log inclusions or state changes.
• support trust ubiquity

Comment 13

[Pedro Fuentes]

(In reply to chrome-root-program from comment #12)

Has OISTE considered issuing a cross-certificate from an existing trusted hierarchy (e.g., OISTE WISeKey Global Root GB CA) to the relevant applicant roots (e.g., OISTE Server Root RSA G1)?

Doing so would:

• allow leafs from the new hierarchy to chain to a root that's already accepted by many CT Logs, thereby enabling logging without needing to wait for additional log inclusions or state changes.
• support trust ubiquity

We haven't considered this because, even if it could be practical to have the leaf certificates trusted immediately, we don't see practical benefit against using the issuing CAs that we already have under (e.g.) Root GB to cover current customer needs.

Also, as per my understanding, even if we create an alternate trust path, we'd still need to be compliant with the Root Programs and BR, and being able to issue test certificates (valid, revoked, expired) under the new roots, so we'd still need to have CT compliance under the direct trust path.

Comment 14

[chrome-root-program]

[In response to Comment 13]

Also, as per my understanding, even if we create an alternate trust path, we'd still need to be compliant with the Root Programs and BR, and being able to issue test certificates (valid, revoked, expired) under the new roots, so we'd still need to have CT compliance under the direct trust path.

We’re having a hard time understanding this comment. Can you please share more?

If OISTE issued a cross-certificate from OISTE WISeKey Global Root GB CA to OISTE Server Root RSA G1, it’s unclear what additional requirements this would impose. Both hierarchies are already expected to adhere to root program policies and the TLS BRs. It’s unclear how a cross-certificate would meaningfully change that.

It is also expected that because of OISTE Server Root RSA G1’s inclusion in NSS, CT log operators will be compelled to add it to the set of acceptedRoots relied upon by those logs. The intent of our comment was to highlight that a faster path without third-party dependencies exists (i.e., cross-certificate approach).

Comment 15

[Pedro Fuentes]

(In reply to chrome-root-program from comment #14)

[In response to Comment 13]

Also, as per my understanding, even if we create an alternate trust path, we'd still need to be compliant with the Root Programs and BR, and being able to issue test certificates (valid, revoked, expired) under the new roots, so we'd still need to have CT compliance under the direct trust path.

We’re having a hard time understanding this comment. Can you please share more?

If OISTE issued a cross-certificate from OISTE WISeKey Global Root GB CA to OISTE Server Root RSA G1, it’s unclear what additional requirements this would impose. Both hierarchies are already expected to adhere to root program policies and the TLS BRs. It’s unclear how a cross-certificate would meaningfully change that.

It is also expected that because of OISTE Server Root RSA G1’s inclusion in NSS, CT log operators will be compelled to add it to the set of acceptedRoots relied upon by those logs. The intent of our comment was to highlight that a faster path without third-party dependencies exists (i.e., cross-certificate approach).

Thank you for clarifying — this helps a lot.

We now understand that your suggestion referred to cross-signing the new root (e.g., OISTE Server Root RSA G1) with an existing trusted root (e.g., OISTE WISeKey Global Root GB CA) to facilitate CT logging and avoid dependency on log operator updates. Our previous response was based on the assumption that the cross-signing would apply to the issuing CAs rather than the roots.

Also, I probably didn’t express myself clearly before — I didn’t mean to suggest that cross-signing would affect compliance requirements, only to emphasize that our preference remains for the new roots to be directly recognized by CT logs to maintain a clean and independent trust path. We appreciate the suggestion and will review this option internally.

FYI. Right now the new roots are already in the Google CT Logs and we have ongoing requests for other Log operators, so we can fulfill the CT Policy requirements.

Comment 16

[Pedro Fuentes]

(In reply to Ben Wilson from comment #5)

Next Step: OISTE/WiseKey will need to have these root CA certificates enabled for CT logging and obtain the necessary SCTs for its test websites in order to comply with Mozilla's CT Policy.

Hi Ben,
this had been done (e.g. https://rsag1validssl.hightrusted.com)
We appreciate the collaboration of the CT Log operators that already included the new Roots.
Best,
Pedro

Comment 17

[Ben Wilson]

Hi Pedro,
Do you have any EV certificates issued under these root hierarchies that I can check for EV enablement?
Thanks,
Ben

Comment 18

[Pedro Fuentes]

Hi Ben,
Sure, you can check:
https://eccg1evvalidssl.hightrusted.com which is issued under "OISTE Server Root ECC G1"
and
https://rsag1evvalidssl.hightrusted.com which is issued under "OISTE Server Root RSA G1"

Thanks,
Pedro