Change:
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-URL) 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 JSON 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 JSON) 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.
URL tries to fix the lack of specification for unsigned voucher requests.
Max 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 don'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.

Discussion:
The above process to locate the serial-number MUST be performed by the pledge when filling out the voucher-request.  Signed voucher- <del> 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. </del> <ins> requests are always passed up to the MASA. </ins> As explained in RequestVoucherFromMASA the Registrar MUST extract the <del> serial-number again itself from the pledge's TLS certificate.  It may </del> <ins> serial-number again itself from the pledge's TLS certificate.  It can </ins> consult the serial-number in the pledge-request if there are any possible confusion about the source of the serial-number (hwSerialNum vs serialNumber).

registrar's proximity. The "prior-signed-voucher-request" leaf is used in registrar voucher- <del> 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. </del> <ins> 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. </ins> Unless otherwise signaled (outside the voucher-request artifact), the signing structure is as defined for vouchers, see RFC8366.

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 <del> 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 </del> <ins> 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 </ins> RequestVoucherFromMASA. The following example illustrates a registrar voucher-request.

that it will not be able to reach the MASA during deployment.  See RequestVoucherFromMASA. <del> 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. </del> 3.4. Following is a YANG RFC7950 module formally extending the RFC8366

This is done with an HTTPS POST using the operation path value of "/.well-known/est/requestvoucher". <del> The pledge voucher-request Content-Types are: </del> <ins> The pledge voucher-request Content-Type is: </ins> The request is a "YANG-defined JSON document that has been signed using a CMS structure" as described in voucher-request using the

request.  The pledge SHOULD sign the request using the IDevIDextension credential. <del> 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. </del> <ins> Registrar impementations SHOULD anticipate future media types but of course will simply fail the request if those types are not yet known. </ins> The pledge SHOULD include an RFC7231 section 5.3.2 "Accept" header indicating the acceptable media type for the voucher response.  The

request-examples Example 1. The registrar validates the client identity as described in EST <del> RFC7030 section 3.3.2.  If the request is signed the registrar confirms that the associated 'proximity-registrar-cert' is correct. </del> <ins> RFC7030 section 3.3.2.  The registrar confirms that the 'proximity' assertion and associated 'proximity-registrar-cert' are correct. </ins> 5.3.

The idevid-issuer value from the pledge certificate is included to ensure a statistically unique identity. <del> 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. </del> <ins> 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. </ins> A nonceless registrar voucher-request MAY be submitted to the MASA. Doing so allows the registrar to request a voucher when the pledge is