Re: [Curdle] [Technical Errata Reported] RFC8410 (6229)
David von Oheimb <David.von.Oheimb@siemens.com> Sat, 08 August 2020 14:22 UTC
Return-Path: <David.von.Oheimb@siemens.com>
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 7A7663A0915; Sat, 8 Aug 2020 07:22:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.845
X-Spam-Level:
X-Spam-Status: No, score=-2.845 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H3=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 ptwAvd74NeRx; Sat, 8 Aug 2020 07:22:44 -0700 (PDT)
Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) (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 C64BF3A0912; Sat, 8 Aug 2020 07:22:43 -0700 (PDT)
Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id 078EMPUg018201 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 8 Aug 2020 16:22:25 +0200
Received: from [139.22.34.45] ([139.22.34.45]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id 078EMO0O025955; Sat, 8 Aug 2020 16:22:24 +0200
From: David von Oheimb <David.von.Oheimb@siemens.com>
To: Benjamin Kaduk <kaduk@mit.edu>, 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, curdle@ietf.org, spasm@ietf.org
References: <20200712154032.8DD22F40745@rfc-editor.org> <20200804231921.GW92412@kduck.mit.edu> <58c7feda-4216-4e80-5149-efffc0812bdd@siemens.com>
Message-ID: <99da805d-0724-f745-629c-316c9d7a153e@siemens.com>
Date: Sat, 08 Aug 2020 16:22:23 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <58c7feda-4216-4e80-5149-efffc0812bdd@siemens.com>
Content-Type: multipart/alternative; boundary="------------5608F70DD90621469CC91297"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/ZVfUoo4WW2tIYYOd89XKExQwWOY>
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: Sat, 08 Aug 2020 14:22:48 -0000
To make things more constructive, I suggest here a replacement for the non-conforming cert. It has basically the same contents as the original one, but in addition a suitable AKID extension. Certificate: Data: Version: 3 (0x2) Serial Number: 0d:b3:b2:03:05:cd:67:9a:c3:db:8f:09:0e:42:7e:ec:09:e5:3d:44 Signature Algorithm: ED25519 Issuer: CN = IETF Test Demo Validity Not Before: Aug 8 14:18:35 2020 GMT Not After : Dec 31 14:18:35 2040 GMT Subject: CN = IETF Test Demo Subject Public Key Info: Public Key Algorithm: X25519 X25519 Public-Key: pub: 85:20:f0:09:89:30:a7:54:74:8b:7d:dc:b4:3e:f7: 5a:0d:bf:3a:0d:26:38:1a:f4:eb:a4:a9:8e:aa:9b: 4e:6a X509v3 extensions: X509v3 Basic Constraints: CA:FALSE X509v3 Key Usage: Key Agreement X509v3 Subject Key Identifier: CA:9A:B8:EB:0C:9B:BD:CC:73:2C:15:F8:7B:0A:0C:F0:78:B9:CC:04 X509v3 Authority Key Identifier: A2:8C:C1:F8:6E:59:60:D3:E0:3A:E7:5C:96:2C:97:A8:D4:48:29:3C Signature Algorithm: ED25519 Signature Value: 4b:6a:01:60:ec:9b:c1:d4:b1:82:3c:7b:7e:7d:ca:87:51:52: db:0b:8c:a6:6d:53:89:d8:86:e9:67:39:a0:8b:c4:0d:fa:8c: c5:91:c6:9b:e1:6f:a1:51:ad:59:87:fb:c1:21:69:d4:10:9f: c4:ee:de:25:57:bb:6b:af:35:06 -----BEGIN CERTIFICATE----- MIIBTjCCAQCgAwIBAgIUDbOyAwXNZ5rD248JDkJ+7AnlPUQwBQYDK2VwMBkxFzAV BgNVBAMMDklFVEYgVGVzdCBEZW1vMB4XDTIwMDgwODE0MTgzNVoXDTQwMTIzMTE0 MTgzNVowGTEXMBUGA1UEAwwOSUVURiBUZXN0IERlbW8wKjAFBgMrZW4DIQCFIPAJ iTCnVHSLfdy0PvdaDb86DSY4GvTrpKmOqptOaqNaMFgwCQYDVR0TBAIwADALBgNV HQ8EBAMCAwgwHQYDVR0OBBYEFMqauOsMm73McywV+HsKDPB4ucwEMB8GA1UdIwQY MBaAFKKMwfhuWWDT4DrnXJYsl6jUSCk8MAUGAytlcANBAEtqAWDsm8HUsYI8e359 yodRUtsLjKZtU4nYhulnOaCLxA36jMWRxpvhb6FRrVmH+8EhadQQn8Tu3iVXu2uv NQY= -----END CERTIFICATE----- On 08.08.20 15:05, David von Oheimb wrote: > > Thanks Ben for your comment. > > Unfortunately I cannot find online the whole tread of this discussion, > and I can neither find how to join the LAMPS mailing list, where there > might already be further responses. > Hope that nevertheless I can contribute to the discussion this way by > email and will receive any further responses. > > The cert in question is part of the OpenSSL repository at > https://github.com/openssl/openssl/blob/master/test/certs/ee-ed25519.pem > > To answer first your indirect question which private key signed this cert: > > As I found during the discussion on a somewhat related OpenSSL issue: > https://github.com/openssl/openssl/issues/1418#issuecomment-448204709 > > this cert has been signed by the private key belonging to > https://github.com/openssl/openssl/blob/master/test/certs/root-ed25519.pem > so that cert is the issuer cert of the cert in question, ee-ed25519.pem. > BTW, it would be less confusing if the cert file had been named > ee-x25519.pem instead. > > This issuing relation can be verified using the following OpenSSL command: > > apps/openssl verify -trusted test/certs/root-ed25519.pem > test/certs/ee-ed25519.pem > > RFC 8410 sections 10.1 and 10.2 > (https://tools.ietf.org/html/rfc8410#section-10.1) > do not clearly state this issuing relation with the public key given > in section 10.1, > which in my view is a further thing to be improved. > The OpenSSL repository contains this public key at > https://github.com/openssl/openssl/blob/master/test/certs/root-ed25519.pubkey.pem > > The private key corresponding to the public key given in 10.1 is given > in section 10.3 > but also here the relation with the public key is implicit and should > better be made explicit. > The OpenSSL repository contains this private key at > https://github.com/openssl/openssl/blob/master/test/certs/root-ed25519.privkey.pem > > Normally, the issuance of ee-ed25519 would be easy to detect by the > issuer/authority key ID of the cert, > but due to the malformedness that is the very issue being discussed in > this errata entry, the AKID is missing. > > I object the suggested trivial 'solution' to remove the word "PKIX" > from the description > because this does not really cure the form of the certificate. > Moreover I see not much sense to have bad examples of certs in RFCs > and other standards > unless they serve the purpose of explicitly giving as negative example > for some good reason. > Here, instead, the purpose of the example clearly is to illustrate > good use of an X25519 public key, > and this should be done in a positive, standards-compliant way, which > in this case means RFC 5280 / PKIX conformance. > > - David > > > On 05.08.20 01:19, Benjamin Kaduk wrote: >> 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
- [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