Draft: dtbootstrap-anima-keyinfra

Commentary: This should be a complete set of diffs for removing unsigned pledge voucher - requests from the text . 
 For issue 
 The text " This artifact may be optionally signed " is buried in the yang module ( ietf - voucher- ) and needs to be removed . 
 When a pledge decides to use an unsigned voucher request , the Registrar will place it into prior - signed - voucher request on the BRSKI - MASA arc . It will be  embedded in . When a pledge decides to use a signed voucher request , the Registrar will place the base64 encode of the pledge_request in as a string . The MASA can tell the difference between the two because the signed thing ( whether CBOR , COSE , CMS signed CBOR , or CMS signed  ) will always be base64 encoded . We need to explain this somewhere . 
 section 5.5 indicates that : prior - signed - voucher - request : If a signed pledge voucher - request was received then it SHOULD be included in the registrar voucher- request . ( NOTE : what is included is the complete pledge voucher- request , inclusive of the ' assertion ' , ' proximity - registrar - cert ' , etc wrapped by the pledge 's original signature ) . If a signed voucher - request was not recieved from the pledge then this leaf is omitted from the registrar voucher request . This indicates that the MASA never needs to " tell the difference " only the registrar . ( The pledge to registrar signaling is via request media type as detailed in s5.2 ) . I did notice this when reading : s3.3 . these references to voucher in the leaf description should be to voucher request ? " If it is necessary to change a voucher , or re - sign and forward a voucher that was previously provided along a protocol path , then the previously signed voucher SHOULD be included in this field . " etc . subsequent paragraphs . 
 tries to fix the lack of specification for unsigned voucher requests . 
  to produce a draft branch that removes unsigned voucher request so we can examine the ramifications of this . 
 v20 of BRSKI removed unsigned voucher requests . What were the reasons for removing ? I do n't see a mention of this in the anima WG email . If removed as a final decision , then this issue can be closed also . 
 Hi , yes , we could close this now . I did post several times to the list in Feb and March , and it was raised during the WG meeting itself , asking for feedback . 
 Ok , I now see the email list discussion also in December 2018 and based on this the unsigned voucher was removed .
The above process to locate the serial-number MUST be performed by
the pledge when filling out the voucher-request.  Signed voucher-
requests are always passed up to the MASA, and the connection between
the serial-number in the voucher-request and the serial number in the
IDevID certificate.
As explained in RequestVoucherFromMASA the Registrar MUST extract the
serial-number again itself from the pledge's TLS certificate.  It may
consult the serial-number in the pledge-request if there are any
possible confusion about the source of the serial-number (hwSerialNum
vs serialNumber).
The above process to locate the serial-number MUST be performed by
the pledge when filling out the voucher-request.  Signed voucher-
requests are always passed up to the MASA.
As explained in RequestVoucherFromMASA the Registrar MUST extract the
serial-number again itself from the pledge's TLS certificate.  It can
consult the serial-number in the pledge-request if there are any
possible confusion about the source of the serial-number (hwSerialNum
vs serialNumber).
The "prior-signed-voucher-request" leaf is used in registrar voucher-
requests.  If present, it is the encoded (signed form) of the pledge
voucher-request.  This provides a method for the registrar to forward
the pledge's signed request to the MASA.  This completes transmission
of the signed "proximity-registrar-cert" leaf.
The "prior-signed-voucher-request" leaf is used in registrar voucher-
requests.  If present, it is the signed pledge voucher-request.  This
provides a method for the registrar to forward the pledge's signed
request to the MASA.  This completes transmission of the signed
"proximity-registrar-cert" leaf.
The following example illustrates a registrar voucher-request.
The 'prior-signed-voucher-request' leaf is populated with the
pledge's voucher-request (such as the prior example).  The
pledge's voucher-request, if a signed artifact with a CMS format
signature is a binary object.  In the JSON encoding used here it
must be base64 encoded.  The nonce, created-on and assertion is
carried forward.  The serial-number is extracted from the pledge's
Client Certificate from the TLS connection.  See
RequestVoucherFromMASA.
The following example illustrates a registrar voucher-request.
The 'prior-signed-voucher-request' leaf is populated with the
pledge's voucher-request (such as the prior example).  The
pledge's voucher-request is a binary object.  In the JSON encoding
used here it must be base64 encoded.  The nonce, created-on and
assertion is carried forward.  The serial-number is extracted from
the pledge's Client Certificate from the TLS connection.  See
RequestVoucherFromMASA.
The following example illustrates a registrar voucher-request.
The 'prior-signed-voucher-request' leaf is not populated with the
pledge voucher-request because the pledge did not sign its own
request.  This form might be used when more constrained pledges
are being deployed.  The nonce is populated from the pledge's
request.  See RequestVoucherFromMASA.
The request is the "YANG-defined JSON document" as described in
voucher-request with the exception that it is not within a CMS
structure.  It is protected only by the TLS client authentication.
This reduces the cryptographic requirements on the pledge.
For simplicity the term 'voucher-request' is used to refer to any of
these media types.  Registrar impementations SHOULD anticipate future
media types but of course will simply fail the request if those types
are not yet known.
Registrar impementations SHOULD anticipate future media types but of
course will simply fail the request if those types are not yet known.
The registrar validates the client identity as described in EST
RFC7030 section 3.3.2.  If the request is signed the registrar
confirms that the associated 'proximity-registrar-cert' is correct.
The registrar validates the client identity as described in EST
RFC7030 section 3.3.2.  The registrar confirms that the 'proximity'
assertion and associated 'proximity-registrar-cert' are correct.
If a signed pledge voucher-request was received then it SHOULD be
included in the registrar voucher-request.  (NOTE: what is
included is the complete pledge voucher-request, inclusive of the
'assertion', 'proximity-registrar-cert', etc wrapped by the
pledge's original signature).  If a signed voucher-request was not
recieved from the pledge then this leaf is omitted from the
registrar voucher request.
The signed pledge voucher-request SHOULD be included in the
registrar voucher-request.  (NOTE: what is included is the
complete pledge voucher-request, inclusive of the 'assertion',
'proximity-registrar-cert', etc wrapped by the pledge's original
signature).  If a signed voucher-request was not recieved from the
pledge then this leaf is omitted from the registrar voucher
request.