The DC release supports RSA-PSS Signing on Windows (April, 2017) and Macintosh (August 2017). Classic track (Windows and Macintosh both) support was added in November 2018. RSA-PSS is an RSA cryptosystem signature scheme that provides increased security assurance. For more details see https://www.emc.com/emc-plus/rsa-labs/historical/raising-standard-rsa-signatures-rsa-pss.htm. Support currently includes:

• Acrobat and Reader DC
• Signature validation
• Signature creation with digital ID files (PFX/P12)
• Signature creation with digital IDs imported to Windows Certificate Store and devices such as smart cards supporting Cryptography API: Next Generation (CNG). CNG is designed to replace the legacy CryptoAPI. In addition to increased security, CNG is extensible and cryptography agnostic. For more detail and a list of features, see https://msdn.microsoft.com/en-us/library/windows/desktop/bb204775(v=vs.85).aspx

Signature creation with devices using Crypto API's are not supported.

Summary table

aRSAPSSHashAlgorithm	Specifies the hash algorithm used for RSA-PSS signing.
bEnableRSAPSSSigning	Specifies whether a signature should be created with the RSA-PSS algorithm.
iRSAPSSSaltLength	Specifies the Salt Length the RSA-PSS algorithm uses.

The address book stores data for certificates used in digital signature and certificate encryption workflows. During a major upgrade (e.g. 10.x to 11.x), the product looks for existing address books on each user machine. Prior to install, you should decide whether to deploy a generic, enterprise address book or let the existing address book on each machine be imported into the new product. By default, when end users first launch the product, the application prompts them to import any discovered address book. The application looks for existing addressbooks from previous product versions by searching directories in this order.

• (root)\AppData\Roaming\Adobe\Acrobat\11.0\addressbook.acrodata
• (root)\AppData\Roaming\Adobe\Acrobat\10.0\addressbook.acrodata
• (root)\AppData\Roaming\Adobe\Acrobat\9.0\addressbook.acrodata
• (root)\Program Files (x86)\Adobe\Acrobat {current version such as 11.0}\Acrobat\Replicate

Summary table

iImportAddressBook

Specifies whether the addressbook.acrodata file should be imported during a new install.

9.x products introduced a security feature that includes the ability to import and export security settings via an .acrobatsecuritysettings file, thereby enabling easier version upgrades as well as configuration of multiple machines. The security settings import/export features offers several advantages over FDF files:

• Most document security and digital signature related settings can be encapsulated in an acrobatsecuritysettings file whereas FDF could only transport one setting type and a time and could not encapsulate registry settings at all.
• One file can be used instead of many files.
• Trust can be assigned to imported files on the fly, thereby simplifying workflows. Files can be signed and encrypted.
• Updates can be configured to occur automatically on a specified schedule.

Use security settings files to backup and restore settings, to distribute settings in a workgroup or enterprise, and to send specific information to another user. Importing settings simply involves importing a file from a network (including automatically from a server) that has been exported from Acrobat and has then been made available from a trusted source.

The following options are available:

• Specifying whether or not to poll a server for settings to import at regular intervals.
• Configuring whether or not the user should grant permission prior to installing new settings.
• Specifying a particular certificate so the signed settings will only be imported from a trusted source.

Summary table

bAskBeforeInstalling	Specifies whether these types of trust anchors should be imported silently or Acrobat should ask permission from the user. To disable this feature, set tLoadSettingsFromURL to 0.
iCheckEvery	The polling interval to check the specified server for an updated security settings file.
iResourceID	An internally used number created by Acrobat when it first sets up the "resource" pointed to by the URL. It is not user customizable.
tLoadSettingsCERT	Specifies a certificate that must be used to sign the imported security settings file.
tLoadSettingsFromURL	Specifies whether to load security settings from a server.
tLoadSettingsNAME	Specifies the signing certificate for the imported settings file.
tLoadSettingsURL	The server URL where the acrobatsecuritysettings file to import resides.
xdata	Binary data used for internal purposes.

Summary table

