Exploring XML Encryption

PeterMan writes "Here's a good XML Encription article that examines the usage model of XML Encryption with the help of a use case scenario. It presents a simple demo application, explaining how it uses the XML Encryption implementation. It then continues with the use of JCA/JCE classes to support cryptography. Finally, It discusses the applications of XML Encryption in SOAP-based Web services."

I don't get it.

[Lukey Boy]

XML is just a form of data, and should be totally independent in regards to encryption. If it transport mechanisms like SOAP work over HTTP, then why not just use HTTPS? What's next - an encryption standard for PNG images, text files and MPG movies? Maybe someone can enlighten me :-)

Re:I don't get it.

[borgboy]

Among other things, XML Encryption gives you the ability to selectively encrypt individual elements of an XML document and do so in a way that clearly identifies what is encrypted and how. Just as in the example, you may want to pass around an XML document which, as a whole, is suitable for public consumption, but that contains parts you would like to keep secret and/or immutable.
The alternative is to pass around multiple documents which then need to reference one another somehow.

As for SOAP, I agree with you. If you need secure SOAP, HTTPS is an excellent, mature solution. His statement that SOAP should work seamlessly with XML Encryption sounds enormously optimistic. But then, I've actually done SOAP interop work between disparate vendors of SOAP servers/clients, requiring quite a bit of tweaking in some cases. Funny, Websphere was one of those culprits ;)

Interesting.

[Lukey Boy]

Sounds kind of cool, but at the same time utterly useless. It's a hell of a lot easier to encrypt document fragments as a whole then encrypting individual nodes of a document (in my opinion). The alternative you outlined still sounds much more robust to me than encrypted islands inside a supposedly human-readable XML file.

What's Encrypted, What's Not

[4of12]

Everyone agrees on two things:

1. XML represents a great hope for higher level communication between automated agents
2. encryption is a necessary ingredient for protected electronic commerce

But I have some reasons to be pessimistic about XML.

If the underlying DTDs and Schemas are not well distributed, as in free, open, unrestricted, the premise of XML as a lingua franca is severely undermined.

Second, it will be too easy to decide that a business logic system based on XML is "too good to reveal to potential competitors and can make us money" and to therefore encrypt many more things that ought not to be encrypted if the objective is to make XML widespread and useful.

Re:What's Encrypted, What's Not

[mh_cryptonomicon]

uh... Who told you that DTDs and Schemas are not freely, openly, distributed? There is absolutely nothing I've seen that prevents you from downloading DTDs and/or Schemas. The documents defining XML, DTDs, and even Schemas are freely available (even though the Schema definition has gone through a great number of revisions, so it's sometimes hard to tell if you're using the right revision.)

Your second point seems to be a critique of encryption, not XML. Encryption is a fundamental technology for business, government, and personal information assurance. Think of XML as sort of ASCII meets the OSI presentation layer. If you start digging in the OSI protocols, you'll find reference to OIDs (Object Identifiers.) These things pop up everywhere, from SNMP traps to x.509 certificates. One thing you'll notice about OIDs is that some of them are well defined, and others are "internal use only." This has not led to protocols using OIDs being insecure or unuseful. DTDs and Schemas are in many ways the XML equivalent to OIDs. There will be a whole bunch of DTDs that are internal use only, but there's nothing wrong with this. OIDs that people tend to use in the real world are the ones about which we can find public documentation. DTDs and Schemas, I expect, will be the same way.

In defense of XML Information Assurance applications, I must say that the structured nature of XML allows applications to have a more refined model as to what in an XML document is encrypted, signed, decrypted, verified, hashed, and logged. If you've ever had to deal with ASN.1 and BER encoding, then you would know how wonderful XML is.

Performance?

[duffbeer703]

How are you going to be able to process large amounts of XML data?

Think about the massive, bloated overhead already associated with XML... now you are going to encrypt individual elements of XML with a variety of different schemes?

This whole XML thing seems to be Intel's wet dream come true.

Re:Performance?

[renehollan]

Yeah. I came away with the feeling that XML is the Cobol of the new millenium strongly reinforced. If anything, XML should be the source code for what actually gets exchanged in a machine-agnostic fashion (anyone remember XDR?).

Re:Performance?

[ChrisDolan]

Have you looked at PDF encryption? Granted, it's all RC4 with MD5 password hashes, not the "variety of different schemes" you mention, but encrypted PDF docs have plaintext metadata and encrypted content data intermixed. It's really quite cool, and the performance hit is tiny. The advantage PDF might have over XML, however, is that the document format is internally indexed, so you don't have to parse the whole thing to get the one piece of data you want. That detail aside, I think this is quite feasible without big CPU hits.

Re:Performance?

[Disco Stu]

You compress it, and then encrypt it, moron. If you'd read the friggin spec, you'd realize that XML Encryption doesn't *just* encrypt xml -- it's a way of embedding encryption information in your xml, to allow you to exchange between machines in a language and platform independent manner. You can use XML encryption to encrypt binary, data, even.

Is this a record for lowest number of comments?

[grytpype]

See subject.

Re:I don't get it.

[Anonymous Coward]

XML is just a form of data, and should be totally independent in regards to encryption. If it transport mechanisms like SOAP work over HTTP, then why not just use HTTPS? What's next - an encryption standard for PNG images, text files and MPG movies? Maybe someone can enlighten me :-)

The official position of most of the XML security groups is that if it's not XML, it's crap (well, words to that effect). Because of this, it's necessary to reinvent everything yourself so you can do it in XML - you can't, for example, just use PGP to wrap up your XML data, or TLS to transport it, but have to build everything from scratch using XML only.

This is probably not the best approach to getting things usably deployed, and there has been some debate in the groups about this. At the moment the XML-ueber-alles side is winning.

Re:I don't get it.

[Arandir]

Hey let's get cynical why don't we? Just because they're in desperate need of psychiatric intervention doesn't mean you should make fun of them!