12.3 XAdES Signature Elements Syntax

This section describes the elements used to build an XAdES signature.

12.3.1 The SigningTime Element

SigningTime is a time stamp over the entire signature. It uses the schema dateTime type. Only one SigningTime element can appear in the signature. Its schema is as follows:

 <!-- Start SigningTime element --> <xsd:element name="SigningTime" type="xsd:dateTime"/> 

12.3.2 The SigningCertificate Element

The SigningCertificate element is the source of the signer identity. Legal entities can have multiple certificates that the same or different certificate authorities issue containing the same key. As a signed property of the signature, the one SigningCertificate incorporated in an ETSI advanced signature remains protected against substitution so that the identity, policy, and restrictions within the certificate will be accessible to the verifier. Its schema follows:

 <!-- Start SigningCertificate --> <xsd:element name="SigningCertificate"              type="SigningCertificateType"> <xsd:complexType name="SigningCertificateType">   <xsd:sequence>     <xsd:element name="Certs" type="CertIDType"/>                  maxOccurs="unbounded"/>   </xsd:sequence> </xsd:complexType> <xsd:complexType name="CertIDType">   <xsd:sequence>     <xsd:element name="CertDigest"                  type="DigestAlgAndValueType"/>     <xsd:element name="IssuerSerial"                  type="ds:X509IssuerSerialType"/>   </sequence> </xsd:complexType> <xsd:complexType name="DigestAlgAndValueType">   <xsd:sequence>     <xsd:element name="DigestMethod"                  type="ds:DigestMethodType"/>     <xsd:element name="DigestValue"                  type="ds:DigestValueType"/>   </xsd:sequence> </xsd:complexType> 

The first certificate identified by the Certs element is the certificate used to verify the signature. You can omit the issuer and serial number if the sig nature has a KeyInfo element with an X509Data child that contains an X509IssuerSerial element.

Any additional certificates that the Certs element identifies limit the set of authorization certificates that are used during signature validation.

12.3.3 The SignaturePolicyIdentifier Element

An ETSI advanced signature must contain exactly one SignaturePolicyIdentifier element that sets the rules for signature creation and validation and, as a signed property, is cryptographically bound to the signature. Its schema follows:

 <!-- Start SignaturePolicyIdentifier --> <xsd:element name="SignaturePolicyIdentifier"              type="SignaturePolicyIdentifierType"> <xsd:complexType name="SignaturePolicyIdentifierType">   <xsd:choice>     <xsd:element name="SignaturePolicyId"                  type="SignaturePolicyIdType"/>     <xsd:element name="SignaturePolicyImplied">   </xsd:choice> </xsd:complexType> <xsd:complexType name="SignaturePolicyIdType">   <xsd:sequence>     <xsd:element name="SigPolicyId"                  type="ObjectIdentifierType"/>     <xsd:element name="SigPolicyHash"                  type="DigestAlgAndValueType"/>     <xsd:element name="SigPolicyQualifiers"                  type="SigPolicyQualifiersListType"                  minOccurs="0"/>   </xsd:sequence> </xsd:complexType> <xsd:complexType name="SigPolicyQualifiersListType">   <xsd:sequence>     <xsd:element name="SigPolicyQualifier"                  type="AnyType"                  maxOccurs="unbounded"/>   </xsd:sequence> </xsd:complexType> 

The policy may be implied by what is being signed or by external data, for which case the SignaturePolicyImplied empty element is provided.

The SigPolicyID element uniquely identifies a version of the policy.

The optional SigPolicyQualifier element contains information qualifying the signature policy. Two types of such information have been defined to date [RFC 2459]:

• A URL from which a copy of the policy can be obtained

• A user notice to be displayed when the signature is verified

