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 -- 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/BL0PR14MB3524C42836D721F89C93303386EFA%40BL0PR14MB3524.namprd14.prod.outlook.com.
