Subject: [Acme] Client draft

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 1 Nov 2019 11:50:06 -0400

Hello,

I posted an update of
https://datatracker.ietf.org/doc/draft-moriarty-acme-client/ that includes
a few updates per Tim Hollebeek's review.

Additional comments and reviews appreciated!

-- 

Best regards,
Kathleen

---

From: Thomas Peterson <[email-masked]>
Date: Sun, 3 Nov 2019 15:00:13 +0000

Asides from a typo nit you have introduced acknowledging Tim "Thank you 
tp Tim..." you draft looks good.

Regards

On 01/11/2019 15:50, Kathleen Moriarty wrote:
> Hello,
> 
> I posted an update of 
> https://datatracker.ietf.org/doc/draft-moriarty-acme-client/ 
> <https://datatracker.ietf.org/doc/draft-moriarty-acme-client/> that 
> includes a few updates per Tim Hollebeek's review.
> 
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Deb Cooley <[email-masked]>
Date: Thu, 7 Nov 2019 07:18:22 -0500

Kathleen,
Here are a few comments, let me know if you have questions/concerns/etc.
I'd be happy to clarify.

Deb Cooley
[email-masked]

0.  So the trick here is in the original ACME spec, they could rely on DNS
registration, as yucky as it is (w/out DNSSEC), at least it exists.  In the
client space, you don't have anything like DNS, nor do you really want it
(privacy, tracking end users, etc.).  But you need something instead.  The
question is what?  If you can punt this issue to be out of scope, then the
rest is easy.  But if you punt it, then is this I-D really necessary?

1.  Section 2, first para:  I would delete the phrase, 'As with the TLS
certificates defined in the core ACME document'.  It is ambigious (is it
defined in RFC 8555 or is it not defined?).

2.  Section 2:  This appears to be basically a reiteration of SP 800-63.
Is this common?  because these standards are freely available.  You don't
appear to be selecting a level, so I'm not sure what the point is.  If I
were the author, I'd take most of this out.

3.  Section 3:  None of those things are immutable (IP address, hostname,
MAC address).  We (DOD) have to work pretty hard to enroll devices the
first time.  For names, we use things like S/N.  Rekey, once we have a
device key/cert in place is much easier.  Usually, we have to have a human
in the loop, at least the first time. Again, you could punt this part....

4.  Section 3:  EST is an open standard.  Where the target is device
enrollment, right?

5.  Section 4, para 1:  Storage of the certificate isn't really an issue.
Storage of the private key is an issue.  Don't know that I'd say 'browser',
perhaps 'browser, O/S key store, or PKCS#11 container'.  How many end users
use a KMIP container? [I'm thinking none of them]

6.  Section 4, para 1:  I wouldn't use the word 'presumably'.  I'd say
'intended to be' instead.

7.  Section 5:  Frankly, I don't think code signing certificates should be
issued automatically. The issuance of these needs to be intentional.  If I
were the author, I'd delete this.

8.  Section 6:  Where is SMS and email defined to be an additional
challenge type?  I don't believe SMS messages are allowed as a
challenge/response mechanism in SP 800-63.  Because SMS notifications do
not normally require a mobile platform to be unlocked to view.

9.  Section 7.1.3:  This section looks like a direct copy and paste of
Section 7.1.  Is that really necessary?

10.  Section 7.2:  In general, I don't like the fact that 'certificates' is
used alone when it is the 'private key/certificate pair' is actually being
used.  Perhaps this could be called the public key cryptography section?

11.  Section 7.2, sentence 2:  replace 'acceptable for the specified
process and then stored appropriately'  with 'acceptable for the specified
process and the private key stored appropriately'.

12.  Section 7.3:  I'm not terribly familiar w/ FIDO.  Do they use
certificates?  Or just bare public/private key pairs (like SSH)?

Grammar/spelling (just as I see them)
1. Intro:  Code SIgning should be code signing.
2. Section 6:  administrors should be administrators.
3. Section 7.2, first sentence:  identiying should be indentifying.
4.  Section 7.2, sentence 2:  posisble should be possible.
5.  Section 7.3:  typos regisration sb registration, puiblic sb public.

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 7 Nov 2019 11:09:05 -0500

Sent from my mobile device

> On Nov 3, 2019, at 10:00 AM, Thomas Peterson <[email-masked]> wrote:
> 
> Asides from a typo nit you have introduced acknowledging Tim "Thank you tp Tim..." you draft looks good.

Thank you, I’ll fix it in the next revision.  I have comments from another reviewer as well off list.

Best regards,
Kathleen 
>> I posted an update of https://datatracker.ietf.org/doc/draft-moriarty-acme-client/ <https://datatracker.ietf.org/doc/draft-moriarty-acme-client/> that includes a few updates per Tim Hollebeek's review.

---

From: Kathleen Moriarty <[email-masked]>
Date: Sat, 16 Nov 2019 09:57:54 -0500

Hi Deb,

Thank you very much for your comments.  I'll respond inline and have a
draft ready to post when the submissions open again.

> rest is easy.  But if you punt it, then is this I-D really necessary?

I'd like to find challenge types that can be helpful for automation, even
if it just means partial automation that will be coupled with an
out-of-band process.  The credentials might be issued through a process
that involves identity proofing, possibly tying the user/admin to an
organization.

> defined in RFC 8555 or is it not defined?).

