Add explicit mentions of mTLS support

Author: JimacoMS4

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

@@ -18,16 +18,16 @@ X.509 certificates can be stored in a hardware security module HSM.
 > [!TIP]
 > We strongly recommend using an HSM with devices to securely store secrets, like the X.509 certificate, on your devices in production.
 
-
 ## X.509 certificates
 
 Using X.509 certificates as an attestation mechanism is an excellent way to scale production and simplify device provisioning. X.509 certificates are typically arranged in a certificate chain of trust in which each certificate in the chain is signed by the private key of the next higher certificate, and so on, terminating in a self-signed root certificate. This arrangement establishes a delegated chain of trust from the root certificate generated by a trusted root certificate authority (CA) down through each intermediate CA to the end-entity "leaf" certificate installed on a device. To learn more, see [Device Authentication using X.509 CA Certificates](../iot-hub/iot-hub-x509ca-overview.md). 
 
 Often the certificate chain represents some logical or physical hierarchy associated with devices. For example, a manufacturer may:
+
 - issue a self-signed root CA certificate
 - use the root certificate to generate a unique intermediate CA certificate for each factory
 - use each factory's certificate to generate a unique intermediate CA certificate for each production line in the plant
-- and finally use the production line certificate, to generate a unique device (end-entity) certificate for each device manufactured on the line. 
+- and finally use the production line certificate, to generate 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). 
 
@@ -39,12 +39,12 @@ A root certificate is a self-signed X.509 certificate representing a certificate
 
 An intermediate certificate is an X.509 certificate, which has been signed by the root certificate (or by another intermediate certificate with the root certificate in its chain). The last intermediate certificate in a chain is used to sign the leaf certificate. An intermediate certificate can also be referred to as an intermediate CA certificate.
 
-##### Why are intermediate certs useful?
+#### Why are intermediate certs useful?
+
 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. 
 
 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 will then use their intermediate certificate to sign their leaf certificates for each device. In this scenario, Contoso can use a single DPS instance where *ContosoRootCert* has been verified with [proof-of-possession](./how-to-verify-certificates.md). They can have an enrollment group for each subsidiary. This way each individual subsidiary will not have to worry about verifying certificates.
 
-
 ### End-entity "leaf" certificate
 
 The leaf certificate, or end-entity certificate, identifies the certificate holder. It has the root certificate in its certificate chain as well as zero or more intermediate certificates. The leaf certificate is not used to sign any other certificates. It uniquely identifies the device to the provisioning service and is sometimes referred to as the device certificate. During authentication, the device uses the private key associated with this certificate to respond to a proof of possession challenge from the service.
@@ -62,7 +62,11 @@ The provisioning service exposes two enrollment types that you can use to contro
 - [Individual enrollment](./concepts-service.md#individual-enrollment) entries are configured with the device certificate associated with a specific device. These entries control enrollments for specific devices.
 - [Enrollment group](./concepts-service.md#enrollment-group) entries are associated with a specific intermediate or root CA certificate. These entries control enrollments for all devices that have that intermediate or root certificate in their certificate chain. 
 
-#### DPS device chain requirements
+### Mutual TLS support
+
+When DPS enrollments are configured for X.509 attestation, mutual TLS (mTLS) is supported by DPS.
+
+### 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 certificate verified with [proof-of-possession](how-to-verify-certificates.md). Otherwise, authentication will fail.
 
@@ -84,14 +88,11 @@ If the device sends the full device chain as follows during provisioning, then D
 
 ![Example device certificate chain](./media/concepts-x509-attestation/example-device-cert-chain.png) 
 
-
-
-
 > [!NOTE]
 > Intermediate certificates can also be verified with [proof-of-possession](how-to-verify-certificates.md)..
 
+### DPS order of operations with certificates
 
-#### DPS order of operations with certificates
 When a device connects to the provisioning service, the service prioritizes more specific enrollment entries over less specific enrollment entries. That is, if an individual enrollment for the device exists, the provisioning service applies that entry. If there is no individual enrollment for the device and an enrollment group for the first intermediate certificate in the device's certificate chain exists, the service applies that entry, and so on, down the chain to the root. The service applies the first applicable entry that it finds, such that:
 
 - If the first enrollment entry found is enabled, the service provisions the device.

articles/iot-dps/tls-support.md

@@ -13,7 +13,8 @@
 
 DPS uses [Transport Layer Security (TLS)](http://wikipedia.org/wiki/Transport_Layer_Security) to secure connections from IoT devices. 
 
-Current TLS protocol versions supported by DPS are: 
+Current TLS protocol versions supported by DPS are:
+
 * TLS 1.2
 
 ## Restrict connections to TLS 1.2
@@ -57,7 +58,6 @@ The DPS resource created using this configuration will refuse devices that attem
 > [!NOTE]
 > The `minTlsVersion` property is read-only and cannot be changed once your DPS resource is created. It is therefore essential that you properly test and validate that *all* your IoT devices are compatible with TLS 1.2 and the [recommended ciphers](#recommended-ciphers) in advance.
 
-
 > [!NOTE]
 > Upon failovers, the `minTlsVersion` property of your DPS will remain effective in the geo-paired region post-failover.
 
@@ -70,8 +70,7 @@ DPS instances that are configured to accept only TLS 1.2 will also enforce the u
 | :--- |
 | `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384`<br>`TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256`<br>`TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384`<br>`TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256` |
 
-
-### Legacy cipher suites 
+### Legacy cipher suites
 
 These cipher suites are currently still supported by DPS but will be depreciated. Use the recommended cipher suites above if possible.
 
@@ -83,6 +82,9 @@ These cipher suites are currently still supported by DPS but will be depreciated
 | :--- |
 | `TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256   (uses SHA-1)`<br>`TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384   (uses SHA-1)`<br>`TLS_RSA_WITH_AES_128_GCM_SHA256           (lack of Perfect Forward Secrecy)`<br>`TLS_RSA_WITH_AES_256_GCM_SHA384           (lack of Perfect Forward Secrecy)`<br>`TLS_RSA_WITH_AES_128_CBC_SHA256           (lack of Perfect Forward Secrecy)`<br>`TLS_RSA_WITH_AES_256_CBC_SHA256           (lack of Perfect Forward Secrecy)`<br>`TLS_RSA_WITH_AES_128_CBC_SHA              (uses SHA-1, lack of Perfect Forward Secrecy)`<br>`TLS_RSA_WITH_AES_256_CBC_SHA              (uses SHA-1, lack of Perfect Forward Secrecy)` |
 
+## Mutual TLS support
+
+When DPS enrollments are configured for X.509 authentication, mutual TLS (mTLS) is supported by DPS.
 
 ## Use TLS 1.2 in the IoT SDKs