Public Discussion of certSIGN's Externally Operated CA by KPN

[Ben Wilson]

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

[Ryan Sleevi]

KPN is not exactly a stranger to the Mozilla program; they presently operate a sub-CA under the PKIoverheid Super-Root, as well as previously having operated a sub-CA under DigiCert.

Relevant to this discussion would be a consideration of the incidents. Not every incident was clearly tagged with the sub-CA, in part, because we ultimately hold the root accountable for supervision. This, however, also means we should consider the Root CAs incidents, to better understand how the root CA (certSIGN) will understand the requirements and expectations and appropriately supervise them.

• Bug 1539296 - DigiCert: KPN Outdated Audit
• Bug 1596923 - PKIoverheid: KPN CPS lacks problem reporting instructions
• Bug 1535871 - PKIoverheid: KPN Insufficient Serial Number Entropy
• Bug 1709650 - PKIoverheid: KPN issued Invalid organizationalUnitName
• Bug 1718675 - certSIGN: CPS specifies md5 and sha1WithRSAEncryption as useable signature types
• Bug 1551375 - certSIGN: "Some-State" in stateOrProvinceName
• Bug 1674886 - certSIGN: misissued an OV SSL certificate with no organizationName and localityName, instead of a DV SSL as requested by client
• Bug 1390979 - certSIGN: Non-BR-Compliant Certificate Issuance
• Bug 1398243 - certSIGN: Non-BR-Compliant OCSP Responders

As called out in Bug 1709650, Comment #5, KPN does not presently implement pre-issuance lints, although they are working on it. That's very surprising for June 2021, and KPN also is in the process of replacing their CA infrastructure.

certSIGN's track record is not particularly encouraging, although worth noting that several of these issues are several years old. It's unclear, however, if that's actually dispositive towards there being nothing problematic, or whether it's simply that certSIGN hasn't been analyzed in the same way other CAs have been recently. It could also be a function of the number of certificates issued. For example, the mere existence of https://crt.sh/?id=50901500 is not exactly something we should find encouraging, even if there's no observed misissuance.

