update requirement files to include whitespace

.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-2.1.toml

@@ -1,23 +1,23 @@
 target = "https://www.rfc-editor.org/rfc/rfc4492#section-2.1"
 
-# 2.1.  ECDH_ECDSA
+# ECDH_ECDSA
 #
-# In ECDH_ECDSA, the server's certificate MUST contain an ECDH-capable
-# public key and be signed with ECDSA.
+#    In ECDH_ECDSA, the server's certificate MUST contain an ECDH-capable
+#    public key and be signed with ECDSA.
 # 
-# A ServerKeyExchange MUST NOT be sent (the server's certificate
-# contains all the necessary keying information required by the client
-# to arrive at the premaster secret).
+#    A ServerKeyExchange MUST NOT be sent (the server's certificate
+#    contains all the necessary keying information required by the client
+#    to arrive at the premaster secret).
 # 
-# The client generates an ECDH key pair on the same curve as the
-# server's long-term public key and sends its public key in the
-# ClientKeyExchange message (except when using client authentication
-# algorithm ECDSA_fixed_ECDH or RSA_fixed_ECDH, in which case the
-# modifications from Section 3.2 or Section 3.3 apply).
+#    The client generates an ECDH key pair on the same curve as the
+#    server's long-term public key and sends its public key in the
+#    ClientKeyExchange message (except when using client authentication
+#    algorithm ECDSA_fixed_ECDH or RSA_fixed_ECDH, in which case the
+#    modifications from Section 3.2 or Section 3.3 apply).
 # 
-# Both client and server perform an ECDH operation and use the
-# resultant shared secret as the premaster secret.  All ECDH
-# calculations are performed as specified in Section 5.10.
+#    Both client and server perform an ECDH operation and use the
+#    resultant shared secret as the premaster secret.  All ECDH
+#    calculations are performed as specified in Section 5.10.
 
 [[spec]]
 level = "MUST"

.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-2.2.toml

@@ -1,21 +1,21 @@
 target = "https://www.rfc-editor.org/rfc/rfc4492#section-2.2"
 
-# 2.2.  ECDHE_ECDSA
+# ECDHE_ECDSA
 #
-# In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA-
-# capable public key and be signed with ECDSA.
+#    In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA-
+#    capable public key and be signed with ECDSA.
 # 
-# The server sends its ephemeral ECDH public key and a specification of
-# the corresponding curve in the ServerKeyExchange message.  These
-# parameters MUST be signed with ECDSA using the private key
-# corresponding to the public key in the server's Certificate.
+#    The server sends its ephemeral ECDH public key and a specification of
+#    the corresponding curve in the ServerKeyExchange message.  These
+#    parameters MUST be signed with ECDSA using the private key
+#    corresponding to the public key in the server's Certificate.
 # 
-# The client generates an ECDH key pair on the same curve as the
-# server's ephemeral ECDH key and sends its public key in the
-# ClientKeyExchange message.
+#    The client generates an ECDH key pair on the same curve as the
+#    server's ephemeral ECDH key and sends its public key in the
+#    ClientKeyExchange message.
 # 
-# Both client and server perform an ECDH operation (Section 5.10) and
-# use the resultant shared secret as the premaster secret.
+#    Both client and server perform an ECDH operation (Section 5.10) and
+#    use the resultant shared secret as the premaster secret.
 
 [[spec]]
 level = "MUST"

.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-2.3.toml

@@ -1,9 +1,9 @@
 target = "https://www.rfc-editor.org/rfc/rfc4492#section-2.3"
 
-# 2.3.  ECDH_RSA
+# ECDH_RSA
 #
-# This key exchange algorithm is the same as ECDH_ECDSA except that the
-# server's certificate MUST be signed with RSA rather than ECDSA.
+#    This key exchange algorithm is the same as ECDH_ECDSA except that the
+#    server's certificate MUST be signed with RSA rather than ECDSA.
 
 [[spec]]
 level = "MUST"

.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-2.4.toml

@@ -1,12 +1,12 @@
 target = "https://www.rfc-editor.org/rfc/rfc4492#section-2.4"
 
-# 2.4.  ECDHE_RSA
+# ECDHE_RSA
 #
