Cert embedding a X25519 pubkey, signed by an Ed25519 key (not self signed)

[karalabe]

Hey there,

I have a fairly unorthodox use case (that is nonetheless conforming to all specs). I want to embed an x25519 public key into a certificate as the subject PKI. That requires a public key algorithm of X25519 == OID 1.3.101.110; but not being a digital signature algorithm means it cannot self sign itself. That is accepted according to the specs.

Furthermore, I want to be able to sign this cert using an ed25519 private key directly, NOT a CA. That is required for use cases where the root key is not some CA, rather a pinned key (i.e. hard coded well known key). This is again something supported by the spec.

You can generate such a certificate with openssl:

openssl genpkey -algorithm x25519 -out my-x25519-key
openssl pkey -in my-x25519-key -pubout -out my-x25519-key.pub

openssl genpkey -algorithm ed25519 -out my-ed25519-key

openssl x509 -new -force_pubkey my-x25519-key.pub -signkey my-ed25519-key -subj="/CN=test" -out my.cert

You can inspect it via:

openssl x509 -in my.cert -text -noout

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            3a:cb:5f:69:46:b1:5d:6a:91:a2:48:0e:cd:d5:24:7c:44:8b:9c:d1
        Signature Algorithm: ED25519
        Issuer: CN=test
        Validity
            Not Before: May 23 14:22:45 2025 GMT
            Not After : Jun 22 14:22:45 2025 GMT
        Subject: CN=test
        Subject Public Key Info:
            Public Key Algorithm: X25519
                X25519 Public-Key:
                pub:
                    17:c3:5b:94:28:bc:e4:75:b6:3b:fc:84:df:eb:3e:
                    9c:a0:91:3b:c4:f6:33:c6:4a:d5:4d:8e:c8:76:4d:
                    89:41
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                B9:49:DA:F2:64:6D:26:99:FB:CF:F7:A0:C1:37:C7:1F:51:C3:BF:D8
            X509v3 Authority Key Identifier: 
                88:97:CF:C8:82:5F:6D:11:4B:76:D5:59:34:28:06:A8:12:9E:5A:0B
    Signature Algorithm: ED25519
    Signature Value:
        90:e5:16:28:1a:e8:77:bd:21:78:7a:ed:ef:15:f6:18:f2:a8:
        5b:55:30:57:38:51:4b:4a:12:a4:53:63:ec:56:e2:af:7e:e9:
        65:34:c9:fb:d4:98:d3:41:38:24:94:ee:9c:cd:02:a4:92:f1:
        32:e6:34:c9:35:72:3e:ea:68:06

or

openssl asn1parse -inform PEM -in my.cert -i

    0:d=0  hl=4 l= 289 cons: SEQUENCE          
    4:d=1  hl=3 l= 212 cons:  SEQUENCE          
    7:d=2  hl=2 l=   3 cons:   cont [ 0 ]        
    9:d=3  hl=2 l=   1 prim:    INTEGER           :02
   12:d=2  hl=2 l=  20 prim:   INTEGER           :3ACB5F6946B15D6A91A2480ECDD5247C448B9CD1
   34:d=2  hl=2 l=   5 cons:   SEQUENCE          
   36:d=3  hl=2 l=   3 prim:    OBJECT            :ED25519
   41:d=2  hl=2 l=  15 cons:   SEQUENCE          
   43:d=3  hl=2 l=  13 cons:    SET               
   45:d=4  hl=2 l=  11 cons:     SEQUENCE          
   47:d=5  hl=2 l=   3 prim:      OBJECT            :commonName
   52:d=5  hl=2 l=   4 prim:      UTF8STRING        :test
   58:d=2  hl=2 l=  30 cons:   SEQUENCE          
   60:d=3  hl=2 l=  13 prim:    UTCTIME           :250523142245Z
   75:d=3  hl=2 l=  13 prim:    UTCTIME           :250622142245Z
   90:d=2  hl=2 l=  15 cons:   SEQUENCE          
   92:d=3  hl=2 l=  13 cons:    SET               
   94:d=4  hl=2 l=  11 cons:     SEQUENCE          
   96:d=5  hl=2 l=   3 prim:      OBJECT            :commonName
  101:d=5  hl=2 l=   4 prim:      UTF8STRING        :test
  107:d=2  hl=2 l=  42 cons:   SEQUENCE          
  109:d=3  hl=2 l=   5 cons:    SEQUENCE          
  111:d=4  hl=2 l=   3 prim:     OBJECT            :X25519
  116:d=3  hl=2 l=  33 prim:    BIT STRING        
  151:d=2  hl=2 l=  66 cons:   cont [ 3 ]        
  153:d=3  hl=2 l=  64 cons:    SEQUENCE          
  155:d=4  hl=2 l=  29 cons:     SEQUENCE          
  157:d=5  hl=2 l=   3 prim:      OBJECT            :X509v3 Subject Key Identifier
  162:d=5  hl=2 l=  22 prim:      OCTET STRING      [HEX DUMP]:0414B949DAF2646D2699FBCFF7A0C137C71F51C3BFD8
  186:d=4  hl=2 l=  31 cons:     SEQUENCE          
  188:d=5  hl=2 l=   3 prim:      OBJECT            :X509v3 Authority Key Identifier
  193:d=5  hl=2 l=  24 prim:      OCTET STRING      [HEX DUMP]:301680148897CFC8825F6D114B76D559342806A8129E5A0B
  219:d=1  hl=2 l=   5 cons:  SEQUENCE          
  221:d=2  hl=2 l=   3 prim:   OBJECT            :ED25519
  226:d=1  hl=2 l=  65 prim:  BIT STRING 

