Re: In-the-wild implementations of RFC6955?
Anders Rundgren <[email protected]> Thu, 26 May 2022 21:22:25 +0200
| Newsgroups | gmane.ietf.x509 |
|---|---|
| Message-ID | <[email protected]> |
On 2022-05-26 19:58, Michael StJohns wrote:
> This looks like a perfectly sane X25519 certificate, signed by what's
> probably a P521 CA. You could remove the basicConstraints extension,
> but it shouldn't cause any problems being there.
>
> I'm actually more interested in the CSR you used to get the CA to issue
> the certificate.
As I understand, for a genuine CA solution, RFC6955 would be the proper approach. I only generated keys locally and called a certificate creation API.
Anders
>
> Thanks - Mike
>
>
> On 5/26/2022 1:42 PM, Anders Rundgren wrote:
>> It seems that things get a bit more challenging with ECDH using X25519
>> keys:
>> https://mta.openssl.org/pipermail/openssl-users/2021-March/013549.html
>>
>> This is (hopefully) a proper ECDH certificate using an X25519 public key:
>>
>>
>> 0: SEQUENCE {
>> 4: SEQUENCE {
>> 8: [0] {
>> 10: INTEGER 2
>> }
>> 13: INTEGER 01 80 fb 4a 58 1a
>> 21: SEQUENCE {
>> 23: OBJECT IDENTIFIER ecdsa-with-Sha512 (1.2.840.10045.4.3.4)
>> }
>> 33: SEQUENCE {
>> 35: SET {
>> 37: SEQUENCE {
>> 39: OBJECT IDENTIFIER commonName (2.5.4.3)
>> 44: PrintableString 'Test Sub CA'
>> }
>> }
>> }
>> 57: SEQUENCE {
>> 59: UTCTime 180101000000
>> 74: UTCTime 301231235959
>> }
>> 89: SEQUENCE {
>> 91: SET {
>> 93: SEQUENCE {
>> 95: OBJECT IDENTIFIER commonName (2.5.4.3)
>> 100: PrintableString 'Test certificate matching
>> x25519privatekey.pem'
>> }
>> }
>> }
>> 148: SEQUENCE {
>> 150: SEQUENCE {
>> 152: OBJECT IDENTIFIER X25519 (1.3.101.110)
>> }
>> 157: BIT STRING, 32 bytes
>> 0000: e9 9a 0c ef 20 58 94 96 0d 9b 1c 05 97 85 13 dc '....
>> X..........'
>> 0010: cb 42 a1 3b fb ce d5 23 a5 1b 8a 11 7a d5 f0 0c
>> '.B.;...#....z...'
>> }
>> 192: [3] {
>> 194: SEQUENCE {
>> 196: SEQUENCE {
>> 198: OBJECT IDENTIFIER basicConstraints (2.5.29.19)
>> 203: OCTET STRING, encapsulates {
>> 205: SEQUENCE {
>> }
>> }
>> }
>> 207: SEQUENCE {
>> 209: OBJECT IDENTIFIER keyUsage (2.5.29.15)
>> 214: BOOLEAN true
>> 217: OCTET STRING, encapsulates {
>> 219: BIT STRING, 5 bits (unused=3) '00001'B
>> }
>> }
>> 223: SEQUENCE {
>> 225: OBJECT IDENTIFIER subjectKeyIdentifier (2.5.29.14)
>> 230: OCTET STRING, encapsulates {
>> 232: OCTET STRING, 20 bytes
>> 0000: b2 79 b5 8e 62 05 b5 3d e3 7c 6a 54 5e 36 de ae
>> '.y..b..=.|jT^6..'
>> 0010: 02 90 08 98 '....'
>> }
>> }
>> 254: SEQUENCE {
>> 256: OBJECT IDENTIFIER authorityKeyIdentifier (2.5.29.35)
>> 261: OCTET STRING, encapsulates {
>> 263: SEQUENCE {
>> 265: [0], 20 bytes
>> 0000: a3 11 65 cf 5d c0 50 a7 4b e5 19 e1 76 7b 54 9a
>> '..e.].P.K...v{T.'
>> 0010: b7 4f 97 8a '.O..'
>> }
>> }
>> }
>> }
>> }
>> }
>> 287: SEQUENCE {
>> 289: OBJECT IDENTIFIER ecdsa-with-Sha512 (1.2.840.10045.4.3.4)
>> }
>> 299: BIT STRING, encapsulates {
>> 303: SEQUENCE {
>> 306: INTEGER
>> 01 b7 80 e4 b5 5c 68 90 81 39 15 03 f4 c1 da 08
>> df 9f 33 db 7b a4 e9 e3 f1 3b 5a ad 99 c3 07 9c
>> 34 b4 09 a8 4a 7c 67 73 dc c2 51 e5 9e 6c 58 de
>> 3e 54 45 47 e0 5d 42 b9 16 26 d5 86 c5 f4 86 3e
>> 61 f2
>> 374: INTEGER
>> 01 ba d7 5c a2 fa b8 39 6f 14 09 7c ff 55 45 88
>> 9e 9d 9d 4d f3 44 cd de c8 de 92 75 f1 13 fb 54
>> 43 92 5e 90 79 97 66 b9 bf ac 8e 88 b5 19 82 ad
>> d2 f1 04 e6 4c 94 d1 06 9d 64 8d 50 02 4a fe 48
>> 72 7b
>> }
>> }
>> }
>>
>> Anders
>
>
_______________________________________________
pkix mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pkix