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