The schema for indicating these values follows:

 Schema Definition: <xsd:element name="SPUri" type="xsd:anyUri"/> <xsd:element name="SPUserNotice"              type="SPUserNoticeType"/> <xsd:complexType name="SPUserNoticeType">   <xsd:sequence>     <xsd:element name="NoticeRef"                  type="NoticeReferenceType"                  minOccurs="0"/>     <xsd:element name="ExplicitText" type="xsd:string"                  minOccurs="0"/>   </xsd:sequence> </xsd:complexType> <xsd:complexType name="NoticeReferenceType">   <xsd:sequence>     <xsd:element name="Organization" type="xsd:string"/>     <xsd:element name="NoticeNumbers"                  type="IntegerListType"/>   </xsd:sequence> </xsd:complexType> <xsd:complexType name="IntegerListType">   <xsd:sequence>     <xsd:element name="int" type="xsd:integer"                  minOccurs="0"                  maxOccurs="unbounded"/>   </xsd:sequence> </xsd:complexType> 

ExplicitText is text to be displayed. NoticeRef is information with which the notice could be extracted from a notices file, if necessary.

12.3.4 The CounterSignature Element

Some signatures may be valid under their signature policy only if they or their signed data are countersigned by appropriate entities. In some cases, the ordering or the determination of whether one party signs the other's signature may not be important, as when two parties sign a contract. In other cases, as a notary attesting to a signature, it may be vital.

Independent parallel signatures can exist as separate signature elements; however, where one signature must cover another, ETSI Advanced XML Signatures provides the CounterSignature element. This element contains one or more signatures and is added as one of the UnsignedProperties of the signature that it covers. The CounterSignature covers the SignatureValue of this signature. A CounterSignature can itself have a CounterSignature, and this layering can continue for any depth needed.

Its schema follows:

 <!-- Start CounterSignature --> <xsd:element name="CounterSignature"              type="CounterSignatureType"/> <xsd:complexType name="CounterSignatureType">   <xsd:sequence>     <xsd:element name="CounterSigInstance"                  ref="ds:SignatureType"   </xsd:sequence> </xsd:complexType> 

12.3.5 The DataObjectFormat Element

In many contexts, it is important to ensure that the user receives data in the format intended by the signer. Otherwise, a bad guy might be able to use some clever "pun." For example, perhaps some data was signed after the signer approved the data in a vector graphics format, but the same data played to the verifier in an audio format means something completely different.

Each DataObjectFormat gives the format of a single signed data item, so multiple DataObjectFormat elements can be included. The element supports lots of format types: a text description for human consumption, an Object Identifier, a MIME type [RFC 2045], and an encoding URI. About the only thing a DataObjectFormat element doesn't provide is a URI encoded type, which can be put in the ds:Type attribute of the ds:Reference element. Thus you can have five different "type" values for the same object.

Having many different type designators for the same object is probably a bad idea. What if they are inconsistent?

The schema for the DataObjectFormat element follows:

 <\!-- Start DataObjectFormat --> <xsd:element name="DataObjectFormat"              type="DataObjectFormatType"/> <xsd:complexType name="DataObjectFormatType">   <xsd:sequence>     <xsd:element name="Description" type="xsd:string"                  minOccurs="0"/>     <xsd:element name="ObjectIdentifier"                  type="ObjectIdentifierType"                  minOccurs="0"/>     <xsd:element name="MimeType" type="xsd:string"                  minOccurs="0"/>     <xsd:element name="Encoding" type="xsd:anyURI"                  minOccurs="0"/>   </xsd:sequence>   <xsd:attribute name="ObjectReference" type="xsd:anyUri"                  use="required"/> </xsd:complexType> 

12.3.6 The CommitmentTypeIndication Element

The CommitmentTypeIndicator says what the signers have bound themselves to. It can be explicit or implied from the semantics of the signed object. If explicit, it can be specified as part of the signature policy or registered for global use.

This SignedSignatureProperty applies to a particular data item, as indicated by the required ObjectReference attribute. Thus multiple CommitmentTypeIndication elements can refer to different data items.

