Merge pull request #1476 from madeline-underwood/CCA-Attestation-LP-intro_cleanup

Cleaned up reference to prerequisite reading that had a title change.

Author: pareenaverma

content/learning-paths/servers-and-cloud-computing/cca-essentials/_index.md

@@ -12,7 +12,7 @@ learning_objectives:
 
 prerequisites:
     - An AArch64 or x86_64 computer running Linux. You can use cloud instances, see this list of [Arm cloud service providers](/learning-paths/servers-and-cloud-computing/csp/).
-    - Completion of the [Introduction to CCA Attestation with Veraison](/learning-paths/servers-and-cloud-computing/cca-veraison) Learning Path.
+    - Completion of [Get Started with CCA Attestation and Veraison](/learning-paths/servers-and-cloud-computing/cca-veraison) Learning Path.
     - Completion of the [Run an application in a Realm using the Arm Confidential Computing Architecture (CCA)](/learning-paths/servers-and-cloud-computing/cca-container/) Learning Path.
 
 author_primary: Arnaud de Grandmaison, Paul Howard, and Pareena Verma

content/learning-paths/servers-and-cloud-computing/cca-essentials/cca-essentials.md

@@ -20,7 +20,7 @@ The role of the KBS is to be a repository for encryption keys or other confident
 
 The workload that runs inside the realm is a client of the KBS. It calls the KBS to request a secret, but the KBS does not return the secret immediately. Instead, it issues an attestation challenge back to the client. The client must respond with evidence in the form of a [CCA attestation token](/learning-paths/servers-and-cloud-computing/cca-container/cca-container/#obtain-a-cca-attestation-token-from-the-virtual-guest-in-a-realm).
 
-When the KBS receives an attestation token from the realm, it needs to call a verification service that checks the token's cryptographic signature and verifies that it denotes a confidential computing platform. As you saw in the prerequisite reading [Introduction to CCA Attestation with Veraison Learning Path](/learning-paths/servers-and-cloud-computing/cca-veraison), Linaro provides such an attestation verifier for use with pre-silicon CCA platforms. This verifier is built from the open-source [Veraison project](https://github.com/veraison). The KBS calls this verifier to obtain an attestation result. The KBS then uses this result to decide whether to release the secrets into the realm for processing.
+When the KBS receives an attestation token from the realm, it needs to call a verification service that checks the token's cryptographic signature and verifies that it denotes a confidential computing platform. As you saw in the prerequisite reading Learning Path [Get Started with CCA Attestation and Veraison](/learning-paths/servers-and-cloud-computing/cca-veraison), Linaro provides such an attestation verifier for use with pre-silicon CCA platforms. This verifier is built from the Open-Source [Veraison project](https://github.com/veraison). The KBS calls this verifier to obtain an attestation result. The KBS then uses this result to decide whether to release the secrets into the realm for processing.
 
 For additional security, the KBS does not release any secrets in clear text, even after a successful verification of the attestation token. Instead, the realm provides an additional public encryption key to the KBS. This is known as a wrapping key. The KBS uses this public key to wrap, which here means encrypt, the secrets. The client workload inside the realm is then able to use its own private key to unwrap the secrets and use them.
 
@@ -32,6 +32,6 @@ The attestation verification service is hosted by Linaro, so it is not necessary
 
 Figure 1 demonstrates the software architecture that you will construct to run the attestation example.
 
-![cca-essentials](cca-essentials.png "Figure 1: Software architecture for running attestation")
+![cca-essentials](cca-essentials.png "Figure 1: Software architecture for running attestation.")
 
 You can now proceed to the next section to run the end-to-end attestation example with the software components and architecture as described here.

content/learning-paths/servers-and-cloud-computing/cca-essentials/example.md

@@ -59,11 +59,11 @@ INFO Actix runtime found; starting in Actix runtime
 INFO starting service: "actix-web-service-172.17.0.2:8088", workers: 16, listening on: 172.17.0.2:8088
 ```
 
-With the key broker server running in one terminal, open up a new terminal in which you will run the key broker client in the next step.
+With the Key Broker Server running in one terminal, open up a new terminal in which you will run the Key Broker Client in the next step.
 
 ## Run the Key Broker Client
 
-In the new terminal that you have just opened, pull the docker container image that contains the FVP and pre-built software binaries to run the key broker client in a realm.
+In the new terminal that you have just opened, pull the docker container image that contains the FVP and pre-built software binaries to run the Key Broker Client in a realm.
 
 ```bash
 docker pull armswdev/cca-learning-path:cca-simulation-v1
@@ -134,15 +134,15 @@ realm login: root
 (realm) #
 ```
 
-Now run the key broker client application in the realm. 
+Now run the Key Broker Client application in the realm. 
 
-Use the endpoint address that the key broker server is listening in on the other terminal:
+Use the endpoint address that the Key Broker Server is listening in on the other terminal:
 
 ```bash
 cd /cca 
 ./keybroker-app -v --endpoint http://172.17.0.2:8088 skywalker 
 ```
-In the command above, `skywalker` is the key name that is requested from the key broker server. 
+In the command above, `skywalker` is the key name that is requested from the Key Broker Server. 
 
 After some time, you should see the following output:
 ```
@@ -151,11 +151,11 @@ INFO Challenge (64 bytes) = [0f, ea, c4, e2, 24, 4e, fa, dc, 1d, ea, ea, 3d, 60,
 INFO Submitting evidence to URL http://172.17.0.2:8088/keys/v1/evidence/3974368321
 INFO Attestation failure :-( ! AttestationFailure: No attestation result was obtained. No known-good reference values.
 ```
-You can see from the key broker client application output that the `skywalker` key is requested from the key broker server, which did send a challenge. 
+You can see from the Key Broker client application output that the `skywalker` key is requested from the Key Broker Server, which did send a challenge. 
 
-The key broker client application uses the challenge to submit its evidence back to the key broker server, but it receives an attestation failure. This is because the server does not have any known good reference values.
+The Key Broker Client application uses the challenge to submit its evidence back to the Key Broker Server, but it receives an attestation failure. This is because the server does not have any known good reference values.
 
-Now look at the key broker server output on the terminal where the server is running. It will look like this:
+Now look at the Key Broker Server output on the terminal where the server is running. It will look like this:
 
 ```output
 INFO Known-good RIM values are missing. If you trust the client that submitted
@@ -164,23 +164,23 @@ command-line option to populate it with known-good RIM values:
 --reference-values <(echo '{ "reference-values": [ "tiA66VOokO071FfsCHr7es02vUbtVH5FpLLqTzT7jps=" ] }')
 INFO Evidence submitted for challenge 1302147796: no attestation result was obtained. No known-good reference values.
 ```
-From the server output, you can see that it did create the challenge for the key broker application, but it reports that it has no known good reference values. 
+From the server output, you can see that it did create the challenge for the Key Broker application, but it reports that it has no known good reference values. 
 
-It does however provide a way to provision the key broker server with known good values if the client is trusted. 
+It does however provide a way to provision the Key Broker Server with known good values if the client is trusted. 
 
-In a production environment, the known good reference value is generated using a deployment- specific process, but for demonstration purposes and simplification, you will use the value proposed by the key broker server.
+In a production environment, the known good reference value is generated using a deployment- specific process, but for demonstration purposes and simplification, you will use the value proposed by the Key Broker Server.
 
-Now go ahead and terminate the running instance of the key broker server using Ctrl+C and restart it with the known good reference value. 
+Now go ahead and terminate the running instance of the Key Broker Server using Ctrl+C and restart it with the known good reference value. 
 
-Notice here that you need to copy the `--reference-values` argument directly from the previous error message reported by the key broker. 
+Notice here that you need to copy the `--reference-values` argument directly from the previous error message reported by the Key Broker. 
 
 When running the next command, ensure that you are copying the exact value reported, for example:
 
 ```bash
 ./keybroker-server -v --addr 172.17.0.2 --reference-values <(echo '{ "reference-values": [ "tiA66VOokO071FfsCHr7es02vUbtVH5FpLLqTzT7jps=" ] }')
 ```
 
-On the terminal with the running realm, rerun the key broker client application with the exact same command line parameters as before:
+On the terminal with the running realm, rerun the Key Broker Client application with the exact same command line parameters as before:
 
 ```bash
 ./keybroker-app -v --endpoint http://172.17.0.2:8088 skywalker