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]>
Sent: Monday, July 29, 2024 9:43 PM
To: Sipos, Brian J. <[email protected]>
Cc: [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]>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
