Updates

Author: msmbaldwin

articles/key-vault/general/logging.md

@@ -68,7 +68,7 @@ The following table lists the field names and descriptions:
 | **durationMs** |Time it took to service the REST API request, in milliseconds. The time does not include the network latency, so the time you measure on the client side might not match this time. |
 | **callerIpAddress** |IP address of the client that made the request. |
 | **correlationId** |An optional GUID that the client can pass to correlate client-side logs with service-side (Key Vault) logs. |
-| **identity** | Identity from the token that was presented in the REST API request. Usually a "user," a "service principal," or the combination "user+appId", for instance when the request comes from a Azure PowerShell cmdlet. |
+| **identity** | Identity from the token that was presented in the REST API request. Usually a "user," a "service principal," or the combination "user+appId", for instance when the request comes from an Azure PowerShell cmdlet. |
 | **properties** |Information that varies based on the operation (**operationName**). In most cases, this field contains client information (the user agent string passed by the client), the exact REST API request URI, and the HTTP status code. In addition, when an object is returned as a result of a request (for example, **KeyCreate** or **VaultGet**), it also contains the key URI (as `id`), vault URI, or secret URI. |
 
 The **operationName** field values are in *ObjectVerb* format. For example:
@@ -188,7 +188,7 @@ The following table lists the **operationName** values and corresponding REST AP
 
 ## Use Azure Monitor logs
 
-You can use the Key Vault solution in Azure Monitor logs to review Key Vault `AuditEvent` logs. In Azure Monitor logs, you use log queries to analyze data and get the information you need. 
+You can use the Key Vault solution in Azure Monitor logs to review Key Vault `AuditEvent` logs. In Azure Monitor logs, you use log queries to analyze data and get the information you need.
 
 For more information, including how to set it up, see [Azure Key Vault in Azure Monitor](../key-vault-insights-overview.md).
 

articles/key-vault/general/troubleshooting-access-issues.md

@@ -15,21 +15,21 @@ ms.topic: how-to
 
 ### I'm not able to list or get secrets/keys/certificate. I'm seeing a "something went wrong" error
 
-If you are having problem with listing/getting/creating or accessing secret, make sure that you have access policy defined to do that operation: [Key Vault Access Policies](./assign-access-policy-cli.md)
+If you're having problem with listing/getting/creating or accessing secret, make sure that you have access policy defined to do that operation: [Key Vault Access Policies](./assign-access-policy-cli.md)
 
 ### How can I identify how and when key vaults are accessed?
 
 After you create one or more key vaults, you'll likely want to monitor how and when your key vaults are accessed, and by whom. You can do monitoring by enabling logging for Azure Key Vault, for step-by-step guide to enable logging, [read more](./logging.md).
 
 ### How can I monitor vault availability, service latency periods or other performance metrics for key vault?
 
-As you start to scale your service, the number of requests sent to your key vault will rise. Such demand has a potential to increase the latency of your requests and in extreme cases, cause your requests to be throttled which will impact the performance of your service. You can monitor key vault performance metrics and get alerted for specific thresholds, for step-by-step guide to configure monitoring, [read more](./alert.md).
+As you start to scale your service, the number of requests sent to your key vault will rise. Such demand has a potential to increase the latency of your requests and in extreme cases, cause your requests to be throttled which will degrade the performance of your service. You can monitor key vault performance metrics and get alerted for specific thresholds, for step-by-step guide to configure monitoring, [read more](./alert.md).
 
 ### I'm not able to modify access policy, how can it be enabled?
 
 The user needs to have sufficient Azure AD permissions to modify access policy. In this case, the user would need to have higher contributor role.
 
-### I am seeing 'Unknown Policy' error. What does that mean?
+### I'm seeing 'Unknown Policy' error. What does that mean?
 
 There are two reasons why you may see an access policy in the Unknown section:
 
@@ -57,7 +57,7 @@ The application also needs at least one Identity and Access Management (IAM) rol
 
 ### How can I redeploy Key Vault with ARM template without deleting existing access policies?
 
