Hi Peter,
Here my feedback as result of reviewing the example voucher payloads:
*** pledge-to-regis.txt:
1- there seems to be an error in the delta encoding of the numeric SID keys.
If I decode the CBOR from the COSE payload in pledge-to-regis, I get the
following
{2501: {2503: "2020-10-5T13:46:13-00:00", 2505: "2022-10-5T13:46:13-00:00",
2502: 2, 2508: h'29C7BAFB81A2C6160D3357D22911F510', 2514: "pledge.1.2.3.4",
2511:
h'30820239308201DEA0030201020214397374F3FA812A0D37103B68C18481C501BC7CFE300A06082A8648CE3D0403023073310B3009060355040613024E4C310B300906035504080C024E423110300E06035504070C0748656C6D6F6E6431133011060355040A0C0A76616E64657273746F6B31143012060355040B0C0B636F6E73756C74616E6379311A301806035504030C117265676973747261722E73746F6B2E6E6C301E170D3230303930393037343230335A170D3231303930393037343230335A3073310B3009060355040613024E4C310B300906035504080C024E423110300E06035504070C0748656C6D6F6E6431133011060355040A0C0A76616E64657273746F6B31143012060355040B0C0B636F6E73756C74616E6379311A301806035504030C117265676973747261722E73746F6B2E6E6C3059301306072A8648CE3D020106082A8648CE3D030107034200046A24A9E24BE234D17AD47E760C94B5E1DC4EE115AD89112AD4A6A64BB1BF68F9177D70E9109CB48C9B0DC7DF2641199D0C2DBFF21ED584038AC83F4781BE138EA350304E301D0603551D0E0416041425CD9371B5A15F6D1EE8C37A5113BE0B8F132CC2301F0603551D2304183016801425CD9371B5A15F6D1EE8C37A5113BE0B8F132CC2300C0603551D13040530030101FF300A06082A8648CE3D0403020349003046022100A66D9E24F9DE08B7F0CF43C3C0EE57CCB660DEAE2E70CC61A1A2B33535025BBA022100BFFD746A99EBDA0177FC6C3795758AF4A09F998EBC4A906249F07AC96596DC75'}}
while based on
https://tools.ietf.org/html/draft-ietf-core-yang-cbor-13#section-4.2.1 I would
expect something like
{2501: {2: "2020-10-5T13:46:13-00:00", 4: "2022-10-5T13:46:13-00:00", 1: 2, 7:
h'29C7BAFB81A2C6160D3357D22911F510', 13: "pledge.1.2.3.4", 10:
h'30820239308201DEA0030201020214397374F3FA812A0D37103B68C18481C501BC7CFE300A06082A8648CE3D0403023073310B3009060355040613024E4C310B300906035504080C024E423110300E06035504070C0748656C6D6F6E6431133011060355040A0C0A76616E64657273746F6B31143012060355040B0C0B636F6E73756C74616E6379311A301806035504030C117265676973747261722E73746F6B2E6E6C301E170D3230303930393037343230335A170D3231303930393037343230335A3073310B3009060355040613024E4C310B300906035504080C024E423110300E06035504070C0748656C6D6F6E6431133011060355040A0C0A76616E64657273746F6B31143012060355040B0C0B636F6E73756C74616E6379311A301806035504030C117265676973747261722E73746F6B2E6E6C3059301306072A8648CE3D020106082A8648CE3D030107034200046A24A9E24BE234D17AD47E760C94B5E1DC4EE115AD89112AD4A6A64BB1BF68F9177D70E9109CB48C9B0DC7DF2641199D0C2DBFF21ED584038AC83F4781BE138EA350304E301D0603551D0E0416041425CD9371B5A15F6D1EE8C37A5113BE0B8F132CC2301F0603551D2304183016801425CD9371B5A15F6D1EE8C37A5113BE0B8F132CC2300C0603551D13040530030101FF300A06082A8648CE3D0403020349003046022100A66D9E24F9DE08B7F0CF43C3C0EE57CCB660DEAE2E70CC61A1A2B33535025BBA022100BFFD746A99EBDA0177FC6C3795758AF4A09F998EBC4A906249F07AC96596DC75'}}
This uses the delta encoding. In order to use the full SID number (e.g. 2503,
2505, etc.) these have to be prefixed with a CBOR tag. By default, delta
encoding is to be used if that tag is not present.
2- for the Registrar certificate embedded in field '10' above, see my previous
email about the certificates.
3- The Yang date-and-time format needs the date to be 2 digits always, so e.g.:
"2020-10-05T13:46:13-00:00". For a constrained system the following equivalent
string is even better: "2020-10-05T13:46:13Z"
4- The ‘created-on’ and ‘expires-on’ fields would typically not be included in
the constrained Voucher request, because the Pledge doesn’t have current time
e.g. a Real-time clock in typical situations nor access to NTP over the network
prior to bootstrap. So I would expect this to be not included typically. If
included the expires time should be sufficiently far in the future, i.e. later
than the ‘created’ timestamp. That’s currently not the case. Leaving both out
is the easiest solution :) - the nonce is anyway used for freshness
verification.
*** regis-to-masa.txt:
The decoded COSE payload looks as follows in CBOR diagnostic:
{2501: {2503: "2020-10-5T13:46:13-00:00", 2505: "2022-10-5T13:46:13-00:00",
2508: h'29C7BAFB81A2C6160D3357D22911F510', 2514: "pledge.1.2.3.4", 2506:
h'433D4E4C2C2053543D4E422C204C3D48656C6D6F6E642C204F3D76616E64657273746F6B2C204F553D6D616E75666163747572696E672C20434E3D757569643A706C656467652E312E322E332E342C2073657269616C4E756D6265723D706C656467652E312E322E332E34',
2510:
h'D28444A101382EA1045820F8926F5BA385B7BCCF23592B97A73C1B00BFFC010230F647F06960870B1FD6EE5902ACA11909C5A61909C77818323032302D31302D355431333A34363A31332D30303A30301909C97818323032322D31302D355431333A34363A31332D30303A30301909C6021909CC5029C7BAFB81A2C6160D3357D22911F5101909D26E706C656467652E312E322E332E341909CF59023D30820239308201DEA0030201020214397374F3FA812A0D37103B68C18481C501BC7CFE300A06082A8648CE3D0403023073310B3009060355040613024E4C310B300906035504080C024E423110300E06035504070C0748656C6D6F6E6431133011060355040A0C0A76616E64657273746F6B31143012060355040B0C0B636F6E73756C74616E6379311A301806035504030C117265676973747261722E73746F6B2E6E6C301E170D3230303930393037343230335A170D3231303930393037343230335A3073310B3009060355040613024E4C310B300906035504080C024E423110300E06035504070C0748656C6D6F6E6431133011060355040A0C0A76616E64657273746F6B31143012060355040B0C0B636F6E73756C74616E6379311A301806035504030C117265676973747261722E73746F6B2E6E6C3059301306072A8648CE3D020106082A8648CE3D030107034200046A24A9E24BE234D17AD47E760C94B5E1DC4EE115AD89112AD4A6A64BB1BF68F9177D70E9109CB48C9B0DC7DF2641199D0C2DBFF21ED584038AC83F4781BE138EA350304E301D0603551D0E0416041425CD9371B5A15F6D1EE8C37A5113BE0B8F132CC2301F0603551D2304183016801425CD9371B5A15F6D1EE8C37A5113BE0B8F132CC2300C0603551D13040530030101FF300A06082A8648CE3D0403020349003046022100A66D9E24F9DE08B7F0CF43C3C0EE57CCB660DEAE2E70CC61A1A2B33535025BBA022100BFFD746A99EBDA0177FC6C3795758AF4A09F998EBC4A906249F07AC96596DC7558473045022100FC28BE418E5F25152590E872B4BBDBE334CD31D1EBB0A806E7A172CAD5CFF604022056EE414DDAC438E7F51DDA9DDF6EC6E31A78CDDE6574717FE46DD3A7C60F5BB5'}}
1- see above comments on delta encoding and timestamps which shouldn’t be equal.
2- when I take the Issuer from the pledge.hex cert, I get the following bytes:
306F310B3009060355040613024E4C310B300906035504080C024E423110300E06035504070C0748656C6D6F6E6431133011060355040A0C0A76616E64657273746F6B31153013060355040B0C0C6D616E7566616374757265723115301306035504030C0C6D6173612E73746F6B2E6E6C
This should be identical to the field 2506 (idevid-issuer) in above COSE
payload, however in the decoded example it looks different. My ASN.1 decoder
even can’t decode it properly.
3- as already discussed in issue
https://github.com/anima-wg/constrained-voucher/issues/59 the COSE signing
needs to be updated to include a certificate signing chain of the Registrar.
(Can be length 1, 2, 3 or more) This can only be implemented of course once we
resolve this issue.
*** voucher-from-MASA.txt:
Decoded payload:
{2451: {2453: "2020-10-5T13:46:14-00:00", 2455: "2022-10-5T13:46:14-00:00",
2452: 3, 2458: h'29C7BAFB81A2C6160D3357D22911F510', 2462: "pledge.1.2.3.4",
2459:
h'30820239308201DEA0030201020214397374F3FA812A0D37103B68C18481C501BC7CFE300A06082A8648CE3D0403023073310B3009060355040613024E4C310B300906035504080C024E423110300E06035504070C0748656C6D6F6E6431133011060355040A0C0A76616E64657273746F6B31143012060355040B0C0B636F6E73756C74616E6379311A301806035504030C117265676973747261722E73746F6B2E6E6C301E170D3230303930393037343230335A170D3231303930393037343230335A3073310B3009060355040613024E4C310B300906035504080C024E423110300E06035504070C0748656C6D6F6E6431133011060355040A0C0A76616E64657273746F6B31143012060355040B0C0B636F6E73756C74616E6379311A301806035504030C117265676973747261722E73746F6B2E6E6C3059301306072A8648CE3D020106082A8648CE3D030107034200046A24A9E24BE234D17AD47E760C94B5E1DC4EE115AD89112AD4A6A64BB1BF68F9177D70E9109CB48C9B0DC7DF2641199D0C2DBFF21ED584038AC83F4781BE138EA350304E301D0603551D0E0416041425CD9371B5A15F6D1EE8C37A5113BE0B8F132CC2301F0603551D2304183016801425CD9371B5A15F6D1EE8C37A5113BE0B8F132CC2300C0603551D13040530030101FF300A06082A8648CE3D0403020349003046022100A66D9E24F9DE08B7F0CF43C3C0EE57CCB660DEAE2E70CC61A1A2B33535025BBA022100BFFD746A99EBDA0177FC6C3795758AF4A09F998EBC4A906249F07AC96596DC75',
2454: 0}}
1- see above on delta encoding and date values
2- the assertion value is 3, which is not defined, it should probably be 2
(proximity) here ?
3- the value of domain-cert-revocation-checks (2454) needs to be a CBOR boolean
‘false’. Currently uses an integer 0. Since YANG Boolean translates to CBOR
Boolean.
4- the “expires-on” field is not really needed in the Voucher. See BRSKI
section 5.6: the expires-on field is set for nonceless vouchers (since the
nonce is used for freshness by the Pledge – not really a need to have an
additional expiry time sent.) See also RFC 8366 for examples, the expires-on
field is there only used in nonce-less vouchers. And the Yang module code for
“leaf nonce” also formally defines a “must not” condition on the “expires-on”
field so the two cannot really be used together.
But if we want to include this field for some reason (which seems to go against
BRSKI and RFC 8366 so needs to be motivated!) then we would also rather set a
shorter timespan for Voucher validity. E.g. BRSKI 5.6 recommends something like
20 minutes time as the expected time e.g. to complete the bootstrap process. 2
years seems really too long for this.
Best regards
Esko
IoTconsultancy.nl | Email/Teams:
[email protected]<mailto:[email protected]> | +31 6
2385 8339
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
