Keytool does not agree with RFC 8410

[Anders Rundgren]

On 2021-02-01 16:01, Wei-Jun Wang wrote:
> 
>> On Feb 1, 2021, at 2:32 AM, Anders Rundgren <anders.rundgren.net at 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.

I believe this is sort of "implicit" because otherwise there would be a need to indicate which key that was used in order to verify the signature.

CMC was probably designed to cope with this restriction.
https://tools.ietf.org/html/rfc5272#section-3.2

>> 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?

WebAuthn appears to use this method although they only register public keys:
https://www.w3.org/TR/webauthn-2/#sctn-api

My particular take on this is a bit more elaborate because the attestation is rather creating a session and shared key which permits secure multi-step key (store) management operations:
https://cyberphone.github.io/doc/security/keygen2.html

Thanx,
Anders

> 
> Thanks,
> Max
> 
>>
>> Regards,
>> Anders
>>
>>
>>> Thanks,
>>> Max
>>>> On Jan 31, 2021, at 2:12 AM, Anders Rundgren <anders.rundgren.net at 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
>