Blake Dournaee, author of XML Security answers 10 frequently-asked-questions on Web services security, taken from...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
his June 19, 2002 Live Expert Q&A Webcast entitled, "XML security standards: XML Signature, XML Encryption, XKMS. View the audio/visual archive here.
Table of Contents
- Q1. Can XML encryption be done selectively?
- Q2. What XKMS toolkit do you recommend?
- Q3. What do you think of WS Security and WS License?
- Q4. What will replace SSL?
- Q5. How/when will security standards be "good enough"?
- Q6. XKMS vs. WS-Security
- Q7. In an XML Signature, how is the signature computed?
- Q8. Is it necessary to sign the whole XML document?
- Q9. Where does SAML fit in the security schema?
- Q10. More time intensive to generate the hash on large data object?
Q: If you have collaborative partners, then you might only need individual parts of a document encrypted, instead of the entire document. Can XML encryption be done selectively?
A: Yes. Unlike a traditional plaintext->ciphertext transformation, the XML Encryption Recommendation  allows for what is called plaintext replacement. This means that elements and element content (but not document fragments) can be selectively encrypted. When this is done, the original element is replaced with an <EncryptedData> element. In the case of an encrypted key, the original data is replaced with an <EncryptedKey> element.
Q: What XKMS (XML Key Management Specification) toolkit do you recommend?
A: XKMS is still a very new technology and most of the available services are experimental. Check  for a list of available XKMS toolkits.
Q: What do you think of WS Security and WS License? Am I crazy or are does there seem to be a ton of competing security standards out there?
A: WS-Security is a standard that describes how to secure a Web service. XML Signature describes how to digitally sign an XML document. XML Encryption describes how to encrypt an XML document, and XKMS describes an XML-based protocol for delegated trust. These standards do not address the larger problem of how one might secure a Web service. These standards instead describe how to secure XML data whether it is part of a Web service or not.
XML Signature, XML Encryption and XKMS are fundamental for WS-Security. That is, WS-Security  utilizes the concepts and ideas presented in the XML Signature Recommendation, XML Encryption, and XKMS. WS-Security does not compete against XML Signature or XML Encryption. Instead, WS-Security builds on top of these standards.
Q: Given that SSL is fairly cpu/bandwidth intensive, but accepted, what will replace it?
A: SSL is great for securing socket based communication between two authenticated hosts. The argument that it is cpu/bandwidth intensive must be qualified. First of all, the handshake process of SSL is the most CPU intensive, and when client authentication is used, the handshake time increases because both sides must perform expensive private key operations (in the case of the RSA algorithm). The actual encrypted stream of SSL, however, is not overly bandwidth intensive. In fact, one can argue that SOAP messages, with their verbose syntax (using XML) are far more bandwidth intensive than SSL protocol messages, which use a binary encoding.
SSL does have a number of shortcomings: First, it does not scale well across multi-host paths. That is, it is good at making a secure connection from node A to node B, but does not scale well when intermediate nodes along the path from A to B must also be involved in the secure transmission. Secondly, SSL does not provide persistent protection for data because only the socket itself is secured, not the data stream that is being passed through the socket.
Assuming that SOAP is used as a messaging scheme, one possible replacement for SSL that would provide some of the benefits of SSL would be the selective encryption and/or signing of pieces and parts of a SOAP message. This allows intermediate nodes to operate on the unsigned, clear data while providing persistent protection for SOAP messages. Environments that do not have these requirements (intermediate node requirements and persistent data protection) can do just fine with a client-authenticated SSL solution.
Q: How/when will security standards be "good enough" to garner enough trust that is can be widely deployed?
A: Traditionally, security standards come from either RSA Laboratories , in the form of PKCS standards, or the W3C, for "Web-based" or "XML-based" security standards. The PKCS standards are fundamental for most encryption and signature algorithms, as well as messaging syntaxes such as PKCS#7 and S/MIME. The W3C standards are considered mature when they reach the "Recommendation" status. For example, XML Signature , is at "Recommendation" status, meaning it is finalized and ready to be used. The other two XML Security standards, XML Encryption and XKMS are in different places on the road to Recommendation status, but they are well-defined enough thus far to support experimental implementations.
Q: XKMS vs. WS-Security - compare and what are the interoperability issues?
A: XKMS  and WS-Security  address different issues. XKMS is an XML-based protocol used to establish the location of public keys and public key name binding, as well as handle operations such as key registration, key revocation, and key recovery. WS-Security is a specification that describes how to secure a Web service in general, specifically by adding extensions to SOAP documents to allow for combinations of encryption and signing. In short, they do not compete with each other. The issue of trust is out of scope for WS-Security, but in scope for XKMS.
Q: In an XML Signature, how is the signature computed?
A: The canonical form of the <SignedInfo> element is signed using an RSA signature (a hash operation and then an RSA private key operation), a DSA signature (a hash operation and then a DSA signing operation) or an HMAC (a SHA1 hash of the XOR of a symmetric key and the original message).
Q: Is it necessary to sign the whole XML document or can we do only a part of it ?
A: An XML Signature can selectively sign a given piece of plaintext with the use of a fragment identifier, which identifies an element to sign by Id value, or an XPath transformation, which allows an arbitrary document subset to be signed. See  for more information.
Q: Where does SAML fit in the security schema?
A: SAML is an XML-based syntax that describes assertions. SAML assertions are XML data and can be signed and/or encrypted using XML Signature or XML Encryption.
Q: In your experience, is it more time intensive to generate the hash on one large data object or the equivalent aggregate sized smaller data objects?
A: Cryptographic hash functions are fast operations. Most use bit shifting, XOR and simple addition. Further, hash functions such as SHA process the input in blocks, and no block takes longer to process than another. The only real speed differences here are going to be I/O time and memory usage to hold one large file instead of many smaller ones. Also, one hash of one large file produces a single hash output, whereas many hashes of many files produce many hash outputs. The two processes ultimately accomplish different end results. XML Signature hashes each Web object being referenced, and then this list of objects is what is signed.
 XML-Signature Syntax and Processing, http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/
 XML-Encryption Syntax and Processing, http://www.w3.org/TR/2002/CR-xmlenc-core-20020304/
 XKMS Working Group, http://www.w3.org/2001/XKMS/
 RSA Laboratories, http://www.rsasecurity.com/rsalabs/