DOCSLIB.ORG

XML Signature/Encryption — the Basis of Web Services Security

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
XML Signature/Encryption — the Basis of Web Services Security Special Issue on Security for Network Society Falsification Prevention and Protection Technologies and Products XML Signature/Encryption — the Basis of Web Services Security By Koji MIYAUCHI* XML is spreading quickly as a format for electronic documents and messages. As a consequence, ABSTRACT greater importance is being placed on the XML security technology. Against this background research and development efforts into XML security are being energetically pursued. This paper discusses the W3C XML Signature and XML Encryption specifications, which represent the fundamental technology of XML security, as well as other related technologies originally developed by NEC. KEYWORDS XML security, XML signature, XML encryption, Distributed signature, Web services security 1. INTRODUCTION 2. XML SIGNATURE XML is an extendible markup language, the speci- 2.1 Overview fication of which has been established by the W3C XML Signature is an electronic signature technol- (WWW Consortium). It is spreading quickly because ogy that is optimized for XML data. The practical of its flexibility and its platform-independent technol- benefits of this technology include Partial Signature, ogy, which freely allows authors to decide on docu- which allows an electronic signature to be written on ment structures. Various XML-based standard for- specific tags contained in XML data, and Multiple mats have been developed including: ebXML and Signature, which enables multiple electronic signa- RosettaNet, which are standard specifications for e- tures to be written. The use of XML Signature can commerce transactions, TravelXML, which is an EDI solve security problems, including falsification, spoof- (Electronic Data Interchange) standard for travel ing, and repudiation. agencies, and NewsML, which is a standard specifica- tion for new distribution formats. 2.2 XML Signature and Related Specifications As the popularity of XML becomes established, a XML Signature was established as a formal ver- greater importance is being placed on security tech- sion of W3C recommendations in Feb. 2002. W3C has nology for data the represented in XML. This means also established related specifications that need to be that XML needs to include features that can deal with fulfilled when XML Signature is actually used. The security risks, including falsification and eavesdrop- specifications relating to XML Signature are as fol- ping on data that is being transmitted over communi- lows: cation paths, such as the Internet, as well as on spoofing and repudiation. · XML-Signature Syntax and Processing: W3C Rec- In order to solve these problems, W3C, OASIS, and ommendation 2002/2/12 other standards organizations are working to estab- · Canonical XML Version 1.0: W3C Recommenda- lish standards specifications for XML security. In tion 2001/3/15 particular, the XML Signature and XML Encryption · Exclusive XML Canonicalization Version 1.0: W3C specifications established by the W3C can be the ba- Recommendation 2002/7/18 sis for all other XML security standards. This paper · XML-Signature XPath Filter 2.0: W3C Recommen- discusses these specifications and related technolo- dation 2002/11/08 gies originally developed by NEC. 2.3 XML-Signature Syntax and Processing This specification forms the core of XML Signa- ture. It defines electronic signature formats using XML, the creation of electronic signatures, and rules *System Platform Software Development Division for verification processing. Figure 1 shows an NEC Journal of Advanced Technology, Vol. 2, No. 1 35 Fig. 1 XML signature format example. example of an XML signature format and XML data 2.4 Canonical XML/Exclusive XML Canonicalization that is XML-signed. Canonical XML is an important specification relat- As shown in Fig. 1, an XML signature is a docu- ing to XML Signature. XML 1.0 is so flexible in docu- ment structure with the <Signature> element at its ment formats that equivalent contents can be ex- top. Under the <Signature> element, lie its child ele- pressed in multiple formats. An example is provided ments, including a <SignedInfo> element, which con- below. tains references to the algorithm used for the XML signature creation and to the target XML data. It also (1) <document></document> holds digest value and other information, a (2) <document/> <SignatureValue> element that contains the signa- ture value, and a <KeyInfo> element that contains Both code fragments in (1) and (2) above represent the public key certificate information to be used when an empty element. They are different in byte repre- the XML signature is verified. When considering the sentation, but are equivalent as XML data. In addi- characteristics of XML Signature, the <Reference> tion, the XML 1.0 specification allows equivalent element, which is a child element of the <SignedInfo> XML data to be expressed in multiple formats in element is particularly important. Multiple <Refer- terms of attribute occurrence sequence, blank charac- ence> elements may be contained in the <SignedInfo> ter handling, and naming space definitions, among element. This enables any number of XML data seg- others. ments at any location to be signed. This feature en- However, the electronic signature is a technology sures that an extremely flexible system can be built based on hash calculation that applies to byte repre- up by using XML Signature. sentations of data. The flexibility of the XML 1.0 specification could raise fatal problems in electronic 36 NEC J. of Adv. Tech., Winter 2005 Special Issue on Security for Network Society signatures. Against this background, the Canonical Recommendation 2002/12/10 XML specification, which provides for canonical forms that are equivalent to XML data formats, was 3.2.1 XML Encryption Syntax and Processing established ahead of XML signature specifications. This specification provides for encryption formats Before XML data is signed and verified, it is con- using XML and processing rules regarding encryption verted to a canonical form that complies with the and decryption. Figure 2 shows an XML encryption Canonical XML specification to ensure that the prob- format and an example of XML-encrypted XML data. lem of format variations can be solved in order to As shown in Fig. 2, XML-encrypted data is of a allow the use of XML Signature. document structure with the <EncryptedData> ele- On the other hand, Exclusive XML Canon- ment at its top. Under the <EncryptedData> element, icalization is one of the XML canonicalization specifi- lie its child elements, including the <Encryption- cations. It has been established considering special Method> element, which contains information on the situations. For example, in consideration that XML- algorithm used for encryption, the <KeyInfo> ele- signed XML data A will be added to a child element of ment, which contains information on the decryption XML data B. When XML data B is converted in accor- key to be used for decryption, and the <CipherData> dance with the Canonical XML specification, the element, which contains the cipher data. If hybrid naming space of XML data A changes because of encryption is used, the structure can also include the canonicalization. This will lead to failure in XML <EncryptedKey> element, which contains the key- signature verification for XML data A. This situation encryption key. In addition to XML signatures and in generally occurs when XML-signed XML data is em- order to ensure that multiple encryption and designa- bedded in a SOAP message. To avoid this problem, tion of multiple recipients are possible URIs can also the Exclusive XML Canonicalization was established be used to specify what is to be encrypted. This fea- as a specification that is based on Canonical XML and ture enables users to build extremely flexible systems excludes naming space and other contexts for the using XML Encryption. target of canonicalization. This specification is par- ticularly important for Web Services Security, which 3.2.2 Decryption Transform for XML Signature specifies XML-signed SOAP messages. The Decryption Transform for XML Signature specification was established to solve problems that 3. XML ENCRYPTION are raised when XML Signature and XML Encryption are used at the same time. It provides for a method 3.1 Overview used to determine whether XML encryption has been XML Encryption is an encryption technology that applied before or after the XML signature creation. is optimized for XML data. Its practical benefits in- This has been established by the W3C’s XML encryp- clude partial encryption, which encrypts specific tags tion working group as an additional specification with contained in XML data, multiple encryption, which regard to the conversion processing that is performed encrypts data multiple times, and complex encryp- on XML signatures. tion, such as the designation of recipients who were permitted to decrypt respective portions of data. The 4. NEC’S ORIGINAL TECHNOLOGIES RELATED use of XML Encryption also helps solve security prob- TO XML SECURITY lems, including XML data eavesdropping. The most important point in the field of XML secu- 3.2 XML Encryption and Related Specifications rity is to guarantee inter-operability with other prod- XML Encryption was established by the W3C as a ucts, or to place precedence on compliance with stan- formal version of W3C recommendations in Dec. dard specifications. This means that vendors find dif- 2002. The W3C also established related specifications ficulty in developing discriminating points for their that solve problems raised when XML Encryption products in this field. NEC has developed the original and XML Signature are used in combination. The technologies, Distributed Signature and HTML Sig- specifications relating to XML Encryption are as fol- nature; has applied for patents of these technologies, lows: and considers that the technologies are discriminat- ing points for the NEC products range. This paper · XML Encryption Syntax and Processing: W3C Rec- discusses Distributed Signature. It is a technology ommendation 2002/12/10 developed to allow the use of XML Signature on thin · Decryption Transform for XML Signature: W3C clients. NEC’s products are being employed in NEC Journal of Advanced Technology, Vol.
Load more

