Re: Keytool does not agree with RFC 8410
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
> wrote:
>
> On 2021-02-01 16:01, Wei-Jun Wang wrote:
>>> On Feb 1, 2021, at 2:32 AM, Anders Rundgren
>>> 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
> 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
> : a3 5e 94 ef bd d0 41 86 90 07 87 9e 80 d0 a5 76
> '.^Av'
> 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
>
Re: Keytool does not agree with RFC 8410
On 2021-02-01 16:01, Wei-Jun Wang wrote:
On Feb 1, 2021, at 2:32 AM, Anders Rundgren
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
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
: a3 5e 94 ef bd d0 41 86 90 07 87 9e 80 d0 a5 76 '.^Av'
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
Re: Keytool does not agree with RFC 8410
> On Feb 1, 2021, at 2:32 AM, Anders Rundgren
> 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
>>> 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
>>> : a3 5e 94 ef bd d0 41 86 90 07 87 9e 80 d0 a5 76
>>> '.^Av'
>>> 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
Re: Keytool does not agree with RFC 8410
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://tools.ietf.org/html/rfc8410#section-10.2.
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.
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.
Regards,
Anders
Thanks,
Max
On Jan 31, 2021, at 2:12 AM, Anders Rundgren
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
: a3 5e 94 ef bd d0 41 86 90 07 87 9e 80 d0 a5 76 '.^Av'
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://tools.ietf.org/html/rfc8410#section-10.2
You can verify this issue by importing the certificate in the RFC.
Anders
Re: Keytool does not agree with RFC 8410
https://bugs.openjdk.java.net/browse/JDK-8260693 filed.
Thanks,
Max
> On Jan 31, 2021, at 2:12 AM, Anders Rundgren
> 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
> : a3 5e 94 ef bd d0 41 86 90 07 87 9e 80 d0 a5 76 '.^Av'
> 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://tools.ietf.org/html/rfc8410#section-10.2
>
> You can verify this issue by importing the certificate in the RFC.
>
> Anders
