The whole thing about serialisation of data prior to encryption is
fraught with problems. Exc-c14n fixed some of them for me - but
obviously there are others I missed!
Are you able to give me a fragment of something that breaks? I think I
can see what you are getting at below, but a concrete example would make
it easier for me :>.
Cheers,
Berin
Scott Cantor wrote:
> Berin,
>
> I'm not sure that using exclusive c14n is the best option in the
> encryptElement routines for serializing the data to be encrypted. At the
> very least, if you're going to do that, you really have to expose an
> inclusive prefix capability or there's no way to safely encrypt elements
> that contain QName-valued children or attributes, including xsi:type. The
> resulting data won't necessarily be well-formed, and break on the other end.
>
> My guess is that signature applications that need excl-c14n are already
> using that in the signature, so if you had a signed fragment and then
> encrypted it, it would be "safe" to use inclusive c14n when encrypting
> because the signature transforms will take care of applying the exclusive
> version to the data when verifying the signature later.
>
> As usual, none of this stuff really works right in the general case. We're
> all just trying to play enough games to make it appear to work often enough
> to fool people. ;-)
>
> -- Scott
>
>
>