Would be nice to have support for generating these keys via rcgen too.

[djc]

Why doesn't rcgen support this? Where do you run into trouble?

[karalabe]

As far as I understand the docs, the way to sign a pubkey via a 3rd party key is CertificateParams::signed_by, where the key to be signed is PublicKeyData. The PublicKeyData however has an algorithm method that returns SignatureAlgorithm, which does not support X25519 (after all, it's not a signature algorithm). IMO the limitation is that PublicKeyData assumes it can only hold a key that can sign, whereas that's not the case.

[karalabe]

Another issue with signed_by is that it requires an issuer certificate, which I don't want to provide (it's the usual way, but for pinned root of trusts, you can also sign only with a key, without an issuer cert).

[karalabe]

This is the spec with the x25519 FWIW https://datatracker.ietf.org/doc/html/rfc8410, though you're probably aware as Ed25519 is also included in it :) Seems parts got left out for now. Would be amazing to support them though.

[djc]

As far as I understand the docs, the way to sign a pubkey via a 3rd party key is CertificateParams::signed_by, where the key to be signed is PublicKeyData. The PublicKeyData however has an algorithm method that returns SignatureAlgorithm, which does not support X25519 (after all, it's not a signature algorithm). IMO the limitation is that PublicKeyData assumes it can only hold a key that can sign, whereas that's not the case.

Another issue with signed_by is that it requires an issuer certificate, which I don't want to provide (it's the usual way, but for pinned root of trusts, you can also sign only with a key, without an issuer cert).

If you want to self-sign, use CertificateParams::self_signed() instead?

[chiro-hiro]

Hi @djc I got the same issue with P256,

I created a root CA root_key and root_cert then create a child_cert and child_key.

 let child_cert = child_cert.signed_by(&child_key, &root_cert, &root_key)?

This is working well so far

chiro@moon ~ % curl -vvv --cacert rootca.cert -X POST -d "Baby shark! do do do do"  https://127.0.0.1:7749/echo
Note: Unnecessary use of -X or --request, POST is already inferred.
*   Trying 127.0.0.1:7749...
* Connected to 127.0.0.1 (127.0.0.1) port 7749
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
*  CAfile: rootca.cert
*  CApath: none
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256 / [blank] / UNDEF
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=rcgen self signed cert
*  start date: Jan  1 00:00:00 1975 GMT
*  expire date: Jan  1 00:00:00 4096 GMT
*  subjectAltName: host "127.0.0.1" matched cert's IP address!
*  issuer: CN=rcgen self signed cert
*  SSL certificate verify ok.
* using HTTP/2

Should child_cert being self signed?

[chiro-hiro]

Key purpose:

root_ca.key_usages = vec![KeyUsagePurpose::KeyCertSign];

child_cert.key_usages = vec![KeyUsagePurpose::DigitalSignature];

[karalabe]

@chiro-hiro Please don't hijack this issue with an unrelated problem.

@djc I need to embed an X25519 key into a cert. That is allowed by the spec. That is not supported by this library (this library doesn't even have the notion of X25519 keys). X25519 is not a digital signature scheme, you cannot self sign with it.