cCertIssuerInfo	Contains a subkey for each certificate with extended information.
cExtendedCertInfo	Contains a subkey for each certificate with extended information provided by attribute certificates.

Summary table

c(someInteger)	The default chain scope in which to look for the policy OIDs.
cValue	An array of strings containing the policy OIDs for a certificate to be considered acceptable.

Security handlers are Acrobat plugins. Information about creating plugins in general and security handlers in particular can be found in the Acrobat Software Development Kit (SDK) and its HFTs, header files, and other API documentation. Because Acrobat's Adobe.PPKLite is becoming more feature rich with each release, it is unlikely that you will need a custom security handler.

Adobe.PPKLite is the default security handler used for performing private key functions, validating signatures, and signing and encrypting documents. This is represented in the user interface as Adobe Default Security in the Digital Signatures Advanced Preferences dialog on both the Verification and Creation tabs. Administrators can install custom handlers to perform these functions, in which case the drop down lists on these tabs will list the additional handlers. All entries in the cHandler folder are reset by the Digital Signature Preferences dialog's Reset button.

If a custom handler is used, you can specify the following:

• Separate handlers for signing/encryption and signature validation.
• The default method displayed in the drop-down list of handlers.
• Lock down the selections so they cannot be modified by end users.

Summary table

aAddressBook	Remembers a preferred handler for accessing Trusted Identity Manager functions including certificate data import from an FDF file.
aDirectory	Remembers a preferred handler for directory functions (e.g. LDAP), including for importing directory information from an FDF data exchange file.
aPrivKey	Used by DigSig and PubSec to store the handler that accesses private key functions.
aVerify	Remembers the name of the preferred handler to use when verifying signatures.
bVerifyUseAlways	Qualifies the use of aVerify.
cDialogs:xSelHandler	The last on-screen coordinates of a handler's digital ID selection dialog

The File Data Exchange Format (FDF) provides a format for easily importing and exporting certificate data and application settings. These settings appear in Security\cPubSec after a client uses the feature.

The default values are stored internally by the application and are not visible in the registry. An administrator can set the default behavior, but your configuration is subject to modification by end users via the user interface.

The following features are available:

• Specifying whether the default export behavior is to save or email the file.
• Specifying whether the default export behavior is to sign the file.
• Specifying whether the default certificate request behavior is to save or email the file.
• Enabling or disabling WebBuy FDF processing (deprecated).

Summary table

bFDFExportSave	Persists whether user chose to save (1) or email (0) the FDF during export.
bFDFExportSign	Persists whether the user chose to sign the FDF during export.
bFDFRequestExcludeCert	Similar to the bFDFRequestSave.
bFDFRequestSave	Caches a user's answer to the question whether they want to save the request as an FDF or email it directly when that user requests a certificate.
bWebBuyFDF	Enables WebBuy FDF file processing.

Security Settings Console preferences persist information about the state of the console user interface. These preferences are user generated and implementation specific and are likely to change across application versions. These keys are not customizable and are provided for informational purposes only.

Summary table

cOpenCategories	An array of binary IDs for all categories in the tree view that were opened.
iSHS	Indicates (in pixels) the position of the horizontal window splitter.
iSVS	Indicates (in pixels) the position of the vertical window splitter.
xCategory	A binary ID of the last-selected category in the tree view.

By default, the Certificate Viewer builds and displays the trusted chain from the EE to the trust anchor. However, it is possible to show all found chains whether they are trusted or not. While most users do not need this information, it can be used for troubleshooting and verification. End users can turn this option on and off by using the Certificate Viewer's checkbox Show all certification paths found.

Summary table

bShowAllChains

Specifies whether to show all chains in the Certificate Viewer.

By default, password caching is turned on so that users will not always have to enter a password when one is required. This feature affects Adobe LiveCycle Rights Management Server log in, signing with digital IDs in the Acrobat store (pfx or p12 files), changing password timeout policies, and creating new password security policies. For example, setting the option to false disables the menu option Save password with the policy when creating a new policy.

The following options are available:

