Subject: Re: [lamps] [Technical Errata Reported] RFC8410 (6229)

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 4 Aug 2020 16:34:37 -0700

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 <[email-masked]>
> > 
> > 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

---

From: David von Oheimb <[email-masked]>
Date: Sat, 8 Aug 2020 15:09:57 +0200

-------- Forwarded Message --------
Subject: 	Re: [Technical Errata Reported] RFC8410 (6229)
Date: 	Sat, 8 Aug 2020 15:05:31 +0200
From: 	David von Oheimb <[email-masked]>
To: 	Benjamin Kaduk <[email-masked]>, RFC Errata System
<[email-masked]>
CC: 	[email-masked], [email-masked], [email-masked],
[email-masked], [email-masked], [email-masked],
[email-masked]

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

---

From: David von Oheimb <[email-masked]>
Date: Sat, 8 Aug 2020 16:22:23 +0200

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:
> do not clearly state this issuing relation with the public key given
> in section 10.1,
> I object the suggested trivial 'solution' to remove the word "PKIX"
> from the description
> Moreover I see not much sense to have bad examples of certs in RFCs
> and other standards
> 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
>
>