Pre-deployment Configuration

The configuration and deployment of digital signature components is complex and usually the responsibility of an Public Key Infrastructure (PKI) administrator. If you only use self-signed certificates for simple signing workflows, skip this section.

Recommendations

To leverage Acrobat’s rich digital signature capabilities, follow these best practices:

1. Familiarize yourself with this guide, the Preference Reference, and the Customization Wizard.

2. Learn about setting registry and plist preferences, including feature locking, paths, the relationship between the UI and the registry, and other topics.

3. Install the application and configure it via the UI. Set the preferences in the Security and Signatures categories.

4. Use the Wizard to copy the registry settings and files from your installed application to the new installer. This is the easiest way to create new settings as well as leverage existing installs.

5. Use the Wizard’s UI to set additional preferences. For example, use its Files and Folders feature to deploy signature-related acrodata files.

6. Deploy the application as described in the Administration Guide.

7. Understand how workflow behavior is determined by registry configuration, certificate extensions, and seed values.

In general, the smaller the scope of the variable, the more controlling it is. For example, an application has a default timestamp server configured, a certificate contains an OID that specifies a different timestamp server, and a seed value specifies a third timestamp server for a particular signature field; in this case, the seed value timestamp server is used.

Deployment checklist

The product ships with default settings, and all of these steps are optional. Review this list to craft the installation you need. Additional settings and details appear in the Preference Reference

1. Establish PKI Trust via CDS, AATL, EUTL, or local trust lists.

2. Set up Directory Server Connections.

3. Set up the Signing Environment requirements, workflow, and method. You may also want to create enterprise signature appearances as described in Custom Signature Appearances.

4. Configure the Timestamp Servers list, defaults, and usage.

5. Configure Signature Validation logging, revocation checking, service providers, and so on.

6. Tune Certificate Revocation Checks for OCSP, CRL, and the interaction of each.

7. Review the Preference Reference for additional other signature-related preferences you may need.

8. If required, enable FIPs compliance.

9. Review the application security preferences to secure your application, data, and network. Configuration involves two main tasks:

   • Enabling protections that restrict potentially malicious content and actions.

   • Trusting specific files, folders, and hosts in your workflow. For example, certified documents can be trusted for exemption from the restrictions above.

10. Test.

11. Deploy.

Document encryption

When FIPS mode is disabled, you can still create encrypted documents that are equivalent to documents encrypted with FIPS mode enabled if you do one of the following:

• Use AES-128 or AES-256 with certificate-based encryption, or

• Use AEM Document Security, which only supports AES-128 and AES-256.

PKI trust

Every PKI leverages a method for trusting the public key certificates. Signers embed a copy of their certificate in their signature, and document recipients validate that signature by determining if the certificate is both valid and trusted. Establishing trust involves issuing signing certificates that chain up a certificate with a high level of integrity. In this way, trust propagates down from the certificate issuer (trust anchor) to all users. Enterprises usually set up trust through a single entity rather than for each its users. Adobe Reader and Acrobat provide two ways to effortlessly establish trust without an additional software download or configuration: CDS and AATL.

Certified document services (CDS)

Certified Document Services (CDS) is a signing solution that allows authors to create Adobe PDF files that automatically certify to the recipient that the author’s identity has been verified by an Adobe CDS provider and that the document has not been altered. CDS signatures ensure the highest level of document integrity because the user’s digital credentials must be stored on a cryptographic hardware device, and they must be issued by a WebTrust certified authority using strict verification guidelines.

Adobe Acrobat Trust List (AATL)

The Adobe Approved Trust List (AATL) program allows signers to create digital signatures that automatically validate on document open. By default, both Acrobat and Reader download a list of “trusted” root digital certificates every 30 days. The product then trusts the digital signatures created with any credential that chains to those pre trusted AATL certificates.

The following preferences allow you to configure how and when the AATL updates.

