fixing links and updates to TOC/Index

ianjmcm · ianjmcm · commit 3dd09a919391 · 2024-04-10T13:10:01.000-04:00
diff --git a/articles/trusted-signing/TOC.yml b/articles/trusted-signing/TOC.yml
@@ -25,4 +25,8 @@
   - name: Concept
     items:
     - name: Trusted Signing trust models
-      href: concept-trusted-signing-trust-models.md
+      href: concept-trusted-signing-trust-models.md
+    - name: Trusted Signing resources and roles
+      href: concept-trusted-signing-resources-roles.md
+    - name: Trusted Signing certificate management
+      href: concept-trusted-signing-cert-management.md
diff --git a/articles/trusted-signing/concept-trusted-signing-cert-management.md b/articles/trusted-signing/concept-trusted-signing-cert-management.md
@@ -32,7 +32,7 @@ For example, if it's determined that a subscriber signed code that was malware o
 
 ### Subscriber Identity Validation Extended Key Usage (EKU)
 
-It's common for x.509 end-entity signing certificates to be renewed. Due to Trusted Signing's *daily certificate renewal*, pinning trust or validation to an end-entity certificate using certificate attributes (for exmaple, the public key) or a certificate's "thumbprint" (hash of the certificate) isn't durable. In addition, subjectDN values can change over the lifetime of an identity or organization.
+It's common for x.509 end-entity signing certificates to be renewed on a regular timeline to ensure key hygiene. Due to Trusted Signing's *daily certificate renewal*, pinning trust or validation to an end-entity certificate using certificate attributes (for exmaple, the public key) or a certificate's "thumbprint" (hash of the certificate) isn't durable. In addition, subjectDN values can change over the lifetime of an identity or organization.
 
 To address these issues, Trusted Signing provides a durable identity value in each certificate that's associated with the Subscription's Identity Validation resource. The durable identity value is a custom EKU that has a prefix of `1.3.6.1.4.1.311.97.` and is followed by additional octet values that are unique to the Identity Validation resource used on the Certificate Profile.
 
