Re: [lamps] Second AD Review: draft-ietf-lamps-pkix-shake-10

Roman Danyliw <rdd@cert.org> Fri, 07 June 2019 15:54 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 544921201EC for <spasm@ietfa.amsl.com>; Fri, 7 Jun 2019 08:54:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 4oPHruGaJzQO for <spasm@ietfa.amsl.com>; Fri, 7 Jun 2019 08:54:00 -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 BCA9D120224 for <spasm@ietf.org>; Fri, 7 Jun 2019 08:53:20 -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 x57FrIOk010728; Fri, 7 Jun 2019 11:53:18 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu x57FrIOk010728
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1559922798; bh=/OdjxHILaFIBGXDdaO3qWdZkYS47KpSr13zo8+FKUi8=; h=From:To:Subject:Date:References:In-Reply-To:From; b=Si+KAc/bKMNhJDhHFSX8mP4sULLluZu+Rkgg0lqoIZbDdypop6WLK/MC5zv1z0pF6 QtVj3NPc4KgoE6pUfOFkDlfBjOwPz9tayIWpiVXLUfiQ2ecUIOBZ84eHhWYt38h3bL inA4tTyM+iH+RIQEVZujc/P5kBcK/kGvi210Fkxk=
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 x57FqmMT004644; Fri, 7 Jun 2019 11:53:15 -0400
Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0439.000; Fri, 7 Jun 2019 11:53:00 -0400
From: Roman Danyliw <rdd@cert.org>
To: "Panos Kampanakis (pkampana)" <pkampana@cisco.com>, "spasm@ietf.org" <spasm@ietf.org>
Thread-Topic: Second AD Review: draft-ietf-lamps-pkix-shake-10
Thread-Index: AdUaOicKPUSplJFAQJW7VEoVRR7HXgCWLijAAC19lfA=
Date: Fri, 7 Jun 2019 15:52:59 +0000
Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B338812D@marathon>
References: <359EC4B99E040048A7131E0F4E113AFC01B338267A@marathon> <BN7PR11MB2547128F9959735034E89B69C9170@BN7PR11MB2547.namprd11.prod.outlook.com>
In-Reply-To: <BN7PR11MB2547128F9959735034E89B69C9170@BN7PR11MB2547.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.22.6]
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/AiCCj9NVwwdQ1DR0bhz4HoCGdXA>
Subject: Re: [lamps] Second AD Review: draft-ietf-lamps-pkix-shake-10
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: Fri, 07 Jun 2019 15:54:04 -0000

Hi Panos!

The working revision below addresses all of my comments.  Thank you for these changes (and for making them proactively in the CMS draft as applicable too).

Roman

> -----Original Message-----
> From: Panos Kampanakis (pkampana) [mailto:pkampana@cisco.com]
> Sent: Thursday, June 06, 2019 2:11 PM
> To: Roman Danyliw <rdd@cert.org>rg>; spasm@ietf.org
> Subject: RE: Second AD Review: draft-ietf-lamps-pkix-shake-10
> 
> Thank you Roman. They are all addressed in the latest version
> https://github.com/csosto-pk/adding-shake-to-pkix/blob/master/draft-ietf-
> lamps-pkix-shake-current.txt The log of the actions take in regards to every
> individual comment is here https://github.com/csosto-pk/adding-shake-to-
> pkix/issues/44
> 
> I am planning to upload the next iteration next Monday unless there is more
> feedback.
> 
> Panos
> 
> 
> -----Original Message-----
> From: Spasm <spasm-bounces@ietf.org> On Behalf Of Roman Danyliw
> Sent: Monday, June 03, 2019 2:33 PM
> To: spasm@ietf.org
> Subject: [lamps] Second AD Review: draft-ietf-lamps-pkix-shake-10
> 
> Hi!
> 
> As a document I inherited in the "IESG:: Waiting for Writeup Internet-Drafts",
> I conducted a second AD review on draft-ietf-lamps-pkix-shake-10.  I have
> the following feedback:
> 
> (1) Header. Per idnits:    == The 'Updates: ' line in the draft header should list
> only the _numbers_ of the RFCs which will be updated by this document (if
> approved); it should not include the word 'RFC' in the list.
> 
> s/Updates: RFC3279/Updates: 3279/
> 
> (2) Additional References Needed
> 
> (2.a) Section 2
>    And, the
>    corresponding collision and second preimage resistance strengths for
>    SHAKE256 are min(d/2,256) and min(d,256) bits respectively.
> 
> Recommend you cite Section A.1 of [SHA3] as the source of these security
> strength metrics.
> 
> (2.b) Section 2
>    A SHAKE can be used as the message digest function (to hash the
>    message to be signed) in RSASSA-PSS and ECDSA  and as the hash in the
>    mask generating function in RSASSA-PSS.
> 
> Provide a reference on first use for RSASSA-PSS [RFC8017] and ECDSA [X9.62]
> 
> (3) Editorial
> (3.a) Section 5.1
>    In an
>    X.509 certificate a signature is encoded  with an algorithm identifier
>    in the signatureAlgorithm attribute and a signatureValue  that
>    contains the actual signature.
> 
> s/signatureValue/signatureValue attribute/
> 
> (3.b) Section 5.1.1.  Add commas between terms.
> 
> s/hash and mask generating algorithm and trailer and salt are embedded in
> the OID definition/ hash, mask generating algorithm, trailer and salt are
> embedded in the OID definition/
> 
> (3.c) Section 5.1.1.  Define the acronym MGF on first use
> 
> s/mask generation function/mask generation function (MGF)/
> 
> (3.d) Section 5.1.  Duplicate word.  s/section Section 4/Section 4/
> 
> (4) Section 5.1.  The ASN.1 blob of Certificate is inserted in the text without
> citation or explanation.  It seems like the paragraph prior to it should make
> explicit reference to it (as it cites the elements).
> 
> (5) Section 5.1.
>    They
>    MAY also generate such signatures in accordance with all other
>    recommendations in [X9.62] or [SEC1] if they have a stated policy
>    that requires conformance to these standards.  These standards may
>    have not specified SHAKE128 and SHAKE256 as hash algorithm options.
>    However, SHAKE128 and SHAKE256 with output length being 32 and 64
>    octets respectively are substitutions for 256 and 512-bit output hash
>    algorithms such as SHA256 and SHA512 used in the standards.
> 
> I recommend being more precise in this text.
> 
> s/These standards may have not specified SHAKE128 and SHAKE256 as hash
> algorithm options./ These standards have not specified SHAKE128 and
> SHAKE256 as hash algorithm options./
> 
> Per "SHAKE128 and SHAKE256 with output length being 32 and 64 octets
> respectively are substitutions for ... SHA256 and SHA 512", what does
> substitutions mean in this case?  Similar output size or cryptographic
> strength?
> 
> Regards,
> Roman
> 
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm