> This discussion piqued my interest (what did Scott mean when > he said the whitespace issues are a real mess?), so I did a > little research. For those who know as little as I, here's > what I found.
Note that the context for my comment is mostly digital signatures. The major problem there isn't about base64 per se, it just happens to show up there more often, and has to do with the inconsistency between standard C14N and schema normalization in terms of whitespace normalization. Base64 is an example of data where people tend to see all sorts of different behavior from encoders wrt whitespace generation, and it tends to be out of one's control in some cases. That leads to problems that can be difficult to solve portably. > So, it looks like generic base64 encoders and decoders would > have to be told what the whitespace and line wrapping rules > are. Rather than have such generic functions, Xerces-C > includes functions that attempt to implement what is needed > and no more: Schema bas64Binary. I haven't looked at the > implementation, but it looks to me like an encoder that > generates base64Binary and complies with RFC 3548 would > either omit whitespace (including line breaks) entirely OR > generate Schema's canonical form. Yep, that's more or less how it looked to me. So I think xmlsec is going to start generating canonical form, since the whitespace makes signatures more readable. Thanks for the legwork. -- Scott --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