• Controlling whether some passwords are cached to disk.
• Disabling the option to save a password with a policy.
• Streamlining Adobe LiveCycle Rights Management Server workflows. This key does not exist in HKCU. It can only be used in HKLM.

Note: Disabling Never ask for password on a digital ID's password timeout dialog does not work in version 9.0.

Summary table

bAllowPasswordSaving

Controls whether certain passwords can be cached to disk; for example, passwords for digital IDs.

The Examine Document dialog box identifies hidden document information that might pose a risk to the integrity of security and signature workflows. Found content is listed and linked to in the Examine Document pane. Users can click on a link to view the content and check/uncheck items to mark them for removal. Checked items are removed when the user selects the Remove button.

The following options are available:

• Examining a document each time it is closed.
• Examining a document each time it is emailed.

Summary table

bAutoLaunchAtDocClose	Automatically examines the document for hidden content when it is closed.
bAutoLaunchAtSendMail	Automatically examines the document for hidden content when it is sent in an email.
bDontRemoveOverlapping	Specifies whether to remove hidden content when sanitizing a document.

These preferences are only used for signature workflows where users access roaming IDs on a roaming ID server. While the needed configuration can be handled through the user interface by end users, you can set the following:

• Specifying a Default Roaming ID Server : When a user adds a roaming ID account through the GUI, a dialog asks for a friendly name and a server URL. If no other accounts have been configured and cDefaultServerInfo exists in the preferences, its values populate both the friendly server name and URL fields in the Add a Roaming ID dialog.
• Specifying one or more authentication methods.

Summary table

tServerName	A user friendly roaming ID server name.
tURL	The URL of the Roaming ID server.

These preferences store roaming ID server data. Some values are provided by the user and some are provided by the server. These keys cannot be customized and are provided for informational purposes only.

Summary table

cAccounts	Contains entries for user accounts on roaming ID servers that the provider knows about.
cRecentServerURLs	Contains an array of roaming ID server URLs recently entered by the user.

These preferences are created as a result of communications with a roaming ID server. Whether or not you customize these settings is determined by the needs or your particular implementation.

Summary table

cCredentials	The value is provided by the server.
cSAML_Assertion	Holds an encrypted SAML assertion obtained during last successful authentication.
tSAML_Assertion_Expiration	Holds the time after which roaming ID provider will not attempt to use the SAML assertion stored in cSAML_Assertion.
tSAML_Assertion_Source	Holds the URL of the authentication server from which the SAML assertion stored in cSAML_Assertion was obtained.
tSAML_Name_Format	SAML_NAME_<Value, Format, Qualifier> comprise the subject name identifier taken from the SAML assertion received during the account's last user authentication.
tSAML_Name_Qualifier	SAML_NAME_<Value, Format, Qualifier> comprise the subject name identifier taken from the SAML assertion received during the account's last user authentication.
tSAML_Name_Value	SAML_NAME_<Value, Format, Qualifier> comprise the subject name identifier taken from the SAML assertion received during the account's last user authentication.
tSASL_Mechanism	The SASL id of the authentication mechanism.
tSASL_UserName	The mechanism-specific persistent data.

The authentication mechanism provider pertains only to roaming IDs. It enables you to specify one or more authentication mechanisms. The mechanism must be supported by the roaming ID server with which the application communicates.

The following features are available:

• Enabling multiple authentication mechanisms.
• Limiting the authentication mechanism to one specified type.
• Turning off authentication so that roaming IDs cannot be used.

Summary table

cAuthMechanisms	An array of text entries (t0-tn) where each entry contains the name of a registered provider.
iAuthMechanisms	Specifies which registered provider(s) to use.

This option is only relevant if the ASSP-Kerberos SPI is selected.

Summary table

sServiceName

The administrator-specified roaming ID Kerberos service name.

By default, users can create self signed digital IDs. However, if you would like to prevent users from creating their own IDs, turn this feature off. Disabling this option prevents users from selecting Create a self-signed ID option in Add ID workflows.

Summary table

bSelfSignCertGen

Specifies whether or not the Create a self-signed ID option in Add ID workflows is available.