Keyname	Default	Summary
bAskBeforeInstalling	1
bLoadSettingsFromURL	1	Specifies whether or not trust anchors should be periodically downloaded from Adobe.
iCheckEvery	604800	The value in seconds that the application should check for new certificates to download from Adobe.
iResourceID	varies	An internally used number created by Acrobat when it first sets up the resource pointed to by the URL.
xdata	null	Binary data used for internal purposes.

European Union Trust List (EUTL)

The European Union Trust Lists (EUTL) is a public list of over 200 active and legacy Trust Service Providers (TSPs) that are specifically accredited to deliver the highest levels of compliance with the EU eIDAS electronic signature regulation. Adobe’s support works in the same way as AATL.

The following preferences allow you to configure how and when the EUTL updates.

Keyname	Default	Summary
bAskBeforeInstalling	1
bLoadSettingsFromURL	1	Specifies whether or not trust anchors should be periodically downloaded from Adobe.
iCheckEvery	604800	The value in seconds that the application should check for new certificates to download from Adobe.
iResourceID	varies	An internally used number created by Acrobat when it first sets up the resource pointed to by the URL.
xdata	null	Binary data used for internal purposes.

Shared trusted identity lists

Trust settings are often stored by the application in an acrodata file that stores a list of trusted identities. As described in Security Setting Import-Export, Acrobat simplifies the migration of existing security settings through version upgrades and across multiple machines. The .acrobatsecurity settings file supports the import and export of all settings including digital ID data, trust, server details, signing preferences, and so on. Only Acrobat can export settings, but all products can import them. These settings can be imported manually per client or placed on a central server for automatic download.

Keyname	Default	Summary
tAddressBook	addressbook.acrodata	The filename the Trusted Identity Manager uses to read and write addressbook data.

Other digital ID options

Other methods for setting up trusted workflows include:

• Custom Certificate Preferences.

• MSCAPI integration and the Windows Certificate Store. See the Windows preferences in the Preference Reference.

• Roaming ID Server Integration, see the Roaming ID preferences in the Preference Reference.

• OIDs and Certificates.

PKCS#11 token and smart card integration

If your company uses PKCS#11 devices such as smart card readers or tokens, distribute the drivers or modules at deployment time. Most configuration must occur manually.

1. Set cAdobe_P11CredentialProvider.

2. Distribute the module file, such as dkck201.dll with instructions about where to locate it.

3. Instruct users to restart Acrobat.

Directory server connections

Directory servers can be integrated with the product’s Trusted Identity feature so that users can access certificates company-wide in signature and certificate security workflows (see tAddressBook above). Server information is stored in a directories.acrodata file.

%FDF-1.2
1 0 obj
<</DirectoryData<</Entries<</1<</authenticationType
0.0/dirStdEntryDirType/LDAP/dirStdEntryID/Example.PKMS.ADSI.dir0
/dirStdEntryName(VeriSign Internet DirectoryService)/dirStdEntryPrefDirHandlerID
/Example.PKMS.ADSI/dirStdEntryVersion 65536/maxNumEntries 100.0/port
1234.0/server(directory.verisign.com)/timeout 60.0>>
endobj

Many organizations use Lightweight Directory Access Protocol (LDAP) directory servers to enable LDAP-aware clients to retrieve email addresses, network services, software directories, and so on. Acrobat products can use LDAP servers as x.509 public key certificate repositories. End users leverage these certificates in certificate-based security workflows when they encrypt a document as wellas when validating a signature. While the product ships with the VeriSign Internet Directory Service as the default server (viewable in the Security Settings console), admins typically set an internal server as the default.

Search the Preference Reference for LDAP for a complete list of registry-level options.

Server configuration

For Acrobat to search for certificates on an LDAP server, the server must be able to respond to a specific LDAP scheme. In addition to returning standard, generic information, the server must be able to respond to the request userCertificate;binary as defined by RFC 4523, Section 2.1.

Note

