Fix idnits and improve Section 3

[mkovatsc]

This update was originally triggered by the the idnits error about references in the abstract and warning about updates, which was found while working on the shepherd write-up.

Some distance to my last review let me see further room for improvement of Section 3, where the format for JWS signed voucher artifacts is defined using references to RFC7515 and JSON examples.

The shepherd write-up template also mentions formal language, which the draft is somewhat lacking. Hence, I saw the need to improve the definitions of the format.

Please check and provide feedback! Please note that there might be issues in the Markdown to RFC pipeline, as I only edited the .mkd without build step.

[mkovatsc]

I discovered a number of issues, including inconsistencies in the BRSKI Voucher terminology:

• First of all, we need UTF8() wrapping the "unsigned voucher data in JSON syntax" (we are lacking a proper term for this) because RFC7515 considers the JWS Payload to be octets:

  JWS Payload
    The sequence of octets to be secured -- a.k.a. the message.  The
    payload can contain an arbitrary sequence of octets.

• As already hinted, there is no good and clear term for the unsigned data going into the voucher.
• RFC8366 loosely uses "voucher artifact" for the unsigned JSON data and "voucher" for the CMS-signed ASN.1, but is not very clear or consistent:

  [...] an artifact signed, directly or indirectly, by the pledge's manufacturer. This artifact is known as the "voucher".

  The voucher artifact is a JSON [[RFC8259](https://www.rfc-editor.org/rfc/rfc8259)] document […]

  Voucher:  A signed statement from the MASA service

• draft-ietf-anima-constrained-voucher talks about "default serialization" and "voucher serialization" when referring to the JSON or CBOR document with the unsigned data.

  [RFC8366] voucher is by default serialized to JSON […]
  This document uses the new CBOR [RFC8949] voucher serialization […]

• I am not sure the Pledge Voucher Request (PVR) fits into this terminology -- I understand it is basically a Voucher, which has slightly different unsigned data and the signature is not done by the MASA, but the Pledge or Registrar.
• RFC8366 also says The voucher artifact is a JSON [RFC8259] document that conforms with a data model described by YANG [RFC7950], is encoded using the rules defined in [RFC8259]:
  • What does this last part with the rules mean, when it already states in the first part that it is a JSON [RFC8259] document?
  • Do we maybe rather need whatever defines the rules to map from YANG to JSON? RFC7951?

I would propose to establish consistent terminology in RFC8366bis and use it accordingly in the new drafts:

• Voucher: A signed statement from the MASA service that indicates to a pledge the cryptographic identity of the domain it should trust.
• JSON Voucher Data: An unsigned JSON document [RFC8259] that conforms with the data model described by the ietf-voucher YANG module [RFC7950] defined in [Section 5.3 of RFC8366bis] and is encoded using the rules defined in [RFC7951].
• CMS Voucher: CMS structure [RFC5652] signing the JSON Voucher Data.

jws-voucher:

• JWS Voucher: JWS structure [RFC7515] signing the JSON Voucher Data.

constrained-voucher:

• CBOR Voucher Data: An unsigned CBOR document [RFC8949] that conforms with the data model described by the ietf-voucher YANG module [RFC7950] defined in [Section 5.3 of RFC8366bis] and is encoded using the rules defined in [RFC9254].
• COSE Voucher: COSE structure [RFC9052] signing the CBOR Voucher Data.

I am not sure yet if we should append " Data" for the unsigned bits or insert "Signed" before Voucher in the signed bits or omit it, as the format already tells that.