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, 8 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