Lijun, Thanks so much for this feedback. I did have the OID encoding wrong and have corrected this locally. The SAN bundleEID is actually using a proposed update to RFC 9171 [3] which modifies the IPN scheme information and encoding, but may confuse this c509 comparison so I’ll avoid this in the future.
Since I’m now able to use the c509_demo_impl there are still a couple of discrepancies: 1. The current encoder seems to ignore the rule that single-valued EKU extensions should avoid the array envelope as in the CDDL from [1]: ExtKeyUsageSyntax = [ 2* KeyPurposeId ] / KeyPurposeId 2. I’m seeing a difference in the encoded public key bytestring, where the first byte is different from my encoder, which is using the Python `cryptography` library to encode the key as: node_key.public_key().public_bytes(serialization.Encoding.X962, serialization.PublicFormat.CompressedPoint) 3. My encoding of the signature itself needs to conform to the details from Section 3.2.2 of [1] which is different than the direct `cryptography` library ECDSA output. 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. For the third difference it seems to require digging into the `cryptography` library output and reformatting the data. Similar to above, it could be helpful to have a more explicit example of this transformation. I know it’s embedded as part of the Appendix A examples but this behavior wasn’t so obvious to me the first time through. Thanks again! Brian S. [3] https://www.ietf.org/archive/id/draft-ietf-dtn-ipn-update-13.html From: Lijun Liao <[email protected]> Sent: Tuesday, July 30, 2024 4:05 PM To: Sipos, Brian J. <[email protected]> Cc: Joel Höglund <[email protected]>; [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, 1. In the type 2 (native hex) C509 certificate, the content of extension id-on-bundleEID seems to be not correct: You have 111: 22 # [0]: simple(-3) 112: 82 # [1]: array(2) 113: 02 # [0]: simple(2) 114: 83 # [1]: array(3) 115: 1A 000EE868 # [0]: uint32(977000) 120: 0A # [1]: simple(10) 121: 00 # [2]: simple(0) Byte offset 114 indicates the SSP has 3 elements, but according to RFC 9171, for the uri-code 2 (as specified at offset 113), the SSP has only 2 elements $eid /= [ uri-code: 2, SSP: [ nodenum: uint, servicenum: uint ] ] 2. In the type 3 (re-encoded hex) C509 certificate, the OID 1.3.6.1.5.5.7.8.11 is not correctly encoded (starting at byte offset 114 as follows). It shall not have the leading DER tag (0x06) and DER length (0x08), as specified in RFC 9090 (see Example in Section 3. Basic Examples). 109: 03 # [0]: simple(3) 110: 82 # [1]: array(2) 111: 00 # [0]: simple(0) 112: 82 # [1]: array(2) 113: 4A # [0]: bytes(10) 114: 06082B0601050507080B 124: 51 # [1]: bytes(17) 125: 160F69706E3A3937373030302E31302E30 Lijun On 30. Jul 2024, at 19:01, Sipos, Brian J. <[email protected] <mailto:[email protected]> > wrote: Joel, Thanks for updating the source for these examples. I had attempted with hex encoding, but the `xxd` encoding tool adds newlines to the hex which isn’t accepted by the demo application. So after I removed those I see that the type-3 (convertible) cert is handled by this tool but not type-2 (native signed), but my type-3 c509 does get handled properly. Still no signature verification possible for a type-2 though. There is also what appears to be a typo in the output from that tool under “CBOR COSE_X509 with 1 certificates” heading that seems like it should read “COSE_C509” to be consistent with the actual content. Related to the OtherName form that I’m prototyping with (the id-on-bundleEID), I think it makes sense to add some conditions and caveats to the CBOR-encoded form which uses the GeneralName code point -3. A general purpose x509/c509 CODEC doesn’t need to use this compressed-form code point and could use code point 0 (OtherName) with the longer encoded OID+text form. This is true of the other negative-value GeneralName code points as well, but there isn’t really discussion on this currently. A BP-EID-aware CODEC could use code point -3 and save 20+ bytes of size at the expense of more processing needed. FWIW my dummy contents look like the following for X509 tree, c509-convertible, and c509-native Certificate: Data: Version: 3 (0x2) Serial Number: 0a:90:26:8e:51:b9:21:91:83:f5:ea:f3:ed:ad:1e:30:df:fa:57:38 Signature Algorithm: ecdsa-with-SHA256 Issuer: CN = Certificate Authority Validity Not Before: Jul 30 16:34:34 2024 GMT Not After : Aug 9 16:34:34 2024 GMT Subject: CN = ipn:977000.10.0 Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:20:ca:94:fd:d4:3f:df:a2:d1:c6:67:65:42:bc: 56:f1:c2:e5:91:bd:2e:1f:67:e9:53:74:b1:19:bc: e8:68:62:dd:b2:ee:70:90:a1:89:60:d6:22:1e:8e: 8a:26:cc:e2:09:8e:86:13:ca:13:1d:c6:d2:08:aa: b3:75:9e:a7:b2 ASN1 OID: prime256v1 NIST CURVE: P-256 X509v3 extensions: X509v3 Subject Alternative Name: othername: 1.3.6.1.5.5.7.8.11::ipn:977000.10.0 X509v3 Key Usage: critical Digital Signature X509v3 Extended Key Usage: 1.3.6.1.5.5.7.3.35 X509v3 Subject Key Identifier: 75:B7:2B:C4:B3:76:69:3E:48:24:77:48:59:97:60:36:12:6F:01:65 X509v3 Authority Key Identifier: 4E:43:2E:F3:A2:48:9A:08:7F:94:75:1E:F1:F5:58:11:2F:9C:F9:08 Signature Algorithm: ecdsa-with-SHA256 Signature Value: 30:46:02:21:00:dc:60:03:c6:f7:04:8c:84:80:84:6e:a1:0e: 4c:48:f1:1b:72:51:12:85:16:a4:b3:27:73:3a:c5:16:2f:a0: 2e:02:21:00:ae:16:65:65:06:fa:13:e5:24:b1:3d:14:83:f1: 5f:ba:7c:af:e7:9e:1c:39:0a:ee:72:70:0b:be:60:95:94:dc Convertible hex: 8B03540A90268E51B9219183F5EAF3EDAD1E30DFFA57380075436572746966696361746520417574686F726974791A66A9161A1A66B6451A6F69706E3A3937373030302E31302E300158210220CA94FDD43FDFA2D1C6676542BC56F1C2E591BD2E1F67E95374B119BCE868628A038200824A06082B0601050507080B51160F69706E3A3937373030302E31302E302101080E015475B72BC4B376693E4824774859976036126F016507544E432EF3A2489A087F94751EF1F558112F9CF90858483046022100DC6003C6F7048C8480846EA10E4C48F11B7251128516A4B327733AC5162FA02E022100AE16656506FA13E524B13D1483F15FBA7CAFE79E1C390AEE72700BBE609594DC Native hex: 8B02540A90268E51B9219183F5EAF3EDAD1E30DFFA57380075436572746966696361746520417574686F726974791A66A9161A1A66B6451A6F69706E3A3937373030302E31302E300158210220CA94FDD43FDFA2D1C6676542BC56F1C2E591BD2E1F67E95374B119BCE868628A0382228202831A000EE8680A002101080E015475B72BC4B376693E4824774859976036126F016507544E432EF3A2489A087F94751EF1F558112F9CF90858473045022100ACA691A3A7BDAADF5A5FB0F199818E6B0EBF0D5C77C8C082C972B5C0800F9ED502201BF8DC2D408F44A98EA8D021210EC33C9DF50747A8BB62DEB14266EAE11ADD9D From: Joel Höglund <[email protected] <mailto:[email protected]> > Sent: Monday, July 29, 2024 9:43 PM To: Sipos, Brian J. <[email protected] <mailto:[email protected]> > Cc: [email protected] <mailto:[email protected]> Subject: [EXT] Re: [COSE] c509 example verification APL external email warning: Verify sender [email protected] <mailto:[email protected]> before clicking links or attachments Thank you for highlighting the lack of expected c509 format description in the demo code! For simplicity, the code just expects the cbor content as a hex string. I added and pushed a small clarification + the example certificates from the draft (together with a bugfix). If the updated code gives you errors, I would be happy if you wanted to share your certificate for investigation. Best Regards Joel Höglund On Mon, 29 Jul 2024 at 22:19, Sipos, Brian J. <[email protected] <mailto:[email protected]> > wrote: All, I’m looking into creating some example c509 certificates which make use of SAN Other Name and EKU code points allocated by the current draft [1] for BP security. I think I have a properly encoded c509 structure using native signature, but don’t have a good way to verify that correctness. I tried using the tool under “c509_demo_impl” of the c509 source repo [2] but just get errors when attempting to use it in the read-C509 mode with “cargo r c …” and I’m not sure what I may be doing wrong (it’s not clear if the input is supposed to be direct binary, which I have tried, or some other form of text-encoding). Any help getting this tool, or some other more appropriate tool, working would be appreciated. Brian S. [1] https://www.ietf.org/archive/id/draft-ietf-cose-cbor-encoded-cert-11.html [2] https://github.com/cose-wg/CBOR-certificates _______________________________________________ COSE mailing list -- [email protected] <mailto:[email protected]> To unsubscribe send an email to [email protected] <mailto:[email protected]> _______________________________________________ COSE mailing list -- <mailto:[email protected]> [email protected] To unsubscribe send an email to <mailto:[email protected]> [email protected]
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
