Re: [Yot] questions concerning sid value assignments

[Michel Veillette <[e-mail]>]

==========
About "The correct encoding is only in conjunction with YANG CBOR draft."

Yes, this encoding is based on https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/ version 6.

========== In the previous email

About "What do you mean? a cwt-voucher or a voucher; OR how to derive cwt-voucher from voucher; OR having a mailbox of vouchers?"



I mean that the use cases for this information in the datastore need to be clearly defined.

What information need to be retrieved and why.



In the introduction of 'draft-ietf-anima-voucher', we can read:

" The lifetimes of vouchers may vary.  In some bootstrapping protocols

   the vouchers may include a nonce restricting them to a single use,

   whereas in others the vouchers may have an indicated lifetime."



This imply that a device may have multiple vouchers at the same time.

This can be implemented as a list or as multiple containers (e.g. previous-voucher, current-voucher, next-voucher)



About voucher vs. cwt-voucher, I assume that both need to be supported, this can be accomplished by using an anydata.

For example:



module ietf-voucher {

  ...



  anydata  current-voucher {

    description "voucher-artifact or any YANG template based on this artifact."

  }
  ...

}


========== In the previous email

About "should be included in an optional feature"



See https://tools.ietf.org/html/rfc7950#section-7.20.1

This mechanism is used to make a portion of the schema as conditional.

A CoMI client can discover which features are implemented by a server by reading its YANG library (e.g. https://datatracker.ietf.org/doc/draft-veillette-core-yang-library/)



Regards,

Michel

-----Original Message-----
From: peter van der Stok [mailto:[e-mail]]
Sent: Wednesday, February 21, 2018 3:30 AM
To: Michel Veillette <[e-mail]>
Cc: [e-mail]; Michael Richardson <[e-mail]>; [e-mail]; Panos Kampanakis (pkampana) <[e-mail]>; Kent Watsen <[e-mail]>
Subject: Re: questions concerning sid value assignments

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?