Johannes Ernst, Master Simplifier: Really Simple XML Signatures

23Feb - by Frank Koehntopp - 9 - In Security

Johannes proposes a simplified approach to XML Signatures.

Actually, that’s how I thought it would work before I read that ‘XML Security’ book ;)

So, can anybody elaborate on why we can’t do that? I mean, apart from all the crap standards bodies: why not just do it, following the RSS example? The Atom guys can then spend the next few years telling us why we need a better namespace design.

9 thoughts on “Johannes Ernst, Master Simplifier: Really Simple XML Signatures”

  1. Pingback: Rohan Pinto
  2. Pingback: DeveloperZen.com
  3. Pingback: DeveloperZen.com
  4. Consider it this way, how many transformations can you make on a DER encoded X.509 certificate without changing it’s meaning in any way? Answer to rhetorical question, zero. That’s why we have all the hoopla with PEM to get the certificate through non-8 bit safe environments intact, and that’s why if I sign a certificate, it really is sign once, verify everywhere.

    Now, ask the same question of XML. How many transformations can I make on an XML document without changing it’s meaning in the slightest? Thousands and thousands! Why, think of all the things I can do the whitespace. That’s explicitly ignored in XML anyway, but if I sign it in the way specified, I’m freezing a particular set of whitespace characters as the “correct” ones.

    That’s why the IETF’s secure XML group exists. Before I heard of this discussion, I’d always thought it would be as simple as applying XHash to document and signing the hash. Unfortunately, this proves to be not the case (not least because Xhash was essentially designed for hash tables, and has next to no cryptographic analysis behind it.) I can only think the author of the article you linked to either didn’t read, or didn’t understand the discussion.

  5. Consider it this way, how many transformations can you make on a DER encoded X.509 certificate without changing it's meaning in any way? Answer to rhetorical question, zero. That's why we have all the hoopla with PEM to get the certificate through non-8 bit safe environments intact, and that's why if I sign a certificate, it really is sign once, verify everywhere.

    Now, ask the same question of XML. How many transformations can I make on an XML document without changing it's meaning in the slightest? Thousands and thousands! Why, think of all the things I can do the whitespace. That's explicitly ignored in XML anyway, but if I sign it in the way specified, I'm freezing a particular set of whitespace characters as the "correct" ones.

    That's why the IETF's secure XML group exists. Before I heard of this discussion, I'd always thought it would be as simple as applying XHash to document and signing the hash. Unfortunately, this proves to be not the case (not least because Xhash was essentially designed for hash tables, and has next to no cryptographic analysis behind it.) I can only think the author of the article you linked to either didn't read, or didn't understand the discussion.

  6. Chris: The author of that article would be me. I can assure you that I completely understand why XML DSig has all the complexity it has. But you misunderstand my argument, it is not about that.

    My argument is that if requirements 1 through 1000 (or whatever number) require us to construct technology X, which thus necessarily becomes so complex that only 1% of people can adopt it (for whatever reasons), then it is time to drop, say, requirements 100-1000, meet only a tenth of the previous list of requirements, and build technology that, say, 60% of people can adopt. Albeit for a smaller set of use cases.

    That is what I’m suggesting. Just like RSS: it became so successful precisely because it did not address most of the requirements and thus could be very simple. And after it had become successful, for a small set of all possible use cases, people said “what about addressing a few more requirements”, and we got Atom. I’m sure there will be further upgrades to syndication formats and protocols… We would have neither RSS nor Atom if we had started with the equivalent of XML-DSig for syndication. (actually, historically, I think we did start with the equivalent except that nobody has ever heard of those technologies because they did not find mass adoption)

    Which doesn’t mean I’m arguing against XML-DSig either, by the way. Only that I believe that the way to broad adoption of signed XML may be by "breaking" most of the nice features of a complex technology first. Counter-intutive for techies, I know …

  7. Chris: The author of that article would be me. I can assure you that I completely understand why XML DSig has all the complexity it has. But you misunderstand my argument, it is not about that.

    My argument is that if requirements 1 through 1000 (or whatever number) require us to construct technology X, which thus necessarily becomes so complex that only 1% of people can adopt it (for whatever reasons), then it is time to drop, say, requirements 100-1000, meet only a tenth of the previous list of requirements, and build technology that, say, 60% of people can adopt. Albeit for a smaller set of use cases.

    That is what I'm suggesting. Just like RSS: it became so successful precisely because it did not address most of the requirements and thus could be very simple. And after it had become successful, for a small set of all possible use cases, people said "what about addressing a few more requirements", and we got Atom. I'm sure there will be further upgrades to syndication formats and protocols… We would have neither RSS nor Atom if we had started with the equivalent of XML-DSig for syndication. (actually, historically, I think we did start with the equivalent except that nobody has ever heard of those technologies because they did not find mass adoption)

    Which doesn't mean I'm arguing against XML-DSig either, by the way. Only that I believe that the way to broad adoption of signed XML may be by "breaking" most of the nice features of a complex technology first. Counter-intutive for techies, I know …

Comments are closed.