Re: [IPsec] Last Call: <draft-kivinen-ipsecme-signature-auth-06.txt> (Signature Authentication in IKEv2) to Proposed Standard

Tero Kivinen <kivinen@iki.fi> Sun, 20 July 2014 19:03 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C72E1B2CD7 for <ipsec@ietfa.amsl.com>; Sun, 20 Jul 2014 12:03:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.122
X-Spam-Level:
X-Spam-Status: No, score=-1.122 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_NEUTRAL=0.779] autolearn=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 9O4mI2BkLpNA for <ipsec@ietfa.amsl.com>; Sun, 20 Jul 2014 12:03:03 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 378971B2CC0 for <ipsec@ietf.org>; Sun, 20 Jul 2014 12:03:03 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s6KJ30dH012493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 20 Jul 2014 22:03:00 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s6KJ2xLx006190; Sun, 20 Jul 2014 22:02:59 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <21452.4707.784185.458764@fireball.kivinen.iki.fi>
Date: Sun, 20 Jul 2014 22:02:59 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Johannes Merkle <johannes.merkle@secunet.com>
In-Reply-To: <53B6BA3F.40509@secunet.com>
References: <20140701161112.18036.94027.idtracker@ietfa.amsl.com> <53B6BA3F.40509@secunet.com>
X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd)
X-Edit-Time: 3 min
X-Total-Time: 2 min
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/3iBryhuN0qnHz0Wootu4tksUMfE
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Last Call: <draft-kivinen-ipsecme-signature-auth-06.txt> (Signature Authentication in IKEv2) to Proposed Standard
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 20 Jul 2014 19:03:06 -0000

Johannes Merkle writes:
> Nice work, the wording is really improved. However, I still have two
> comments: 
> 
> 1. The wording in A.4 is confusing.
> 
>    With RSASSA-PSS, the algorithm object identifier is always id-RSASSA-
>    PSS, but the hash function is taken from the optional parameters, and
>    is required.
> 
> It is not the hash function or the optional parameters that are
> required but the OID id-RSASSA-PSS. Secondly, the "but" in the
> second part of the sentence indicates some contrast but I don't see
> one. Furthermore, not only the hash function is determined from the
> parameters but also the other options for the padding.
> 
> Why not changing the text to
> 
>    With RSASSA-PSS, the algorithm object identifier must always be
>    id-RSASSA-PSS, and the hash function and padding parameters are
>    conveyed in the optional parameters.

Changed to:

	With RSASSA-PSS, the algorithm object identifier must always
	be id-RSASSA-PSS, and the hash function and padding parameters
	are conveyed in the parameters (which are not optional in this
	case). See <xref target="RFC4055"/> for more information.

In the RSASSA-PSS the parameters are required, but they can be empty,
so they are not optional in this case.

> 2. The wording in A.4.1 is also not unambiguous:
> 
>    Parameters are empty, but the ASN.1 part of the sequence must be
>    there.  This means default parameters are used (same as the next
>    example).
> 
> Here "next example" does not refer to the example following
> immediately after this paragraph but to the example in the next
> section. A reference to A.4.2 should be included.


Changed to:

	Parameters are empty, but the ASN.1 part of the sequence must
	be present. This means default parameters are used.

I.e removed the reference to next example.
	
-- 
kivinen@iki.fi