Fix for vanishing attribute namespace prefixes

["Wijlens, Joris (J.)" <Jo...@uwv.nl>]

Hi there,

 

I'm using the XML-security package for a Java project.

 

I have this problem with as you describe it "vanishing attribute namespace
prefixes". I tried the workaround (described in Mikolaj Habryn's message of
Thu, 16 Sep 2004 19:05:56) but that didn't help me. I did the following:

 

   * I create message1 (document) and add a element with namespace.

   * I serialize it into message2 (documentToBeSigned) like this:

 

           OutputFormat format = new OutputFormat(document,"UTF-8",false);

           ByteArrayOutputStream arrayOutputStream = new
ByteArrayOutputStream();

           XMLSerializer serializer = new
XMLSerializer(arrayOutputStream,format);

           serializer.setNamespaces(true);

           serializer.asDOMSerializer();

           serializer.serialize(document.getDocumentElement());

Document documentToBeSigned = documentBuilder.parse(new
ByteArrayInputStream(arrayOutputStream.toByteArray()));

 

   * I sign message2 and yes Mikolaj is right about the namespace being

     added and the signing succeeding, but there are namespaces and empty
namespace (like this: xmlns="")

     attributes all over the place.

   * I "cut" the signature from message2

   * I import the message in message1 and all looks fine.

 

But when I try to verify message1 it fails. I think because I think the
appearing xmlns="" 's in message2 are taken into account when signing the
message (?? and message1 doesn't have them). Am I doing something wrong
here?

 

Besides that I have a couple of questions:

1. Is it planned to be fixed in the coming month (for version 1.2)?

2. Is this problem logged as a bug and can I track it?

3. Is version 1.2 going to be compatible with jdk1.3 because when I
yesterday tried to compile HEAD from CVS with       a 1.3 sdk I got several
compiler errors on RuntimeExceptions that were passing the causing
exceptions.

 

Thanks anyway,

 

Joris Wijlens

 

-- 

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Whitehorses B.V.

Dukatenburg 84a, Nieuwegein, +31 (0)30 - 600 4720

Malburgse Sluis 27, Arnhem, +31 (0)26 - 322 6900

Mobiel: +31 (0)6 - 5200 2532

 

 

Meer weten over nieuwe en interessante Oracle en Java ontwikkelingen?

Wat ze voor u betekenen en wat u er aan heeft?

Lees dan onze maandelijkse Whitebooks op www.whitehorses.nl.

Re: Fix for vanishing attribute namespace prefixes

[Mikolaj Habryn <di...@rcpt.to>]

On Fri, 2004-10-01 at 18:35, Wijlens, Joris (J.) wrote:
> But when I try to verify message1 it fails. I think because I think
> the appearing xmlns="" 's in message2 are taken into account when
> signing the message (?? and message1 doesn't have them). Am I doing
> something wrong here?

You definitely are; the clear blunder that you're guilty of is trusting
the email that I sent. I thought that I had tested that this technique
worked at the time that I wrote the email, but you're quite right,
transferring the signature back to the original document, contrary to my
words, doesn't in fact work. At all.

I was hoping I'd get some time to work out why and send through some
fixes before anybody actually noticed ;) Eyeballing the content doesn't
seem to adequately explain why it doesn't work; in theory, you take
document A, serialize and re-parse it, leaving you with document A
(again), you then insert a signature into it. Inserting a signature
should be a matter of c14n'ing document A, which should *still* leave
you with document A, and then inserting an element somewhere.

Given that all of those steps should happen the same way when validating
a signature, one would think that one should be able to take the
signature element out and insert it into any of the previous versions of
document A, and, as long as it's always in the same place in the
document, it should still validate.

Clearly, it doesn't, meaning that one or more of those transformations
is non-isomorphic. I'm looking at the c14n bit here, since I don't think
it has any business munging the original document anyway, although it
should theoretically still work even if it does. 

Sorry for misleading you!

m.