[Anima] Feedback on constrained-voucher example voucher payloads (in Github / -09)

[Esko Dijk <[e-mail]>]

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: [e-mail]<mailto:[e-mail]>    |   [phone]