Digital Signature Service Core Protocols, Elements, and Bindings
5th Committee Draft, 19 August 2006 (WD-46)
Document identifier:
oasis-dss-1.0-core-spec-cd-r5.doc
Location:
http://docs.oasis-open.org/dss/v1.0/
Editor:
Stefan Drees, individual
Contributors:
Dimitri Andivahis, Surety
Glenn Benson, JPMorganChase
Juan Carlos Cruellas, individual <cruellas@ac.upc.edu>
Carlos Gonzalez-Cadenas, Netfocus, S.L
Frederick Hirsch, Nokia
Pieter Kasselman, Cybertrust
Andreas Kuehne , individual
Konrad Lanz , Austria Federal Chancellery <Konrad.Lanz@iaik.tugraz.at>
Tommy Lindberg, individual
Paul Madsen, Entrust
John Messing, American Bar Association
Tim Moses, Entrust
Trevor Perrin, individual
Nick Pope, individual
Rich Salz, DataPower
Ed Shallow, Universal Postal Union
Abstract:
This document defines XML request/response protocols for signing and verifying XML documents and other data. It also defines an XML timestamp format, and an XML signature property for use with these protocols. Finally, it defines transport and security bindings for the protocols.
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
1.2 Schema Organization and Namespaces
1.3 DSS Overview (Non-normative)
2.2 Type InternationalStringType
2.3 Type saml:NameIdentifierType
2.4.3 Element <TransformedData>
2.7 Elements <OptionalInputs> and <OptionalOutputs>
2.8.1 Optional Input <ServicePolicy>
2.8.2 Optional Input <ClaimedIdentity>
2.8.3 Optional Input <Language>
2.8.4 Optional Input <AdditionalProfile>
2.8.5 Optional Input <Schemas>
2.9.1 Optional Output <Schemas>
3.3 Processing for XML Signatures
3.3.1 Basic Process for <Base64XML>
3.3.2 Process Variant for <InlineXML>
3.3.3 Process Variant for <EscapedXML>
3.3.4 Process Variant for <Base64Data>
3.3.5 Process Variant for <TransformedData>
3.3.6 Process Variant for <DocumentHash>
3.4 Basic Processing for CMS Signatures
3.4.1 Process Variant for <DocumentHash>
3.5 Optional Inputs and Outputs
3.5.1 Optional Input <SignatureType>
3.5.2 Optional Input <AddTimestamp>
3.5.3 Optional Input <IntendedAudience>
3.5.4 Optional Input <KeySelector>
3.5.5 Optional Input <Properties>
3.5.6 Optional Input <IncludeObject>
3.5.7 Optional Input <IncludeEContent>
3.5.8 Enveloped Signatures, Optional Input <SignaturePlacement> and Output <DocumentWithSignature>
3.5.9 Optional Input <SignedReferences>
4.3 Basic Processing for XML Signatures
4.3.1 Multi-Signature Verification
4.3.2 Signature Timestamp verification procedure
4.4 Basic Processing for CMS Signatures
4.5 Optional Inputs and Outputs
4.5.1 Optional Input <VerifyManifests> and Output <VerifyManifestResults>
4.5.2 Optional Input <UseVerificationTime>
4.5.3 Optional Input/Output <ReturnVerificationTimeInfo> / <VerificationTimeInfo>
4.5.4 Optional Input <AdditionalKeyInfo>
4.5.5 Optional Input <ReturnProcessingDetails> and Output <ProcessingDetails>
4.5.6 Optional Input <ReturnSigningTimeInfo> and Output <SigningTimeInfo>
4.5.7 Optional Input <ReturnSignerIdentity> and Output <SignerIdentity>
4.5.9 Optional Input <ReturnTransformedDocument> and Output <TransformedDocument>
5.2 Element <RequesterIdentity>
6.1 HTTP POST Transport Binding
6.2 SOAP 1.2 Transport Binding
6.3.1 TLS X.509 Server Authentication
6.3.2 TLS X.509 Mutual Authentication
6.3.4 TLS SRP and X.509 Server Authentication
7.1 Signature Type Identifiers
Appendix A. Use of Exclusive Canonicalization
Appendix B. More Complex <Response> Example
This specification defines the XML syntax and semantics for the Digital Signature Service core protocols, and for some associated core elements. The core protocols support the server-based creation and verification of different types of signatures and timestamps. The core elements include an XML timestamp format, and an XML signature property to contain a representation of a client’s identity.
The core protocols are typically bound into other protocols for transport and security, such as HTTP and TLS. This document provides an initial set of bindings. The core protocols are also typically profiled to constrain optional features and add additional features. Other specifications are being produced which profile the core for particular application scenarios.
The following sections describe how to understand the rest of this specification.
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: <DSSElement> , <ns:ForeignElement> , Attribute , Datatype, OtherCode .
Listings of DSS schemas appear like this.
1.2 Schema Organization and Namespaces
The structures described in this specification are contained in the schema file [Core-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:core:schema
If a future version of this specification is needed, it will use a different namespace.
Conventional XML namespace prefixes are used in the schema:
- The prefix dss: stands for the DSS core namespace [Core-XSD].
- The prefix ds: stands for the W3C XML Signature namespace [XMLDSIG].
- The prefix xs: stands for the W3C XML Schema namespace [Schema1].
- The prefix saml: stands for the OASIS SAML Schema namespace [SAMLCore1.1] .
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].
The following schema fragment defines the XML namespaces and other header information for the DSS core schema:
<xs:schema xmlns:dss ="urn:oasis:names:tc:dss:1.0:core:schema"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
targetNamespace="urn:oasis:names:tc:dss:1.0:core:schema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
1.3 DSS Overview (Non-normative)
This specification describes two XML-based request/response protocols – a signing protocol and a verifying protocol. Through these protocols a client can send documents (or document hashes) to a server and receive back a signature on the documents; or send documents (or document hashes) and a signature to a server, and receive back an answer on whether the signature verifies the documents.
These operations could be useful in a variety of contexts – for example, they could allow clients to access a single corporate key for signing press releases, with centralized access control, auditing, and archiving of signature requests. They could also allow clients to create and verify signatures without needing complex client software and configuration.
The signing and verifying protocols are chiefly designed to support the creation and verification of XML signatures [XMLDSIG], XML timestamps (see section 5.1), binary timestamps [RFC 3161] and CMS signatures [RFC3369]. These protocols may also be extensible to other types of signatures and timestamps, such as PGP signatures [RFC 2440].
It is expected that the signing and verifying protocols will be profiled to meet many different application scenarios. In anticipation of this, these protocols have only a minimal set of required elements, which deal with transferring “input documents” and signatures back and forth between client and server. The input documents to be signed or verified can be transferred in their entirety, or the client can hash the documents themselves and only send the hash values, to save bandwidth and protect the confidentiality of the document content.
All functionality besides transferring input documents and signatures is relegated to a framework of “optional inputs” and “optional outputs”. This document defines a number of optional inputs and outputs. Profiles of these protocols can pick and choose which optional inputs and outputs to support, and can introduce their own optional inputs and outputs when they need functionality not anticipated by this specification.
Examples of optional inputs to the signing protocol include: what type of signature to produce, which key to sign with, who the signature is intended for, and what signed and unsigned properties to place in the signature. Examples of optional inputs to the verifying protocol include: the time for which the client would like to know the signature’s validity status, additional validation data necessary to verify the signature (such as certificates and CRLs), and requests for the server to return information such as the signer’s name or the signing time.
The signing and verifying protocol messages must be transferred over some underlying protocol(s) which provide message transport and security. A binding specifies how to use the signing and verifying protocols with some underlying protocol, such as HTTP POST or TLS. Section 6 provides an initial set of bindings.
In addition to defining the signing and verifying protocols, this specification defines two XML elements that are related to these protocols. First, an XML timestamp element is defined in section 5.1. The signing and verifying protocols can be used to create and verify both XML and binary timestamps; a profile for doing so is defined in [XML-TSP]. Second, a RequesterIdentity element is defined in section 5.2. This element can be used as a signature property in an XML signature, to give the name of the end-user who requested the signature.
The following sections describe XML structures and types that are used in multiple places.
2.1 Type AnyType
The AnyType complex type allows arbitrary XML element content within an element of this type (see section 3.2.1 Element Content [XML]).
< xs:complexType name ="AnyType">
< xs:sequence>
<xs:any processContents="lax"
minOccurs="0"
maxOccurs="unbounded"/>
</ xs:sequence>
</ xs:complexType>
2.2 Type InternationalStringType
The InternationalStringType complex type attaches an xml:lang attribute to a human-readable string to specify the string’s language.
< xs:complexType name ="InternationalStringType">
< xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="xml:lang" use="required">
</xs:extension base="xs:string">
</ xs:simpleContent>
</ xs:complexType>
2.3 Type saml:NameIdentifierType
The saml:NameIdentifierType complex type is used where different types of names are needed (such as email addresses, Distinguished Names, etc.). This type is borrowed from [SAMLCore1.1] section 2.4.2.2. It consists of a string with the following attributes:
NameQualifier [Optional]
The security or administrative domain that qualifies the name of the subject. This attribute provides a means to federate names from disparate user stores without collision.
Format [Optional]
A URI reference representing the format in which the string is provided. See section 7.3 of [SAMLCore1.1] for some URI references that may be used as the value of the Format attribute.
2.4 Element <InputDocuments>
The <InputDocuments> element is used to send input documents to a DSS server, whether for signing or verifying. An input document can be any piece of data that can be used as input to a signature or timestamp calculation. An input document can even be a signature or timestamp (for example, a pre-existing signature can be counter-signed or timestamped). An input document could also be a <ds:Manifest> , allowing the client to handle manifest creation while using the server to create the rest of the signature. Manifest validation is supported by an optional input / output.
The <InputDocuments> element consists of any number of the following elements:
<Document> [Any Number]
It contains a document as specified in section 2.4.2 of this document.
<TransformedData> [Any Number]
This contains the binary output of a chain of transforms applied by a client as specified in section 2.4.3 of this document.
<DocumentHash> [Any Number]
This contains the hash value of an XML document or some other data after a client has applied a sequence of transforms and also computed a hash value as specified in section 2.4.4 of this document.
<Other>
Other may contain arbitrary content that may be specified in a profile and can also be used to extend the Protocol for details see section 2.1.
< xs:element name ="InputDocuments">
< xs:complexType >
<xs:sequence>
<xs:choice minOccurs="1" maxOccurs="unbounded">
<xs:element ref="dss:Document"/>
<xs:element ref="dss:TransformedData"/>
<xs:element ref="dss:DocumentHash"/>
<xs:element name="Other" type="dss:AnyType"/>
</xs:choice>
</xs:sequence>
</ xs:complexType >
</ xs:element>
When using DSS to create or verify XML signatures, each input document will usually correspond to a single <ds:Reference> element. Thus, in the descriptions below of the <Document> , <TransformedData> and <DocumentHash> elements, it is explained how certain elements and attributes of a <Document> , <TransformedData> and <DocumentHash> correspond to components of a <ds:Reference> .
2.4.1 Type DocumentBaseType
The DocumentBaseType complex type is subclassed by <Document> , <TransformedData> and <DocumentHash> elements. It contains the basic information shared by subclasses and remaining persistent during the process from input document retrieval until digest calculation for the relevant document. It contains the following elements and attributes:
ID [Optional]
This identifier gives the input document a unique label within a particular request message. Through this identifier, an optional input (see sections 2.7, 3.5.6 and 3.5.8) can refer to a particular input document.
RefURI [Optional]
This specifies the value for a <ds:Reference> element’s URI attribute when referring to this input document. The RefURI attribute SHOULD be specified; no more than one RefURI attribute may be omitted in a single signing request.
RefType [Optional]
This specifies the value for a <ds:Reference> element’s Type attribute when referring to this input document.
SchemaRefs [Optional]:
The identified schemas are to be used to identify ID attributes during parsing in sections 2.5.2, 3.3.1 1.a and 4.3 and for XPath evaluation in sections 2.6, 3.5.7, 4.3.1. If anything else but <Schema> are referred to, the server MUST report an error. If a referred to <Schema> is not used by the XML document instance this MAY be ignored or reported to the client in the <Result> / <ResultMessage> (for the definition of <Schema> see 2.8.5 or 2.9.1 on <Schemas>) .
The Document is assumed to be valid against the first <Schema> referred to by SchemaRefs .
If a <Schemas> element is referred to first by SchemaRefs the document is assumed to be valid against the first <Schema> inside <Schemas>. In both cases, the remaining schemas may occur in any order and are used either directly or indirectly by the first schema.
If present, the server MUST use the schemas to identify the ID attributes and MAY also perform complete validation against the schemas.
< xs:complexType name ="DocumentBaseType" abstract ="true">
< xs:attribute name ="ID" type ="xs:ID" use ="optional"/>
< xs:attribute name ="RefURI" type ="xs:ID" use ="optional"/>
< xs:attribute name ="RefType" type ="xs:ID" use ="optional"/>
< xs:attribute name ="SchemaRefs" type ="xs:IDREFS" use ="optional"/>
</ xs:complexType>
Note: It is recommended to use xml:id as defined in [xml:id] as id in the payload being referenced by a <ds:Reference> , because the schema then does not have to be supplied for identifying the ID attributes.
2.4.2 Element <Document>
The <Document> element may contain the following elements (in addition to the common ones listed in section 2.4.1):
If the content inside one of the following mutually exclusive elements <InlineXML>, <EscapedXML> or <Base64XML> is not parseable XML data, after appropriate decoding, then the server MUST return a <Result> (section 2.6) issuing a <ResultMajor> RequesterError qualified by a <ResultMinor> NotParseableXMLDocument .
The server MUST use the <Schema> referred by <SchemaRefs> for validation if specified.
<Base64XML> [Optional] [Default]
This contains a base64 string obtained after base64 encoding of a XML data. The server MUST decode it to obtain the XML data.
<InlineXML> [Optional]
The InlineXMLType clearly expresses the fact, that content of <InlineXML> is inline XML that should be equivalent to a complete XML Document. I.e. having only one DocumentElement (see section 2.1 Well-Formed XML Documents [XML]) and not allowing anything but PI's and Comments before and after this one element.
It may contain the ignorePIs and ignoreComments attributes. These attributes apply to the complete document and indicate respectively, if processing instructions or comments MAY be ignored.
If one or both of these attributes are not present, their values MUST be considered to be "true".
InlineXML will work with PIs and/or Comments if ignorePIs and ignoreComments are false respectively and if the server supports such behavior.
<EscapedXML> [Optional]
This contains an escaped string. The server MUST unescape (escape sequences are processed to produce original XML sequence) it for obtaining XML data.
<Base64Data> [Optional]
This contains a base64 encoding of data that are not XML. The type of data is specified by its MimeType attribute, that may be required when using DSS with other signature types.
< xs:element name ="Document" type ="dss:DocumentType"/>
< xs:complexType name ="DocumentType">
< xs:complexContent>
< xs:extension base ="dss:DocumentBaseType">
< xs:choice>
<xs:element name="InlineXML" type="dss:InlineXMLType"/>
<xs:element name="Base64XML" type="xs:base64Binary"/>
<xs:element name="EscapedXML" type="xs:string"/>
<xs:element ref="dss:Base64Data"/>
</ xs:choice>
</ xs:extension>
</ xs:complexContent>
</ xs:complexType>
< xs:element name ="Base64Data">
< xs:complexType>
< xs:simpleContent>
<xs:extension base="xs:base64Binary">
<xs:attribute name="MimeType" type="xs:string"
use="optional">
</xs:extension>
</ xs:simpleContent>
</ xs:complexType>
</ xs:element>
< xs:complexType name ="InlineXMLType">
< xs:sequence>
<xs:any processContents="lax"/>
</ xs:sequence>
<xs:attribute
name="ignorePIs”
type="xs:boolean"
use="optional" default="true"/>
<xs:attribute
name="ignoreComments"
type="xs:boolean"
use="optional" default="true"/>
</ xs:complexType>
2.4.3 Element <TransformedData>
The <TransformedData> element contains the following elements (in addition to the common ones listed in section 2.4.1):
<ds:Transforms> [Optional]
This is the sequence of transforms applied by the client and specifies the value for a <ds:Reference> element’s <ds:Transforms> child element. In other words, this specifies transforms that the client has already applied to the input document before the server will hash it.
<Base64Data> [Required]
This gives the binary output of a sequence of transforms to be hashed at the server side.
< xs:element name ="TransformedData">
< xs:complexType>
< xs:complexContent>
<xs:extension base="dss:DocumentBaseType">
<xs:sequence>
<xs:element ref="ds:Transforms" minOccurs="0"/>
<xs:element ref="dss:Base64Data"/>
</xs:sequence>
</xs:extension>
</ xs:complexContent>
</ xs:complexType>
</ xs:element>
2.4.4 Element <DocumentHash>
The <DocumentHash> element contains the following elements (in addition to the common ones listed in section 2.4.1):
<ds:Transforms> [Optional]
This specifies the value for a <ds:Reference> element’s <ds:Transforms> child element when referring to this document hash. In other words, this specifies transforms that the client has already applied to the input document before hashing it.
<ds:DigestMethod> [Required]
This identifies the digest algorithm used to hash the document at the client side. This specifies the value for a <ds:Reference> element’s <ds:DigestMethod> child element when referring to this input document.
<ds:DigestValue> [Required]
This gives the document’s hash value. This specifies the value for a <ds:Reference> element’s <ds:DigestValue> child element when referring to this input document.
< xs:element name ="DocumentHash">
< xs:complexType>
< xs:complexContent>
<xs:extension base="dss:DocumentBaseType">
<xs:sequence>
<xs:element ref="ds:Transforms" minOccurs="0"/>
<xs:element ref="ds:DigestMethod"/>
<xs:element ref="ds:DigestValue"/>
</xs:sequence>
</xs:extension>
</ xs:complexContent>
</ xs:complexType>
</ xs:element>
2.5 Element <SignatureObject>
The <SignatureObject> element contains a signature or timestamp of some sort. This element is returned in a sign response message, and sent in a verify request message. It may contain one of the following child elements:
<ds:Signature> [Optional]
An XML signature [XMLDSIG].
<Timestamp> [Optional]
An XML, RFC 3161 or other timestamp (see section 5.1).
<Base64Signature> [Optional]
A base64 encoding of some non-XML signature, such as a PGP [RFC 2440] or CMS [RFC 3369] signature. The type of signature is specified by its Type attribute (see section 7.1).
<SignaturePtr> [Optional]
This is used to point to an XML signature in an input (for a verify request) or output (for a sign response) document in which a signature is enveloped.
SchemaRefs [Optional]
As described above in 2.4.1
A <SignaturePtr> contains the following attributes:
WhichDocument [Required]
This identifies the input document as in section 2.4.2 being pointed at (see also ID attribute in section 2.4.1).
XPath [Optional]
a) This identifies the signature element being pointed at.
b) The XPath expression is evaluated from the root node (see section 5.1 of [XPATH]) of the document identified by WhichDocument after the XML data was extracted and parsed if necessary. The context node for the XPath evaluation is the document’s DocumentElement (see section 2.1 Well-Formed XML Documents [XML]).
c) About namespace declarations for the expression necessary for evaluation see section 1 of [XPATH]. Namespace prefixes used in XPath expressions MUST be declared within the element containing the XPath expression. E.g.: <SignaturePtr xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" XPath="//ds:Signature"> . See also the following example below. A piece of a XML signature of a < ds:Reference> containing a < ds:Transforms> with a XPath filtering element that includes inline namespace prefixes declaration. This piece of text comes from one of the signatures that were generated in the course of the interoperability experimentation. As one can see they are added to the < ds:XPath> element:
<Reference URI="">
<Transforms>
<ds:Transform xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
<ds:XPath xmlns:upc1="http://www.ac.upc.edu/namespaces/ns1"
xmlns:upc2="http://www.ac.upc.edu/namespaces/ns2">ancestor-or-self::upc1:Root</ds:XPath>
</ds:Transform>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>24xf8vfP3xJ40akfFAnEVM/zxXY=</DigestValue>
</Reference>
If the XPath does not evaluate to one element the server MUST return a <Result> (section 2.6) issuing a <ResultMajor> RequesterError qualified by a <ResultMinor> XPathEvaluationError .
<Other>
Other may contain arbitrary content that may be specified in a profile and can also be used to extend the Protocol.
The following schema fragment defines the <SignatureObject> , <Base64Signature> , and <SignaturePtr> elements:
< xs:element name ="SignatureObject">
< xs:complexType>
<xs:sequence>
<xs:choice>
<xs:element ref="ds:Signature"/>
<xs:element ref="dss:Timestamp"/>
<xs:element ref="dss:Base64Signature"/>
<xs:element ref="dss:SignaturePtr"/>
<xs:element name ="Other" ref =" dss:AnyType "/>
</xs:choice>
</xs:sequence>
< xs:attribute name ="SchemaRefs" type ="xs:IDREFS" use ="optional"/>
</ xs:complexType >
</ xs:element >
< xs:element name ="Base64Signature">
< xs:complexType>
< xs:simpleContent>
<xs:extension base="xs:base64Binary">
<xs:attribute name="Type" type="xs:anyURI"/>
</xs:extension>
</ xs:simpleContent>
</ xs:complexType>
</ xs:element>
< xs:element name ="SignaturePtr">
< xs:complexType>
<xs:attribute name="WhichDocument" type="xs:IDREF"/>
<xs:attribute name="XPath" type="xs:string" use="optional"/>
</ xs:complexType>
</ xs:element>
2.6 Element <Result>
The <Result> element is returned with every response message. It contains the following child elements:
<ResultMajor> [Required]
The most significant component of the result code.
<ResultMinor> [Optional]
The least significant component of the result code.
<ResultMessage> [Optional]
A message which MAY be returned to an operator, logged, used for debugging, etc.
< xs:element name ="Result">
< xs:complexType>
< xs:sequence>
<xs:element name="ResultMajor" type="xs:anyURI"/>
<xs:element name="ResultMinor" type="xs:anyURI"
minOccurs="0"/>
<xs:element name="ResultMessage"
type="InternationalStringType" minOccurs="0"/>
</xs:sequence>
</ xs:complexType>
</ xs:element>
The <ResultMajor> URIs MUST be values defined by this specification or by some profile of this specification. The <ResultMajor> values defined by this specification are:
urn:oasis:names:tc:dss:1.0:resultmajor:Success
The protocol executed successfully.
urn:oasis:names:tc:dss:1.0:resultmajor:RequesterError
The request could not be satisfied due to an error on the part of the requester.
urn:oasis:names:tc:dss:1.0:resultmajor:ResponderError
The request could not be satisfied due to an error on the part of the responder.
urn:oasis:names:tc:dss:1.0:resultmajor:InsufficientInformation
The request could not be satisfied due to insufficient information.
In case of doubt of who is responsible a urn:oasis:names:tc:dss:1.0:resultmajor:ResponderError is assumed.
This specification defines the following <ResultMinor> values, that are listed below, grouped by the respective associated <ResultMajor> code.
One of the following <ResultMinor> values MUST be returned when the <ResultMajor> code is Success.
urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:OnAllDocuments
The signature or timestamp is valid. Furthermore, the signature or timestamp covers all of the input documents just as they were passed in by the client.
urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:NotAllDocumentsReferenced
The signature or timestamp is valid. However, the signature or timestamp does not cover all of the input documents that were passed in by the client.
urn:oasis:names:tc:dss:1.0:resultminor:invalid:IncorrectSignature
The signature fails to verify, for example due to the signed document being modified or the incorrect key being used.
urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:HasManifestResults
The
signature is valid with respect to XML Signature core
validation. In addition, the message also contains
VerifyManifestResults
.
Note: In the case that the core signature validation failed no
attempt is made to verify the manifest.
urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:InvalidSignatureTimestamp
The signature is valid however the timestamp on that signature is invalid.
The following <ResultMinor> values is suggest MAY be returned when the <ResultMajor> code is RequesterError .
urn:oasis:names:tc:dss:1.0:resultminor:ReferencedDocumentNotPresent
A ds:Reference element is present in the ds:Signature containing a full URI, but the corresponding input document is not present in the request.
urn:oasis:names:tc:dss:1.0:resultminor:KeyInfoNotProvided
The required key information was not supplied by the client, but the server expected it to do so.
urn:oasis:names:tc:dss:1.0:resultminor:MoreThanOneRefUriOmitted
The server was not able to create a signature because more than one RefUri was omitted.
urn:oasis:names:tc:dss:1.0:resultminor:InvalidRefURI
The value of the RefURI attribute included in an input document is not valid.
urn:oasis:names:tc:dss:1.0:resultminor:NotParseableXMLDocument
The server was not able to parse a Document.
urn:oasis:names:tc:dss:1.0:resultminor:NotSupported
The server doesn’t recognize or can’t handle any optional input.
urn:oasis:names:tc:dss:1.0:resultminor:Inappropriate:signature
The
signature or its contents are not appropriate in the current
context.
For example, the signature may be associated with a signature
policy and semantics which the DSS server considers
unsatisfactory.
Further values
for
<ResultMinor>
associated with
<ResultMajor>
code
urn:oasis:names:tc:dss:1.0:resultmajor:RequesterError
are left open to the
implementer or profile to be defined with in their
namespaces.
The following <ResultMinor> values MAY be returned when the <ResultMajor> code is ResponderError.
urn:oasis:names:tc:dss:1.0:resultminor:GeneralError
The processing of the request failed due to an error not covered by the existing error codes. Further details should be given in the result message for the user which may be passed on to the relevant administrator.
urn:oasis:names:tc:dss:1.0:resultminor:invalid:KeyLookupFailed
Locating the identified key failed (e.g. look up failed in directory or in local key file).
Further values
for
<ResultMinor>
associated with
<ResultMajor>
code
urn:oasis:names:tc:dss:1.0:resultmajor:ResponderError
are left open to the
implementer or profile to be defined within their
namespaces.
The following <ResultMinor> values MAY be returned when the <ResultMajor> code is InsufficientInformation .
urn:oasis:names:tc:dss:1.0:resultminor:CrlNotAvailiable
The relevant certificate revocation list was not available for checking.
urn:oasis:names:tc:dss:1.0:resultm