diff --git a/articles/trusted-signing/concept-trusted-signing-resources-roles.md b/articles/trusted-signing/concept-trusted-signing-resources-roles.md
@@ -57,7 +57,8 @@ Trusted Signing provides five total Certificate Profile types that all subscribe
     - **VBS Enclave**: Used for signing [Virtualization-based Security Enclaves](https://learn.microsoft.com/windows/win32/trusted-execution/vbs-enclaves) on Windows.
     - **Public Trust Test**: Used for test signing only and aren't publicly trusted by default. Consider Public Trust Test Certificate Profile as a great option for inner loop build signing. 
     
-        **Note**: All certificates under this Certificate Profile type include the Lifetime EKU (1.3.6.1.4.1.311.10.3.13) forcing validation to respect the lifetime of the signing certificate regardless of the presence of a valid time stamp countersignature. 
+        [!NOTE]
+        All certificates under the Public Trust Test Certificate Profile type include the Lifetime EKU (1.3.6.1.4.1.311.10.3.13) forcing validation to respect the lifetime of the signing certificate regardless of the presence of a valid time stamp countersignature. 
 
 - **Private Trust**
     - **Private Trust**: Used for signing internal or private artifacts such as Line of Business (LoB) applications and containers. It can also be used to sign [catalog files for Windows App Control for Business](https://learn.microsoft.com/windows/security/application-security/application-control/windows-defender-application-control/deployment/deploy-catalog-files-to-support-wdac).
diff --git a/articles/trusted-signing/concept-trusted-signing-trust-models.md b/articles/trusted-signing/concept-trusted-signing-trust-models.md
@@ -17,21 +17,19 @@ This article explains the concept of trust models, the primary trust models that
 
 A trust model defines the rules and mechanisms for validating digital signatures and ensuring the security of communications in a digital environment. In other words, trust models define how trust is established and maintained within entities in a digital ecosystem.
 
-For signature consumers like publicly trusted code signing for Microsoft Windows applications, trust models depend on signatures that have certificates from a Certification Authority (CA) that is part of the [Microsoft Root Certificate Program](https://learn.microsoft.com/security/trusted-root/program-requirements). This is because Trusted Signing is designed to support Windows Authenticode signing and security features that use code signing on Windows (e.g. [Smart App Control](https://learn.microsoft.com/windows/apps/develop/smart-app-control/overview) and [Windows Defender Application Control](https://learn.microsoft.com/windows/security/application-security/application-control/windows-defender-application-control/wdac)).
+For signature consumers like publicly trusted code signing for Microsoft Windows applications, trust models depend on signatures that have certificates from a Certification Authority (CA) that is part of the [Microsoft Root Certificate Program](https://learn.microsoft.com/security/trusted-root/program-requirements). This is primarily why Trusted Signing trust models are designed to support Windows Authenticode signing and security features that use code signing on Windows (e.g. [Smart App Control](https://learn.microsoft.com/windows/apps/develop/smart-app-control/overview) and [Windows Defender Application Control](https://learn.microsoft.com/windows/security/application-security/application-control/windows-defender-application-control/wdac)).
 
 Trusted Signing provides two primary trust models to support a wide variety of signature consumption (validations): 
 
-- Public-Trust <add link to #public-trust>
-- Private-Trust <add link to #private-trust>
+- [Public-Trust](#public-trust)
+- [Private-Trust](#private-trust)
 
 [!NOTE]
-Subscribers to Trusted Signing aren't limited to the signing scenarios application of the trust models shared in this article. Trusted Signing was designed to support Windows Authenticode code signing and App Control for Business features in Windows with an ability to broadly support other signing and trust models beyond Windows. 
+Trusted Signing was designed to support Windows Authenticode code signing and Windows Defender Application Control features in Windows with an ability to broadly support other signing and trust models beyond those Windows features. 
 
 ## Public-Trust
 
-Public-Trust is one of the models provided in Trusted Signing and is the most commonly used model. The certificates are issued from a CA that complies with the [CA/Browser Forum's Baseline Requirements for Code-Signing Certificates](https://cabforum.org/working-groups/code-signing/documents/) and is included a relying party's root certificate program such as the [Microsoft Root Certificate Program](https://learn.microsoft.com/security/trusted-root/program-requirements). 
-
-Trusted Signing's Public-Trust Identity Validation and Certificate Profiles are backed by a CA included in the Microsoft Root Certificate Program. The Public-Trust Root CA certificate is [Microsoft Identity Verification Root Certificate Authority 2020](https://www.microsoft.com/pkiops/certs/microsoft%20identity%20verification%20root%20certificate%20authority%202020.crt) and complies with the [Microsoft PKI Services Third Party Certification Practice Statement (CPS)](https://www.microsoft.com/pkiops/docs/repository.htm). 
+Public-Trust is one of the models provided in Trusted Signing and is the most commonly used model. The certificates in the Public-Trust model are issued from the [Microsoft Identity Verification Root Certificate Authority 2020](https://www.microsoft.com/pkiops/certs/microsoft%20identity%20verification%20root%20certificate%20authority%202020.crt) and complies with the [Microsoft PKI Services Third Party Certification Practice Statement (CPS)](https://www.microsoft.com/pkiops/docs/repository.htm). This root CA is included a relying party's root certificate program such as the [Microsoft Root Certificate Program](https://learn.microsoft.com/security/trusted-root/program-requirements) for the usage of code signing and timestamping. 
 
 The Public-Trust resources in Trusted Signing are designed to support the following signing scenarios and security features:
 
@@ -43,7 +41,7 @@ The Public-Trust resources in Trusted Signing are designed to support the follow
 Public-Trust is recommended for signing any artifact that is to be shared publicly and for the signer to be a validated legal organization or individual. 
 
 [!NOTE]
-Trusted Signing includes options for "Test" Certificate Profiles under the Public-Trust collection. These "Test" Certificate Profiles are intended to be used for inner loop dev/test signing and trust only in test environments.
+Trusted Signing includes options for "Test" Certificate Profiles under the Public-Trust collection, but not publicly trusted. These "Test" Certificate Profiles are intended to be used for inner loop dev/test signing and should NOT be trusted.
 
 ## Private-Trust
 
diff --git a/articles/trusted-signing/index.yml b/articles/trusted-signing/index.yml
@@ -41,4 +41,10 @@ landingContent:
       - linkListType: concept
         links:
           - text: What is Signing?
-            url: concept.md
+            url: concept.md
+          - text: Trusted Signing trust models
+            url: concept-trusted-signing-trust-models.md
+          - text: Trusted Signing resources and roles
+            url: concept-trusted-signing-resources-roles.md
+          - text: Trusted Signing certificate management
+            url: concept-trusted-signing-cert-management.md
