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 <[email protected]>, Sandelman Software Works > -= IPv6 IoT consulting =- > > > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
