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

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:

>> 

> 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'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'}} 
> 
> 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'D28444A101382EA1045820F8926F5BA385B7BCCF23592B97A73C1B00BFFC010230F647F06960870B1FD6EE5902ACA11909C5A61909C77818323032302D31302D355431333A34363A31332D30303A30301909C97818323032322D31302D355431333A34363A31332D30303A30301909C6021909CC5029C7BAFB81A2C6160D3357D22911F5101909D26E706C656467652E312E322E332E341909CF59023D30820239308201DEA0030201020214397374F3FA812A0D37103B68C18481C501BC7CFE300A06082A8648CE3D0403023073310B3009060355040613024E4C310B300906035504080C024E423110300E06035504070C0748656C6D6F6E6431133011060355040A0C0A76616E64657273746F6B31143012060355040B0C0B636F6E73756C74616E6379311A301806035504030C117265676973747261722E73746F6B2E6E6C301E170D3230303930393037343230335A170D3231303930393037343230335A3073310B3009060355040613024E4C310B300906035504080C024E423110300E06035504070C0748656C6D6F6E6431133011060355040A0C0A76616E64657273746F6B31143012060355040B0C0B636F6E73756C74616E6379311A301806035504030C117265676973747261722E73746F6B2E6E6C3059301306072A8648CE3D020106082A8648CE3D030107034200046A
24A9E24BE234D17AD47E760C94B5E1DC4EE115AD89112AD4A6A64BB1BF68F9177D70E9109CB48C9B0DC7DF2641199D0C2DBFF21ED584038AC83F4781BE138EA350304E301D0603551D0E0416041425CD9371B5A15F6D1EE8C37A5113BE0B8F132CC2301F0603551D2304183016801425CD9371B5A15F6D1EE8C37A5113BE0B8F132CC2300C0603551D13040530030101FF300A06082A8648CE3D0403020349003046022100A66D9E24F9DE08B7F0CF43C3C0EE57CCB660DEAE2E70CC61A1A2B33535025BBA022100BFFD746A99EBDA0177FC6C3795758AF4A09F998EBC4A906249F07AC96596DC7558473045022100FC28BE418E5F25152590E872B4BBDBE334CD31D1EBB0A806E7A172CAD5CFF604022056EE414DDAC438E7F51DDA9DDF6EC6E31A78CDDE6574717FE46DD3A7C60F5BB5'}} 
> 
> 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 [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. 
> 
> *** 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'30820239308201DEA0030201020214397374F3FA812A0D37103B68C18481C501BC7CFE300A06082A8648CE3D0403023073310B3009060355040613024E4C310B300906035504080C024E423110300E06035504070C0748656C6D6F6E6431133011060355040A0C0A76616E64657273746F6B31143012060355040B0C0B636F6E73756C74616E6379311A301806035504030C117265676973747261722E73746F6B2E6E6C301E170D3230303930393037343230335A170D3231303930393037343230335A3073310B3009060355040613024E4C310B300906035504080C024E423110300E06035504070C0748656C6D6F6E6431133011060355040A0C0A76616E64657273746F6B31143012060355040B0C0B636F6E73756C74616E6379311A301806035504030C117265676973747261722E73746F6B2E6E6C3059301306072A8648CE3D020106082A8648CE3D030107034200046A24A9E24BE234D17AD47E760C94B5E1DC4EE115AD89112AD4A6A64BB1BF68F9177D70E9109CB48C9B0DC7DF2641199D0C2DBFF21ED584038AC83F4781BE138EA350304E301D0603551D0E0416041425CD9371B5A15F6D1EE8C37A5113BE0B8F132CC2301F0603551D2304183016801425CD9371B5A15F6D1EE8C37A5113BE0B8F132CC2300C0603551D13040530030101FF300A06082A8648CE3D040302
0349003046022100A66D9E24F9DE08B7F0CF43C3C0EE57CCB660DEAE2E70CC61A1A2B33535025BBA022100BFFD746A99EBDA0177FC6C3795758AF4A09F998EBC4A906249F07AC96596DC75', 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: esko.dijk@iotconsultancy.nl    |   +31 6 2385 8339 
> 
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> 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