Introduction

Contents

• Introduction
• Standards Initiatives
  • CEN/ISSS (CEN Information Society Standardization System)
  • ETSI (European Telecommunications Standards Institute)
  • IETF (Internet Engineering Task Force)
  • IETF/W3C XML Signature and XML Key Management
  • ISO (International Organization for Standardization)
  • JCP (Java Community Process)
  • OASIS Digital Signature Services (DSS)
  • Other Specifications
• XML and Security
• General Reference Works/Collections
• Articles, Papers

---

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."

---

Standards Initiatives

General Reference Works/Collections

[Section not complete]

• RSA Public-Key Cryptography Standards
• XML Security reference page. Maintained by Christian Geuer-Pollmann (Universität Siegen, Institut für Nachrichtenübermittlung)
• Digital Signatures. Resources from EPIC
• ISO/IEC, CEN, EDIFACT. Digital Signature: Inventory of International Regulatory, Standardisation And Commercial Activities.
• Legal Aspects of Digital Signatures.
• The Legal Aspects of Digital Signatures "This book is the result of a research carried out at the Interdisciplinary Centre for Law and Information Technology (ICRI), Katholieke Universiteit Leuven, Faculty of Law, for DG XV-Internal Market and Financial Services of the European Commission."

---

Articles, Papers

• [January 07, 2003] "Infomosaic Releases Java Support for SecureXML Digital Signature." - "Infomosaic Corporation today announced the release of Java Support for SecureXML Digital Signature, rounding its Digital Signature product offering and support for software developers utilizing the following programming languages and development environments: C, C++, Java, VB/ VB Script/ ASP, JavaScript/ Web, C#/ VB.NET/ ASP.NET and Cold Fusion. SecureXML makes it extremely easy for software developers and system integrators to add industry standard digital signature to their web and standalone applications. SecureXML provides functionality to sign web pages, forms, XML data and documents in Word, PDF and other formats. Manoj Srivastava, President and CEO of Infomosaic Corp., said, 'With the addition of support for Java (Sun JDK 1.4.1) in SecureXML, Java developers can now take full advantage of Windows native cryptography and XML Signature without having to reinvent everything'... As more and more companies transmit data across the Web and archive information electronically, the security of documents becomes increasingly important. Electronic Signatures on documents and data files are replacing the traditional hand written signatures on financial, legal, medical and business documents. Electronic Signatures assure (1) Integrity: The data/document isn't changed as it goes from the sender to the receiver; (2) Authenticity: The document actually came from the indicated sender; (3) Non Repudiation: The sender of the document cannot claim that they did not send it or that the content was altered; (4) Acceptance: The signing process establishes the agreement of the signer with what is being signed... Infomosaic Corporation is a leading provider of Digital Signature products and services. Its SecureXML product family was the first C-language implementation of the XML Digital Signature standard. It is highly optimized for high volume XML transaction applications, intended for digitally signing network data, web content and standalone documents. The software can be used in workflow and other e-business automation applications..."

• [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..."

---