Re: [Acme] Client draft

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Sat, 16 November 2019 14:58 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.com>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8434712006E for <acme@ietfa.amsl.com>; Sat, 16 Nov 2019 06:58:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbbxwT7s8znS for <acme@ietfa.amsl.com>; Sat, 16 Nov 2019 06:58:31 -0800 (PST)
Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DECF0120020 for <acme@ietf.org>; Sat, 16 Nov 2019 06:58:30 -0800 (PST)
Received: by mail-oi1-x236.google.com with SMTP id m193so11345151oig.0 for <acme@ietf.org>; Sat, 16 Nov 2019 06:58:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VHVJJLzeNFurnqT/fVudsyvTo+sPPs/iSUo9B5MVc5c=; b=VRbMn64tAsm62d/R7DQb3Qoz2L3loeiFDlKoE9gT1pg3eE3Vft6pF86sQAjA7SGE9e dsh2q2UaNn9SSNRVWhGVbpLDLg6y4V28pSKE0F7O84vCGcxoI6HYLgwJf5VqRCsBerF0 yFI2MvOzV8yzKF/ixMVqMZg8dm+xjZynxirkgNIFVda18qugSBxEC2ZetRdZ3r2XuKBZ lAc5R8X34iwR5dq5o/MvFKeEyATWbEEknJGk09LoU1iQY30/HWtGC+PFh6q+VrNFQejH G3Pi1mw6Jo7Gi7wkCn+aS2nc/fRO5QFbzzOleN3XI38xOmz6N0IczJE2TFlJvwYaSems Lgyw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VHVJJLzeNFurnqT/fVudsyvTo+sPPs/iSUo9B5MVc5c=; b=Kzy2CXZ3kszow9xkpq/JIzcfpaTDfuwA8uZFwBJEY7zqP2o7K4UNDHJ5etX291uj5R 3Kd/C8GNprreuURa1yKCxs1TSbP6ySj0IvmeHxuhmBoWuPX4WVc8bHlctoqhcLkrrNOk +8XVQ525LZBM6gH2GXp+Q1QIJzacMBGzjx9Mk/T+xxf2i1ab7//BJZ+wfUQdtrtajuKL +b7hfQjE2sLyajwGoxJwZ7Togsw9gsLL3AXiXfVUHdmCTSmYXw+K9R/H5sq8NnEf9BSx 9DMzSp8osTh9QdMlhFfWNszs/v5/Bbx/g0GFcQCqwYcG/u98XO2ttHaEN06MVZPFdmNg UDxw==
X-Gm-Message-State: APjAAAWfJG2s0IeLrUKAYlbdcZDxiP1GyzH+jT1BxsjZiuO2uvn0d7fQ hw0mn5ksaYPcXMYIB6cIA8Vs14bBDdYsRWxcklc=
X-Google-Smtp-Source: APXvYqwijVktyq1/XBzm1LFFV2IzPa7w5Mm3a+2Jwxpmb5Mhjl3F5GJ4GhGwACmRVfRwR8wbquoctFW1W/QQLtnv09I=
X-Received: by 2002:a05:6808:ab1:: with SMTP id r17mr2420827oij.111.1573916310149; Sat, 16 Nov 2019 06:58:30 -0800 (PST)
MIME-Version: 1.0
References: <CAHbuEH6rLwRq+_JA6v4UpWwYb22Sh07A3LfTXNOT_MbPjSfvOg@mail.gmail.com> <595a44aa-c6fd-2586-f04d-abaef94c05ff@gmail.com> <CAGgd1OcXb1-RafTw_BxrYoVoserkEwW16pYH-JrHbQOA0b705A@mail.gmail.com>
In-Reply-To: <CAGgd1OcXb1-RafTw_BxrYoVoserkEwW16pYH-JrHbQOA0b705A@mail.gmail.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Sat, 16 Nov 2019 09:57:54 -0500
Message-ID: <CAHbuEH75Kq1m49us598r8535Cy-UQR5GSiRWxujFQVSvMsPt+A@mail.gmail.com>
To: Deb Cooley <debcooley1@gmail.com>
Cc: IETF ACME <acme@ietf.org>, "Cooley, Dorothy E" <decoole@nsa.gov>
Content-Type: multipart/alternative; boundary="000000000000929e67059777f2a2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/eID3nq-skL9L6tgroWVKk6e03R4>
Subject: Re: [Acme] Client draft
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Nov 2019 14:58:35 -0000

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.

On Thu, Nov 7, 2019 at 7:18 AM Deb Cooley <debcooley1@gmail.com> wrote:

> Kathleen,
> Here are a few comments, let me know if you have questions/concerns/etc.
> I'd be happy to clarify.
>
> Deb Cooley
> decoole@nsa.gov
>
> 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?
>

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.


>
> 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?).
>

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).


>
> 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.
>

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.

>
> 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....
>
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
> enrollment, right?
>

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.


>
> 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]
>

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.


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

Good catch, thanks!

>
> 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.
>

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.


> 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.
>

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


>
> 9.  Section 7.1.3:  This section looks like a direct copy and paste of
> 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.

>
> 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'.
>

Fixed, thank you!

>
> 12.  Section 7.3:  I'm not terribly familiar w/ FIDO.  Do they use
> 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.


> Grammar/spelling (just as I see them)
> 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

>
> On Sun, Nov 3, 2019 at 10:00 AM Thomas Peterson <nosretep.samoht@gmail.com>
> wrote:
>
>> 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.
>> >
>> > Additional comments and reviews appreciated!
>> >
>> > --
>> >
>> > Best regards,
>> > Kathleen
>> >
>> > _______________________________________________
>> > Acme mailing list
>> > Acme@ietf.org
>> > https://www.ietf.org/mailman/listinfo/acme
>> >
>>
>> _______________________________________________
>> Acme mailing list
>> Acme@ietf.org
>> https://www.ietf.org/mailman/listinfo/acme
>>
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>


-- 

Best regards,
Kathleen