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]> 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 -- [email protected]
> To unsubscribe send an email to [email protected]
_______________________________________________
COSE mailing list -- [email protected]
To unsubscribe send an email to [email protected]