While Acrobat is case insensitive, LDAP servers may not be. The LDAP server should be capable of handling the specific request that Acrobat sends. Verify your server uses the exact format of userCertificate;binary.

Product configuration

Administrators can configure directory servers in several ways:

• Pre-installation (Recommended): Tune the installer with the Adobe Customization Wizard prior to application deployment. The process involves configuring a directory server in your template installation and using the Wizard to copy the directories.acrodata file to the tuned installer.

• Post-installation setting distribution: Export server configuration details in an acrobatsecuritysettings or FDF file and distribute it across the organization. Users can automatically import the settings by double clicking on the file. This method is useful for configuration of an existing installation.

• Post-installation instruction distribution: Tell users how to configure the server manually.

To configure a directory server manually:

1. Open the Security Settings Console. The method varies across versions. For 11.0, choose Preferences > Security > Configure Server Settings > More.

2. Select Directory Servers in the left-hand list.

3. Choose New.

4. Configure the LDAP server settings in the Edit Directory Server dialog:

   • Directory Name: An arbitrary directory name.

   • Access Type: LDAP is the only type supported.

   • Server Name: The server name.

   • Port: The server port.

   • Search Base: A comma-separated list of name-value pairs used in the search. For example, c=us,cn=Brown Trout,ou=Engineering for country, common name, organizational unit.

   • This server requires me to log on: Check if the server requires a username and password.

   • User name: Leave blank.

   • Password: Leave blank.

   • Timeout: The number of seconds to keep trying to connect.

   • Maximum Number of Records to Receive: The number of records to return up to 10.

5. Optional: Make the server the default one to search by highlighting the directory server in the right-hand panel and choosing Set Default.

6. Choose OK if a confirmation dialog appears. A star appears next to the default server.

Signing environment

Administrators can configure preferences to control the signing workflow, when and how a signature is created, the conditions for successful signature creation, and so on. For example, these preferences tell the application where to look for Windows certificates, control signature appearances, and provide control over message digest algorithms.

Signing format

Replace the default signature format.

Keyname	Default	Summary
aSignFormat	adbe.pkcs7.detached	The format to use when signing a document using public key cryptography when a format is not specified by a seed value, javascript parameter, or the PubSec Handler.

Signing hash algorithm

Replace the default hash algorithm.

Keyname	Default	Summary
aSignHash	SHA1 for 9.0 and earlier; SHA256 for 9.1 and later	The hashing algorithm to use while signing.
tSignHash	SHA1 for 9.0 and earlier; SHA256 for 9.1 and later	A text entry that contains the OID of the hashing algorithm.

Signing digest comparison

Require a message digest match.

Keyname	Default	Summary
bEnforceSecureChannel	0	Specifies whether to prevent signing when the original message digest and the signed message digest do not match.

Signing Preview Mode

Require the use of Preview Mode.

Keyname	Default	Summary
bPreviewModeBeforeSigning	0	Specifies whether a signer is forced to use preview mode during signing.

Signing certification

These settings pertain specifically to certified signatures in certified documents. See also bTrustCertifiedDocuments.

Keyname	Default	Summary
bAllowCertNonGreen	1	Specifies whether a certification signature may be applied to a document containing Legal PDF warnings.
bAllowInvisibleSig	1	Specifies whether to allow invisible certification signatures.
bAllowSigCertGreenOnly	0	Specifies whether any subsequent signers can sign a certified document that does not contain LegalPDF warnings with additional approval signatures.
bAllowSigCertOnly	1	Specifies whether any subsequent signers can sign a certified document containing LegalPDF warnings with additional approval signatures.
cAttest	null	Stores a list of the most recently used attestations regarding LegalPDF warnings in a document.

Long term validation

Without certain information added to the PDF, a signature can be validated for only a limited time. This limitation occurs because certificates related to the signature eventually expire or are revoked. Once a certificate expires, the issuing authority is no longer responsible for providing revocation status on that certificate. Without conforming revocation status, the signature cannot be validated.

