Re: [Acme] Client draft

Deb Cooley <> Thu, 07 November 2019 12:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BB4AA120178 for <>; Thu, 7 Nov 2019 04:18:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.747
X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id R3kDO1ACQcqx for <>; Thu, 7 Nov 2019 04:18:34 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::32e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9A63D12006F for <>; Thu, 7 Nov 2019 04:18:34 -0800 (PST)
Received: by with SMTP id f10so1823801oto.3 for <>; Thu, 07 Nov 2019 04:18:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OW65f+jxH89xmn0hfHL63cztdM3a3IBqF7C6gavHaus=; b=NcQNQfGOwAGDJ7hJEXBTVR0LPWLNzGppTBFqa3XOHVsgKCWWFQmnJUmAPW3gpjwwhF +oYdrE6EmzWN0zvSpKuKDudsA1R6K82Ggpe0Ahe5R4ezGf+KbbWEd6QJBS/C/7RBXJpr TBaG2kUpHdd7FwFfrf2zksXd07dPncoR55w6EJnpgGTIzSmOeRUA+/UDq3sUW4ZvmXlg cp2ao9I0fvJuEAOtEtDGzWPyaC9jXiQG48Ps0gKEfEdGILsoiDxWKbiCLCPgYvDbKuP5 EGbAqJmIU6IN1de8TNX+CqmQVVNmslpk44CY9RIsxGUpm/w3CYWU0SEBosQmgZemGWFB GuFA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OW65f+jxH89xmn0hfHL63cztdM3a3IBqF7C6gavHaus=; b=XVAZKFsotluyOnWgK6VnvzmNAaKZqcbv/Ts0K5q7PippP2QnmBYNOMNMk5kKvR72Lk utteLk6Bu/pruELxPbGjCWi/kNT9/bRL9mW81h2gnL14HjHGdFNWKf5jzphCNKkf2NEU otIlNApCxXN5/Tnc14CZ1Xxz4SvXtv8GZZUCskC3BP1YEIXqUy9NeG1kcMr7Yx/tZyF8 ZCMRpfuTBdO+Sjp1uH8H1egyKGNmjNptoRUcpGUyx09VJqDo5OJ5ylWjXzcNlQo0zDUJ LHJJNwr10OuJJ0EJwK7hV0o2fMb8k9CbSCApiU13UNGjyNMSuq1AHajq0yXZ9yIX+hze 48dg==
X-Gm-Message-State: APjAAAVmnIYO3k9fIpkm4PLJ/ijhfoAV9a/G+/pCph+xMG7l016ymiSR 31QKU4xEIwhRybj1ahibjvqp8cbj/mZtchVDDYoO1cBWxw==
X-Google-Smtp-Source: APXvYqyUID65g9lpaLuOcCNB8dIRlO6QLqLCODyWwbU1l3T66jokXR3vQsryl4Wy9Zq3KqRVglHeSxhCMfq8gTlejrM=
X-Received: by 2002:a05:6830:1158:: with SMTP id x24mr2643407otq.109.1573129113585; Thu, 07 Nov 2019 04:18:33 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Deb Cooley <>
Date: Thu, 7 Nov 2019 07:18:22 -0500
Message-ID: <>
Cc: "Cooley, Dorothy E" <>
Content-Type: multipart/alternative; boundary="000000000000004d6e0596c0aaff"
Archived-At: <>
Subject: Re: [Acme] Client draft
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Automated Certificate Management Environment <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 07 Nov 2019 12:18:37 -0000

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

Deb Cooley

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.

On Sun, Nov 3, 2019 at 10:00 AM Thomas Peterson <>

> 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
> >
> > <> that
> > includes a few updates per Tim Hollebeek's review.
> >
> > Additional comments and reviews appreciated!
> >
> > --
> >
> > Best regards,
> > Kathleen
> >
> > _______________________________________________
> > Acme mailing list
> >
> >
> >
> _______________________________________________
> Acme mailing list