-# This key exchange algorithm is the same as ECDHE_ECDSA except that
-# the server's certificate MUST contain an RSA public key authorized
-# for signing, and that the signature in the ServerKeyExchange message
-# must be computed with the corresponding RSA private key.  The server
-# certificate MUST be signed with RSA.
+#    This key exchange algorithm is the same as ECDHE_ECDSA except that
+#    the server's certificate MUST contain an RSA public key authorized
+#    for signing, and that the signature in the ServerKeyExchange message
+#    must be computed with the corresponding RSA private key.  The server
+#    certificate MUST be signed with RSA.
 
 [[spec]]
 level = "MUST"

.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-2.5.toml

@@ -1,36 +1,36 @@
 target = "https://www.rfc-editor.org/rfc/rfc4492#section-2.5"
 
-# 2.5.  ECDH_anon
+# ECDH_anon
 #
-# In ECDH_anon, the server's Certificate, the CertificateRequest, the
-# client's Certificate, and the CertificateVerify messages MUST NOT be
-# sent.
+#    In ECDH_anon, the server's Certificate, the CertificateRequest, the
+#    client's Certificate, and the CertificateVerify messages MUST NOT be
+#    sent.
 # 
-# The server MUST send an ephemeral ECDH public key and a specification
-# of the corresponding curve in the ServerKeyExchange message.  These
-# parameters MUST NOT be signed.
+#    The server MUST send an ephemeral ECDH public key and a specification
+#    of the corresponding curve in the ServerKeyExchange message.  These
+#    parameters MUST NOT be signed.
 # 
-# The client generates an ECDH key pair on the same curve as the
-# server's ephemeral ECDH key and sends its public key in the
-# ClientKeyExchange message.
+#    The client generates an ECDH key pair on the same curve as the
+#    server's ephemeral ECDH key and sends its public key in the
+#    ClientKeyExchange message.
 # 
-# Both client and server perform an ECDH operation and use the
-# resultant shared secret as the premaster secret.  All ECDH
-# calculations are performed as specified in Section 5.10.
+#    Both client and server perform an ECDH operation and use the
+#    resultant shared secret as the premaster secret.  All ECDH
+#    calculations are performed as specified in Section 5.10.
 # 
-# Note that while the ECDH_ECDSA, ECDHE_ECDSA, ECDH_RSA, and ECDHE_RSA
-# key exchange algorithms require the server's certificate to be signed
-# with a particular signature scheme, this specification (following the
-# similar cases of DH_DSS, DHE_DSS, DH_RSA, and DHE_RSA in [2] and [3])
-# does not impose restrictions on signature schemes used elsewhere in
-# the certificate chain.  (Often such restrictions will be useful, and
-# it is expected that this will be taken into account in certification
-# authorities' signing practices.  However, such restrictions are not
-# strictly required in general: Even if it is beyond the capabilities
-# of a client to completely validate a given chain, the client may be
-# able to validate the server's certificate by relying on a trusted
-# certification authority whose certificate appears as one of the
-# intermediate certificates in the chain.)
+#    Note that while the ECDH_ECDSA, ECDHE_ECDSA, ECDH_RSA, and ECDHE_RSA
+#    key exchange algorithms require the server's certificate to be signed
+#    with a particular signature scheme, this specification (following the
+#    similar cases of DH_DSS, DHE_DSS, DH_RSA, and DHE_RSA in [2] and [3])
+#    does not impose restrictions on signature schemes used elsewhere in
+#    the certificate chain.  (Often such restrictions will be useful, and
+#    it is expected that this will be taken into account in certification
+#    authorities' signing practices.  However, such restrictions are not
+#    strictly required in general: Even if it is beyond the capabilities
+#    of a client to completely validate a given chain, the client may be
+#    able to validate the server's certificate by relying on a trusted
+#    certification authority whose certificate appears as one of the
+#    intermediate certificates in the chain.)
 
 [[spec]]
 level = "MUST"

.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-2.toml

@@ -1,101 +1,101 @@
 target = "https://www.rfc-editor.org/rfc/rfc4492#section-2"
 
-# 2.  Key Exchange Algorithms
+# Key Exchange Algorithms
 #
