Note - Data signing should not be confused with code/template signing, which remains unchanged.
Signature Security
Digital signatures are only as secure as the cryptographic algorithms they use to ensure signed data hasn't been tampered with. InfoPath 2007 and 2003 support RSA or DSA for signing and SHA1 for hashing. Though a combination of RSA and SHA1 is considered secure for now, algorithms become exposed to attack over time and are eventually rendered obsolete. If either the signing or hashing algorithm is cracked or compromised, the integrity of the signature can no longer be verified. InfoPath 2010 enables you to address these concerns by supporting newer, more secure, ECC signing and SHA-2 family of hashing algorithms.Signing with a particular algorithm
When creating a signature, a user may sign with one of potentially many certificates installed on their machine. The signature algorithm is determined by the chosen digital certificate. To determine the algorithm:- Begin the signing process
- Change your signing certificate
- Highlight desired certificate and click View Certificate
- Look at the Public key field under the Details tab
Administrator Settings: Hashing algorithms
By default, InfoPath 2010 hashes signature data using SHA1. This is done to maintain backwards compatibility with InfoPath 2007 and InfoPath 2003. InfoPath 2010 also supports the SHA2 family of hashing algorithms. If backwards compatibility is not a concern, an administrator can set the hashing algorithm in the registry.| HKCU\Software\Microsoft\Office\14.0\Common\Signatures\SignatureHashAlg | |
| Value | Description |
| “sha1” (default) | SHA1 hash algorithm |
| “sha256” | SHA256 hash algorithm |
| “sha384” | SHA384 hash algorithm |
| “sha512” | SHA512 hash algorithm |
Signing and Hashing Algorithm Compatibility
The following table shows which versions of InfoPath are able to sign and/or verify signatures with the given combinations of signing and hashing algorithms:
Long-term Signature Support
Certificates guarantee the identity of the signer, but expire after a while. This is to reduce the time attackers have to deduce an associated private key (which would allow them to impersonate a signer) and to limit the shelf-life of a compromised certificate. Certificates may also be revoked if they are taken out of commission before their expiration date. If the certificate used to create a signature is now expired or revoked, we should be cautious of whether the signed data is valid or not unless we can verify that the data was signed while the certificate was still valid. This poses an impending problem because all certificates expire (often in a year!), and we would require a trusted timestamp to confirm when the signature was created. Without such a trusted timestamp, InfoPath will show the signature as invalid, with the reason in the Signature Details dialog:
This can be especially problematic, for example, for a printed copy of the form which would show an invalid signature, and there would be no way to verify why. InfoPath 2010 adds support for XML Advanced Electronic Signature (XAdES), which allows for adding a trusted timestamp that can be used to resolve when the signature was added relative to the signing certificate's expiration and/or revocation time (see a detailed discussion of XAdES in Microsoft Office for details and level options). If such a timestamp exists and confirms that the signature was made when the signing certificate was valid, InfoPath can safely conclude that the signature is entirely valid:
