Home arrow XML arrow Page 4 - XML Signatures: Behind the Curtain
XML

XML Signatures: Behind the Curtain


In this article, Larry considers the security risks that exists with the current XML authentication standards.

Author Info:
By: Larry Loeb
Rating: 3 stars3 stars3 stars3 stars3 stars / 8
March 07, 2003
TABLE OF CONTENTS:
  1. · XML Signatures: Behind the Curtain
  2. · Introduction
  3. · The Overview
  4. · What They Don't Tell You in the Specification
  5. · The Geek Part
  6. · Signature Elements
  7. · An Example to Mull Over
  8. · A Pithy Summary
  9. · The Resources

print this article
SEARCH DEVARTICLES

XML Signatures: Behind the Curtain - What They Don't Tell You in the Specification
(Page 4 of 9 )

There is also an implicit assumption here, and it's in-your-face obvious upon due examination. XML is Web- and server-based. It's a sort of thin-client approach, as opposed to the "damn the bandwidth, load the servlet" approach of Java. XML signatures will therefore use the Web (via URLs in the XML) to find out the method to encode or decode things. Exactly how it uses the Web can be syntactically specified (as demonstrated in the technical discussion that follows), but that kind of discussion ignores the meta-question of what URL to use. That is, if the signature needs 'Net resources to complete its action, then who will supply those resources? If this sort of signature becomes a widely-used "semaphore" for authentication of messages and transactions, whichever URLs are pointed to in the XML code can become a de facto standard for authentication services.

But wait, there's more. The real use of authentication services will most likely be found in Web shopping; rather than, for example, secured e-mail. A merchant will want to know that he is receiving a valid order from a customer, and so will insist on some form of acceptable authentication. This is the sort of problem that was first solved by Electronic Data Interchange (EDI) systems that used secured networks to operate. Over the insecure Internet, the same previously-solved operational problems remain open. The XML signature process is meant to address this in a sweeping way, but that sweep is part of the problem. This little-known candidate carries in it the seeds of a method for some company to monopolize Internet authentication services.

Let me posit a scenario. Imagine that some Commercial Off The Shelf (COTS) software company decides it wants to be the authorization service that all must pass through to get things done. Also further posit that this COTS proprietary operating system is found on the majority of the deployed systems under consideration. The COTS vendor then brings out an Xtra Proprietary version of its OS, which contains a client that uses XML signatures (and only XML signatures) for security. All the XML code points to this vendor's servers to provide information, sort of like a non-public PKI infrastructure. This client becomes widely used for authentication simply because it's easy to set up as a default since the OS is widely used. Also, said manufacturer embeds it in its popular "free" browser as the default security mechanism.

To put the icing on the cake, say this vendor starts to charge someone (perhaps the merchant and, indirectly, the consumer) every time its servers are used for authentication by this client. Voila! Monopoly and revenue streams all in one.

Now, having used these security services in good faith, a merchant might find that these services don't actually address underlying problem -- that of "chargebacks" from the credit card companies. These chargeback issues -- where people acknowledge that they had an agreement or some contact with the merchant but claim that the merchant did not performed in some or all aspects as promised (like nothing delivered, or the order was cancelled, or some other reason) -- are part of the credit card issuer's business model and beyond the scope of an XML signature specification. Indeed, in the US the Fair Credit Billing Act (15 U.S.C. 1666-1666j) preserves the customer's right to make arguments with an issuing bank about the correctness of a bill (including amount, computation, timing, and delivery/receipt of goods/services). Those rights can't be waived by contract.

I'm coming to the windup here.

So, even if schemes like XML signatures are in place and being used, they may not address the real world problems they were supposed to solve. Given that, and the potential for abuse by greedy companies to establish a 'Net monopoly, use of this technology may end up unsatisfying. That doesn't mean that a developer may have to, in the long run, use this sort of scheme just to be compatible; but don't think that it's just a magic incantation, either. Companies other than the largest ones may develop unique authentication services, and using them may require small rewrites in the XML code. The true problem may be the unquestioning acceptance of manufacturer-supplied XML signature code. So let's take a look at the tech specification with an eye towards understanding where things may need to be changed as services evolve.


blog comments powered by Disqus
XML ARTICLES

- Open XML Finally Supported by MS Office
- XML Features Added to Two Systems
- Using Regions with XSL Formatting Objects
- Using XSL Formatting Objects
- More Schematron Features
- Schematron Patterns and Validation
- Using Schematron
- Datatypes and More in RELAX NG
- Providing Options in RELAX NG
- An Introduction to RELAX NG
- Path, Predicates, and XQuery
- Using Predicates with XQuery
- Navigating Input Documents Using Paths
- XML Basics
- Introduction to XPath

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
 
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 
Support 

Developer Shed Affiliates

 




© 2003-2017 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials