Hi ACME!

I provide this review as an individual, with my Chair-Hat off. I will start a 
separate thread to provide some Chair's questions / comments on how to progress 
this adopted draft.

Document / version reviewed: draft-ietf-acme-client-13



The goal of this document seems to be to extend ACME to support cert 
enrollments where control of the requested identifiers cannot be verified in an 
automated way in-band in the ACME protocol; particularly, this seems to be in 
support of issuing certs to cloud workloads and is a building-block for the 
WIMSE WG. Specifically, this draft adds authentication challenges to ACME: OTP, 
Client Cert, and WebAuthn.


I think this is a reasonable goal, but I don't think the current draft 
articulates this particularly well; it took me until Section 7 to realize 
that's what it's doing.

So, I suggest that this draft re-brand itself to make the core content clearer.


I would change the title to "ACME Client Authentication Challenges", or 
something similar.


I suggest the abstract be changed

OLD:

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 service account authentication credentials, micro-service 
accounts credentials, device client, code signing, document signing 
certificates and keys.


NEW:

Abstract


Automated Certificate Management Environment (ACME) core protocol addresses 
certificate issuance use cases where identity proofing can be performed inline, 
for example verifying control of a DNS record or HTTP endpoint. In cases where 
identity proofing is performed out-of-band, then the ACME protocol merely needs 
to authenticate the certificate requester. This document extends the ACME 
protocol to add OTP, PKI and WebAuthn based authentication Challenges that give 
a CA greater flexibility in how it authenticates the ACME client.



I would suggest re-structuring the Intro to start by cleanly defining the terms 
"identity proofing" and "authentication"; explaining that the Challenge types 
in RFC8555 only address inline and automatable identity proofing; this draft 
extends ACME to cover certificate issuance cases that cannot do inline identity 
proofing by adding Authentication Challenge types so that an ACME Server can 
authenticate this request against the same entity who had previously performed 
identity proofing via some other means.


I would remove the entire sections on Code Signing and Document Signing since I 
think that's a distraction from the core of the draft - I would turn them into 
a passing "Motivating use cases" paragraph in the Intro. The CSR discussion in 
these sections is confusing; it says "CSR MUST be set to the correct values for 
the CA", but my understanding of RFC8555 - particularly the /new-order - is 
that the CSR is only a container for the public key, and all the actual 
metadata (requested identifiers, requested cert lifetime) go in the JSON body 
of the /new-order, so I'm not sure what "correct values" the CSR is supposed to 
contain? I also worry that some of the normative stuff in the Code Signing and 
Document Signing sections could come into conflict with CA/B Forum or ETSI 
requirements for Code Signing and Document Signing certs, so maybe best to just 
not go there and focus this draft on the OTP, Client Cert, and WebAuthn 
authentication mechanisms that it's adding.


I think the draft's Introduction and Security Considerations needs some 
discussion that this draft changes the philosophical nature of the ACME 
protocol - whereas the Challenge types in RFC8555 are all focused on 
establishing proof-of-control of a reachable identifier (DNS Name or email 
address), this draft moves all of that out-of-band and actually brings the ACME 
protocol closer to existing PKI enrollment protocols in terms of functionality 
offered (CMP, EST, CSR-pasted-into-webpage, etc).


[PS: I'm fighting with the IETF mail server and multiple personal email 
addresses; so apologies if this sends twice]


---
Mike Ounsworth
Software Security Architect, Entrust

Any email and files/attachments transmitted with it are intended solely for the 
use of the individual or entity to whom they are addressed. If this message has 
been sent to you in error, you must not copy, distribute or disclose of the 
information it contains. Please notify Entrust immediately and delete the 
message from your system.

_______________________________________________
Acme mailing list -- acme@ietf.org
To unsubscribe send an email to acme-le...@ietf.org

Reply via email to