Long-term signature validation (LTV) allows you to check the validity of a signature long after the document was signed. LTV requires embedding signature validation in the signed PDF. Embedding these elements can occur when the document is signed, or after signature creation.

The required elements for establishing the validity of a signature include the signing certificate chain, certificate revocation status, and possibly a timestamp. If the required elements are available and embedded during signing, the signature can be validated requiring external resources for validation. Acrobat and Reader can embed the required elements, if the elements are available. The PDF creator must enable usage rights for Reader users (File > Save As > Reader extended Document).

Note

When a timestamp server is used, the signature validation time must be set to Secure Time. CDS certificates can add verification information, such as revocation and timestamp into the document without requiring any configuration from the signer. However, the signer must be online to fetch the appropriate information.

Information and methods used to include this long term validation (LTV) information in the PDF comply with Part 4 of the ETSI 102 778 PDF Advanced Electronic Signatures (PAdES) standard. For more information, see blogs.adobe.com/security/2009/09/eliminating_the_penone_step_at.html.

Keyname	Default	Summary
bIsEnabled	Pre 9.1 0; 9.1 and later: 1	Specifies whether the signature revocation status is included in the signature.
bReturnRevInfoToUser	0	If true, the revocation information is maintained within the SignatureInfo object and can be retrieved through JavaScript.
iAutoAddLTV	1	Specifies whether LTV information should be automatically added to all signatures.
iMaxRevInfoArchiveSize	1500Kb	The maximum size of the revocation archival information in kilobytes.
iUseArchivedRevInfo	2	Indicates whether the revocation information archived with the signature is used for revocation checking.

Signing revocation checking

Require a revocation check for the signer’s certificate.

Keyname	Default	Summary
iReqRevCheck	0	Indicates whether revocation checks are required to succeed to create the signature.

Signing reasons

Control signing reasons.

Keyname	Default	Summary
bAllowReasonWhenSigning	0	Specifies whether the reason UI will appear during signing.
bReasons	null	Prevents users from modifying reason's settings.
cReasons	See details.	Stores a list of signing reasons.

Signer details

Show a signer’s location and contact details.

Keyname	Default	Summary
bAllowOtherInfoWhenSigning	0	Specifies whether the location and contact information UI will appear during signing.
tContactInfo	null	When bAllowOtherInfoWhenSigning is true (on), the signing dialog displays a location and contact field.
tLocation	null	Stores the location information of the signer.

Timestamp servers

Timestamping a signature tells you that a document and signature existed prior to the indicated time. While all signatures are associated with the signer machine’s local time, they may also include a timestamp provided by a timestamp server if one is configured. Because a user can set that time forward or back, a local time is less reliable than a timestamp time. Local times are labeled as such in the Date/Time and Summary tabs of the Signature Property dialog. Timestamps are usually provided by third-party timestamp authorities. Because timestamp authorities may charge for their services, Acrobat does not automatically set a default timestamp server if multiple servers are listed.

Certificate-level timestamp configuration can also be set by specifying the server URL in an X-509 certificate extension. For details, see X.509 Extension OIDs in See OIDs and Certificates.

Setting a default timestamp server

Keyname	Default	Summary
bAuthRequired	null	Specifies whether the timestamp server requires authentication.
iHashAlgo	1	Identifies the hashing algorithm used to hash the timestamped data.
iReqRevCheck	2	Indicates whether revocation checks on timestamps are required to succeed before signing.
iSize	4096	ASPKI requires the signature property to predict the size (in bytes) so that enough space can be set aside.
sHashAlgo	SHA1	The hashing algorithm OID used to hash the data to be timestamped.
sPassword	null	The server log in password.
sURL	null	A timestamp server URL such as http://www.example.com/tsp.
sUser	null	The server login username.
xLockboxId	null	If a timestamp server requires authentication, the authentication data is stored in a secure store identified by this ID (e.g. Microsafe).

