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

From: Esko Dijk <[email-masked]>
Date: Fri, 4 Dec 2020 14:33:55 +0000

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-masked]<mailto:[email-masked]>    |   +31 6 2385 8339

---

From: Peter van der Stok <[email-masked]>
Date: Fri, 04 Dec 2020 15:56:20 +0100

Hi Esko,

thanks,
several oversights from me, especially forgetting the delta encoding for
SID is difficult to explain.

Once everythings is repaired, I will issue a new version with updated
examples.

Peter
Esko Dijk schreef op 2020-12-04 15:33:

> {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'30820239308201DEA0030201020214397374F3FA812A0D37103B68C18481C501BC7CFE300A06082A8648CE3D0403023073310B3009060355040613024E4C310B300906035504080C024E423110300E06035504070C0748656C6D6F6E6431133011060355040A0C0A76616E64657273746F6B31143012060355040B0C0B636F6E73756C74616E6379311A301806035504030C117265676973747261722E73746F6B2E6E6C301E170D3230303930393037343230335A170D3231303930393037343230335A3073310B3009060355040613024E4C310B300906035504080C024E423110300E06035504070C0748656C6D6F6E6431133011060355040A0C0A76616E64657273746F6B31143012060355040B0C0B636F6E73756C74616E6379311A301806035504030C117265676973747261722E73746F6B2E6E6C3059301306072A8648CE3D020106082A8648CE3D030107034200046A24A9E24BE234D17AD47E760C94B5E1DC4EE115AD89112AD4A6A64BB1BF68F9177D70E9109CB48C9B0DC7DF2641199D0C2DBFF21ED584038AC83F4781BE138EA350304E301D0603551D0E0416041425CD9371B5A15F6D1EE8C37A5113BE0B8F132CC2301F0603551D2304183016801425CD9371B5A15F6D1EE8C37A5113BE0B8F132CC2300C0603551D13040530030101FF300A06082A8648CE3D040302
0349003046022100A66D9E24F9DE08B7F0CF43C3C0EE57CCB660DEAE2E70CC61A1A2B33535025BBA022100BFFD746A99EBDA0177FC6C3795758AF4A09F998EBC4A906249F07AC96596DC75'}} 
> 
> while based on https://tools.ietf.org/html/draft-ietf-core-yang-cbor-13#section-4.2.1 [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'30820239308201DEA0030201020214397374F3FA812A0D37103B68C18481C501BC7CFE300A06082A8648CE3D0403023073310B3009060355040613024E4C310B300906035504080C024E423110300E06035504070C0748656C6D6F6E6431133011060355040A0C0A76616E64657273746F6B31143012060355040B0C0B636F6E73756C74616E6379311A301806035504030C117265676973747261722E73746F6B2E6E6C301E170D3230303930393037343230335A170D3231303930393037343230335A3073310B3009060355040613024E4C310B300906035504080C024E423110300E06035504070C0748656C6D6F6E6431133011060355040A0C0A76616E64657273746F6B31143012060355040B0C0B636F6E73756C74616E6379311A301806035504030C117265676973747261722E73746F6B2E6E6C3059301306072A8648CE3D020106082A8648CE3D030107034200046A24A9E24BE234D17AD47E760C94B5E1DC4EE115AD89112AD4A6A64BB1BF68F9177D70E9109CB48C9B0DC7DF2641199D0C2DBFF21ED584038AC83F4781BE138EA350304E301D0603551D0E0416041425CD9371B5A15F6D1EE8C37A5113BE0B8F132CC2301F0603551D2304183016801425CD9371B5A15F6D1EE8C37A5113BE0B8F132CC2300C0603551D13040530030101FF300A06082A8648CE3D040302
0349003046022100A66D9E24F9DE08B7F0CF43C3C0EE57CCB660DEAE2E70CC61A1A2B33535025BBA022100BFFD746A99EBDA0177FC6C3795758AF4A09F998EBC4A906249F07AC96596DC75'}} 
> 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: 
> 
> {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'D28444A101382EA1045820F8926F5BA385B7BCCF23592B97A73C1B00BFFC010230F647F06960870B1FD6EE5902ACA11909C5A61909C77818323032302D31302D355431333A34363A31332D30303A30301909C97818323032322D31302D355431333A34363A31332D30303A30301909C6021909CC5029C7BAFB81A2C6160D3357D22911F5101909D26E706C656467652E312E322E332E341909CF59023D30820239308201DEA0030201020214397374F3FA812A0D37103B68C18481C501BC7CFE300A06082A8648CE3D0403023073310B3009060355040613024E4C310B300906035504080C024E423110300E06035504070C0748656C6D6F6E6431133011060355040A0C0A76616E64657273746F6B31143012060355040B0C0B636F6E73756C74616E6379311A301806035504030C117265676973747261722E73746F6B2E6E6C301E170D3230303930393037343230335A170D3231303930393037343230335A3073310B3009060355040613024E4C310B300906035504080C024E423110300E06035504070C0748656C6D6F6E6431133011060355040A0C0A76616E64657273746F6B31143012060355040B0C0B636F6E73756C74616E6379311A301806035504030C117265676973747261722E73746F6B2E6E6C3059301306072A8648CE3D020106082A8648CE3D030107034200046A
24A9E24BE234D17AD47E760C94B5E1DC4EE115AD89112AD4A6A64BB1BF68F9177D70E9109CB48C9B0DC7DF2641199D0C2DBFF21ED584038AC83F4781BE138EA350304E301D0603551D0E0416041425CD9371B5A15F6D1EE8C37A5113BE0B8F132CC2301F0603551D2304183016801425CD9371B5A15F6D1EE8C37A5113BE0B8F132CC2300C0603551D13040530030101FF300A06082A8648CE3D0403020349003046022100A66D9E24F9DE08B7F0CF43C3C0EE57CCB660DEAE2E70CC61A1A2B33535025BBA022100BFFD746A99EBDA0177FC6C3795758AF4A09F998EBC4A906249F07AC96596DC7558473045022100FC28BE418E5F25152590E872B4BBDBE334CD31D1EBB0A806E7A172CAD5CFF604022056EE414DDAC438E7F51DDA9DDF6EC6E31A78CDDE6574717FE46DD3A7C60F5BB5'}} 
> 
> 1- see above comments on delta encoding and timestamps which shouldn't be equal. 
> 
> 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 [2] 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. 
> 
> {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'30820239308201DEA0030201020214397374F3FA812A0D37103B68C18481C501BC7CFE300A06082A8648CE3D0403023073310B3009060355040613024E4C310B300906035504080C024E423110300E06035504070C0748656C6D6F6E6431133011060355040A0C0A76616E64657273746F6B31143012060355040B0C0B636F6E73756C74616E6379311A301806035504030C117265676973747261722E73746F6B2E6E6C301E170D3230303930393037343230335A170D3231303930393037343230335A3073310B3009060355040613024E4C310B300906035504080C024E423110300E06035504070C0748656C6D6F6E6431133011060355040A0C0A76616E64657273746F6B31143012060355040B0C0B636F6E73756C74616E6379311A301806035504030C117265676973747261722E73746F6B2E6E6C3059301306072A8648CE3D020106082A8648CE3D030107034200046A24A9E24BE234D17AD47E760C94B5E1DC4EE115AD89112AD4A6A64BB1BF68F9177D70E9109CB48C9B0DC7DF2641199D0C2DBFF21ED584038AC83F4781BE138EA350304E301D0603551D0E0416041425CD9371B5A15F6D1EE8C37A5113BE0B8F132CC2301F0603551D2304183016801425CD9371B5A15F6D1EE8C37A5113BE0B8F132CC2300C0603551D13040530030101FF300A06082A8648CE3D040302
0349003046022100A66D9E24F9DE08B7F0CF43C3C0EE57CCB660DEAE2E70CC61A1A2B33535025BBA022100BFFD746A99EBDA0177FC6C3795758AF4A09F998EBC4A906249F07AC96596DC75', 2454: 0}} 
> 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. 
> 
> IoTconsultancy.nl  |  Email/Teams: [email-masked]    |   +31 6 2385 8339 
> 
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

Links:
------
[1]
https://tools.ietf.org/html/draft-ietf-core-yang-cbor-13#section-4.2.1
[2] https://github.com/anima-wg/constrained-voucher/issues/59

---

From: Peter van der Stok <[email-masked]>
Date: Tue, 22 Dec 2020 11:02:46 +0100

> Hi Esko,
> 
> thanks for your comments; they constitute a first step to interoperability.
> 
> 1.1) yes, the SID delta numbering is a stupid mistake and repaired.
> 
> 1.2) the former remarks about the certificates have been incorporated in the used certificates
> 
> 1.3) the expired and created times differ by 1 year. You must have overlooked. I will leave them in as an example, it does not hurt. However, I adjusted the formats by generating 0 padded two digit numbers
> 
> 2.2) The issuer contained the printable form. This is now back to the asn format as you expected.
> 
> 2.3) did nothing here. Just a chain of one certificate; which is totally feasable.
> 
> 3.2) repaired
> 
> 3.3) replaced by CBOR boolean FALSE
> 
> 3.4) a time span of 20 mins is now taken. Thanks anyway, I discovered another format mistake here.
> 
> Many thanks for the comments; my implementation has improved considerably.
> 
> Before the new year I will generate the new examples and some text for the empty ACK.
> 
> Greetings,
> 
> Peter
> 
> Hi Peter, 
> 

Links:
------
[1]