> So, for example, if the original base64 encoded data > comes through SMTP, we will have to decode and encode > it again if we have to put the same value in an XML?
No, precisely the opposite. Anything you get that's legal base64, whatever the line length, is "legal" XML, and moreover is valid with respect to the rules for base64Binary in XSD. So saying that it should look a certain way is only advisory. In other words, xmlsec producing the line feeds is legal. That's all I was trying to say. Requiring them would not be, obviously. I must have said something that confused you or that I didn't say clearly. I wasn't trying to argue anything else. > What I am driving at is that having new lines in > base64 encoded data is not restricted by any spec - in > fact it is deemed necessary by at least one spec. > And also that you can make your decoder flexible by > checking and setting the flag as I mentioned earlier. Sure. All I was saying in the thread was that one reason why the linefeeds were useful was because that flag was either not known, not implemented, etc, so without them, using OpenSSL's decoder was a problem. And the workaround was to not use OpenSSL's decoder, which is really the better solution...yeah, the flag's there, but why bother when you can just do it in one pass without examining the data first? > But normalization is a real problem for signature > validation, as you mentioned earlier - looks like > whitespace facet for signed content must always be > preserve - particularly if you have schema validators > before signature verification. Correct, and of course this isn't allowed by XSD, which requires collapse for base64Binary. So you have to turn the normalization off to get it to work. In practice, what makes things tend to work is that schema validation and signature-oriented applications aren't all that overlapping in practice, something I had to learn the hard way. -- Scott
