CP RSS Channel
About Our Sponsors
Articles & Papers
Technology and Society
Overview from the W3C XML Digital Signatures Activity Statement: "Digital signatures are created and verified using cryptography, the branch of applied mathematics concerned with transforming messages into seemingly unintelligible forms and then back again. Digital signatures are created by performing an operation on information such that others can confirm that a holder of a secret performed the operation and that the signed information has not subsequently changed. In a symmetric key system, both the sender and receiver need to be privy to the secret. In the public key cryptographic system, the holder of the private (secret) key signs information, but anyone with access to the public key can confirm that the signature is valid. The novel feature of public key cryptography is that knowledge of the public key used to confirm signatures does not reveal information about the private key itself."
The CEN/ISSS Workshop on Electronic Signatures (WS/E-Sign) operates under the jurisdiction of Comité Européen de Normalisation [CEN], European Committee for Standardization. "CEN's Information Society Standardization System (CEN/ISSS) is responsible for the part of the EESSI work programme dealing with quality and functional standards for Signature Creation and Verification products, as well as quality and functional standards for Certification Service Providers (CSPs). In the fast-moving domain of information and communications technologies (ICT), CEN/ISSS makes use of a Workshop mechanism, in addition to the traditional CEN Technical Committees. CEN/ISSS Workshops are open to all interested parties. They operate by consensus and produce specifications, pre-Standards, guidance and other material. Their deliverables are published by CEN as CEN Workshop Agreements (CWAs)."
"In the framework of the European Electronic Signature Standardization Initiative (EESSI) implementation phase, CEN/ISSS and ETSI/SEC have been entrusted with the execution of the work programme. The work areas were identified and their contents elaborated in the course of the first phase of EESSI. The core element in the definition of the work programme is a report drawn up by a Team of Experts, highlighting the key recommendations for standards-setting in the area of Electronic Signatures. The work items assigned to CEN/ISSS for identification of standardization requirements and for proposals of standards-setting work have been carried out within the Electronic Signatures (E-SIGN) Workshop..."
See: Business Plan for the CEN/ISSS Workshop on Electronic Signatures. CEN/ISSS WS/E-SIGN 2002-2003. [cache]
Several of the CEN/ISSS Electronic Signatures specifications are available online; see the Electronic signatures section in the list of CEN Workshop Agreements.
Drafts and Deliverables: Snapshot 2002-10-21; CEN Workshop Agreement drafts as developed and approved by WS/E-Sign for download and comment:
- CWA 14355: Guidelines for the implementation of Secure Signature-Creation Devices; Version 0.91, 2001-12-17 (approved) N 0183rev.
- CWA 14365: Guide on the Use of Electronic Signatures, Version 1.1, 26 September 2002 N 0221
- Comment Resolution on CWA 14365: General Requirements for Electronic Signatures, V.066, May 06 2002 (WSES N 0196) N 0203
- CEN/ISSS WS/E-Sign: Terminolgy for EESSI documents N 123
- CWA 14167-1 Security Requirements for Trustworthy Systems Managing Certificates for Electronic Signatures (approved 2001-08-24) N 161
- Revised CWA 14167-1 Security Requirements for Trustworthy Systems Managing Certificates for Electronic Signatures; for electronic voting (voting terminates on 2002-09-23) N 0210
- Draft CWA 14167-2: Cryptographic Module for CSP Signing Operations - Protection Profile (MCSO-PP); V 0.18 (approved) N 178
- Draft CWA 14167-3: Cryptographic Module for CSP Key Generation Services -- Protection Profile -- CMCKG-PP; Version 0.07, 2002-07-24 (published for comment) N 0206
- CWA 14168 Secure Signatur-Creation Devices, version 'EAL 4', 2001-03-01 (approved) N 136
- CWA 14169 Secure Signatur-Creation Devices, version 'EAL 4+', 2001-03-01 (approved) N 137
- Explanatory memorandum concerning the two versions of the CWA Drafts on Area F, 2000-11-29 N 118
- Memorandum: CC-Evaluation of WS/E-Sign CWA Area F (approved) N 177
- CWA 14170 Security Requirements for Signature Creation Systems; Version 3.0, 2000-10-08 (approved) N 141
- CWA 14171 Procedures for Electronic Signature Verification; V 1.0.5, 2001-03-13 (approved) N 140
- Working Draft: Application Interface for SmartCards used as Secure Signature Creation Devices, Version 0.8 Release 0, 12th March 2002 N 0195
- Inventory of European Economic Area Member State Strategies for implementation of European Directive 1999/93/EC, 2000-08-30 N 72
- Minimum criteria to be taken into account by Member States when designating bodies in accordance with Article 3 (4) of Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999 on a Community framework for electronic signatures, 2000-11-28 N 112
- CWA 14172-1 EESSI Conformity Assessment Guidance: Part 1 - General, 2001-03-15 (approved) N 143
- CWA 14172-2 EESSI Conformity Assessment Guidance: Part 2 - Certification Authority services and processes, 2001-03-15 (approved) N 144
- CWA 14172-3 EESSI Conformity Assessment Guidance: Part 3 - Trustworthy systems managing certificates for electronic signatures (approved) N 170
- CWA 14172-4 EESSI Conformity Assessment Guidance: Part 4 - Signature creation applications and procedures for electronic signature verification (approved) N 165
- CWA 14172-5 EESSI Conformity Assessment Guidance: Part 5 - Secure signature creation devices (approved)
ETSI Electronic Signatures and Infrastructures (EESSI Program). "ETSI SEC is responsible for Electronic Signatures and Infrastructures standardization within ETSI. The ESI Working Group of ETSI SEC is in charge of executing the program. there are currently 2 Special Task Forces assisting in this activity. The work is done is close co-operation with CEN/ISSS within the ITCSB/EESSI work programme... ETSI (the European Telecommunications Standards Institute) is a not for profit organization whose mission is to produce the telecommunications standards that will be used for decades to come throughout Europe and beyond. Based in Sophia Antipolis, south of France, ETSI unites 912 members from 54 countries inside and outside Europe, and represents administrations, network operators, manufacturers, service providers, research bodies and users."
Specialist Task Force 155. European standardization initiatives in support of business self-regulation. Electronic signature infrastructure standardization. "The object of STF155 is to progress the standardization of electronic signature infrastructure in response to the new mandate (M/290). The tasks follow the proposed work programme set out by the Electronic Signatures Standardization Initiative (EESSI) and support the implementation of the EC Directive in electronic signatures in accordance with the commonly agreed work repartition between ETSI and CEN... STF155 produced the following deliverables for the European Commission:  DTS/SEC-004007-2 (Task 1): Policy requirements for certification authorities issuing qualified certificates;  DTS/SEC-004001 (Task 2): Electronic signature formats;  DTS/SEC-004003 (Task 3): Profile to qualified certificates X.509;  DTS/SEC-004004 (Task 4): Time stamping profile;  DTR/SEC-004015 (Task 6): Intern. Harmonisation of Policy Requirements for CAs issuing Certificates;  RTS/SEC-004013 (Task 7): Maintenance TS 101 456.
For 'ETSI TR 102 038' and 'ETSI TS 101 903' as two XML-related specifications, see: ETSI Releases Draft Technical Report on XML Format for Signature Policies:
TC Security - Electronic Signatures and Infrastructures (ESI). XML Format for Signature Policies. From: European Telecommunications Standards Institute. Prepared by the ETSI Technical Committee Security (SEC). ETSI Technical Report. Reference: ETSI TR 102 038, V1.1.1 (2002-04); DTR/SEC-004011. 26 pages. "The present document represents a very first version of a XML format for Signature Policies able to contain information on Signature Policies as specified by TS 101 733."
XML Advanced Electronic Signatures (XAdES). ETSI TS 101 903 V1.1.1 (2002-02) ETSI Technical Specification. Reference: ETSI TS 101 903, V1.1.1 (2002-02); DTS/SEC-004008. 70 pages. Normative Annex B presents the XML schema; Annex C contains the XML DTD. "The present document defines XML formats for advanced electronic signatures that remain valid over long periods, are compliant the European Directive and incorporate additional useful information in common uses cases. This includes evidence as to its validity even if the signer or verifying party later attempts to deny (repudiates) the validity of the signature. The present document is based on the use of public key cryptography to produce digital signatures, supported by public key certificates."
Time Stamping Profile. Technical Specification ETSI TS 101 861 V1.1.1 (2001-08). Produced by ETSI Technical Committee Security (SEC). Time Stamping is critical for electronic signatures in order to know whether the digital signature was affixed during the validity period of the certificate. To this respect, electronic signatures must be time stamped during the life time of the corresponding certificate. A Time Stamp Protocol has been defined by the IETF. The present document limits the number of options by placing some additional constraints... The profile is based on the Time Stamp Protocol (TSP) from the IETF, RFC 3161 . It defines what a Time Stamping client must support and what a Time Stamping Server must support."
Electronic signature formats. ETSI TS 101 733 V1.3.1. February 2002. 103 pages. "The present document defines an electronic signature that remains valid over long periods. This includes evidence as to its validity even if the signer or verifying party later attempts to deny (repudiates) the validity of the signature. The present document specifies use of trusted service providers (e.g., TimeStamping Authorities), and the data that needs to be archived (e.g., cross certificates and revocation lists) to meet the requirements of long term electronic signatures. An electronic signature defined by the present document can be used for arbitration in case of a dispute between the signer and verifier, which may occur at some later time, even years later. The present document uses a signature policy, referenced by the signer, as the basis for establishing the validity of an electronic signature. The present document is based on the use of public key cryptography to produce digital signatures, supported by public key certificates."
Telecommunications Security: Electronic Signature Standardization Report. Draft TR 101 xxx V0.4.2 (1998-11). Technical Report. 30 pages.
ETSI SEC Publications listing:
Phase 3 Publications
- XML format for signature policies - TR 102 038 (April 2002)
- Policy requirements for time-stamping authorities - TS 102 023 (April 2002)
- Policy requirements for certification authorities issuing public key certificates - TS 102 042 (April 2002)
- Policy requirements for certification authorities issuing qualified certificates - TS 101 456 v 1.2.1 (April 2002)
- Provision of harmonized Trust Service Provider status information - TR 102 030 (April 2002)
- FAQ (March 2002)
- International Harmonization of Policy Requirements for CAs issuing Certificates - TR 102 040 (March 2002)
- Time stamping profile - TS 101 861 v1.2.1 (March 2002)
- Signature Policies Report - TR 102 041 (February 2002)
- XML Advanced Electronic Signatures (XAdES) - TS 101 903 (February 2002)
- Electronic Signature Formats - TS 101 733 v 1.3.1 (February 2002)
Phase 1 and 2 Publications
- Time Stamping Profile - TS 101 861 v 1.1.1 (September 2001)
- Qualified Certificate Profile - TS 101 862 v 1.2.1 (June 2001)
- Policy requirement for certification authorities issuing qualified certificates TS 101 456 v 1.1.1 (December 2000)
- Qualified Certificate Profile - TS 101 862 v 1.1.1 (December 2000)
- Electronic Signature Formats - TS 101 733 v 1.2.2 (December 2000)
- Electronic Signature Formats - ETSI ES 201 733 v 1.1.3 (May 2000
Digital signature specifications from various IETF Working Groups. This section not complete. The IETF XML Digital Signatures Working Group is a joint WG with W3C's XML Signature Working Group; see below.
"ECDSA with XML-Signature Syntax." IETF Internet Draft. By Simon Blake-Wilson (BCI), Gregor Karlinger (Chief Information Office Austria), and Yongge Wang (University of North Carolina at Charlotte). June 30, 2002. Reference: 'draft-blake-wilson-xmldsig-ecdsa-03.txt'. Appendix A provides the Aggregate XML Schema; Appendix B provides the Aggregate DTD. "This document specifies how to use ECDSA (Elliptic Curve Digital Signature Algorithm) with [IETF/W3C] XML Signatures. The mechanism specified provides integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or included by reference. [cache]
Digital Signatures for the v1.0 Internet Open Trading Protocol (IOTP). IETF Request for Comments, 2802. April 2000. Produced by the IETF Internet Open Trading Protocol Working Group. "The objective of this document is to propose syntax and procedures for the computation and verification of digital signatures applicable to Version 1.0 IOTP protocol messages, providing for: (1) Authentication of IOTP transactions (2) Provide a means by which an IOTP message may be made "tamper-proof", or detection of tampering is made evident (3) Describe a set of available digest and signature algorithms at least one of which is mandatory to implement for interoperability (4) Easily integrate within the IOTP 1.0 Specification (5) Provide lightweight signatures with minimal redundancy (6) Allow signed portions of IOTP message to be "forwarded" to another trading roles with different signature algorithms than the original recipient.." See: Digital Signatures for Internet Open Trading Protocol (IOTP)
Digest Values for DOM (DOMHASH). IETF Request for Comments, 2803. April 2000. "This memo defines a clear and unambiguous definition of digest (hash) values of the XML objects regardless of the surface string variation of XML. This definition can be used for XML digital signature as well efficient replication of XML objects... There are at least two usage scenarios of DOMHASH. One is as a basis for digital signatures for XML. Digital signature algorithms normally require hashing a signed content before signing. DOMHASH provides a concrete definition of the hash value calculation. The other is to use DOMHASH when synchronizing two DOM structures..." Produced by the IETF Internet Open Trading Protocol Working Group. Earlier references: Digest Values for DOM (DOMHASH).
"The mission of the XML Signature Working Group is to develop an XML compliant syntax used for representing the signature of Web resources and portions of protocol messages (anything referencable by a URI) and procedures for computing and verifying such signatures. This is a joint Working Group of the IETF and W3C.
"The mission of the XML Key Management Working Group working group is to develop a specification of XML application/protocol that allows a simple client to obtain key information (values, certificates, management or trust data) from a web service."
General Reference documents
Several ISO/IEC standards relevant to digital signatures are listed/described at the Diffuse website:
- ISO 9796 Digital signature schemes giving message recovery
- ISO 9797 Message Authentication Codes
- ISO 9979 Registration of Cryptographic Algorithms
- ISO 10118 Hash-functions
- ISO 11770 Key Management
- ISO 13888 Non-repudiation
- ISO 14888 Digital signatures with appendix
- ISO 15946 Cryptographic techniques based on elliptic curves
JCP is an "open, participative process to develop and revise the Java technology specifications, reference implementations, and test suites, the Java Community Process (JCP) program has fostered the evolution of the Java platform in cooperation with the international Java developer community."
"The OASIS Digital Signature Services Technical Committee (DSS) will develop techniques to support the processing of digital signatures. This includes defining an interface for requesting that a web service produce and/or verify a digital signature on a given piece of data and techniques for proving that a signature was created within its private key validity period."
The DSS proposal says: "Many efforts related to digital signatures and related technologies are underway throughout the industry. The following work may be relevant to this Digital Signature Services TC:
[November 26, 2002] Entrust Contributes Digital Signature Protocol Specifications to OASIS DSS TC. 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.
[November 27, 2002] Schema/DTD for Response from a Digital Signature Verification Web Service. Posted to the OASIS DSS TC list by Manoj K. Srivastava (Infomosaic Corporation) on 2002-11-27. "I would like to submit the following DTD / XSD for response from a digital signature verification web service. You can try a signature verification web service, which follows the above schema, hosted by Infomosaic. See the text version.
[Section not complete]
"Specifications for the Digital Signature Standard (DSS)." [US] Federal Information Processing Standards Publication (FIPS) 186-2. U.S. Department Of Commerce / National Institute of Standards and Technology (NIST). 2000-January-27. 76 pages. "This publication prescribes three algorithms suitable for digital signature (ds) generation and verification. The first algorithm, the Digital Signature Algorithm (DSA), is described in sections 4 - 6 and appendices 1 - 5. The second algorithm, the RSA ds algorithm, is discussed in section 7 and the third algorithm, the ECDSA algorithm, is discussed in section 8 and recommended elliptic curves in appendix 6." [cache]
ISO/IEC 15945:2002. Information technology -- Security techniques -- Specification of TTP services to support the application of digital signatures. JTC 1/SC 27. See the description from Diffuse: "ISO/IEC 15945 / ITU-T X.843 defines those TTP services needed to support the application of digital signatures in commercial applications. It also defines interfaces and protocols to enable interoperability between entities associated with these TTP services."
ANSI X9.31-1998: Digital Signatures Using Reversible Public Key Cryptography for the Financial Services Industry (rDSA). Covers both the manual and automated management of keying material using both asymmetric and symmetric key cryptography for the wholesale financial services industry. ANSI X9.31 contains the complete specification for the RSA signature algorithm.
ANSI X9.55-1997: Public Key Cryptography for the Financial Services Industry; Extensions to Public Key Certificates and Certificate Revocation Lists. As standards for public key certificates evolve, this standard extends the certificate with provisions to facilitate explicit management of certificates, certification paths, security policies, and transfer-of-trust so that non-hierarchical infrastructures are practical and manageable.
American Bar Association Digital Signature Guidelines. "The "Guidelines" describe a system for ensuring the identity of the holder of a private key, for making digital signatures as usable in commerce and in legal proceedings as a written signature on paper, and for ascribing appropriate responsibility to those engaged in electronic commerce should one of the parties involved deny liability under the transaction."
[November 05, 2002] PKI Forum Continues Security Advocacy as an OASIS PKI Member Section. OASIS has announced the expansion of its Member Section Program to include the PKI Forum. The newest OASIS Member Section, PKI Forum "will continue to advance the use of the Public-Key Infrastructure (PKI) as a foundation for secure transactions in e-business and Web services applications. As a security advocacy group, the PKI Forum brings technology and service providers, integrators and end-users together to accelerate the adoption and use of PKI applications, digital certificates and other real world solutions, as well as to facilitate interoperability through multi-vendor testing of industry standards and educational outreach. Established in 1999, PKI Forum serves as a global information resource for PKI and advocates cooperation and market awareness enabling organizations to understand and exploit the value of PKI in applications relevant to their businesses. Under the new organizational structure, members of PKI Forum will join OASIS and be eligible to contribute to all OASIS technical work. Existing OASIS members will have the option to participate in PKI committee activities without additional membership dues. PKI committees will be formed and operate under the OASIS technical process. The PKI Forum Executive Board will continue to guide the alliance as the OASIS PKI Member Section Steering Committee. Members include Derek Brink of RSA Security, Peter Doyle of Baltimore Technologies, John Sabo of Computer Associates, Mitch Arnone of Schlumberger Network Solutions, Patrick Gen Kanaishi of Neucom, Terry Leahy of Wells Fargo, and Jeff Stapleton of KPMG."
[October 17, 2002] "Yes, You Can Secure Your Web Services Documents, Part 2. XML Signature Ensures Your XML Documents' Integrity." By Ray Djajadinata. In Java World (October 11, 2002). ['In the first installment of this two-part series, Ray Djajadinata discussed the foundation of confidentiality for WS-Security: XML Encryption. In this second installment, he introduces XML Digital Signature, a standard that handles a document's integrity. He explains the standard, what you should know about it, and shows how to write XML Signature code using an implementation currently available: IBM XML Security Suite.'] "In this article, we look closer at the integrity part of the equation: XML Signature, which turns out to be a bit more complicated than its confidentiality counterpart... The main difference between XML Signature and other digital signature standards such as PKCS#7 (Public-Key Cryptography Standard #7) is that it is XML-aware. That is, with XML Signature, not only can you sign arbitrary digital content as a whole, but you can also sign just specific parts of XML documents. This proves useful when parts of XML documents can be moved, copied, encrypted, signed, and verified in any order, which is quite likely to happen as we move more towards shuffling around XML messages instead of binary payload over the wire. However, as you will see later, XML awareness doesn't come free. Compared to XML Signature, XML Encryption is relatively straightforward. You select some nodes to encrypt, and that's basically it. You decrypt the ciphertext with the correct key, and you retrieve the plaintext -- as simple as that. Not so with XML Signature! XML Signature is more complicated because signatures need to be verified correctly... As of now, XML Signature is already more developed than its cousin XML Encryption. The official Java API for XML Signature should be coming out soon, so be on the look out; JavaOne 2002 featured a high-level overview of the API, and from the look of it, I gather it will be quite easy to learn and use. For example, the API features a class called XMLSignatureMarshaller, which converts XML Signatures to/from XML. If this is not the template feature we've come to know, I don't know what is. The API also includes Transforms, URIDereferencer, and so on, whose names, after reading this article, should clue you in to their functionalities. Last but not least, XML Signature operates under the assumption that key distribution and registration has already been handled. This article's examples are trivial -- we created the key and then used it to verify the signatures. In the real world, things are definitely more complicated. Keys must be registered and distributed properly, and trust relationships must be established. XKMS (XML Key Management Specification), related to Java Specification Request 104, tries to address these issues. In any case, many new and interesting things are emerging from XML security, and with its strong tie to Web services security, you can bet an official Java API will follow soon..." See also Part 1, "XML Encryption Keeps Your XML Documents Safe and Secure." General references in "XML Digital Signature (Signed XML - IETF/W3C)."
[October 07, 2002] "Designing Web Services with XML Signatures." By Mark Young (Kamiak Corp). In Web Services Journal Volume 2, Issue 10 (October 2002), pages 10-12. [Note: Kamiak supports the Omniopera WSDL and Schema Editor, reviewed in XML Journal.] "XML signatures apply digital signatures to XML documents. Digital signatures let parties that exchange data ensure the identity of the sender and the integrity of the data. This last item is a benefit that physical signatures can't provide. Digital signatures don't have the legal status that physical signatures have, at least not yet. Over the last few years this has been changing, as the federal government and many state governments have moved to accept digital signatures as legally binding for some applications, where they identify the sender and provide nonrepudiation (the signer can't deny ever having signed). Since Web services that use SOAP exchange XML documents, they can include XML signatures. Web service developers who produce Web services with XML signatures will be able to realize the benefits of those signatures, and may be able to use them in place of physical signatures where the legal community has agreed they are binding. Putting XML signatures into a Web service, however, is not trivial. In this article I'll provide some background on XML signatures, and then explore how you can incorporate them into your Web services. I'll develop an example Web service, written in Java for Apache Axis, that uses an XML signature, to illustrate how it can be done..." See: (1) W3C XML Digital Signatures Activity Statement; (2) local references in "XML Digital Signature (Signed XML - IETF/W3C)."
[August 29, 2002] "Internet Open Trading Protocol Version 2 Requirements." By Donald E. Eastlake 3rd (Motorola). Request for Comments (RFC): 3354. Date: August 2002. I-D Tag: 'draft-ietf-trade-iotp2-req-02.txt'. "This document gives requirements for the Internet Open Trading Protocol (IOTP) Version 2 by describing design principles and scope and dividing features into those which will, may, or will not be included. Version 2 of the IOTP will extend the interoperable framework for Internet commerce capabilities of Version 1 while replacing the XML messaging and digital signature part of IOTP v1 with standards based mechanisms... IOTP v2 will provide optional authentication via standards based XML Digital Signatures [RFC 3275]; however, neither IOTP v1 nor v2 provide a confidentiality mechanism. Both require the use of secure channels such as those provided by TLS [RFC 2246] or IPSEC for confidentiality and depend on the security mechanisms of any payment system used in conjunction with them to secure payments..." WG description from the charter: "The Internet Open Trading Protocol is an interoperable framework for Internet commerce. It is optimized for the case where the buyer and the merchant do not have a prior acquaintance and is payment system independent. It can encapsulate and support payment systems such as SET, Mondex, secure channel card payment, GeldKarte, etc. IOTP is able to handle cases where such merchant roles as the shopping site, the payment handler, the deliverer of goods or services, and the provider of customer support are performed by different Internet sites. The working group will document interoperability experience with IOTP version 1 (which has been published as an Informational RFC) and develop the requirements and specifications for IOTP version 2. Version 2 will make use of an independent Messaging Layer and utilize standard XML Digital Signatures." See (1) Internet Open Trading Protocol (Trade) Working Group; (2) "Internet Open Trading Protocol (IOTP)." [cache]
[August 07, 2002] "Getting Started With XML Security." By Frederick Hirsch. July 31, 2002. With 32 references. From a collection of referenced papers. "Meeting security requirements for privacy, confidentiality and integrity is essential in order to move business online. With the growing acceptance of XML technologies for documents and protocols, it is logical that security should be integrated with XML solutions. The XML Security standards define XML vocabularies and processing rules in order to meet security requirements. These standards use legacy cryptographic and security technologies, as well as emerging XML technologies, to provide a flexible, extensible and practical solution toward meeting security requirements. The XML Security standards include XML Digital Signature for integrity and signing solutions, XML Encryption for confidentiality, XML Key Management (XKMS) for public key registration, location and validation, Security Assertion Markup Language (SAML) for conveying authentication, authorization and attribute assertions, XML Access Control Markup Language (XACML) for defining access control rules, and Platform for Privacy Preferences (P3P) for defining privacy policies and preferences. Major use cases include securing Web Services (WS-Security) and Digital Rights Management (eXtensible Rights Markup Language 2.0 - XrML)... [Conclusion:] The XML Security standards define XML languages and processing rules for meeting common security requirements. For the most part, these standards incorporate the use of the other XML Security standards, especially the core XML Digital Signature and XML Encryption standards. Another example is the sharing of policy statements by SAML and XACML. This set of interlocking standards has emerged quickly, and, since it is based on a foundation of accepted practices and technologies, should mature quickly. This article has presented a brief introduction to the set of standards and how they work together. XML Security standards will be essential to moving business online as XML technologies are adopted for Web Services, Digital Rights Management and other emerging applications. Understanding of how XML may meet authentication, authorization, confidentiality, integrity, signature and privacy requirements will be essential..." (1) "Security, Privacy, and Personalization" and (2) "XML and Digital Rights Management (DRM)." [cache 2002-08-07]
[June 21, 2002] "Securing Your J2ME/MIDP Apps. How to digitally sign and verify XML documents on wireless devices using the Bouncy Castle Crypto APIs." By Michael Juntao Yuan (Research Associate, Center for Research in Electronic Commerce, University of Texas at Austin). From IBM developerWorks, Java technology. June 2002. ['XML digital signature technology can help you implement lightweight and flexible security solutions for wireless Web services applications. In this article, Michael Yuan discusses the importance of XML digital signatures and their application. He also walks through the digital signature APIs of the Bouncy Castle cryptography package, providing examples in the context of secure XML messaging between a J2ME/MIDP wireless front end and a JSP page back end.'] "The XML digital signature is a W3C specification to add a digital signature to an XML document. The sender can choose to digitally sign the entire document or only part of it. Digital signatures, digests, and public keys are formatted into XML elements. Those extra elements of security information can envelop the entire original XML message, or alternatively they can be embedded into the original message. In this article, I will use the enveloping format for convenience. For the sake of clarity, the XML digital signature examples I use in this article are not completely W3C compliant. For example, I have left out the canonicalization (standardization of XML tags) part because it only ensures the conformity of XML documents and has nothing to do with security itself. Also, instead of using encoded public keys certificates, I break a key into several parameters and pass those parameters in separate XML elements under the public key element KeyInfo. That establishes more obvious connections between keys and the Java code that handles them. IBM alphaWorks develops a Java package called XML Security Suite, which supports the latest XML digital signature specification. JSR 105 is a community effort to standardize a set of Java APIs to process XML digital signatures. However, they only work for Java 2 Standard Edition (J2SE), which means that you can use XML Security Suite or JSR 105 Java XML digital signature APIs on the server side, but not on the MIDP wireless device side. ... Wrapup In this article, you learned the importance of security in wireless Web services and illustrated techniques to process XML digital signatures on both the wireless and the Web services sides. I used the pure Java implementation of Bouncy Castle Java cryptography package to handle digital signatures. Of all the algorithms Bouncy Castle offers, only the RSA algorithm offers marginally acceptable performance on wireless devices. However, future advancement in MIDP runtime environment could make digital signatures more readily available to mobile users..."
[May 16, 2002] "Biometric based Digital Signature Scheme." By Rohas Nagpal and Shuchi Nagpal (Asian School of Cyber Laws, India). IETF Internet-Draft. Intended Category: Informational. Reference: 'draft-nagpal-biometric-digital-signature-00.txt'. May 2002; expires: October 2002. "Digital Signatures are fast emerging as a viable information security solution, satiating the objectives of data integrity, entity authentication, privacy, non-repudiation and certification. The technique, as it stands today, faces the problem of the maintenance of the secrecy of the private key. This document provides a conceptual framework for the establishment of a biometric-based key generation scheme. In this scheme, the private key is generated each time a document or record requires to be signed. Such generation is based upon a combination of biometric traits... Biometrics is the use of some physiological or behavioural characteristics for authentication and identification. This technique of authentication is based upon the fact that certain characteristics are never the same in any two people. Biometric recognition systems operate in two modes: one is the identification where the system identifies a person by searching a large database for a match and the other the authentication mode where the systems verifies a person's claimed identity by checking against a previously entered pattern. The techniques included in this method of identification are retina scanning, iris scanning, fingerprint verification, voice verification, facial analysis etc. Biometric based authentication schemes are utilized in sectors like Public services, Law Enforcement and Banking... The authors propose a biometric-based key generation scheme, [in] which a private key of the person would be generated every time that the person wishes to sign (or for that matter decrypt) a record. His public key, on the other hand will always be taken from the records of the bank (or other Government appointed agency) where the key pair was first generated. An elaborate key revocation protocol would have to be worked out based upon current practices with relevant modifications. The private key should be allowed to sign as long as the iris, retina and fingerprint of the person are in adequate physical proximity to the system. Once that proximity is lost, the private key should be permanently erased by the system. This method of key generation would ensure the trust of the public in cryptography and digital signatures to a much larger extent. It would be possible to utilize this method in many applications requiring authentication or identification..." See also: "XML Common Biometric Format (XCBF)." [cache]
[May 03, 2002] "Privacy and XML, Part 2." By Paul Madsen and Carlisle Adams. From XML.com. May 01, 2002. ['Examining XML-based initiatives for controlling and describing online privacy: Paul Madsen and Carlisle Adams discuss P3P, XACML, XML Encryption and Signature, WS-Security, and SAML. Two weeks ago we published an introduction to privacy issues on the Web. This week we're publishing the follow-up to this article, which describes how XML is being used to address the issue of online privacy.] "There are a number of efforts currently underway in standards bodies and other organizations to address various aspects of privacy with XML-based technologies. (1) P3P The Platform for Privacy Preferences (P3P) is a protocol developed by the World Wide Web Consortium (W3C). P3P (on the server side) defines an XML-based language by which Web sites can describe their privacy policies in a machine readable format. Categories of information include the contact information of the legal entity making the privacy statement, whether users will have access to information collected about them, different types of data being collected, the purpose(s) for collection, and which organizations will have access to the collected data... (2) XACML An OASIS Technical Committee, is producing XACML [XML Access Control Markup Language], a proposal for capturing authorization policies for resources. XACML is expected to address fine-grained control of authorized activities (e.g., read, write, copy, etc.) based on, among other criteria, access requester characteristics ('only Senior VPs and above can view this document'), the protocol over which the request is made ('this data is only viewable if accessed over HTTPS'), and the authentication mechanism ('requester must have authenticated using a Digital ID')... (3) XML Encryption Currently a W3C Candidate Recommendation, XML Encryption is a proposal for an XML vocabulary for capturing the results of an encryption operation performed on arbitrary (but most likely XML) data. A critical feature of the XML Encryption proposal is that it supports the concept of encrypting only specific portions of an XML document, not only minimizing the encryption processing but, more importantly, leaving non-sensitive information in plain text form such that general (i.e., non-security-related) processing of the XML can proceed... (4) XML Signature W3C XML Signature defines an XML Schema for capturing the result of a digital signature operation applied to arbitrary (but often XML) data. Unlike previous non-XML Digital Signature standards, XML Signature has been designed to both account for and take advantage of the Internet and XML... (5) WS Security WS Security is a recent proposal from Microsoft for adding security metadata to SOAP messages. We'll discuss it here in the context of a site requesting user information from .NET My Services [authenticity, confidentiality]... (6) SAML An OASIS initiative, SAML (Security Assertions Markup Language) will provide a standard way to define user authentication, authorization, and attribute information in XML documents. As its name suggests, SAML will allow business entities to make assertions regarding the identity, authorizations, and attributes of a subject to other entities, which may be partner companies, other enterprise applications, and so on... Privacy, ensuring that e-business customers remain in control over the personal information they share with online businesses, is one of the key issues facing today's companies as they attempt to take advantage of the great potential the Internet has for creating personalized and trusted relationships with customers. XML, not surprisingly, plays a critical role, both aggravating the problem through the free-flow of information it enables and providing syntax that offers a piece of the technology puzzle for solving the problem..."
[March 27, 2002] "Donald Eastlake on XML Digital Signatures. An Interview With One of the Specification's Pioneers." By Larry Loeb [and Donald Eastlake]. From IBM developerWorks, XML Zone. March 2002. ['In this exclusive developerWorks interview, XML Digital Signatures pioneer Donald Eastlake responds to Larry Loeb's recent article on the topic by clarifying a number of issues about how this technology is used. Note from Larry Loeb: In a recent article on XML Digital Signatures, I questioned their utility and usefulness. Since the proposal has just been recommended for passage into general usage, I decided it was time to check back on the topic again. This time, I talked with Donald Eastlake, the editor of the XML Digital Signature (XMLDSIG) RFC, and someone who should know something about the subject, since he has been intimately involved with XML specifications since the effort began in the 1990s. He has also served on IETF efforts too numerous to list. His responses appear unedited, except for minor grammatical changes.'] Eastlake on real world use of XML digital signatures: "I believe there will be a full spectrum of usage but two areas of particular prominence seem likely: documents and messages. While these sometimes blend into each other, documents tend to be longer lived and the signatures on them tend to indicate human approval of all or part of the document, although they may also have time stamp signatures affixed automatically. Messages tend to be transient and would more commonly have authentication automatically affixed and removed. Of course, a message could include one or more documents, in the sense I'm using the word here, in its content... Documents are most likely to use public key techniques while messages, depending on the application, could use public key or symmetric secret key techniques. Documents are more likely to be something "important" like a mortgage or court filing. But if XML digital signatures are widely used for messages, messages could be several orders of magnitude more numerous." Article also in PDF format. See "XML Digital Signature (Signed XML - IETF/W3C)."
[March 06, 2002] "Additional XML Security URIs." By Donald E. Eastlake 3rd (Motorola). IETF Internet-Draft. Reference: 'draft-eastlake-xmldsig-uri-02.txt'. January 2002; expires: July 2002. ['Distribution of this draft is unlimited. It is intended to become an Informational RFC and will probably also be published as a W3C Note. Comments should be sent to the author or the XMLDSIG working group'] Abstract: "A number of algorithm and keying information identifying URIs intended for use with XML Digital Signatures and XML Encryption are defined." From the introduction: "XML Digital Signatures have been standardized by the joint IETF/W3C XMLDSIG working group. The Proposed Standard is specified in RFC 3075 and a Draft Standard version is pending before the IESG [XMLDSIG-D]. Canonical XML, which is used by many digital signatures, has been standardized by the W3C and is documented in Informational RFC 3076. In addition, XML Encryption and Exclusive XML Canonicalization are currently being standardized by the W3C. All of these standards and recommendations use URIs to identify algorithms and keying information types. This document is intended to be a convenient reference list of URIs and descriptions for algorithms in which there is substantial interest but which can not or have not been included in the main documents for some reason. Note in particular that raising XML digital signature to Draft Standard in the IETF requires remove of any algorithms for which there is not demonstrated interoperability from the main standards document. This requires removal of the Minimal Canonicalization algorithm, in which there appears to be continued interest, to be dropped from the standards track specification. It is included here..." See references in : (1) See "XML Digital Signature (Signed XML - IETF/W3C)"; (2) "XML and Encryption."
[December 2001] "XML Signatures: Behind the Curtain. Who can be trusted with authentication?" By Larry Loeb (Author, Secure Electronic Transactions). From IBM developerWorks, Security. December 2001. ['The XML Digital Signature Standard establishes how XML can functionally sign itself over an insecure network like the Internet. While this effort does not require an established PKI to function, it may require the use of trusted XML servers for authentication. Consequently, each enterprise will have to evaluate the potential security risk of outsourcing this increasingly critical business function.'] "There's a W3C candidate out for XML signatures that looks fairly close to being the final one, though it is still a work in progress and has not as of this writing officially advanced to the Draft Standard stage. It's also been known to the Internet Engineering Task Force (IETF) as RFC 3075. Judging by the author list for this candidate -- which includes folks from the W3, MIT, and Microsoft -- it's clear that the Internet industry is taking this subject seriously. XML signatures have been designed (according to the RFC) with the multiple goals of providing "integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or elsewhere." (I've bolded that last phrase because it is central to what this candidate implies for how the 'Net would work if it is adopted and implemented. More on this later.) These are fairly ambitious goals to be sure, and fairly extensive if considered in context. These signatures and their associated processes have as an ultimate goal providing the default basic server-based security services for the Web through the use of XML..."
[October 21, 2001] "Supporting Digital Signatures Within SOAP Messages." By Brenda Coulson. From DEVX.com. "SOAP (Simple Object Access Protocol), one of the many specifications contributing to the success of Web services, is being positioned to replace EDI as the de-facto commercial B2B exchange. SOAP defines the XML document structure for sending Web service requests and responses. It is possible to send SOAP messages over the HTTPS protocol, providing encryption of the data. However, there are other security requirements to address if SOAP is to be completely embraced for B2B transactions. There is an existing specification outside the Web service realm, called XML-Signature, that describes how to represent a document and its corresponding signature in XML format. Now there is a W3C Note, SOAP-DSIG that defines how to digitally sign SOAP messages. How do all these pieces fit together? Piecing these elements together using Java, this article provides step-by-step, how-to instructions for you to build a complete solution that enables secure Web services..."
[October 03, 2001] "XML Security for Multipart MIME: Multipart/Signed and Multipart/Encrypted." IETF Network Working Group, Internet Draft. Reference: 'draft-fhirsch-xml-mime-security-00'. October 1, 2001. Expires: April 1, 2002. By Frederick Hirsch (Zolera Systems). Abstract: "This draft defines how XML Digital Signatures and XML Encryption may be used with Multipart MIME security to provide MIME integrity and confidentiality. It extends RFC 1847 by defining application/signature+xml and application/encryption+xml protocols for the Multipart/Signed and Multipart/Encrypted MIME types. Although non-XML content may be signed or encrypted based on XML signing and encryption, additional capabilities are available for XML MIME content. This draft defines a signature transform parameter for partial signing or manipulation of XML MIME content as well as processing rules in addition to the XML Digital Signature and XML Encryption processing rules." From the Introduction: "RFC 1847 defines a general mechanism for security multiparts in MIME, defining the Multipart/Signed and Multipart/Encrypted types. This mechanism uses a protocol parameter to specify the signature or encryption mechanism. Multipart/Signed enables the first MIME part to contain arbitrary MIME content and the second to contain a signature over that content. Common mail applications currently use application/x-pkcs7-signature as the signing protocol, creating a PKCS#7 signature in the signature part. Multipart/Encrypted uses the first part to contain encryption control information, and the second part encrypted content. An alternative to Multipart/Encrypted is to pass a single MIME part containing encrypted content using using application/x-pkcs7-mime, as done by common mail applications. XML DIGITAL SIGNATURE and XML ENCRYPTION recommendations enable signing and encryption of arbitary content as well as providing advanced support for XML content. This includes the ability to sign or encrypt portions of XML, reference multiple objects in a signature and include metadata information with signed or encrypted content. XML signatures support multiple signatures, useful when content is routed for approvals. Both XML Signatures and Encryption support inclusion of the signature or encrypted content in the orginal XML document, creating a close binding. Signatures may also be separate from the signed content, especially useful when the content is large or binary and would interfere with XML processing of the signature. Likewise, encrypted cipherdata may be included in an XML encrypted element or managed separately. Combining the XML security mechanisms with Multipart MIME security enables MIME applications to benefit from XML security as well as enabling XML security to use a defined mechanism for handling multiple parts. This draft extends the existing Multipart MIME security mechanism by defining two new protocol parameters to be used with RFC 1847, application/signature+xml and application/encryption+xml. These names follow the XML naming convention defined in RFC 3023, XML MEDIA TYPES. This draft defines these parameters and a minimal set of processing rules..." Also in text format. See (1) XML Media/MIME Types"; (2) "XML Digital Signature (Signed XML - IETF/W3C)"; (3) "XML and Encryption."
[September 21, 2001] "Enabling XML security. An introduction to XML encryption and XML signature." By Murdoch Mactaggart (IBMDev@TextBiz.com). From IBM developerWorks. September 2001. "XML is a major enabler of what the Internet, and latterly Web services, require in order to continue growing and developing. Yet a lot of work remains to be done on security-related issues before the full capabilities of XML languages can be realised. At present, encrypting a complete XML document, testing its integrity, and confirming the authenticity of its sender is a straightforward process. But it is increasingly necessary to use these functions on parts of documents, to encrypt and authenticate in arbitrary sequences, and to involve different users or originators. At present, the most important sets of developing specifications in the area of XML-related security are XML encryption, XML signature, XACL, SAML, and XKMS. This article introduces the first two. XML has become a valuable mechanism for data exchange across the Internet. SOAP, a means of sending XML messages, facilitates process intercommunication in ways not possible before, while UDDI seems to be fast becoming the standard for bringing together providers and users of Web services; the services themselves are described by XML in the form of WSDL, the Web Services Description Language. Without XML, this flexibility and power would not be possible and, as various people have remarked, it would be necessary to invent the metalanguage. The other area of rapid growth is that of security. Traditional methods of establishing trust between parties aren't appropriate on the public Internet or, indeed, on large LANs or WANs. Trust mechanisms based on asymmetric cryptography can be very useful in such situations, but the ease of deployment and key management, the extent of interoperability, and the security offered are, in reality, far less than the enthusiastic vendors of different Public Key Infrastructures (PKI) would have us believe. There are particular difficulties in dealing with hierarchical data structures and with subsets of data with varying requirements as to confidentiality, access authority, or integrity. In addition, the application of now standard security controls differentially to XML documents is not at all straightforward. Several bodies are actively involved in examining the issues and in developing standards. The main relevant developments here are XML encryption and the related XML signature, eXtensible Access Control Language (XACL), and the related Security Assertion Markup Language (SAML -- a blending of the formerly competing AuthML and S2ML). Each of these is driven by OASIS, and XML Key Management Specification (XKMS). This article introduces XML encryption and XML signature... SAML is an imitative driven by OASIS that attempts to blend the competing specifications AuthML and S2ML, and to facilitate the exchange of authentication and authorisation information. Closely related to SAML, but focusing more on a subject-privilege-object orientated security model in the context of a particular XML document, is the eXtensible Access Control Markup Language, also directed by OASIS and variously known (even within the same documents) as XACML or XACL. By writing rules in XACL, a policy author can define who can exercise what access privileges for a particular XML document, something relevant in the situations cited earlier. XKMS, now being considered by a W3C committee, is intended to establish a protocol for key management on top of the XML signature standard. With SAML, XACL, and other initiatives, XKMS is an important element in the large jigsaw that makes up security as applied to XML documents. Its immediate effect is to simplify greatly the management of authentication and signature keys; it does this by separating the function of digital certificate processing, revocation status checking, and certification path location and validation from the application involved -- for example, by delegating key management to an Internet Web service." See "XML Digital Signature (Signed XML - IETF/W3C)."
[August 28, 2001] "SOAP Security Extensions: Digital Signature. SOAP-DSIG and SSL." By Satoshi Hada (Sr. Engineer, IBM Tokyo Research Laboratory). From IBM developerWorks, Web services. August 2001. ['SOAP Security Extensions: Digital Signature (SOAP-DSIG) defines the syntax and processing rules for digitally signing SOAP messages and validating signatures. This article discusses how SOAP-DSIG is related to SSL, and describes how the two technologies complement each other.'] "Digital signatures allow messages to be as authentically sent by the origin user or software. Unfortunately, the Simple Object Access Protocol (SOAP) 1.1 did not include provisions for signing messages and thus lacks this security. My cohorts and I sent a proposal for adding digital signature technology to SOAP, which has since been accepted by the World Wide Web Consortium as the SOAP-DSIG Note, defining the syntax and processing rules for digitally signing SOAP messages and validating signatures. This technology has since been implemented into shipping products from IBM, Microsoft and others. SOAP-DSIG, however, has to work with Secure Sockets Layer (SSL), the most popular and widely deployed security technology used by Web sites. Therefore we should raise the questions: How is SOAP-DSIG related to SSL? And what are the differences between these two technologies? This article addresses these questions and describes how these two technologies provide complementary functions in areas where the other is lacking. Also, since HTTP (that is SOAP over HTTP) is so widely used, this article focuses primarily on HTTP as the transport layer. However, you should note that both SOAP and SOAP-DSIG are transport-independent and can be used over other transport protocols such as SMTP, FTP and MQ. When using other transport protocols, you need to know how SOAP-DSIG is related to the corresponding security of that transport layer (e.g., S/MIME in SMTP), as I will explain later in this article...
[August 13, 2001] "An Introduction to XML Digital Signatures." By Ed Simon, Paul Madsen, Carlisle Adams. From XML.com. August 08, 2001. ['How to understand and create XML-aware digital signatures.] "The very features that make XML so powerful for business transactions (e.g., semantically rich and structured data, text-based, and Web-ready nature) provide both challenges and opportunities for the application of encryption and digital signature operations to XML-encoded data. For example, in many workflow scenarios where an XML document flows stepwise between participants, and where a digital signature implies some sort of commitment or assertion, each participant may wish to sign only that portion for which they are responsible and assume a concomitant level of liability. Older standards for digital signatures provide neither syntax for capturing this sort of high-granularity signature nor mechanisms for expressing which portion a principal wishes to sign. Two new security initiatives designed to both account for and take advantage of the special nature of XML data are XML Signature and XML Encryption. Both are currently progressing through the standardization process. XML Signature is a joint effort between the World Wide Web Consortium (W3C) and Internet Engineering Task Force (IETF), and XML Encryption is solely W3C effort. This article presents a brief introduction to the XML Signature specification and the underlying cryptographic concepts... As XML becomes a vital component of the emerging electronic business infrastructure, we need trustable, secure XML messages to form the basis of business transactions. One key to enabling secure transactions is the concept of a digital signature, ensuring the integrity and authenticity of origin for business documents. XML Signature is an evolving standard for digital signatures that both addresses the special issues and requirements that XML presents for signing operations and uses XML syntax for capturing the result, simplifying its integration into XML applications." See "XML Digital Signature (Signed XML - IETF/W3C)."
[July 30, 2000] "Make your software behave: Cryptography essentials. Using hashing algorithms for data integrity and authentication." By Gary McGraw (Reliable Software Technologies). From IBM developerWorks, Security. July 2000. ['In this series on cryptography thus far, Gary and John have touched on both common forms of cryptographic algorithms -- public key cryptosystems, such as RSA, and symmetric algorithms, such as DES -- the most common ways to address the data confidentiality problem. They also discussed the importance of using well-understood algorithms instead of rolling your own, and introduced the risks commonly encountered when implementing cryptography in an application. In this installment, they turn to common approaches to data integrity and authentication, starting with hashing algorithms.'] "...The idea behind a digital signature is analogous to a traditional hand-written signature. The idea is to be able to 'sign' digital documents in such a way that the signature is as legally binding in court as a physical signature. Digital signatures must be at least as good as hand-written signatures at meeting these main goals of signatures: (1) A signature should be proof of authenticity. Its existence on a document should be able to convince people that the person whose signature appears on the document signed the document deliberately. (2) A signature should be impossible to forge. As a result, the person who signed the document should not be able to claim this signature is not theirs. (3) After the document is signed, it should be impossible to alter the document without detection, so that the signature can be invalidated. (4) It should be impossible to move the signature to another document... Even in hand-written signatures, these ideals are merely conceptual, and don't really reflect reality. For example, forging signatures is possible, even though few people are skilled enough to actually do it...The one problem with digital signatures is non-repudiation. People can always claim their key was stolen. Nonetheless, digital signatures are widely accepted as legal alternatives to a physical signature, because they come at least as close to meeting the ideals presented above as do physical signatures. At least 30 states have digital signature laws now, and more are likely to follow (if the U.S. Congress doesn't beat them to the punch by passing a national law). Most public key algorithms, including RSA and ElGamal, can be easily extended to support digital signatures. In fact, a good software package that supports one of these algorithms should also support digital signatures. We recommend using your favorite public key cryptography algorithm for digital signatures. Try to use built-in primitives instead of building your own construction out of an encryption algorithm and a hash function..."
[May 10, 2000] "The XML Security Suite: Increasing the security of e-business." By Doug Tidwell. Cyber Evangelist, developerWorks XML team. From IBM developerWorks. April 2000. "As more and more companies use XML to transmit structured data across the Web, the security of documents becomes increasingly important. This article presents some basics of Web security, describes the components of the XML Security Suite, and gives examples that illustrate how the technologies in the XML Security Suite increase the security of Web commerce. . . As more and more companies use XML to transmit structured data across the Web, the security of documents becomes increasingly important. The World Wide Web Consortium (W3C) and the Internet Engineering Task Force (IETF) are currently defining an XML vocabulary for digital signatures. The Tokyo Research Lab has created the XML Security Suite, a prototype implementation of the XML signature specification. The XML Security Suite, available from IBM's alphaWorks, contains utilities to automatically generate XML digital signatures. . . The XML Security Suite provides two other utilities, an ASN.1-to-XML translator and a variety of DOMHASH tools. The ASN.1-to-XML translator automatically translates between ASN.1 data (such as X.509 certificates and LDAP data) and XML. DOMHASH is an algorithm that generates a unique hash value for a given node in an XML document tree. The DOMHASH tools included with the XML Security Suite calculate hash values for given nodes, and provide a suite of DOMHASH test tools. alphaWorks contains a DOMHASH application called XMLTreeDiff; it uses DOMHASH to determine the differences between two DOM trees..."
|Receive daily news updates from Managing Editor, Robin Cover.|