Subject: [Acme] comments on draft-ietf-acme-client-03.txt

From: "Cooley, Dorothy E" <[email-masked]>
Date: Tue, 28 Sep 2021 10:52:44 +0000

Kathleen, 

Thank you for updating the client draft.  This is a rough and quick review,
just to get things started:

1.  Section 3, para 1:  Storage of certificates is trivial (they are
public), storage of private keys is more important.  Is this too pedantic?
(note:  this confusion of certificates and private keys continues through
the draft, not just in this paragraph)

2.  Section 3, []:  Isn't this why we need identity credential (i.e. the key
and certificate)?  An authentication challenge doesn't 'test the identity of
the user', but using the identity credential is supposed to chain back to
the fact that the identity of the user was validated.

3.  Section 4:  I will freely admit that code signing certificates makes me
extremely twitchy (my own biases at play).  Of all the things that could be
automated, I would choose this one last.  I haven't had a chance to look at
the current state of CA/Browser Forum requirements for code signing
certificates, OV (organizational validation), or EV wrt code signing.  My
personal opinion is that we should tread carefully here.  I would be curious
to see what use case needs this.  And who would consider implementing.  I'm
going to pass on comments this time around. 

4.  Section 5:  SMS is only mentioned once in RFC 8555 as a notification
method - for a user to go back and collect the completed certificate.  I
don't see where it is listed as an allowed pre-authorization challenge
method.  (Note:  collection of an issued certificate is not the same as
holding the complete credential (private key and certificate))

typos, etc.

1.  Section 3, para 1:  KMIP, spell this out somewhere.  I think you only
use this once...

Deb Cooley
[email-masked]
Pronouns:  she/her

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 29 Sep 2021 10:55:09 -0400

Hello Deb,

Thank you for taking the time to review the draft again. I'll respond in
line and update the draft accordingly.

> the draft, not just in this paragraph)
I made a few adjustments. I think the reason I was focused on certificates
is that the request in ACME sets the correct bits in the certificate. You
are correct though and not too pedantic.

> the fact that the identity of the user was validated.

What change are you recommending?  Identity proofing isn't always done back
to a user, it is sometimes just authenticating a consistent credential tied
to a consistent entity behind that and that entity may never have gone
through identity proofing. The credential used in the challenge may not be
the key and certificate, it could be something else as is done for
other challenge/responses in ACME.

> going to pass on comments this time around.

It's already being used in this way. If you think about, the purist view
prevented us from implementing automated certificate management for many
years. Then, after Snowden, there was a willingness to allow it. We had a
jump to 30% adoption of web server encryption following Snowden. As a
result in the years following, ACME became an option and the automation and
free certificates brought us to somewhere around 90%. If we want code
signing to be ubiquitous, we need to make it easier. SOme will choses a
more trustworthy path and some will be stringent about the authentication
process behind an automated process.  This will likely tie into SBOM in
time, I'd like to see us get to a high rate of adoption for SBOM, ideally
with in-person identity proofing for the credentials used in the process to
get code signing certificates. If you look at the process in use today,
it's not really different from what's described, we just need to really
encourage the use of a solid process prior to the automated part. This will
let us have shorter lifetimes on code signing and could even consider
single use, etc.

It would be really useful to get to the point where we could allowlist all
software expected on a system (including libraries within applications) to
enable the ability to flag unexpected software. SBOM may enable that and
could get us away from deny list approaches of AV and threat indicators. If
it's not easy as well as secure, we won't get there.

> holding the complete credential (private key and certificate))

Noted, I removed SMS. Thank you for catching that!

I'll post a new version.

Best regards,
Kathleen

> 1.  Section 3, para 1:  KMIP, spell this out somewhere.  I think you only
Thank you! I expanded a few other acronyms as well.

I appreciate your helpful review.

Best regards,
Kathleen

-- 

Best regards,
Kathleen