5.1 Auxiliary
syntax
The following three auxiliary XML structures are utilized in several
casesin the subsequent clauses.
5.1.1
The AnyType data type
The AnyType schema data type has a content model that allowsa
sequence of arbitrary XML elements that is of unrestricted length.
Additionally, an element of this data type can bear an unrestricted number of
arbitrary attributes. It is used throughout the remaining parts of this
clause wherever the content of an XML element has been left open.
<xsd:complexType name="AnyType" mixed="true">
<xsd:sequence>
<xsd:any namespace="##any"/>
</xsd:sequence>
<xsd:anyAttribute namespace="##any"/>
</xsd:complexType>
|
5.1.2
The ObjectIdentifierType data type
The ObjectIdentifierType data type can be used to identify
aparticular data object.
It allows the specification of an unique and permanent identifier of an
object. In addition, a textual description of the nature of the data object,
and a number of references to documents where additional information about
the nature of the data object can be found.
<xsd:complexType name="ObjectIdentifierType">
<xsd:sequence>
<xsd:element name="Identifier" type="xsd:anyURI"/>
<xsd:element name="Description" type="xsd:string" minOccurs="0"/>
<xsd:element name="DocumentationReferences"
type="DocumentationReferencesType" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
|
The Identifier element contains a permanent identifier. Once
assigned the identifier can never be re-assigned again. It supports both the
mechanism that is used to identify objects in ASN.1 and the mechanism that is
usually used to identify objects in an XML environment:
In ASN.1 an Object IDentifier (OID) is used to identify an object.
To encode an OID using the ObjectIdentifierType, the element
Identifier MUST contain the OID as a Uniform Resource Name
[URN-OID] conforming to the way specified in RFC3061. A textual
representation enabling humans to easily understand the meaning of the
OID MAY be given using the element Description. The present
document does not suggest a particular format for such a textual
representation.
In an XML environment objects are typically identified by means of
an Uniform Resource Identifier [URI]. To encode such a
URI using the ObjectIdentifierType, the element
Identifier MUST be used.
Please note: Since such a URI represenent a PERMANENT identifier,
the URI (scheme, domain name) should be carefully chosen. For example, if
a domain ceases to exist, this will also invalidiate all the identifiers
specified under the domain, since it could happen that the do- main is
reassigned to a different owner who could then change the meaning of the
identifiers. .
Should an OID and an URI exist identifying the same object, the present
document encourages the use of the URI as explained in the first bullet
above.
<xsd:complexType name="IdentifierType">
<xsd:complexContent>
<xsd:extension base="xsd:anyURI">
<xsd:attribute name="Qualifier" type="QualifierType" use="optional"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:simpleType name="QualifierType">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="OIDAsURI"/>
<xsd:enumeration value="OIDAsURN"/>
</xsd:restriction>
</xsd:simpleType>
|
The optional Description element contains an informal
textdescribing the object identifier.
The optional DocumentationReferences element consists of an
arbitrary number of references pointing to further explanatory documentation
of the object identifier.
<xsd:complexType name="DocumentationReferencesType">
<xsd:sequence maxOccurs="unbounded">
<xsd:element name="DocumentationReference" type="xsd:anyURI"/>
</xsd:sequence>
</xsd:complexType>
|
5.1.3
The EncapsulatedPKIDataType data type
The EncapsulatedPKIDataType is used to incorporate a piece
ofPKI data into an XML structure whereas the PKI data is encoded using an
ASN.1 encoding mechanism. Examples of such PKI data that are widely used at
the time being include X509 certificates and revocation lists, OCSP
responses, attribute certificates and time-stamps.
<xsd:complexType name="EncapsulatedPKIDataType">
<xsd:complexContent>
<xsd:extension base="xsd:base64Binary">
<xsd:attribute name="Id" type="xsd:ID" use="optional"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
|
The content of this data type is the piece of PKI data, base64 encoded
asdefined in [XMLDSIG]. The optional ID
attribute can be used to make a reference to an element of this data type.
5.1.4
The TimeStampType data type
Time-Stamps shall be used with XML Advanced Electronic Signatures in
anumber of use cases:
A XML Advanced Electronic Signature with Time-Stamp (XAdES-T)
includes a time-stamp over the XML Advanced Electronic Signature (XAdES)
to protect against repudiation in case of a key compromise.
Two mechanisms are provided for protection against fraudulence in
case of a CA key compromise, obtaining the XAdES-X form:
A time-stamp only over all certificate and revocation
information references of an XML Advanced Electronic Signature with
Complete Validation Data (XAdES-C).
A time-stamp computed over the signature value, the signature
time-stamp and the certificate and revocation information references
present in the XML Advanced Electronic Signature with Complete
Validation Data (XAdES-C).
To provide for long term validity of an XML signature, a time-stamp
can be applied over an XML Advanced Electronic Signature with Extended
Validation Data (XAdES-X-L) to obtain a XAdES-A form. In this case the
time-stamp is called an Archive Time-Stamp. Additional time-stamps can be
added to this XAdES-A as time goes on.
Additionally, time-stamps proving that some or all the data objects
to be signed have been created before some time can also be added as
signed properties to the XAdES.
A time-stamp is obtained by sending the digest value of the given data
tothe Time-Stamp Authority (TSA). The returned time-stamp is a signed data
that contains the digest value, the identity of the TSA, and the time of
stamping. This proves that the given data existed before the time of
stamping.
Time-Stamps specified in the present document will be generated on
selected parts of the XAdES signature element.
Below follows the schema definition for the data type used for all the
time-stamps mentioned above.
<xsd:complexType name="TimeStampType">
<xsd:sequence>
<xsd:element name="HashDataInfo" type="HashDataInfoType"
maxOccurs="unbounded"/>
<xsd:choice>
<xsd:element name="EncapsulatedTimeStamp"
type="EncapsulatedPKIDataType"/>
<xsd:element name="XMLTimeStamp" type="AnyType"/>
</xsd:choice>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="HashDataInfoType">
<xsd:sequence>
<xsd:element name="Transforms" type="ds:TransformsType" minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="uri" type="xsd:anyURI" use="required"/>
</xsd:complexType>
|
Each HashDataInfo element contains an
uriattribute referencing a data object and one
ds:Transforms element indicating the transformations to make to
this data object as described in [XMLDSIG].
The sequence of HashDataInfo elements will be used to produce
the input of the hash computation process whose result will be included in
the time-stamp request to be sent to the TSA.
The actual input to the hash computation is obtained as follows. Each data
object referenced in the sequence of elements HashDataInfo is
transformed according the indications of the corresponding
Transforms element. Once all the referenced data objects have
been transformed, the resulting octets are concatenated in the order in which
the data objects are referenced.
The time-stamp generated by the TSA can be either an ASN.1 data object (as
defined in [TSP], use EncapsulatedTimeStamp), or it can be
encoded as XML (use XMLTimeStamp). Since at the time being there is no
standard for an XML time-stamp, we provide a placeholder for future use.
5.2 Syntax for
XAdES
This clause describes in detail the qualifying properties that can
appearin XAdES and XAdES-T advanced electronic signatures forms as described
in clause 4 Syntax overview.
5.2.1 The
SigningTime element
The SigningTime property specifies the time at which the
signer (purportedly) performed the signing process.
The XML Schema recommendation [XML-schema-part-2] defines an XML type
xsd:dateTime that allows for the inclusion of the required
information. This is the type selected for the SigningTime
element.>
This is a signed property that qualifies the whole signature.
An XML electronic signature aligned with the present document MUST contain
exactly one SigningTime element .
Below follows the schema definition for this element:
<xsd:element name="SigningTime" type="xsd:dateTime"/>
|
5.2.2 The
SigningCertificate element
According to what has been stated in the Introduction clause, anelectronic
signature produced in accordance with the present document incorporates: "a
commitment that has been explicitly endorsed under a signature policy, at a
given time, by a signer under an identifier, e.g. a name or a pseudonym, and
optionally a role".
In many real life environments users will be able to get from different
CAs or even from the same CA, different certificates containing the same
public key for different names. The prime advantage is that a user can use
the same private key for different purposes. Multiple use of the private key
is an advantage when a smart card is used to protect the private key, since
the storage of a smart card is always limited. When several CAs are involved,
each different certificate may contain a different identity, e.g. as a
national or as an employee from a company. Thus when a private key is used
for various purposes, the certificate is needed to clarify the context in
which the private key was used when generating the signature. Where there is
the possibility of multiple use of private keys it is necessary for the
signer to indicate to the verifier the precise certificate to be used.
Many current schemes simply add the certificate after the signed data and
thus are subject to various substitution attacks. An example of a
substitution attack is a "bad" CA that would issue a certificate to someone
with the public key of someone else. If the certificate from the signer was
simply appended to the signature and thus not protected by the signature, any
one could substitute one certificate by another and the message would appear
to be signed by some one else.
In order to counter this kind of attack, the identifier of the certificate
has to be protected by the digital signature from the signer.
The SigningCertificate property is designed to prevent
thesimple substitution of the certificate. This property contains references
to certificates and digest values computed on them.
The certificate used to verify the signature shall be identified in the
sequence; the signature policy may mandate other certificates be present,
that may include all the certificates up to the point of trust.
This is a signed property that qualifies the signature.
An XML electronic signature aligned with the present document MUST contain
exactly one SigningCertificate element .
Below follows the schema definition:
<xsd:element name="SigningCertificate" type="CertIDListType"/>
<xsd:complexType name="CertIDListType">
<xsd:sequence>
<xsd:element name="Cert" 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"/>
</xsd: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 SigningCertificate element contains the
aforementionedsequence of certificate identifiers and digests computed on the
certificates (Cert elements).
The element IssuerSerial contains the identifier of one of
the certificates referenced in the sequence. Should the
ds:X509IssuerSerial element appear in the signature to denote
the same certificate, its value MUST be consistent with the corresponding
IssuerSerial element.
If the signer uses an attribute certificate to associate a role with the
electronic signature, such a certificate MUST be present in the
SignerRole property.
The element CertDigest contains the digest of one of the
certificates referenced in the sequence. It contains two elements:
DigestMethod indicates the digest algorithm and
DigestValue contains the value of the digest.
5.2.3 The
SignaturePolicyIdentifier element
The signature policy is a set of rules for the creation and validation
ofan electronic signature, under which the signature can be determined to be
valid. A given legal/contractual context may recognize a particular signature
policy as meeting its requirements.
The signature policy needs to be available in human readable form so that
it can be assessed to meet the requirements of the legal and contractual
context in which it is being applied.
To facilitate the automatic processing of an electronic signature the
parts of the signature policy which specify the electronic rules for the
creation and validation of the electronic signature also need to be in a
computer processable form.
If no signature policy is identified then the signature may be assumed to
have been generated/verified without any policy constraints, and hence may be
given no specific legal or contractual significance through the context of a
signature policy.
As it has been stated before, any electronic signature claiming alignment
with the present document must contain an unambiguous way allowing the
identification of the Signature. The present document specifies two
alternatives:
The electronic signature can contain an explicit and unambiguous
identifier of a Signature Policy together with a hash value of the
signature policy, so it can be verified that the policy selected by the
signer is the one being used by the verifier. An explicit signature
policy has a globally unique reference, which, in this way, is bound to
an electronic signature by the signer as part of the signature
calculation. In these cases, for a given explicit signature policy there
shall be one definitive form that has a unique binary encoded value.
Finally, a signature policy identified in this way may be qualified by
additional information.
Alternatively, the electronic signature can avoid the inclusion of
the aforementioned identifier and hash value. This will be possible when
the signature policy can be unambiguously derived from the semantics of
the type of data object(s) being signed, and some other information, e.g.
national laws or private contractual agreements, that mention that a
given signature policy must be used for this type of data content. In
such cases, the signature will contain a specific empty element
indicating that this implied way to identify the signature policy is used
instead the identifier and hash value.
The signature policy identifier is a signed property qualifying
thesignature.
An XML electronic signature aligned with the present document MUST contain
exactly one SignaturePolicyIdentifier element.
Below follows the schema definition for this type:
<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 ref="ds:Transforms" minOccurs="0"/>
<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 SignaturePolicyId element will appear when the
signaturepolicy is identified using the first alternative. The
SigPolicyId element contains an identifier that uniquely
identifies a specific version of the signature policy. The
SigPolicyHash element contains the identifier of the hash
algorithm and the hash value of the signature policy. The
SigPolicyQualifier element can contain additional information
qualifying the signature policy identifier. The optional
ds:Transforms element can contain the transformations performed
on the signature policy document before computing its hash. The processing
model for these transformations is described in [XMLDSIG].
Alternatively, the SignaturePolicyImplied element will appear
when the second alternative is used. This empty element indicates that the
data object(s) being signed and other external data imply the signature
policy.
5.2.3.1
Signature policy qualifiers
Two qualifiers for the signature policy have been identified so far:
Below follows the schema definition for these two elements:
<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>
|
The SPUserNotice element is intended for being displayed
whenever the signature is validated. The ExplicitText element
contains the text of the notice to be displayed. Other notices could come
from the organization issuing the signature policy. The
NoticeRef element names an organization and identifies by
numbers (NoticeNumbers element) a group of textual statements
prepared by that organization, so that the application could get the explicit
notices from a notices file.
5.2.4 The
CounterSignature element
Some electronic signatures may only be valid if they bear more than
onesignature. This is the case generally when a contract is signed between
two parties. The ordering of the signatures may or may not be important, i.e.
one may or may not need to be applied before the other.
Several forms of multiple and counter signatures need to be supported,
which fall into two basic categories:
Independent signatures.
Embedded signatures.
Independent signatures are parallel signatures where the ordering of
thesignatures is not important. Therefore an independent signature will not
appear as a CounterSignature property of another independent
one.
Embedded signatures are applied one after the other and are used where the
order the signatures are applied is important. Multiple embedded signatures
are supported using the CounterSignature unsigned property. Each
CounterSignature is carried in one CounterSignature
element added to the Signature element to which the
CounterSignature is applied.
In a qualified Signature the contents of the CounterSignature
element are one or more signatures (i.e. ds:Signature elements)
of the SignatureValue in the qualified
Signature.
A CounterSignature can itself be qualified by a
CounterSignature property. Thus it is possible to construct
arbitrarily long series of countersignatures.
This is a unsigned property that qualifies the signature.
Below follows the schema definition for this element.
<xsd:element name="CounterSignature" type="CounterSignatureType" />
<xsd:complexType name="CounterSignatureType">
<xsd:sequence>
<xsd:element ref="ds:Signature"/>
</xsd:sequence>
</xsd:complexType>
|
The next figure shows a countersigned Signature.
Figure 5. Use of CounterSignature element
5.2.5 The
DataObjectFormat element
When presenting signed data to a human user it may be important that there
is no ambiguity as to the presentation of the signed data object to the
relying party. In order for the appropriate representation (text, sound or
video) to be selected by the relying party a content hint may be indicated by
the signer. If a relying party system does not use the format specified to
present the data object to the relying party, the electronic signature may
not be valid. Such a behaviour may have been established by the signature
policy, for instance.
The DataObjectFormat element provides information that
describes the format of the signed data object. This element MUST be present
when it is mandatory to present the signed data object to human users on
verification. This is a signed property that qualifies one specific signed
data object. In consequence, an XML electronic signature aligned with the
present document MAY contain more than one DataObjectFormat
elements, each one qualifying one signed data object.
Below follows the schema definition for this element.
<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>
|
This element can convey:
Textual information related to the signed data object(s) in element
Description.
An identifier indicating the type of the signed data object(s) in
element ObjectIdentifier.
An indication of the MIME type of the signed data object(s), in
element MimeType.
An indication of the encoding format of the signed data object(s),
in element Encoding.
At least one element of Description,
ObjectIdentifier and MimeType must be present
within the property.
5.2.6 The
CommitmentTypeIndication element
According to what has been stated in the Introduction clause, anelectronic
signature produced in accordance with the present document incorporates: "a
commitment that has been explicitly endorsed under a signature policy, at a
given time, by a signer under an identifier, e.g. a name or a pseudonym, and
optionally a role".
The commitment type can be indicated in the electronic signature
either:
If the indicated commitment type is explicit by means of a commitment
typeindication in the electronic signature, acceptance of a verified
signature implies acceptance of the semantics of that commitment type. The
semantics of explicit commitment types indications shall be specified either
as part of the signature policy or may be registered for generic use across
multiple policies.
If a signature includes a commitment type indication other than one of
those recognized under the signature policy the signature shall be treated as
invalid.
How commitment is indicated using the semantics of the data object being
signed is outside the scope of the present document.
The commitment type may be:
Defined as part of the signature policy, in which case the
commitment type has precise semantics that is defined as part of the
signature policy.
A registered type, in which case the commitment type has precise
semantics defined by registration, under the rules of the registration
authority. Such a registration authority may be a trading association or
a legislative authority.
The definition of a commitment type includes:
The qualifiers can provide more information about the commitment, it
couldprovide, for example, information about the context be it
contractual/legal/application specific.
If an electronic signature does not contain a recognized commitment type
then the semantics of the electronic signature is dependent on the data
object being signed and the context in which it is being used.
This is a signed property that qualifies signed data object(s). In
consequence, an XML electronic signature aligned with the present document
MAY contain more than one CommitmentTypeIndication elements.
Below follows the schema definition for this element.
<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 univocally identifies the type
of commitment made by the signer. A number of commitments have been already
identified in TS 101 733 [ESI] (and consequently assigned
a corresponding OIDs), namely:
Proof of origin indicates that the signer recognizes to have
created, approved and sent the signed data object.
Proof of receipt indicates that signer recognizes to have received
the content of the signed data object.
Proof of delivery indicates that the TSP providing that indication
has delivered a signed data object in a local store accessible to the
recipient of the signed data object.
Proof of sender indicates that the entity providing that indication
has sent the signed data object (but not necessarily created it).
Proof of approval indicates that the signer has approved the content
of the signed data object.
Proof of creation indicates that the signer has created the signed
data object (but not necessarily approved, nor sent it).
One ObjectReference element refers to
oneds:Reference element of the ds:SignedInfo
corresponding with one data object qualified by this property. If some but
not all the signed data objects share the same commitment, one
ObjectReference element MUST appear for each one of them.
However, if all the signed data objects share the same commitment, the
AllSignedDataObjects empty element MUST be present.
The CommitmentTypeQualifiers element provides means to
include additional qualifying information on the commitment made by the
signer.
