some questions: 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?
On 2023년 10월 3일 오후 8시 54분 16초 GMT+09:00, Ben Wilson <[email protected]> 작성함: >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. -- 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/386D1C74-E568-436B-9B98-8B8A713F53C0%40gmail.com.