-Currently Key Vault redeployment deletes any access policy in Key Vault and replaces them with access policy in ARM template. There is no incremental option for Key Vault access policies. To preserve access policies in Key Vault, you need to read existing access policies in Key Vault and populate ARM template with those policies to avoid any access outages.
+Currently Key Vault redeployment deletes any access policy in Key Vault and replaces them with access policy in ARM template. There's no incremental option for Key Vault access policies. To preserve access policies in Key Vault, you need to read existing access policies in Key Vault and populate ARM template with those policies to avoid any access outages.
 
 Another option that can help for this scenario is using Azure RBAC and roles as an alternative to access policies. With Azure RBAC, you can redeploy the key vault without specifying the policy again. You can read more this solution [here](./rbac-guide.md).
 

articles/key-vault/keys/about-keys-details.md

@@ -14,7 +14,7 @@ ms.author: mbaldwin
 
 # Key types, algorithms, and operations
 
-Key Vault supports two resource types: vaults and managed HSMs. Both resources types support various encryption keys. To see a summary of supported key types, protection types by each resource type, please see [About keys](about-keys.md).
+Key Vault supports two resource types: vaults and managed HSMs. Both resources types support various encryption keys. To see a summary of supported key types, protection types by each resource type, see [About keys](about-keys.md).
 
 Following table shows a summary of key types and supported algorithms.
 
@@ -77,7 +77,7 @@ Following table shows a summary of key types and supported algorithms.
 Key Vault, including Managed HSM, supports the following operations on key objects:  
 
 - **Create**: Allows a client to create a key in Key Vault. The value of the key is generated by Key Vault and stored, and isn't released to the client. Asymmetric keys may be created in Key Vault.  
-- **Import**: Allows a client to import an existing key to Key Vault. Asymmetric keys may be imported to Key Vault using a number of different packaging methods within a JWK construct. 
+- **Import**: Allows a client to import an existing key to Key Vault. Asymmetric keys may be imported to Key Vault using several different packaging methods within a JWK construct. 
 - **Update**: Allows a client with sufficient permissions to modify the metadata (key attributes) associated with a key previously stored within Key Vault.  
 - **Delete**: Allows a client with sufficient permissions to delete a key from Key Vault.  
 - **List**: Allows a client to list all keys in a given Key Vault.  
