A posting from Robert Zuccherato (Entrust) to the OASIS DSS TC list announces the contribution of three technical specifications from Entrust germane to the work of the OASIS Digital Signature Services Technical Committee. An X-KISS Extension for Digital Signature Verification defines an extension to the XKMS X-KISS protocol that supports the verification of digital signatures. The document Digital Signature Web Service Interface "describes an RPC interface for a centralized digital signature web service that enforces policy controls on who can request signatures for specific transactions. The signature is calculated using a private key owned by the web service for the purpose of producing an 'organization' signature. Thus, anyone within the organization authorized to obtain an 'organization' signature can obtain it simply by request to the web service." A third document Tokens and Protocol for the Temporal Integrity Markup Language (TIML) "defines an XML schema for a timestamping protocol. Its schema is based upon the RFC 3161 ASN.1 timestamping protocol, but uses the XML Signature standard for signature formatting." These three protocols developed at Entrust are believed to meet the requirements for three particular deliverables sketched in the TC's provisional Statement of Purpose.

An X-KISS Extension for Digital Signature Verification. This protocol specification "defines an extension to the XKMS X-KISS [XML Key Information Service Specification] protocol that supports the verification of digital signatures. The <ToBeVerifiedSignature> element specifies the signature to be verified by the X-KISS server. It is included as a child of a <xkms:QueryKeyBinding> or <xkms:KeyBinding> element in a signature verification request or response. It includes one of [several] elements and attributes..."

Digital Signature Web Service Interface. Motivation: A digital signature provides: Authentication, support for Non-repudiation, and data integrity... Most current implementations of digital signatures bind the public key with a specific individual that is responsible for the content of any data signed with the corresponding private key. However, there is a need, especially in the web services paradigm, for signatures that represent "organizations" (not individuals within organizations) and this need is becoming more apparent over time. Distributing the "organization" private key among all end users authorized to use it creates a number of security concerns. It makes sense then to provide a centralized service which applies all "organization" signatures using a private key unique to the organization. Thus, this document describes an RPC interface for a centralized digital signature web service that enforces policy controls on who can request signatures for specific transactions..."

Tokens and Protocol for the Temporal Integrity Markup Language (TIML). In order to support proper verification of digital signatures, the DSS provisional charter identified as one deliverable a "protocol to produce cryptographic time stamps that can be used for determining whether or not a signature was created within the associated public key's validity period or before revocation" was listed. The TIML specification from Entrust "defines an XML schema for a timestamping protocol. The schema is based upon the RFC 3161 ASN.1 timestamping protocol, but uses the XML Signature standard for signature formatting."

From the 2002-11-26 posting:

The Statement of Purpose for the Digital Signature Services Technical Committee explicitly lists three potential deliverables. The first is "a protocol for a digital signature creation web service." Second is "a protocol for a centralized digital signature verification web service that can verify signatures in relation to a given policy set." Finally, in order to support proper verification of digital signatures a "protocol to produce cryptographic time stamps that can be used for determining whether or not a signature was created within the associated public key's validity period or before revocation" was listed.

In this light, as an FYI to the potential members of the group, I would like to submit the attached documents to be considered at the first meeting. They describe protocols that we have developed at Entrust to achieve the objectives above. It is hoped that these documents can be used as a basis for discussion at the first meeting.

Entrust accepts the OASIS rules on contributions to a TC. We are not aware of any IPR on this submission.