Advanced Electronic Signature Profiles of the OASIS Digital Signature Service
2nd Committee Draft, 12 September, 2006 (WD 09)
Document identifier:
oasis-dss-1.0-profiles-AdES-spec-cd-r2
Location:
http://docs.oasis-open.org/dss/v1.0/
Editor:
Juan Carlos Cruellas, individual <cruellas@ac.upc.es>
Contributors:
Nick Pope, individual
Ed Shallow, Universal Post Union
Trevor Perrin, individual
Konrad Lanz, Austria Federal Chancellery <Konrad.Lanz@iaik.tugraz.at>
Abstract:
This draft defines one abstract profile of the OASIS DSS protocols for the purpose of creating and verifying XML or CMS based Advanced Electronic Signatures. It also defines two concrete sub-profiles: one for creating and verifying XML Advanced Electronic Signatures and the other for creating and verifying CMS based Advanced Electronic Signatures.
Status:
This is a Public Review
Draft produced by the OASIS Digital Signature Service Technical Committee.
Comments may be submitted to the TC by any person by clicking on "Send A
Comment" on the TC home page at:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=dss.
For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Digital Signature Service TC web page at http://www.oasis-open.org/committees/dss/ipr.php.
Table of Contents
3 Advanced Electronic Signature abstract profile
3.2.2 Relationship To Other Profiles
3.3 Profile of Signing Protocol
3.3.1.1 Element <OptionalInputs>
3.3.1.1.1.1 Optional Input <SignatureForm>
3.3.1.1.2 Optional Inputs already defined in the Core
3.3.1.1.2.1 Optional Input <SignatureType>
3.3.1.1.2.2 Optional inputs <ClaimedIdentity> and <KeySelector>
3.3.1.1.2.3 Optional Input <SignedProperties>
3.3.1.1.2.3.1 Requesting SigningTime
3.3.1.1.2.3.2 Requesting CommitmentTypeIndication
3.3.1.1.2.3.3 Requesting SignatureProductionPlace
3.3.1.1.2.3.4 Requesting SignerRole
3.3.1.1.2.3.5 Requesting AllDataObjectsTimeStamp
3.3.1.1.2.3.6 Requesting DataObjectFormat
3.3.2.1 Element <SignatureObject>
3.4 Profile of Verifying Protocol
3.4.1.2 Element <SignatureObject>
3.4.1.3 Element <OptionalInputs>
3.4.1.3.1 Element <ReturnUpdatedSignature>
3.5.1.1 Element <OptionalOutputs>
3.5.1.1.1 Optional Output <UpdatedSignature>
4 XML Advanced Electronic Signatures concrete Profile
4.2.3 Relationship To Other Profiles
4.3 Profile of Signing Protocol
4.3.2.1 Element <OptionalInputs>
4.3.2.1.1.1 Element <SignatureForm>
4.3.2.1.2 Optional Inputs already defined in the Core
4.3.2.1.2.1 Optional Input <SignatureType>
4.3.2.1.2.2 Optional inputs < ClaimedIdentity> and <KeySelector>
4.3.2.1.2.3 Optional Input <SignedProperties>
4.3.2.1.2.3.1 Requesting SigningTime
4.3.2.1.2.3.2 Requesting CommitmentTypeIndication
4.3.2.1.2.3.3 Requesting SignatureProductionPlace
4.3.2.1.2.3.4 Requesting SignerRole
4.3.2.1.2.3.5 Requesting AllDataObjectTimeStamp
4.3.2.1.2.3.6 Requesting DataObjectFormat
4.3.2.1.2.3.7 Requesting <xades:IndividualDataObjectTimeStamp>
4.3.3.1 Element <SignatureObject>
4.4 Profile of Verifying Protocol
4.4.1.2 Element <SignatureObject>
4.4.1.3 Element <OptionalInputs>
4.4.1.3.1 Optional Output <ReturnUpdatedSignature>
4.4.2 Element <VerifyResponse>
4.4.2.1 Element <OptionalOutputs>
4.4.2.1.1 Optional Output <UpdatedSignature>
4.5.2.2 TLS X.509 Mutual Authentication
5 CMS-based Advanced Electronic Signature profile
5.2.3 Relationship To Other Profiles
5.3 Profile of Signing Protocol
5.3.1.2 Element <OptionalInputs>
5.3.1.2.1.1 Element <SignatureForm>
5.3.1.2.2 Optional Inputs already defined in the Core
5.3.1.2.2.1 Element <SignatureType>
5.3.1.2.2.2 Optional inputs < ClaimedIdentity> / <KeySelector>
5.3.1.2.2.3 Element <SignedProperties>
5.3.1.2.2.3.1 Requesting signing-time
5.3.1.2.2.3.2 Requesting commitment-type-indication
5.3.1.2.2.3.3 Requesting signer-location
5.3.1.2.2.3.4 Requesting signer-attributes
5.3.1.2.2.3.5 Requesting content-time-stamp
5.3.1.2.2.3.6 Requesting content-hints
5.3.2.1 Element <SignatureObject>
5.4 Profile of Verifying Protocol
5.4.1.2 Element <OptionalInputs>
5.4.1.2.1 Element <ReturnUpdatedSignature>
5.4.1.3 Element <SignatureObject>
5.4.2 Element <VerifyResponse>
5.4.2.1 Element <OptionalOutputs>
5.4.2.1.1 Element <UpdatedSignature>
5.5.2.2 TLS X.509 Mutual Authentication
6 XML timestamps in XAdES signatures
6.1 Generation and inclusion of XML timestamps
6.1.1 Profile for XAdES timestamp containers
6.1.2 XML timestamp within xades:IndividualDataObjectsTimeStamp
6.1.3 XML timestamp within xades:AllDataObjectsTimeStamp
6.1.4 XML timestamp within xades:SigAndRefsTimeStamp
6.1.5 XML timestamp within xades:RefsOnlyTimeStamp
6.1.6 XML timestamp within xades:ArchiveTimeStamp
6.2 Verification of XML timestamps
6.2.1 Verification of of xades:IndividuallDataObjectsTimeStamp including a XML timestamp
6.2.2 Verification of xades:AllDataObjectsTimeStamp including a XML timestamp
6.2.3 Verification of xades:SigAndRefsTimeStamp including a XML timestamp
6.2.4 Verification of xades:RefsOnlyTimeStamp including a XML timestamp
6.2.5 Verification of xades:ArchiveTimeStamp including a XML timestamp
7 Identifiers defined in this specification
7.1 Predefined advanced electronic signature forms identifiers
The DSS signing and verifying protocols are defined in [DSSCore]. As defined in that document, the DSS protocols have a fair degree of flexibility and extensibility. This document defines an abstract profile for the use of the DSS protocols for creating and verifying XML and CMS-based Advanced Electronic Signatures as defined in [XAdES] and [CAdES]. This document also defines two concrete profiles derived from the abstract one: one for creating and verifying XAdES signatures and the other for creating and verifying CAdES signatures.
1.1 Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in IETF RFC 2119 [RFC 2119]. These keywords are capitalized when used to unambiguously specify requirements over protocol features and behavior that affect the interoperability and security of implementations. When these words are not capitalized, they are meant in their natural-language sense.
This specification uses the following typographical conventions in text: <ns:Element>, Attribute, Datatype, OtherCode.
1.2 Namespaces
The structures described in this specification are contained in the schema file [AdES-XSD]. All schema listings in the current document are excerpts from the schema file. In the case of a disagreement between the schema file and this document, the schema file takes precedence.
This schema is associated with the following XML namespace:
urn:oasis:names:tc:dss:1.0:profiles:AdES:schema#
Conventional XML namespace prefixes are used in this document:
o The prefix dss: (or no prefix) stands for the DSS core namespace [Core-XSD].
o The prefix ds: stands for the W3C XML Signature namespace [XMLSig].
o The prefix xades: stands for ETSI XML Advanced Electronic Signatures (XAdES) document [XAdES].
Applications MAY use different namespace prefixes, and MAY use whatever namespace defaulting/scoping conventions they desire, as long as they are compliant with the Namespaces in XML specification [XML-ns].
This document defines three profiles of the protocols specified in: “Digital Signature Services Core Protocol and Elements” [DSSCore].
The first one is an abstract profile defining messages for supporting the lifecycle of advanced electronic signatures. Both, XML and CMS-based advanced electronic signatures are supported by this profile.
One concrete profile, derived from the aforementioned abstract profile, gives support to the lifecycle of XML advanced electronic signatures as specified in [XAdES].
A second concrete profile, also derived from the abstract one, gives support to the lifecycle of CMS-based advanced electronic signatures as specified in [CAdES].
Implementations should implement one of the concrete profiles (or both) in order to request generation or validation of advanced electronic signatures in one of the two formats (or both).
3.1 Overview
This abstract profile supports operations within each phase of the lifecycle of two types of advanced electronic signature:
o XML encoded signatures based on [XMLSig] such as specified in [XAdES].
o Binary encoded signatures based on [RFC 3852] such as specified in [CAdES].
Henceforward, the document will use the term advanced signature when dealing with issues that affect to both types of signatures. The document will use XAdES or CAdES signatures when dealing with issues that affect one or the other but not both of them.
For the generation of advanced signatures, the following operations apply:
o SignRequest. This operation supports requests for:
o Generating predefined advanced signature forms as defined in [XAdES] and [CAdES].
o Generating XML signatures incorporating specific signed/unsigned properties whose combination does not fit any predefined XAdES signature form. In such cases, the form MUST have been defined in a proprietary specification and MUST be identified by one URI.
o Generating CMS signatures incorporating specific signed/unsigned attributes whose combination does not fit any predefined [CAdES] signature form. In such cases, the form MUST have been defined in a proprietary specification and MUST be identified by one URI.
o SignResponse. This operation supports delivery of:
o Predefined advanced signature forms as defined in [XAdES] and [CAdES].
o XML signatures with specific properties whose combination does not fit any predefined XAdES signature form. In such cases, the form MUST have been defined in some other specification and MUST be identified by one URI.
o CMS signatures incorporating specific signed attributes whose combination does not fit any predefined [CAdES] signature form. In such cases, the form MUST have been defined in some other specification and MUST be identified by one URI.
For advanced signature verification (and updating) the following operations apply:
o VerifyRequest. This operation supports requests for:
o Verifying a predefined advanced signature form.
o Verifying XML signatures incorporating specific properties whose combination does not fit any predefined XAdES signature form.
o Verifying any of the signatures mentioned above PLUS updating them by addition of additional properties (time-stamps, validation data, etc) leading to a predefined XAdES form.
o Verifying CMS signatures incorporating specific attributes whose combination does not fit any predefined [CAdES] signature form.
o Verifying any of the signatures mentioned above PLUS updating them by addition of additional attributes (time-stamps, validation data, etc) leading to a predefined [CAdES] form.
o Verifying a long-term advanced signature in a certain point of time.
o VerifyResponse. This operation supports delivery of:
o Advanced signature verification result of signatures mentioned above.
o Advanced signature verification result PLUS the updated signatures as requested.
The material for each operation will clearly indicate the lifecycle phase it pertains to.
3.2 Profile Features
3.2.1 Scope
This document profiles the DSS signing and verifying protocols defined in [DSSCore].
3.2.2 Relationship To Other Profiles
The profile in this document is based on the [DSSCore]. The profile in this document may not be directly implemented. It is further profiled by the two concrete profiles also defined in sections 4 and 5.
3.2.3 Signature Object
This profile supports the creation and verification of advanced signatures as defined in [XAdES] and [CAdES].
This profile also supports update of advanced signatures by addition of unsigned properties (time-stamps and different types of validation data), as specified in [XAdES] and [CAdES].
3.3 Profile of Signing Protocol
The present profile allows requesting:
o Predefined forms of advanced electronic signatures as defined in [XAdES] and [CAdES].
o Other forms of signatures based in [XMLSig] or [RFC 3852] defined in other specifications,
In both cases, the specific requested form will be identified by an URI.
According to this profile, the following predefined advanced signature forms defined in [XAdES] and [CAdES] MAY be requested (those forms whose name begin by XAdES- are forms names for XAdES signatures; those ones whose name begin by CAdES are names for CAdES signatures):
o CAdES-BES and XAdES-BES. In this form, the signing certificate is secured by the signature itself.
o CAdES-EPES and XAdES-EPES. This form incorporates an explicit identifier of the signature policy that will govern the signature generation and verification.
o CAdES-ES-T and XAdES-T. This form incorporates a trusted time, by means of a time-stamp token or a time-mark.
o CAdES-ES-C and XAdES-C.
o CAdES-ES-X and XAdES-X.
o CAdES-ES-X-L and XAdES-X-L.
o CAdES-ES-A and XAdES-A.
In addition, the present profile provides means for requesting incorporation in any of the aforementioned forms any of the signed properties defined in [XAdES] and signed attributes defined in [CAdES].
Other electronic signature forms based in [XMLSig] or [RFC 3852], defined elsewhere, MAY also be requested using the mechanisms defined in this profile.
3.3.1 Element <SignRequest>
This clause profiles the dss:SignRequest element.
3.3.1.1 Element <OptionalInputs>
3.3.1.1.1 New Optional Inputs
3.3.1.1.1.1 Optional Input <SignatureForm>
The form of signature required MAY be indicated using the following new optional input
<xs:element name="SignatureForm" type=”xs:anyURI”/>
If not present the signature form SHALL be implied by the selected <SignaturePolicy> or the signature policy applied by the server.
Section 7.1 of this abstract profile defines a set of URIs identifying the predefined advanced electronic signature forms specified in [CAdES] and [XAdES].
Should other standard or proprietary specification define new signature forms and their corresponding URIs, concrete sub-profiles of this abstract profile could be defined for giving support to their verification and update.
Should a form identified by an URI, admit different properties combinations, the server will produce a specific combination depending on its policy or configuration settings.
3.3.1.1.2 Optional Inputs already defined in the Core
None of the optional inputs specified in the [DSS Core] are precluded in this abstract profile. It only constrains some of them and specifies additional optional inputs.
3.3.1.1.2.1 Optional Input <SignatureType>
This element is OPTIONAL. If present, <SignatureType> SHALL be either:
urn:ietf:rfc:3275
for requesting XML-based signatures, or
urn:ietf:rfc:3369
for requesting CMS-based signatures, as defined in 7.1 of [DSS Core].
If not present the signature type SHALL be implied by the selected <SignaturePolicy> or the signature policy applied by the server.
3.3.1.1.2.2 Optional inputs <ClaimedIdentity> and <KeySelector>
As forms defined in [XAdES] and [CAdES] require that the signing certificate is protected by the signature, the server MUST gain access to that certificate.
<dss:ClaimedIdentity> or <dss:KeySelector> optional inputs MAY be present. If they are not present, the server may use means not specified in this profile to identify the signer’s key and gain access to its certificate.
3.3.1.1.2.3 Optional Input <SignedProperties>
The requester MAY request to the server the addition of optional signed properties using the <dss:SignedProperties> element’s <dss:Property> child profiled as indicated in clauses below. First names correspond to the one given by XAdES to the signed properties. Second ones correspond to the names given by CAdES to the signed attributes.
Signed properties that MAY be requested are:
XAdES |
CAdES |
SigningTime |
signing-time |
CommitmentTypeIndication |
commitment-type-indication |
SignerRole |
signer-attributes |
SignatureProductionPlace |
signer-location |
DataObjectFormat |
content-hints |
AllDataObjectsTimeStamp |
content-time-stamp |
IndividualDataObjectsTimeStamp |
No equivalent signed attribute |
Next sub-sections show how a client should request each of the aforementioned properties-attributes. The type of signature requested (XAdES or CAdES) will determine whether a XAdES property or a CAdES attribute is generated by the server.
3.3.1.1.2.3.1 Requesting SigningTime
Value for <Identifier> element:
urn:oasis:names:tc:dss:1.0:profiles:AdES:SigningTime
If the client does not request such property, the server still MAY generate and include this property depending on its policy.
No content is required for Value element, since the actual contents of the property will be generated by the server when required.
3.3.1.1.2.3.2 Requesting CommitmentTypeIndication
Value for <Identifier> element:
urn:oasis:names:tc:dss:1.0:profiles:AdES:CommitmentTypeIndication
If the client does not request such property, the server still MAY generate and include it with values that depend on server’s policy.
The client MAY request the generation and inclusion of this signed property. In such cases the <Value> element MUST have the following content:
<xs:element name="RequestedCommitment">
<xs:complexType>
<xs:choice>
<xs:element ref="xades:CommitmentTypeIndication"/>
<xs:element name="BinaryValue" type="xs:base64Binary"/>
</xs:choice>
</xs:complexType>
</xs:element>
Element <xades:CommitmentTypeIndication> will be present when requesting a XML signature.
Element <BinaryValue> will be present when requesting an ASN.1 signature. Its contents MUST be the base64 encoding of commitment-type-indication ASN.1 attribute defined in [CAdES], DER-encoded
3.3.1.1.2.3.3 Requesting SignatureProductionPlace
Value for <Identifier> element:
urn:oasis:names:tc:dss:1.0:profiles:AdES:SignatureProductionPlace
The client MAY request a certain value for this property. Nevertheless, this value MAY be ignored by the server depending on its own policy, and the property be set to another value.
For requesting a value for this property, the <Value> element MUST have the following content:
<xs:element name="RequestedSignatureProductionPlace">
<xs:complexType>
<xs:choice>
<xs:element ref="xades:SignatureProductionPlace"/>
<xs:element name="BinaryValue" type="xs:base64Binary"/>
</xs:choice>
</xs:complexType>
</xs:element>
Element <xades:SignatureProductionPlace> will be present when requesting a XML signature.
Element <BinaryValue> will be present when requesting an ASN.1 signature. Its contents MUST be the base64 encoding of SignerLocation ASN.1 attribute defined in [CAdES], DER-encoded.
3.3.1.1.2.3.4 Requesting SignerRole
Value for <Identifier> element:
urn:oasis:names:tc:dss:1.0:profiles:AdES:SignerRole
When the client requests the generation and inclusion of this signed property the <Value> element MUST have the following content:
<xs:element name="RequestedSignerRole">
<xs:complexType>
<xs:choice>
<xs:element ref="xades:SignerRole"/>
<xs:element name="BinaryValue" type="xs:base64Binary"/>
</xs:choice>
</xs:complexType>
</xs:element>
Element <xades:SignerRole> will be present when requesting a XML signature.
Element <BinaryValue> will be present when requesting a ASN.1 signature. Its contents MUST be the base64 encoding of signer-attributes ASN.1 attribute defined in [CAdES], DER-encoded.
3.3.1.1.2.3.5 Requesting AllDataObjectsTimeStamp
This element will be added for requesting the generation and inclusion of a time-stamp token on (all) the data object(s) to be signed.
Value for <Identifier> element:
urn:oasis:names:tc:dss:1.0:profiles:AdES:AllDataObjectsTimeStamp
No content is required for <Value> element, since the actual contents of the property will be generated by the server when required.
3.3.1.1.2.3.6 Requesting DataObjectFormat
Value for Identifier element:
urn:oasis:names:tc:dss:1.0:profiles:AdES:DataObjectFormat
When the client requests the generation and inclusion of this signed property the <Value> element MUST have the following content.
<xs:element name="RequestedDocsFormat" type="DocsFormatType"/>
<xs:complexType name="DocsFormatType">
<xs:sequence>
<xs:choice>
<xs:element name="DocFormat" type="DocFormatType" maxOccurs="unbounded"/>
<xs:element name="BinaryValue" type="xs:base64Binary"/>
</xs:choice>
</xs:sequence>
</xs:complexType>
<xs:complexType name="DocFormatType">
<xs:complexContent>
<xs:extension base="DocReferenceType">
<xs:sequence>
<xs:element ref="xades:DataObjectFormat"/>
</xs: sequence >
</xs:extension>
</xs:complexContent>
</xs:complexType>
Elements <DocFormat> will be present when requesting an XML based signature.
Element <BinaryValue> will be present when requesting a CMS based signature. Its contents MUST be the base64 encoding of content-hints ASN.1 attribute defined in [RFC 2634] DER-encoded.
3.3.2 Element <SignResponse>
This clause profiles the dss:SignResponse element.
3.3.2.1 Element <SignatureObject>
This element SHALL NOT contain a dss:TimeStamp element as a child.
3.3.2.2 Optional Outputs
None of the optional outputs specified in the [DSS Core] are neither precluded nor further profiled in this abstract profile.
3.4 Profile of Verifying Protocol
3.4.1 Element <VerifyRequest>
This clause specifies the profile for the contents of the dss:VerifyRequest when used for:
o Requesting verification of advanced signatures.
o Requesting verification of advanced signatures AND update of signatures to other predefined forms.
3.4.1.1 Attribute Profile
The value for the Profile attribute, indicating the concrete sub-profile of this abstract profile, MUST be present.
3.4.1.2 Element <SignatureObject>
This element SHALL NOT contain a dss:TimeStamp element as a child.
3.4.1.3 Element <OptionalInputs>
None of the optional inputs specified in the [DSS Core] are precluded in this abstract profile. It only constrains some of them and specifies additional optional inputs.
3.4.1.3.1 Element <ReturnUpdatedSignature>
This element MUST be present when the client requests verification of a signature and update to a predefined form of advanced signature.
The Type attribute identifies the advanced signature form requested.
Acceptable predefined values for this attribute are the URIs specified in table 1 corresponding to the following forms predefined in [CAdES] and [XAdES]: XAdES-T/CAdES -T, XAdES-C/CAdES-C, XAdES-X/CAdES-X,XAdES-X-L/CAdES-X-L, XAdES-A/CAdES-A.
Should other standard or proprietary specification define new signature forms and their corresponding URIs, concrete sub-profiles of this abstract profile could be defined for giving support to their verification and update.
When the requested form allows for different contents, the server MUST decide the specific contents of the updated signature delivered, according to its configuration and settings.
3.5 Element <VerifyResponse>
This clause profiles the dss:VerifyResponse element.
3.5.1.1 Element <OptionalOutputs>
None of the optional inputs specified in the [DSS Core] are precluded in this abstract profile. It only constrains some of them.
3.5.1.1.1 Optional Output <UpdatedSignature>
This element SHALL contain a dss:SignatureObject element that SHALL
NOT contain a dss:TimeStamp element as a child.
4.1 Overview
This concrete profile supports operations within each phase of the lifecycle of XML Advanced Electronic Signature based on [XMLSig] such as specified in [XAdES]. It will then provide all the features related to XAdES signatures that are specified in the abstract profile defined in section 3.
For the generation of XAdES signatures, the following operations apply:
o SignRequest. This operation supports requests for:
o Generating predefined advanced signature forms as defined in [XAdES].
o Generating XML signatures incorporating specific signed/unsigned properties whose combination does not fit any predefined XAdES signature form. In such cases, the form MUST have been defined in a proprietary specification and MUST be identified by one URI.
o SignResponse. This operation supports delivery of:
o Predefined advanced signature forms as defined in [XAdES].
o XML signatures with specific properties whose combination does not fit any predefined XAdES signature form. In such cases, the form MUST have been defined in a proprietary specification and MUST be identified by one URI.
For verification [and updating] of XAdES signatures the following operations apply:
o VerifyRequest. This operation supports requests for:
o Verifying a predefined XAdES signature form.
o Verifying XML signatures incorporating specific properties whose combination does not fit any predefined XAdES signature form.
o Verifying any of the signatures mentioned above PLUS updating them by adding unsigned properties (time-stamps, validation data, etc) leading to a predefined XAdES form.
o Verifying a long-term advanced signature in a certain point of time.
o VerifyResponse. This operation supports delivery of:
o Advanced signature verification result of signatures mentioned above.
o Advanced signature verification result PLUS the updated signatures as requested.
4.2 Profile features
4.2.1 Identifier
urn:oasis:names:tc:dss:1.0:profiles:XAdES.
4.2.2 Scope
This document profiles the DSS abstract profile defined in section 3 of the present document.
4.2.3 Relationship To Other Profiles
The profile in this section is based on the abstract profile for Advanced Electronic Signatures defined in section 3.
4.2.4 Signature Object
This profile supports the creation and verification of XML advanced signatures as defined in [XAdES].
This profile also supports verification and update of advanced signatures by addition of unsigned properties (time-stamps and different types of validation data), as specified in [XAdES]
4.2.5 Transport Binding
This profile does not specify or constrain the transport binding.
4.2.6 Security Binding
This profile does not specify or constrain the security binding.
4.3 Profile of Signing Protocol
The present profile allows requesting:
o Predefined forms of advanced electronic signatures as defined in [XAdES]. A server aligned with this profile SHALL generate XAdES signatures with direct incorporation of qualifying properties as defined in [XAdES] section 6.3.
o Other forms of signatures based in [XMLSig] defined in other specifications,
In both cases, the specific requested form will be identified by an URI.
According to this profile, the following predefined advanced signature forms defined in [XAdES] MAY be requested: XAdES-BES, XAdES-EPES, XAdES-T, XAdES-C, XAdES-X, XAdES-X-L., and XAdES-A.
In addition, the present profile provides means for requesting incorporation in any of the aforementioned forms any of the following properties: SigningTime, CommitmentTypeIndication, SignatureProductionPlace, SignerRole