Merge pull request #271845 from ianjmcm/trustedsigning-release

Trustedsigning release

Author: Stacyrch140

articles/trusted-signing/TOC.yml

@@ -12,6 +12,10 @@
       href: how-to-signing-integrations.md
     - name: Sign CI Policies with Trusted Signing
       href: how-to-sign-ci-policy.md
+    - name: Access signed transactions in Trusted Signing 
+      href: how-to-sign-history.md
+    - name: Revoke a certificate profile in Trusted Signing
+      href: how-to-cert-revocation.md
   - name: Quickstart
     items:
     - name: Quickstart onboarding
@@ -27,4 +31,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

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.
 

articles/trusted-signing/concept-trusted-signing-resources-roles.md

@@ -56,8 +56,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).

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. 
 
 ## 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:
 
@@ -42,8 +40,8 @@ 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.
+[!NOTE]
+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
 

articles/trusted-signing/how-to-cert-revocation.md

@@ -0,0 +1,61 @@
+---
+title: Revoke a certificate profile in Trusted Signing 
+description: how-to revoke a Trusted Signing certificate from Azure portal. 
+author: mehasharma 
+ms.author: mesharm 
+ms.service: azure-code-signing 
+ms.topic: how-to 
+ms.date: 03/31/2024 
+---
+
+
+
+# Revoke a certificate profile in Trusted Signing
+
+Certificate revocation is an act of invalidating a certificate. Once a certificate is successfully revoked, all the files signed with a revoked certificate become invalid from the selected revocation date and time. 
+
+If the certificate issued to you doesn’t match your intended values or if you suspect any compromise of your account, consider the following steps:
+
+1. **Revoke the Existing Certificate**:
+Revoking the certificate ensures that any compromised or incorrect certificates become invalid.
+Make sure to promptly revoke any certificates that no longer meet your requirements.
+
+2. **Contact Microsoft for Certificate Revocation Requests**:
+- If you encounter any issues revoking a certificate through the Azure portal (especially for non-misuse or nonabuse scenarios), reach out to Microsoft.
+- For any misuse or abuse of certificates issued to you by Trusted Signing, contact Microsoft immediately at [email protected].
+
+3. **To continue signing with Trusted Signing**:
+- Initiate a new Identity Validation request.
+    - Verify that the information in certificate subject preview accurately reflects your intended values. 
+- Create a new certificate profile with newly Completed Identity Validation.
+
+
+Before initiating a certificate revocation, it’s crucial to verify that all the details are accurate and as intended. Once a certificate is revoked, reversing the process isn't possible. Therefore, exercise caution and double-check the information before proceeding with the revocation process. 
+
+Revocation can only be completed in the Azure portal – it can't be completed with Azure CLI.
+
+This tutorial will guide you through the process of revoking a certificate profile from a Trusted Signing account.
+
+## Prerequisites
+- Ensure you have **Owner** role for the Subscription. For RBAC access management, see link to role assignment. 
+
+## Revoke a certificate
+
+Complete these steps to revoke a certificate profile from Trusted Signing:
+
+1.	Sign in to the [Azure portal](https://portal.azure.com/).
+2.	Navigate to your **Trusted Signing account** resource page in the Azure portal.
+3.	Select **certificate profile** from either the Account Overview page or Objects page. 
+4.	Select the relevant certificate profile.
+5.	In the Search box, enter the thumbprint of the certificate to be revoked.  
+•	For example for .cer file, thumbprint can be found on the Details tab. 
+6.	Select the thumbprint, then select **Revoke**. 
+7.	In the **Revocation reason** pull-down menu, select a reason.
+8.	Enter **Revocation date time** (must be within the certification created and expiry date).
+•	 The Revocation date time is converted to your local time zone.
+9.	Enter **Remarks**.
+10.	Select **Revoke**.
+11.	Once the certificate is successfully revoked:
+    - The status is updated for the thumbprint that was revoked.
+    - An email is sent to the email addresses provided during Identity Validation. 
+    

articles/trusted-signing/how-to-sign-ci-policy.md

@@ -1,12 +1,12 @@
 ---
-title: Signing CI Policies #Required; page title is displayed in search results. Include the brand.
-description: Learn how to sign new CI policies with Trusted Signing. #Required; article description that is displayed in search results. 
-author: microsoftshawarma #Required; your GitHub user alias, with correct capitalization.
-ms.author: rakiasegev #Required; microsoft alias of author; optional team alias.
-ms.service: azure-code-signing #Required; service per approved list. slug assigned by ACOM.
-ms.topic: how-to #Required; leave this attribute/value as-is.
-ms.date: 04/04/2024 #Required; mm/dd/yyyy format.
-ms.custom: template-how-to-pattern #Required; leave this attribute/value as-is.
+title: Signing CI Policies 
+description: Learn how to sign new CI policies with Trusted Signing.  
+author: microsoftshawarma 
+ms.author: rakiasegev 
+ms.service: azure-code-signing 
+ms.topic: how-to 
+ms.date: 04/04/2024 
+ms.custom: template-how-to-pattern 
 ---
 
 # Sign CI Policies with Trusted Signing

articles/trusted-signing/how-to-sign-history.md

@@ -0,0 +1,36 @@
+---
+title: Access signed transactions in Trusted Signing 
+description: How-to access signed transactions in Trusted Signing in Azure portal. 
+author: mehasharma 
+ms.author: mesharm 
+ms.service: azure-code-signing 
+ms.topic: how-to 
+ms.date: 04/01/2024 
+---
+
+# Access signed transactions in Trusted Signing
+
+Review the details of the signing requests executed by Trusted Signing in Azure portal. 
+Currently there are four different options enabled:  
+- Log Analytics workspace  
+- Storage Account  
+- Event Hub  
+- Partner Solution   
+
+Following is an example of how to view signing transactions through storage account.
+## Prerequisites:  
+- Ability to create storage accounts in a subscription. (Note: The billing of storage accounts is separate from Trusted Signing resources.)  
+- Sign in to the Azure portal.
+
+## Send signed transactions to storage account 
+Follow the steps to access and send sign transactions to your storage account:  
+1.	Follow this guide to create Storage Accounts, Create a storage account - Azure Storage | Microsoft Learn, in the same region as your trusted signing account (Basic storage account is sufficient)  
+2.	Navigate to your trusted signing account in the Azure portal.
+3.	On the trusted signing account overview page, locate **Diagnostics Settings** under Monitoring section. 
+    1.	Select Diagnostics Settings on the left-side blade and click **+ Add diagnostic setting** link on the left side.
+    2.	From **Diagnostics setting** page, select **Sign Transactions** category and choose ‘Archive to a storage account’ option and select the subscription and Storage account that you newly created or already have. 
+    4.	After selecting subscription & storage account, click **Save**. This action brings you to previous page where it displays list of all diagnostics settings created for this code sign account.  
+    5.	After creating a diagnostic setting, wait for 10-15 mins before the events begin to get ingested to the newly created storage account.  
+    6.	Navigate to the storage account created in step 1. In this example, we will use storage account **storagetestneu1**.  
+    7.	From storage account resource, navigate to **Containers** under **Data storage**. 
+    8.	From the list, select container named **insights-logs-signtransactions** and navigate to the date and time you're looking to download the log.    

articles/trusted-signing/how-to-signing-integrations.md

@@ -1,12 +1,12 @@
 ---
-title: Implement signing integrations with Trusted Signing #Required; page title is displayed in search results. Include the brand.
-description: Learn how to set up signing integrations with Trusted Signing. #Required; article description that is displayed in search results. 
-author: microsoftshawarma #Required; your GitHub user alias, with correct capitalization.
-ms.author: rakiasegev #Required; microsoft alias of author; optional team alias.
-ms.service: azure-code-signing #Required; service per approved list. slug assigned by ACOM.
-ms.topic: how-to #Required; leave this attribute/value as-is.
-ms.date: 04/04/2024 #Required; mm/dd/yyyy format.
-ms.custom: template-how-to-pattern #Required; leave this attribute/value as-is.
+title: Implement signing integrations with Trusted Signing 
+description: Learn how to set up signing integrations with Trusted Signing.  
+author: microsoftshawarma 
+ms.author: rakiasegev 
+ms.service: azure-code-signing 
+ms.topic: how-to
+ms.date: 04/04/2024 
+ms.custom: template-how-to-pattern 
 ---
 
 # Implement Signing Integrations with Trusted Signing
@@ -46,15 +46,15 @@ To download and install SignTool:
 1.	Download the latest version of SignTool + Windows Build Tools NuGet at: [Microsft.Windows.SDK.BuildTools](https://www.nuget.org/packages/Microsoft.Windows.SDK.BuildTools/)
 2.	Install SignTool from Windows SDK (min version: 10.0.2261.755)
 
- Another option is to use the latest nuget.exe to download and extract the latest SDK Build Tools NuGet package by completing the following steps (PowerShell):
+ Another option is to use the latest `nuget.exe` to download and extract the latest SDK Build Tools NuGet package by completing the following steps (PowerShell):
 
-1.	Download nuget.exe by running the following download command:  
+1.	Download `nuget.exe` by running the following download command:  
 
 ```
 Invoke-WebRequest -Uri https://dist.nuget.org/win-x86-commandline/latest/nuget.exe -OutFile .\nuget.exe  
 ```
 
-2.	Install nuget.exe by running the following install command:
+2.	Install `nuget.exe` by running the following install command:
 ```
 .\nuget.exe install Microsoft.Windows.SDK.BuildTools -Version 10.0.20348.19 
 ```
@@ -122,4 +122,5 @@ This section explains how to set up other not [SignTool](#set-up-signtool-with-t
 
 * Azure PowerShell: App Control for Business CI Policy – To use Trusted Signing for CI policy signing follow the instructions at [Signing a New CI policy](./how-to-sign-ci-policy.md) and visit the [Az.CodeSigning PowerShell Module](/powershell/azure/install-azps-windows).
 
-* Trusted Signing SDK – To create your own signing integration our [Trusted Signing SDK](https://www.nuget.org/packages/Azure.CodeSigning.Sdk) is publicly available.
+* Trusted Signing SDK – To create your own signing integration our [Trusted Signing SDK](https://www.nuget.org/packages/Azure.CodeSigning.Sdk) is publicly available.
+

articles/trusted-signing/index.yml

@@ -30,6 +30,12 @@ landingContent:
         links:
           - text: Sign CI Policies with Trusted Signing
             url: how-to-sign-ci-policy.md
+          - text: Signing Integrations with Trusted Signing
+            url: how-to-signing-integrations.md
+          - text: Access signed transactions in Trusted Signing 
+            url: how-to-sign-history.md
+          - text: Revoke a certificate profile in Trusted Signing
+            url: how-to-cert-revocation.md
   - title: Overview
     linkLists:
         - linkListType: overview
@@ -46,5 +52,9 @@ landingContent:
     linkLists:
       - linkListType: concept
         links:
-          - text: What is Signing?
-            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