review and acrolinx fixes

Author: kgremban

articles/iot-dps/concepts-tpm-attestation.md

@@ -14,29 +14,29 @@ ms.service: iot-dps
 
 This article describes the concepts involved when provisioning devices using Trusted Platform Module (TPM) attestation in the Device Provisioning Service (DPS). This article is relevant to all personas involved in getting a device ready for deployment.
 
-A Trusted Platform Module (TPM) is a type of hardware security module (HSM). This article assumes you are using a discrete, firmware, or integrated TPM. Software emulated TPMs are well-suited for prototyping or testing, but they do not provide the same level of security as discrete, firmware, or integrated TPMs do. We do not recommend using software TPMs in production.
+A Trusted Platform Module (TPM) is a type of hardware security module (HSM). This article assumes that you're using a discrete, firmware, or integrated TPM. Software emulated TPMs are well-suited for prototyping or testing, but they don't provide the same level of security as discrete, firmware, or integrated TPMs do. We don't recommend using software TPMs in production.
 
-This article is only relevant for devices using TPM 2.0 with HMAC key support and their endorsement keys. TPM is an industry-wide, ISO standard from the Trusted Computing Group, and you can read more about TPM at the [complete TPM 2.0 spec](https://trustedcomputinggroup.org/tpm-library-specification/) or the [ISO/IEC 11889 spec](https://www.iso.org/standard/66510.html). This article also assumes you are familiar with public and private key pairs, and how they are used for encryption.
+This article is only relevant for devices using TPM 2.0 with HMAC key support and their endorsement keys. TPM is an industry-wide, ISO standard from the Trusted Computing Group, and you can read more about TPM at the [complete TPM 2.0 spec](https://trustedcomputinggroup.org/tpm-library-specification/) or the [ISO/IEC 11889 spec](https://www.iso.org/standard/66510.html). This article also assumes that you're familiar with public and private key pairs, and how they're used for encryption.
 
-The Device Provisioning Service device SDKs handle everything that is described in this article for you. There is no need for you to implement anything additional if you are using the SDKs on your devices. This article helps you understand conceptually what’s going on with your TPM security chip when your device provisions and why it’s so secure.
+The Device Provisioning Service device SDKs handle everything that is described in this article for you. There is no need for you to implement TPM support if you're using the SDKs on your devices. This article helps you understand conceptually what’s going on with your TPM security chip when your device provisions and why it’s so secure.
 
 ## Overview
 
 TPMs use something called the endorsement key (EK) as the secure root of trust. The EK is unique to the TPM and changing it essentially changes the device into a new one.
 
-TPM have another type of key called the storage root key (SRK). An SRK may be generated by the TPM's owner after it takes ownership of the TPM. Taking ownership of the TPM is the TPM-specific way of saying "someone sets a password on the HSM." If a TPM device is sold to a new owner, the new owner can take ownership of the TPM to generate a new SRK. The new SRK generation ensures the previous owner can't use the TPM. Because the SRK is unique to the owner of the TPM, the SRK can be used to seal data into the TPM itself for that owner. The SRK provides a sandbox for the owner to store their keys and provides access revocability if the device or TPM is sold. It's like moving into a new house: taking ownership is changing the locks on the doors and destroying all furniture left by the previous owners (SRK), but you can't change the address of the house (EK).
+TPMs have another type of key called the storage root key (SRK). An SRK may be generated by the TPM's owner after it takes ownership of the TPM. Taking ownership of the TPM is the TPM-specific way of saying "someone sets a password on the HSM." If a TPM device is sold to a new owner, the new owner can take ownership of the TPM to generate a new SRK. The new SRK generation ensures the previous owner can't use the TPM. Because the SRK is unique to the owner of the TPM, the SRK can be used to seal data into the TPM itself for that owner. The SRK provides a sandbox for the owner to store their keys and provides access revocability if the device or TPM is sold. It's like moving into a new house: taking ownership is changing the locks on the doors and destroying all furniture left by the previous owners (SRK), but you can't change the address of the house (EK).
 
-Once a device has been set up, it will have both an EK and an SRK available for use.
+Once a device is set up, it has both an EK and an SRK available for use.
 
-![Diagram that demonstrates taking ownership of a TPM](./media/concepts-tpm-attestation/tpm-ownership.png)
+![Diagram that demonstrates taking ownership of a TPM.](./media/concepts-tpm-attestation/tpm-ownership.png)
 
-The specific steps involved in taking ownership of a TPM vary depending on the manufacturer, the set of TPM tools being used, and the device operating system. Follow the instructions relevant to your system to take ownership.
+The specific steps involved in taking ownership of a TPM vary depending on the manufacturer, the set of TPM tools being used, and the device operating system.
 
 The Device Provisioning Service uses the public part of the EK (EK_pub) to identify and enroll devices. The device vendor can read the EK_pub during manufacture or final testing and upload the EK_pub to the provisioning service so that the device will be recognized when it connects to provision. The Device Provisioning Service does not check the SRK or owner, so “clearing” the TPM erases customer data, but the EK (and other vendor data) is preserved and the device will still be recognized by the Device Provisioning Service when it connects to provision.
 
 ## Attestation process
 
-When a device with a TPM connects to the Device Provisioning Service, the service first checks the provided EK_pub against the EK_pub stored in the enrollment list. If the EK_pubs do not match, the device is not allowed to provision. If the EK_pubs do match, the service then requires the device to prove ownership of the private portion of the EK via a nonce challenge, which is a secure challenge used to prove identity. The Device Provisioning Service generates a nonce and then encrypts it with the SRK and then the EK_pub, both of which are provided by the device during the initial registration call. The TPM always keeps the private portion of the EK secure. This prevents counterfeiting and ensures SAS tokens are securely provisioned to authorized devices.
+When a device with a TPM connects to the Device Provisioning Service, the service first checks the provided EK_pub against the EK_pub stored in the enrollment list. If the EK_pubs don't match, the device is not allowed to provision. If the EK_pubs do match, the service then requires the device to prove ownership of the private portion of the EK via a nonce challenge, which is a secure challenge used to prove identity. The Device Provisioning Service generates a nonce and then encrypts it with the SRK and then the EK_pub, both of which are provided by the device during the initial registration call. The TPM always keeps the private portion of the EK secure. This prevents counterfeiting and ensures SAS tokens are securely provisioned to authorized devices.
 
 Let’s walk through the attestation process in detail.
 

articles/iot-dps/concepts-x509-attestation.md

@@ -28,7 +28,7 @@ Often the certificate chain represents a logical or physical hierarchy associate
 * A self-signed root CA certificate begins the certificate chain.
 * The root certificate generates a unique intermediate CA certificate for each factory.
 * Each factory's certificate generates a unique intermediate CA certificate for each production line in the factory.
-* Finally, the production line certificate generates a unique device (end-entity) certificate for each device manufactured on the line.
+* The production line certificate generates a unique device (end-entity) certificate for each device manufactured on the line.
 
 To learn more, see [Conceptual understanding of X.509 CA certificates in the IoT industry](../iot-hub/iot-hub-x509ca-concept.md). 
 
@@ -40,13 +40,13 @@ A *root certificate* is a self-signed X.509 certificate that represents a certif
 
 An *intermediate certificate* is an X.509 certificate that has been signed by the root certificate (or by another intermediate certificate with the root certificate in its chain) and can also sign new certificates. The last intermediate certificate in a chain signs the leaf certificate. An intermediate certificate can also be called an *intermediate CA certificate*.
 
-Intermediate certificates are used in a variety of ways. For example, intermediate certificates can be used to group devices by product lines, customers purchasing devices, company divisions, or factories. 
+Intermediate certificates are used in various ways. For example, intermediate certificates can be used to group devices by product lines, customers purchasing devices, company divisions, or factories. 
 
 Imagine that Contoso is a large corporation with its own Public Key Infrastructure (PKI) using the root certificate named `ContosoRootCert`. Each subsidiary of Contoso has their own intermediate certificate that is signed by `ContosoRootCert`. Each subsidiary uses their intermediate certificate to sign their leaf certificates for each device. In this scenario, Contoso can use a single DPS instance where `ContosoRootCert` is a [verified certificate](./how-to-verify-certificates.md). They can have an enrollment group for each subsidiary. This way each individual subsidiary doesn't have to worry about verifying certificates.
 
 ### End-entity "leaf" certificate
 
-A *leaf certificate*, or *end-entity certificate*, identifies a certificate holder. It has the root certificate in its certificate chain as well as zero or more intermediate certificates. A leaf certificate is not used to sign any other certificates. It uniquely identifies a device to the provisioning service and is sometimes referred to as a *device certificate*. During authentication, a device uses the private key associated with its certificate to respond to a proof of possession challenge from the service.
+A *leaf certificate*, or *end-entity certificate*, identifies a certificate holder. It has the root certificate in its certificate chain and zero or more intermediate certificates. A leaf certificate is not used to sign any other certificates. It uniquely identifies a device to the provisioning service and is sometimes referred to as a *device certificate*. During authentication, a device uses the private key associated with its certificate to respond to a proof of possession challenge from the service.
 
 Leaf certificates used with [individual enrollment](./concepts-service.md#individual-enrollment) entries must have the subject common name (CN) set to the registration ID. The registration ID identifies the device registration with DPS and must be unique to the DPS instance (ID scope) where the device registers.
 
@@ -69,19 +69,19 @@ When DPS enrollments are configured for X.509 attestation, mutual TLS (mTLS) is
 
 ### DPS device chain requirements
 
-When a device is attempting registration through DPS using an enrollment group, the device must send the certificate chain from the leaf certificate to a [verified certificate](how-to-verify-certificates.md). Otherwise, authentication will fail.
+When a device is attempting registration through DPS using an enrollment group, the device must send the certificate chain from the leaf certificate to a [verified certificate](how-to-verify-certificates.md). Otherwise, authentication fails.
 
-For example, if only the root certificate is verified and an intermediate certificate is uploaded to the enrollment group, the device should present the certificate chain from leaf certificate all the way to the verified root certificate. This certificate chain would include any intermediate certificates in-between. Authentication will fail if DPS cannot traverse the certificate chain to a verified certificate.
+For example, if only the root certificate is verified and an intermediate certificate is uploaded to the enrollment group, the device should present the certificate chain from leaf certificate all the way to the verified root certificate. This certificate chain would include any intermediate certificates in-between. Authentication fails if DPS cannot traverse the certificate chain to a verified certificate.
 
 For example, consider a corporation that uses the following device chain for a device.
 
-![Diagram that shows an example device certificate chain](./media/concepts-x509-attestation/example-device-cert-chain.png) 
+![Diagram that shows an example device certificate chain.](./media/concepts-x509-attestation/example-device-cert-chain.png) 
 
 In this example, the root certificate is verified with DPS, and `intermediate2` certificate is uploaded on the enrollment group.
 
 ![Diagram that highlights the root and intermediate 2 certificates as being uploaded to DPS.](./media/concepts-x509-attestation/example-root-verified.png) 
 
-If the device only sends the following device chain during provisioning, authentication will fail. Because DPS can't attempt authentication assuming the validity of `intermediate1` certificate.
+If the device only sends the following device chain during provisioning, authentication fails. Because DPS can't attempt authentication assuming the validity of `intermediate1` certificate.
 
 ![Diagram that shows a certificate chain failing authentication because it doesn't chain to the root.](./media/concepts-x509-attestation/example-fail-cert-chain.png) 
 
@@ -91,7 +91,7 @@ If the device sends the full device chain as follows during provisioning, then D
 
 ### DPS order of operations with certificates
 
-When a device connects to the provisioning service, the service walks its certificate chain beginning with the device (leaf) certificate and looks for a corresponding enrollment entry. It uses the first entry that it finds in the chain to determine whether to provision the device. That is, if an individual enrollment for the device certificate exists, the provisioning service applies that entry. If there isn't an individual enrollment for the device, the service looks for an enrollment group that corresponds to the first intermediate certificate. If it finds one, it applies that entry; otherwise, it looks for an enrollment group for the next intermediate certificate, and so on down the chain to the root.  
+When a device connects to the provisioning service, the service walks its certificate chain beginning with the device (leaf) certificate and looks for a corresponding enrollment entry. It uses the first entry that it finds in the chain to determine whether to provision the device. That is, if an individual enrollment for the device certificate exists, the provisioning service applies that entry. If there isn't an individual enrollment for the device, the service looks for an enrollment group that corresponds to the first intermediate certificate. If it finds one, it applies that entry; otherwise, it looks for an enrollment group for the next intermediate certificate, and so on, down the chain to the root.  
 
 The service applies the first entry that it finds, such that:
 
@@ -101,7 +101,7 @@ The service applies the first entry that it finds, such that:
 
 Each certificate in a device's certificate chain can be specified in an enrollment entry, but it can be specified in only one entry in the DPS instance.
 
-This mechanism and the hierarchical structure of certificate chains provides powerful flexibility in how you can control access for individual devices as well as for groups of devices. For example, imagine five devices with the following certificate chains:
+This mechanism and the hierarchical structure of certificate chains provides powerful flexibility in how you can control access for individual devices and groups of devices. For example, imagine five devices with the following certificate chains:
 
 - *Device 1*: root certificate -> certificate A -> device 1 certificate
 - *Device 2*: root certificate -> certificate A -> device 2 certificate

articles/iot-dps/how-to-manage-enrollments.md

@@ -64,7 +64,7 @@ An individual enrollment is an entry for a single device that may be assigned to
 
 For a walkthrough of how to create and use individual enrollments with X.509 certificates, see [Quickstart:Provision an X.509 certificate device](quick-create-simulated-device-x509.md#create-a-device-enrollment).
 
-To create a X.509 certificate individual enrollment:
+To create an X.509 certificate individual enrollment:
 
 <!-- INCLUDE -->
 [!INCLUDE [iot-dps-individual-enrollment-x509.md](../../includes/iot-dps-individual-enrollment-x509.md)]