Re: 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....@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....@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