Plan digital signature settings for Office 2010
Applies to: Office 2010
Topic Last Modified: 2011-08-05
You can digitally sign documents by using Microsoft Excel 2010, Microsoft PowerPoint 2010, and Microsoft Word 2010. You can also add a signature line or signature stamp by using Excel 2010, Microsoft InfoPath 2010, and Word 2010. Microsoft Office 2010 includes support for XAdES (XML Advanced Electronic Signatures), which is a set of extensions to the XML-DSig standard. This was first supported in the 2007 Microsoft Office system.
In this article:
What is a digital signature?
Digital Certificate: self-signed or issued by CAs
Using digital signatures
What is a digital signature?
You can digitally sign a document for many of the same reasons why you might place a handwritten signature on a paper document. A digital signature is used to help authenticate the identity of the creator of digital information — such as documents, e-mail messages, and macros — by using cryptographic algorithms.
Digital signatures are based on digital certificates. Digital certificates are verifiers of identity issued by a trusted third party, which is known as a certification authority (CA). This works similarly to the use of printed identity documents. For example, a trusted third party such as a government entity or employer issues identity documents — such as driver’s licenses, passports and employee ID cards — on which other people rely to verify that a person is whom he or she claims to be.
What digital signatures accomplish
Digital signatures help establish the following authentication measures:
Authenticity The digital signature and its underlying digital certificate helps ensure that the signer is whom he or she claims to be. This helps prevent other people from pretending to be the originator of a particular document (the equivalent of forgery on a printed document).
Integrity The digital signature helps ensure that the content has not been changed or tampered with since it was digitally signed. This helps prevent documents from being intercepted and changed without knowledge of the originator of the document.
Non-repudiation The digital signature helps prove to all parties the origin of the signed content. "Repudiation" refers to the act of a signer's denying any association with the signed content. This helps prove that the originator of the document is the true originator and not someone else, regardless of the claims of the signer. A signer cannot repudiate the signature on that document without repudiating his or her digital key and, therefore, other documents signed with that key.
Requirements for digital signatures
To establish these conditions, the content creator must digitally sign the content by creating a signature that satisfies the following criteria:
The digital signature is valid. A CA that is trusted by the operating system must sign the digital certificate on which the digital signature is based.
The certificate that is associated with the digital signature is not expired or contains a time stamp indicating the certificate was valid at the time of signing.
The certificate that is associated with the digital signature is not revoked.
The signing person or organization (known as the publisher) is trusted by the recipient.
Word 2010, Excel 2010, and PowerPoint 2010 detect these criteria for you and warn you if there seems to be a problem with the digital signature. Information about problematic certificates can easily be viewed in a certificate task pane that appears in the Office 2010 application. Office 2010 applications let you add multiple digital signatures to the same document.
Digital signatures in the business environment
The following scenario shows how digital signing of documents can be used in a business environment:
An employee uses Excel 2010 to create an expense report. The employee then creates three signature lines: one for herself, one for her manager, and one for the accounting department. These lines are used to identify that the employee is the originator of the document, that no changes will occur in the document as it moves to the manager and the accounting department, and that there is proof that both the manager and the accounting department have received and reviewed the document.
The manager receives the document and adds her digital signature to the document, confirming that she has reviewed and approved it. She then forwards it to the accounting department for payment.
A representative in the accounting department receives the document and signs it, which confirms receipt of the document.
This example demonstrates the ability to add multiple signatures to a single Office 2010 document. In addition to the digital signature, the signer of the document can add a graphic of her actual signature, or use a Tablet PC to actually write a signature into the signature line in the document. There is also a “rubber stamp” feature that can be used by departments, which indicates that a member of a specific department received the document.
Compatibility issues
Office 2010, just as the 2007 Office system, uses the XML-DSig format for digital signatures. In addition, Office 2010 has added support for XAdES (XML Advanced Electronic Signatures). XAdES is a set of tiered extensions to XML-DSig, the levels of which build upon the previous to provide more reliable digital signatures. For more information about the levels of XAdES that are supported in Office 2010, see Using digital signatures later in this article. For more information about the details of XAdES, see the specification for XML Advanced Electronic Signatures (XAdES) (https://go.microsoft.com/fwlink/p/?LinkId=186631).
It is important to be aware that digital signatures created in Office 2010 are incompatible with versions of Microsoft Office earlier than the 2007 Office system. For example, if a document is signed by using an application in Office 2010 or in the 2007 Office system and opened by using an application in Microsoft Office 2003 that has the Office Compatibility Pack installed, the user will be informed that the document was signed by a newer version of Microsoft Office and the digital signature will be lost.
The following figure shows a warning that the digital signature is removed when the document is opened in an earlier version of Office.
.jpg "Figure 1 Compatibility Issues")
Also, if XAdES is used for the digital signature in Office 2010, the digital signature would not be compatible with the 2007 Office system unless you configure the Group Policy setting, Do not include XAdES reference object in the manifest, and set it to Disabled. For more information about the digital signature Group Policy settings, see Configure digital signatures later in this article.
If you need digital signatures created in Office 2010 to be compatible with Office 2003 and earlier versions, you can configure the Group Policy setting, Legacy format signatures, and set it to Enabled. This Group Policy setting is located under User Configuration\Administrative Templates\(ADM\ADMX)\Microsoft Office 2010\Signing. After this setting is set to Enabled, the Office 2010 applications use the Office 2003 binary format to apply digital signatures to Office 97–2003 binary documents created in Office 2010.
Digital certificate: Self-signed or issued by CAs
Digital certificates can be either self-signed or issued by CAs in an organization, such as a Windows Server 2008 computer that is running Active Directory Certificate Services, or a public CA, such as VeriSign or Thawte. Self-signed certificates are typically used by people and small businesses that do not want to set up a public key infrastructure (PKI) for their organizations and do not want to purchase a commercial certificate.
The primary drawback of using self-signed certificates is that they are only useful if you exchange documents with those who know you personally and are confident that you are the actual originator of the document. By using self-signed certificates, there is no third party that validates the authenticity of your certificate. Each person who receives your signed document must manually decide whether to trust your certificate.
For larger organizations, two primary methods for obtaining digital certificates are available: certificates that are created by using a corporate PKI and commercial certificates. Organizations that want to share signed documents only among other employees in the organization might prefer a corporate PKI to reduce costs. Organizations that want to share signed documents with people outside of their organization might prefer to use commercial certificates.
Certificates created by using a corporate PKI
Organizations have the option to create their own PKI. In this scenario, the company sets up one or more certification authorities (CAs) that can create digital certificates for computers and users throughout the company. When combined with the Active Directory directory service, a company can create a complete PKI solution so that all corporate-managed computers have the corporate CA chain installed and that both users and computers are automatically assigned digital certificates for document signing and encryption. This allows for all employees in a company to automatically trust digital certificates (and, therefore, valid digital signatures) from other employees in the same company.
For more information, see Active Directory Certificate Services (https://go.microsoft.com/fwlink/p/?LinkId=119113).
Commercial certificates
Commercial certificates are purchased from a company whose line of business is to sell digital certificates. The main advantage of using commercial certificates is that the commercial certificate vendor’s root CA certificate is automatically installed on Windows operating systems, which enables these computers to automatically trust these CAs. Unlike the corporate PKI solution, commercial certificates enable you to share your signed documents with users who do not belong to your organization.
There are three kinds of commercial certificates:
Class 1 Class 1 certificates are issued to people who have valid e-mail addresses. Class 1 certificates are appropriate for digital signatures, encryption, and electronic access control for non-commercial transactions where proof of identity is not required.
Class 2 Class 2 certificates are issued to people and devices. Class 2 individual certificates are appropriate for digital signatures, encryption, and electronic access control in transactions where proof of identity based on information in the validating database is sufficient. Class 2 device certificates are appropriate for device authentication; message, software, and content integrity; and confidentiality encryption.
Class 3 Class 3 certificates are issued to people, organizations, servers, devices, and administrators for CAs and root authorities (RAs). Class 3 individual certificates are appropriate for digital signatures, encryption, and access control in transactions where proof of identity must be assured. Class 3 server certificates are appropriate for server authentication; message, software, and content integrity; and confidentiality encryption.
For more information about commercial certificates, see Digital ID – Office Marketplace (https://go.microsoft.com/fwlink/p/?LinkId=119114).
Using digital signatures
You can digitally sign documents by using Microsoft Excel 2010, Microsoft PowerPoint 2010, and Microsoft Word 2010. You can also add a signature line or signature stamp using Excel 2010, Microsoft InfoPath 2010, and Word 2010. Digitally signing a document that has a digital certificate but does not have a signature line or stamp is known as creating an invisible digital signature. Both methods, visible and invisible digital signatures, use a digital certificate for signing the document. The difference is the graphical representation within the document when a visible digital signature line is used. For more information about how to add a digital signature, see Add or remove a digital signature in Office files (https://go.microsoft.com/fwlink/p/?LinkId=187659).
By default, Office 2010 creates XAdES-EPES digital signatures, whether a self-signed certificate or a certificate signed by a CA is used during the creation of the digital signature.
The XAdES digital signature levels, based on the XML-DSig digital signature standard, available in Office 2010 are listed in the following table. Each of the levels builds upon the previous level and contains all the capabilities of the previous levels. For example, XAdES-X also contains all of the capabilities of XAdES-EPES, XAdES-T, and XAdES-C, in addition to the new functionality introduced with XAdES-X.
| Signature level | Description |
|---|---|
XAdES-EPES (Base) |
Adds information about the signing certificate to the XML-DSig signature. This is the default for Office 2010 signatures. |
XAdES-T (Timestamp) |
Adds a time stamp to the XML-DSig and XAdES-EPES sections of the signature, which helps protect against certificate expiration. |
XAdES-C (Complete) |
Adds references to certification chain and revocation status information. |
XAdES-X (Extended) |
Adds a time stamp to the XML-DSig SignatureValue element, and the –T and –C sections of the signature. The additional time stamp protects the additional data from repudiation. |
XAdES-X-L (Extended Long Term) |
Stores the actual certificate and certificate revocation information together with the signature. This allows for certificate validation even if the certificate servers are no longer available. |
Time stamp digital signatures
The ability with Office 2010 to add a time stamp to a digital signature allows for helping to extend the lifespan of a digital signature. For example, if a revoked certificate has previously been used for the creation of the digital signature, which contains a time stamp from a trusted time stamp server, the digital signature could still be considered valid if the time stamp occurred before the revocation of the certificate. To use the time stamp functionality with digital signatures, you must complete the following:
Set up a time stamp server that is compliant with RFC 3161
Use the Group Policy setting, Specify server name, to enter the location of the time stamp server on the network.
You can also configure additional time stamp parameters by configuring one or more of the following Group Policy settings:
Configure time stamping hashing algorithm
Set timestamp server timeout
If you do not configure and enable Configure time stamping hashing algorithm, the default value of SHA1 will be used. If you do not configure and enable Set timestamp server timeout, the default time that Office 2010 will wait for the time stamp server to respond to a request is 5 seconds.
Configure digital signatures
In addition to the Group Policy settings for configuring time stamp related–settings, there are other Group Policy settings to configure how digital signatures are configured and controlled in an organization. The setting names and descriptions are listed in the following table.
| Setting | Description |
|---|---|
Require OCSP at signature generation time |
This policy setting lets you determine whether Office 2010 requires OCSP (Online Certificate Status Protocol) revocation data for all digital certificates in a chain when digital signatures are generated. |
Specify minimum XAdES level for digital signature generation |
This policy setting lets you specify a minimum XAdES level that Office 2010 applications must reach in order to create an XAdES digital signature. If unable to reach the minimum XAdES level, the Office application does not create the signature. |
Check the XAdES portions of a digital signature |
This policy setting lets you specify whether Office 2010 checks the XAdES portions of a digital signature, if present, when validating a digital signature for a document. |
Do not allow expired certificates when validating signatures |
This policy setting lets you configure whether Office 2010 applications accept expired digital certificates when verifying digital signatures. |
Do not include XAdES reference object in the manifest |
This policy setting lets you determine whether an XAdES reference object should appear in the manifest. You must configure this setting to Disabled if you want the 2007 Office system to be able to read Office 2010 signatures that contain XAdES content; otherwise, the 2007 Office system will consider signatures that contain XAdES content invalid. |
Select digital signature hashing algorithm |
This policy setting lets you configure the hashing algorithm that Office 2010 applications use to confirm digital signatures. |
Set signature verification level |
This policy setting lets you set the verification level that is used by Office 2010 applications when validating a digital signature. |
Requested XAdES level for signature generation |
This policy setting lets you specify a requested or desired XAdES level in creating a digital signature. |
Additional digital signature related Group Policy settings are listed as follows:
Key Usage Filtering
Set default image directory
EKU filtering
Legacy format signatures
Suppress Office Signing Providers
Suppress external signature services menu item
For more information about each Group Policy setting, see the help files that are contained with the Administrative Template files for Office 2010. For more information about the Administrative Template files, see Group Policy overview for Office 2010.
Note
For the latest information about policy settings, refer to the Microsoft Excel 2010 workbook Office2010GroupPolicyAndOCTSettings_Reference.xls, which is available in the Files in this Download section on the Office 2010 Administrative Template files (ADM, ADMX, ADML) and Office Customization Tool (https://go.microsoft.com/fwlink/p/?LinkID=189316&clcid=0x409) download page.