@@ -92,7 +92,7 @@ For more information, see [Key operations in the Key Vault REST API reference](/
 
 Once a key has been created in Key Vault, the following cryptographic operations may be performed using the key:  
 
-- **Sign and Verify**: Strictly, this operation is "sign hash" or "verify hash", as Key Vault doesn't support hashing of content as part of signature creation. Applications should hash the data to be signed locally, then request that Key Vault sign the hash. 
+- **Sign and Verify**: Strictly, this operation is "sign hash" or "verify hash", as Key Vault doesn't support hashing of content as part of signature creation. Applications should hash the data to be signed locally, then request that Key Vault sign the hash.
 Verification of signed hashes is supported as a convenience operation for applications that may not have access to [public] key material. For best application performance, VERIFY operations should be performed locally.  
 - **Key Encryption / Wrapping**: A key stored in Key Vault may be used to protect another key, typically a symmetric content encryption key (CEK). When the key in Key Vault is asymmetric, key encryption is used. For example, RSA-OAEP and the WRAPKEY/UNWRAPKEY operations are equivalent to ENCRYPT/DECRYPT. When the key in Key Vault is symmetric, key wrapping is used. For example, AES-KW. The WRAPKEY operation is supported as a convenience for applications that may not have access to [public] key material. For best application performance, WRAPKEY operations should be performed locally.  
 - **Encrypt and Decrypt**: A key stored in Key Vault may be used to encrypt or decrypt a single block of data. The size of the block is determined by the key type and selected encryption algorithm. The Encrypt operation is provided for convenience, for applications that may not have access to [public] key material. For best application performance, ENCRYPT operations should be performed locally.  
@@ -116,11 +116,11 @@ Key vault key auto-rotation can be set by configuring key auto-rotation policy.
 
 In addition to the key material, the following attributes may be specified. In a JSON Request, the attributes keyword and braces, '{' '}', are required even if there are no attributes specified.  
 
-- *enabled*: boolean, optional, default is **true**. Specifies whether the key is enabled and useable for cryptographic operations. The *enabled* attribute is used in conjunction with *nbf* and *exp*. When an operation occurs between *nbf* and *exp*, it will only be permitted if *enabled* is set to **true**. Operations outside the *nbf* / *exp* window are automatically disallowed, except for certain operation types under [particular conditions](#date-time-controlled-operations).
+- *enabled*: boolean, optional, default is **true**. Specifies whether the key is enabled and useable for cryptographic operations. The *enabled* attribute is used with *nbf* and *exp*. When an operation occurs between *nbf* and *exp*, it will only be permitted if *enabled* is set to **true**. Operations outside the *nbf* / *exp* window are automatically disallowed, except for certain operation types under [particular conditions](#date-time-controlled-operations).
 - *nbf*: IntDate, optional, default is now. The *nbf* (not before) attribute identifies the time before which the key MUST NOT be used for cryptographic operations, except for certain operation types under [particular conditions](#date-time-controlled-operations). The processing of the *nbf* attribute requires that the current date/time MUST be after or equal to the not-before date/time listed in the *nbf* attribute. Key Vault MAY provide for some small leeway, normally no more than a few minutes, to account for clock skew. Its value MUST be a number containing an IntDate value.  
 - *exp*: IntDate, optional, default is "forever". The *exp* (expiration time) attribute identifies the expiration time on or after which the key MUST NOT be used for cryptographic operation, except for certain operation types under [particular conditions](#date-time-controlled-operations). The processing of the *exp* attribute requires that the current date/time MUST be before the expiration date/time listed in the *exp* attribute. Key Vault MAY provide for some small leeway, typically no more than a few minutes, to account for clock skew. Its value MUST be a number containing an IntDate value.  
 
-There are additional read-only attributes that are included in any response that includes key attributes:  
+There are more read-only attributes that are included in any response that includes key attributes:  
 
 - *created*: IntDate, optional. The *created* attribute indicates when this version of the key was created. The value is null for keys created prior to the addition of this attribute. Its value MUST be a number containing an IntDate value.  
 - *updated*: IntDate, optional. The *updated* attribute indicates when this version of the key was updated. The value is null for keys that were last updated prior to the addition of this attribute. Its value MUST be a number containing an IntDate value.  
@@ -137,16 +137,16 @@ For more information on other possible attributes, see the [JSON Web Key (JWK)](
 
 ## Key tags
 
-You can specify additional application-specific metadata in the form of tags. Key Vault supports up to 15 tags, each of which can have a 256 character name and a 256 character value.  
+You can specify more application-specific metadata in the form of tags. Key Vault supports up to 15 tags, each of which can have a 256 character name and a 256 character value.  
 
 > [!NOTE] 
 > Tags are readable by a caller if they have the *list* or *get* permission to that key.
 
 ##  Key access control
 
-Access control for keys managed by Key Vault is provided at the level of a Key Vault that acts as the container of keys. You can control access to keys using Key Vault [role-based access control](../general/rbac-guide.md) (recommended) or old [vault access policy](../general/assign-access-policy.md) permssion model. Role-based permission model has three predefined roles to manage keys: 'Key Vault Crypto Officer', 'Key Vault Crypto User', 'Key Vault Service Encryption User' and can be scoped to subscription, resource group or vault level.
+Access control for keys managed by Key Vault is provided at the level of a Key Vault that acts as the container of keys. You can control access to keys using Key Vault [role-based access control](../general/rbac-guide.md) (recommended) or old [vault access policy](../general/assign-access-policy.md) permission model. Role-based permission model has three predefined roles to manage keys: 'Key Vault Crypto Officer', 'Key Vault Crypto User', 'Key Vault Service Encryption User' and can be scoped to subscription, resource group or vault level.
 
-Vault access policy permssion model permissions:
+Vault access policy permission model permissions:
 
 - Permissions for key management operations
   - *get*: Read the public part of a key, plus its attributes
@@ -169,7 +169,7 @@ Vault access policy permssion model permissions:
 
 - Permissions for privileged operations
   - *purge*: Purge (permanently delete) a deleted key
-  - *release*: Release a key to a confidential compute environment which matches the release_policy of the key
+  - *release*: Release a key to a confidential compute environment, which matches the release_policy of the key
 
 - Permissions for rotation policy operations
   - *rotate*: Rotate an existing key by generating new version of the key (Key Vault only)