This element's schema follows:

 <!-- Start CommitmentTypeIndication --> <xsd:element name="CommitmentTypeIndication"              type="CommitmentTypeIndicationType"/> <xsd:complexType name="CommitmentTypeIndicationType">   <xsd:sequence>     <xsd:element name="CommitmentTypeId"              type="ObjectIdentifierType"/>     <xsd:choice>       <xsd:element name="ObjectReference"                    type="xsd:anyURI"                    minOccurs="0"                    maxOccurs="unbounded"/>       <xsd:element name="AllSignedDataObjects"/>     </xsd:choice>     <xsd:element name="CommitmentTypeQualifiers"                  type="CommitmentTypeQualifiersListType"                  minOccurs="0"/>   </xsd:sequence> </xsd:complexType> <xsd:complexType name="CommitmentTypeQualifiersListType">   <xsd:sequence>     <xsd:element name="CommitmentTypeQualifier                  type="AnyType"                  minOccurs="0"/>              maxOccurs="unbounded"/>   </xsd:sequence> </xsd:complexType> 

The CommitmentTypeId element precisely identifies the type of commitment made by the signer. ETSI document TS 101 733 defines the following commitment possibilities:

• Proof of origin: a combination of proof of creation, proof of approval, and proof of sender

• Proof of receipt: the signer has received the contents of the signed data object

• Proof of delivery: the signing service provider has placed the signed data object in a local store accessible to the recipient

• Proof of sender: the signer has sent the signed data object (but not necessarily created or approved it)

• Proof of approval: the signer has approved the contents of the signed data object

• Proof of creation: the signer has created the signed data object (but not necessarily approved or sent it)

The CommitmentTypeQualifiers element provides a means to include additional qualifying information on the commitment made by the signer.

12.3.7 The SignatureProductionPlace Element

The SignatureProductionPlace element is a SignedSignatureProperty that can in clude a bunch of information about the signer at the time of the signature. It is optional, and an ETSI signature can include no more than one such element.

 <!-- Start SignatureProductionPlace --> <xsd:element name="SignatureProductionPlace"              type="SignatureProductionPlaceType" /> <xsd:complexType name="SignatureProductionPlaceType">   <xsd:sequence>     <xsd:element name="City"                  type="xsd:string"                  minOccurs="0"/>     <xsd:element name="StateOrProvince"                  type="xsd:string"                  minOccurs="0"/>     <xsd:element name="PostalCode"                  type="xsd:string"                  minOccurs="0"/>     <xsd:element name="CountryName"                  type="xsd:string"                  minOccurs="0"/>   </xsd:sequence> </xsd:complexType> <!-- End SignatureProductionPlace --> 

12.3.8 The SignerRole Element

Sometimes it is critical to know the "role" that someone is playing when he or she signs an object. For example, is the person signing as a vice president authorized to bind a company? The optional SignerRole provides two ways to indicate the signer's role: through a list of claimed roles or through an attribute certificate that binds the signer's identity to a role attribute.

This signed property qualifies the signer. The schema for the SignerRole element follows:

 <!-- Start SignerRole --> <xsd:element name="SignerRole" type="SignerRoleType"> <xsd:complexType name="SignerRoleType">   <xsd:sequence>     <xsd:element name="ClaimedRoles"                  type="ClaimedRolesListType"                  minOccurs="0"/>     <xsd:element name="CertifiedRoles"                  type="CerifiedRolesListType"                  minOccurs="0"/>   </xsd:sequence> </xsd:complexType> <xsd:complexType name="ClaimedRolesListType">   <xsd:sequence>     <xsd:element name="ClaimedRole" type="AnyType"              maxOccurs="unbounded"/>   </xsd:sequence> </xsd:complexType> <xsd:complexType name="CertifiedRolesListType">   <xsd:sequence>     <xsd:element name="CertifiedRole"                  type="EncapsulatedPKIDataType"                  maxOccurs="unbounded"/>   </xsd:sequence> </xsd:complexType> <!-- End SignerRole --> 

12.3.9 The AllDataObjectsTimeStamp and IndividualDataObjects-TimeStamp Elements

These signed properties qualify the signed data object(s) and may occur multiple times in an ETSI signature. Their schema follows:

 Schema Definition: <xsd:element name="AllDataObjectsTimeStamp"              type="TimeStampType"/> <xsd:element name="IndividualObjectsTimeStamp"              type="TimeStampType"/>