[lamps] AD Review of draft-ietf-lamps-cms-update-alg-id-protect-02

Roman Danyliw <rdd@cert.org> Mon, 27 July 2020 19:03 UTC

Return-Path: <rdd@cert.org>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47B253A0044 for <spasm@ietfa.amsl.com>; Mon, 27 Jul 2020 12:03:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, 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=cert.org
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 7T0Bab0CSDnF for <spasm@ietfa.amsl.com>; Mon, 27 Jul 2020 12:03:23 -0700 (PDT)
Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CECE53A087D for <spasm@ietf.org>; Mon, 27 Jul 2020 12:03:22 -0700 (PDT)
Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 06RJ3LAt003315 for <spasm@ietf.org>; Mon, 27 Jul 2020 15:03:22 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu 06RJ3LAt003315
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1595876602; bh=919lE83umq/5KkwZoI8hfZJZTa9VLO/HnoBKEp6j9rA=; h=From:To:Subject:Date:From; b=SOmBxwQuDxulXlDT3Ccdu4t/AbfnddtinL30h/Jc8LDRJQE7ZbvEuCCGWWxDSetZ0 dV+zKHiha3N4M3xdLOod0ZBT9QJ7GQgf8V3gux+iRBLo968hX1MLFz2vt/R9Tf58ev EtVITIyaC5gMrMSbzT+8+RWklCiz7RfULw0vkLcM=
Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 06RJ3Iio020689 for <spasm@ietf.org>; Mon, 27 Jul 2020 15:03:18 -0400
Received: from MURIEL.ad.sei.cmu.edu (147.72.252.47) by CASCADE.ad.sei.cmu.edu (10.64.28.248) with Microsoft SMTP Server (TLS) id 14.3.487.0; Mon, 27 Jul 2020 15:03:18 -0400
Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MURIEL.ad.sei.cmu.edu (147.72.252.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Mon, 27 Jul 2020 15:03:17 -0400
Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.1979.003; Mon, 27 Jul 2020 15:03:17 -0400
From: Roman Danyliw <rdd@cert.org>
To: LAMPS WG <spasm@ietf.org>
Thread-Topic: AD Review of draft-ietf-lamps-cms-update-alg-id-protect-02
Thread-Index: AdZkSFWD+IydvLxlRLucfc76q2usIA==
Date: Mon, 27 Jul 2020 19:03:16 +0000
Message-ID: <a71b205936bc43b3ad0b8d78b15a3093@cert.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.201.41]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/Bz-CNNjnHGmtHOKpMN81uYvwtgA>
Subject: [lamps] AD Review of draft-ietf-lamps-cms-update-alg-id-protect-02
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jul 2020 19:03:36 -0000

Hi!

I conducted an AD review of draft-ietf-lamps-cms-update-alg-id-protect-02.  Thanks for the work on this document to harden CMS.  Below is my feedback.  As it is editorial in nature, it can be handled with any other IETF LC feedback.

** Section 3.  Section title. Editorial. s/Require use the same hash algorithm/Required use of the same hash algorithm/

** Section 3.  Editorial.  Recommend consistent use of either signedAttrs or signedAttributes (i.e., choose either the data structure name or the variable name)
-- Section 3.1 says "If signedAttrs are present in SignerInfo ..."

-- Section 3.2 says "When the signedAttrs field is present ..."

-- Section 3.3.says "If the SignedData signerInfo includes signedAttributes ..." and "... included in the signedAttributes of the SignedData signerInfo"

** Section 3.1.  Editorial.  Simplify the guidance.

OLD
If signedAttrs are present in the SignerInfo, then the same digest
      algorithm MUST be used to compute the digest of the SignedData
      encapContentInfo eContent, which is carried in the message-digest
      attribute, and to compute the digest of the DER-encoded SET OF
      signed attributes, which is passed to the signature algorithm.
NEW
If signedAttrs are present in the SignerInfo, then the same digest algorithm MUST be used to compute both the digest of the SignedData encapContentInfo eContent, which is carried in the message-digest attribute, and the digest of the DER-encoded SET OF signed attributes, which is passed to the signature algorithm.

** Section 3.2. Typo. s/the the/the/

** Section 3.3.  Typo. s/the the/the/

** Section 3.4.  Significant editorial.  s/might lead to compatibility/might lead to incompatibility/

** Section 6.  Per "There is not currently protection mechanism ..." and "Likewise there is not currently a protection mechanism ...", it's true that these are a gap, but would that age well?  Perhaps just say:

OLD
There is not currently protection mechanism for
   the algorithm identifiers used in the enveloped-data, digested-data,
   or encrypted-data content types.  Likewise there is not currently a
   protection mechanism for the algorithm identifiers used in the
   authenticated-enveloped-data content type defined in [RFC5083].

NEW

It provides no protection mechanism for the algorithm identifiers used in the enveloped-data, digested-data, or encrypted-data content types.  Likewise, The CMSAlgorithmProtection attribute provides no protection for the algorithm identifiers used in the authenticated-enveloped-data content type defined in [RFC5083].

Regards,
Roman