This is just a reminder that this Public Discussion is scheduled to close next Tuesday, October 10, 2023.
On Wednesday, September 6, 2023 at 4:39:43 PM UTC-4 So, Nicol wrote: > 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 public+unsubscr...@ccadb.org. To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/96def9a4-30f1-4193-8138-372da87e5b38n%40ccadb.org.
