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 작성함:
>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.
--
You received this message because you are subscribed to the Google Groups
"CCADB