Configuring the timestamp server list

Keyname	Default	Summary
bAuthReqd	null	This is an internal copy of bAuthReqd that cannot be modified.
bAuthRequired	null	Specifies whether or not the timestamp server requires authentication.
tName	null	The user-defined server name.
tServer	null	The server URL.
xLockboxId	null	If a timestamp server requires authentication, the authentication data is stored in a secure store such as Microsafe and is identified by this ID.

Configuring timestamp usage

Keyname	Default	Summary
bReqSigPropRetrieval	0	Indicates whether retrieving a signature property must succeed.
bUseExpiredTimestamps	1	Specifies whether expired timestamps should be used.
bUseTSAsSigningTime	0	Specifies whether the timestamp time should be displayed in the signature appearance.

Diplaying timestamp server time

By default, the signature appearance displays the signing time from the signer’s computer clock. To display the timestamp server time in a signature appearance:

1. Go to HKLM\SOFTWARE\Policies\Adobe\(product)\(version)\FeatureLockDown\cSecurity\cPubSec\.

2. Create the new DWORD bUseTSAsSigningTime and set it to 1.

3. Go to HKCU\Software\Adobe\(product)\(version)\Security\cASPKI\cASPKI\cSign.

4. Set bReqSigPropRetrieval to 1. Create the preference if it does not exist.

5. Verify the computer time does not vary from the signature validation revocation check response time specified by HKCU\Software\Adobe\(product)\(version)\Security\cPubSec\iMaxClockSkew. The default is 65 minutes. iMaxClockSkew allows admins to account for a network delay, time synchronization issues, and so on without invalidation signatures.

iMaxClockSkew allows admins to account for a network delay, time synchronization issues, and so on without invalidation signatures.

Signature validation

Signature validation preferences specify conditions for trust, the display of status icons, logging, how validation occurs, and other requirements. The process requires that the signer’s certificate or some other certificate it chains up to must be trusted for signing (a trust anchor). In Acrobat products, this means a trusted certificate appears in the application’s trusted identity list in the Trusted Identity Manager and that it’s trust level is appropriately set. While end users trust certificates on-the-fly directly from a signature in a PDF, admins typically configure machines to eliminate any manual tasks.

Many of the following preferences interact with signing preferences and should be set accordingly.

Validation main settings

Keyname	Default	Summary
bReqRevCheck	0	Locks Security\cASPKI\cASPKI\cVerify\iReqRevCheck and disables the user interface item.
bShowSignerWarnings	0	Specifies whether to show a warning that there is a greater forgery risk when revocation information is embedded in the signature.
bShowTSWarnsInDMB	1	Specifies whether to show timestamp warnings in the Document Message Bar.
bValidateOnOpen	1	Specifies whether to automatically validate all signatures on document open.
iReqRevCheck	2	Specifies whether revocation checks are required to succeed.
iSigVerificationTime	1 (9.1 and later: 2)	Indicates the time at which signature validation should occur.

Certificate chain building

Keyname	Default	Summary
bFollowURIsFromAIA	0	Specifies whether to allow the chain builder to follow URIs in AIA certificate extensions so that certificates can be downloaded if they are not available locally.
bRequireValidSigForChaining	0	Specifies whether to allow the chain builder to build chains with invalid RSA signatures on certificates.
cValue	null	An array of strings c0-cN containing the required certificate policy OIDs.
iValidityModel	0	Specifies the validity model for validating signatures and certificates.
sLDAP	null	Specifies the URL of an LDAP server to be used for path discovery.

Specifying directory providers

Keyname	Default	Summary
cDirectoryProvider	All of the available values. See the description.	An array of text entries (t0-tn) containing the name of a registered provider.
iDirectoryProvider	2	Specifies a directory provider for signature validation.

Signature status icons

