Re: [Gen-art] [Acme] Genart last call review of draft-ietf-acme-email-smime-08

Alexey Melnikov <alexey.melnikov@isode.com> Thu, 24 September 2020 17:26 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1088A3A1131; Thu, 24 Sep 2020 10:26:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 4Vg947g1FEen; Thu, 24 Sep 2020 10:26:14 -0700 (PDT)
Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 3C01C3A0FCB; Thu, 24 Sep 2020 10:26:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1600968370; d=isode.com; s=june2016; i=@isode.com; bh=kiTLsZAq2alxYJDUozppYIp4uAltMmSXQrISCCEddA4=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=knUb5gPn1HAYJWPUriuD1P3ihLiImhJTRUCxzKAl0KH0n73z/7Owm5TLhgvCkVK3RomUV6 vknEtyieH9LIgJ+ZfoutH8iBx3u5KfKskJRsGqQ7huQh58dGyAsogH6jwk1P1c6Ew2Vprt 6x4QWK1Ni/99v+mFZz+OZntLCRrM1RA=;
Received: from [192.168.0.5] (97e7601a.skybroadband.com [151.231.96.26]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id <X2zWsAABYKlX@waldorf.isode.com>; Thu, 24 Sep 2020 18:26:09 +0100
To: Peter Yee <peter@akayla.com>, gen-art@ietf.org
Cc: last-call@ietf.org, draft-ietf-acme-email-smime.all@ietf.org, acme@ietf.org
References: <159428288280.21264.7200695250082171545@ietfa.amsl.com>
From: Alexey Melnikov <alexey.melnikov@isode.com>
Message-ID: <449e2320-aec2-338c-e27c-20a3a36801cc@isode.com>
Date: Thu, 24 Sep 2020 18:26:08 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
In-Reply-To: <159428288280.21264.7200695250082171545@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/D55woEPC0NvDVmqEs7KvFOe_qx0>
Subject: Re: [Gen-art] [Acme] Genart last call review of draft-ietf-acme-email-smime-08
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Sep 2020 17:26:16 -0000

Hi Peter,

Thank you for your detailed review. My answers/comments are below:

On 09/07/2020 09:21, Peter Yee via Datatracker wrote:
> Reviewer: Peter Yee
> Review result: Ready with Issues
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair. Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
>
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>
> Document: draft-ietf-acme-email-smime-08
> Reviewer: Peter Yee
> Review Date: 2020-07-09
> IETF LC End Date: 2020-07-09
> IESG Telechat date: Not scheduled for a telechat
>
> Summary: This Informational Track draft defines an ACME challenge to be used in
> the issuance of S/MIME certificates. I have points I'd like to see clarified as
> well as some nits that need to be cleaned up before I would declare it ready.
> [Ready with Issues]
>
> Major issues: None
>
> Minor issues:
>
> General: this draft doesn’t frame the operation of the ACME request that uses
> this challenge. It mentions a token-part2 that magically arrives over HTTPS,
> but gives no indication of why this happened or what causes the generation of
> the email challenge. Some context around when this challenge is invoked and
> what signals the ACME server that this challenge is required would be helpful.
Good point. I've added a paragraph on this.
> Page 3, 1st enumerated item: I find the definition of “first part of the token”
> to be far looser than it needs to be. You merely say that it needs to contain
> 64 bits of entropy. Is there an upper bound?
No. I don't believe base ACME has upper bound on tokens either.
> Do you need to say anything about it not being reused in another challenge?
This was the intent and I clarified that.
> Page 4, example Subject header field: it would be much better if you gave an
> actual example of a base64url-encoded value here rather than some explanatory
> text in much the same way you have given actual, legal values for Date,
> Message-ID, etc.
Ok.
> Page 5, section 3.2, 1st enumerated item, 1st sentence: it doesn’t seem like
> you particularly care what is in front of “ACME:”. While you say it’s typically
> “Re:” , it could be anything. Would there ever be a case to reject a response
> message based on what appears before “ACME:”? I’d like to see a little more
> rigor here on what’s required. Some characters followed by a colon and a white
> space before the “ACME:” suffices?

I would like for email to use standardardized reply prefix, but there 
are variations. E.g. using "Re[<number>]". And don't get me started on 
localized versions, which should be banned from the face of the Earth ;-).

You do have a point that probably anything before "ACME:" can be 
allowed. I will clarify that.

> Page 5, section 3.2, 6th enumerated item, 2nd sentence: where it says
> “calculated based on”…, it would be preferable to point back to page 3, 2nd
> enumerated item where you explicitly indicate that the two token parts are
> concatenated.
I clarified that.
> Page 5, section 3.2, 6th enumerated item, last sentence: I’m assuming that
> ACME-unaware clients are only receiving this email in the case of the email
> being bounced to an administrator or returned to the user.
I suppose ACME server processing can be manual, but this is more likely 
to be a misconfiguration.
> In either case, it’s
> not the client that will be reading this outside-the-block text, it’s a user.
> There’s no processing to be done on that text.
Yes, it will be read by a user. I am not sure what needs changing in the 
text.
> Page 7, example Subject header field: use a real value here, please.
>
> Nits/editorial comments:

I've applied these and the changes will appear in -09. Use of English 
language articles is not my strong point :-)

Best Regards,

Alexey