addressing feedback

Author: ianjmcm

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

@@ -42,9 +42,10 @@ A `1.3.6.1.4.1.311.97.990309390.766961637.194916062.941502583` value indicates a
 - **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.
+[!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.
+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
 
@@ -53,9 +54,10 @@ Trusted Signing aims to simplify signing as much as possible for subscribers usi
 - 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").
+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.
+[!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
 
@@ -71,7 +73,7 @@ Trusted Signing passionately supports a healthy ecosystem by using active threat
 
 - 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.
+- 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
 

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

@@ -18,7 +18,7 @@ This article introduces you to the resources and roles that are specific to Trus
 ## 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. There are two account tiers available, Basic or Premium, depending on the number of signatures and Certificate Profiles needed for each type.
+- **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. 
 
@@ -28,34 +28,15 @@ In the below example structure, notice that an Azure Subscription has a Resource
 
 ![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). 
+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).
+[!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. There are two tiers: Basic and Premium. 
-
-Here are the attributes of Basic and Premium Trusted Signing Account tiers:
-
-||Basic|Premium
-|---------------|---------------|-----------------|
-|**Signature quota**|5,000 per month|100,000 per month|
-|**Price**| $9.99 USD/month| $99.99 USD/month|
-|**Price after quota is reached**|$0.005/signature|$0.005/signature|
-|**Certificate Profiles**| 1 of each type available| 10 of each type available|
-||||
-
-Subscribers must choose the tier that works best for their needs in signing. To help make this decision, subscribers can answer two simple questions:
-
-1. How many signatures do I need to use per month?
-2. Do I need more than 1 of any of the Certificate Profile types?
-
-The answer to the first question is defined by the number of artifacts in total needed to be signed in a month. Consider that one binary executable (.EXE/.DLL) is 1 signature, but a package such as an MSIX may contain minimally 2 signatures. If your per month estimated signature needs are below 5000 signatures, the Basic account tier is a good fit. However, if you're more in the range of hundreds of thousands of signatures per month, a Premium account tier is likely the better fit. Consider the costs of going over an account's quota and what best fits your needs. 
-
-**Note**: 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 and billing. 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.
+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
 
@@ -97,7 +78,7 @@ Azure Role Based Access Controls (RBAC) is a cornerstone concept for all Azure r
 |User Access Admin|||||X||
 ||||||||
 
-<sub>1</sub> Required to create/manage Identity Validation only available on the Azure Portal experience. 
+<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.
 

articles/trusted-signing/concept-trusted-signing-trust-models.md

@@ -24,7 +24,8 @@ Trusted Signing provides two primary trust models to support a wide variety of s
 - Public-Trust <add link to #public-trust>
 - Private-Trust <add link to #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. 
+[!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
 
@@ -41,7 +42,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. These "Test" Certificate Profiles are intended to be used for inner loop dev/test signing and trust only in test environments.
 
 ## Private-Trust