The key contains a list of P11 modules the user has loaded by choosing Attach Modules in the Security Settings console. By specifying a valid path to a PKCS#11 DLL, modules can be pre-attached to installed clients. Because various errors appear as a result of a bad filename or pointing to a dll that is not a valid PKCS#11 module, test the settings and file before distributing them.

The following options are available:

• Preconfiguring the key when tuning the installer and distributing the module file or when modules are already installed.
• Setting the default browse path in which to look for additional modules.

For Reader X (10.0), not all PKCS#11 devices may work with Protected Mode (PM) enabled. However, in most cases, they do. Installation of such devices usually involves disabling Protected Mode, installing the driver, restarting the application, and then re-enabling Protected Mode. For the latest information about PM compatibility with certain features, see http://kb2.adobe.com/cps/860/cpsid_86063.html.

Summary table

cModules	Array of dynamic library paths to PKCS#11 modules.
cP11Credentials	Contains an array of subcabs for all known PKCS#11 digital IDs.
cP11Path	Stores the last folder in which the user browsed for a P11 module.

Most digital ID default values are set by the application when a user first uses an ID or manually specifies a default value in the Security Settings Console. Moreover, since user actions will overwrite some preconfigured value an administrator might provide, setting many of these properties is usually not worthwhile. However, it is possible and the following options are available:

• Specifying a default URL to obtain a new digital ID. This value is NOT overwritten by user actions.
• Listing a set of attribute certificates.
• Specifying a default signing ID. This value is end user-specific.
• Specifying a default encryption ID. This value is end user-specific.
• Customizing a default directory server used to locate certificates that can be imported into the Trusted Identity Manager.

Note : Acrobat 9.0 users who configure a 3rd party security handler plugin may find that their non-default choice does not stick if the plugin calls PSUNregisterHandler(). That is, each time Acrobat restarts, the non-default security handler choice is lost. To fix the problem, change the plugin code to not call PSUNregisterHandler().

Summary table

aDefDirectory	Default directory to use when searching for digital IDs.
bCustomPrefsCreated	Indicates whether a custom certificate specific preference (e.g. Identrus) has already been created and written to the registry.
cACs	Contains a set of attribute certificates as binary data.
cDigitalIDFiles	Contains an array of subcabs for all application-known digital ID files.
tCredProvider	Identifies credential service provider interface for the default signing digital ID.
tCredProvider	Identifies credential service provider interface for the ASPKI provider which exposes this digital ID.
xCertSHA1	Identifies the default signing digital ID by its SHA1 hash of the public key.
xCertSHA1	Identifies the default encryption digital ID by its SHA1 hash of the public key.
xDefEnrollmentURL	The destination URL when the user selects <b>Enroll at an online CA</b> while adding a new digital ID.

The digital ID default path preferences point to the application security folder. For example, C:\Documents and Settings\(user name)\Application Data\Adobe\Acrobat\8.0\Security. The path is used when the user imports or exports an ID from the Security Settings Console. Since the application remembers the last accessed directory, if a user chooses a different directory, that action will overwrite the preconfigured value an administrator might provide.

The following options are available:

• Specifying a default path for exporting and importing digital ID certificates (does not include private keys).
• Specifying a default path for saving newly created digital ID files.

Summary table

cEmbeddedFilePath	The path last chosen for extracting an embedded file from a WebBuy FDF.
cExportPath	Default path for exporting credentials.
cImportPath	Default path for importing credentials.
cProfilePath	Default path for storing profile files such as PKCS#12 files.

The Adobe Approved Trust List (AATL) program allows signers to automatically trust digital signatures chain to the trustworthy AATL certificates. By default, both Acrobat and Reader automatically download a list of "trusted" root digital certificates. The update frequency for Acrobat DC and AATL is as follows:

• Acrobat 11 and DC: Updates are now every 14 days.
• Acrobat 10: Updates every 30 days.
• Acrobat 9 and earlier: Updates every 90 days.

To assure that downloaded (as well as any other) trust anchors have not been revoked, configure bRevCheckTrust.For more about the AATL program, see the AATL pageand this blog.

Summary table

bAskBeforeInstalling	Specifies whether these types of trust anchors should be imported silently or Acrobat should ask permission from the user. To disable this feature, set tLoadSettingsFromURL to 0.
bLoadSettingsFromURL	Specifies whether or not trust anchors should be periodically downloaded from Adobe.
iCheckEvery	The value in seconds that the application should check for new certificates to download from Adobe.
iResourceID	An internally used number created by Acrobat when it first sets up the resource pointed to by the URL.
xdata	Binary data used for internal purposes.

Like the AATL program, the European Union Trust List (EUTL) program allows signers to automitically trust digital signatures that chain to trustworthy EUTL certificates. While the feature was introduced with 11.0.06, the first EUTL trust lists were made available with the October 13, 2015 release.

To assure that downloaded (as well as any other) trust anchors have not been revoked, configure bRevCheckTrust.

Note that both the AATL and EUTL features load certificates into the user's Acrobat Address Book (Acrobat Trust Store). The addition of the EUTL certificates increases the size of the address book and can affect the performance of signature validation in versions 11.0.06 to 11.0.10. Later product versions should validate in about 1/2 second. If you experience performance issues, update to the latest product. Alternatively, you can remove the EUTL preference (not recommended).

For more about the EUTL program, see the blog.

Summary table

bAskBeforeInstalling	Specifies whether these types of trust anchors should be imported silently or Acrobat should ask permission from the user. To disable this feature, set tLoadSettingsFromURL to 0.
bLoadSettingsFromURL	Specifies whether or not trust anchors should be periodically downloaded from Adobe.
iCheckEvery	The value in seconds that the application should check for new certificates to download from Adobe.
iResourceID	An internally used number created by Acrobat when it first sets up the resource pointed to by the URL.
xdata	Binary data used for internal purposes.

While Acrobat has its own store, the Windows store may already contain needed certificates or your enterprise may simply be a Windows shop. Windows integration allows end users to search for and use certificates in the Windows Certificate Store.

End users can configure their application for Windows integration through the application's Preference panel. Configuration options allow users to search the Windows store from the Trusted Identity Manager (through the Search button), set trust levels for any found certificate, and choose which certificates to use for encryption (once the certificate is located and added to the Trusted Identity Manager). If a user has a personal ID in the Windows store, it appears in the Security Settings Console automatically without any special configuration.

Administrators can control whether clients can access MSCAPI through Acrobat so that users can find, use, and set trust levels for Windows certificates.

The following options are available:

• Adding the Windows Certificate Store as a searchable repository with bCertStoreImportEnable.
• Setting separate trust levels for approval and certification signatures.
• Preventing end user modification of certificate trust levels.
• Tuning the service provider interface for:
• Certificate Providers (for Signing and Decryption)
• Revocation Checker Providers
• Signature Validation Directory Providers

Summary table

bCertStoreImportEnable	If true, then users can import from MSCAPI certificate stores into their Trusted Identity Manager.
bMSStoreTrusted	Locks the UI so that end users cannot change the value set by iMSStoreTrusted
iMSStoreTrusted	Controls whether or not certificates in the Windows Certificate Store are trusted for signing and certifying.

The trusted identity list contains all of a users imported certificates that they use for validating someone else's signature or encrypting a document for them. The list is maintained and managed via the Trusted Identity Manager; however, administrators can preconfigure applications to use non-default list files, add certificates from the Windows, store, and so on.

The following options are available:

• Creating a custom filename/file for the trusted identity list.
• Specifying a non-default security handler to control Trusted Identity Manager functions. For details, see aAddressBook.
• Adding the Windows Certificate Store as a searchable repository with bCertStoreImportEnable.
• Turning off and on the ability to automatically download certificates sent by Adobe to users over the internet via bLoadSettingsFromURL.

Summary table

tAddressBook

The filename the Trusted Identity Manager uses to read and write addressbook data.

The directory provider SPI provides access to trust anchors and intermediate CAs used for signature validation. By default, certificates in all of the supported locations are used.

The following options are available:

• Preventing or allowing access to certificates in P12 files. End users must also be logged in to the file.
• Preventing or allowing access to certificates in the Trusted Identity Manager.
• Preventing or allowing access to certificates in the Window Certificate Store.
• Preventing or allowing access to self-signed certificates created by an Adobe application.

Summary table

cDirectoryProvider	An array of text entries (t0-tn) containing the name of a registered provider.
iDirectoryProvider	Specifies a directory provider for signature validation.

While users can configure these general signature validation preferences via the GUI, admins usually preconfigure the application.

The following options are available:

• Controlling whether all signatures are validated when a document opens.
• Specifying which time to use when validating a signature.
• Specifying when to do revocation checking as well as the affect of a failed or bad response.
• Using expired timestamps.
• Showing timestamp warnings in the Document Message Bar.

Summary table

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

By default, when an application validates a signature it displays a signature status icon in the Signature Properties dialog, and in the Signatures Pane. You can customize status icon behavior for a particular enterprise requirement. For example, a blue i appears on a signature status icon based on certain rules when a document is changed after it was signed.

The following options are available:

• Turning on the icon for signature appearances with bSigAPStatusIconDisable. This is off by default because displaying the signature status within the document represents a security vulnerability.
• Turning off the icon for signature appearances AND remove the Hide signature field validity icon when signature is valid from the user interface so the user cannot change the setting with iDisplayValidIcon.
• Turning on the icon for valid signatures only with iDisplayValidIcon.
• Turning off the blue i in the Signature Properties dialog, and Signatures Pane with bShowWarningForChanges.

Summary table

bShowWarningForChanges	Determines whether or not to show a blue i on validated signature(s) if the document changes after it was signed.
bSigAPStatusIconDisable	Controls whether the signature status icon is displayed in the signature appearance on the document.
iDisplayValidIcon	Determines when the signature status icon is displayed in a signature appearance.

Versions 8.x and later enable logging certificate validation and revocation checking information. You can set both the logging level and log location. The path must already exist for logging to take place. Note that when Protected Mode is enabled, the log file path must be one that Protected Mode permits.

The following options are available:

• Specifying a logging path and filename.
• Setting a logging level.

Chain building log file settings

[HKEY_CURRENT_USER\Software\Adobe\Adobe
Acrobat\8.0\Security\cASPKI\cAdobe_ChainBuilder]
"iLogLevel"=dword:00000008
"sLogFilePath"=(BINARYpathtoexistingdirectoryforlogfile)

Log file for troubleshooting certificate validation

20070207000213Z:---------------------------
20070207000213Z:Chainbuilder:Startingchainvalidation.Chainlength=
3
20070207000213Z:ProcessingCertificate:DN:ou=VeriSignTrust
Network,ou=(c)1998VeriSign,Inc.-Forauthorizeduseonly,ou=Class2
PublicPrimaryCertificationAuthority-G2,o=VeriSign,Inc.,c=USSerial:
00B92F60CC889FA17A4609B85B706C8AAF
20070207000213Z:verificationtime=20070207000213Z
20070207000213Z:ProcessingCertificate:DN:cn=EnterpriseServices
CA,ou=Class2OnSiteIndividualSubscriberCA,ou=Termsofuseat
https://www.verisign.com/rpa(c)01,ou=VeriSignTrustNetwork,o=AdobeSystems
IncorporatedSerial:0C0DB7043D0427BEB15AECA02DC95903
20070207000213Z:verificationtime=20070207000213Z
20070207000213Z:ProcessingCertificate:DN:email=example@adobe.com,
cn=BenWriter,ou=AdobeCPS-http://www.adobe.com/misc/CPS.html,
ou=www.verisign.com/repository/CPSIncorp.byRef.,LIAB.LTD(c)99Serial:
5C41B5256825491A4981D4FABFCCA044
20070207000213Z:verificationtime=20070207000213Z
20070207000213Z:FinishedChainValidation.TroubleFlags:0

Summary table

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

The following options are available:

• Requiring signature property verification such as timestamps. Signatures will not be valid if this key is true and timestamp verification does not succeed.
• Limiting the number of nested verification sessions to prevent looping.
• Limiting the amount of time the signing time can be after the validation time.
• Forcing revocation checks on intermediate and self-signed trust anchors (those which aren't roots).

Summary table

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

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. It is possible to require certain features for certificates used to sign OCSP requests and responses. If either does not meet the specified parameters, it is considered invalid and the signature status may be Unknown or Invalid. See RFC 2560 for details.

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 iMaxClockSkew (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 iMaxClockSkew.
• 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.

This behavior is designed to support the long term validation feature and allows validating a signature with embedded responses that were valid at signing time. 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 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.
• Setting a limit on the amount of time difference between the local time and response's publish time.
• Allowing or disallowing the OCSPNoCheck extension.
• Requiring the presence of a public key hash extension (bRequireOCSPCertHash).
• Specifying whether OCSP requests should by signed (bSignRequest).
• Requiring the presence of a particular OID in a request (sSignCertOID).

It is possible to require certain features for certificates used to sign OCSP responses. If a response does not meet the specified parameters, it is considered invalid and the signature status may be Unknown or Invalid. The following options are available:

• Allowing or disallowing the OCSPNoCheck extension.
• Requiring the presence of a public key hash extension via bRequireOCSPCertHash.

Summary table

bAllowOCSPNoCheck	Specifies whether the OCSPNoCheck extension is allowed in the response signing certificate.
bExpiredCertGoOnline	Specifies whether to go online to get the revocation information for an expired certificate.
bGoOnline	Specifies whether to go online to do revocation checking.
bIgnoreNextUpdate	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	Specifies whether to ignore the response's thisUpdate and nextUpdate times, thereby preventing any negative effect of these times on response validity.
bRequireOCSPCertHash	Specifies whether a certificate public key hash extension must be present in OCSP responses.
bSendNonce	Specifies signature validation behavior with respect to nonces.
bSignRequest	Specifies whether the OCSP request should be signed.
iMaxClockSkew	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	Indicates whether revocation checks are required to succeed on the OCSP response.
iResponseFreshness	Specifies the amount of time in minutes after the response's published thisUpdate time for which the response will be valid.
iSendNonce	Specifies signature validation behavior with respect to nonces.
iURLToConsult	Specifies how the revocation checker chooses which responder to use.
sURL	The URL used to fetch OCSP responses.

CRL 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.

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.
• Setting a time limit for caching a response after which the application must get a new response.
• Specifying a LDAP server to query for CRLs. Querying an LDAP server can result in poor application performance depending on the quality of the network connection and the number of directories to search.
• Specifying whether to ignore the response certificate's times in the thisUpdate and nextUpdate extensions.
• Requiring the presence of the Authority Key Identifier extension.

It is possible to require certain features for certificates used to sign CRL responses. If a response does not meet the specified parameters, the response will be considered invalid and the signature status may be Unknown or Invalid.

The following options are available:

• Specifying whether to ignore the response certificate's times in the thisUpdate and nextUpdate extensions.
• Requiring the presence of the Authority Key Identifier extension.

Summary table

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

The revocation checking process includes building the certificate chain so that each discovered certificate can be analyzed and processed as specified by other application preferences. Administrators do have some control over what certificates are used to build a chain.

The following options are available:

• Controlling whether AIA extensions are followed.
• Requiring the use of valid RSA signatures on all certificates in a chain.
• Requiring the presence of specific policy OIDs in the specified chain scope for it to be valid.
• Pointing to an LDAP server for path discovery purposes. Querying an LDAP server can result in poor application performance depending on the quality of the network connection and the number of directories to search.

Summary table

bFollowURIsFromAIA	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	Specifies whether to allow the chain builder to build chains with invalid RSA signatures on certificates.
cValue	An array of strings c0-cN containing the required certificate policy OIDs.
iValidityModel	Specifies the validity model for validating signatures and certificates.
sLDAP	Specifies the URL of an LDAP server to be used for path discovery.