README: Fix typos

README.rst

@@ -26,7 +26,7 @@ constraint at all on subject and alternate subject certificate fields.
 To still allow certificates to be used, caucase uses itself to authenticate
 users (humans or otherwise) who implement the validation procedure: they tell
 caucase what certificates to emit. Once done, any certificate can be
-prolungated at a simple request of the key holder while the to-renew
+prolonged at a simple request of the key holder while the to-renew
 certificate is still valid (not expired, not revoked).
 
 Bootstrapping the system (creating the first service certificate for
@@ -37,7 +37,7 @@ set number of certificates upon submission.
 Vocabulary
 ==========
 
-Caucase manipulates the following asymetric cryptography concepts.
+Caucase manipulates the following asymmetric cryptography concepts.
 
 - Key pair: A private key and corresponding public key. The public key can be
   derived from the private key, but not the other way around. As a consequence,
@@ -54,11 +54,11 @@ Caucase manipulates the following asymetric cryptography concepts.
   certified, which they send to a certificate authority. The certificate signing
   request contains the public key and desired set of attributes that the CA
   should pronounce itself on. The CA has all liberty to issue a different set
-  of attiributes, or to not issue a certificate.
+  of attributes, or to not issue a certificate.
 
 - Certificate revocation list: Lists the certificates which were issued by a CA
-  but which should not be trusted annymore. This can happen for a variety of
-  reasons: the private key was compromised, or its owneing entity should not be
+  but which should not be trusted anymore. This can happen for a variety of
+  reasons: the private key was compromised, or its owning entity should not be
   trusted anymore (ex: entity's permission to access to protected service was
   revoked).
 
@@ -69,7 +69,7 @@ Caucase manipulates the following asymetric cryptography concepts.
 Validity period
 ===============
 
-Cryptographic keys wear out as are used and and as they age.
+Cryptographic keys wear out as are used and as they age.
 
 Of course, they do not bit-rot nor become thinner with use. But each time one
 uses a key and each minute an attacker had access to a public key, fractions
@@ -87,7 +87,7 @@ Then the CA certificate has a default life span of 4 "normal" certificate
 validity periods. As CA renewal happens in caucase without x509-level cross
 signing (by decision, to avoid relying on intermediate CA support on
 certificate presenter side and instead rely on more widespread
-multi-CA-certificate support on virifier side), there is a hard lower bound of
+multi-CA-certificate support on verifier side), there is a hard lower bound of
 3 validity periods, under which the CA certificate cannot be reliably renewed
 without risking certificate validation issues for emitted "normal"
 certificates. CA certificate renewal is composed of 2 phases:
@@ -106,7 +106,7 @@ certificates. CA certificate renewal is composed of 2 phases:
   out of use as its signed "normal" certificates expire.
 
 By default, all caucase tools will generate a new private key unrelated to the
-previous one on each certificat renewal.
+previous one on each certificate renewal.
 
 Lastly, there is another limited validity period, although not for the same
 reasons: the list of revoked certificates also has a maximum life span. In
@@ -258,7 +258,7 @@ their access only via different credentials.
 - key holders manifest themselves
 
 - admin picks a key holder, requests them to provide their existing private key
-  and to generate a new key and accompanying csr
+  and to generate a new key and accompanying CSR
 
 - key holder provide requested items