Thanks. I also noticed ‘openssl x509’ has a -force_pubkey for this case. We’ll think about what is the best we can do.
—Max
> On Feb 1, 2021, at 11:23 AM, Anders Rundgren <anders.rundgren.net at gmail.com> wrote:
>
> 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://urldefense.com/v3/__https://tools.ietf.org/html/rfc2986*section-3__;Iw!!GqivPVa7Brio!Ijzb1F6vf9ECCLwUXYTNnZ0XEm7RWM5C17BPQO2k-YySNn8RpgCInbcsZ1pH23wpwA$ 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://urldefense.com/v3/__https://tools.ietf.org/html/rfc5272*section-3.2__;Iw!!GqivPVa7Brio!Ijzb1F6vf9ECCLwUXYTNnZ0XEm7RWM5C17BPQO2k-YySNn8RpgCInbcsZ1pvrP3bEQ$
>>> 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://urldefense.com/v3/__https://www.w3.org/TR/webauthn-2/*sctn-api__;Iw!!GqivPVa7Brio!Ijzb1F6vf9ECCLwUXYTNnZ0XEm7RWM5C17BPQO2k-YySNn8RpgCInbcsZ1olcwu24Q$
> 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://urldefense.com/v3/__https://cyberphone.github.io/doc/security/keygen2.html__;!!GqivPVa7Brio!Ijzb1F6vf9ECCLwUXYTNnZ0XEm7RWM5C17BPQO2k-YySNn8RpgCInbcsZ1rBveLZ7A$
> 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
>