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

Benjamin Kaduk <kaduk@mit.edu> Tue, 04 August 2020 23:35 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 2B9793A115D; Tue, 4 Aug 2020 16:35:36 -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 TIP7AIR7SOWA; Tue, 4 Aug 2020 16:35:34 -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 13AD73A11E0; Tue, 4 Aug 2020 16:34:51 -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 074NYck1001425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 4 Aug 2020 19:34:40 -0400
Date: Tue, 04 Aug 2020 16:34:37 -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, spasm@ietf.org
Message-ID: <20200804233437.GX92412@kduck.mit.edu>
References: <20200712154032.8DD22F40745@rfc-editor.org> <20200804231921.GW92412@kduck.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20200804231921.GW92412@kduck.mit.edu>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/wF5LPUDWK3vJIv1rpggSZ-0DUw0>
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:35:36 -0000

On Tue, Aug 04, 2020 at 04:19:26PM -0700, Benjamin Kaduk wrote:
> Adding LAMPS.

This time for sure.
-Ben

> 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