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
- [Curdle] [Technical Errata Reported] RFC8410 (622… RFC Errata System
- Re: [Curdle] [Technical Errata Reported] RFC8410 … Benjamin Kaduk
- Re: [Curdle] [Technical Errata Reported] RFC8410 … Benjamin Kaduk
- Re: [Curdle] [Technical Errata Reported] RFC8410 … David von Oheimb
- Re: [Curdle] [Technical Errata Reported] RFC8410 … David von Oheimb