Greetings, The version 4 addresses Deb’s comments (provided she agrees). I’d like to determine if this document is ready for last call. To state it simply, it added several challenge types, which can be separated from certificate/key types in ACME. I think this would be useful as a working group item to ensure adequate review and to allow for this flexibility. The code signing use case is already following this process, using some automation.
With an increased push for built in security, this could be quite useful to achieve automated reporting on assets and software. These are foundational elements to any security control framework and difficult to achieve right now for under resourced organizations. With attestation work and SBOM evolving, we may be able to get the inventory of assets, including software automated with standards and baked into products. Best regards, Kathleen Sent from my mobile device > On Sep 29, 2021, at 3:35 PM, 서수찬 <[email protected]> wrote: > > > I think I'm missing the point of DV end user client certificate. Most CA > already gives cert with both Server Authentication and Client Authentication > when they signs a TLS certificate. So I'm not sure why anyone would bother to > set up for additional challenge to get a client-limited usage certificate. > > for personal identity verification, maybe electronic ID cards like bio-metric > passport can be used? e-boarder but happens remotely? not sure if we can > trust client's camera/fingerprint sensor/etc in this context though. > > and as ACME (by rfc8555) doesn't get CSR until they finalize the order that > happens after verification > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
