Hacker News Reader

Comment by vbezhenar | Hacker News Reader

What's confusing about it? Everything seems pretty obvious to me.

To clarify, in signing you have to convert xml to bytes you can get back in the other side, while modifying the same bytes injecting signatures. The whole custom canonical xml serializer is actually complex with escape rules and a bunch of other insanity. On the other side you have to do the opposite by dropping the signature element and serializing the same way.

Worse this is done at an element level not a document level as noted in the linked article.

Really, it’s not that simple. It typically requires a while xml library for dealing with it that is error prone. Check the number of errors and cves for libxmlsec for example. Or even the versions in C# or Java.

Adding Signatures to an existing document, no matter the format is just a whole bunch of trouble.

To expand, generally you wouldn't want to change the identity of the document by signing it (eg change it's hash). That's bananas. If the signature was external to the document, you wouldn't need any complex and error prone rules to canonicalize. You'd just generate an HMAC tag and send it alongside (or, better yet, use an authenticated encryption like AES-GCM).

The sane thing is to sign bytes, as you suggest. But OP is right that it needs to preclude adding signatures to a document.

Xml canonicalization is insane but necessary. Far more complex than the signature process itself

Then the incredibly stupid need to modify the signed document to insert the signature online so verifying it requires a full blown parser among other things

Exactly, I had worked on creating a implementation of saml in go, initially I wanted to use the builtin xml library but quickly found it to be overwhelmingly difficult and ended up creating a binding to xmlsec.

Go's XML namespace handling is broken and has been for years. It's a shame.

Reply on news.ycombinator.com