I cleaned up this text.  I don't think RFC8555 makes this clear and since
this draft is about client certificates, the connection is likely important
to some readers who may not have the full picture.  Some of my text
resulted from discussions on points such as this where there were
misunderstandings (like the storage one below).

> were the author, I'd take most of this out.

I cut out the text and left the reference in.  It's fine to copy NIST
document text, but not necessary.  I left the references in with
explanatory text.

> in the loop, at least the first time. Again, you could punt this part....
I deleted the device certificate section per Andrei's comments and that a
separate draft is in the works.

> 4.  Section 3:  EST is an open standard.  Where the target is device

Yes, this is in the ACME overview draft (just expired and we'll revive it
if of interest).  I don't see it in this draft as this one is on clients.
Can you expand on the suggestion here?  Thanks!
There is a gap with EST and the other drafts are working to close the gap.

> use a KMIP container? [I'm thinking none of them]

Right and this is separable from ACME.  This is only in here because I was
getting questions elsewhere. I think you are correct on KMIP, it's just
used to store device certificates and can be used to store code signing
certificates.  I cleaned this up a bit, but the section may need more
cleanup.

> 'intended to be' instead.

Good catch, thanks!

> were the author, I'd delete this.

If you walk through the process of obtaining a code signing certificate, it
requires organization authentication and verification from employees.
That's where the challenge types come in to play.  The automation is not
fully complete with what is described, as verification from approved
credentials is included as part of the described process. Those credentials
likely have an identity proofing process tied to them.

Do you mean you'd delete the section?  Code signing is one of the main
intentions of the draft tied to credentials that have had identity proofing
performed used as the challenge types.  Perhaps that is not clear enough?
We have to make this stuff easier to get more deployed.  This doesn't fully
automate.

> not normally require a mobile platform to be unlocked to view.

RFC8555 lists them as options in the text, not as defined types.   I
changed the text slightly to better reflect that.

> Section 7.1.  Is that really necessary?

If you look closely, the type is different.

>
> 10.  Section 7.2:  In general, I don't like the fact that 'certificates'
> is used alone when it is the 'private key/certificate pair' is actually
> being used.  Perhaps this could be called the public key cryptography
> section?
>

Done, good suggestion.  Thanks.

> process and the private key stored appropriately'.

Fixed, thank you!

> certificates?  Or just bare public/private key pairs (like SSH)?
Just raw keys.  It's now WebAuthn from W3C and much more widely supported
(recent-ish change).  I updated this to say W3C WebAuthn instead of FIDO.

> 1. Intro:  Code SIgning should be code signing.
Thanks!  Fixed per another review.

> 2. Section 6:  administrors should be administrators.
Fixed, thank you!  My editor doesn't highlight my typos unfortunately.  I
should be more careful.

> 3. Section 7.2, first sentence:  identiying should be indentifying.
Thank you.

> 4.  Section 7.2, sentence 2:  posisble should be possible.
Fixed, thank you!

> 5.  Section 7.3:  typos regisration sb registration, puiblic sb public.
Fixed, thank you!

I appreciate your careful review.  Thank you!

Kathleen

-- 

Best regards,
Kathleen