diff --git a/design/20190708.certificate-request-crd.md b/design/20190708.certificate-request-crd.md
index 23d9e3335..f6654c37e 100644
--- a/design/20190708.certificate-request-crd.md
+++ b/design/20190708.certificate-request-crd.md
@@ -203,7 +203,7 @@ CertificateRequest with a Denied condition will never be signed.
 ##### Behaviour
 
 The Approved and Denied conditions are two distinct condition types on the
-CertificateRequest. These conditions must always have the status of True, and
+CertificateRequest. These conditions must only have the status of True, and
 are mutually exclusive (i.e. a CertificateRequest cannot have an Approved and
 Denied condition simultaneously). This behaviour is enforced in the cert-manager
 validating admission webhook.
@@ -232,8 +232,8 @@ certificates.k8s.io CertificateSigningRequest resource that utilises `approval`,
 as CustomResourceDefinitions may [only define `/status` or `/scale`
 sub-resources](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#subresources).
 Approvers must therefore have permissions to update the status sub-resource of
-CertificateSigningRequests. Approvers missing this permissions will have their
-request rejected by the API server.
+CertificateRequests. Approvers missing this permissions will have their request
+rejected by the API server.
 
 Setting the Approved or Denied conditions are restricted by the approver having
 sufficient RBAC permissions. These permissions are based upon the request
@@ -274,7 +274,7 @@ that is performed in the cert-manager Webhook component when a user attempts to
 set the Approve or Denied condition. The user of the approver is tested along
 with the IssuerRef of the CertificateRequest.
 
-If the user does not have sufficient permissions defined above to set the
+If the approver does not have sufficient permissions defined above to set the
 Approved or Denied conditions, the request will be rejected by the cert-manager
 validating admission webhook.
 
@@ -331,9 +331,9 @@ and `bar`:
 ##### Webhook signer string building
 
 The validating admission webhook is responsible for making SubjectAccessReviews
-to evaluate whether the user has [sufficient permissions to add the Approved or
-Denied conditions](#rbac). The webhook will attempt to first check whether the
-use can approve all signers in all namespaced (wildcard), and if this fails,
+to evaluate whether the approver has [sufficient permissions to add the Approved
+or Denied conditions](#rbac). The webhook will attempt to first check whether
+the use can approve all signers in all namespaced (wildcard), and if this fails,
 whether it can approve for the exact signer (`.<signer-name>` or
 `<signer-namespace>.<signer-name>`).
 
@@ -351,10 +351,10 @@ The cert-manager controller is deployed with an internal approver controller.
 This controller will attempt to Approve *all* CertificateRequests that are
 created, regardless of its contents or IssuerRef.
 
-By default, this approver is given the permission to sign all internal signers,
-that is `Issuer` and `ClusterIssuer` `cert-manager.io` signers. This means its
-ClusterRole is given the `resourceNames`: `issuers.cert-manager.io/*` and
-`clusterissuers.cert-manager.io/*`
+By default, this approver is given the permission to approve all internal
+signers, that is `Issuer` and `ClusterIssuer` `cert-manager.io` signers. This
+means its ClusterRole is given the `resourceNames`: `issuers.cert-manager.io/*`
+and `clusterissuers.cert-manager.io/*`
 
 External issuers may consider whether they wish to install further RBAC that
 would allow the cert-manager approver controller to also approve