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

[David von Oheimb <[e-mail]>]

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 <[e-mail]>
>>
>> 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