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 [email protected]. 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.