Keyname	Default	Summary
bShowWarningForChanges	1	Determines whether or not to show a blue i on validated signature(s) if the document changes after it was signed.
bSigAPStatusIconDisable	0	Controls whether the signature status icon is displayed in the signature appearance on the document.
iDisplayValidIcon	null for 9.0 and later; 0 for pre 9.	Determines when the signature status icon is displayed in a signature appearance.

Validation logging

The log file must already exist. When Protected Mode is enabled, the log file path must be one that Protected Mode permits such as the sandbox’s Temp directory or the product AppData directory. Alternatively, enable bUseWhitelistConfigFile and specify a custom location.

Keyname	Default	Summary
iLogLevel	null	Specifies the log level during chain building and validation.
sLogFilePath	null	Specifies the full path of the text log file; for example: C:\ASPKI.log.

Certificate revocation checks

Revocation checking can occur both during signature creation and signature validation, and product settings may be configured to control both the user’s ability to sign and to validate signatures. A check can occur for the signing certificate as well as for the certificates associated with any revocation check responses. OCSP and CRL checking are both supported, and MSCAPI checks will use one or the other, or both.

OCSP and CRL references interact as follows: If a signature has a chain such as Certificate Authority Root (CA) | Intermediate Certificate Authority (ICA) | End Entity Certificate (EE) and OCSP revocation checking preferences are specified for the CA but CRL preferences are not, then Adobe_OCSPRevChecker and Adobe_CRLChecker behave as follows:

• While doing OCSP revocation checking for the ICA, the preferences specified for the CA are used. If the scope for the preferences is specified as infinite, then the CA preferences are also used for revocation checking the EE.

• While doing CRL revocation checking, if no preferences have been specified either for the CA or the ICA, then the preferences present at cASPKI:cAdobe_CRLRevChecker are used instead.

General settings

Specify revocation checking providers.

Keyname	Default	Summary
cRevocationChecker	Adobe_OCSPRevChecker, Adobe_CRLRevChecker	An array of text entries (t0-tn) containing the name of a registered provider.
iRevocationChecker	2	Specifies a provider for revocation checking.

Specify signature revocation checking constraints.

