Address formatting issues with the BRs

There are three typographical/formatting issues in the current generated documents: - Sections 3.2.2.4.18 / 3.2.2.4.19 don't properly appear as numbered lists. - Section 4.10.1 is missing a trailing period. - Section 6.1.6 makes use of <sup> for superscript, which is valid for GitHub flavored markdown, but not in general Markdown. Although Pandoc supports superscripts via the `superscript` extension, that just leans more into Pandoc-flavored markdown. Rather than do that, keep it vanilla markdown by adding a carat and whitespace to indicate the superscripting. Closes cabforum#230 Closes cabforum#231
sleevi · Nov 24, 2020 · e50be27 · e50be27
1 parent 219e2c0
commit e50be27
Showing 1 changed file with 33 additions and 26 deletions.
diff --git a/docs/BR.md b/docs/BR.md
@@ -756,22 +756,26 @@ The Random Value SHALL remain valid for use in a confirming response for no more
 ##### 3.2.2.4.18 Agreed-Upon Change to Website v2
 
 Confirming the Applicant's control over the FQDN by verifying that the Request Token or Random Value is contained in the contents of a file.
+
 1.	The entire Request Token or Random Value MUST NOT appear in the request used to retrieve the file, and
 2.	the CA MUST receive a successful HTTP response from the request (meaning a 2xx HTTP status code must be received).
 
 The file containing the Request Token or Random Number:
+
 1.	MUST be located on the Authorization Domain Name, and
 2.	MUST be located under the "/.well-known/pki-validation" directory, and
 3.	MUST be retrieved via either the "http" or "https" scheme, and
 4.	MUST be accessed over an Authorized Port.
 
 If the CA follows redirects the following apply:
+
 1.	Redirects MUST be initiated at the HTTP protocol layer (e.g. using a 3xx status code).
 2.	Redirects MUST be the result of an HTTP status code result within the 3xx Redirection class of status codes, as defined in RFC 7231, Section 6.4.
 3.	Redirects MUST be to resource URLs with either via the "http" or "https" scheme.
 4.	Redirects MUST be to resource URLs accessed via Authorized Ports.
 
 If a Random Value is used, then:
+
 1.	The CA MUST provide a Random Value unique to the certificate request.
 2.	The Random Value MUST remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values, in which case the CA MUST follow its CPS.
 
