use certificate authority vs certification authority

Author: drbruced12

infra.rst

@@ -317,7 +317,7 @@ additional layers in this hierarchy. A hierarchy of
 certificates can be created to follow this hierarchy of address
 allocation.  The RIRs form trust anchors from which chains of trust
 can be built, much the way a modern browser comes with a set of
-trusted root certification authorities (CAs) so that the certificates
+trusted root certificate authorities (CAs) so that the certificates
 issued by web sites, which are signed by CAs, can be checked for validity.
 
 A key distinction between RPKI and the certificates that we are
@@ -519,7 +519,7 @@ or numbers corresponding to the AS in which the router is located.
 As with all public key certificates, we need a chain of trust from a
 trusted root to the router certificate. For example, an RIR could
 provide the root of trust, and sign certificates for ISPs, who
-could then act as the certification authorities for their own routers. The
+could then act as the certificate authorities for their own routers. The
 use of the word "could" in this paragraph reflects the lack of
 real-world deployment of BGPsec.
 
@@ -884,7 +884,7 @@ While there are obvious similarities to the chains of trust used for
 TLS, the notable difference here is that the chain of
 certificates that must be followed is precisely defined by the
 hierarchy of the DNS. Whereas a TLS certificate could be issued by a
-range of certification authorities, the certificates for any zone in
+range of certificate authorities, the certificates for any zone in
 DNSSEC must be issued by the parent zone. This has some advantages,
 such as limiting the opportunities for bad behavior by CAs that has
 occasionally occurred with TLS certificates. However, it also

key-distro.rst

@@ -98,14 +98,16 @@ perhaps directly from Alice—as long as they trust Bob and know his
 public key. You can see how starting from a very small number of keys
 (in this case, just Bob’s) you could build up a large set of trusted
 keys over time. Bob in this case is playing the role often referred to
-as a *certification authority* (CA), and much of today’s Internet
-security depends on CAs. VeriSign is one well-known commercial CA.
+as a *certificate authority* (CA), and much of today’s Internet
+security depends on CAs. There are many commercial and non-profit CAs
+in widespread use today. You may also see CA expanded as
+*certification authority*—the two expansions are equivalent. 
 
 One thing to note about the above example is that we have to know two
 things about Bob. First, we need to know his public key so that we can
 verify that certain messages were originated by Bob. But we also have
 to know that Bob is trustworthy enough to make statements about the
-keys of others, which is where certification authorities (rather than
+keys of others, which is where certificate authorities (rather than
 random individuals) come into play.  We return to this topic below.
 
 One of the major standards for certificates is known as X.509. This
@@ -138,7 +140,7 @@ domains.
 There are different ways a PKI could formalize the notion of trust. We
 discuss the two main approaches.
 
-4.1.1 Certification Authorities
+4.1.1 Certificate Authorities
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 In the first model, trust is binary; you either trust someone
@@ -152,10 +154,10 @@ In other words, all you need is a chain of certificates, all signed by
 entities you trust, as long as it leads back to an entity whose key you
 already know.
 
-A *certification authority* or *certificate authority* (CA) is an entity
+A *certificate authority* or *certification authority* (CA) is an entity
 claimed (by someone) to be trustworthy for verifying identities and
 issuing public key certificates. There are commercial CAs, governmental
-CAs, and even free CAs. To use a CA, you must know its own key. You can
+CAs, and non-profit CAs. To use a CA, you must know its own key. You can
 learn that CA’s key, however, if you can obtain a chain of CA-signed
 certificates that starts with a CA whose key you already know. Then you
 can believe any certificate signed by that new CA.
@@ -172,7 +174,7 @@ trust for that participant.
    :width: 600px
    :align: center
 
-   Tree-structured certification authority hierarchy.
+   Tree-structured certificate authority hierarchy.
 
 There are some significant issues with building chains of trust. Most
 importantly, even if you are certain that you have the public key of the
@@ -296,7 +298,7 @@ distribution of the CRL to prolong the amount of time they can use the
 compromised key. A number of proposals have been made to improve the
 effectiveness of certificate revocation, such as using bit vectors or
 other compact representations of the CRL to reduce its size, and the
-development of the Online Certification Status Protocol (OCSP) to
+development of the Online Certificate Status Protocol (OCSP) to
 enable real-time checks on a certificate's status. At the time of
 writing, there are some best practices for handling certificate
 revocation but no comprehensive solution. A good discussion of the

tls.rst

@@ -146,7 +146,7 @@ between client and server will be encrypted. But we still have to rule
 out the MITM attack.
 
 3. The server now sends one or more certificates. In the simplest
-   case, there is a single certificate signed by a certification
+   case, there is a single certificate signed by a certificate
    authority (CA) that is trusted by the client.
 
 4. The server sends a "certificate verify" message, which proves that
@@ -528,7 +528,7 @@ need to consider how all the parts of a system interact with each
 other to form a coherent whole, rather than just looking at single
 components in isolation. For example, TLS is a system that includes
 both public-key and symmetric-key cryptography, authentication and
-privacy mechanisms, certification authorities, and sub-layers such as
+privacy mechanisms, certificate authorities, and sub-layers such as
 the record protocol and the handshake protocol. But the systems
 approach applies recursively too. As we have already seen, it is
 important to look at how TLS sits within the overall protocol stack,
@@ -552,7 +552,7 @@ another warning is presented. Users can generally choose to override
 these warnings but the overall effect is to reinforce behaviors that
 are more secure and discourage those that are insecure.
 
-Certification authorities are a critical part of this overall
+Certificate authorities are a critical part of this overall
 system. Most users have no way to determine whether any given CA does
 its job properly. As discussed in Chapter 4, the way that CA
 hierarchies work means that a lot of trust is placed at the top-level