Re: Keytool does not agree with RFC 8410

[Wei-Jun Wang]

> On Feb 1, 2021, at 2:32 AM, Anders Rundgren <anders.rundgren....@gmail.com> 
> wrote:
> 
> On 2021-01-31 20:00, Wei-Jun Wang wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8260693 filed.
> 
> Thanx!
> In the bug report you also write:
> 
>    We'll also need a way to generate this kind of certificate (or certreq).
>    There is no signature algorithm on XDH and we need to use EdDSA instead.
>    See 
> https://urldefense.com/v3/__https://tools.ietf.org/html/rfc8410*section-10.2__;Iw!!GqivPVa7Brio!NmY7j2ZVt-VJoTtZkQFA8tbhvHgLZazChGpwWEbycxxjAHm6aDkm8clW3eJ2H14Ugw$
>  .
> 
> AFAIK there is no standard for CSRs for encryption keys.  You need to use a 
> signature key that sort of vouches for the enclosed public key.  This key may 
> use any valid signature algorithm.

https://tools.ietf.org/html/rfc2986#section-3 says:

        1. A CertificationRequestInfo value containing a subject
           distinguished name, a subject public key, and optionally a
           set of attributes is constructed by an entity requesting
           certification.

        2. The CertificationRequestInfo value is signed with the subject
           entity's private key.  (See Section 4.2.)

It hasn’t said the “public key” and “private key” above should be a pair, 
though.

> 
> As a side note, my own applications use a key container attestation key for 
> *all* CSRs which is a more useful method than self-signed CSRs.

Interesting. Is there any document describing this feature?

Thanks,
Max

> 
> Regards,
> Anders
> 
> 
>> Thanks,
>> Max
>>> On Jan 31, 2021, at 2:12 AM, Anders Rundgren 
>>> <anders.rundgren....@gmail.com> wrote:
>>> 
>>> Since the JDK bug report tool does not include "keytool" I posted this here.
>>> 
>>> Keytool for JDK 15 reports "Subject Public Key Algorithm: XDH key of 
>>> unknown size" for a certificate  containing the following public key:
>>> 
>>> 148:     SEQUENCE {
>>>  150:       SEQUENCE {
>>>  152:         OBJECT IDENTIFIER X25519 (1.3.101.110)
>>>             }
>>>  157:       BIT STRING, 32 bytes
>>>       0000: a3 5e 94 ef bd d0 41 86 90 07 87 9e 80 d0 a5 76 
>>> '.^....A........v'
>>>       0010: 0e a1 ba 82 19 2e c3 90 21 89 05 5a f6 d9 e6 50 
>>> '........!..Z...P'
>>>           }
>>> 
>>> which seems to be aligned with: 
>>> https://urldefense.com/v3/__https://tools.ietf.org/html/rfc8410*section-10.2__;Iw!!GqivPVa7Brio!NmY7j2ZVt-VJoTtZkQFA8tbhvHgLZazChGpwWEbycxxjAHm6aDkm8clW3eJ2H14Ugw$
>>>  
>>> You can verify this issue by importing the certificate in the RFC.
>>> 
>>> Anders