You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@santuario.apache.org by "Clement Pellerin (Created) (JIRA)" <ji...@apache.org> on 2012/03/28 18:17:28 UTC
[jira] [Created] (SANTUARIO-309) Default XMLCipher canonicalizer
may decrypt element to the wrong namespace
Default XMLCipher canonicalizer may decrypt element to the wrong namespace
--------------------------------------------------------------------------
Key: SANTUARIO-309
URL: https://issues.apache.org/jira/browse/SANTUARIO-309
Project: Santuario
Issue Type: Bug
Affects Versions: Java 1.5.1, Java 1.4.5
Reporter: Clement Pellerin
Assignee: Colm O hEigeartaigh
The default XMLCipher canonicalizer is Inclusive XML C14N with comments. This canonicalization has the problem described in the XML Encryption spec section 4.3.3. If the encrypted element <elem> undeclares the default namespace inherited from its parent, the resulting decrypted element is missing the undeclaration and therefore the element lays in the wrong namespace.
In this example, <elem> moves from the global namespace to the http://default.com namespace.
<env:Envelope xmlns="http://default.com" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"><env:Body><elem xmlns="">11</elem></env:Body></env:Envelope>"
It would be tempting to use Exclusive XML C14N, but this algorithm also has problems. It removes namespace declarations that are not visibly used. If the namespace prefix is used only in text mode, the algorithm cannot detect it.
I would argue that the best way to solve this problem is to create a non-standard canonicalization that simply emits the nodes as is. This is like a pretty-printer without indenting.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANTUARIO-309) Default XMLCipher canonicalizer
may decrypt element to the wrong namespace
Posted by "Colm O hEigeartaigh (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SANTUARIO-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13245326#comment-13245326 ]
Colm O hEigeartaigh commented on SANTUARIO-309:
-----------------------------------------------
I'm going to look into using a DOM2Writer approach to directly serialize the Element into an array of bytes instead of using c14n for encryption over the next few weeks.
Colm.
> Default XMLCipher canonicalizer may decrypt element to the wrong namespace
> --------------------------------------------------------------------------
>
> Key: SANTUARIO-309
> URL: https://issues.apache.org/jira/browse/SANTUARIO-309
> Project: Santuario
> Issue Type: Bug
> Components: Java
> Affects Versions: Java 1.4.5, Java 1.5.1
> Reporter: Clement Pellerin
> Assignee: Colm O hEigeartaigh
> Attachments: TestC14N.java
>
>
> The default XMLCipher canonicalizer is Inclusive XML C14N with comments. This canonicalization has the problem described in the XML Encryption spec section 4.3.3. If the encrypted element <elem> undeclares the default namespace inherited from its parent, the resulting decrypted element is missing the undeclaration and therefore the element lays in the wrong namespace.
> In this example, <elem> moves from the global namespace to the http://default.com namespace.
> <env:Envelope xmlns="http://default.com" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"><env:Body><elem xmlns="">11</elem></env:Body></env:Envelope>"
> It would be tempting to use Exclusive XML C14N, but this algorithm also has problems. It removes namespace declarations that are not visibly used. If the namespace prefix is used only in text mode, the algorithm cannot detect it.
> I would argue that the best way to solve this problem is to create a non-standard canonicalization that simply emits the nodes as is. This is like a pretty-printer without indenting.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANTUARIO-309) Default XMLCipher canonicalizer
may decrypt element to the wrong namespace
Posted by "Clement Pellerin (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SANTUARIO-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13246254#comment-13246254 ]
Clement Pellerin commented on SANTUARIO-309:
--------------------------------------------
I cannot reproduce the test case error. What is the output that you get?
I'm running on Windows 7 with jdk1.6.0_21.
The only error I get is from ECDSA, it says org.apache.xml.security.keys.keyresolver.KeyResolverException: java.io.IOException: Only named ECParameters supported
but this predates my fix.
> Default XMLCipher canonicalizer may decrypt element to the wrong namespace
> --------------------------------------------------------------------------
>
> Key: SANTUARIO-309
> URL: https://issues.apache.org/jira/browse/SANTUARIO-309
> Project: Santuario
> Issue Type: Bug
> Components: Java
> Affects Versions: Java 1.4.5, Java 1.5.1
> Reporter: Clement Pellerin
> Assignee: Colm O hEigeartaigh
> Attachments: SANTUARIO-309.diff, TestC14N.java
>
>
> The default XMLCipher canonicalizer is Inclusive XML C14N with comments. This canonicalization has the problem described in the XML Encryption spec section 4.3.3. If the encrypted element <elem> undeclares the default namespace inherited from its parent, the resulting decrypted element is missing the undeclaration and therefore the element lays in the wrong namespace.
> In this example, <elem> moves from the global namespace to the http://default.com namespace.
> <env:Envelope xmlns="http://default.com" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"><env:Body><elem xmlns="">11</elem></env:Body></env:Envelope>"
> It would be tempting to use Exclusive XML C14N, but this algorithm also has problems. It removes namespace declarations that are not visibly used. If the namespace prefix is used only in text mode, the algorithm cannot detect it.
> I would argue that the best way to solve this problem is to create a non-standard canonicalization that simply emits the nodes as is. This is like a pretty-printer without indenting.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (SANTUARIO-309) Default XMLCipher
canonicalizer may decrypt element to the wrong namespace
Posted by "Clement Pellerin (Issue Comment Edited) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SANTUARIO-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13246331#comment-13246331 ]
Clement Pellerin edited comment on SANTUARIO-309 at 4/4/12 3:09 PM:
--------------------------------------------------------------------
Uploaded SANTUARIO-309b.diff
This is the same fix with updated junit test.
The asserts were not compiled in, so the test case appeared to work when in fact it was failing.
I thought calling assert was strange but I was just trying to be consistent with the rest of the file.
was (Author: clement_pellerin@ibi.com):
Same fix with updated junit test.
The asserts were not compiled in, so the test case appeared to work when in fact it was failing.
I thought calling assert was strange but I was just trying to be consistent with the rest of the file.
> Default XMLCipher canonicalizer may decrypt element to the wrong namespace
> --------------------------------------------------------------------------
>
> Key: SANTUARIO-309
> URL: https://issues.apache.org/jira/browse/SANTUARIO-309
> Project: Santuario
> Issue Type: Bug
> Components: Java
> Affects Versions: Java 1.4.5, Java 1.5.1
> Reporter: Clement Pellerin
> Assignee: Colm O hEigeartaigh
> Attachments: SANTUARIO-309.diff, SANTUARIO-309b.diff, TestC14N.java
>
>
> The default XMLCipher canonicalizer is Inclusive XML C14N with comments. This canonicalization has the problem described in the XML Encryption spec section 4.3.3. If the encrypted element <elem> undeclares the default namespace inherited from its parent, the resulting decrypted element is missing the undeclaration and therefore the element lays in the wrong namespace.
> In this example, <elem> moves from the global namespace to the http://default.com namespace.
> <env:Envelope xmlns="http://default.com" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"><env:Body><elem xmlns="">11</elem></env:Body></env:Envelope>"
> It would be tempting to use Exclusive XML C14N, but this algorithm also has problems. It removes namespace declarations that are not visibly used. If the namespace prefix is used only in text mode, the algorithm cannot detect it.
> I would argue that the best way to solve this problem is to create a non-standard canonicalization that simply emits the nodes as is. This is like a pretty-printer without indenting.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SANTUARIO-309) Default XMLCipher canonicalizer
may decrypt element to the wrong namespace
Posted by "Clement Pellerin (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SANTUARIO-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Clement Pellerin updated SANTUARIO-309:
---------------------------------------
Attachment: SANTUARIO-309b.diff
Same fix with updated junit test.
The asserts were not compiled in, so the test case appeared to work when in fact it was failing.
I thought calling assert was strange but I was just trying to be consistent with the rest of the file.
> Default XMLCipher canonicalizer may decrypt element to the wrong namespace
> --------------------------------------------------------------------------
>
> Key: SANTUARIO-309
> URL: https://issues.apache.org/jira/browse/SANTUARIO-309
> Project: Santuario
> Issue Type: Bug
> Components: Java
> Affects Versions: Java 1.4.5, Java 1.5.1
> Reporter: Clement Pellerin
> Assignee: Colm O hEigeartaigh
> Attachments: SANTUARIO-309.diff, SANTUARIO-309b.diff, TestC14N.java
>
>
> The default XMLCipher canonicalizer is Inclusive XML C14N with comments. This canonicalization has the problem described in the XML Encryption spec section 4.3.3. If the encrypted element <elem> undeclares the default namespace inherited from its parent, the resulting decrypted element is missing the undeclaration and therefore the element lays in the wrong namespace.
> In this example, <elem> moves from the global namespace to the http://default.com namespace.
> <env:Envelope xmlns="http://default.com" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"><env:Body><elem xmlns="">11</elem></env:Body></env:Envelope>"
> It would be tempting to use Exclusive XML C14N, but this algorithm also has problems. It removes namespace declarations that are not visibly used. If the namespace prefix is used only in text mode, the algorithm cannot detect it.
> I would argue that the best way to solve this problem is to create a non-standard canonicalization that simply emits the nodes as is. This is like a pretty-printer without indenting.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SANTUARIO-309) Default XMLCipher canonicalizer
may decrypt element to the wrong namespace
Posted by "Colm O hEigeartaigh (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SANTUARIO-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Colm O hEigeartaigh updated SANTUARIO-309:
------------------------------------------
Component/s: Java
> Default XMLCipher canonicalizer may decrypt element to the wrong namespace
> --------------------------------------------------------------------------
>
> Key: SANTUARIO-309
> URL: https://issues.apache.org/jira/browse/SANTUARIO-309
> Project: Santuario
> Issue Type: Bug
> Components: Java
> Affects Versions: Java 1.4.5, Java 1.5.1
> Reporter: Clement Pellerin
> Assignee: Colm O hEigeartaigh
> Attachments: TestC14N.java
>
>
> The default XMLCipher canonicalizer is Inclusive XML C14N with comments. This canonicalization has the problem described in the XML Encryption spec section 4.3.3. If the encrypted element <elem> undeclares the default namespace inherited from its parent, the resulting decrypted element is missing the undeclaration and therefore the element lays in the wrong namespace.
> In this example, <elem> moves from the global namespace to the http://default.com namespace.
> <env:Envelope xmlns="http://default.com" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"><env:Body><elem xmlns="">11</elem></env:Body></env:Envelope>"
> It would be tempting to use Exclusive XML C14N, but this algorithm also has problems. It removes namespace declarations that are not visibly used. If the namespace prefix is used only in text mode, the algorithm cannot detect it.
> I would argue that the best way to solve this problem is to create a non-standard canonicalization that simply emits the nodes as is. This is like a pretty-printer without indenting.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANTUARIO-309) Default XMLCipher canonicalizer
may decrypt element to the wrong namespace
Posted by "Clement Pellerin (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SANTUARIO-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13245360#comment-13245360 ]
Clement Pellerin commented on SANTUARIO-309:
--------------------------------------------
I'm working on a solution that appears as a canonicalizer, because the choice of canonicalizer name is exposed in the XMLCipher constructor. My canonicalizer is still sorting the attributes, but we could change the innards of the canonicalizer to skip that too. I'm about to test it today. Stay tuned.
> Default XMLCipher canonicalizer may decrypt element to the wrong namespace
> --------------------------------------------------------------------------
>
> Key: SANTUARIO-309
> URL: https://issues.apache.org/jira/browse/SANTUARIO-309
> Project: Santuario
> Issue Type: Bug
> Components: Java
> Affects Versions: Java 1.4.5, Java 1.5.1
> Reporter: Clement Pellerin
> Assignee: Colm O hEigeartaigh
> Attachments: TestC14N.java
>
>
> The default XMLCipher canonicalizer is Inclusive XML C14N with comments. This canonicalization has the problem described in the XML Encryption spec section 4.3.3. If the encrypted element <elem> undeclares the default namespace inherited from its parent, the resulting decrypted element is missing the undeclaration and therefore the element lays in the wrong namespace.
> In this example, <elem> moves from the global namespace to the http://default.com namespace.
> <env:Envelope xmlns="http://default.com" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"><env:Body><elem xmlns="">11</elem></env:Body></env:Envelope>"
> It would be tempting to use Exclusive XML C14N, but this algorithm also has problems. It removes namespace declarations that are not visibly used. If the namespace prefix is used only in text mode, the algorithm cannot detect it.
> I would argue that the best way to solve this problem is to create a non-standard canonicalization that simply emits the nodes as is. This is like a pretty-printer without indenting.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SANTUARIO-309) Default XMLCipher canonicalizer
may decrypt element to the wrong namespace
Posted by "Colm O hEigeartaigh (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SANTUARIO-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Colm O hEigeartaigh updated SANTUARIO-309:
------------------------------------------
Fix Version/s: Java 1.5.2
> Default XMLCipher canonicalizer may decrypt element to the wrong namespace
> --------------------------------------------------------------------------
>
> Key: SANTUARIO-309
> URL: https://issues.apache.org/jira/browse/SANTUARIO-309
> Project: Santuario
> Issue Type: Bug
> Components: Java
> Affects Versions: Java 1.4.5, Java 1.5.1
> Reporter: Clement Pellerin
> Assignee: Colm O hEigeartaigh
> Fix For: Java 1.5.2
>
> Attachments: SANTUARIO-309.diff, SANTUARIO-309b.diff, SANTUARIO-309c.diff, TestC14N.java
>
>
> The default XMLCipher canonicalizer is Inclusive XML C14N with comments. This canonicalization has the problem described in the XML Encryption spec section 4.3.3. If the encrypted element <elem> undeclares the default namespace inherited from its parent, the resulting decrypted element is missing the undeclaration and therefore the element lays in the wrong namespace.
> In this example, <elem> moves from the global namespace to the http://default.com namespace.
> <env:Envelope xmlns="http://default.com" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"><env:Body><elem xmlns="">11</elem></env:Body></env:Envelope>"
> It would be tempting to use Exclusive XML C14N, but this algorithm also has problems. It removes namespace declarations that are not visibly used. If the namespace prefix is used only in text mode, the algorithm cannot detect it.
> I would argue that the best way to solve this problem is to create a non-standard canonicalization that simply emits the nodes as is. This is like a pretty-printer without indenting.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANTUARIO-309) Default XMLCipher canonicalizer
may decrypt element to the wrong namespace
Posted by "Colm O hEigeartaigh (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SANTUARIO-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13246255#comment-13246255 ]
Colm O hEigeartaigh commented on SANTUARIO-309:
-----------------------------------------------
testPhysicalRepresentation(org.apache.xml.security.test.encryption.XMLCipherTest) Time elapsed: 0.004 sec <<< FAILURE!
java.lang.AssertionError
at org.apache.xml.security.test.encryption.XMLCipherTest.testPhysicalRepresentation(XMLCipherTest.java:666)
The actual output is "xenc:EncryptedData".
Could you also replace the assert's with assertEquals or assertTrue?
Colm.
> Default XMLCipher canonicalizer may decrypt element to the wrong namespace
> --------------------------------------------------------------------------
>
> Key: SANTUARIO-309
> URL: https://issues.apache.org/jira/browse/SANTUARIO-309
> Project: Santuario
> Issue Type: Bug
> Components: Java
> Affects Versions: Java 1.4.5, Java 1.5.1
> Reporter: Clement Pellerin
> Assignee: Colm O hEigeartaigh
> Attachments: SANTUARIO-309.diff, TestC14N.java
>
>
> The default XMLCipher canonicalizer is Inclusive XML C14N with comments. This canonicalization has the problem described in the XML Encryption spec section 4.3.3. If the encrypted element <elem> undeclares the default namespace inherited from its parent, the resulting decrypted element is missing the undeclaration and therefore the element lays in the wrong namespace.
> In this example, <elem> moves from the global namespace to the http://default.com namespace.
> <env:Envelope xmlns="http://default.com" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"><env:Body><elem xmlns="">11</elem></env:Body></env:Envelope>"
> It would be tempting to use Exclusive XML C14N, but this algorithm also has problems. It removes namespace declarations that are not visibly used. If the namespace prefix is used only in text mode, the algorithm cannot detect it.
> I would argue that the best way to solve this problem is to create a non-standard canonicalization that simply emits the nodes as is. This is like a pretty-printer without indenting.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SANTUARIO-309) Default XMLCipher canonicalizer
may decrypt element to the wrong namespace
Posted by "Clement Pellerin (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SANTUARIO-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Clement Pellerin updated SANTUARIO-309:
---------------------------------------
Attachment: SANTUARIO-309.diff
Here is a patch that implements the non-standard Physical XML Canonicalization and makes it the default in XMLCipher. This algorithm is not a real canonicalization since it preserves the physical representation. It is implemented as a canonicalizer to fit in the current framework. The canonicalizer name is a parameter of the XMLCipher.
The attributes are still sorted, so in theory if the initialization vector is the same, the encryption could produce the same result on physically equivalent documents.
A junit is provided with some cases documented in SANTUARIO-308.
Have you ever noticed that C14N is mis-spelled N14C in XMLCipher public static constants? To keep it consistent, I mis-spelled the new constant name too.
> Default XMLCipher canonicalizer may decrypt element to the wrong namespace
> --------------------------------------------------------------------------
>
> Key: SANTUARIO-309
> URL: https://issues.apache.org/jira/browse/SANTUARIO-309
> Project: Santuario
> Issue Type: Bug
> Components: Java
> Affects Versions: Java 1.4.5, Java 1.5.1
> Reporter: Clement Pellerin
> Assignee: Colm O hEigeartaigh
> Attachments: SANTUARIO-309.diff, TestC14N.java
>
>
> The default XMLCipher canonicalizer is Inclusive XML C14N with comments. This canonicalization has the problem described in the XML Encryption spec section 4.3.3. If the encrypted element <elem> undeclares the default namespace inherited from its parent, the resulting decrypted element is missing the undeclaration and therefore the element lays in the wrong namespace.
> In this example, <elem> moves from the global namespace to the http://default.com namespace.
> <env:Envelope xmlns="http://default.com" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"><env:Body><elem xmlns="">11</elem></env:Body></env:Envelope>"
> It would be tempting to use Exclusive XML C14N, but this algorithm also has problems. It removes namespace declarations that are not visibly used. If the namespace prefix is used only in text mode, the algorithm cannot detect it.
> I would argue that the best way to solve this problem is to create a non-standard canonicalization that simply emits the nodes as is. This is like a pretty-printer without indenting.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANTUARIO-309) Default XMLCipher canonicalizer
may decrypt element to the wrong namespace
Posted by "Colm O hEigeartaigh (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SANTUARIO-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13246225#comment-13246225 ]
Colm O hEigeartaigh commented on SANTUARIO-309:
-----------------------------------------------
Hi Clement,
Looks fine to me. XMLCipherTest.testPhysicalRepresentation is failing for me with the change though?
Colm.
> Default XMLCipher canonicalizer may decrypt element to the wrong namespace
> --------------------------------------------------------------------------
>
> Key: SANTUARIO-309
> URL: https://issues.apache.org/jira/browse/SANTUARIO-309
> Project: Santuario
> Issue Type: Bug
> Components: Java
> Affects Versions: Java 1.4.5, Java 1.5.1
> Reporter: Clement Pellerin
> Assignee: Colm O hEigeartaigh
> Attachments: SANTUARIO-309.diff, TestC14N.java
>
>
> The default XMLCipher canonicalizer is Inclusive XML C14N with comments. This canonicalization has the problem described in the XML Encryption spec section 4.3.3. If the encrypted element <elem> undeclares the default namespace inherited from its parent, the resulting decrypted element is missing the undeclaration and therefore the element lays in the wrong namespace.
> In this example, <elem> moves from the global namespace to the http://default.com namespace.
> <env:Envelope xmlns="http://default.com" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"><env:Body><elem xmlns="">11</elem></env:Body></env:Envelope>"
> It would be tempting to use Exclusive XML C14N, but this algorithm also has problems. It removes namespace declarations that are not visibly used. If the namespace prefix is used only in text mode, the algorithm cannot detect it.
> I would argue that the best way to solve this problem is to create a non-standard canonicalization that simply emits the nodes as is. This is like a pretty-printer without indenting.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SANTUARIO-309) Default XMLCipher canonicalizer
may decrypt element to the wrong namespace
Posted by "Colm O hEigeartaigh (Resolved) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SANTUARIO-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Colm O hEigeartaigh resolved SANTUARIO-309.
-------------------------------------------
Resolution: Fixed
> Default XMLCipher canonicalizer may decrypt element to the wrong namespace
> --------------------------------------------------------------------------
>
> Key: SANTUARIO-309
> URL: https://issues.apache.org/jira/browse/SANTUARIO-309
> Project: Santuario
> Issue Type: Bug
> Components: Java
> Affects Versions: Java 1.4.5, Java 1.5.1
> Reporter: Clement Pellerin
> Assignee: Colm O hEigeartaigh
> Fix For: Java 1.5.2
>
> Attachments: SANTUARIO-309.diff, SANTUARIO-309b.diff, SANTUARIO-309c.diff, TestC14N.java
>
>
> The default XMLCipher canonicalizer is Inclusive XML C14N with comments. This canonicalization has the problem described in the XML Encryption spec section 4.3.3. If the encrypted element <elem> undeclares the default namespace inherited from its parent, the resulting decrypted element is missing the undeclaration and therefore the element lays in the wrong namespace.
> In this example, <elem> moves from the global namespace to the http://default.com namespace.
> <env:Envelope xmlns="http://default.com" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"><env:Body><elem xmlns="">11</elem></env:Body></env:Envelope>"
> It would be tempting to use Exclusive XML C14N, but this algorithm also has problems. It removes namespace declarations that are not visibly used. If the namespace prefix is used only in text mode, the algorithm cannot detect it.
> I would argue that the best way to solve this problem is to create a non-standard canonicalization that simply emits the nodes as is. This is like a pretty-printer without indenting.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SANTUARIO-309) Default XMLCipher canonicalizer
may decrypt element to the wrong namespace
Posted by "Clement Pellerin (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SANTUARIO-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Clement Pellerin updated SANTUARIO-309:
---------------------------------------
Attachment: TestC14N.java
See the attached class that reproduces the problem.
> Default XMLCipher canonicalizer may decrypt element to the wrong namespace
> --------------------------------------------------------------------------
>
> Key: SANTUARIO-309
> URL: https://issues.apache.org/jira/browse/SANTUARIO-309
> Project: Santuario
> Issue Type: Bug
> Affects Versions: Java 1.4.5, Java 1.5.1
> Reporter: Clement Pellerin
> Assignee: Colm O hEigeartaigh
> Attachments: TestC14N.java
>
>
> The default XMLCipher canonicalizer is Inclusive XML C14N with comments. This canonicalization has the problem described in the XML Encryption spec section 4.3.3. If the encrypted element <elem> undeclares the default namespace inherited from its parent, the resulting decrypted element is missing the undeclaration and therefore the element lays in the wrong namespace.
> In this example, <elem> moves from the global namespace to the http://default.com namespace.
> <env:Envelope xmlns="http://default.com" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"><env:Body><elem xmlns="">11</elem></env:Body></env:Envelope>"
> It would be tempting to use Exclusive XML C14N, but this algorithm also has problems. It removes namespace declarations that are not visibly used. If the namespace prefix is used only in text mode, the algorithm cannot detect it.
> I would argue that the best way to solve this problem is to create a non-standard canonicalization that simply emits the nodes as is. This is like a pretty-printer without indenting.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (SANTUARIO-309) Default XMLCipher canonicalizer may
decrypt element to the wrong namespace
Posted by "Colm O hEigeartaigh (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SANTUARIO-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Colm O hEigeartaigh closed SANTUARIO-309.
-----------------------------------------
> Default XMLCipher canonicalizer may decrypt element to the wrong namespace
> --------------------------------------------------------------------------
>
> Key: SANTUARIO-309
> URL: https://issues.apache.org/jira/browse/SANTUARIO-309
> Project: Santuario
> Issue Type: Bug
> Components: Java
> Affects Versions: Java 1.4.5, Java 1.5.1
> Reporter: Clement Pellerin
> Assignee: Colm O hEigeartaigh
> Fix For: Java 1.5.2
>
> Attachments: SANTUARIO-309.diff, SANTUARIO-309b.diff, SANTUARIO-309c.diff, TestC14N.java
>
>
> The default XMLCipher canonicalizer is Inclusive XML C14N with comments. This canonicalization has the problem described in the XML Encryption spec section 4.3.3. If the encrypted element <elem> undeclares the default namespace inherited from its parent, the resulting decrypted element is missing the undeclaration and therefore the element lays in the wrong namespace.
> In this example, <elem> moves from the global namespace to the http://default.com namespace.
> <env:Envelope xmlns="http://default.com" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"><env:Body><elem xmlns="">11</elem></env:Body></env:Envelope>"
> It would be tempting to use Exclusive XML C14N, but this algorithm also has problems. It removes namespace declarations that are not visibly used. If the namespace prefix is used only in text mode, the algorithm cannot detect it.
> I would argue that the best way to solve this problem is to create a non-standard canonicalization that simply emits the nodes as is. This is like a pretty-printer without indenting.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SANTUARIO-309) Default XMLCipher canonicalizer
may decrypt element to the wrong namespace
Posted by "Clement Pellerin (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SANTUARIO-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Clement Pellerin updated SANTUARIO-309:
---------------------------------------
Attachment: SANTUARIO-309c.diff
Uploaded SANTUARIO-309c.diff
This contains a patch to remove assert in other junits.
There was only one other junit calling assert.
> Default XMLCipher canonicalizer may decrypt element to the wrong namespace
> --------------------------------------------------------------------------
>
> Key: SANTUARIO-309
> URL: https://issues.apache.org/jira/browse/SANTUARIO-309
> Project: Santuario
> Issue Type: Bug
> Components: Java
> Affects Versions: Java 1.4.5, Java 1.5.1
> Reporter: Clement Pellerin
> Assignee: Colm O hEigeartaigh
> Attachments: SANTUARIO-309.diff, SANTUARIO-309b.diff, SANTUARIO-309c.diff, TestC14N.java
>
>
> The default XMLCipher canonicalizer is Inclusive XML C14N with comments. This canonicalization has the problem described in the XML Encryption spec section 4.3.3. If the encrypted element <elem> undeclares the default namespace inherited from its parent, the resulting decrypted element is missing the undeclaration and therefore the element lays in the wrong namespace.
> In this example, <elem> moves from the global namespace to the http://default.com namespace.
> <env:Envelope xmlns="http://default.com" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"><env:Body><elem xmlns="">11</elem></env:Body></env:Envelope>"
> It would be tempting to use Exclusive XML C14N, but this algorithm also has problems. It removes namespace declarations that are not visibly used. If the namespace prefix is used only in text mode, the algorithm cannot detect it.
> I would argue that the best way to solve this problem is to create a non-standard canonicalization that simply emits the nodes as is. This is like a pretty-printer without indenting.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira