Subject: [Acme] I-D Action: draft-ietf-acme-client-04.txt

From: [email-masked]
Date: Wed, 29 Sep 2021 07:57:09 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Automated Certificate Management Environment WG of the IETF.

        Title           : ACME End User Client and Code Signing Certificates
        Author          : Kathleen M. Moriarty
	Filename        : draft-ietf-acme-client-04.txt
	Pages           : 14
	Date            : 2021-09-29

Abstract:
   Automated Certificate Management Environment (ACME) core protocol
   addresses the use case of web server certificates for TLS.  This
   document extends the ACME protocol to support end user client, device
   client, and code signing certificates.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-acme-client/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-acme-client-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-client-04

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: 서수찬 <[email-masked]>
Date: Thu, 30 Sep 2021 04:34:58 +0900

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

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 30 Sep 2021 08:10:18 -0400

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-masked]> 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-masked]
> https://www.ietf.org/mailman/listinfo/acme