Re: [Curdle] [Technical Errata Reported] RFC8410 (6229)

Benjamin Kaduk <kaduk@mit.edu> Tue, 04 August 2020 23:19 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: curdle@ietfa.amsl.com
Delivered-To: curdle@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8FDD3A112D for <curdle@ietfa.amsl.com>; Tue, 4 Aug 2020 16:19:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Lq-9ofOxY4eE for <curdle@ietfa.amsl.com>; Tue, 4 Aug 2020 16:19:38 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 0527E3A112A for <curdle@ietf.org>; Tue, 4 Aug 2020 16:19:37 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 074NJLOV029809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 4 Aug 2020 19:19:24 -0400
Date: Tue, 4 Aug 2020 16:19:21 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: simon@josefsson.org, ietf@augustcellars.com, rdd@cert.org, daniel.migault@ericsson.com, rsalz@akamai.com, David.von.Oheimb@siemens.com, curdle@ietf.org, lamps@ietf.org
Message-ID: <20200804231921.GW92412@kduck.mit.edu>
References: <20200712154032.8DD22F40745@rfc-editor.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200712154032.8DD22F40745@rfc-editor.org>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/461eeZgRrLI44QbydkriGou5q0c>
Subject: Re: [Curdle] [Technical Errata Reported] RFC8410 (6229)
X-BeenThere: curdle@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of potential new security area wg." <curdle.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/curdle>, <mailto:curdle-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/curdle/>
List-Post: <mailto:curdle@ietf.org>
List-Help: <mailto:curdle-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/curdle>, <mailto:curdle-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Aug 2020 23:19:40 -0000

Adding LAMPS.

My confidence level here is not terribly high, since there is no
certificate presented with the public key whose private key signed the
X25519 certificate in question and there is some possibility of a different
edge case that allows this behavior.

That said, it seems like the smallest possible change would be to just
remove the word "PKIX" from the description of the certificate in question.

-Ben

On Sun, Jul 12, 2020 at 08:40:32AM -0700, RFC Errata System wrote:
> The following errata report has been submitted for RFC8410,
> "Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure".
> 
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6229
> 
> --------------------------------------
> Type: Technical
> Reported by: David von Oheimb <David.von.Oheimb@siemens.com>
> 
> Section: 10.2
> 
> Original Text

> An example of a self-issued PKIX certificate using Ed25519 to sign an
> X25519 public key would be
> 
> Corrected Text
> --------------
> 
> 
> Notes
> -----
> The given example certificate is self-issued but not self-signed (which is fine because its public key cannot be used for signing).
> It includes a subjectKeyIdentifier but not an authorityKeyIdentifier.
> 
> For not self-signed certificates RFC 5280 requires in section 4.2.1.1 (https://tools.ietf.org/html/rfc5280#section-4.2.1.1) that the authorityKeyIdentifier is present.
> 
> Thus for such an example certificate the authorityKeyIdentifier MUST be added in order to be a conforming certificate.
> Otherwise, cert chain validation will be mislead to assume that the certificate is self-signed (while usually not actually verifying this supposition).
> 
> 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. 
> 
> --------------------------------------
> RFC8410 (draft-ietf-curdle-pkix-10)
> --------------------------------------
> Title               : Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure
> Publication Date    : August 2018
> Author(s)           : S. Josefsson, J. Schaad
> Category            : PROPOSED STANDARD
> Source              : CURves, Deprecating and a Little more Encryption
> Area                : Security
> Stream              : IETF
> Verifying Party     : IESG