[IPsec] [Editorial Errata Reported] RFC7427 (4295)

Tero Kivinen <kivinen@iki.fi> Tue, 24 March 2015 15:56 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 D57FC1A9056 for <ipsec@ietfa.amsl.com>; Tue, 24 Mar 2015 08:56:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.131
X-Spam-Level:
X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] 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 ItPFV-1CsLrN for <ipsec@ietfa.amsl.com>; Tue, 24 Mar 2015 08:56:02 -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 A44BC1A900A for <ipsec@ietf.org>; Tue, 24 Mar 2015 08:56:01 -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 t2OFtpUq023219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 24 Mar 2015 17:55:51 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t2OFtn1q009669; Tue, 24 Mar 2015 17:55:49 +0200 (EET)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <21777.35077.256865.60502@fireball.kivinen.iki.fi>
Date: Tue, 24 Mar 2015 17:55:49 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: RFC Errata System <rfc-editor@rfc-editor.org>
In-Reply-To: <20150310100921.959FD180207@rfc-editor.org>
References: <20150310100921.959FD180207@rfc-editor.org>
X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd)
X-Edit-Time: 15 min
X-Total-Time: 19 min
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipsec/2VCQi_Z7lKhdQ6eLDvGmxOkJVp4>
Cc: a.yousar@informatik.hu-berlin.de, paul.hoffman@vpnc.org, ipsec@ietf.org, Kathleen.Moriarty.ietf@gmail.com, jms@opus1.com, stephen.farrell@cs.tcd.ie
Subject: [IPsec] [Editorial Errata Reported] RFC7427 (4295)
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: Tue, 24 Mar 2015 15:56:04 -0000

RFC Errata System writes:
> The following errata report has been submitted for RFC7427,
> "Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=7427&eid=4295
> 
> --------------------------------------
> Type: Editorial
> Reported by: Annie Yousar <a.yousar@informatik.hu-berlin.de>
> 
> Section: A.4.2
> 
> Original Text
> -------------
>    Here the parameters are present and contain the default parameters,
>    i.e., hashAlgorithm of SHA-1, maskGenAlgorithm of mgf1SHA1,
>    saltLength of 20, and trailerField of 1.
> 
>    0000 : SEQUENCE
>    0002 :   OBJECT IDENTIFIER  RSASSA-PSS (1.2.840.113549.1.1.10)
>    000d :   SEQUENCE
>    000f :     CONTEXT 0
>    0011 :       SEQUENCE
>    0013 :         OBJECT IDENTIFIER  id-sha1 (1.3.14.3.2.26)
>    001a :         NULL
>    001c :     CONTEXT 1
>    001e :       SEQUENCE
>    0020 :         OBJECT IDENTIFIER  1.2.840.113549.1.1.8
>    002b :         SEQUENCE
>    002d :           OBJECT IDENTIFIER  id-sha1 (1.3.14.3.2.26)
>    0034 :           NULL
>    0036 :     CONTEXT 2
>    0038 :       INTEGER   0x14 (5 bits)
>    003b :     CONTEXT 3
>    003d :       INTEGER   0x1 (1 bits)
> 
>    Name = RSASSA-PSS with default parameters,
>           oid = 1.2.840.113549.1.1.10
>    Length = 64
>    0000: 303e 0609 2a86 4886 f70d 0101 0a30 31a0
>    0010: 0b30 0906 052b 0e03 021a 0500 a118 3016
>    0020: 0609 2a86 4886 f70d 0101 0830 0906 052b
>    0030: 0e03 021a 0500 a203 0201 14a3 0302 0101
> 
> 
> 
> Corrected Text
> --------------
>    If the default parameters are used, i.e., hashAlgorithm of SHA-1, 
>    maskGenAlgorithm of mgf1SHA1, saltLength of 20, and trailerField 
>    of 1, the parameters MUST NOT be encoded according to the 
>    Distiguished Encoding Rules (DER) of ASN.1. Therefore the encoding
>    is the same as of A.4.1.

Not true. In the RFC 4055 the section 3.1 says that even when the
default values are used the implementation MUST understand both
formats, i.e. the case where the default value is omitted and the case
where the default value is explictly given:

>From RFC4055 section 3.1:

      hashAlgorithm

         The hashAlgorithm field identifies the hash function.  It MUST
	 be one of the algorithm identifiers listed in Section 2.1, and
	 the default hash function is SHA-1.  Implementations MUST
	 support SHA-1 and MAY support any of the other one-way hash
	 functions listed in Section 2.1.  Implementations that perform
	 signature generation MUST omit the hashAlgorithm field when
	 SHA-1 is used, indicating that the default algorithm was used.
	 Implementations that perform signature validation MUST
	 recognize both the sha1Identifier algorithm identifier and an
	 absent hashAlgorithm field as an indication that SHA-1 was
	 used.

In this case we are not actually doing either one of those options, we
are not generating signature, and we are not validating them. In this
document we are simply indicating what kind of signature will follows
this binary blob. Yes, when generating those ASN.1 objects for default
values implementations should use the A.4.1 version, but they might
also want to understand the version specified in the A.4.2.

Note, that in some cases the implementations might simply take the
AlgorithmIdentifier pieces from their own cerificate and not generate
it at all, and this might cause them to take whatever the CA vendor
generated for them.

Actually when checking for the RFC4055 I notice it says that same
thing (MUST omit in generate, MUST recognize both) for everything else
(hashAlgorithm, maskGenAlgorithm, and trailerField) expect for
saltLength... I do not know if this means that for saltLength we
should actually not encode the default as number or if this is just
sloppy writing of the RFC4055...

>    0000 : SEQUENCE
>    0002 :   OBJECT IDENTIFIER  RSASSA-PSS (1.2.840.113549.1.1.10)
>    000d :   SEQUENCE
> 
>    Name = RSASSA-PSS with default parameters,
>           oid = 1.2.840.113549.1.1.10
>    Length = 15
>    0000: 300d 0609 2a86 4886 f70d 0101 0a30 00
> 
> 
> Notes
> -----
> Section 3 requires the use of DER:
> The ASN.1 used here is the same ASN.1 used in the AlgorithmIdentifier of PKIX (see Section 4.1.1.2 of [RFC5280]), encoded using distinguished encoding rules (DER) [CCITT.X690.2002].

Yes, when generating them they needs to be in DER, when matching the
values sent from the other end, the matching can be looser.

We could add note saying that format A.4.1 MUST be used when
generating the RSASSA-PSS with default parameters, but A.4.2 can also
be recognized.

If the implementation has real ASN.1 parser this is exactly what it
will do automatically.
-- 
kivinen@iki.fi