@@ -786,6 +790,7 @@ The CA MUST receive a successful HTTP response from the request (meaning a 2xx H
 The token (as defined in RFC 8555, section 8.3) MUST NOT be used for more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values, in which case the CA MUST follow its CPS.
 
 If the CA follows redirects:
+
 1.	Redirects MUST be initiated at the HTTP protocol layer (e.g. using a 3xx status code).
 2.	Redirects MUST be the result of an HTTP status code result within the 3xx Redirection class of status codes, as defined in RFC 7231, Section 6.4.
 3.	Redirects MUST be to resource URLs with either via the "http" or "https" scheme.
@@ -1172,7 +1177,6 @@ Effective 2020-09-30:
 3. For OCSP responses with validity intervals less than sixteen hours, then the CA SHALL update the information provided via an Online Certificate Status Protocol prior to one-half of the validity period before the nextUpdate.
 4. For OCSP responses with validity intervals greater than or equal to sixteen hours, then the CA SHALL update the information provided via an Online Certificate Status Protocol at least eight hours prior to the nextUpdate, and no later than four days after the thisUpdate.
 
-
 For the status of Subordinate CA Certificates:
 
 * The CA SHALL update information provided via an Online Certificate Status Protocol (i) at least every twelve months; and (ii) within 24 hours after revoking a Subordinate CA Certificate.
@@ -1210,8 +1214,7 @@ Not applicable.
 ## 4.10 Certificate status services
 
 ### 4.10.1 Operational characteristics
-Revocation entries on a CRL or OCSP Response MUST NOT be removed until after the Expiry Date of the revoked
-Certificate
+Revocation entries on a CRL or OCSP Response MUST NOT be removed until after the Expiry Date of the revoked Certificate.
 
 ### 4.10.2 Service availability
 The CA SHALL operate and maintain its CRL and OCSP capability with resources sufficient to provide a response time of ten seconds or less under normal operating conditions.
@@ -1497,7 +1500,7 @@ For ECDSA key pairs, the CA SHALL:
 No other algorithms or key sizes are permitted.
 
 ### 6.1.6 Public key parameters generation and quality checking
-RSA: The CA SHALL confirm that the value of the public exponent is an odd number equal to 3 or more. Additionally, the public exponent SHOULD be in the range between 2<sup>16</sup>+1 and 2<sup>256</sup>-1. The modulus SHOULD also have the following characteristics: an odd number, not the power of a prime, and have no factors smaller than 752. [Source: Section 5.3.3, NIST SP 800-89]
+RSA: The CA SHALL confirm that the value of the public exponent is an odd number equal to 3 or more. Additionally, the public exponent SHOULD be in the range between 2^16 + 1 and 2^256 - 1. The modulus SHOULD also have the following characteristics: an odd number, not the power of a prime, and have no factors smaller than 752. [Source: Section 5.3.3, NIST SP 800-89]
 
 ECDSA: The CA SHOULD confirm the validity of all keys using either the ECC Full Public Key Validation Routine or the ECC Partial Public Key Validation Routine. [Source: Sections 5.6.2.3.2 and 5.6.2.3.3, respectively, of NIST SP 800-56A: Revision 2]
 
@@ -2345,32 +2348,36 @@ This appendix defines permissible verification procedures for including one or m
 
 1. The Domain Name MUST contain at least two labels, where the right-most label is "onion", and the label immediately preceding the right-most "onion" label is a valid Version 3 Onion Address, as defined in section 6 of the Tor Rendezvous Specification - Version 3 located at <https://spec.torproject.org/rend-spec-v3>.
 2. The CA MUST verify the Applicant’s control over the .onion Domain Name using at least one of the methods listed below:
+
     a. The CA MAY verify the Applicant’s control over the .onion service by using method 3.2.2.4.6, Agreed‐Upon Change to Website. If this method is replaced by a newer version(s) of Agreed-Upon Change to Website, the timelines for use of new and existing version of this method that are defined in section 3.2.2.4 SHALL apply.
     b. The CA MAY verify the Applicant's control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains:
+
         (i) A caSigningNonce attribute that contains a Random Value that is generated by the CA; and
         (ii) An applicantSigningNonce attribute that contains a single value with at least 64-bits of entropy that is generated by the Applicant.
 
-The signing nonce attributes have the following format:
-```
-caSigningNonce ATTRIBUTE ::= {
-    WITH SYNTAX              OCTET STRING
-    EQUALITY MATCHING RULE   octetStringMatch
-    SINGLE VALUE             TRUE
-    ID                       { cabf-caSigningNonce }
-}
-
-cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 }
-
-applicantSigningNonce ATTRIBUTE ::= {
-    WITH SYNTAX              OCTET STRING
-    EQUALITY MATCHING RULE   octetStringMatch
-    SINGLE VALUE             TRUE
-    ID                       { cabf-applicantSigningNonce }
-}
-
-cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 }
-```
-The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values.
-The CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the left-most character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 3.2.2.6 of these Requirements.
+        The signing nonce attributes have the following format:
+
+        ```
+        caSigningNonce ATTRIBUTE ::= {
+            WITH SYNTAX              OCTET STRING
+            EQUALITY MATCHING RULE   octetStringMatch
+            SINGLE VALUE             TRUE
+            ID                       { cabf-caSigningNonce }
+        }
+
+        cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 }
+
+        applicantSigningNonce ATTRIBUTE ::= {
+            WITH SYNTAX              OCTET STRING
+            EQUALITY MATCHING RULE   octetStringMatch
+            SINGLE VALUE             TRUE
+            ID                       { cabf-applicantSigningNonce }
+        }
+
+        cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 }
+        ```
+
+        The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values.
+        The CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the left-most character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 3.2.2.6 of these Requirements.
 
 3. When a Certificate includes an FQDN where "onion" is in the right-most label of the Domain Name, the Domain Name shall not be considered an Internal Name provided that the Certificate was issued in compliance with this Appendix B.