Merge pull request #271241 from ianjmcm/trustedsigning-release

adding concept files

Author: American-Dipper

.openpublishing.redirection.json

@@ -3969,6 +3969,11 @@
             "source_path_from_root":"/articles/virtual-network-manager/concept-security-admin-rules-network-groups.md",
             "redirect_url":"/azure/virtual-network-manager/overview",
             "redirect_document_id":false 
+        },
+        {
+            "source_path_from_root":"/articles/trusted-signing/concept.md",
+            "redirect_url":"/azure/trusted-signing/concept-trustedsigning-resources-roles",
+            "redirect_document_id":false 
         }
     ]
 }

articles/trusted-signing/TOC.yml

@@ -26,5 +26,5 @@
       href: faq.yml
   - name: Concept
     items:
-    - name: Signing concepts
-      href: concept.md
+    - name: Trusted Signing trust models
+      href: concept-trusted-signing-trust-models.md

articles/trusted-signing/concept-trusted-signing-cert-management.md

@@ -0,0 +1,80 @@
+---
+title: Trusted Signing certificate management
+description: Learn about the certificates used in Trusted Signing, including the two unique certificate attributes, the zero-touch certificate lifecycle management process, and most effective ways to manage the certificates.
+author: ianjmcm
+ms.author: ianmcm
+ms.service: azure-code-signing
+ms.topic: concept-article
+ms.date: 04/03/2024
+ms.custom: template-concept
+---
+
+# Trusted Signing certificate management
+
+The certificates used in the Trusted Signing service follow standard practices for x.509 code signing certificates. To support a healthy ecosystem, the service includes a fully managed experience for the x.509 certificates and asymmetric keys used for signing. This fully managed experience automatically provides the necessary certificate lifecycle actions for all certificates used under a customer's Certificate Profile resource in Trusted Signing.
+
+This article explains the Trusted Signing certificates, including their two unique attributes, the zero-touch lifecycle management process, the importance of timestamp countersignatures, and our active threat monitoring and revocation actions.
+
+## Certificate attributes
+
+Trusted Signing uses the Certificate Profile resource type to create and manage x.509 V3 certificates that Trusted Signing customers use for signing. The certificates conform with the RFC 5280 standard and relevant Microsoft PKI Services Certificate Policy (CP) and Certification Practice Statements (CPS) found on [PKI Repository - Microsoft PKI Services](https://www.microsoft.com/pkiops/docs/repository.htm).
+
+In addition to the standard features, the certificates also include the following two unique features to help mitigate risks and impacts associated with misuse/abuse:
+
+- Short-lived certificates
+- Subscriber Identity Validation Extended Key Usage (EKU) for durable identity pinning
+
+### Short-lived certificates
+
+To help reduce the impact of signing misuse and abuse, Trusted Signing certificates are renewed daily and are only valid for 72 hours. These short-lived certificates enable revocation actions to be as acute as a single day or as broad as needed, to cover any incidents of misuse and abuse.
+
+For example, if it's determined that a subscriber signed code that was malware or PUA (Potentially Unwanted Application) as defined by [How Microsoft identifies malware and potentially unwanted applications](https://learn.microsoft.com/microsoft-365/security/defender/criteria), the revocation actions can be isolated to only revoking the certificate that signed the malware or PUA. Thus, the revocation only impacts the code that was signed with that certificate, on the day it was issued, and not any of the code signed prior to or after that day.
+
+### 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.
+
+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.
+
+- **Public-Trust Identity Validation example**:
+A `1.3.6.1.4.1.311.97.990309390.766961637.194916062.941502583` value indicates a Trusted Signing subscriber using Public-Trust Identity Validation. The `1.3.6.1.4.1.311.97.` prefix is Trusted Signing's Public-Trust code signing type and the `990309390.766961637.194916062.941502583` value is unique to the subscriber's Identity Validation for Public-Trust.
+
+- **Private-Trust Identity Validation example**:
+A  `1.3.6.1.4.1.311.97.1.3.1.29433.35007.34545.16815.37291.11644.53265.56135` value indicates a Trusted Signing subscriber using Private-Trust Identity Validation. The `1.3.6.1.4.1.311.97.1.3.1.` prefix is Trusted Signing's Private-Trust code signing type and the `29433.35007.34545.16815.37291.11644.53265.56135` is unique to the subscriber's Identity Validation for Private Trust. Because Private-Trust Identity Validations can be used for WDAC CI Policy signing, there's also a slightly different EKU prefix: `1.3.6.1.4.1.311.97.1.4.1.`. However, the suffix values match the durable identity value for the subscriber's Identity Validation for Private Trust.  
+
+>[!NOTE]
+>The durable identity EKUs can be used in WDAC CI Policy settings to pin trust to an identity in Trusted Signing accordingly. Refer to [Use signed policies to protect Windows Defender Application Control against tampering](https://learn.microsoft.com/windows/security/application-security/application-control/windows-defender-application-control/deployment/use-signed-policies-to-protect-wdac-against-tampering) and [Windows Defender Application Control Wizard](https://learn.microsoft.com/windows/security/application-security/application-control/windows-defender-application-control/design/wdac-wizard) for WDAC Policy creation.
+
+All Trusted Signing Public Trust certificates also contain the `1.3.6.1.4.1.311.97.1.0` EKU to be easily identified as a publicly trusted certificate from Trusted Signing. All EKUs are in addition to the Code Signing EKU (`1.3.6.1.5.5.7.3.3`) to identify the specific usage type for certificate consumers. The only exception is certificates from CI Policy Certificate Profile types, where no Code Signing EKU is present.
+
+## Zero-touch certificate lifecycle management
+
+Trusted Signing aims to simplify signing as much as possible for subscribers using a zero-touch certificate lifecycle management process. A major part of simplifying signing is to provide a fully automated certificate lifecycle management solution. This is where Trusted Signing's Zero-Touch Certificate Lifecycle Management feature handles all of the standard actions automatically for the subscribers. This includes:
+
+- Secure key generation, storage, and usage in FIPS 140-2 Level 3 hardware crypto modules managed by the service.
+- Daily renewals of the certificates to ensure subscribers always have a valid certificate to sign with for their Certificate Profile resources.
+
+Every certificate created and issued is logged for subscribers in the Azure portal and logging data feeds, including the serial number, thumbprint, created date, expiry date, and status (for example, "Active", "Expired", or "Revoked").
+
+>[!NOTE]
+>Trusted Signing does NOT support subscribers importing or exporting private keys and certificates. All certificates and keys used in Trusted Signing are managed inside FIPS 140-2 Level 3 operated hardware crypto modules.
+
+### Time stamp countersignatures
+
+The standard practice in signing is to countersign all signatures with an RFC3161 compliant time stamp. Since Trusted Signing uses short-lived certificates, the importance of time stamp countersigning is imperative to the signatures being valid beyond the life of the signing certificate. This is because a time stamp countersignature provides a cryptographically secure time stamp token from a Time Stamp Authority that meets standard requirements in the CSBRs.
+
+The countersignature provides a reliable date and time of when the signing occurred, so if the time stamp countersign is inside the signing certificate's validity period (and the Time Stamp Authority certificate's validity period) the signature is valid even long after the signing (and Time Stamp Authority) certificates have expired (unless either are revoked).
+
+Trusted Signing provides a generally available Time Stamp Authority endpoint at `http://acs.timestamp.microsoft.com`. We recommend that all Trusted Signing subscribers leverage this Time Stamp Authority endpoint for countersigning any signatures they're producing.
+
+### Active monitoring
+
+Trusted Signing passionately supports a healthy ecosystem by using active threat intelligence monitoring to constantly look for cases of misuse and abuse of Trusted Signing subscribers' Public Trust certificates.
+
+- If there's a confirmed case of misuse or abuse, Trusted Signing immediately completes the necessary steps to mitigate and remediate any threats, including targeted or broad certificate revocation and account suspension.
+
+- Subscribers can also complete revocation actions directly from the Azure portal for any certificates that are logged under a Certificate Profile they own.
+
+## Next steps
+
+- Get started with Trusted Signing's [Quickstart Guide](./quickstart.md).

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

@@ -0,0 +1,90 @@
+---
+title: Trusted Signing resources and roles
+description: Trusted Signing is a Microsoft fully managed end-to-end signing solution that simplifies the signing process for Azure developers. Learn all about the resources and roles specific to Trusted Signing, such as identity validations, certificate profiles, and the code signing identity verifier.
+author: ianjmcm
+ms.author: ianmcm
+ms.service: azure-code-signing
+ms.topic: concept-article
+ms.date: 04/03/2024
+ms.custom: template-concept
+---
+
+# Trusted Signing resources and roles
+
+Trusted Signing is an Azure native resource with full support for common Azure concepts such as resources. As with all other Azure Resource, Trusted Signing also has its own set of resources and roles designed to simplify the management of the service. 
+
+This article introduces you to the resources and roles that are specific to Trusted Signing.
+
+## Trusted Signing Resource Types
+Trusted Signing has the following resource types: 
+
+- **Trusted Signing Account**: The account is a logical container of all the subscriber's resources to complete signing and manage access controls to those sensitive resources. 
+
+- **Certificate Profile**: Certificate Profiles are the configuration attributes that generate the certificates you use to sign code. They also define the trust model and scenario signed content is consumed under by relying parties. Signing roles are assigned to this resource to authorize identities in the tenant to request signing. A prerequisite for creating any Certificate Profile is to have at least one Identity Validation request completed. 
+
+- **Identity Validation**: Identity Validation performs verification of your organization or individual identity before you can sign code. The verified organization or individual identity is the source of the attributes for your Certificate Profiles' SubjectDN values (for example, "CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US"). Identity validation roles are assigned to identities in the tenant to create these resources.
+
+In the below example structure, notice that an Azure Subscription has a Resource Group. Under the Resource Group you can have one or many Trusted Signing Account resources with one or many Identity Validations and Certificate Profiles. 
+
+![Diagram of Trusted Signing resource group and cert profiles](./media/trusted-signing-resource-structure.png)
+
+This ability to have multiple Code Signing Accounts and Certificate Profiles is useful as the service supports Public Trust, Private Trust, CI Policy, VBS Enclave, and Test signing types. For more information on the Certificate Profile types and how they're used, review [Trusted Signing certificate types and management](./concept-trusted-signing-cert-management.md). 
+
+> [!NOTE]
+> Identity Validations and Certificate Profiles align with either Public or Private Trust. Meaning that a Public Trust Identity Validation is only used for Certificate Profiles that are used for the Public Trust model. For more information, review [Trusted Signing trust models](./concept-trusted-signing-trust-models.md).
+
+### Trusted Signing account
+
+The Trusted Signing account is a logical container of the resources that are used to do signing. Trusted Signing accounts can be used to define boundaries of a project or organization. For most, a single Trusted Signing account can satisfy all the signing needs for an individual or organization. Subscribers can sign many artifacts all distributed by the same identity (for example, "Contoso News, LLC"), but operationally, there may be boundaries the subscriber wants to draw in terms of access to signing. You may choose to have a Trusted Signing account per product or per team to isolate usage of an account. However, this isolation pattern can also be achieved at the Certificate Profile level.
+
+### Identity Validations
+
+Identity Validations are all about establishing the identity on the certificates that are used for signing.  There are two types: Private Trust and Public Trust. These two types are defined by the level of identity validation that's required to complete the creation of an Identity Validation resource. 
+
+**Private Trust** is intended for use in situations where there's an established trust in a private identity across one or many relying parties (consumers of signatures) or internally in app control or Line of Business (LoB) scenarios. With Private Trust Identity Validations, there's minimal verification of the identity attributes (for example, Organization Unit value) and it's tightly associated with the Azure Tenant of the subscriber (for example, Costoso.onmicrosoft.com). The values inputted for Private Trust are otherwise not validated beyond the Azure Tenant information. 
+
+**Public Trust** means that all identity values must be validated in accordance to our [Microsoft PKI Services Third Party Certification Practice Statement (CPS)](https://www.microsoft.com/pkiops/docs/repository.htm). This aligns with the expectations for publicly trusted code signing certificates. 
+
+For more details on Private and Public Trust, review [Trusted Signing trust models](./concept-trusted-signing-trust-models.md). 
+
+### Certificate Profiles
+
+Trusted Signing provides five total Certificate Profile types that all subscribers can use with the aligned and completed Identity Validation resources. These five Certificate Profiles are aligned to Public or Private Trust Identity Validations as follows:
+
+- **Public Trust**
+    - **Public Trust**: Used for signing code and artifacts that can be publicly distributed. It's default trusted on the Windows platform for code signing. 
+    - **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. 
+
+- **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).
+    - **Private Trust CI Policy**: The Private Trust CI Policy Certificate Profile is the only type that does NOT include the Code Signing EKU (1.3.6.1.5.5.7.3.3). It's specifically designed for [signing Windows App Control for Business CI policy files](https://learn.microsoft.com/windows/security/application-security/application-control/windows-defender-application-control/deployment/use-signed-policies-to-protect-wdac-against-tampering). 
+ 
+
+## Supported roles
+
+Azure Role Based Accesfnotes Controls (RBAC) is a cornerstone concept for all Azure resources. Trusted Signing adds two custom roles to meet subscribers’ needs for creating an Identity Validation (Code Signing Identity Verifier) and signing with Certificate Profiles (Code Signing Certificate Profile Signer). These custom roles explicitly must be assigned to perform those two critical functions in using Trusted Signing. Below is a complete list of roles Trusted Signing supports and their capabilities, including all standard Azure roles.
+
+|Role|Managed/View Account|Manage Certificate Profiles|Sign with Certificate Profile|View Signing History|Manage Role Assignment|Manage Identity Validation|
+|---------------|---------------|-----------------|-----------------|-----------------|-----------------|-----------------|
+|Code Signing Identity Verifier<sub>1</sub>||||||X|
+|Code Signing Certificate Profile Signer<sub>2</sub>|||X|X|||
+|Owner|X|X|||X||
+|Contributor|X|X|||||
+|Reader|X||||||
+|User Access Admin|||||X||
+||||||||
+
+<sub>1</sub> Required to create/manage Identity Validation only available on the Azure portal experience. 
+
+<sub>2</sub> Required to successfully sign with Trusted Signing.
+
+## Next steps
+
+* Get started with [Trusted Signing's Quickstart Guide](./quickstart.md).
+* Review the [Trusted Signing Trust Models](./concept-trusted-signing-trust-models.md) concept.
+* Review the [Trusting Signing certificates and management](./concept-trusted-signing-cert-management.md) concept.
+