Re: [Yot] questions concerning sid value assignments

[Michel Veillette <[e-mail]>]

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.)

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?