Remove manual wrapping

draft-ietf-acme-dns-account-01.mkd

@@ -52,68 +52,36 @@ informative:
 
 --- abstract
 
-This document outlines a new challenge for the ACME protocol, enabling an ACME
-client to answer a domain control validation challenge from an ACME server
-using a DNS resource linked to the ACME Account ID. This allows multiple
-systems or environments to handle challenge-solving for a single domain.
+This document outlines a new challenge for the ACME protocol, enabling an ACME client to answer a domain control validation challenge from an ACME server using a DNS resource linked to the ACME Account ID. This allows multiple systems or environments to handle challenge-solving for a single domain.
 
 --- middle
 
 # Introduction
 
-The `dns-01` challenge specified in section 8.4 of {{!RFC8555}} requires that
-ACME clients validate the domain under the `_acme-challenge` label for the
-`TXT` record. This label creates several limiations in domain validation.
-
-First, the `_acme-challenge` label does not specify if the authorization is
-intended for a specific host, a wildcard domain, or a domain and all of its
-subdomains. Consequently, domain owners who may be delegating or provisioning
-authorization labels for a domain must concede control over the domain and all
-subdomains, violating the principle of least privilege.
-
-Furthermore, since each domain only has a single authorization label, it creates an impediment
-limiting the number of other entities domain validation can be delegated to.
-Delegating authorization to an entity requires the use of CNAME records, which can only used once
-per DNS name (or in this case, once per authorization label). This limitation requires that
-operators to pick a single ACME challenge solver for their domain name.
-
-In multi-region deployments, where separate availability zones
-serve the same content, and dependencies across them are avoided, operators need
-a way to obtain a separate certificate per zone, for the same domain name.
-Similarly, in cases of zero-downtime migration, two different setups of the
-infrastructure may coexist for a long period of time, and both need access to valid
-certificates.
+The `dns-01` challenge specified in section 8.4 of {{!RFC8555}} requires that ACME clients validate the domain under the `_acme-challenge` label for th `TXT` record. This label creates several limiations in domain validation.
+
+First, the `_acme-challenge` label does not specify if the authorization is intended for a specific host, a wildcard domain, or a domain and all of its subdomains. Consequently, domain owners who may be delegating or provisioning authorization labels for a domain must concede control over the domain and all subdomains, violating the principle of least privilege.
+
+Furthermore, since each domain only has a single authorization label, it creates an impediment limiting the number of other entities domain validation can be delegated to. Delegating authorization to an entity requires the use of CNAME records, which can only used once per DNS name (or in this case, once per authorization label). This limitation requires that operators to pick a single ACME challenge solver for their domain name.
+
+In multi-region deployments, where separate availability zones serve the same content, and dependencies across them are avoided, operators need a way to obtain a separate certificate per zone, for the same domain name. Similarly, in cases of zero-downtime migration, two different setups of the infrastructure may coexist for a long period of time, and both need access to valid certificates.
 
 This document specifies two new challenge types. `dns-02` and `dns-account-01`, which aim to address these deficiencies.
 
-This work follows all recommendations set forth in "Domain Control
-Validation using DNS" [I-D.draft-ietf-dnsop-domain-verification-techniques].
+This work follows all recommendations set forth in "Domain Control Validation using DNS" [I-D.draft-ietf-dnsop-domain-verification-techniques].
 
-This RFC does not intend to deprecate the `dns-01` challenge specified in
-{{!RFC8555}}. Since these new challenges do not modify any pre-existing challenges,
-the ability to complete the `dns-02` or `dns-account-01` challenge requires ACME server
-operators to deploy new changes to their codebase. This makes adopting and using these
-challenges an opt-in process.
+This RFC does not intend to deprecate the `dns-01` challenge specified in {{!RFC8555}}. Since these new challenges do not modify any pre-existing challenges, the ability to complete the `dns-02` or `dns-account-01` challenge requires ACME server operators to deploy new changes to their codebase. This makes adopting and using these challenges an opt-in process.
 
 ## DNS-02
 
-The `dns-02` challenge adds onto `dns-01` by introducing a scoping mechanism
-to the domain authorization label. This allows for the client to specify if the
-intended domain validation is for a specific host, a wildcard domain, or a domain
-and all of its subdomains.
+The `dns-02` challenge adds onto `dns-01` by introducing a scoping mechanism to the domain authorization label. This allows for the client to specify if the intended domain validation is for a specific host, a wildcard domain, or a domain and all of its subdomains.
 
 ## DNS-ACCOUNT-01
 
-The `dns-account-01` challenge leverages the ACME Account Resource URL to present
-an account-unique stable challenge to an ACME server. This challenge allows any
-domain name to delegate its domain validation to more than one service through
+The `dns-account-01` challenge leverages the ACME Account Resource URL to present an account-unique stable challenge to an ACME server. This challenge allows any domain name to delegate its domain validation to more than one service through
 unique per ACME account DNS records.
 
-With this new challenge, domain validation of the same DNS name can be done through
-different authorization labels. Since these authorization labels will depend on the ACME
-account KID ({{!RFC8555, Section 6.2}}), any number of them can be generated in advance.
-This allows all required `CNAME` records for domain validation delegation to be constructed
-statically.
+With this new challenge, domain validation of the same DNS name can be done through different authorization labels. Since these authorization labels will depend on the ACME account KID ({{!RFC8555, Section 6.2}}), any number of them can be generated in advance. This allows all required `CNAME` records for domain validation delegation to be constructed statically.
 
 # Conventions and Definitions