Document new PKI CMPv2 configuration field disabled_validations (#29707)

* Document new PKI CMPv2 configuration field disabled_validations.

website/content/api-docs/secret/pki/issuance.mdx

@@ -705,6 +705,7 @@ $ curl \
   "data": {
     "audit_fields": ["common_name", "alt_names", "ip_sans", "uri_sans"],
     "default_path_policy": "role:example-role",
+    "disabled_validations": [],
     "authenticators": {
       "cert": {
         "accessor": "auth_cert_7fe0c1cc",
@@ -750,6 +751,11 @@ updated values as a response along with an updated `last_updated` field.
  `locality`, `province`, `street_address`, `postal_code`, `serial_number`, `use_pss`, `key_type`, `key_bits`,
  `add_basic_constraints`
 
+- `disabled_validations` `(list: [])` - Checks to skip during request validation. Possible values are
+ `DisableMatchingKeyIdValidation`, and 'DisableCertTimeValidation'. `DisableMatchingKeyIdValidation` disables
+ the check that sender key ID in the request header needs to match the subject public key ID in the signing
+ certificate. `DisableCertTimeValidation` disables the not before/not after verifications within the signing
+ certificate. Disabling any validation is highly discouraged.
 
 #### Sample Payload
 
@@ -762,6 +768,7 @@ updated values as a response along with an updated `last_updated` field.
       "cert_role": "cert1"
     },
    "default_path_policy": "sign-verbatim",
+   "disabled_validations": ["DisableMatchingKeyIdValidation"],
    "audit_fields": ["common_name", "alt_names", "ip_sans", "uri_sans"],
    "enable_sentinel_parsing": true
   }
@@ -790,12 +797,10 @@ $ curl \
         "cert_role": "cert1"
       },
     "default_path_policy": "sign-verbatim",
+    "disabled_validations": ["DisableMatchingKeyIdValidation"],
     "enabled": true,
     "enable_sentinel_parsing": true,
     "last_updated": "2024-02-02T10:49:20-05:00"
   }
 }
 ```
-
-
-

website/content/docs/secrets/pki/cmpv2.mdx

@@ -31,8 +31,8 @@ required, which are broken down into three main categories:
 CMPv2 is a bit unique, in that it uses the Issuer CA certificate to sign the
 CMP messages.  This means your issuer must have the `DigitalSignature` key
 usage.
-Existing CA issuers likely do not have this, so you will need to generate a new 
+Existing CA issuers likely do not have this, so you will need to generate a new
-issuer (likely an intermediate) that has this property.  If you are configuring PKI 
+issuer (likely an intermediate) that has this property.  If you are configuring PKI
 for the first time or creating a new issuer, ensure you set `key_usage` to,
 as an example, `CRL,CASign,DigitalSignature`.
 
@@ -40,17 +40,17 @@ See [Generate intermediate CSR](/vault/api-docs/secret/pki#generate-intermediate
 
 ### Configuring CMPv2 Authentication
 
-At this time, Vault's implementation of CMPv2 supports only 
+At this time, Vault's implementation of CMPv2 supports only
 [Certificate TLS authentication](/vault/docs/auth/cert), where clients proof
 of posession of a TLS client certificate authenticates them to Vault.
 
 Authentication leverages a separate Vault authentication
 mount, within the same namespace, to validate the client provided credentials
-along with the client's ACL policy to enforce. 
+along with the client's ACL policy to enforce.
 
 For proper accounting, a mount supporting CMPv2 authentication should be
 dedicated to this purpose, not shared with other workflows.  In other words,
-create a new certificate auth mount for CMPv2 even if you already have one 
+create a new certificate auth mount for CMPv2 even if you already have one
 another in use for other purposes.
 
 When setting up the authentication mount for CMPv2 clients, the token type must
@@ -58,7 +58,7 @@ be configured to return [batch tokens](/vault/docs/concepts/tokens#batch-tokens)
 Batch tokens are required to avoid an excessive amount of leases being generated
 and persisted as every CMPv2 incoming request needs to be authenticated.
 
-The path within an ACL policy must match the `cmp` path underneath the 
+The path within an ACL policy must match the `cmp` path underneath the
 PKI mount.  The path to use can be the default `cmp` path or a role based one.
 
 If using the `sign-verbatim` as a path policy, the following
@@ -89,7 +89,7 @@ $ vault read -field=accessor sys/auth/auth/cert
 
 For CMP to work within certain clients, a few response headers need to be explicitly
 allowed, trailing slashes must be trimmed, and the list of accessors the mount can delegate authentication towards
-must be configured. The following will grant the required response headers, you will need to replace the values for 
+must be configured. The following will grant the required response headers, you will need to replace the values for
 the `delegated-auth-accessors` to match your values.
 
 ```shell-session
@@ -112,6 +112,7 @@ vault write pki/config/cmp -<<EOC
 {
   "enabled": true,
   "default_path_policy": "role:example-role",
+  "disabled_validations": [],
   "authenticators": {
     "cert": {
       "accessor": "auth_cert_4088ac2d"
@@ -123,7 +124,7 @@ EOC
 ```
 
 Of course, substituting your own role and accessor values.  After this, the
-CMP endpoints will be able to handle client requests, authenticated with the 
+CMP endpoints will be able to handle client requests, authenticated with the
 previously configured Cert Auth method.
 
 ## Limitations
@@ -138,8 +139,6 @@ In particular, the following are not yet supported:
  * CA creation/update operations.
 
 Note that CMPv2 is not integrated with these existing Vault PKI features:
- 
+
  * Certificate Metadata - CMPv2 has no means of providing metadata.
  * Certificate Issuance External Policy Service [(CIEPS)](/vault/docs/secrets/pki/cieps)
-
-