This appears to be certSIGN's first cross-signing operation. What evidence do we have about certSIGN's preparedness for the level of supervision and oversight necessary? Symantec, DigiCert, and PKIoverheid all had prior experience with respect to cross-signs, and at least in the example of the latter two, have had some of their incident reports and strategies held up as exemplary for the community, and even led to discussions of policy changes based on that ( https://github.com/mozilla/pkipolicy/issues/182 )

Similar to understanding certSIGN's approach to managing this relationship, it's equally useful to understand KPN's goals in pursuing it, especially given the existing relationship with PKIoverheid. PKIoverheid has continued to have an approach to incident management worth holding up to other CAs, showing that they are actively monitoring discussions in the CA/Browser Forum, CA incidents, and dev-security-policy, and proactively making changes, such as around OUs and certificate lifetimes, well before such changes are mandated. One possibility is that KPN (which is contractually obligated to follow these) is looking to contract with a more lax organization, which would be problematic. While I realize there are plenty of potentially benign explanations, I think the possibility there benefits from added transparency by KPN about their goals.

Equally important is to understand why this relationship requires a dedicated CA, with all the attendant risks. The technical reality is that this is rarely needed, and given the risks posed to users in the community, seems reasonable for the burden of demonstration to be placed on KPN as to why this is the best path (for the community and for Mozilla users) compared to alternatives, such as technically constrained sub-CAs or, quite simply, not pursuing such a relationship. Here again, a possible explanation may be that KPN wishes to perform OV/EV levels of validation. While the pursuit of a sub-CA is absolutely more transparent to this community, compared to pursuing an RA relationship (given that RAs have been perennially dogged by failures), it's worth asking if KPNs desire to perform OV/EV for their user community outweighs the risk to this community of yet-another-organization performing domain validation, key protection, and all the other critical elements of an audited CA.

Finally, we have no disclosure about the intended audit scheme and auditors. Hopefully the above issues capture why this is and should be a matter of concern for the broader community.

Ultimately, I don't think, given the information provided, and the known risks, this would be a positive development for users. But I do think this discussion provides a good opportunity for certSIGN and KPN to address these concerns, much like a new CA inclusion would, to help understand the risks, benefits, and approach to compliance, that would help offset those concerns.

[Ryan Sleevi]

On Wed, Jun 30, 2021 at 10:25 AM Gabriel Petcu <gabrie...@certsign.ro> wrote:

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."

Hi Gabriel,

While that's ostensibly the minimum required by the Baseline Requirements, it's also a strategy that, alone, has been shown not to produce the right results. I do fear you may have misunderstood the concern, based on your response, and that fits with my general unease about seeing this relationship happen.

• Specifically, which is it: Is it WebTrust, or is it ETSI?
• The DigiCert incident shows there were incidents with the ETSI audit, which is why DigiCert explicitly required a WebTrust audit
• The choice - whether certSIGN allows KPN to choose which audit scheme and which auditor - reveals a lot about certSIGN's approach to sub-CA supervision, and whether it's familiar with and taking steps to prevent issues we've seen in the past.
  
• Whether there are additional contractual provisions applied on the audit, as there have been in the past (again, by other CAs I've referenced)
  
• Whether certSIGN is relying on audits alone, or has a more comprehensive compliance strategy in place

More concretely, it's best perhaps to think about it this way:

• If certSIGN will be immediately, comprehensively, and retroactively removed if KPN has a single incident - whether it be as "small as" a typo in a single field or "as large as" an unauthorized certificate for, say, mozilla.com - what would certSIGN do differently than it currently proposes?

That is, would you be willing to stake all of certSIGN's future, and all of certSIGN's customers, on KPN's auditor detecting and preventing issues before this? That's what cross-signing a CA is committing to, and it's unclear if you fully understand and appreciate that risk to certSIGN, which is simply a reflection of the risk that new root/sub-CAs pose to the broader community.

[Sander Steenbergen]

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.

[Matt Palmer]

On Thu, Jul 01, 2021 at 01:30:20AM -0700, 'Sander Steenbergen' via dev-secur...@mozilla.org wrote:
> 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.

My understanding is that most CAs use a cross-signature from an established
CA while they are going through the inclusion process for the various trust
stores. To what extent has KPN investigated the feasability of this route?

> 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.

By "production line", are you referring to validation processes? If so,
speaking for myself, I don't find that argument particularly compelling.
The need for your customers to validate their information twice, for
example, for two separate certificates does not seem like a sufficiently
onerous imposition to justify the need for an independent subordinate CA,
without the oversight afforded by being a direct Mozilla trust store
participant.

At the very least, I think it would be helpful if you could expand on this
point significantly, if you feel that the customer experience is indeed
unacceptable unless you have an independently-operated sub CA.

- Matt

[Sander Steenbergen]

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.

best regards,

Sander

[Ryan Sleevi]

On Mon, Jul 5, 2021 at 2:34 PM 'Sander Steenbergen' via dev-secur...@mozilla.org <dev-secur...@mozilla.org> wrote:

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.

Sander,

Thanks for these details. To be honest, I think they reflect the growing concern here with proceeding as planned.

To your first point, I agree, this is a challenge. However, it's a challenge for a reason, and the reason speaks to the broader concerns with your second point.

You mention the cost and challenge of operating as a root CA, maintaining contact with various root programs, and, presumably, complying with various root programs requirements, whether they be contractual, technical, or even just communicative (like CA communications). The reality is that what KPN proposes is indistinguishable in risk to the user community as operating a root CA, but as you highlight, the proposed path would allow KPN to not have to account for that risk, and that's the concern.

As a sub-CA, you'll still be expected to do everything a root CA does, because you will pose the same risk. There is no cost savings here, and if there is, it suggests that KPN may not be performing as expected.

It's interesting that you highlight the desire for OV-TLS, which has zero security benefit to users, has zero technical interaction with TLS libraries, and poses significant and ongoing risks to agility, stability, and predictability of certificates. This is true whether private PKI or public PKI, but it should be particularly concerning that this is the path being proposed for a modern, 2021 CA certificate. You framed this in terms of "our customers desire", but without any analysis of the corresponding risk to users.

For example, one significant challenge with DigiNotar, a previous PKIoverheid participant, was in helping Dutch government entities and municipalities migrate away from DigiNotar and on to other CAs, so they would not disrupt users with warnings. The path you've outlined, issuing OV TLS certificates, would similarly present such a migration challenge, should KPN be later removed/revoked, because OV certificates fundamentally do not lend themselves to automation. Even if they were automated, the practice of OV validation would still introduce artificial delays in obtaining certificates, due to validation practices. This would create a tension for KPN: would it pursue laxer validation, to support the security-positive goal of quicker issuance, or would it require slow and manual processes, making security of users weaker by making TLS unnecessarily difficult and time-consuming to deploy? Further, should the need to migrate from KPN to another CA, these customers will be faced not only with the same challenge you seek to avoid now, but also even greater delays, as whatever new CAs need to perform validation themselves. If these customers relied on data in the OV certificate (e.g. "OV pinning"), this could be fatal: there's no guarantee another CA can or will represent data the same way in certificates.

Everything about your plan outlined currently screams "risk to security". It's a risk because you acknowledge that the costs of good security practices are too high. It's a risk because the plan is pursuing a type of certificate that has no security benefit to TLS users, at best, and is harmful to them, in practice. The substantive differences called out, in CA management and sub-CA strategies by other CAs, do not appear to have connected with KPN or CertSign management, thus suggesting not only will this not be "good practice", but that it may not even meet "minimum expectations".

Because all of the risk of KPN is assumed by this community - Mozilla and Google users - it may be best if you can articulate the value, not to your customers, but to these users, as well as detail your plans to minimize risk using industry good practices.

[Matt Palmer]

On Mon, Jul 05, 2021 at 11:34:41AM -0700, Sander Steenbergen 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.

Surely the vast majority of the cost of operating a CA is in the security
practices, audits, staff, and operations required to be an
independently-operated, publicly-trusted CA, and not the costs of
communicating with root stores? Looked at another way, if the costs of
communication are a significant part of CA operations, I would posit that
something, somewhere has gone terribly, horribly wrong.

In any event, you'd still have to communicate with the root CA of whom you
are a sub CA, so that they can communicate effectively on your behalf to the
trust stores.

Since you brought up costs, I find it hard to believe that it would be
cheaper for KPN to pay a root CA for the time and effort to properly review
and administer the audits and other communications involved -- and also
price in the risk that any failure of KPN may put the root CA's own
operations in jeopardy -- than for KPN to operate a root CA themselves. A
root CA, in effect, outsources the work (and cost) of reviewing and
supervising the CA and its audits to Mozilla and the other trust store
operators (none of whom, as far as I am aware, require payment from CAs to
perform this work). This leads me to be concerned that the supervising root
CA may not have accounted for all the work involved in properly supervising
KPN's sub CA operations.

If the required work of supervising a sub CA is not fully funded, this would
itself be a very concerning state of affairs. An improperly supervised
independently-operated sub CA is a huge risk to the ecosystem. Conversely,
an arrangement on which the root CA loses money is unlikely to continue
long-term, and unwinding a CA's operations is itself one which has a
significant risk of causing problems for relying parties, such as loss of
stable and reliable revocation services.

> 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.

As Ryan has mentioned, the expectations of your customers, whilst one
element to be considered, do not supercede or override the expectations of
relying parties, which Mozilla and this group represent. Without describing
how the arrangement you seek serves the needs of relying parties, it is hard
for me to see how Mozilla could be keen to accept the risk of said
arrangement.

- Matt

[Matthew Hardeman]

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. 

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.

Moreover, I would suspect that the primary thing that many of your customers want is a "PKIoverheid" certificate which is both trusted inside the scope of the PKIoverheid hierarchy as well as the general WebPKI trust hierarchy.  I don't think there's any strategy that gets you to that endpoint.

[Andrew Ayer]

The CPS for KPN's current intermediate CA under PKIoverheid
(https://certificaat.kpn.com/files/CPS/KPN_PKIoverheid_CPS_v5.5_English.pdf)
says on page 34 that KPN uses method 3.2.2.4.6 for domain validation,
which is forbidden.

In light of
https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/CDal5qSIYvE
it seems like KPN is not monitoring mdsp, which may be reflective
of their troubling belief
(https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/ahCHlHVEHaw/m/ZnYmalKLAQAJ)
that operating an external sub-CA allows them to save money by avoiding
interactions with root programs.

I have to agree with others in this thread that this proposed plan looks
risky for Mozilla users.

Regards,
Andrew

[Watson Ladd]

On Mon, Jul 5, 2021 at 11:34 AM 'Sander Steenbergen' via
dev-secur...@mozilla.org <dev-secur...@mozilla.org>
wrote:
>

> 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.

Your clients should be using automated methods for certificate
issuance. OV is not providing anything beyond DV for the general
public. Failure to automate makes it impossible to switch providers
and reissue quickly, a necessary function since distrust can happen at
any time for any reason.

Sincerely,
Watson Ladd


--
Astra mortemque praestare gradatim

[Peter Bowen]

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.
>
> Moreover, I would suspect that the primary thing that many of your customers want is a "PKIoverheid" certificate which is both trusted inside the scope of the PKIoverheid hierarchy as well as the general WebPKI trust hierarchy. I don't think there's any strategy that gets you to that endpoint.

I think that they made it pretty clear that is not the goal. Quoting
KPN: "PKIoverheid has announced they will stop with public OV server

certificates and will not have a new root CA trusted for public TLS

certificates." 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

[Matt Palmer]

On Tue, Jul 06, 2021 at 09:42:18PM -0700, Peter Bowen wrote:
> 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.
>

> 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.

That's as may be, but KPN's objections to being a direct participant of root
store programs was "the costs of establishing and maintaining contacts with
the root store owners". If the cost of operating the root CA itself was an
issue, I would expect KPN to have stated that.

> 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.

If and when KPN is in the situation you hypothesise, then that should be
brought to the attention of the community, with all relevant details, and it
can be discussed. Otherwise we'll be discussing an abstract situation,
which will no doubt vary in the particulars from the situation actually in
existence, and thus the discussion will be unlikely to provide helpful
outcomes.

- Matt

[Watson Ladd]

On Tuesday, July 6, 2021 at 9:42:32 PM UTC-7 pzb...@gmail.com wrote:

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. 

I think some people, myself included, conflate CA the organization and the chain of certificates they use.  We also tend to focus a lot on issues involving validation of the information attached to end entity 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.

Signing a subCA also enables a competitor! Without technical constraints the subCA is capable of signing any certificate, and unlike a root CA where Mozilla can independently assure itself of the safe operation,

>> 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 server

certificates and will not have a new root CA trusted for public TLS

certificates." 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.

PKIoverheid has only discussed OV validations, and wanting to simplify the process of obtaining OV certificates. Furthermore, while the private PKI can do what it wants, the public Web PKI demands certain standards in the validation of the information in certificates. Reusing the information thus extends the trust required.

Thanks,
Peter

[Ryan Sleevi]

On Wed, Jul 7, 2021 at 12:42 AM Peter Bowen <pzb...@gmail.com> wrote:

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. 

While not wanting to discount your personal experiences on the operational side, if there is any discounting occurring, it's simply because the publicly available details don't support the point you're making. I think if this is a point that should be considered, it certainly should be incumbent upon KPN to provide those concrete details, rather than us speculating on their behalf, or at least, making positive assumptions.

Outside of a browser vendor, there is no other organization that can have the most negative influence on a user's browsing security than a CA. We hold CAs to high standards, including on transparency, precisely because of that, and so we cannot make affordances that we might otherwise want to give to individuals and participants here, with respect to assuming "good" intent even when unstated.

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.

As Watson points out, this argument does not actually seem to hold up to scrutiny. There is nothing inherently preventing a cross-signed sub-CA from subsequently applying as a root CA. As I know you're personally familiar with, because of your significant contributions to improving the space, the distinction between a root and a subordinate CA, with respect to key generation ceremonies, does not have a functional distinction other than simply what the CA chose to do at the time. That's not to say there aren't ways to game it, if a root CA is trying to prevent the sub-CA from ever being a competitor, but that's not the norm either.

 

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 think there's a conflation of principles here. We certainly should be applauding PKIoverheid, and I hope my previous message came across as such, as the drivers of this change. PKioverheid has indeed been on top of many changes to the TLS ecosystem and adopting their policies to reflect good practices here. However, that's not the same as KPN, and unlike trust, such accolades do not chain downwards.

What is distinctly missing here, however, and it's unclear if the curious omission from this message was intentional, was that KPN has not actually provided substantive explanation as to why the public PKI needs to share any relationship. If anything, the plan outlined by KPN shows very much the problematic practice that the purpose of private PKIs seeks to solve: namely, KPNs stated benefits (for their customers, not necessarily browser users) is that their customers can use the same validation practices for both their private and public PKIs.

That combination of trust frameworks is very much called out in the past by Mozilla as something that can impair agility and security, at least in the context of eIDAS and TLS. Perhaps you could share more detail if you see there being a functional difference between combining {eIDAS scheme, with separate policies, policy authorities, and audits} with TLS and {PKIoverheid scheme, which is-a eIDAS scheme, and with separate policies, policy authorities, and audits} and TLS. For me, I functionally cannot see a difference here in the principles or risks, and that's why it bears calling out. I hope my previous message highlighted that.

 

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.

While I have no doubt this was meant with the best of intentions, there's quite a bit of problematic logic at play here to reach this conclusion. The statement here seems to suggest that the community should ignore the broader risks at play here, as shown by things such as the CA incident dashboard, unless and until it performs a step change for the entire ecosystem. To the best of my knowledge, this doesn't match how root programs have ever operated. Accepting a new CA, whether root or sub-CA, always brings new risks, and the act of reviewing CAs has always been to use the best available information at the time in order to assess the risk that the new relationship would pose to browser users. For example, CP/CPS reviews have never "simply" looked at say the BRs, WebTrust principles, or ETSI's checklists: they've carefully analyzed the statements and considered CA incidents that have happened, to understand how this particular CA approaches and mitigates those risks. Or, for that matter, the fact that new CAs get CP/CPS reviews, while existing CAs don't, is perhaps telling itself that new CAs are always subjected to more scrutiny.

That's because once a browser enters into a partnership with a CA, allowing that CA to provide security services for the browser vendor (as the relationship is not to the browsers' users, but rather, to the browser itself), the browser is assuming the risk on behalf of their users. Existing CAs present existing risk, and while that's hardly ideal, it also provides an ample number of datapoints to help evaluate and manage that risk. New CAs generally lack those data points, such as historic operation and practices, and so even greater scrutiny must be applied based on the available information and proposed practices.

We equally see this "unequal" treatment of risk (even though it's simply trying to adjust for the information asymmetries of extant vs new CAs) when looking at key lifecycle management. New CAs are expected to provide audits from the moment of root creation, and inclusion requests are regularly and consistently rejected when a CA approaches with some existing, legacy root they have, requesting for inclusion. Meanwhile, however, there are plenty of already-included CAs that lack such provenance and clean audit history, because they are, in effect, "grandfathered in" as part of the accepted risk. The most recent Mozilla CA Communication seeks to explore correcting that, but of course it remains that new CAs are still being treated differently.

Note that I didn't suggest the mere act of issuing OV was itself disqualifying. However, combined with the other statements from KPN, and from the historic practices of KPN, certSIGN, and the broader set of CA incidents, it unquestionably and undeniably introduces substantial risk - risk that is more clear now than when EV was introduced, and certainly obvious even then in the context of OV. My previous message highlighted several of these systemic risks, and importantly, how KPNs own apparent lack of familiarity with these concerns, as reflected by them taking no steps to address them or even acknowledge them previously, fits a troublesome pattern.

This is why I think your logic is flawed: you conflated the concern as the act of simply issuing OV at all, when the concern is more holistic, and encompasses the focus on OV, the lack of suitable controls for the failings of OV, and the combination of trust frameworks at the validation level, even when there is technical separation. This is a perfect storm for disaster, which we've seen amply played out previously.

[Sander Steenbergen]

Carefully reading through all the comments in this discussion has provided us with new insights. 

We decided that KPN will currently not pursue its own sub CA under the Certsign Root CA.

I want to thank everyone who has commented on this forum and took the effort to engage in this discussion. 

Special thanks to Andrew Ayer for notifying KPN of the shortcoming in our CPS, 

this will be addressed in https://bugzilla.mozilla.org/show_bug.cgi?id=1719451.

best regards,

Sander