Re: [Acme] Short WGLC review of draft-ietf-acme-email-smime-13

Fraser Tweedale <frase@frase.id.au> Sun, 13 December 2020 05:16 UTC

Return-Path: <frase@frase.id.au>
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 4F52D3A10FE for <acme@ietfa.amsl.com>; Sat, 12 Dec 2020 21:16:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.003
X-Spam-Level:
X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 pkAG6SP7FTFq for <acme@ietfa.amsl.com>; Sat, 12 Dec 2020 21:16:30 -0800 (PST)
Received: from mail14.tpgi.com.au (mail14.tpgi.com.au [203.12.160.182]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5433A10FB for <acme@ietf.org>; Sat, 12 Dec 2020 21:16:30 -0800 (PST)
X-TPG-Junk-Status: Message not scanned
X-TPG-Abuse: host=123-243-182-129.static.tpgi.com.au; ip=123.243.182.129; date=Sun, 13 Dec 2020 16:16:26 +1100
Received: from bacardi.hollandpark.frase.id.au (123-243-182-129.static.tpgi.com.au [123.243.182.129]) by mail14.tpgi.com.au (envelope-from frase@frase.id.au) (8.14.3/8.14.3) with ESMTP id 0BD5GNfe006952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 13 Dec 2020 16:16:26 +1100
Received: from bacardi.hollandpark.frase.id.au (localhost [127.0.0.1]) by bacardi.hollandpark.frase.id.au (8.15.2/8.15.2) with ESMTPS id 0BD5GMgQ093471 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 13 Dec 2020 15:16:23 +1000 (EST) (envelope-from frase@frase.id.au)
Received: (from fraser@localhost) by bacardi.hollandpark.frase.id.au (8.15.2/8.15.2/Submit) id 0BD5GMui093470; Sun, 13 Dec 2020 15:16:22 +1000 (EST) (envelope-from frase@frase.id.au)
X-Authentication-Warning: bacardi.hollandpark.frase.id.au: fraser set sender to frase@frase.id.au using -f
Date: Sun, 13 Dec 2020 15:16:22 +1000
From: Fraser Tweedale <frase@frase.id.au>
To: acme@ietf.org
Cc: Rich Salz <rsalz@akamai.com>
Message-ID: <X9WjpuaB+WsPMYLP@bacardi.hollandpark.frase.id.au>
References: <0C99CBF3-A8D3-4BB2-9A57-A9F946BED27D@akamai.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <0C99CBF3-A8D3-4BB2-9A57-A9F946BED27D@akamai.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/nz5Fkidg3zE-T-Z7FgYi1X9Dojw>
Subject: Re: [Acme] Short WGLC review of draft-ietf-acme-email-smime-13
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: Sun, 13 Dec 2020 05:16:32 -0000

On Thu, Dec 10, 2020 at 06:23:08PM +0000, Salz, Rich wrote:
> In order to address feedback that came up during AD and WGLC review, Alexey posted a new draft.
> This link will show the differences: https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-acme-email-smime-13.txt
> 
> Summary is that it adds text about putting the right keyUsage extensions (signing, encryption) so that different keys/certs can be used for signing and encryption. It’s important to be able to have separate signing and encryption keys.
> 
> Please send feedback by the end of next week.  Thanks!

There is ambiguity in Section 3.3:

   In order to request signing only S/MIME certificate, the CSR MUST
   include the key usage extension with digitalSignature and/or
   nonRepudiation bits set.

This text does not imply that that other bits, including
keyEncipherment/keyAgreement, MUST NOT be set.  I would suggest
appending "and no other bits set", i.e.:

   In order to request signing only S/MIME certificate, the CSR MUST
   include the key usage extension with digitalSignature and/or
   nonRepudiation bits set, and no other bits set.

Similarly for the subsequent paragraph (which can be solved the same
way):

   In order to request encryption only S/MIME certificate, the CSR MUST
   include the key usage extension with keyEncipherment and/or
   keyAgreement bits set.

Thanks,
Fraser