[Anima] voucher draft last-call fixes (Re: minor clarifications to voucher)

[Toerless Eckert <[e-mail]>]

Here is the rfcdiff between the -03 (last call) version of the voucher document and
the version where the authors have integrated their last call fixes. This includes
what Michaels last mail was referring to:

https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/voucher/master/draft-ietf-anima-voucher.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-voucher-03.txt

- Textual fixes without semantic changes (eg: writing out abbreviations on first use)

- The tree diagram notation used in the doc is now explained in the document itself.
  In -03 we referred to an external document but that doc is still evolving and would 
  therefore be an unstable reference.

- Explained that vouchers can be sent by someone else than MASA and received by someone else
  than pledge. This clarifies the intended additional use of voucher in BRSKI beside that "normal" case.

- Inlined grouping in the yang model for the voucher to simplify the definition/format.

- Updated requirements langauge to include (RFC8174) (only capital MUST/SHOULD are standards language..).

Latest version: https://raw.githubusercontent.com/anima-wg/voucher/master/draft-ietf-anima-voucher.txt

Cheers
    Toerless (as one of the authors).




On Tue, Jun 20, 2017 at 10:14:58AM -0400, Michael Richardson wrote:
> 
> Based upon discussion last week about synchronizing the voucher document with
> the BRSKI MASA protocol the following clarification was made to the voucher
> document as part of the WGLC:
> 
> 
> -          signed using a PKCS#7 structure.  The voucher artifact is generated by
> -          the pledge's manufacture or delegate (i.e. the MASA).</t>
> +          signed using a PKCS#7 structure.  The voucher artifact is normally generated by
> +          the pledge's manufacture or delegate (i.e. the Manufacturer Authorized Signing
> +          Authority). A voucher artifact could be signed by a non-MASA and be compliant
> +          to the specified artifact format described in this document. The appropriate
> +          use and trust of such vouchers is out-of-scope of this document.
> +          </t>
> 
>             <t>This document only defines the voucher artifact, leaving it to other
>             documents to describe specialized protocols for accessing it.</t>
> @@ -75,7 +79,8 @@
> 
>           <t>This document defines a strategy to securely assign a pledge to an owner,
>           using an artifact signed, directly or indirectly, by the pledge's manufacturer
> -        or delegate (i.e. the MASA).  This artifact is known as the voucher.</t>
> +        or delegate, i.e. the Manufacturer Authorized Signing
> +        Authority (MASA).  This artifact is known as the voucher.</t>
> 
>           <t>The voucher artifact is a JSON document, conforming to a data model
>           described by YANG <xref target="RFC7950"/>,  that has been signed using
> @@ -265,7 +270,7 @@ NOTE: All voucher types include a 'Pledge ID serial number'
> 
>         <section title="Voucher" anchor="voucher">
> 
> -        <t>The voucher's purpose is to securely assign a pledge to an owner.
> +        <t>The voucher's primary purpose is to securely assign a pledge to an owner.
>           The voucher informs the pledge which entity it should consider to be
>          its owner.</t>
> 
> 
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
>