Re: [Netconf] [6tisch] [Anima] Cross-WGs WGLC (second) on draft-ietf-anima-voucher-04 - Respond by Aug 08, 2017

[Kent Watsen <[e-mail]>]

Hi Peter,


>> Can a discussion section about "manufacturer additions" be
>> added. Pointing out the consequences for interoperability
>> when using "Augment" to add manufacturer specifics can be
>> helpful.
> 
> I'm confused, which section does this comment regard?

It refers to the document as a whole and especially section 7.
Usually, manufacturers want manufacturer-specific additions to 
documents.
They may consider to use Augment for that purpose.
My suggestion is to discuss ways to add manufacturer additions to the 
voucher and the consequences.
That may turn out to be a big NO-NO to manufacturer additions.
I think it would be worthwhile to point that out.

<KENT> Are you asking for the voucher to contain a node
called something like 'opaque' having YANG type 'anyData'?
A sanctioned place where the MASA can stash some extra
stuff not defined by this document?  Recall that some of
the motivation for this work being standardized is to
enable inspection by intermediates, and while the opaque
data could be presented to a human, it might be base64
data.  Any concerns bout that?


> Section 2; mention terminology from RFC7950
> 
> <KENT> What is this?  Are you asking for the draft to import terms
> from RFC7950?  Which terms

Reading RFC7950 is useful to understand section 4 for example; and 
needed when reading the voucher YANG text.
So not especially terms, but complete knowledge of RFC7950 is required.

<KENT> I added an introductory sentence to Section 6.3:

   Following is a YANG [RFC7950] module formally describing the
   voucher's JSON document structure.

Good?


> page 4, Voucher: add: that "acknowledges ownership of the pledge and"
> indicates...
> 
> <KENT> what does "acknowledges ownership of the pledge" mean?  how
> is it different than "indicates to a Pledge the cryptographic identity
> of the Domain it should trust"?

Now I am confused. I thought it was 2 ways. Pledge trusts domain, and 
domain partners trust pledge.

<KENT> The pledge trusts the MASA (which signs the voucher) and then
the pledge trusts the domain (whose cert is inside the voucher).
Perhaps you're conflating signing the voucher with acknowledging
ownership?


>> Add type in:
>> Ownership ID voucher "type" is named
>> Bearer Voucher "type" is named
> 
> <KENT> you only mention these two, but none of the voucher type
> descriptions have "type" in them, or maybe I'm missing something.

The name of the voucher is taken from the type I understand.
Only ownership ID voucher and Bearer voucher have text starting with 
"xxxx is named".
I see that I forgot: An audit voucher "type" is named .....

<KENT> Max, this is your section, can you reply to Peter on this?


>> section 7.1 last line: "there is a delay" is that delay between 
>> creation
>> and consumption and when is the delay unacceptable? the text is (on
>> purpose?) vague.
> 
> <KENT> The previous sentence says "...there may be a significant
> delay between when a voucher is created and when it is consumed."
> and the remainder of the line you're citing says "to ensure that
> the assertions made when the voucher was created are still valid
> when it is consumed."   This is vague?

To me yes. It sounds like a circular definition.
To paraphrase: When the voucher is consumed, the assertions are valid by 
definition.   I would expect a pointer to a delay definition and then an
assertion that states: when consumption time is larger than the creation time + delay, the voucher is invalid.

<KENT> I'm modified the paragraph slightly (s/delay/time delay/ + end
of last sentence):

   The lifetimes of vouchers may vary.  In some bootstrapping protocols,
   the vouchers may be created and consumed immediately whereas, in
   other bootstrapping solutions, there may be a significant time delay
   between when a voucher is created and when it is consumed.  In cases
   when there is a time delay, there is a need for the pledge to ensure
   that the assertions made when the voucher was created are still
   valid.

and the 3rd paragraph, to call out the 'expires-on' leaf:

   Addressing the short-comings of revocations, this document recommends
   instead the use of lightweight renewals of short-lived non-revocable
   vouchers.  That is, rather than issue a long-lived voucher, where the
   'expires-on' leaf is set to some distant date, the expectation is for
   the MASA to instead issue a short-lived voucher, where the 'expires-
   on' leaf is set to a relatively near date, along with a promise
   (reflected in the 'last-renewal-date' field) to re-issue the voucher
   again when needed.  Importantly, while issuing the initial voucher

Better?


Kent