Keyname	Default	Summary
bReqSigPropVerification	0	Specifies whether signature property verification must succeed for a signature to be valid.
bRevCheckTrust	1	Specifies whether to perform revocation checks on intermediate trust anchors (those which aren't roots).
iMaxClockSkew	65 (minutes)	The maximum difference in minutes the signing time is allowed to be after the validation time for the signature to be valid.
iMaxVerifySession	5	Specifies the maximum number of nested verification sessions allowed.

OCSP revocation checking

OCSP revocation checking can occur both during signature creation and signature validation on both the signing certificate as well as for the certificates associated with any revocation check responses.

OCSP responders: Determining if they are authorized to do rev checks

RFC2560 defines three methods of determining whether the OCSP responder is authorized to perform OCSP revocation checking. Two methods are strictly defined and the third one is called “local configuration” which Acrobat defines by specifying a set of certificates. If OCSP response is signed with one of these certificates then the responder is considered authorized.

• Rule 1 (Acrobat 8.0): defined the local configuration rule as follows by authorizing OCSP responses that come from responders specified by sURL.

• Rule 2(Acrobat 9.0): If a custom certificate preference has a new “AuthorizedResponder” boolean entry with a value of true, and the certificate being checked for OCSP revocation as well as the OCSP response both chain up to the customer certificate, then the responder is authorized.

The order in which verifying OCSP responders occurs is as follows:

1. Local configuration rule #1 (A8 and A9).

2. Local configuration rule #2 (new in A9).

3. The two deterministic methods from RFC2560.

Note

The structure and location of the new AuthorizedResponder entry is the same as for SendNonce entry. However, while SendNonce may be specified under ASPKI or a custom certificate preference, AuthorizedResponder may be specified only under custom certificate preferences.

Specifying the Time and Method of OCSP Checks

OCSP revocation checking preferences allow you to control when and how an OCSP check occurs. The following options are available:

• Specifying when to do revocation checking as well as the effect of a failed or bad response.

• Specifying when and where to go online to get a response.

• Specifying whether to include a nonce. Nonces are random generated numbers that are sent with a revocation check request and matched by a response. They improve security by assuring communication with an active, non-spoofed server.

• Using or ignoring a response’s thisUpdate and nextUpdate times to control its validity. See RFC 2560 for details.

• Setting a limit on the amount of time difference between the local time and response’s publish time.

OCSP response embedding changes with 10.1

Prior to 10.1, OCSP responses without nextUpdate were never embedded in a signature. For 10.1 and later, OCSP responses are always embedded irrespective of the presence of nextUpdate; however, whether they are used for signature validation depends on certain conditions:

• Validation time is greater than thisUpdate minus the value of maxClockSkew (the default is 5 minutes). This test is always performed.

• When nextUpdate is present and the validation time is less than the nextUpdate time plus the value of maxClockSkew.

• When nextUpdate is not present and the validation time is less than the thisUpdate time or the producedAt time (whichever is greater) plus the value of iMaxClockSkew.

If you need a relaxed security environment (for example, when the responder is caching OCSP responses), bIgnoreNextUpdate can be set to 1 to ignore the last test. In this case, embedded responses without nextUpdate are always used for signature validation provided that they pass first test.

Note

This behavior is designed to support Acrobat’s long term validation feature and allows validating a signature with embedded responses that were valid at signing time.

Keyname	Default	Summary
bAllowOCSPNoCheck	1	Specifies whether the OCSPNoCheck extension is allowed in the response signing certificate.
bExpiredCertGoOnline	0	Specifies whether to go online to get the revocation information for an expired certificate.
bGoOnline	1	Specifies whether to go online to do revocation checking.
bIgnoreNextUpdate	0	Specifies whether to use embedded OCSP responses when nextUpdate is not present and the validation time is less than the greater of thisUpdate or producedAt time plus the value of iMaxClockSkew.
bIgnoreValidityDates	0	Specifies whether to ignore the response's thisUpdate and nextUpdate times, thereby preventing any negative effect of these times on response validity.
bRequireOCSPCertHash	0	Specifies whether a certificate public key hash extension must be present in OCSP responses.
bSendNonce	1	Specifies signature validation behavior with respect to nonces.
bSignRequest	1	Specifies whether the OCSP request should be signed.
iMaxClockSkew	5 minutes	The number of minutes the local machine time can vary from the response's published time to account for a network delay, time synchronization issues, and so on.
iReqRevCheck	2	Indicates whether revocation checks are required to succeed on the OCSP response.
iResponseFreshness	525600 (1 year)	Specifies the amount of time in minutes after the response's published thisUpdate time for which the response will be valid.
iSendNonce	2	Specifies signature validation behavior with respect to nonces.
iURLToConsult	0	Specifies how the revocation checker chooses which responder to use.
sURL	null	The URL used to fetch OCSP responses.

CRL Revocation Checking

Keyname	Default	Summary
bAlwaysConsult	0	Determines when the URL is used for an additional URL CRL distribution point.
bGoOnline	1	Indicates whether it's acceptable to go online to fetch a CRL.
bIgnoreValidityDates	0	Specifies whether to ignore the response's thisUpdate and nextUpdate times, thereby preventing any negative effect of these times on response validity.
bRequireAKI	0	Specifies whether the Authority Key Identifier extension must be present in a CRL.
iMaxRevokeInfoCacheLifetime	24	Maximum cache lifetime in hours of the information (e.g. CRL) used to do revocation checking.
iReqRevCheck	1	Indicates whether revocation checks are required to succeed on the CRL response.
sLDAP	Null	The LDAP server to get CRLs from in the form www.ldap.com.
sURL	null	The URL used to fetch CRL responses for an additional URL CRL Distribution point.