On Fri, 01 Sep 2023 07:09:16 -0700, Andrew Ayer wrote:

> 10 of the 12 test certificates are misissued because they contain

> empty SCT extensions.  Per RFC 6962 Section 3.3, SCT extensions MUST

> contain at least one SCT.



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

-- 
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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/a/ccadb.org/d/msgid/public/BL0PR14MB3524E1A0F6677967611D93FA86EFA%40BL0PR14MB3524.namprd14.prod.outlook.com.

Reply via email to