All,
This is to announce and begin public discussion of certSIGN’s intent to use its publicly trusted certSIGN ROOT CA (https://crt.sh/?id=6385) to create a new external subordinate CA to be operated and maintained from the Netherlands by KPN B.V., www.kpn.com. See Mozilla Root Store Policy, Section 8 - CA Operational Changes.
The proposed procedure for approving externally operated CAs contemplates that the root CA would start the public discussion here, but since that procedure has not become final, I’m going to start this discussion now, and I have opened a bug for this in the CA Certificate Root Program component in Bugzilla- Bug 1718666.
The certSIGN-KPN subordinate CA will issue publicly-trusted OV TLS server certificates. KPN will be required to follow all Mozilla requirements, Baseline Requirements of the CA/Browser Forum, and the certSIGN CPS, which were the main criteria used by certSIGN in selecting KPN to operate this new, third-party, intermediate certSIGN Sub-CA.
KPN successfully passed certSIGN’s approval process and verification procedures as a subordinate CA. Section 1.3.1 of certSIGN’s CPS states, “Any external entity wishing to operate a CA subordinated to the certSIGN ROOT CA has to sign first an agreement stating its obligations to follow the current CP and CPS versions and to pass an external audit for verifying compliance with the WebTrust for CA standard, or equivalent.”
All the operational services related to the Subscribers of the new CA will be performed by KPN, namely client registration and identification, processing of certificate applications, certificate issuance, certificate publishing, certificate status services, and certificate management.
KPN will fulfill the role of a certSIGN Subordinate Certification Authority according to contractual obligations to observe the requirements of: the Mozilla Root Store Policy Program, the CA/Browser Forum’s Baseline Requirements, Microsoft’s Trusted Root Program, the Chrome Root Program, the Apple Root Store Program, certSIGN’s CP/CPS, the WebTrust Principles and Criteria for Certification Authorities, and the WebTrust Principles and Criteria for Certification Authorities – SSL Baseline with Network Security.
The new Sub-CA will not be technically constrained and will not have any subordinates. certSIGN will ensure the services for the creation, status, and management of the Sub-CA certificate.
KPN will maintain an annual WebTrust audit of all its operational services associated with the new CA. Thus, certSIGN will not add the new sub-CA into its yearly WebTrust audits, as it will be separately audited.
This email begins a 3-week comment period ending 20-July-2021, after which we will consider approval of certSIGN’s request.
Thanks,
Ben Wilson
Mozilla Root Store Program
Regarding the audit, we have provisions in the agreement with KPN that KPN shall perform a WebTrust or ETSI audit, as we previously stated “KPN will maintain an annual WebTrust audit of all its operational services associated with the new CA. Thus, certSIGN will not add the new sub-CA into its yearly WebTrust audits, as it will be separately audited."
I want to explain the reasoning for KPN to seek a Sub Ca under the Certsign Root CA. KPN is currently one of the PKIoverheid Certificate Service Providers in the Netherlands. KPN (previously PinkRoccade, Getronics PinkRoccade, Getronics) has operated ETSI and Webtrust certified (sub)CAs for over 15 years.
KPN issues PKIoverheid private certificates for machine-to-machine communication, PKIoverheid public qualified certificates for signing & encryption and also PKIoverheid public server certificates. KPN has done this for a long period and we are accustomed to ETSI (ETSI EN 319 411-1/2) and Webtrust (Principles and Criteria for Certification Authorities, version 2.2.1) audits. All KPN PKI-related documentation can be found here: https://certificaat.kpn.com/support/downloads/repository/
Our customers for public server certificates are mostly public entities, such as municipalities and (semi)government organizations. These customers buy private server certificates as well as public OV server certificates for their websites. PKIoverheid acts as a Super CA for all those certificates and government institutions are required by law to use PKIoverheid certificates.
PKIoverheid has announced they will stop with public OV server certificates and will not have a new root CA trusted for public TLS certificates. Therefor the customers of PKIoverheid OV-TLS certificates will be forced to use non-PKIoverheid certificates. As the current public PKIoverheid root will expire in December 2022, we cannot issue new 1-Year valid public OV server certificates after early December 2021.
To offer our customers continuity and a one-stop shop we need an alternative Trusted root to issue OV-TLS certificates.
KPN has considered establishing its own Root CA, but the process would take too long and would be impossible to complete and get trusted in all major trust stores in such a short time frame. The reselling of other commercially available OV-TLS certificates would decrease the customer experience since end customers who need to buy both private PKIoverheid as well as public TLS certificates would have to experience two production lines.
KPN selected Certsign for the creation of a Sub CA under the Certsign Trusted Root. Certsign is already a technical partner with KPN in the European Tachograph field and is willing to help KPN continue its portfolio completeness. KPN agreed with Certsign pre-issuance linting has to be implemented (based on zlint) and KPN agreed that EY will audit KPN yearly based on Webtrust.
KPN
has considered opting for a public Root CA or a cross signed CA (for an
intermediate period).
However, this would inconvenience our clients that use private PKIoverheid ov-TLS and
public ov-TLS certificates.
Our findings show that for establishing a public
root:
1. the expected lead time for all browsers, operating systems and mobile devices will (by far) exceed our deadline of December 2021;
2. the costs of establishing and
maintaining contacts with the root store owners are not profitable for
KPN,
considering the small volume in the niche market we operate in.
Cross signing might be a workaround for 1., but still imposes the costs in 2.
We
respect your opinion that a ‘dual validation process’ does not outweigh the
creation of new Sub CA.
From our customers perspective
(majority Dutch government entities and municipalities) our findings show,
that
our clients expect one customer journey for PKIoverheid private OV-TLS and public
OV-TLS certificates,
by maximizing the validated customer data.
A Sub
CA will provide in this demand. KPN and its predecessors are accustomed to operating
a sub CA.
Combined with CertSign’s Root CA, we can provide the best solution for
our customers.
KPN has considered opting for a public Root CA or a cross signed CA (for an intermediate period).
However, this would inconvenience our clients that use private PKIoverheid ov-TLS and public ov-TLS certificates.
Our findings show that for establishing a public root:1. the expected lead time for all browsers, operating systems and mobile devices will (by far) exceed our deadline of December 2021;
2. the costs of establishing and maintaining contacts with the root store owners are not profitable for KPN,
considering the small volume in the niche market we operate in.Cross signing might be a workaround for 1., but still imposes the costs in 2.
We respect your opinion that a ‘dual validation process’ does not outweigh the creation of new Sub CA.
From our customers perspective (majority Dutch government entities and municipalities) our findings show,
that our clients expect one customer journey for PKIoverheid private OV-TLS and public OV-TLS certificates,
by maximizing the validated customer data.A Sub CA will provide in this demand. KPN and its predecessors are accustomed to operating a sub CA.
Combined with CertSign’s Root CA, we can provide the best solution for our customers.
2. the costs of establishing and maintaining contacts with the root store owners are not profitable for KPN,
considering the small volume in the niche market we operate in.
We respect your opinion that a ‘dual validation process’ does not outweigh the creation of new Sub CA.
From our customers perspective (majority Dutch government entities and municipalities) our findings show,
that our clients expect one customer journey for PKIoverheid private OV-TLS and public OV-TLS certificates,
by maximizing the validated customer data.
On Mon, Jul 5, 2021 at 11:27 PM Matthew Hardeman <mhar...@gmail.com> wrote:
>
> On Mon, Jul 5, 2021 at 1:34 PM 'Sander Steenbergen' via dev-secur...@mozilla.org <dev-secur...@mozilla.org> wrote:
>>
>> 2. the costs of establishing and maintaining contacts with the root store owners are not profitable for KPN,
>> considering the small volume in the niche market we operate in.
>
> This seems to be an admission against interest. Having an externally managed SubCA implies all the burdens of being an independent Root CA and with the capability to risk both your own institutional reputation as well as that of your sponsoring CA. Which is probably why a cross-sign for the pendency during which a new CA becomes an independent root member is probably the scenario more likely seen these days.
(writing only for myself in a personal capacity)
It seems many who have not been involved with operating a publicly
trusted CA underestimate the effort delta between running a subCA and
running a rootCA + subCA. Root CAs are unique beasts that operate
very differently, as required by Mozilla policy and the CABF BRs.
Most CAs I'm aware of run a completely separate software stack for the
root CAs because the roots are required to be offline and only issue a
very small number of certificates. This significantly increases audit
costs and operational costs as one must have the root processes with
unique controls and audits and then the online CAs with their controls
and audits.
It also seems that many over-estimate the willingness of existing CAs
to cross-sign a proposed root. Cross-signing a root has every risk
that a subCA has plus has significant downside as you are enabling a
potential competitor.
>> We respect your opinion that a ‘dual validation process’ does not outweigh the creation of new Sub CA.
>> From our customers perspective (majority Dutch government entities and municipalities) our findings show,
>> that our clients expect one customer journey for PKIoverheid private OV-TLS and public OV-TLS certificates,
>> by maximizing the validated customer data.
>
> The position of the browsers on the value of OV certificates has been made pretty clear. None of the major browsers treat them with any higher regard than a domain-validated certificate today.
>
> While it IS likely that your customers have a different expectation of the ideal path to acquiring certificates, a CA's customers' concerns are broadly regarded as less important than the entire set of users worldwide who rely upon secure CA management & certificate issuance practices.
>
I think that they made it pretty clear that is not the goal. Quoting
KPN: "PKIoverheid has announced they will stop with public OV servercertificates and will not have a new root CA trusted for public TLScertificates." To me it appears KPN is trying to follow the guidance
that has been given in this forum many times, which is to only use
publicly trusted WebPKI certificates where necessary and use private
PKIs elsewhere. We should be applauding them for trying to make
private PKI easy for their customers.
I appreciate that identity information in server certificates beyond
DNS names and IP addresses is not used by browsers. However the
Mozilla Root Store Policy still calls out EV certificates as being
recognized and requires the CA to follow the latest version of the
Extended Validation Guidelines. Until the Mozilla policy changes to
remove EV certificates as a special case and until Mozlla adds
including "offline" identity information as a problematic practice, I
don't think it is fair to penalize CAs for planning to issue
certificates allowed under the policy.
Thanks,
Peter
Most CAs I'm aware of run a completely separate software stack for the
root CAs because the roots are required to be offline and only issue a
very small number of certificates.
It also seems that many over-estimate the willingness of existing CAs
to cross-sign a proposed root. Cross-signing a root has every risk
that a subCA has plus has significant downside as you are enabling a
potential competitor.
To me it appears KPN is trying to follow the guidance
that has been given in this forum many times, which is to only use
publicly trusted WebPKI certificates where necessary and use private
PKIs elsewhere. We should be applauding them for trying to make
private PKI easy for their customers.
Until the Mozilla policy changes to
remove EV certificates as a special case and until Mozlla adds
including "offline" identity information as a problematic practice, I
don't think it is fair to penalize CAs for planning to issue
certificates allowed under the policy.