Brain, Yes. The signature is valid using my tool. However, the public key in the native encoded certificate is not correct. It shall start with 0x02, but in your example, it is 0xFE.
Lijun > On 5. Sep 2024, at 22:49, Sipos, Brian J. <[email protected]> wrote: > > Lijun, > This is a helpful explanation for me to understand, coming at this from the > perspective of typically using COTS tools to manipulate PKIX artifacts. If I > prepared a sample natively-signed C509 cert using the keys included in the > C509 Appendix A.1.4 would you be able to verify the signature using your > tooling? > > This is the OpenSSL text form of the original dummy cert using the CA and EE > keys already in the C509 appendix. > > Certificate: > Data: > Version: 3 (0x2) > Serial Number: > 08:19:d6:46:4f:9f:1b:a8:d8:5f:ce:58 > Signature Algorithm: ecdsa-with-SHA256 > Issuer: CN = CA-1 > Validity > Not Before: Aug 29 11:41:18 2024 GMT > Not After : Sep 8 11:41:18 2024 GMT > Subject: CN = ipn:4196183048192010.0 > Subject Public Key Info: > Public Key Algorithm: id-ecPublicKey > Public-Key: (256 bit) > pub: > 04:b1:21:6a:b9:6e:5b:3b:33:40:f5:bd:f0:2e:69: > 3f:16:21:3a:04:52:5e:d4:44:50:b1:01:9c:2d:fd: > 38:38:ab:ac:4e:14:d8:6c:09:83:ed:5e:9e:ef:24: > 48:c6:86:1c:c4:06:54:71:77:e6:02:60:30:d0:51: > f7:79:2a:c2:06 > ASN1 OID: prime256v1 > NIST CURVE: P-256 > X509v3 extensions: > X509v3 Basic Constraints: critical > CA:FALSE > X509v3 Subject Alternative Name: > othername: 1.3.6.1.5.5.7.8.11::ipn:4196183048192010.0 > X509v3 Key Usage: critical > Digital Signature > X509v3 Extended Key Usage: > 1.3.6.1.5.5.7.3.35 > X509v3 Subject Key Identifier: > DD:FB:15:B3:1E:56:19:94:E3:9D:05:7A:44:26:B0:2B:FB:87:46:08 > X509v3 Authority Key Identifier: > BC:04:33:C1:0D:DF:CD:4F:3E:96:D0:46:C0:D7:6E:EA:A1:81:CD:9E > Signature Algorithm: ecdsa-with-SHA256 > Signature Value: > 30:44:02:20:04:1e:71:fd:2a:91:00:0d:5d:8f:a9:ba:11:9b: > 1e:0c:1e:4b:00:7e:ec:9a:a1:5c:60:87:29:b8:d8:e7:92:b6: > 02:20:04:0f:2e:0f:58:6c:2b:f4:ff:c3:3b:e1:f4:55:96:79: > 48:65:0b:d5:09:f4:b3:60:9a:ca:35:2f:f0:bb:c1:a6 > > Invertible c509 with copied SAN and EKU items, as hex string: > > 8b034c0819d6464f9f1ba8d85fce58006443412d311a66d05e5e1a66dd8d > 5e7669706e3a343139363138333034383139323031302e30015821feb121 > 6ab96e5b3b3340f5bdf02e693f16213a04525ed44450b1019c2dfd3838ab > 8c232103820082482b0601050507080b5818161669706e3a343139363138 > 333034383139323031302e302101080e0154ddfb15b31e561994e39d057a > 4426b02bfb8746080754bc0433c10ddfcd4f3e96d046c0d76eeaa181cd9e > 5840041e71fd2a91000d5d8fa9ba119b1e0c1e4b007eec9aa15c608729b8 > d8e792b6040f2e0f586c2bf4ffc33be1f455967948650bd509f4b3609aca > 352ff0bbc1a6 > > Native-signed c509 with compressed SAN bundleEID and EKU, as hex string: > > 8b024c0819d6464f9f1ba8d85fce58006443412d311a66d05e5e1a66dd8d > 5e7669706e3a343139363138333034383139323031302e30015821feb121 > 6ab96e5b3b3340f5bdf02e693f16213a04525ed44450b1019c2dfd3838ab > 8a0382228202821b000ee8680000000a002101080e0154ddfb15b31e5619 > 94e39d057a4426b02bfb8746080754bc0433c10ddfcd4f3e96d046c0d76e > eaa181cd9e5840feabc44f99ab30a5f396fc3a9bec51057f45353e7c5af1 > 3db093c2fab60311a099445b939006e0c8d64bb413089ca3572e498712f1 > 25293c86de8300a18b9d35 > > From: Lijun Liao <[email protected] <mailto:[email protected]>> > Sent: Wednesday, July 31, 2024 1:57 AM > To: Sipos, Brian J. <[email protected] <mailto:[email protected]>> > Cc: Joel Höglund <[email protected] <mailto:[email protected]>>; > [email protected] <mailto:[email protected]> > Subject: Re: [COSE] [EXT] Re: c509 example verification > > APL external email warning: Verify sender [email protected] > <mailto:[email protected]> before clicking links or attachments > > > Brian, > > Here the theory: > > If in X.509 certificate: Q_Uncompressed = 04 || Qx || Qy, > Normally Q_Compressed = 02 || Qx if Qy is even, and = 03 || Qy if Qy is odd. > And in C.509 certificate: 02 is replaced by 0xFE, and 03 by 0xFD. (Or just > 0x0100 - first byte, since 02 + 0xFE = 0x0100 = 03 + 0xFD) > > Lijun > > > On 30. Jul 2024, at 23:43, Sipos, Brian J. <[email protected] > <mailto:[email protected]>> wrote: > > > For the second difference it appears to be a nuance related to the > compression defined in Section 3.2.1 of [1]. Is this conversion as simple as > translating the first octet between 0x02 or 0x03 to 0xFD or 0xFE > respectively? The c509 draft might be a little more explicit on this point > for those of us familiar with manipulating X509 structures opaquely but not > familiar with specific field encodings.
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
