Public Discussion of CommScope CA Inclusion Request
Ben Wilson
All,
This email commences a six-week public discussion of CommScope’s request to include the following four (4) certificates as publicly trusted root certificates in one or more CCADB Root Store Member’s program. This discussion period is scheduled to close on October 10, 2023.
The purpose of this public discussion process is to promote openness and transparency. However, each Root Store makes its inclusion decisions independently, on its own timelines, and based on its own inclusion criteria. Successful completion of this public discussion process does not guarantee any favorable action by any root store.
Anyone with concerns or questions is urged to raise them on this CCADB Public list by replying directly in this discussion thread. Likewise, a representative of the applicant must promptly respond directly in the discussion thread to all questions that are posted.
CCADB Case Number: 00000923; Bugzilla: 1673177
Organization Background Information (listed in CCADB):
CA Owner Name: CommScope
Website(s): https://www.pki-center.com/, https://cert.pkiworks.com/Public/Portal, https://www.commscope.com/
Address: 6450 Sequence Drive, San Diego CA 92121
Problem Reporting Mechanism(s): https://cert.pkiworks.com/Public/SecurityIncidentReport/ or email to #Advanced-PKI-P...@commscope.com
Organization Type: CAs are owned by wholly owned subsidiaries of CommScope Holding Company, Inc., a NASDAQ-traded company
Repository URL: https://certificates.pkiworks.com/Public/Documents/
Certificates Requesting Inclusion:
CommScope Public Trust RSA Root-01:
Certificate download links: (CA Repository, crt.sh)
Use cases served/EKUs:
Server Authentication (TLS) 1.3.6.1.5.5.7.3.1
Client Authentication 1.3.6.1.5.5.7.3.2
Test websites:
CommScope Public Trust RSA Root-02:
Certificate download links: (CA Repository, crt.sh)
Use cases served/EKUs:
Server Authentication (TLS) 1.3.6.1.5.5.7.3.1
Client Authentication 1.3.6.1.5.5.7.3.2
Test websites:
CommScope Public Trust ECC Root-01
Certificate download links: (CA Repository, crt.sh)
Use cases served/EKUs:
Server Authentication (TLS) 1.3.6.1.5.5.7.3.1
Client Authentication 1.3.6.1.5.5.7.3.2
Test websites:
CommScope Public Trust ECC Root-02
Certificate download links: (CA Repository, crt.sh)
Use cases served/EKUs:
Server Authentication (TLS) 1.3.6.1.5.5.7.3.1
Client Authentication 1.3.6.1.5.5.7.3.2
Test websites:
Relevant Policy and Practices Documentation:
The following applies to all four (4) applicant root CAs:
https://certificates.pkiworks.com/Public/DownloadDocument/18 (CP/CPS v. 2.6 dated 2/10/2023)
Most Recent Self-Assessment:
The following applies to all four (4) applicant root CAs:
https://bugzilla.mozilla.org/attachment.cgi?id=9281545 (completed 6/15/2022)
Audit Statements:
Audit Criteria: WebTrust
Date of Audit Issuance: 9/5/2022
For Period Ending: 6/30/2022
Audit Statement(s):
Risk-vs-Value Justification:
Thank you,
Ben, on behalf of the CCADB Steering Committee
Yuwei HAN (hanyuwei70)
Can CA explain what can be improved if accepted to Mozilla Root Program?
Ben Wilson
From: So, Nicol <nico...@commscope.com>
Date: Wed, Aug 30, 2023 at 6:10 PM
Subject: RE: Public Discussion of CommScope CA Inclusion Request
To: CCADB Public <pub...@ccadb.org>
Cc: Ben Wilson <bwi...@mozilla.com>
On Monday, August 28, 2023 at 5:49 PM, Yuwei HAN (hanyuwei70) wrote:
> Giving that there were so many TLS CAs, I don't see any necesssity to add another TLS CA unless something new is provided by CA.
> Can CA explain what can be improved if accepted to Mozilla Root Program?
CommScope has been delivering CA and device identity provisioning services across 200+ OEM/ODM/repair locations spanning 30+ countries. Besides being a device manufacturer itself, CommScope also serves customers and partners, such as Motorola and Broadcom. Additionally, we have successfully provided over-the-air solutions to more than a dozen leading domestic and international service providers, such as Verizon and T-Mobile, enabling them to upgrade device cryptographic identities and enhance security in real-world deployments. The devices we touched include mobile phones, wireless access points, mobile network base stations, home gateways, cable modems, and set-top boxes. We are expanding our services to IoT devices. We understand the challenges device manufacturers and service providers face trying to meet the PKI requirements from industry consortia such as CableLabs, WInnForum, and CSA. We have seen and have solved the problems that arise in global manufacturing operations and post-deployment network operations, such as duplicate device identities and network trust changes. Over the years, we’ve securely installed over 6 billion sets of device identity credentials through different channels at different stages of device lifetime.
CommScope is more than just a standard CA. With its wealth of experience dealing with device manufacturing, deployment and operation, we are also well positioned to serve device manufacturers and operators of device fleets, whose requirements are not the same as typical web site operators.
Sincerely,
Nicol So
Yuwei HAN (hanyuwei70)
IoT devices do post a new challenge to PKI ecosystem because they are extremely difficult to update. I hope your company could serve community well.
Andrew Ayer
empty SCT extensions. Per RFC 6962 Section 3.3, SCT extensions MUST
contain at least one SCT.
I'm very concerned that the primary use for this CA will be issuing
certificates for embedded systems such as set top boxes, cable modems,
IoT devices, and the like. Embedded systems tend to run out-of-date
software which never receives updates. Historically, using
publicly-trusted certificates with embedded systems has harmed the
WebPKI by holding back progress and creating perverse incentives for
CAs to misissue certificates for compatibility with old devices.
I would ask CommScope to describe in detail:
1. How CommScope will ensure that the devices which use their certificates
stay up-to-date with TLS and WebPKI ecosystem improvements.
2. How the certificates on these devices will be replaced in the
event that an arbitrarily large number of certificates need to be
revoked within the timelines specified by BR 4.9.1.
Regards,
Andrew
Antonios Chariton
Do you plan to offer certificates to other entities or will you only be issuing certificates for your own products?
I read your post carefully about the value to the ecosystem stemming from your experience, but I did not understand what the difference will be at the certificate layer, and why a publicly trusted Root CA is needed to serve this.
You write:
> CommScope is more than just a standard CA. With its wealth of experience dealing with device manufacturing, deployment and operation, we are also well positioned to serve device manufacturers and operators of device fleets, whose requirements are not the same as typical web site operators.
The WebPKI has evolved to serve website operators, and the vast amount of requirements imposed on all of its CAs have been designed for browsers and websites, so you may have to face challenging circumstances if you try to deviate too far from that. Especially with IoT, where — as Andrew said — revocation and renewal is difficult, especially at these volumes you describe, every incident that occurs will be more difficult to deal with, not just for CommScope, but potentially for other entities involved such as user agents. CAs are also required to implement changes relatively quickly. The typical time frame is either weeks or months. Does that match your expectations and the lifecycle for software updates and changes to your relying parties?
It’s not clear to me what the purpose of this application is, but perhaps you are limiting your flexibility quite a bit by going down that path. I’m not saying you should, or shouldn’t, I just want to understand if this is all clear from the beginning. You clearly have experience with PKIs, so I just wanted to get your thoughts on the issues above.
Thanks,
Antonis
So, Nicol
Thanks for alerting us to the issue. We would note that while the SCT extensions do not conform with RFC 6962, the issue is a technicality and not security related.
We are a long-time CA operator trying to enter the public CA space. We tried publishing precertificates to CT logs. Our experience was that not many CT logs would accept precertificates from CAs not already included in at least one of the major root programs. The ones that we published to before stopped being available to us at some points. We decided stop including SCTs in our certificates until we get accepted by the Mozilla Root Certificate Program. That was our intent.
We will revoke the certificates in question and replace them with ones that are conformant.
> I'm very concerned that the primary use for this CA will be issuing
> certificates for embedded systems such as set top boxes, cable modems,
> IoT devices, and the like. Embedded systems tend to run out-of-date
> software which never receives updates. Historically, using
> publicly-trusted certificates with embedded systems has harmed the
> WebPKI by holding back progress and creating perverse incentives for
> CAs to misissue certificates for compatibility with old devices.
Historically most of the devices we provision credentials to are managed devices deployed by service providers. These devices typically receive updates from time to time. Not all of the certificates in these devices will be publicly trusted. Many of these certificates are defined by and only used in specific ecosystems. I don't see any perverse incentive for us, or other CAs in our position, to deliberately misissue publicly-trusted certificates for backward compatibility, given the managed devices are updatable. Compared to the past, service providers’ capabilities in managing deployed devices like STBs and cable modems have progressed a lot and that regular and on-demand device updates have become a common practice.
> 1. How CommScope will ensure that the devices which use their certificates
> stay up-to-date with TLS and WebPKI ecosystem improvements.
We participate in CA/Browser Forum and follow the discussions in applicable working groups there. We also monitor the several major root programs for proposed/planned changes in the requirements. When we identify changes that affect our use cases, we add the changes to our development roadmap to maintain compliance.
In addition, whenever we identify changes that affect the devices holding certificates issued by us, we notify the device makers and service providers, and work closely with them to make sure that there is a path to updating the devices so that they are compliant with any new or updated requirements. We have done this in the past for other industry consortia and we will do the same for the TLS and WebPKI ecosystems.
> 2. How the certificates on these devices will be replaced in the
> event that an arbitrarily large number of certificates need to be
> revoked within the timelines specified by BR 4.9.1.
The timelines in BR 4.9.1 apply only to publicly-trusted certificates. For managed devices, typically the management system has a record of the devices, from which the device certificates can be determined. The deploying organization can provide us with a list of certificates that need to be revoked, and we can quickly add them to the CRLs and OCSP responders that we maintain. (Our system supports bulk revocation, in which a large number of certificates can be revoked in a single request.) Publicly-trusted certificates need to be replaced periodically in any case, so an automated certificate rekeying / replacement capability will naturally be part of the deployment.
We have an existing automated solution for installing new certificates on deployed devices that can sustain a high volume of requests. In one instance, a major US service provider used this solution to install over 1 million certificates within 24 hours. This solution is capable of scaling up to serve even higher volumes.
Nicol So
So, Nicol
On Fri, 01 Sep 2023 08:19:04 -0700, Antonios Chariton wrote:
> Will you be a TLS Client Certificate-heavy CA, or will you issue mostly Server certificates?
For the near term, we expect the certificates to be used mostly as server certificates.
> Do you plan to offer certificates to other entities or will you only be issuing certificates for your own products?
We plan to offer our service to external parties as well.
> You write:
>> CommScope is more than just a standard CA. With its wealth of experience dealing with device manufacturing, deployment and operation, we are also well positioned to serve device manufacturers and operators of device fleets, whose requirements are not the same as typical web site operators.
> Based on that, I wanted to ask: have you tried (or plan to use) ACME for these types of operations? If not, what is preventing you from doing so?
We support certificate enrollment using ACME and CMPv2. We will use those protocols if the deploying organization requires them.
> The WebPKI has evolved to serve website operators, and the vast amount of requirements imposed on all of its CAs have been designed for browsers and websites, so you may have to face challenging circumstances if you try to deviate too far from that. Especially with IoT, where — as Andrew said — revocation and renewal is difficult, especially at these volumes you describe, every incident that occurs will be more difficult to deal with, not just for CommScope, but potentially for other entities involved such as user agents. CAs are also required to implement changes relatively quickly. The typical time frame is either weeks or months. Does that match your expectations and the lifecycle for software updates and changes to your relying parties?
Not all revocation-triggering events will affect a large number of devices, and not all issues are security-related and require a 24-hour turnaround time. The devices that we expect to have publicly-trusted certificates provisioned are typically managed devices. If there’s a common cause that requires the certificates of multiple devices to be revoked, determining the devices affected should not be a problem because of the information maintained in the management system and in our own records. The deploying organization can provide us with information about the devices affected, we can quickly add the certificates to the CRL and the OCSP responder.
Issues that would require a large number of certificates to be revoke are also a possibility for CAs that serve primarily website operators. For managed devices, there is usually a capability to automate and coordinate the certificate replacement process, which may not be available when the user base consists of website operators with diverse architectures and varying degrees of automation.
We understand that the requirements on publicly-trusted certificates will continue to evolve, and we accept that reality.
> It’s not clear to me what the purpose of this application is, but perhaps you are limiting your flexibility quite a bit by going down that path. I’m not saying you should, or shouldn’t, I just want to understand if this is all clear from the beginning. You clearly have experience with PKIs, so I just wanted to get your thoughts on the issues above.
There are use cases in which managed devices will need to accept connections from devices not owned or controlled by the service provider. Asking subscribers to configure the trust stores on their devices is either technically not possible or unacceptable for other reasons. Being able to issue publicly trusted certificates would enable CommScope to simplify the solution architecture and offer a better solution to our customers.
Nicol So
Ben Wilson
Seo Suchan
what kind of validation methods you'll use for your certificates? as in allowed method numbered in ca/b br? as you said will use acme I guess 3.2.2.4.7 /19/20 , right?
So, Nicol
On Tue, 03 Oct 2023 05:41:50 -0700, Seo Suchan wrote:
> what kind of validation methods you'll use for your certificates? as in allowed method numbered in ca/b br? as you said will use acme I guess 3.2.2.4.7 /19/20 , right?
As stated in our CP/CPS, CommScope currently support 2 methods for domain control validation:
- Email to Domain Contact (BR § 3.2.2.4.2)
- DNS Change (BR § 3.2.2.4.7)
We have the technical capability to support ACME’s automated domain validation methods, but we currently don’t offer them. (ACME can be used with external account binding and have domain validation performed outside the protocol.) Going forward, we will support the “Agreed-Upon Change to Website – ACME” method (BR § 3.2.2.4.19) when the business need arises.
Nicol So
Ben Wilson
All,
On August 28, 2023, we began a six-week, public discussion[1] on the following root CA certificates issued by Commscope:
CommScope Public Trust RSA Root-01:
Use cases served/EKUs:
Server Authentication (TLS) 1.3.6.1.5.5.7.3.1
Client Authentication 1.3.6.1.5.5.7.3.2
CommScope Public Trust RSA Root-02:
Use cases served/EKUs:
Server Authentication (TLS) 1.3.6.1.5.5.7.3.1
Client Authentication 1.3.6.1.5.5.7.3.2
CommScope Public Trust ECC Root-01
Use cases served/EKUs:
Server Authentication (TLS) 1.3.6.1.5.5.7.3.1
Client Authentication 1.3.6.1.5.5.7.3.2
CommScope Public Trust ECC Root-02
Use cases served/EKUs:
Server Authentication (TLS) 1.3.6.1.5.5.7.3.1
Client Authentication 1.3.6.1.5.5.7.3.2
The public discussion period ended today, October 10, 2023.
Summary of Questions and Responses
One question asked about the particular value that Commscope would add to the web PKI.
Commscope replied that it had served companies like Motorola, Broadcom, Verizon, and T-Mobile and that it had manufacturing experience provisioning solutions for billions of IoT devices. In addition to device manufacturing, Commscope said that it would serve “device manufacturers and operators of device fleets, whose requirements are not the same as typical web site operator.”
One commenter noted that embedded systems tend to run out-of-date software that is never updated and that using publicly-trusted certificates with embedded systems harms the WebPKI by holding back progress and that CAs will sometimes misissue certificates to older devices for compatibility reasons.
Follow-up questions from two commenters asked how CommScope would ensure that devices with certificates would stay up-to-date with TLS and WebPKI ecosystem requirements and how certificates on such devices would be replaced in the event that an arbitrarily large number of certificates needed to be revoked within the timelines specified by the CA/Browser Forum’s Baseline Requirements.
Commscope responded that it participates in CA/Browser Forum discussions and monitors root programs for rule changes and would take a proactive approach to compliance with industry standards. They also said that they would ensure compliance by notifying device manufacturers and service providers and assist them with updates as needed. Commscope also claimed to have the capacity for bulk, high-volume certificate revocation and automated certificate replacement on devices.
Another comment pointed out that Commscope had issued test certificates with empty SCT extensions.
Commscope explained the difficulty experienced in submitting certificates to CT logs, and it agreed to revoke and replace the certificates in question. It also filed an incident report.[2]
One commenter asked whether Commscope would be issuing certificates to other entities or only to its own products.
Commscope said that it would be issuing certificates to other entities.
Another question was whether Commscope would use ACME?
Commscope said that it supported certificate enrollment using ACME and CMPv2 and would use them if the deploying organization required their use.
Another question asked about the domain validation methods that Commscope would use.
Commscope said that it currently uses email to the Domain Contact (BR § 3.2.2.4.2) and DNS Change (BR § 3.2.2.4.7) to perform domain validation, but that it had the ability to support ACME (“Agreed-Upon Change to Website – ACME” method (BR § 3.2.2.4.19)) when the business need arises.
Conclusion
We thank the community for its review and consideration during this period. Root Store Programs will make final inclusion decisions independently, on their own timelines, and based on each Root Store Member’s inclusion criteria. Further discussion may take place in the independently managed Root Store community forums (i.e., MDSP).
Ben
[1] https://groups.google.com/a/ccadb.org/g/public/c/HVwBXDw6GnU/m/1LsNC19RAQAJ
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1852404#c7--
You received this message because you are subscribed to the Google Groups "CCADB Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to public+un...@ccadb.org.
To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/LV8PR14MB753428A208508557E334017786CAA%40LV8PR14MB7534.namprd14.prod.outlook.com.