Re: [pkix] [Technical Errata Reported] RFC4055 (5199)

Russ Housley <housley@vigilsec.com> Wed, 06 December 2017 15:30 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E91E1126DD9 for <pkix@ietfa.amsl.com>; Wed, 6 Dec 2017 07:30:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 d7Hu9EszZG6w for <pkix@ietfa.amsl.com>; Wed, 6 Dec 2017 07:30:26 -0800 (PST)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DC16120725 for <pkix@ietf.org>; Wed, 6 Dec 2017 07:30:26 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 76669300670 for <pkix@ietf.org>; Wed, 6 Dec 2017 10:30:25 -0500 (EST)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id A3MNLPKjjyBS for <pkix@ietf.org>; Wed, 6 Dec 2017 10:30:20 -0500 (EST)
Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 054553002C6; Wed, 6 Dec 2017 10:30:19 -0500 (EST)
From: Russ Housley <housley@vigilsec.com>
Message-Id: <7FC51BDF-D5E5-4473-9658-BE0F34C1021C@vigilsec.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_DBC78D87-69FE-4898-9CC5-D17A1EB25326"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Wed, 06 Dec 2017 10:30:19 -0500
In-Reply-To: <20171205213236.83CB1B81B9E@rfc-editor.org>
Cc: Jim Schaad <ietf@augustcellars.com>, Burt Kaliski <bkaliski@verisign.com>, Stefan Santesson <stefan@aaa-sec.com>, bernd-2017@eckenfels.net, IETF PKIX <pkix@ietf.org>
To: Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>, Eric Rescorla <ekr@rtfm.com>
References: <20171205213236.83CB1B81B9E@rfc-editor.org>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/ksSxa4b7-Evlf-Md_GwQy9i-c7M>
Subject: Re: [pkix] [Technical Errata Reported] RFC4055 (5199)
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Dec 2017 15:30:29 -0000

Burt Kaliski observes:

"""
The text in Sec. 4.1 of RFC4055 including the syntax of RSAES-OAEP-params largely follows Sec. 11.2.1 of RFC2437 (PKCS #1 v2.0), which uses the term “encoding parameters P”, rather than the Sec. A.2.1 of RFC3447 (PKCS #1 v2.1), which uses the term “label L”.  (RFC3560, the CMS profile for these algorithms, similarly follows RFC2437.)
 
RFC3447 acknowledges that “In previous versions of this specification, the term ‘encoding parameters’ was used”.  Given that RFC4055 inserts “commonly called” before RFC2437’s “P”, it appears that RFC4055 is attempting to bridge between RFC3447 and RFC2437.
"""

I observe that RFC 2437, RFC 3447, and RFC 4055 all use the same ASN.1 structure for RSAES-OAEP-params.  While the description of RSAES-OAEP in [P1v2.1] uses "L" instead of "P", this change in terminology did not carry through to the ASN.1 structure.

I think that this should not be classified as a technical errata.  Perhaps a better text would be:

   The pSourceFunc field identifies the source (and possibly the value)
   of the encoding parameters, commonly called P. (Note: it is referred
   to as label L in Section 7.1.1 of [P1v2.1], and it is referred to as P
   throughout [P1v2.0] and Section A.2.1 of [P1v2.1].)

   [P1v2.0] = RFC 2437

I don’t see an error here, so I think the corrected errata should be approved as editorial.

Russ



> On Dec 5, 2017, at 4:32 PM, RFC Errata System <rfc-editor@rfc-editor.org> wrote:
> 
> The following errata report has been submitted for RFC4055,
> "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5199
> 
> --------------------------------------
> Type: Technical
> Reported by: Bernd Eckenfels <bernd-2017@eckenfels.net>
> 
> Section: 4.1
> 
> Original Text
> -------------
> The pSourceFunc field identifies the source (and possibly the value)
> of the encoding parameters, commonly called P.
> 
> Corrected Text
> --------------
> The pSourceFunc field identifies the source (and possibly the value)
> of the encoding parameters, commonly called P. In the EME-OAEP encoding
> method [P1v2.1] defines this parameter as label L.
> 
> Notes
> -----
> There is no place where P is linked to the parameter name L as used in
> referenced [P1v2.1]
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC4055 (draft-ietf-pkix-rsa-pkalgs-03)
> --------------------------------------
> Title               : Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
> Publication Date    : June 2005
> Author(s)           : J. Schaad, B. Kaliski, R. Housley
> Category            : PROPOSED STANDARD
> Source              : Public-Key Infrastructure (X.509)
> Area                : Security
> Stream              : IETF
> Verifying Party     : IESG