-# This document introduces five new ECC-based key exchange algorithms
-# for TLS.  All of them use ECDH to compute the TLS premaster secret,
-# and they differ only in the lifetime of ECDH keys (long-term or
-# ephemeral) and the mechanism (if any) used to authenticate them.  The
-# derivation of the TLS master secret from the premaster secret and the
-# subsequent generation of bulk encryption/MAC keys and initialization
-# vectors is independent of the key exchange algorithm and not impacted
-# by the introduction of ECC.
-# 
-# The table below summarizes the new key exchange algorithms, which
-# mimic DH_DSS, DHE_DSS, DH_RSA, DHE_RSA, and DH_anon (see [2] and
-# [3]), respectively.
-# 
-#        Key
-#        Exchange
-#        Algorithm           Description
-#        ---------           -----------
-# 
-#        ECDH_ECDSA          Fixed ECDH with ECDSA-signed certificates.
-# 
-#        ECDHE_ECDSA         Ephemeral ECDH with ECDSA signatures.
-# 
-#        ECDH_RSA            Fixed ECDH with RSA-signed certificates.
-# 
-#        ECDHE_RSA           Ephemeral ECDH with RSA signatures.
-# 
-#        ECDH_anon           Anonymous ECDH, no signatures.
-# 
-#                   Table 2: ECC Key Exchange Algorithms
-# 
-# The ECDHE_ECDSA and ECDHE_RSA key exchange mechanisms provide forward
-# secrecy.  With ECDHE_RSA, a server can reuse its existing RSA
-# certificate and easily comply with a constrained client's elliptic
-# curve preferences (see Section 4).  However, the computational cost
-# 
-# incurred by a server is higher for ECDHE_RSA than for the traditional
-# RSA key exchange, which does not provide forward secrecy.
-# 
-# The ECDH_RSA mechanism requires a server to acquire an ECC
-# certificate, but the certificate issuer can still use an existing RSA
-# key for signing.  This eliminates the need to update the keys of
-# trusted certification authorities accepted by TLS clients.  The
-# ECDH_ECDSA mechanism requires ECC keys for the server as well as the
-# certification authority and is best suited for constrained devices
-# unable to support RSA.
-# 
-# The anonymous key exchange algorithm does not provide authentication
-# of the server or the client.  Like other anonymous TLS key exchanges,
-# it is subject to man-in-the-middle attacks.  Implementations of this
-# algorithm SHOULD provide authentication by other means.
-# 
-# Note that there is no structural difference between ECDH and ECDSA
-# keys.  A certificate issuer may use X.509 v3 keyUsage and
-# extendedKeyUsage extensions to restrict the use of an ECC public key
-# to certain computations [15].  This document refers to an ECC key as
-# ECDH-capable if its use in ECDH is permitted.  ECDSA-capable is
-# defined similarly.
-# 
-#            Client                                        Server
-#            ------                                        ------
-# 
-#            ClientHello          -------->
-#                                                     ServerHello
-#                                                    Certificate*
-#                                              ServerKeyExchange*
-#                                            CertificateRequest*+
-#                                 <--------       ServerHelloDone
-#            Certificate*+
-#            ClientKeyExchange
-#            CertificateVerify*+
-#            [ChangeCipherSpec]
-#            Finished             -------->
-#                                              [ChangeCipherSpec]
-#                                 <--------              Finished
-# 
-#            Application Data     <------->      Application Data
-# 
-#                 * message is not sent under some conditions
-#                 + message is not sent unless client authentication
-#                   is desired
-# 
-#               Figure 1: Message flow in a full TLS handshake
-# 
-# Figure 1 shows all messages involved in the TLS key establishment
-# protocol (aka full handshake).  The addition of ECC has direct impact
-# only on the ClientHello, the ServerHello, the server's Certificate
-# message, the ServerKeyExchange, the ClientKeyExchange, the
-# CertificateRequest, the client's Certificate message, and the
-# CertificateVerify.  Next, we describe each ECC key exchange algorithm
-# in greater detail in terms of the content and processing of these
-# messages.  For ease of exposition, we defer discussion of client
-# authentication and associated messages (identified with a + in
-# Figure 1) until Section 3 and of the optional ECC-specific extensions
-# (which impact the Hello messages) until Section 4.
+#    This document introduces five new ECC-based key exchange algorithms
+#    for TLS.  All of them use ECDH to compute the TLS premaster secret,
+#    and they differ only in the lifetime of ECDH keys (long-term or
+#    ephemeral) and the mechanism (if any) used to authenticate them.  The
+#    derivation of the TLS master secret from the premaster secret and the
+#    subsequent generation of bulk encryption/MAC keys and initialization
+#    vectors is independent of the key exchange algorithm and not impacted
+#    by the introduction of ECC.
+# 
+#    The table below summarizes the new key exchange algorithms, which
+#    mimic DH_DSS, DHE_DSS, DH_RSA, DHE_RSA, and DH_anon (see [2] and
+#    [3]), respectively.
+# 
+#           Key
+#           Exchange
+#           Algorithm           Description
+#           ---------           -----------
+# 
+#           ECDH_ECDSA          Fixed ECDH with ECDSA-signed certificates.
+# 
+#           ECDHE_ECDSA         Ephemeral ECDH with ECDSA signatures.
+# 
+#           ECDH_RSA            Fixed ECDH with RSA-signed certificates.
+# 
+#           ECDHE_RSA           Ephemeral ECDH with RSA signatures.
+# 
+#           ECDH_anon           Anonymous ECDH, no signatures.
+# 
+#                      Table 2: ECC Key Exchange Algorithms
+# 
+#    The ECDHE_ECDSA and ECDHE_RSA key exchange mechanisms provide forward
+#    secrecy.  With ECDHE_RSA, a server can reuse its existing RSA
+#    certificate and easily comply with a constrained client's elliptic
+#    curve preferences (see Section 4).  However, the computational cost
+# 
+#    incurred by a server is higher for ECDHE_RSA than for the traditional
+#    RSA key exchange, which does not provide forward secrecy.
+# 
+#    The ECDH_RSA mechanism requires a server to acquire an ECC
+#    certificate, but the certificate issuer can still use an existing RSA
+#    key for signing.  This eliminates the need to update the keys of
+#    trusted certification authorities accepted by TLS clients.  The
+#    ECDH_ECDSA mechanism requires ECC keys for the server as well as the
+#    certification authority and is best suited for constrained devices
+#    unable to support RSA.
+# 
+#    The anonymous key exchange algorithm does not provide authentication
+#    of the server or the client.  Like other anonymous TLS key exchanges,
+#    it is subject to man-in-the-middle attacks.  Implementations of this
+#    algorithm SHOULD provide authentication by other means.
+# 
+#    Note that there is no structural difference between ECDH and ECDSA
+#    keys.  A certificate issuer may use X.509 v3 keyUsage and
+#    extendedKeyUsage extensions to restrict the use of an ECC public key
+#    to certain computations [15].  This document refers to an ECC key as
+#    ECDH-capable if its use in ECDH is permitted.  ECDSA-capable is
+#    defined similarly.
+# 
+#               Client                                        Server
+#               ------                                        ------
+# 
+#               ClientHello          -------->
+#                                                        ServerHello
+#                                                       Certificate*
+#                                                 ServerKeyExchange*
+#                                               CertificateRequest*+
+#                                    <--------       ServerHelloDone
+#               Certificate*+
+#               ClientKeyExchange
+#               CertificateVerify*+
+#               [ChangeCipherSpec]
+#               Finished             -------->
+#                                                 [ChangeCipherSpec]
+#                                    <--------              Finished
+# 
+#               Application Data     <------->      Application Data
+# 
+#                    * message is not sent under some conditions
+#                    + message is not sent unless client authentication
+#                      is desired
+# 
+#                  Figure 1: Message flow in a full TLS handshake
+# 
+#    Figure 1 shows all messages involved in the TLS key establishment
+#    protocol (aka full handshake).  The addition of ECC has direct impact
+#    only on the ClientHello, the ServerHello, the server's Certificate
+#    message, the ServerKeyExchange, the ClientKeyExchange, the
+#    CertificateRequest, the client's Certificate message, and the
+#    CertificateVerify.  Next, we describe each ECC key exchange algorithm
+#    in greater detail in terms of the content and processing of these
+#    messages.  For ease of exposition, we defer discussion of client
+#    authentication and associated messages (identified with a + in
+#    Figure 1) until Section 3 and of the optional ECC-specific extensions
+#    (which impact the Hello messages) until Section 4.
 
 [[spec]]
 level = "SHOULD"

.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-3.1.toml

@@ -1,14 +1,14 @@
 target = "https://www.rfc-editor.org/rfc/rfc4492#section-3.1"
 
-# 3.1.  ECDSA_sign
+# ECDSA_sign
 #
-# To use this authentication mechanism, the client MUST possess a
-# certificate containing an ECDSA-capable public key and signed with
-# ECDSA.
+#    To use this authentication mechanism, the client MUST possess a
+#    certificate containing an ECDSA-capable public key and signed with
+#    ECDSA.
 # 
-# The client proves possession of the private key corresponding to the
-# certified key by including a signature in the CertificateVerify
-# message as described in Section 5.8.
+#    The client proves possession of the private key corresponding to the
+#    certified key by including a signature in the CertificateVerify
+#    message as described in Section 5.8.
 
 [[spec]]
 level = "MUST"