minor fixes

draft-vesco-vcauthtls.md

@@ -78,7 +78,7 @@ This document defines a new certificate type and extension for the exchange of V
 
 --- middle
 
-# Introduction {#sec-intro}
+# Introduction {#sec-introduction}
 
 The Self-Sovereign Identity (SSI) is a decentralised identity model that gives a node control over the data it uses to generate and prove its identity. SSI model relies on three fundamental elements: a distributed ledger as the Root of Trust (RoT) for public keys, Decentralized IDentifier {{DID}}, and Verifiable Credential {{VC}}. An SSI aware node builds his identity starting from generating the identity key pair (_sk_, _pk_). Then the node stores _pk_ in the distributed ledger of choice for other nodes to authenticate it.
 A node's DID is a pointer to the distributed ledger where other nodes can retrieve its _pk_. A DID is a Uniform Resource Identifier (URI) in the form ``did:did-method-name:method-specific-id`` where ``method-name`` is the name of the {{DID}} Method used to interact with the distributed ledger and ``method-specific-id`` is the pointer to the {{DID}} Document that contains _pk_, stored in the distributed ledger.
@@ -92,13 +92,12 @@ SSI is emerging as an identity option for Internet of Thing and Edge nodes in co
 This document describes the extensions to TLS handshake protocol to support the use of VCs for authentication while preserving the interoperability with TLS endpoints that use X.509 certificates.
 The extensions enable server and mutual authentication using VC, X.509, Raw Public Key or a combination of two of them. The ability to perform hybrid authenticated handshakes supports the gradual deployment of SSI in existing systems. Moreover, the extension allows TLS endpoints to use different distributed ledger technologies to store their public keys and to authenticate the peer. The authentication process is successful if the TLS endpoints implement the DID Method to resolve the peer's DID.
 
-This document uses _italic formatting_ in the following sections to mark some paragraphs discussing items still under design: [](#serverhello-message) and [](#certificate-message).
+This document uses _italic formatting_ in the following sections to mark some paragraphs discussing items still under design: {{sec-server-hello-message}} and {{sec-certificate-message}}.
 
 # Conventions and Definitions
 
 {::boilerplate bcp14-tagged}
 
-
 # Extensions
 
 ## client_certificate_type and server_certificate_type extensions
@@ -211,15 +210,14 @@ DLT          Client                               Server           DLT
 
 To express support for ``VC`` certificate type, a client MUST include the extension of type ``client_certificate_type`` or ``server_certificate_type`` in the extended ``ClientHello`` message as described in {{Section 4.1.2 of RFC8446}}. If the client sends the ``server_certificate_type`` extension indicating ``VC``, it MUST also send the ``did_methods`` extension.
 
-## ServerHello message
+## ServerHello message {#sec-server-hello-message}
 
 When the server receives the ``ClientHello`` message containing the ``server_certificate_type`` extension and/or the ``client_certificate_type`` extension, the following scenarios are possible:
 
 - The server does not support the extensions, omits them in ``EncryptedExtensions`` and the handshake proceeds with X.509 certificate(s).
 - The server does not support any of the proposed certificate types and terminates the session with a fatal alert of type ``unsupported_certificate``.
 - Both client and server indicate support for the ``VC`` certificate type. The server selects ``VC`` certificate type, but the client did not send the ``did_methods`` extension in addition to the ``server_certificate_type`` extension. The server MUST terminate the session with a fatal alert of type ``missing_extension``.
 - Both client and server indicate support for the ``VC`` certificate type. The server selects ``VC`` certificate type, but the server's DID is not compatible with any of the DID Methods supported by the client and listed in the ``did_methods`` extension sent with the ``ClientHello`` message. _This document defines two possible server behaviours (a) the server terminates the session with a fatal alert of type ``unsupported_did_methods``, (b) the server sends a HelloRetryRequest (HRR) message with a new extension listing the DLTs in which it owns a DID_.
-
 _These design considerations apply: solution (a) requires defining a new fatal alert message type, and the client has no clues to perform a new successful TLS handshake; solution (b) requires defining a new HRR extension which could have privacy implications as it discloses the DLTs where the server owns its DIDs; on the other hand, this extension provides the client with clues to retry a successful new TLS handshake_.
 
 - Both client and server indicate support for the ``VC`` certificate type, the server MAY select the first (most preferred) certificate type from the client's list that is supported by both endpoints. It MAY include the ``client_certificate_type`` in the ``EncryptedExtensions`` message to request a certificate from the client. In case the server selects ``VC`` certificate type, it MUST also send the ``did_methods`` extension in the ``CertificateRequest`` message.
@@ -228,13 +226,13 @@ _These design considerations apply: solution (a) requires defining a new fatal a
 
 The server sends the ``CertificateRequest`` message to request client authentication. It MUST include the ``did_methods`` extension if it indicates ``VC`` in the ``client_certificate_type`` extension. If the ``ClientHello`` contains the ``did_methods`` extension, the server MUST send a list of DID Methods client and server have in common. If the client does not send the ``did_methods`` extension the server MUST select a list of DID Methods it supports. A client that processes the ``CertificateRequest`` message that does not own a DID compatible with the DID Methods selected by the server MUST send a ``Certificate`` message containing no certificates, i.e. with the ``certificate_list`` field having length 0.
 
-## Certificate message
+## Certificate message {#sec-certificate-message}
 
-When the selected certificate type is ``VC``, the ``certificate_list`` in the ``Certificate`` message MUST contain no more than one ``CertificateEntry`` with the content of the endpoint's Verifiable Credential. The content of the Verifiable Credential SHOULD be CBOR encoded. After decoding, the endpoint MUST follows the procedure in {{VC}} to verify the Verifiable Credential.
+When the selected certificate type is ``VC``, the ``certificate_list`` in the ``Certificate`` message MUST contain no more than one ``CertificateEntry`` with the content of the endpoint's Verifiable Credential. _This document intends to mandate CBOR encoding for the Verifiable Credential_. After decoding, the endpoint MUST follows the procedure in {{VC}} to verify the Verifiable Credential.
 
 ## CertificateVerify message
 
-As discussed in {{sec-intro}}, an Holder wraps its own Verifiable Credential into a Verifiable Presentation and signs it before presenting it to a Verifier for authentication purposes. During the TLS handshake, when the selected certificate type is ``VC``, the subsequent ``CertificateVerify`` message acts also as the Holder signature on the Verifiable Presentation. In fact, the signature is computed over the transcript hash that contains also the Verifiable Credential of the sender inside the ``Certificate`` message.
+As discussed in {{sec-introduction}}, an Holder wraps its own Verifiable Credential into a Verifiable Presentation and signs it before presenting it to a Verifier for authentication purposes. During the TLS handshake, when the selected certificate type is ``VC``, the subsequent ``CertificateVerify`` message acts also as the Holder signature on the Verifiable Presentation. In fact, the signature is computed over the transcript hash that contains also the Verifiable Credential of the sender inside the ``Certificate`` message.
 
 # TLS handshake Examples