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 _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
