SEARCH
Advanced Search
ABOUT
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors
NEWS
Cover Stories
Articles & Papers
Press Releases
CORE STANDARDS
XML
SGML
Schemas
XSL/XSLT/XPath
XLink
XML Query
CSS
SVG
TECHNOLOGY REPORTS
XML Applications
General Apps
Government Apps
Academic Apps
EVENTS
LIBRARY
Introductions
FAQs
Bibliography
Technology and Society
Semantics
Tech Topics
Software
Related Standards
Historic
|
| News: Cover Stories |  |  |
| W3C XML Security Working Group Invites Public Review of New Working Drafts. |
Contents
Members of the W3C XML Security Working Group have published a collection of eight Working Drafts for public review. This Working Group, part of the W3C Security Activity in the Technology and Society Domain, has been chartered through May 2010 to review requirements and take next step in developing the XML security specifications.
Four of the eight specifications are subject of special call for early feedback. The XML Signature 1.1 and XML Encryption 1.1 First Public Working Drafts make changes to the default sets of cryptographic algorithms in both specifications. XML Security Use Cases and Requirements and XML Signature Transform Simplification: Requirements and Design are documents that the XML Security Working Group expects to help guide technical work on a future version of the XML Security specifications that might make more radical changes than the 1.1 series of these specifications. The Working Group would appreciate public feedback on these documents, with special attention to the algorithms listed in XML Signature 1.1 and XML Encryption 1.1, the proposed 2.0 changes in the Transform Simplification document and Use Cases and Requirements.
Additionally, the new XML Security Derived Keys specification introduces mark-up for key derivation, for use with both XML Signature and XML Encryption. XML Signature Properties defines commonly used signature properties. XML Security Algorithms provides a cross-reference for the algorithms and their identifiers used with the XML security specifications, bringing in one place information located in a number of documents. XML Signature Best Practices is a revised Working Draft for Best Practices in using the XML Signature specification.
This section provides a summary for each of the eight specifications, linked in each instance to a complete
bibliographic reference listing title, editors, URIs, diff-marked versions, etc.
XML Signature Syntax and Processing Version 1.1
XML Signature Syntax and Processing Version 1.1 is a First Public Working Draft of "XML Signature 1.1." This standards track document specifies XML digital signature processing rules and syntax. XML Signatures provide integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or elsewhere. Integrity as a property means that "data has not been changed, destroyed, or lost in an unauthorized or accidental manner; a simple checksum can provide integrity from incidental changes in the data. Message authentication is similar but also protects against an active attack to alter the data whereby a change in the checksum is introduced so as to match the change in the data. Given an authentication code/protected checksum, message authentication ensures that tampering with both the data and checksum, so as to introduce changes while seemingly preserving integrity, are still detected. Signer authentication is a property to ensure that the identity of the signer is as claimed; a signature should indicate who signed a document, message or record, and should be difficult for another person to produce without authorization.
"Conformance-affecting changes against the previous 10-June-2008 XML Signature (Second Edition) Recommendation mainly affect the set of mandatory to implement cryptographic algorithms, including Elliptic Curve DSA (and mark-up for corresponding key material), and additional hash algorithms. There is currently no consensus about the inclusion of the ECDSA algorithm as mandatory to implement, and the Working Group seeks early community input into what algorithms should be supported. Arguments for and against specific approaches are called out in an editorial note in section 6.1, 'Algorithm Identifiers and Implementation Requirements'. In parallel to this XML Signature 1.1 technical work, members of the XML Security Working Group are developing requirements and designs for a more radically different version 2 of XML Signature. XML Encryption Syntax and Processing Version 1.1
XML Encryption Syntax and Processing Version 1.1 is a First Public Working Draft of "XML Encryption 1.1." This standards track document specifies a process for encrypting data and representing the result in XML. "The data may be arbitrary data (including an XML document), an XML element, or XML element content. The result of encrypting data is an XML Encryption EncryptedData element which contains (via one of its children's content) or identifies (via a URI reference) the cipher data. When encrypting an XML element or element content the EncryptedData element replaces the element or content (respectively) in the encrypted version of the XML document. When encrypting arbitrary data (including entire XML documents), the EncryptedData element may become the root of a new XML document or become a child element in an application-chosen XML document..."
Conformance-affecting changes against this previous recommendation mainly affect the set of mandatory to implement cryptographic algorithms, by adding Elliptic Curve Diffie-Hellman Key Agreement. There is currently no consensus about the inclusion of this algorithm as mandatory to implement, and the Working Group seeks early community input into what algorithms should be supported. Arguments for and against specific approaches are called out in an editorial note in section 5.1, 'Algorithm Identifiers and Implementation Requirements'. XML Security Use Cases and Requirements
XML Security Use Cases and Requirements is a is a First Public Working Draft which summarizes scenarios, design decisions, and requirements for the XML Signature and Canonical XML specifications, to guide ongoing W3C work to revise these specifications. Specifically, the document is intended to summarize use cases and requirements driving revisions to XML Signature Second Edition, XML Encryption, and Canonical XML 1.1. It is not intended to define all possible use cases for these Recommendations, but rather to provide rationale for decisions leading to XML Signature 1.1, XML Encryption 1.1 and XML Signature 2.0 and/or other specifications.This work-in-progress document outlines general principles, elaborating on those expressed for the original XML Security work and then use cases, requirements and design options that impact the design of revisions to the XML Security specifications.
This document summarizes a number of scenarios in which the XML Signature and Canonical XML specifications are used, and identifies distinguishing properties of these scenarios. Usage scenarios may fall into the following categories which may have different requirements: (1) Document workflow; (2) Long Term Signatures (several years); (3) Minimal signatures on XML or binary content; (4) Token signing and verification; (5) Web services security. Section 3.3 ('Derived Keys') notes that contrary to the situation in the ASN.1-based world (e.g. S/MIME), there is currently a lack of general support in the core XML Security specifications (XML Signature and XML Encryption), for derived keys. Derived keys are used for a variety of purposes including encryption and message authentication, and the purpose of key derivation itself is typically a combination of a desire to expand a given, but limited, set of key material and prudent security practices of limiting use (exposure) of such key material. Solution requirements and design options are discussed. XML Signature Transform Simplification: Requirements and Design
XML Signature Transform Simplification: Requirements and Design is a First Public Working Draft document outlining a proposed simplification of the XML Signature Transform mechanism, intended to enhance security, performance, streamability and to ease adoption. The design outlined in this document is part of the XML Security Working Group's development of a revised version 2 of XML Signature.
"The Reference processing model and associated transforms currently defined by XML Signature Syntax and Processing (Second Edition) are very general and open-ended, which complicates implementation and allows for misuse, leading to performance and security difficulties. Support for arbitrary canonicalization algorithms, and the complexity of the existing algorithms in order to meet various generic requirements is also a source of problems. Current experience with the use of XML Signature suggests that a simplified reference, transform, and canonicalization processing model would address the most common use cases while improving performance and reducing complexity and security risks... This Working Draft is published to solicit early community review of the direction that the Working Group expects to take with version 2; early feedback is welcome. document is expected to be further updated based on both Working Group input and public comments. The Working Group anticipates to eventually publish a stabilized version of this document as a W3C Working Group Note." XML Security Derived Keys
XML Security Derived Keys is a First Public Working Draft document produced by members of the W3C XML Security Working Group; the Working Group expects to advance this Working Draft to Recommendation Status. It defines an XML Syntax and processing rules for use of derived keys within both the XML Signature and XML Encryption frameworks. Key derivation is a well-established mechanism for generating new cryptographic keys material from some existing, original ("master") key material and potentially other information. This document augments XML Signature and XML Encryption by defining XML types and elements necessary to enable use of derived keys in XML security applications. The specification does not define any new cryptographic algorithms, and does not include any additional mandatory to implement algorithms...
"In cryptographic applications, it is common to make use of derived cryptographic key material. In these applications, derived keys are used for a variety of purposes including data encryption and message authentication. The reason for doing key derivation itself is typically a combination of a desire to expand a given, but limited, set of original key material and prudent security practices of limiting use (exposure) of such key material. Key separation (such as avoiding use of the same key material for multiple purposes) is an example of such practices. Key derivation has wide use. The key derivation process may be based on passphrases agreed upon or remembered by users, or it can be based on some master keys (and be intended to reduce exposure of such master keys), etc. Derived keys themselves may be used in XML Signature and XML Encryption as any other keys; in particular, they may be used to compute message authentication codes (e.g. digital signatures using symmetric keys) or for encryption/decryption purposes. This specification defines a derived key XML type and associated elements; conformance requirements are specified by way of schema definitions and prose..." XML Signature Properties
XML Signature Properties is a First Public Working Draft in the W3C standards track. It outlines proposed standard XML Signature Properties syntax and processing rules and an associated namespace for these properties. The intent is these can be composed with any version of XML Signature using the XML SignatureProperties element. The properties specified in the document are believed to be broadly useful, but are primarily motivated by use of XML Signature for code signing, and by relevant work in the W3C Web Applications Working Group. The specification is intended to provide building blocks for profiles of XML Signature; specifying detailed processing for individual properties is left to these profiles.
The SignatureProperties element defined by XML Signature Syntax and Processing (Second Edition) offers a means to associate property values with an XML Signature. This document defines specific properties that may be used by various applications of XML Signature, without requiring those applications to define such properties on a per case basis. This document defines how these properties are to be specified and processed when used but does not require their use; specifications that reference this document may or may not require their use. The changes proposed in this document would not be a breaking change to XML Signature, but warrant a new namespace for the properties themselves so that they can be used in various versions of XML Signature. For each property, an intended processing model is suggested. However, the details of processing each of these properties will depend upon individual application scenarios, and must be specified in any profile that makes use of the properties defined in this document..." XML Security Algorithm Cross-Reference
XML Security Algorithm Cross-Reference is a W3C First Public Working Draft developed by members of the XML Security Working Group. It summarizes XML Security algorithm URI identifiers and the specifications associated with them. The document is intended to serve as a cross-reference to various commonly used XML security specifications. It does not include any normative requirements of its own.
"Various XML Security specifications have defined a number of algorithms of various types, while allowing and expecting additional algorithms to be defined later. Over time, these identifiers have been defined in a number of different specifications, including XML Signature, XML Encryption, RFCs and elsewhere. This makes it difficult for users of the XML Security specifications to know whether and where a URI for an algorithm of interest has been defined, and can lead to the use of incorrect URIs. The purpose of this Note is to collect the various known URIs at the time of its publication and indicate the specifications in which they are defined in order to avoid confusion and errors. This document is not intended as an exhaustive list of all known related identifiers, some of which may have been defined by other standards or specifications. Furthermore, this note is not to be taken as normative regarding the information provided; if information here conflicts with the referenced specification, the specification takes precedence in all cases..." XML Signature Best Practices
XML Signature Best Practices is a W3C Working Draft document which collects best practices for implementors and users of the XML Signature specification (XML-Signature Syntax and Processing, Second Edition). Most of these best practices are related to improving security and mitigating attacks, yet others are for best practices in the practical use of XML Signature.
The XML Signature specification offers powerful and flexible mechanisms to support a variety of use cases. This flexibility has the downside of increasing the number of possible attacks. One countermeasure to the increased number of threats is to follow best practices, including a simplification of use of XML Signature where possible. This document outlines best practices noted by the XML Security Specifications Maintenance Working Group, the XML Security Working Group, as well as items brought to the attention of the community in a Workshop on Next Steps for XML Security. While most of these best practices are related to improving security and mitigating attacks, yet others are for best practices in the practical use of XML Signature, such as signing XML that doesn't use namespaces. The document addresses (for example): [1] For Implementors: Reduce the opportunities for denial of service attacks; [2] For Implementors: provide a mechanism to determine what was signed; [3] For Implementors: be aware of certificate encoding issues; [4] For Applications: prevent replay attacks; [5] For Applications: Check what is signed; [6] Enable Long-Lived Signatures; [7] Signing XML without namespace information — 'legacy XML'; [8] Avoiding default XML Schema values; [9] Be aware of XML Schema Normalization...
XML Signature Syntax and Processing Version 1.1. W3C Working Draft. 26-February-2009. This version URI: http://www.w3.org/TR/2009/WD-xmldsig-core1-20090226/. Latest version URI: http://www.w3.org/TR/xmldsig-core1/. Previous version URI: http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/. Latest XML Signature Recommendation URI: http://www.w3.org/TR/xmldsig-core/.
Edited by Donald Eastlake <d3e3e3@gmail.com>, Joseph Reagle <reagle@mit.edu>, David Solo <dsolo@alum.mit.edu>, Frederick Hirsch <frederick.hirsch@nokia.com>, Thomas Roessler <tlr@w3.org>, and Kelvin Yiu <kelviny@microsoft.com> Authors: Mark Bartel <mbartel@adobe.com>, John Boyer <boyerj@ca.ibm.com>, Barb Fox <bfox@Exchange.Microsoft.com>, Brian LaMacchia <bal@microsoft.com>, and Ed Simon <edsimon@xmlsec.com>.
As of 2009-02-26, the most recent W3C Recommendation of XML Signature 1 was the 10-June-2008 XML Signature (Second Edition) Recommendation. A colored diff-marked version of this specification is available; it shows differences between the latest recommendation and this version of the specification. Please send comments about this document to the publicly archived mailing list public-xmlsec-comments.
"This document specifies XML syntax and processing rules for creating and representing digital signatures. XML Signatures can be applied to any digital content (data object), including XML. An XML Signature may be applied to the content of one or more resources. Enveloped or enveloping signatures are over data within the same XML document as the signature; detached signatures are over data external to the signature element. More specifically, this specification defines an XML signature element type and an XML signature application; conformance requirements for each are specified by way of schema definitions and prose respectively. This specification also includes other useful types that identify methods for referencing collections of resources, algorithms, and keying and management information.
The XML Signature is a method of associating a key with referenced data (octets); it does not normatively specify how keys are associated with persons or institutions, nor the meaning of the data being referenced and signed. Consequently, while this specification is an important component of secure XML applications, it itself is not sufficient to address all application security/trust concerns, particularly with respect to using signed XML (or other data formats) as a basis of human-to-human communication and agreement. Such an application must specify additional key, algorithm, processing and rendering requirements..."
The specification makes use of XML namespaces, and uses Uniform Resource Identifiers to identify resources, algorithms, and semantics. Implementations of this specification MUST use the prescribed XML namespace URIs.. While implementations MUST support XML and XML namespaces, and while use of the [prescribed] namespace URIs is REQUIRED, the namespace prefixes and entity declarations given are merely editorial conventions used in this document. Their use by implementations is OPTIONAL. The defined namespace URIs are also used as the prefix for algorithm identifiers that are under control of this specification. For resources not under the control of this specification, we use the designated Uniform Resource Names (URN) or Uniform Resource Identifiers (URI) defined by the relevant normative external specification..." XML Encryption Syntax and Processing Version 1.1. W3C Working Draft. 26-February-2009. This version URI: http://www.w3.org/TR/2009/WD-xmlenc-core1-20090226/. Latest version URI: http://www.w3.org/TR/xmlenc-core1/. Previous version URI: http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/. Latest XML Encryption Recommendation URI: http://www.w3.org/TR/xmlenc-core/.
Edited by Donald Eastlake <dee3@torque.pothole.com> and Joseph Reagle <reagle@w3.org>. Authors: Takeshi Imamura <IMAMU@jp.ibm.com>, Blair Dillaway <blaird@microsoft.com>, Ed Simon <edsimon@xmlsec.com> and Kelvin Yiu <kelviny@microsoft.com>
As of 2009-02-26, the most recent W3C Recommendation of XML Encryption 1 was the 10-December-2002 XML Encryption Syntax and Processing Recommendation. Please send comments about this document to the publicly archived mailing list public-xmlsec-comments. XML Security Use Cases and Requirements. W3C Working Draft. 26-February-2009. This version URI: http://www.w3.org/TR/2009/WD-xmlsec-reqs-20090226/. Latest version URI: http://www.w3.org/TR/xmlsec-reqs/. Edited by Frederick Hirsch (Nokia) and Thomas Roessler (W3C). XML Signature Transform Simplification: Requirements and Design. W3C Working Draft. 26-February-2009. This version URI: http://www.w3.org/TR/2009/WD-xmldsig-simplify-20090226/. Latest version URI: http://www.w3.org/TR/xmldsig-simplify/. Edited by Frederick Hirsch (Nokia) and Pratik Datta (Oracle). Editor's Draft. XML Security Derived Keys. W3C Working Draft. 26-February-2009. This version URI: http://www.w3.org/TR/2009/WD-xmlsec-derivedkeys-20090226/. Latest version URI: http://www.w3.org/TR/xmlsec-derivedkeys/. Edited by Magnus Nyström, (RSA, The Security Division of EMC). XML Signature Properties. W3C Working Draft. 26-February-2009. This version URI: http://www.w3.org/TR/2009/WD-xmldsig-properties-20090226/. Latest version URI: http://www.w3.org/TR/xmldsig-properties/. Edited by Frederick Hirsch (Nokia). XML Security Algorithm Cross-Reference. W3C Working Draft. 26-February-2009. This version URI: http://www.w3.org/TR/2009/WD-xmlsec-algorithms-20090226/. Latest version URI: http://www.w3.org/TR/xmlsec-algorithms/. Edited by Frederick Hirsch (Nokia), Thomas Roessler (W3C), and Kelvin Yiu (Microsoft). Editor's draft. XML Signature Best Practices. W3C Working Draft. 26-February-2009. Edited by Frederick Hirsch (Nokia) and Pratik Datta (Oracle). This version URI: http://www.w3.org/TR/2009/WD-xmldsig-bestpractices-20090226/. Latest version URI: http://www.w3.org/TR/xmldsig-bestpractices/. Previous version URI: http://www.w3.org/TR/2008/WD-xmldsig-bestpractices-20081114/. See also the colored diff-marked version.
The W3C XML Security Working Group has been chartered through May 31, 2010 "to take the next step in developing the XML security specifications based upon lessons learned from implementation and deployment experience to date. The existing suite of XML security specifications has become a fundamental technology in the XML and Web Service worlds over the past seven years: The joint IETF/W3C XML Signature Working Group specified mechanisms to digitally sign XML documents and other data, and to encapsulate digital signatures in XML. The W3C XML Encryption Working Group specified mechanisms to encrypt XML documents and other data, and to encapsulate the encrypted material and related meta-information in XML. In 2007, the XML Security Specifications Maintenance Working Group took up limited maintenance work of the XML Signature Specification, and the XML Core Working Group prepared the Canonical XML 1.1 Recommendation, on which XML Signature depends. The W3C Workshop on Next Steps for XML Signature and XML Encryption identified next steps for this suite of technologies that are desirable to a broader community..."
Three broad areas of activity for the XML Security Working Group include Requirements Development, Specification Development, and Specification Maintenance. A first phrase of activity targeted the review of use cases and requirements for the design and application of canonicalization algorithms; review of use cases and requirements for an updated version of XML Signature Syntax and Processing (this work should particularly consider experience gathered with the XML Signature transform and reference processing models as well as experiences gathered with other technologies that are used to sign XML data); and review of requirements related to updates to the XML environment, including XML 1.1 and Efficient XML Interchange. Based on the requirements gathered in the first phase of its work, the Working Group is to develop updates to the core XML Security specifications: Canonicalization, XML Signature, and XML Encryption. The Working Group may consider comments and updates to the following set of specifications: (1) XML-Signature XPath Filter 2.0; (2) Canonical XML Version 1.0; (3) Canonical XML Version 1.1; (4) Exclusive XML Canonicalization Version 1.0; (5) Decryption Transform for XML Signature..."
The work in the W3C Security Activity currently comprises two Working Groups, the Web Security Context Working Group and the XML Security Working Group. The Web Security Context Working Group focuses on the challenges that arise when users encounter currently deployed security technology, such as TLS: While this technology achieves its goals on a technical level, attackers' strategies shift towards bypassing the security technology instead of breaking it. When users do not understand the security context in which they operate, then it becomes easy to deceive and defraud them. This Working Group is currently planning to see its main deliverable, the User Interface Guidelines, through to Recommendation, but will not engage in additional recommenation track work beyond this deliverable. The Working Group is currently operating at reduced Team effort (compared to the initial effort reserved to this Working Group). Initial (and informal) conversations are under way about forming an Interest Group that would provide a forum for the group's participants, and could also serve as a point of contact for specification review..."
The Web Security Context Working Group published a second Last Call Working Draft of its User Interface Guidelines document. Based on feed-back both in last-call comments and from implementers, the specification was cut down to specify best current practice in the space, as it has evolved over the last few years. Most experimental features have been dropped from this specification..."
The W3C Security Activity is part of the W3C Technology and Society Domain. "Working at the intersection of Web technology and public policy, the Technology and Society Domain's goal is to augment existing Web infrastructure with building blocks that assist in addressing critical public policy issues affecting the Web. Our expectation is not to solve policy problems entirely with technology, but we do believe that well-designed technical tools can lead to policy approaches that are more consistent with the way the Web should operate. The Semantic Web is an important component in this endeavor, as it provides the means for various entities to instrument their interactions through formal specifications of vocabularies describing relevant policies, rules and resources. Semantic Web technologies will enable our machines to assist users in exercising more control over their online environment and interactions." The following activities are part of this domain:
- Working Draft Specifications for review:
- XML Security Working Group:
- W3C Context (Activity and Domain):
|
 | Receive daily news updates from Managing Editor, Robin Cover.
 |
|