Recommended publications
  • An Arbitration System for Student Evaluation Based on XML Signature
    2nd EUROPEAN COMPUTING CONFERENCE (ECC’08) Malta, September 11-13, 2008 An Arbitration System for Student Evaluation based on XML Signature ROBERT ANDREI BUCHMANN, SERGIU JECAN Business Information Systems Dpt. Faculty of Economic Sciences and Business Administration Babes Bolyai University Cluj Napoca Str. Th. Mihali 58-60, ROMANIA [email protected], [email protected] Abstract: This paper promotes an e-learning application model for student evaluation, based on AJAX frameworks in order to provide improved user experience and asynchronous data exchange and the XML Signature standard in order to impose message authentications for the test papers. The motivation of this research is the need to arbitrate contestation for e-learning evaluation by providing an authentication and non-repudiation mechanism for both the students’ answers and the teachers’ evaluation criteria and rating, especially in open answer tests. Keywords: - e-learning, digital signature, AJAX 1 Introduction arose the issue of arbitration in contestation processes, especially in tests based on open E-learning already provides a mature model for questions, but also in multiple choice tests with educational processes. However, the separation no immediate answer validation. The proposed of parties in time and space is bound to solution is an extension to traditional e-learning communication gaps causing situations where an application models, regarding the evaluation arbitration system should provide trust module, based on XML-based digital signature mechanisms between the student and the and improved usability through AJAX teacher. The proposed application model is an frameworks. evolutionary step of the XML-driven e- commerce application previously implemented 3 Problem Solution for Flash 2004 with XML support and currently migrated under an AJAX framework and within 3.1 Instrumentation an e-learning context based on trust managed through XML Signatures.
    [Show full text]
  • On the Integrity and Trustworthiness of Web Produced Data
    CORE Metadata, citation and similar papers at core.ac.uk Provided by Open Repository of the University of Porto On the Integrity and Trustworthiness of web produced data Luís A. Maia Mestrado Integrado em Engenharia de Redes e Sistemas Informáticos Departamento de Ciência de Computadores 2013 Orientador Professor Doutor Manuel Eduardo Carvalho Duarte Correia, Professor Auxiliar do Departamento de Computadores, Faculdade de Ciências da Universidade do Porto Todas as correções determinadas pelo júri, e só essas, foram efetuadas. O Presidente do Júri, Porto, ______/______/_________ Acknowledgments I would like to express my appreciation for the help of my supervisor in researching and bringing different perspectives and to thank my family, for their support and dedication. 3 Abstract Information Systems have been a key tool for the overall performance improvement of administrative tasks in academic institutions. While most systems intend to deliver a paperless environment to each institution it is recurrent that document integrity and accountability is still relying on traditional methods such as producing physical documents for signing and archiving. While this method delivers a non-efficient work- flow and has an effective monetary cost, it is still the common method to provide a degree of integrity and accountability on the data contained in the databases of the information systems. The evaluation of a document signature is not a straight forward process, it requires the recipient to have a copy of the signers signature for comparison and training beyond the scope of any office employee training, this leads to a serious compromise on the trustability of each document integrity and makes the verification based entirely on the trust of information origin which is not enough to provide non-repudiation to the institutions.
    [Show full text]
  • Sams Teach Yourself XML in 21 Days
    Steven Holzner Teach Yourself XML in 21 Days THIRD EDITION 800 East 96th Street, Indianapolis, Indiana, 46240 USA Sams Teach Yourself XML in 21 Days, ASSOCIATE PUBLISHER Michael Stephens Third Edition ACQUISITIONS EDITOR Copyright © 2004 by Sams Publishing Todd Green All rights reserved. No part of this book shall be reproduced, stored in a retrieval DEVELOPMENT EDITOR system, or transmitted by any means, electronic, mechanical, photocopying, record- Songlin Qiu ing, or otherwise, without written permission from the publisher. No patent liability MANAGING EDITOR is assumed with respect to the use of the information contained herein. Although every precaution has been taken in the preparation of this book, the publisher and Charlotte Clapp author assume no responsibility for errors or omissions. Nor is any liability assumed PROJECT EDITOR for damages resulting from the use of the information contained herein. Matthew Purcell International Standard Book Number: 0-672-32576-4 INDEXER Library of Congress Catalog Card Number: 2003110401 Mandie Frank PROOFREADER Printed in the United States of America Paula Lowell First Printing: October 2003 TECHNICAL EDITOR 06050403 4321 Chris Kenyeres Trademarks TEAM COORDINATOR Cindy Teeters All terms mentioned in this book that are known to be trademarks or service marks have been appropriately capitalized. Sams Publishing cannot attest to the accuracy INTERIOR DESIGNER of this information. Use of a term in this book should not be regarded as affecting Gary Adair the validity of any trademark or service mark. COVER DESIGNER Warning and Disclaimer Gary Adair PAGE LAYOUT Every effort has been made to make this book as complete and as accurate as possi- ble, but no warranty or fitness is implied.
    [Show full text]
  • Bibliography of Erik Wilde
    dretbiblio dretbiblio Erik Wilde's Bibliography References [1] AFIPS Fall Joint Computer Conference, San Francisco, California, December 1968. [2] Seventeenth IEEE Conference on Computer Communication Networks, Washington, D.C., 1978. [3] ACM SIGACT-SIGMOD Symposium on Principles of Database Systems, Los Angeles, Cal- ifornia, March 1982. ACM Press. [4] First Conference on Computer-Supported Cooperative Work, 1986. [5] 1987 ACM Conference on Hypertext, Chapel Hill, North Carolina, November 1987. ACM Press. [6] 18th IEEE International Symposium on Fault-Tolerant Computing, Tokyo, Japan, 1988. IEEE Computer Society Press. [7] Conference on Computer-Supported Cooperative Work, Portland, Oregon, 1988. ACM Press. [8] Conference on Office Information Systems, Palo Alto, California, March 1988. [9] 1989 ACM Conference on Hypertext, Pittsburgh, Pennsylvania, November 1989. ACM Press. [10] UNIX | The Legend Evolves. Summer 1990 UKUUG Conference, Buntingford, UK, 1990. UKUUG. [11] Fourth ACM Symposium on User Interface Software and Technology, Hilton Head, South Carolina, November 1991. [12] GLOBECOM'91 Conference, Phoenix, Arizona, 1991. IEEE Computer Society Press. [13] IEEE INFOCOM '91 Conference on Computer Communications, Bal Harbour, Florida, 1991. IEEE Computer Society Press. [14] IEEE International Conference on Communications, Denver, Colorado, June 1991. [15] International Workshop on CSCW, Berlin, Germany, April 1991. [16] Third ACM Conference on Hypertext, San Antonio, Texas, December 1991. ACM Press. [17] 11th Symposium on Reliable Distributed Systems, Houston, Texas, 1992. IEEE Computer Society Press. [18] 3rd Joint European Networking Conference, Innsbruck, Austria, May 1992. [19] Fourth ACM Conference on Hypertext, Milano, Italy, November 1992. ACM Press. [20] GLOBECOM'92 Conference, Orlando, Florida, December 1992. IEEE Computer Society Press. http://github.com/dret/biblio (August 29, 2018) 1 dretbiblio [21] IEEE INFOCOM '92 Conference on Computer Communications, Florence, Italy, 1992.
    [Show full text]
  • XML for Java Developers G22.3033-002 Course Roadmap
    XML for Java Developers G22.3033-002 Session 1 - Main Theme Markup Language Technologies (Part I) Dr. Jean-Claude Franchitti New York University Computer Science Department Courant Institute of Mathematical Sciences 1 Course Roadmap Consider the Spectrum of Applications Architectures Distributed vs. Decentralized Apps + Thick vs. Thin Clients J2EE for eCommerce vs. J2EE/Web Services, JXTA, etc. Learn Specific XML/Java “Patterns” Used for Data/Content Presentation, Data Exchange, and Application Configuration Cover XML/Java Technologies According to their Use in the Various Phases of the Application Development Lifecycle (i.e., Discovery, Design, Development, Deployment, Administration) e.g., Modeling, Configuration Management, Processing, Rendering, Querying, Secure Messaging, etc. Develop XML Applications as Assemblies of Reusable XML- Based Services (Applications of XML + Java Applications) 2 1 Agenda XML Generics Course Logistics, Structure and Objectives History of Meta-Markup Languages XML Applications: Markup Languages XML Information Modeling Applications XML-Based Architectures XML and Java XML Development Tools Summary Class Project Readings Assignment #1a 3 Part I Introduction 4 2 XML Generics XML means eXtensible Markup Language XML expresses the structure of information (i.e., document content) separately from its presentation XSL style sheets are used to convert documents to a presentation format that can be processed by a target presentation device (e.g., HTML in the case of legacy browsers) Need a
    [Show full text]
  • Introduction to XML
    Introduction to XML CS 317/387 Agenda – Introduction to XML 1. What is it? 2. What’s it good for? 3. How does it work? 4. The infrastructure of XML 5. Using XML on the Web 6. Implementation issues & costs 2 1. What is it? Discussion points: First principles: OHCO Example: A simple XML fragment Compare/contrast: SGML, HTML, XHTML A different XML for every community Terminology 3 1 Ordered hierarchies of content objects Premise: A text is the sum of its component parts A <Book> could be defined as containing: <FrontMatter>, <Chapter>s, <BackMatter> <FrontMatter> could contain: <BookTitle> <Author>s <PubInfo> A <Chapter> could contain: <ChapterTitle> <Paragraph>s A <Paragraph> could contain: <Sentence>s or <Table>s or <Figure>s … Components chosen should reflect anticipated use 4 Ordered hierarchies of content objects OHCO is a useful, albeit imperfect, model Exposes an object’s intellectual structure Supports reuse & abstraction of components Better than a bit-mapped page image Better than a model of text as a stream of characters plus formatting instructions Data management system for document-like objects Does not allow overlapping content objects Incomplete; requires infrastructure 5 Content objects in a book Book FrontMatter BookTitle Author(s) PubInfo Chapter(s) ChapterTitle Paragraph(s) BackMatter References Index 6 2 Content objects in a catalog card Card CallNumber MainEntry TitleStatement TitleProper StatementOfResponsibility Imprint SummaryNote AddedEntrySubject(s) Added EntryPersonalName(s) 7 Semistructured Data Another data model, based on trees. Motivation: flexible representation of data. Often, data comes from multiple sources with differences in notation, meaning, etc. Motivation: sharing of documents among systems and databases.
    [Show full text]
  • Feasibility and Performance Evaluation of Canonical XML
    Feasibility and Performance Evaluation of Canonical XML Student Research Project Manuel Binna Student: E-mail: [email protected] Matriculation Number: 108004202162 Supervisor: Dipl.-Inf. Meiko Jensen Period: 20.07.2010 - 19.10.2010 Chair for Network and Data Security Prof. Dr. Jörg Schwenk Faculty of Electrical Engineering and Information Technology Ruhr University Bochum Feasibility and Performance Evaluation of Canonical XML Manuel Binna Abstract Within the boundaries of the XML specification, XML documents can be formatted in various ways without losing the logical equivalence of its content within the scope of the application. However, some applications like XML Signature cannot deal with this flexibility, thus needing a definite textual representation in order to distinguish changes which do or do not alter the logical equivalence of XML content. Canonical XML provides a method to transform textually different yet logically equivalent XML content into a single definite textual representation. This work evaluates the upcoming new major version Canonical XML Version 2.0 with respect to feasibility and performance. Chair for Network and Data Security, Ruhr University Bochum 2 Feasibility and Performance Evaluation of Canonical XML Manuel Binna Declaration I hereby declare that the content of this thesis is a work of my own and that it is original to the best of my knowledge, except where indicated by references to other sources. ____________________________ ______________________________________ Location, Date Signature Chair for Network and Data Security, Ruhr University Bochum 3 Feasibility and Performance Evaluation of Canonical XML Manuel Binna Table of Contents 1. Introduction! 5 1.1.XML 5 1.2.Canonicalization 6 1.3.History 7 1.4.Canonicalization and XML Signature 16 2.
    [Show full text]
  • Web API Protocol and Security Analysis Web
    EXAMENSARBETE INOM DATATEKNIK, GRUNDNIVÅ, 15 HP STOCKHOLM, SVERIGE 2017 Web API protocol and security analysis Web API protokoll- och säkerhetsanalys CRISTIAN ARAYA MANJINDER SINGH KTH SKOLAN FÖR TEKNIK OCH HÄLSA Web API protocol and security analysis Web API protokoll- och säkerhetsanalys Cristian Araya and Manjinder Singh Degree project in Computer science First level, 15hp Supervisor from KTH: Reine Bergström Examiner: Ibrahim Orhan TRITA-STH 2017:34 KTH The School of Technology and Health 141 52 Flemingsberg, Sweden Abstract There is problem that every company has its own customer portal. This problem can be solved by creating a platform that gathers all customers’ portals in one place. For such platform, it is required a web API protocol that is fast, secure and has capacity for many users. Consequently, a survey of various web API protocols has been made by testing their performance and security. The task was to find out which web API protocol offered high security as well as high performance in terms of response time both at low and high load. This included an investigation of previous work to find out if certain protocols could be ruled out. During the work, the platform’s backend was also developed, which needed to implement chosen web API protocols that would later be tested. The performed tests measured the APIs’ connection time and their response time with and without load. The results were analyzed and showed that the protocols had both pros and cons. Finally, a protocol was chosen that was suitable for the platform because it offered high security and fast connection.
    [Show full text]
  • OASIS Digital Signature Services (OASIS-DSS) an Architecture, Implementation and Interoperability Master’S Thesis at Graz University of Technology 2008
    OASIS Digital Signature Services (OASIS-DSS) An Architecture, Implementation and Interoperability Master’s Thesis at Graz University of Technology 2008 submitted by Konrad Lanz, bakk.techn., BSc Hons Institute for Applied Information Processing and Communications (IAIK), Graz University of Technology A-8010 Graz, Austria December 2008 © Copyright 2005-2008 Konrad Lanz Assessor: O.Univ.-Prof. Dipl.-Ing. Dr.techn. Reinhard Posch Supervisor: Ass.-Prof. Dipl.-Ing. Dr.techn. Peter Lipp i The candidate confirms that the work submitted is his own and the appropriate credit has been given where reference has been made to the work of others. I understand that failure to attribute material which is obtained from another source may be considered as plagiarism. (Signature of student) Signature Value F4BtvtUqSBPSgBeE2QPp1suVNoU75kZAk05AgIgLKJlMEov7RCAW35vkkEr/HwdR Signatory C=AT,OU=VSig,O=Hauptverband österr. Sozialvers.,CN=Konrad Lanz Date/Time-UTC 2008-12-15T23:15:40Z Issuer-Certificate C=AT,O=Hauptverband österr. Sozialvers.,CN=VSig CA 2 Serial-No. 17293657787164074630362273138432232730208 Method urn:pdfsigfilter:bka.gv.at:binaer:v1.1.0 Parameter etsi-bka-1.0@1229382940-394096199@31239-32542-0-14959-320 Verification Verification service: http://demo.a-sit.at/el_signatur/verification ©2005-2008 Konrad Lanz, All Rights reserved. Permission to copy this document is granted to Graz University of Technology i.e. the Institute for Applied Information Processing and Communications (IAIK) for in house educational purposes and its library and on a fair use basis. For permission to copy this document otherwise please do not hesitate to contact [email protected] with the following subject “request for copy permission MSc-Thesis 2008”.
    [Show full text]
  • Signxml Documentation Release 0.0.1
    SignXML Documentation Release 0.0.1 Andrey Kislyuk Oct 29, 2020 Contents 1 Installation 3 2 Synopsis 5 2.1 Verifying SAML assertions.......................................5 2.2 XML signature methods: enveloped, detached, enveloping.......................6 2.3 XML parsing security and compatibility with xml.etree.ElementTree .............7 3 Authors 9 4 Links 11 4.1 Bugs................................................... 11 5 License 13 6 API documentation 15 7 Release Notes 21 8 Changes for v2.8.1 (2020-10-29) 23 9 Changes for v2.8.0 (2020-06-20) 25 10 Changes for v2.7.3 (2020-06-10) 27 11 Changes for v2.7.2 (2019-12-01) 29 12 Changes for v2.7.1 (2019-11-30) 31 13 Changes for v2.7.0 (2019-11-30) 33 14 Changes for v2.6.0 (2019-01-10) 35 15 Changes for v2.5.2 (2017-12-07) 37 16 Changes for v2.5.1 (2017-12-07) 39 17 Changes for v2.5.0 (2017-12-07) 41 18 Changes for v2.4.0 (2017-07-10) 43 i 19 Changes for v2.3.0 (2017-04-24) 45 20 Changes for v2.2.4 (2017-03-19) 47 21 Changes for v2.2.3 (2016-12-20) 49 22 Changes for v2.2.2 (2016-12-20) 51 23 Changes for v2.2.1 (2016-09-26) 53 24 Changes for v2.2.0 (2016-09-25) 55 25 Changes for v2.1.4 (2016-09-18) 57 26 Changes for v2.1.0 (2016-09-18) 59 26.1 Version 2.0.0 (2016-08-05).......................................
    [Show full text]
  • A Layered Approach to XML Canonicalization
    A Layered Approach to XML Canonicalization A Position Paper for the W3C Workshop on Next Steps for XML Signature and XML Encryption Ed Simon, XMLsec Inc. [email protected] 1 Background ● XML Canonicalization enables reliable textual and binary comparison of XML documents through the removal of irrelevant differences in structure and content ● Current approach is to write a single specification that details how all parts of XML instances are to be canonicalized ● Proposed alternative approach is to layer canonicalization rules according to the XML stack: core, schema-specific, namespace-specific ● Potential advantages include flexibility and significant optimization of processing 2 Canonicalization Layers ● Core – Normalizes the elements, attributes, and whitespace of an XML instance ● Schema-Aware – Normalization of schema- aware aspects including default attributes, schema-defined data types, etc ● Namespace-Aware – Normalization of XML information set nodes that belong to, or are contained by nodes that belong to, an XML node declared with a particular namespace. Includes the normalization of namespace declarations themselves. 3 Core Canonicalization ● Defined much as per W3C XML Canonicalization version 1.1 ● Only canonicalizes what can be derived from the text of the XML instance ● Includes formatting of XML elements and attributes, whitespace, line breaks, CDATA, entities, etc... ● No namespace normalization (but don't worry, it's coming!) 4 Core Canonicalization Example <xsl:stylesheet version='2.0' xmlns="http://www.w3.org/1999/xhtml" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:ns1="http://www.xmlsec.com/namespaces/a" > <xsl:template match="/"> <p>Total Amount: <xsl:value-of ... ...select="ns1:expense-report/ns1:total"/></p> </xsl:template> </xsl:stylesheet> ...will be, after core canonicalization, found to be identical to..
    [Show full text]
  • TU07 XML at The
    ApacheCon 2004 November 2004 XML at the ASF Ted Leung [email protected] Copyright © Sauria Associates, LLC 2004 1 ApacheCon 2004 November 2004 Overview xml.apache.org ws.apache.org Xerces XML-RPC Xalan Axis FOP WSIF Batik JaxMe Xindice cocoon.apache.org Forrest XML-Security Cocoon XML-Commons Lenya XMLBeans Copyright © Sauria Associates, LLC ApacheCon 2004 2 There are three major XML focused projects at the ASF. Originally there was one project, xml.apache.org. Earlier this year, the Cocoon and web services projects were formed. Xml.apache.org contains a number of projects that are general purpose XML tools. Most of these tools are based on specifications from the World Wide Web Consortium. This includes XML itself, XSLT, XSL Formatting object, Scalable Vector Graphics, and XML Signature and XML Encryption The web services project, ws.apache.org contains projects that cluster around standards for dealing with Web Services, including SOAP and XML-RPC The Cocoon project is oriented around the Cocoon Web publishing framework which is basd on XML, XSLT, and a number of other XML related technologies. I’m not going to be able to give you any deep technical details regarding all of these projects. Instead, I’m going to try to describe what these projects are, what standards they implement, and talk about situations where you might use them. Unless I say otherwise, I’m going to be covering the Java projects. There are a few projects which have C/C++ versions and I’ll mention that where applicable. Copyright © Sauria Associates,
    [Show full text]