Re: [Yot] questions concerning sid value assignments

[peter van der Stok <[e-mail]>]

Hi Michel,

see below

Michel Veillette schreef op 2018-02-20 16:47:
> Hi Peter, Hi Michael
> 
> In my previous email, I forgot to highlight the errors for the
> cwt-voucher encoding.
> 
> When the augment is on the 'voucher-artifac' template, the 'voucher'
> container is not redefined, the original definition, path and SID
> apply.
> Only the "pinned-domain-subject-public-key-info" leaf is part of the
> augment and get specific SID assigned to it.
> 
> The encoding should be:
> {
>   1001001: {
>     +2 : "2016-10-07T19:31:42Z",  / SID = 1001003, created-on /
>     +4 : "2016-10-21T19:31:42Z",  / SID = 1001005, expires-on /
>     +1 : "verified",              / SID = 1001002, assertion /
>     +10 : "JADA123456789",        / SID = 1001011, serial-number /
>     +5 : h'01020D0F',             / SID = 1001006, idevid-issuer /
>     +8 : h'01020D0F',             / SID = 1001009, pinned-domain-cert /
>     +3 : true,                    / SID = 1001004,
> domain-cert-revocation-checks /
>     +6 : "2017-10-07T19:31:42Z",  / SID = 1001007, last-renewal-date /
>     +30 : h'01020D0F'             / SID = 1001031,
> pinned-domain-subject-public-key-info /
>   }
> }
> 
> This corrected encoding probably reinforce your current conclusion
> (This is an argument to not re-using the values.)

(RIGHT)
To be sure:
The correct encoding (many thanks for doing this) is only in conjunction 
with YANG CBOR draft.
If you do not expect inter-operability problems with the voucher, an 
alternative encoding with the same resultant values is OK. (for example 
not using the h'number' encoding but just a bsd64 encoding also 
supported by CBOR)

Cheerio,

Peter
> 
> Regards,
> Michel
> 
> -----Original Message-----
> From: peter van der Stok [mailto:[e-mail]]
> Sent: Tuesday, February 20, 2018 3:40 AM
> To: Michael Richardson <[e-mail]>
> Cc: [e-mail]; [e-mail]; Michel Veillette
> <[e-mail]>; Panos Kampanakis (pkampana)
> <[e-mail]>; Kent Watsen <[e-mail]>
> Subject: Re: questions concerning sid value assignments
> 
> 
> Michael Richardson schreef op 2018-02-19 19:23:
>> peter van der Stok <[e-mail]> wrote:
>>     > I created an example for myself by heart. Can you see if my
>> memory is still
>>     > correct?
>> 
>>     > I assume a server with one voucher module and one cwt-voucher
>> module;
>>     > The augment with grouping is used for SID allocation.
>>     > The diagnostic notation is used for CBOR.
>> 
>> Cool...
>> 
>>     > {
>>     > 1001000: {
>>     > +3 : "2016-10-07T19:31:42Z",
>> 
>>     > A returned cwt-voucher may look like:
>> 
>>     > {
>>     > 1001030: {
>>     > -27 : "2016-10-07T19:31:42Z",
>> 
>> It took me a moment to figure out that 1001000+3 == 1001030-27.
>> That's exactly what I would think should happen if we have SIDs
>> allocate for the underlying ietf-voucher object which we then repeat.
>> 
>> There is a concern if the gap between 1001000 and 1001030 was larger!
>> -27 is fortunately still a 1-byte CBOR integer.  Otherwise, we get
>> into
>> 2
>> byte CBOR integers and even three byte ones.  Since the delta is
>> relative to the enclosing value, not the previous value, we can't even
>> amortize the gap.
>> 
>> This is an argument to not re-using the values.
> 
> Well, that concludes the exercise for me.
> Now we can make the examples and fix the cwt-voucher SID allocation
> 
>> 
>>     > Both can be identified nicely though the presence of 1001030 or
>> 1001000
>> 
>>     > However, when using comi to return the value of for example:
>>     > ietf-voucher/created-on, or
>>     > iet-cwt-voucher/created-on
>> 
>>     > The request for both is identical:
>> 
>>     > GET //example-server.com/c/1001003
>> 
>>     > The server does not know which one to return.
>>     > Did I miss something?