Re: [VOTE] - Release Apache Santuario - XML Security for Java 4.0.2/3.0.4

[Sean Mullan]

+1

--Sean

On 2/19/24 5:38 AM, Colm O hEigeartaigh wrote:

This is a vote to release Apache Santuario - XML Security for Java
4.0.2 and 3.0.4. They contain a new feature to support Key Agreement
using ECDH-ES.

4.0.2:
   Release notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311231=12353948
   Git tag: 
https://github.com/apache/santuario-xml-security-java/releases/tag/xmlsec-4.0.2
   Artifacts: 
https://repository.apache.org/content/repositories/orgapachesantuario-1047/

3.0.4:
   Release notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311231=12353740.
   Git tag: 
https://github.com/apache/santuario-xml-security-java/releases/tag/xmlsec-3.0.4
   Artifacts: 
https://repository.apache.org/content/repositories/orgapachesantuario-1048/

+1 from me.

Colm.

Re: [VOTE] - Release Apache Santuario - XML Security for Java 4.0.1

[Sean Mullan]

+1.

—Sean

> On Nov 24, 2023, at 9:50 AM, Colm O hEigeartaigh  wrote:
> 
> This is a vote to release Apache Santuario XML Security for Java
> 4.0.1. It contains a bug fix
> https://issues.apache.org/jira/browse/SANTUARIO-609 "Remove call to
> Signature.getProvider() in debug log"
> 
> Artifacts: 
> https://repository.apache.org/content/repositories/orgapachesantuario-1046/
> Git tag: 
> https://github.com/apache/santuario-xml-security-java/releases/tag/xmlsec-4.0.1
> 
> +1 from me.
> 
> Colm.

Re: [VOTE] - Release Apache Santuario - XML Security for Java 3.0.3, 2.3.4 and 2.2.6

[Sean Mullan]

+1

—Sean

> On Oct 13, 2023, at 10:05 AM, Colm O hEigeartaigh  wrote:
> 
> This is a vote to release Apache Santuario - XML Security for Java
> 3.0.3, 2.3.4 and 2.2.6. These are all bug fix releases.
> 
> All artifacts are in the same maven repo for release:
> https://repository.apache.org/content/repositories/orgapachesantuario-1045/
> 
> 3.0.3 git tag: 
> https://github.com/apache/santuario-xml-security-java/releases/tag/xmlsec-3.0.3
> 2.3.4 git tag: 
> https://github.com/apache/santuario-xml-security-java/releases/tag/xmlsec-2.3.4
> 2.2.6 git tag: 
> https://github.com/apache/santuario-xml-security-java/releases/tag/xmlsec-2.2.6
> 
> 3.0.3 issues fixed:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311231=12353074
> 2.3.4 issues fixed:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311231=12353075
> 
> +1 from me.
> 
> Colm.

Re: Issue with support of RSASSA-PSS algorithms with implicit params in Oracle Java 17

[Sean Mullan]

Great - thanks for testing!

—Sean

On Oct 11, 2023, at 11:43 PM, Brent Putman 
mailto:putm...@georgetown.edu>> wrote:


Hi,

Sorry this took longer to get to than I anticipated.  I wanted to report back 
on this before the upcoming Santuario releases.

I have tested OpenSAML against a local build of xmlsec 3.0.3-SNAPSHOT, under 
JDK 17 which is the baseline for our current branch. The new RSASSA-PSS stuff 
seems to work ok.  I have unit tests that exercise signing and validation of 
all 9 of the PSS algorithm URIs, so I'd say it looks good as far as I can tell 
as this point.

Thanks for working on this!

Thanks,
Brent


On 9/13/23 1:31 PM, Brent Putman wrote:
Hi Sean,

Thanks for working on this.  I'll see about doing some local build testing in 
the next few days.

Thanks,
Brent


On 9/12/23 8:45 AM, Sean Mullan wrote:
Hi Brent,

I have fixed this issue [1] and it will be in the next 2.3.4 and 3.0.3 releases 
of Santuario. However, if you have a chance to pull the latest sources and do a 
local build to see if it addresses your concerns, that would be great and 
provide more assurance that it is working.

Thanks,
Sean

[1] https://issues.apache.org/jira/browse/SANTUARIO-604

On 8/10/23 4:26 PM, Brent Putman wrote:

On 8/10/23 1:15 PM, Sean Mullan wrote:
Yes, sorry I guess I wasn't clear enough. This is a Santuario issue. I can 
probably post a PR in the next few days that addresses this.To me this is the 
best solution if you want to provide a solution that works both with BC and the 
JDK.


Ok, thanks! Yes, I agree that it's the best solution, and should be transparent 
to users of the library.


Even if we did add direct support to the JDK for the PSS w/o param algorithm 
URIs as defined in RFC 9231, it would initially only be supported in the next 
version of JDK (22), and would need justification, etc in order to be 
backported to earlier releases.


Yes, and even if it was in 22, it wouldn't help us much (OpenSAML/Shib) as we 
baseline only on LTS releases and so the release of our new 5.0 in the next few 
weeks will be on 17.


Also for some reason, I thought you were a Santuario Committer, so sorry if I 
implied you could do the work. :)


Ah, understood.  Yeah, only Scott from our team is currently a Santuario 
committer.

--Brent

Re: Issue with support of RSASSA-PSS algorithms with implicit params in Oracle Java 17

[Sean Mullan]

Hi Brent,

I have fixed this issue [1] and it will be in the next 2.3.4 and 3.0.3 
releases of Santuario. However, if you have a chance to pull the latest 
sources and do a local build to see if it addresses your concerns, that 
would be great and provide more assurance that it is working.


Thanks,
Sean

[1] https://issues.apache.org/jira/browse/SANTUARIO-604

On 8/10/23 4:26 PM, Brent Putman wrote:


On 8/10/23 1:15 PM, Sean Mullan wrote:
Yes, sorry I guess I wasn't clear enough. This is a Santuario issue. I 
can probably post a PR in the next few days that addresses this.To me 
this is the best solution if you want to provide a solution that works 
both with BC and the JDK. 



Ok, thanks! Yes, I agree that it's the best solution, and should be 
transparent to users of the library.



Even if we did add direct support to the JDK for the PSS w/o param 
algorithm URIs as defined in RFC 9231, it would initially only be 
supported in the next version of JDK (22), and would need 
justification, etc in order to be backported to earlier releases.



Yes, and even if it was in 22, it wouldn't help us much (OpenSAML/Shib) 
as we baseline only on LTS releases and so the release of our new 5.0 in 
the next few weeks will be on 17.



Also for some reason, I thought you were a Santuario Committer, so 
sorry if I implied you could do the work. :)



Ah, understood.  Yeah, only Scott from our team is currently a Santuario 
committer.


--Brent

Re: [VOTE] - Release Apache Santuario - XML Security for Java 4.0.0-M1

[Sean Mullan]

+1

--Sean

On 8/28/23 9:12 AM, Colm O hEigeartaigh wrote:

This is a vote to release Apache Santuario - XML Security for Java
4.0.0-M1. It is a milestone release and not meant for production.

The main new features of the release come from this PR
https://github.com/apache/santuario-xml-security-java/pull/192
  - Java 11 requirement
  - Removing SLF4J and using System.Logger
  - AutoCloseable for several types

Git tag: 
https://github.com/apache/santuario-xml-security-java/releases/tag/xmlsec-4.0.0-M1
Artifacts: 
https://repository.apache.org/content/repositories/orgapachesantuario-1043/

+1 from me.

Colm.

Re: [VOTE] - Release Apache Santuario - XML Security for Java 2.2.5

[Sean Mullan]

+1

--Sean

On 8/16/23 2:50 AM, Colm O hEigeartaigh wrote:

Hi Scott,

You can review all changes between 2.2.5 and 2.2.4 here:
https://github.com/apache/santuario-xml-security-java/compare/xmlsec-2.2.4...xmlsec-2.2.5

Essentially it's just Xalan, BouncyCastle, Woodstox and Jetty upgrades.

Colm.

On Tue, Aug 15, 2023 at 3:34 PM Cantor, Scott  wrote:



Issues fixed:


This was empty: could you update Jira to capture what's been changed?

All I saw in git seemed to be updating BC (which I'm aware had some CVEs, so 
that might be what you meant).

-- Scott

Re: Issue with support of RSASSA-PSS algorithms with implicit params in Oracle Java 17

[Sean Mullan]

Hi Brent,

On 8/8/23 7:39 PM, Brent Putman wrote:


Hi Sean,


On 8/8/23 4:05 PM, Sean Mullan wrote:


As mentioned before, you can implement this in the Santuario layer by 
instantiating the algorithms as "RSASSA-PSS" and passing in an 
appropriate PSSParameterSpec with the default values as specified by 
RFC 6931. I recommend this technique as it should work for either BC 
or JDK providers that support the RSASSA-PSS algorithm and the 
particular parameters of those algorithms. It isn't a lot of code to 
do that.



Sure, I understood what you suggested before wrt to usage of the JDK's 
API.  But as I said before, I can not personally do this, as I am not 
orchestrating the Java JCA calls here - it's Santuario.  We (the 
OpenSAML/Shibboleth project) are mere users of the Santuario library.


Santuario would have to update its methodology as you describe, and do 
new releases. At a minimum, JCEMapper would have to update the 
URI->JCA algorithm name mappings (trivial) and SignatureBaseRSA would 
have to start supplying a PSSParameterSpec with the implicit values in 
the nested subclasses that support those URIs (less trivial, but 
probably easy). (And I imagine also need to update the corresponding 
classes used in the JSR 105 impl, but I'm not familiar with that.)


So unless/until that happens, users of existing Santuario versions 
will be limited to using BC, which (possibly erroneously) uses the 
withRSAandMGF1 algorithm names.


So unlike what I thought when I started this thread, it appears this 
IS now a Santuario issue. Are there opinions about whether and when 
Santuario should be updated to this new methodology? It seems it ought 
to be a backward compatible change for any other provider (like BC) 
that supports "RSASSA-PSS", but that assumption needs to be validated.


Yes, sorry I guess I wasn't clear enough. This is a Santuario issue. I 
can probably post a PR in the next few days that addresses this. To me 
this is the best solution if you want to provide a solution that works 
both with BC and the JDK. Even if we did add direct support to the JDK 
for the PSS w/o param algorithm URIs as defined in RFC 9231, it would 
initially only be supported in the next version of JDK (22), and would 
need justification, etc in order to be backported to earlier releases. 
So best to have a solution that works across all JDK versions that 
already have RSASSA-PSS support.


Also for some reason, I thought you were a Santuario Committer, so sorry 
if I implied you could do the work. :)






Further discussion needs to be made in the JDK area as to whether 
algorithms like "SHA256withRSAandMGF1" are standard and what that 
means; ex - it isn't clear that it is for RSASSA-PSS and not RSA. RFC 
6931 is at a higher layer than the RSA specifications, so it is not 
the standard we necessarily adhere to at the JCE layer. Thus, more 
discussion on that is needed.



Ok, understood. I was guided by what was in the JDK docs and the 
existing impls, but you're saying some of this may simply be wrong.


I'll point out in passing that RFC 9231 clearly (and as an RFC I would 
think canonically?) defines the corresponding algorithm URIs in 
question as RSASSA-PSS without Parameters 
<https://www.rfc-editor.org/rfc/rfc9231#name-rsassa-pss-without-paramete> 
and they do not contain "SSA" or "PSS" or similar in the trailing 
parts. In fact they look much like the JCA algorithm names in terms of 
the sub-parts they contain, e.g.  "#sha256-rsa-MGF1" vs  
"SHA256withRSAandMGF1".


I don't know if the RFC URIs were modeled after the (now retracted) 
JCA names (or vice versa) - the RFC isn't Java-specific obviously - 
but at least some people across different projects/efforts apparently 
thought they were representing the same thing.  Just an observation.



Sorry, I don't know the history of RFC 9231 there enough to comment.

--Sean


Again, thanks for taking the time to look into this. Much appreciated.

--Brent

Re: Issue with support of RSASSA-PSS algorithms with implicit params in Oracle Java 17

[Sean Mullan]

Hi Brent,

The JDK docs for the SunRsaSign provider are incorrect, and we don't 
support those algorithm names. A bug has been filed to correct that: 
https://bugs.openjdk.org/browse/JDK-8313797


I am still looking into your other questions, will get back to you when 
I have more info.


--Sean

On 8/4/23 3:26 PM, Brent Putman wrote:

Ok, great, thanks for looking into it!

--Brent


On 8/4/23 3:12 PM, Sean Mullan wrote:

Yeah, I get it, I need to chat with some folks here first that worked
on this before I can give you a better response.

--Sean

On 8/4/23 2:55 PM, Brent Putman wrote:

Hi Sean,

I understood that was how to do the RSA PSS algorithm with explicit
parameters, which in Java is done with a PSSParameterSpec.  For XML
Signature that corresponds with this RFC URI:

http://www.w3.org/2007/05/xmldsig-more#rsa-pss

I'm instead talking here about the ones that have implicit/defaulted
parameters, where the MGF, salt length and trailer field are
defaulted (and the digest method is carried as usual in the
algorithm ID).  Such as this one:

http://www.w3.org/2007/05/xmldsig-more#sha256-rsa-MGF1

So it's not my understanding that in Java one passes
PSSParameterSpec with those, such as "SHA256withRSAandMGF1". All
params are defaulted with those - that's the whole purpose of those
variants. (And it would be problematic I think to pass the param
spec with those, because you could specify in the params say SHA-512
as the digest method, which could be inconsistent with the JCA
algorithm ID, as the one above.)

But most importantly, I'm not doing any of this.  It's Santuario
that specifies how the actual Java cryptography works, and for those
URIs it uses the Java algorithm ID variants in question, not
"RSASSA-PSS". When I attempt the #sha256-rsa-MGF1 URI, it throws
under Java 17 with NoSuchAlgorithm. I am merely observing from
additional testing that those algorithm IDs are in fact documented
in Java 17 for SunRsaSign, but yet do not actually work.

The code in Santuario's JCEMapper and SignatureBaseRSA agrees with
this understanding.  Running with BC loaded works fine also, so they
have the same understanding.

Thanks
Brent


On 8/4/23 2:13 PM, Sean Mullan wrote:

Hi Brent,

You need to pass the MGF and other parameters in a PSSParameterSpec
to the Signature algorithm, like so:

Signature sig = Signature.getInstance("RSASSA-PSS", "SunRsaSign")
sig.setParameter(new PSSParameterSpec("SHA-256", "MGF1",
MGF1ParameterSpec.SHA256, 32, PSSParameterSpec.TRAILER_FIELD_BC));

I think the JDK docs could be improved to clarify this, so I'll
file a bug to have this fixed.

--Sean

On 8/4/23 12:27 AM, Brent Putman wrote:

This is not a Santuario issue per se, but it's sort of related and
there are people on the list like Colm and Sean who might have
info...

In OpenSAML was working on adding support for the RSASSA-PSS
algorithms (only those with implicit params) from RFC 9231:

https://shibboleth.atlassian.net/browse/OSJ-372

The TL/DR is:  The docs for the SunRsaSign provider in at least
Java 17 claim to support algorithm IDs like
"SHA256withRSAandMGF1". But in practice they all throw
NoSuchAlgorithmException.

Iterating the providers in the JDK and the algorithm IDs supported
confirms that they are not listed.

Those are the algorithm IDs expected by Santuario in JCEMapper for
the corresponding URIs from RFC 9231, such as
http://www.w3.org/2007/05/xmldsig-more#sha256-rsa-MGF1.

This seems like a huge discrepancy between the JDK docs and the
JDK behavior.  Anyone know anything?  Unless I'm missing
something, seems like a possible bug in the JDK, at least with
respect to the docs.

(Such algorithm IDs are supported and do work when using Bouncy
Castle as a security provider.)

Thanks,
Brent

Re: Issue with support of RSASSA-PSS algorithms with implicit params in Oracle Java 17

[Sean Mullan]

Yeah, I get it, I need to chat with some folks here first that worked on 
this before I can give you a better response.


--Sean

On 8/4/23 2:55 PM, Brent Putman wrote:

Hi Sean,

I understood that was how to do the RSA PSS algorithm with explicit 
parameters, which in Java is done with a PSSParameterSpec.  For XML 
Signature that corresponds with this RFC URI:


http://www.w3.org/2007/05/xmldsig-more#rsa-pss

I'm instead talking here about the ones that have implicit/defaulted 
parameters, where the MGF, salt length and trailer field are defaulted 
(and the digest method is carried as usual in the algorithm ID).  Such 
as this one:


http://www.w3.org/2007/05/xmldsig-more#sha256-rsa-MGF1

So it's not my understanding that in Java one passes PSSParameterSpec 
with those, such as "SHA256withRSAandMGF1".  All params are defaulted 
with those - that's the whole purpose of those variants. (And it would 
be problematic I think to pass the param spec with those, because you 
could specify in the params say SHA-512 as the digest method, which 
could be inconsistent with the JCA algorithm ID, as the one above.)


But most importantly, I'm not doing any of this.  It's Santuario that 
specifies how the actual Java cryptography works, and for those URIs it 
uses the Java algorithm ID variants in question, not "RSASSA-PSS". When 
I attempt the #sha256-rsa-MGF1 URI, it throws under Java 17 with 
NoSuchAlgorithm. I am merely observing from additional testing that 
those algorithm IDs are in fact documented in Java 17 for SunRsaSign, 
but yet do not actually work.


The code in Santuario's JCEMapper and SignatureBaseRSA agrees with this 
understanding.  Running with BC loaded works fine also, so they have the 
same understanding.


Thanks
Brent


On 8/4/23 2:13 PM, Sean Mullan wrote:

Hi Brent,

You need to pass the MGF and other parameters in a PSSParameterSpec to 
the Signature algorithm, like so:


Signature sig = Signature.getInstance("RSASSA-PSS", "SunRsaSign")
sig.setParameter(new PSSParameterSpec("SHA-256", "MGF1", 
MGF1ParameterSpec.SHA256, 32, PSSParameterSpec.TRAILER_FIELD_BC));


I think the JDK docs could be improved to clarify this, so I'll file a 
bug to have this fixed.


--Sean

On 8/4/23 12:27 AM, Brent Putman wrote:
This is not a Santuario issue per se, but it's sort of related and 
there are people on the list like Colm and Sean who might have info...


In OpenSAML was working on adding support for the RSASSA-PSS 
algorithms (only those with implicit params) from RFC 9231:


https://shibboleth.atlassian.net/browse/OSJ-372

The TL/DR is:  The docs for the SunRsaSign provider in at least Java 
17 claim to support algorithm IDs like "SHA256withRSAandMGF1". But in 
practice they all throw NoSuchAlgorithmException.


Iterating the providers in the JDK and the algorithm IDs supported 
confirms that they are not listed.


Those are the algorithm IDs expected by Santuario in JCEMapper for 
the corresponding URIs from RFC 9231, such as 
http://www.w3.org/2007/05/xmldsig-more#sha256-rsa-MGF1.


This seems like a huge discrepancy between the JDK docs and the JDK 
behavior.  Anyone know anything?  Unless I'm missing something, seems 
like a possible bug in the JDK, at least with respect to the docs.


(Such algorithm IDs are supported and do work when using Bouncy 
Castle as a security provider.)


Thanks,
Brent

Re: Issue with support of RSASSA-PSS algorithms with implicit params in Oracle Java 17

[Sean Mullan]

Hi Brent,

You need to pass the MGF and other parameters in a PSSParameterSpec to 
the Signature algorithm, like so:


Signature sig = Signature.getInstance("RSASSA-PSS", "SunRsaSign")
sig.setParameter(new PSSParameterSpec("SHA-256", "MGF1", 
MGF1ParameterSpec.SHA256, 32, PSSParameterSpec.TRAILER_FIELD_BC));


I think the JDK docs could be improved to clarify this, so I'll file a 
bug to have this fixed.


--Sean

On 8/4/23 12:27 AM, Brent Putman wrote:
This is not a Santuario issue per se, but it's sort of related and there 
are people on the list like Colm and Sean who might have info...


In OpenSAML was working on adding support for the RSASSA-PSS algorithms 
(only those with implicit params) from RFC 9231:


https://shibboleth.atlassian.net/browse/OSJ-372

The TL/DR is:  The docs for the SunRsaSign provider in at least Java 17 
claim to support algorithm IDs like "SHA256withRSAandMGF1". But in 
practice they all throw NoSuchAlgorithmException.


Iterating the providers in the JDK and the algorithm IDs supported 
confirms that they are not listed.


Those are the algorithm IDs expected by Santuario in JCEMapper for the 
corresponding URIs from RFC 9231, such as 
http://www.w3.org/2007/05/xmldsig-more#sha256-rsa-MGF1.


This seems like a huge discrepancy between the JDK docs and the JDK 
behavior.  Anyone know anything?  Unless I'm missing something, seems 
like a possible bug in the JDK, at least with respect to the docs.


(Such algorithm IDs are supported and do work when using Bouncy Castle 
as a security provider.)


Thanks,
Brent

Re: [VOTE] - Release Apache Santuario - XML Security for Java 3.0.2 and 2.3.3

[Sean Mullan]

+1.

--Sean

On 3/27/23 7:02 AM, Colm O hEigeartaigh wrote:

This is a vote to release Apache Santuario - XML Security for Java
3.0.2 and 2.3.3.

3.0.2:
  - Issues fixed:
https://issues.apache.org/jira/projects/SANTUARIO/versions/12352305
  - Artifacts: 
https://repository.apache.org/content/repositories/orgapachesantuario-1039/
  - Git tag: 
https://github.com/apache/santuario-xml-security-java/releases/tag/xmlsec-3.0.2

2.3.3:
  - Issues fixed:
https://issues.apache.org/jira/projects/SANTUARIO/versions/12352306
  - Artifacts: 
https://repository.apache.org/content/repositories/orgapachesantuario-1040/
  - Git tag: 
https://github.com/apache/santuario-xml-security-java/releases/tag/xmlsec-2.3.3

+1 from me.

Colm.-

Re: Remove Xalan and here() function support

[Sean Mullan]

Colm,

Should SANTUARIO-583 [1] also be closed or marked as a duplicate of 
SANTUARIO-593 [2]?


--Sean

[1] https://issues.apache.org/jira/browse/SANTUARIO-583
[2] https://issues.apache.org/jira/browse/SANTUARIO-593

On 8/30/22 8:03 AM, Sean Mullan wrote:

I support this proposal. I think the "here" function was never specified
correctly anyway as I have been told a while ago by an XPath expert that
it should have been defined in a namespace in order to be properly
processed as an XPath extension.

--Sean

On 8/30/22 4:04 AM, Colm O hEigeartaigh wrote:

Hi all,

I'd like to propose removing Xalan as an (optional) dependency and
also support as a result for the here() function defined in the spec:
https://www.w3.org/TR/xmldsig-core1/#function-here

To re-cap, currently for XPath we use the default Java implementation.
Xalan is an optional dependency, meaning that someone has the ability
to add Xalan to the classpath, in which case Xalan will be used
instead. For Xalan, we do some hacking to support the here() function:

https://github.com/apache/santuario-xml-security-java/blob/12466b78dcac65e6442d50571c1e6d5dd7748b84/src/main/java/org/apache/xml/security/utils/XalanXPathAPI.java#L162

This is a little-used part of the spec, that causes a few tests to
fail if we remove it. From previous conversations it doesn't seem
easily possible to support this function using the JDK implementation.

A recent serious security issue was published for Xalan which makes it
clear the project is being retired -
https://nvd.nist.gov/vuln/detail/CVE-2022-34169. I think it's time
that we removed it, even though it's obviously not ideal that we are
then not fully implementing the spec. We can make it pluggable so that
someone can add the code back in if they want to use it.

Thoughts?

Colm.

Re: Remove Xalan and here() function support

[Sean Mullan]

I support this proposal. I think the "here" function was never specified 
correctly anyway as I have been told a while ago by an XPath expert that 
it should have been defined in a namespace in order to be properly 
processed as an XPath extension.


--Sean

On 8/30/22 4:04 AM, Colm O hEigeartaigh wrote:

Hi all,

I'd like to propose removing Xalan as an (optional) dependency and
also support as a result for the here() function defined in the spec:
https://www.w3.org/TR/xmldsig-core1/#function-here

To re-cap, currently for XPath we use the default Java implementation.
Xalan is an optional dependency, meaning that someone has the ability
to add Xalan to the classpath, in which case Xalan will be used
instead. For Xalan, we do some hacking to support the here() function:

https://github.com/apache/santuario-xml-security-java/blob/12466b78dcac65e6442d50571c1e6d5dd7748b84/src/main/java/org/apache/xml/security/utils/XalanXPathAPI.java#L162

This is a little-used part of the spec, that causes a few tests to
fail if we remove it. From previous conversations it doesn't seem
easily possible to support this function using the JDK implementation.

A recent serious security issue was published for Xalan which makes it
clear the project is being retired -
https://nvd.nist.gov/vuln/detail/CVE-2022-34169. I think it's time
that we removed it, even though it's obviously not ideal that we are
then not fully implementing the spec. We can make it pluggable so that
someone can add the code back in if they want to use it.

Thoughts?

Colm.

Re: [VOTE] - Release Apache Santuario - XML Security for Java 2.2.4

[Sean Mullan]

+1

--Sean

On 4/29/22 2:25 AM, Colm O hEigeartaigh wrote:

This is a vote to release Apache Sanutario - XML Security for Java 2.2.4.

Re: [VOTE] - Release Apache Santuario - XML Security for Java 2.1.8

[Sean Mullan]

+1

--Sean

On 4/29/22 2:46 AM, Colm O hEigeartaigh wrote:

This is a vote to release Apache Santuario - XML Security for Java
2.1.8. This is the last planned release on this branch.

Re: [VOTE] - Release Apache Santuario - XML Security for Java 3.0.0

[Sean Mullan]

On 4/28/22 3:17 AM, Colm O hEigeartaigh wrote:

This is a vote to release Apache Santuario - XML Security for Java
3.0.0. This is a new major release which has switched to use the
Jakarta namespace.


+1.

--Sean

Re: [VOTE] - Release Apache Santuario - XML Security for Java 2.3.1

[Sean Mullan]

On 4/28/22 4:18 AM, Colm O hEigeartaigh wrote:

This is a vote to release Apache Santuario - XML Security for Java 2.3.1.


+1.

--Sean

Re: Proposed release of xml-security-c 2.0.4 - Call for Vote

[Sean Mullan]

+1.

--Sean

On 11/1/21 8:25 AM, Cantor, Scott wrote:

I have posted a release candidate for 2.0.4 [1] to correct a regression on 
OpenSSL 1.0.0 and older from the DSA bug fix included in the release last week. 
The only change apart from the versioning bits is [2], inlining a small 
function introduced in OpenSSL 1.1.

Re: [VOTE] - Release Apache Santuario - XML Security for Java 2.3.0

[Sean Mullan]

+1

--Sean

On 10/25/21 6:52 AM, Colm O hEigeartaigh wrote:

This is a vote to release Apache Santuario - XML Security for Java
2.3.0. This is a major new release of the library. Some of the
significant changes include:

Re: [VOTE] - Release Apache Santuario - XML Security for Java 2.1.7

[Sean Mullan]

On 9/10/21 9:38 AM, Colm O hEigeartaigh wrote:

This is a vote to release Apache Santuario - XML Security for Java 2.1.7


+1.

--Sean

Re: [VOTE] - Release Apache Santuario - XML Security for Java 2.2.3

[Sean Mullan]

On 9/10/21 9:37 AM, Colm O hEigeartaigh wrote:

This is a vote to release Apache Santuario - XML Security for Java 2.2.3.


+1

--Sean

Re: [VOTE] - Release Apache Santuario - XML Security for Java 2.2.2

[Sean Mullan]

+1.

--Sean

On 4/30/21 5:18 AM, Colm O hEigeartaigh wrote:

This is a vote to release Apache Santuario - XML Security for Java 2.2.2.

Artifacts: 
https://urldefense.com/v3/__https://repository.apache.org/content/repositories/orgapachesantuario-1029/__;!!GqivPVa7Brio!N_HCGEhBDnSK3qX9pZR4RVQj3hJjdlOVKvjgmUELGtee2WWHIfi42RogVtQjf30K$
Git tag: 
https://urldefense.com/v3/__https://github.com/apache/santuario-xml-security-java/releases/tag/xmlsec-2.2.2__;!!GqivPVa7Brio!N_HCGEhBDnSK3qX9pZR4RVQj3hJjdlOVKvjgmUELGtee2WWHIfi42RogVtNR38Ec$
Issues fixed: 
https://urldefense.com/v3/__https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311231=12349491__;!!GqivPVa7Brio!N_HCGEhBDnSK3qX9pZR4RVQj3hJjdlOVKvjgmUELGtee2WWHIfi42RogVo3QRDxq$

+1 from me.

Colm.

Re: [VOTE] - Release Apache Santuario - XML Security for Java 2.2.0

[Sean Mullan]

+1

--Sean

On 5/26/20 2:45 AM, Colm O hEigeartaigh wrote:
This is a vote to release Apache Santuario - XML Security for Java 
2.2.0. This is a new major release with the following features:


  * Added support for RSASSA-PSS with Parameters
  * Extensive refactoring and code simplification
  * JDK14 officially supported
  * Ability to set a security provider when using 
org.apache.xml.security.signature.XMLSignature
  * Added support for customizing how to parse a Inputstream into a DOM 
Document


Issues fixed: 
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311231=12344983
Git tag: 
https://github.com/apache/santuario-xml-security-java/tree/xmlsec-2.2.0
Artifacts: 
https://repository.apache.org/content/repositories/orgapachesantuario-1027/


+1 from me.

Colm.

Re: CRLF change in Java 8 patch

[Sean Mullan]

On 10/17/19 11:49 AM, Cantor, Scott wrote:

To be honest, it *is* possible that the Java 8 change we observed could have 
been that they suddenly moved it from shadowing xmlsec 2.0.x to 2.1.x, but I 
think it's more plausible that just the Base64 class changed (or they revved a 
2.0.x release) than that they would have moved a whole minor xmlsec version in 
the JDK patch.


That came in as part of the upgrade to 2.1.3: 
https://bugs.openjdk.java.net/browse/JDK-8230710


It has also been pushed to OpenJDK 11.0.5: 
https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/caa57e349340


Not yet to OpenJDK 8 it seems. You could ask about any plans to do that 
on the OpenJDK 8 dev list: jdk8u-...@openjdk.java.net


--Sean



-- Scott

On 10/17/19, 10:22 AM, "Colm O hEigeartaigh"  wrote:

Hi Scott,

Are you referring to the fix that was made for 2.1.2?
https://issues.apache.org/jira/browse/SANTUARIO-482

Re: xml-security-c 2.0.2 (call for vote)

[Sean Mullan]

+1

--Sean

On 10/30/18 4:30 PM, Cantor, Scott wrote:

I have a couple of small patches to release to address another bug [1] and I've 
had a colleague beating on the code to try and find any other similar problems 
and we haven't found anything else to this point, so I'd like to get this patch 
set released as V2.0.2.

I've uploaded a signed artifact built from svn revision 1843566 at [2].

I'd like to get this out by next week latest if possible.

This is my +1

Thanks,
-- Scott

[1] https://issues.apache.org/jira/browse/SANTUARIO-496
[2] https://dist.apache.org/repos/dist/dev/santuario/c-library/

Re: Call for vote on xml-security-c 2.0.1

[Sean Mullan]

+1

--Sean

On 8/2/18 9:32 AM, Cantor, Scott wrote:

I'd like to get a couple of votes by end of week if possible, today preferably.

The changes are these two commits, just adding null string and node checks.

http://svn.apache.org/viewvc?view=revision=1837236
http://svn.apache.org/viewvc?view=revision=1837240

I'll be digging into it further once the known issue is patched to identify 
other possible trouble spots but the ETA on that is unknown.

-- Scott


-Original Message-
From: Cantor, Scott
Sent: Wednesday, August 1, 2018 10:23 AM
To: santuario-...@apache.org
Subject: Call for vote on xml-security-c 2.0.1

A patch for a reported bug [1] has been prepared and I've uploaded RC2
source artifacts [2] for approval based on svn revision 1837241. Only a couple
of source files are impacted, adding some null checks. I found an additional
area of the code to address while testing, necessitating the RC2 designation.

I'd like to get this out promptly please.

This is my +1.

-- Scott

[1] https://issues.apache.org/jira/browse/SANTUARIO-491
[2] https://dist.apache.org/repos/dist/dev/santuario/c-library/

Re: [VOTE] - Release Apache Santuario - XML Security for Java 2.1.2 (take III)

[Sean Mullan]

+1.

--Sean

On 6/8/18 12:05 PM, Colm O hEigeartaigh wrote:
This is a vote (take III) to release Apache Santuario - XML Security for 
Java 2.1.2.


Issues fixed:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311231=12342674

SVN tag:

http://svn.apache.org/viewvc/santuario/xml-security-java/tags/xmlsec-2.1.2/

Artifacts:

https://repository.apache.org/content/repositories/orgapachesantuario-1022/

+1 from me.

Colm.


--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: [VOTE] - Release Apache Santuario - XML Security for Java 2.0.10

[Sean Mullan]

+1

--Sean

On 1/22/18 12:45 PM, Colm O hEigeartaigh wrote:

This is a vote to release Apache Santuario - XML Security for Java 2.0.10.

Issues fixed:

https://issues.apache.org/jira/projects/SANTUARIO/versions/12341414

SVN tag:

https://svn.apache.org/repos/asf/santuario/xml-security-java/tags/xmlsec-2.0.10/

Maven artifacts:

https://repository.apache.org/content/repositories/orgapachesantuario-1017/

+1 from me.

Colm.


--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: [VOTE] - Release Apache Santuario - XML Security for Java 2.1.0

[Sean Mullan]

+1

--Sean

On 8/14/17 6:23 AM, Colm O hEigeartaigh wrote:
This is a vote to release Apache Santuario - XML Security for Java 
2.1.0. The main features of this new major release are as follows:


a) JDK-9 support. All tests pass with the latest JDK 9 candidate.
b) JDK 8 is the minimum supported Java version.
c) The code has switched to use the Java Base64 implementation. The old 
Santuario Base64 implementation is now deprecated, but still included 
for backwards compatibility reasons.


SVN tag:

https://svn.apache.org/repos/asf/santuario/xml-security-java/tags/xmlsec-2.1.0/

Artifacts:

https://repository.apache.org/content/repositories/orgapachesantuario-1014/

Source release:

https://repository.apache.org/content/repositories/orgapachesantuario-1014/org/apache/santuario/xmlsec/2.1.0/xmlsec-2.1.0-source-release.zip

+1 from me.

Colm.


--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: [VOTE] - Release Apache Santuario - XML Security for Java 2.0.9

[Sean Mullan]

+1

--Sean

On 8/14/17 7:10 AM, Colm O hEigeartaigh wrote:
This is a vote to release Apache Santuario - XML Security for Java 
2.0.9. This is a minor bug fix release - perhaps the most significant 
fix is to allow setting default algorithms without invoking the 
SecurityManager, and so to allow Santuario to run in google app engine.


SVN tag:

https://svn.apache.org/repos/asf/santuario/xml-security-java/tags/xmlsec-2.0.9/

Artifacts:

https://repository.apache.org/content/repositories/orgapachesantuario-1015/

Source dist:

https://repository.apache.org/content/repositories/orgapachesantuario-1015/org/apache/santuario/xmlsec/2.0.9/xmlsec-2.0.9-source-release.zip

+1 from me.

Colm.


--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: [VOTE] - Release Apache Santuario - XML Security for Java 2.0.8

[Sean Mullan]

+1

--Sean

On 12/1/16 8:39 AM, Colm O hEigeartaigh wrote:

This is a vote to release Apache Santuario - XML Security for Java 2.0.8.

Issues fixed:

https://issues.apache.org/jira/browse/SANTUARIO/fixforversion/12336742

Maven artifacts:

https://repository.apache.org/content/repositories/orgapachesantuario-1013/

SVN tag:

https://svn.apache.org/repos/asf/santuario/xml-security-java/tags/xmlsec-2.0.8/

+1 from me.

Colm.


--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: [VOTE] - Release Apache Santuario - XML Security for Java 2.0.7

[Sean Mullan]

+1.

--Sean

On 06/13/2016 12:59 PM, Colm O hEigeartaigh wrote:

This is a vote to release Apache Santuario - XML Security for Java 2.0.7.

Issues fixed:
https://issues.apache.org/jira/browse/SANTUARIO/fixforversion/12334297

Artifacts:
https://repository.apache.org/content/repositories/orgapachesantuario-1012/

SVN tag:
https://svn.apache.org/repos/asf/santuario/xml-security-java/tags/xmlsec-2.0.7/

+1 from me.

Colm.


--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: X509Digest

[Sean Mullan]

This is not going to work. You are mixing 2 different APIs together. To 
understand this better, I need to explain a bit more.


The original Apache Java XML Signature library consisted of APIs in the 
org.apache.xml.security namespace.


Later, JSR 105 based the implementation of the standard Java XML 
Signature API (javax.xml.crypto and subpackages) on the Apache XML 
Signature Library. However, only a subset of the implementation could be 
used since the underlying Apache APIs were too different to be 
retrofitted and maintain compatibility at the same time.


Since there was already a large base of users using the original Apache 
XML Signature APIs, we could not just remove them, so we decided to 
support both usages, i.e. 1) via the standard Java API, and 2) via the 
Apache API.


So, you can't do what you are trying to do below. You need to use either 
the standard Java API OR the Apache API but not both.


You should be able to pass in a DOMStructure object that represents an 
X509Digest element. Ideally though, the JSR 105 API should be enhanced 
to add a new X509Digest class. I'll file an RFE for that.


HTH,
Sean

On 02/16/2016 05:15 PM, Pellerin, Clement wrote:

I'm trying to create a signature programmatically in Santuario 2.0.6
I need to add the new element X509Digest defined by XML DSig 1.1
Unfortunately, there is no junit for this usage.

When I run this code:
   List x509Content = new ArrayList();
   XMLX509Digest certDigest = new XMLX509Digest(domDocument, signerCert, 
certDigestUri);
   x509Content.add(certDigest);
   X509Data x509Data = keyInfoFactory.newX509Data(x509Content);

I'm getting the error:
   ClassCastException: content[0] is not a valid X509Data type

Indeed, the constructor of DOMX509Data does not accept an XMLX509Digest
as part of the content list. In particular, XMLX509Digest is not an
XMLStructure.

I noticed XMLX509Digest is tagged by the XMLX509DataContent interface,
but that interface is not used by DOMX509Data, surprisingly.


As a side note, I looked for a factory method in DOMKeyInfoFactory
but I could not find one to create an X509Digest.
There are factory methods in org.apache.xml.security.keys.content.X509Data
which is unrelated to javax.xml.crypto.dsig.keyinfo.X509Data
so I'm confused.

Re: [VOTE] - Release Apache Santuario - XML Security for Java 2.0.6

[Sean Mullan]

+1

--Sean

On 12/04/2015 07:37 AM, Colm O hEigeartaigh wrote:

This is a vote to release Apache Santuario - XML Security for Java 2.0.6.

Issues fixed:

https://issues.apache.org/jira/browse/SANTUARIO/fixforversion/12333015

Maven artifacts:

https://repository.apache.org/content/repositories/orgapachesantuario-1010/

SVN tag:

https://svn.apache.org/repos/asf/santuario/xml-security-java/tags/xmlsec-2.0.6/

+1 from me.

Colm.


--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: EdDSA Ed25519/Ed448 for XML Digital Signatures

[Sean Mullan]

On 12/02/2015 03:43 PM, Simon Josefsson wrote:

On 12/2/15, 9:29 AM, "Simon Josefsson"  wrote:


Hi.  I have prepared a writeup on how to add the EdDSA Ed25519/Ed448
public-key digital signature algorithm to XMLDSIG.

https://mailarchive.ietf.org/arch/msg/curdle/Ylertitv43TdDrcm4ufh2LxdBjM

Are you interested in implementing this?  If so, your feedback on the
description is appreciated.  If there is interest among XMLDSIG
implementers, I would turn this into a proper IETF draft.


Hi Simon,

Speaking as the C++ maintainer, it's pretty much dependent on OpenSSL
support (and my ability to figure out how to make use of it without
screwing it up, given that OpenSSL is largely undocumented).


Hi.  Thanks.  I'm sure people are working on it, but I opened an issue
to track this: https://github.com/openssl/openssl/issues/487


Speaking as a consumer of the Java code, does Java actually support
this algorithm? I didn't see any sign it did. I don't think there's
any actual crypto in the current library, it's JCE-reliant. Colm can
correct me.


How would one go about specifying support for a new algorithm like
EdDSA in Java?  I've seen that people have been thinking about adding
it to Bouncycastle, but I assume you would really want to have it be
part of JCE.


We typically don't include an implementation of a new crypto algorithm 
in the JDK unless it is a standard and has gained enough industry 
traction or support from the community to justify inclusion.


Unfortunately, I'm not familiar with the EdDSA algorithm so don't really 
have much more to say on your proposal.


--Sean

Re: Release 2.0.6?

[Sean Mullan]

On 11/30/2015 08:16 AM, Colm O hEigeartaigh wrote:

We have a few issues fixed now for 2.0.6:

https://issues.apache.org/jira/browse/SANTUARIO-430?jql=project%20%3D%20SANTUARIO%20AND%20fixVersion%20%3D%20%22Java%202.0.6%22%20AND%20status%20%3D%20Resolved%20ORDER%20BY%20priority%20DESC

Is there anything else outstanding or shall I go ahead and call a vote?


Nothing more ready from me at this time.

--Sean

Re: [VOTE] - Release Apache Santuario - XML Security for Java 2.0.5

[Sean Mullan]

+1.

--Sean

On 07/10/2015 11:25 AM, Colm O hEigeartaigh wrote:

This is a vote to release Apache Santuario - XML Security for Java 2.0.5.

Artifacts:

https://repository.apache.org/content/repositories/orgapachesantuario-1009/

SVN tag:

https://svn.apache.org/repos/asf/santuario/xml-security-java/tags/xmlsec-2.0.5/

Issues fixed:

https://issues.apache.org/jira/browse/SANTUARIO/fixforversion/12332067/

+1 from me.

Colm.

--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: [VOTE] - Release Apache Santuario - XML Security for Java 2.0.4

[Sean Mullan]

+1

--Sean

On 04/15/2015 11:06 AM, Colm O hEigeartaigh wrote:

This is a vote to release Apache Santuario - XML Security for Java 2.0.4.

Issues fixed:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311231version=12329273

Maven artifacts:
https://repository.apache.org/content/repositories/orgapachesantuario-1008/

SVN tag:
https://svn.apache.org/repos/asf/santuario/xml-security-java/tags/xmlsec-2.0.4/

Here is my +1.

Colm.


--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: Santuario xml-security-c 1.7.3 release candidate posted, call for vote

[Sean Mullan]

+1 from me.

--Sean

On 03/13/2015 11:31 AM, Cantor, Scott wrote:

On 3/10/15, 2:12 PM, Cantor, Scott canto...@osu.edu wrote:


I've uploaded a release candidate of the 1.7.3 patch release [1] for the vote. 
There have been no changes since the beta last week and I've encountered no 
issues testing it.

This is my +1.


Just noting I still need a couple of votes for this release.

-- Scott

Re: [VOTE] - Release Apache Santuario - XML Security for Java 2.0.3

[Sean Mullan]

+1

--Sean

On 01/09/2015 10:32 AM, Colm O hEigeartaigh wrote:

This is a vote to release Apache Santuario - XML Security for Java 2.0.3.

The issues fixed are here:

https://issues.apache.org/jira/browse/SANTUARIO/fixforversion/12328679

Maven artifacts:

https://repository.apache.org/content/repositories/orgapachesantuario-1006/

SVN tag:

http://svn.apache.org/viewvc/santuario/xml-security-java/tags/xmlsec-2.0.3/

Here is my +1.

Colm.


--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: [VOTE] - Release Apache Santuario - XML Security for Java 1.5.7

[Sean Mullan]

+1

--Sean

On 06/27/2014 11:08 AM, Colm O hEigeartaigh wrote:

This is a vote to release Apache Santuario - XML Security for Java
1.5.7. The issues fixed are here:

https://issues.apache.org/jira/browse/SANTUARIO/fixforversion/12325592

The maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachesantuario-1003/

The svn tag is here:

https://svn.apache.org/repos/asf/santuario/xml-security-java/tags/xmlsec-1.5.7/

The distribution is here:

http://people.apache.org/~coheigea/stage/xmlsec/1.5.7/dist/

Here is my +1.

Colm.


--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: Defining a new SignatureMethod

[Sean Mullan]

On 06/03/2014 05:21 AM, Colm O hEigeartaigh wrote:

Hi Frank,

Would you be interested in contributing a patch to make this more
flexible? So long as it's compatible with the existing API that is...


Yes, a patch would be useful. Regarding API changes to JSR 105 
(javax.xml.crypto and subpackages), you may have noticed that there have 
never been any updates to 105 since the original JSR was finalized. This 
is partially due to the fact that it is very expensive to produce a 
maintenance release of JSR 105 which is a standalone JSR. Thus, going 
forward, we have discontinued JSR 105 as a standalone JSR and will only 
be evolving the API in Java SE. See the announcement on the JSR 105 page 
for more information (scroll down to 2014.01.14):


https://jcp.org/en/jsr/detail?id=105

What this means essentially is that API changes to JSR 105 (such as 
adapting SignatureMethod to allow pluggable implementations), will only 
be made in Java SE 9 and up. However, this does mean that we can now 
more easily add several long-standing RFEs to the API.


Thanks,
Sean



Colm.


On Fri, May 30, 2014 at 11:15 PM, Frank Cornelis i...@e-contract.be
mailto:i...@e-contract.be wrote:

Hi,


For one of my projects requiring an audit trail, I've extended the
XMLSignatureFactory with a new SignatureMethod, capable of doing
urn:ietf:rfc:3161 signatures, thus actually XML signatures where
the signature is a timestamp.

At the JCA level I was perfectly capable of defining a Timestamp
KeyStore, corresponding PrivateKey, and a Signature supporting
SHA1withRFC3161.

Unfortunately at the XML Signature level, the flexibility of the JCA
is not fully utilized. Besides TransformService and KeyInfoFactory,
you basically have to redefine the entire XMLSignatureFactory just
to introduce a new SignatureMethod. For the XML timestamp signature
creation this was rather painful, but technically possible. As
DOMSignatureMethod is package protected, I had to do a
TimestampSignatureMethod within a
org.apache.jcp.xml.dsig.__internal.dom split package construct.
After some fighting with the JBoss EAP 6 module classloading, I got
things working as expected.

Unfortunately for the XML timestamp signature verification, the
DOMXMLSignatureFactory unmarshalling is not walking over
newSignatureMethod but is completely hardcoded towards
DOMSignatureMethod.unmarshal. This method is doing a large if-else
and finally throws an exception because of the alien algorithm.

It's rather sad to see that, while JCA gives opportunities to add
sufficient flexibility to be able to extend the Java security layer,
that this is not used at its full potential.

Are there any plans to work in this area, or did I overlook a magic
feature somewhere?


Kind Regards,
Frank.




--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: XMLDsig and XML Signature API

[Sean Mullan]

On 03/20/2014 11:00 AM, M. D. wrote:

  Okay, thanks a lot for your responses! (:

So to sum things up:

1] It is not a very common usecase to have multiple certificates embedded in a 
document


I don't think that's true, since that would require the relying party to 
be able to discover a chain back to a trusted anchor or root 
certificate. I would expect a more common use case is to include the 
entire chain including the root or the first cert issued by the root. 
However, I believe there is no order implied by the certs in the 
X509Data, so you should not assume they are in the correct order.


--Sean

Re: Is still example still valid?

[Sean Mullan]

On 03/30/2013 09:57 AM, Alex O'Ree wrote:

I was looking at the sample signature validation code from the
distribution 
xml-security-1_5_3\samples\javax\xml\crypto\dsig\samples\Validate.java

I've seen other signature validation code that looks nearly identical,
except for the following snippet:

  String providerName = System.getProperty
 (jsr105Provider,
org.apache.jcp.xml.dsig.internal.dom.XMLDSigRI);
 XMLSignatureFactory fac = XMLSignatureFactory.getInstance(DOM,
 (Provider) Class.forName(providerName).newInstance());

I have a few questions.
1) Is that class still the correct one to use? The use of the
internal package name is what's throwing me off. In other examples
(outside of Santuario) it's just:
XMLSignatureFactory fac = XMLSignatureFactory.getInstance();


Yes, it is still correct, if you want to be sure you are using the JSR 
105 provider that is included with Santuario. The code above will use 
the first provider it finds.



2) Using this snippet, will Santuario resolve automatically resolve
transforms included with the signature? (assuming that the signature
originated from somewhere else and that we don't know ahead of time
what type of transform will used)


Yes, but keep in mind that this is sample code. The code does not verify 
the key used to sign the signature, which should ideally be done before 
you validate the signature and process the transforms. See 
http://www.w3.org/TR/xmldsig-bestpractices/#denial-of-service



3) From the samples in
xml-security-1_5_3\samples\org\apache\xml\security\samples\transforms,
is there a complete example of signing and validating a signature
using some kind of xpath or xslt transformation?


Look at the tests in src/test/java. There are several examples.


4) Last one, does Santuario provide of any kind certificate trust
chain building, or OCSP/CRL validation options?


No, you need to implement your own, or you can use the 
java.security.cert.CertPathValidator APIs in the JDK.


--Sean

Re: [VOTE] - Release Apache XML Security for Java 1.5.4

[Sean Mullan]

+1.

On 03/15/2013 06:39 AM, Colm O hEigeartaigh wrote:


This is a vote to release Apache XML Security for Java 1.5.4. Here are
the issues fixed:

https://issues.apache.org/jira/browse/SANTUARIO/fixforversion/12323381

Here are the Maven artifacts:

https://repository.apache.org/content/repositories/orgapachesantuario-005/

Here is the distribution:

http://people.apache.org/~coheigea/stage/xmlsec/1.5.4/dist/

Here is my +1.

Colm.


--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: Detached Signature?

[Sean Mullan]

On 8/9/12 4:41 AM, Hariprasath wrote:
 Hi,
Im trying to implement detached signature using the Java. Im not 
 able 
 to find the option for changing the type of the signature (enveloped, 
 detached 
 etc.) Can you guys point me to the right option for building detached 
 signatures?

There is no option, but there are samples in the source code (in the
samples/javax/xml/crypto/dsig/samples and
samples/org/apache/xml/security/samples/signature directories) that show you how
to create each type. This is really a property of how you structure your
signature and what data is signed by your Reference URIs. In fact, a single XML
Signature can exhibit all 3 properties (enveloped, detached and enveloping).

--Sean

Re: Supported Canonicalization methods

[Sean Mullan]

On 06/01/2012 01:28 PM, David Wall wrote:

Not sure who to ask, but is there a list of supported canonicalization
methods?


I'm not sure if it is documented anywhere, but the config.xml file in 
the source code lists all of the supported CanonicalizationMethod 
algorithms. See:


http://svn.apache.org/viewvc/santuario/xml-security-java/trunk/src/main/java/org/apache/xml/security/resource/config.xml?view=markup


How about for Java 6's XML Digital Signature code?


For Oracle JDK 6: 
http://docs.oracle.com/javase/6/docs/technotes/guides/security/SunProviders.html#XMLDSigProvider



There are only the two include/exclusive versions defined in
javax.xml.crypto.dsig CanonicalizationMethod (each with/without
comments) that are basically like:
http://www.w3.org/TR/2001/REC-xml-c14n-20010315

Is there a way to use the latest, like http://www.w3.org/TR/xml-c14n11;
or http://www.w3.org/TR/2008/REC-xml-c14n11-20080502;? I gave these a
try on Java 6 and they were not found, so not sure if I have the wrong
literals or they are not supported. Is anything supported more than
those defined in CanonicalizationMethod? I found that I could use
RSA_SHA512 SignatureMethod with
http://www.w3.org/2001/04/xmldsig-more#rsa-sha512; even though it's not
defined as a constant in there either.


Oracle's JDK 6 does support some of the stronger SHA (256, 384, 512) 
algorithms but does not support C14N 1.1. You will have to upgrade to 
JDK 7, or you can try using the latest Apache Santuario provider with 
JDK 6. (You may need to register it in your java.security file or invoke 
it using the provider name).


--Sean

Re: Problem with an XSLT transformation

[Sean Mullan]

I don't have time to debug your code, but the exception indicates that the XSLT
Transform cannot find the stylesheet element.

My guess is that the XSLT stylesheet is located in an external document than the
document that will contain the XML Signature. This is a problem. You will need
to import that element into the Document that will contain the signature so the
Transform can find it - try the DOM Document.importNode method.

--Sean

On 5/25/12 2:14 AM, Ernad Besirevic wrote:
 Ernad Besirevic ernadb at gmail.com writes:
 

 I get following 
 exception:

 javax.xml.crypto.dsig.XMLSignatureException: 
 javax.xml.crypto.dsig.TransformException: 
 com.sun.org.apache.xml.internal.security.transforms.TransformationException:
 Cannot find xslt:stylesheet in Transform
 Original Exception was 
 com.sun.org.apache.xml.internal.security.transforms.
 TransformationException:
 Cannot find xslt:stylesheet in Transform
 at org.jcp.xml.dsig.internal.dom.DOMReference.transform(Unknown Source)
 at org.jcp.xml.dsig.internal.dom.DOMReference.digest(Unknown Source)
 at org.jcp.xml.dsig.internal.dom.DOMXMLSignature.
 digestReference(Unknown Source)
 at org.jcp.xml.dsig.internal.dom.DOMXMLSignature.sign(Unknown Source)

 
 Here is the code (Sun's XML Signature API):
 
 code
 
 Document signingDocument = signRequest.getDocument();
   
 // add references
 ListReference references = 
  new ArrayListReference();
 ListTransform transforms = 
  new ArrayListTransform();
   
 XSLTTransformParameterSpec spec = 
 new XSLTTransformParameterSpec(
 getStylesheetXmlStructure() );
   
 transforms.add( fac.newTransform( Transform.XSLT, spec ) );
   
 Reference ref = fac.newReference( , 
 fac.newDigestMethod( DigestMethod.SHA1,
 null), transforms, null, null );
 references.add( ref );
   
 SignedInfo si = fac.newSignedInfo(
 fac.newCanonicalizationMethod(
CanonicalizationMethod.INCLUSIVE_WITH_COMMENTS,
 (C14NMethodParameterSpec) null),
 fac.newSignatureMethod( SignatureMethod.RSA_SHA1, 
null ),references );
 
 X509Certificate cert = (X509Certificate)
 signRequest.getCertificate();
 KeyInfoFactory kif = fac.getKeyInfoFactory();
 ListObject x509Content = new ArrayListObject();
   
 x509Content.add( cert.getSubjectX500Principal().getName() );
 x509Content.add( cert );
   
 X509Data xd = kif.newX509Data( x509Content );
 KeyInfo ki = kif.newKeyInfo( Collections.singletonList( xd ) );
 DOMSignContext dsc = new DOMSignContext(
  signRequest.getPrivateKey(),
  signingDocument.getDocumentElement() );
 XMLSignature signature = fac.newXMLSignature( si, ki );
 
 signature.sign( dsc );
 
 /code
 
 With Santuario I am not sure how to add XSLT document. 
 Here is my Santuario code:
 
 code
 Init.init();
 ElementProxy.setDefaultPrefix( Constants.SignatureSpecNS, ds );
 
 Document signedDocument = signRequest.getDocument();
 Element rootElement = signedDocument.getDocumentElement();
 XMLSignature signature = new XMLSignature( signedDocument, null,
 XMLSignature.ALGO_ID_SIGNATURE_RSA_SHA1 );
   
 rootElement.appendChild( signature.getElement() );
   
 Transforms transforms = new Transforms( signedDocument );
 
 transforms.addTransform( Transforms.TRANSFORM_ENVELOPED_SIGNATURE );
 transforms.addTransform( Transforms.TRANSFORM_C14N_WITH_COMMENTS );
 
 // only for testing purpose I added the second Transforms object
 Transforms transforms2 = new Transforms( signedDocument );
 
 transforms2.addTransform( Transforms.TRANSFORM_XSLT );
 
 //  How to add XSLT file to the transformation?
 
 signature.addDocument( , transforms, Constants.ALGO_ID_DIGEST_SHA1 );
 signature.addDocument( , transforms2 );
 
 X509Certificate certificate = signRequest.getCertificate();
 
 signature.addKeyInfo( certificate );
 signature.addKeyInfo( certificate.getPublicKey() );
 
 signature.sign( signRequest.getPrivateKey() );
   
 return signedDocument;
 /code
 
 Thanks in advance
 errno
 
 

Re: Santuario port using GenXDM - how to do secure parsing with StAX API?

[Sean Mullan]

Did you check with the StAX developers? We don't support StAX here, so I'm not 
sure.

--Sean

On 5/24/12 9:48 AM, Eric Johnson wrote:
 I apologize in advance if this seems somewhat off topic, but this 
 problem came up in the context of porting 1.5.0 of Santuario to use 
 GenXDM (a project I've had underway for some time over at 
 https://code.google.com/a/apache-extras.org/p/santuario-genxdm/)
 
 Specifically, when using Santuario in conjunction with trees not based 
 on DOM, we're currently creating those trees using the StAX API, rather 
 than SAX.
 
 Unfortunately StAX, and the implementations for which I've looked at 
 docs, doesn't seem to support the XMLConstants.FEATURE_SECURE_PROCESSING.
 
 Is it possible to configure StAX to have equivalent functionality, and 
 I've just overlooked it?
 
 Any help you might have is most welcome.
 
 -Eric.
 

Re: [VOTE] - Release Apache XML Security for Java 1.5.2

[Sean Mullan]

+1

--Sean

On 05/09/2012 06:25 AM, Colm O hEigeartaigh wrote:

This is a vote to release Apache XML Security for Java 1.5.2.

Svn tag:

https://svn.apache.org/repos/asf/santuario/xml-security-java/tags/1.5.2/

Distribution:

http://people.apache.org/~coheigea/stage/xmlsec/1.5.2/dist/

Maven artifacts:

http://people.apache.org/~coheigea/stage/xmlsec/1.5.2/maven/

Issues fixed:

https://issues.apache.org/jira/browse/SANTUARIO/fixforversion/12320048

Here is my +1.

Colm.

Re: 1.4.7 and 1.5.2 Java releases

[Sean Mullan]

Looks good to me.

--Sean

On 4/23/12 5:06 AM, Colm O hEigeartaigh wrote:
 Is there anything else anyone would like to see go into 1.4.7 and
 1.5.2? Currently there are 5 issues fixed for 1.4.7:
 
 https://issues.apache.org/jira/browse/SANTUARIO/fixforversion/12318844
 
 and 8 for 1.5.2:
 
 https://issues.apache.org/jira/browse/SANTUARIO/fixforversion/12320048
 
 I'd like to get both released in the next few weeks.
 
 Colm.
 

Re: Checkout bug

[Sean Mullan]

Ok, though the problem has been fixed on the trunk. I don't know if it 
is possible to fix it on a version that is already tagged like 1.5.1. 
I'll defer to someone with more subversion experience than I.


--Sean

On 04/11/2012 08:02 PM, George Stanchev wrote:

Hi Sean,

The exact screenshot dump is below

George

--
D:\aDev\lib\svn\asf\java\xml-security\tags\1.5.1svn export --force 
https://svn.apache.org/repos/asf/santuario/xml-security-java/tags/1.5.1/ .
A.
Acontrib
...
A
src\test\resources\org\w3c\www\interop\xmldsig11\sun\c14n10-signature-enveloping-rsa_sha384.xml
svn: E720123: Can't move 
'src\test\resources\org\w3c\www\interop\xmldsig11\sun\svn-6AD5CF0E' to 
'src\test\resources\org\w3c\www\interop\xmldsig11\sun\index.html?C=D;O=A': The 
filename, directory name, or volume label syntax is incorrect.
--



-Original Message-
From: Sean Mullan [mailto:sean.mul...@oracle.com]
Sent: Wednesday, April 11, 2012 3:10 PM
To: dev@santuario.apache.org
Cc: George Stanchev
Subject: Re: Checkout bug

On 4/10/12 9:37 PM, George Stanchev wrote:

I hit the same error. Can someone please fix it?


Hmm, that should be fixed. What svn command are you using to do the checkout?

--Sean





*From:*Pellerin, Clement [mailto:clement_pelle...@ibi.com]
*Sent:* Monday, March 26, 2012 9:24 AM
*To:* dev@santuario.apache.org
*Subject:* Checkout bug



I am having trouble checking out the Santuario trunk on Windows.

The error is:



svn: E720123: Can't move 'D:\dev\santuario\.svn\tmp\svn-5E9C50C5' to
'D:\dev\santuario\src\test\resources\org\w3c\www\interop\xmldsig11\sun\index.html?C=D;O=A':
The filename, directory name, or volume label syntax is incorrect.



I found someone reported the same problem 10 months ago.

What was the solution?



-Original Message-

From: George Stanchev

Sent: Monday, May 16, 2011 11:23 AM

To: dev@santuario.apache.org; coheigea at apache.org

Subject: RE: small bug



I'm having some troubles checking out the trunk: getting error [1].
Looking at [2] I see the

following file: index.html?C=D;O=A. Is there any way to get around this?



[1] svn: Can't open file
'trunk\samples\data\org\w3c\www\interop\xmldsig11\sun\.svn\tmp\text-base\index.html?C=D;O=A.svn-base':

The filename, directory name, or volume label syntax is incorrect.

[2]
https://svn.apache.org/repos/asf/santuario/xml-security-java/trunk/sam
ples/data/org/w3c/www/interop/xmldsig11/sun/

Re: Source download - duplicated files

[Sean Mullan]

On 02/13/2012 09:42 AM, Eric Johnson wrote:

To whom it may concern,

I just downloaded the source zip for the latest Java Santuario release
(1.5.0), and noticed duplicated files in the source zip release, as well
as in the Subversion tags for the project.

Specifically:

This download:
https://archive.apache.org/dist/santuario/java-library/1_5_0/xml-security-src-1_5_0.zip


contains duplicates on the paths samples/data/org/w3c/www and
src/test/resources/org/w3c/www.

Looking via the web viewer of Subversion, I see similar duplication?

[Apache-SVN]
/santuario/xml-security-java/tags/1.5.0/samples/data/org/w3c/www

appears to be identical to:

[Apache-SVN]
/santuario/xml-security-java/tags/1.5.0/src/test/resources/org/w3c/www

Is this a mistake, or is this data intentionally duplicated?


I think it was intentional (looks like it was done as part of 
Santuario-257), but should probably be fixed.


Colm, any thoughts?

--Sean

Re: Id Resolution Observations and Suggestions

[Sean Mullan]

Are you still thinking we should also scan the document for duplicate IDs?

--Sean

On 12/21/11 7:14 AM, Chad La Joie wrote:
 So, last night I spent some time digging in to the new code and
 discussing with some things with Scott.  Here's where we ended up.
 
 The IdResolver is not designed in a manner that would allow alternative
 implementations to be used.  Though, given that it is only used by the
 ResourceResolver implementations, those could be replaced by the user of
 the library
 
 The new code does use the Document.getElementById method to look up IDs
 in the general case.  This may be overridden by explicitly placing
 ID-to-Element mappings into the IdResolver, but since doing this is
 neither documented nor shown in the examples it is fairly safe to assume
 this isn't happening out in the wild.
 
 Given the above, this code does not guard against any issues that may
 arise from duplicate IDs.
 
 In the case of signatures, there seems to be nothing that a library can
 do in order to ensure that the right thing is covered by the signature
 since the right thing is use-case specific.
 
 In the case of encryption, there is no way for the application to know
 whether the dereferenced encrypted encryption key is what the document
 author actually intended.  If it's not, however, the worst that would
 happen is that encrypted data would not decrypt.
 
 Given this, I believe the following things should be done:
 - The use of Document.getElementById and the potential issue caused by
 the lack of a strong guarantee on ID uniqueness should be documented.
 - The documentation for XMLSignature and all the examples should be
 updated to make it clear that the user of the library needs to check
 that what they thought was covered by the signature actually was.
 - Attempting to update the examples in this way will make it clear that
 better APIs need to be provided to expose the content indicated by
 References.
 
 In addition, given the manner in which the IdResolver currently works, I
 believe it could be done away with entirely. The
 IdResolver.registerElementById method could simply be replaced by the
 appropriate Element.setIdAttribute* method.  Doing so would remove a
 potentially large in-memory data structure as well as various
 synchronization points that currently prevent concurrent ID resolutions.
 

Re: XML Security Java 1.5.0-RC1 available

[Sean Mullan]

On 12/20/2011 10:19 AM, Chad La Joie wrote:

On Tue, Dec 20, 2011 at 04:58, Colm O hEigeartaighcohei...@apache.org  wrote:

This is already available via the JSR-105 API by setting the
javax.xml.crypto.dsig.cacheReference property to true. Apache WSS4J
uses this to build a set of protected element results, that can be
subsequently compared to an XPath expression via WS-SecurityPolicy.


Thanks for the pointer.


It is up to the application calling the signature verification code to
ensure that ID's are unique. The 1.5.0 release tightens this
requirement by not searching the document tree for any IDs in known
namespaces. The calling code must find the desired elements and
register them on the context/IdResolver for signature validation to
work.


I really think the library should support this directly and by
default.  Given *zero* systems using the library did the right thing
in the review done by the researchers, I think it's safe to say this
is non-obvious.

Let me ask this a different way.  What speaks against adding this
check in if, via an option, it can be disabled and remove the
performance hit that would be caused?


This is actually fixed in 1.5, unless I'm misunderstanding the issue. 
See the code for registerElementById() in [1]


public static void registerElementById(Element element, String 
idValue) {

Document doc = element.getOwnerDocument();
synchronized (docMap) {
MapString, WeakReferenceElement elementMap = 
docMap.get(doc);

if (elementMap == null) {
elementMap = new WeakHashMapString, 
WeakReferenceElement();

docMap.put(doc, elementMap);
elementMap.put(idValue, new 
WeakReferenceElement(element));

} else {
WeakReferenceElement ref = elementMap.get(idValue);
if (ref != null) {
if (!ref.get().equals(element)) {
throw new IllegalArgumentException(ID is 
already registered);

}
} else {
elementMap.put(idValue, new 
WeakReferenceElement(element));

}
}
}
}

Note the lines where it checks if the ID is already registered, and 
throws an IllegalArgumentExc.


--Sean

[1] 
http://svn.apache.org/viewvc/santuario/xml-security-java/tags/1.5.0-RC1/src/main/java/org/apache/xml/security/utils/IdResolver.java?view=markup

Re: XML Security Java 1.5.0-RC1 available

[Sean Mullan]

On 12/20/2011 10:37 AM, Chad La Joie wrote:

That code would be part of the solution.  But does the entire tree get
walked or does the IdResolver just stop once it finds a match (which I
thought was what happened).


It no longer searches. All IDs have to be pre-registered. It knows about 
IDs in the XML signature namespace so pre-registers those itself.


We could search the entire document every time for duplicate IDs but 
then nobody would use the library because it would be too slow.


This is an issue that we can solve partially, but in my opinion higher 
level APIs need to also do their job and register the IDs in their own 
namespaces (or use a validating schema). Then wrapping attacks are not 
possible.


--Sean




On Tue, Dec 20, 2011 at 10:35, Sean Mullansean.mul...@oracle.com  wrote:

On 12/20/2011 10:19 AM, Chad La Joie wrote:


On Tue, Dec 20, 2011 at 04:58, Colm O hEigeartaighcohei...@apache.org
  wrote:


This is already available via the JSR-105 API by setting the
javax.xml.crypto.dsig.cacheReference property to true. Apache WSS4J
uses this to build a set of protected element results, that can be
subsequently compared to an XPath expression via WS-SecurityPolicy.



Thanks for the pointer.


It is up to the application calling the signature verification code to
ensure that ID's are unique. The 1.5.0 release tightens this
requirement by not searching the document tree for any IDs in known
namespaces. The calling code must find the desired elements and
register them on the context/IdResolver for signature validation to
work.



I really think the library should support this directly and by
default.  Given *zero* systems using the library did the right thing
in the review done by the researchers, I think it's safe to say this
is non-obvious.

Let me ask this a different way.  What speaks against adding this
check in if, via an option, it can be disabled and remove the
performance hit that would be caused?



This is actually fixed in 1.5, unless I'm misunderstanding the issue. See
the code for registerElementById() in [1]

public static void registerElementById(Element element, String idValue) {
Document doc = element.getOwnerDocument();
synchronized (docMap) {
MapString, WeakReferenceElement  elementMap = docMap.get(doc);
if (elementMap == null) {
elementMap = new WeakHashMapString,
WeakReferenceElement();
docMap.put(doc, elementMap);
elementMap.put(idValue, new WeakReferenceElement(element));
} else {
WeakReferenceElement  ref = elementMap.get(idValue);
if (ref != null) {
if (!ref.get().equals(element)) {
throw new IllegalArgumentException(ID is already
registered);
}
} else {
elementMap.put(idValue, new
WeakReferenceElement(element));
}
}
}
}

Note the lines where it checks if the ID is already registered, and throws
an IllegalArgumentExc.

--Sean

[1]
http://svn.apache.org/viewvc/santuario/xml-security-java/tags/1.5.0-RC1/src/main/java/org/apache/xml/security/utils/IdResolver.java?view=markup

Re: XML Security Java 1.5.0-RC1 available

[Sean Mullan]

On 12/20/2011 10:59 AM, Cantor, Scott wrote:

On 12/20/11 10:55 AM, Sean Mullansean.mul...@oracle.com  wrote:


It no longer searches. All IDs have to be pre-registered. It knows about
IDs in the XML signature namespace so pre-registers those itself.


Does that imply you no longer rely on getElementById either? Because
that's a search you don't control, and we know Xerces allows duplicates,
ergo so does Santuario if it uses that API.


The code does still call DOM Document.getElementById, but how does that 
make it possible to do an attack? The trusted validation code should be 
creating the Document and registering the IDs. If you are letting 
untrusted code create the Document for you and register arbitrary IDs, 
then that is a bug.


--Sean


We could search the entire document every time for duplicate IDs but
then nobody would use the library because it would be too slow.


It would work fine in many applications that favor guarantees over speed.


This is an issue that we can solve partially, but in my opinion higher
level APIs need to also do their job and register the IDs in their own
namespaces (or use a validating schema). Then wrapping attacks are not
possible.


Unless you're not using the DOM ID APIs anymore, they're still possible
because Xerces remains broken.

-- Scott

Re: XML Security Java 1.5.0-RC1 available

[Sean Mullan]

On 12/20/2011 11:06 AM, Chad La Joie wrote:

On Tue, Dec 20, 2011 at 10:55, Sean Mullansean.mul...@oracle.com  wrote:

It no longer searches. All IDs have to be pre-registered. It knows about IDs
in the XML signature namespace so pre-registers those itself.


I guess I'm missing something.  How is this done?  After a parse
(without schema validation) no attributes would be marked as ID
attributes.  So how does the library pre-register anything?


It has builtin knowledge of the XML Signature schema, so it is able to 
register all elements with ID attributes in the dsig namespace as it is 
parsing the XML Signature. If there are any duplicates, as of 1.5 it 
throws an exception.



And are
you saying that prior to signature validation (or encrypted key
resolution), that the app must go through and register every
ID/element mapping itself?


Just the ones that aren't in the dsig namespace. We don't have any 
knowledge of other schemas. I'm not sure about the enc namespace, will 
need to check that.



We could search the entire document every time for duplicate IDs but then
nobody would use the library because it would be too slow.


Not to be flippant, but do you actually have anything to back that up?
  Relatively speaking, a treewalk is pretty fast (when compared to
things like canonicalization and various crypto functions).


We used to do a recursive walk of the tree every time to fix namespace 
attributes when canonicalizing to workaround bug 2560 in Xerces - the 
code is actually still in there - search for circumventBug2560.


I remember that when we removed the dependency on this method, there was 
a performance improvement, how much I don't recall but it was somewhat 
significant if I remember - these numbers could be in the archives 
somewhere, when I have some more time I'll check.


I would want to do some performance testing before we added something 
like this.



This is an issue that we can solve partially, but in my opinion higher level
APIs need to also do their job and register the IDs in their own namespaces
(or use a validating schema). Then wrapping attacks are not possible.


Sure, and everyone should always completely bug free code.  They
don't.  All I'm trying to say is that we could provide a real fix for
this that protects people against an attack that is known to be in the
wild and which all tested users of Santuario were vulnerable to.


Ok, I can see how this could make things easier and help screen out 
potentially dangerous documents. Would you have some time to writeup a 
patch that we could then do some more testing on?


--Sean

Re: XML Security Java 1.5.0-RC1 available

[Sean Mullan]

On 12/20/2011 11:21 AM, Cantor, Scott wrote:

On 12/20/11 11:12 AM, Sean Mullansean.mul...@oracle.com  wrote:


The code does still call DOM Document.getElementById, but how does that
make it possible to do an attack?


If you mark known ID attributes as IDs by calling setIdAtribute, Xerces
will allow duplicates.


I did a grep of the source tree, and our code never calls 
Element.setIdAttribute.



If you insist that the application do a tree walk
to prevent duplicates, then you're telling us that every app should
implement the thing you claim is too slow for Santuario to implement.


Usually an app won't have to do that - it is aware of the schema, and 
where the element IDs should be in the document - Colm can comment some 
more on how the WSS library does this. Our library won't find anything 
that isn't registered, so if you stick something way down in the guts of 
the document, it simply won't find it. (It used to, but not as of 1.5). 
But I can see the duplicate ID issues you mention, if the app uses 
Element.setIdAttribute to register the ID attributes.


As I understand the wrapping attacks, it happens after the signature is 
validated, when the application actually acts on the element content 
that is mapped to that ID. Then, it needs to find that element, and if 
there are duplicate IDs and it gets the wrong one, then oops. As Colm 
mentioned, we do have a mechanism to return the Elements that were 
actually validated.


But I guess I see an issue in that it is hard for the app to do all 
these extra checks to prevent wrapping attacks. It sounds like what we 
need is an additional optional sanity check on the entire document 
looking for duplicate IDs.



Additionally, parsers have bugs enforcing uniqueness on IDs during schema
validation. Xerces-C for example has a nasty one involving wildcards and
lax schemas. All because they allow something that shouldn't ever be legal
in the first place, duplicates in the Document's ID map. Fix that, in one
place, and all of this goes away.

Thus my point. The Xerces team is wrong. Somebody needs to explain that to
them, somebody they'll listen to.


If they won't listen to you, I'm sure they won't listen to me ;)


The trusted validation code should be
creating the Document and registering the IDs. If you are letting
untrusted code create the Document for you and register arbitrary IDs,
then that is a bug.


If you claim schema validation is one way, then the parser has to be
trusted. Alternatively, the application can't just register the IDs, but
must also track and search for duplicates, or it can't rely on
setIdAttributeNS to register them.

That's why I'm asking about the algorithm. You're basically duplicating
the DOM3 ID API in Santuario. So my advice is to stop relying on the
original. Since I don't think that's really a good thing either, I
continue to argue that the fix belongs in the parser.


Hmm, I suppose we could stop calling Document.getElementById if the 
document was not validated against a schema. Let me think about that 
some more.


--Sean

Re: XML Security Java 1.5.0-RC1 available

[Sean Mullan]

On 12/20/2011 02:29 PM, Cantor, Scott wrote:

On 12/20/11 2:11 PM, Sean Mullansean.mul...@oracle.com  wrote:


I did a grep of the source tree, and our code never calls
Element.setIdAttribute.


Yes, but apps do. My code does. That's currently the way for schema
validation *and* manual ID setting to result in the same outcome, assuming
you call getElementById on your end.


Yep, although we do offer our own API alternatives for manual 
registration that don't use getElementById():


JSR 105: DOMCryptoContext.setIdAttributeNS()
XMLSec:  IdResolver.registerElementById()


As I understand the wrapping attacks, it happens after the signature is
validated, when the application actually acts on the element content
that is mapped to that ID. Then, it needs to find that element, and if
there are duplicate IDs and it gets the wrong one, then oops. As Colm
mentioned, we do have a mechanism to return the Elements that were
actually validated.


Right. I agree that it's obviously better to do that, although I wonder
about the performance when dealing with transformed node sets.

I don't have it yet in C++, and I've been hesitant because it's a lot of
work, and I don't have a lot of time to fix things that aren't broken in
my code. I'm particularly unclear how to do it for the general case, not
just a simple ID reference to an element subtree. All I can see to do is
clone the nodes to save them off and return them. Or save the octets I
guess.

Point being, the API can't be just here's the Element, but rather the
node set or stream.


Right, it can be costly to cache the data as well, that's why we made it 
optional. We return an octet stream or a node-set, depending on what was 
dereferenced.



Thus my point. The Xerces team is wrong. Somebody needs to explain that
to
them, somebody they'll listen to.


If they won't listen to you, I'm sure they won't listen to me ;)


Well, we tried (in fairness Xerces-C is more or less dead, so the open bug
is all I really expected there). Now I think it's down to us defining a
suitable algorithm. It may be that abandoning the DOM API is the right
thing, but I don't think we should do that without some deprecation time.


Yes, breaking compatibility is a concern.


Hmm, I suppose we could stop calling Document.getElementById if the
document was not validated against a schema. Let me think about that
some more.



I'm not sure if you can tell, actually. Maybe in Java.


Possibly not just Java. Looking at the DOM APIs, I think you could get a 
DOMConfiguration object from the Document object, and if the validate 
parameter is set to true, assume that it has been validated.



I think the most logical thing to do if you're going to deprecate that
call is to make it an application option. Basically I'd have a set of
IdResolvers with different, defined behavior, choose a default for the
time being, possibly deprecate some of them, etc. I think that's cleaner
than trying to create a bunch of options.


Yes, just need someone to write the code now :)

--Sean

Re: Issue Endorsing Santuario

[Sean Mullan]

On 11/2/11 7:19 PM, Chad La Joie wrote:
 On Wed, Nov 2, 2011 at 18:13, Sean Mullan sean.mul...@oracle.com wrote:
 The JDK and Santuario implementations use different logging APIs.
 
 Right, that is the reason you have to put the commons logging library
 in the endorsed directory and the cause of the potential conflicts.
 The question is, is that really the way it should be?
 
 Personally, I think if the goal is to allow Santuario to be used as a
 JVM's JSR105 implementation, as opposed to just implementing the
 JSR105 APIs, then you have to accept the limitations of the JVM's
 environment (i.e., use their logging facility).

I'm open to doing this, since it is the main integration pain point I have to go
through every time I pull in a new release of Santuario into the JDK. I don't
see any advantage to keeping the commmons-logging dependency as the logging API
in the JDK offers equivalent functionality for what we are using it for.
However, I have not thought enough about the compatibility impact so we should
think this through some more first.

--Sean

Re: Issue Endorsing Santuario

[Sean Mullan]

On 11/3/11 11:28 AM, Chad La Joie wrote:
 Okay, so, I think the question is still the same.  Do we, or not, want
 to have to requirement the logging library on the classpath.
 
 As an aside, given the choice between endorsing the library and editing
 the java.security file and adding the lib to the ext directory, I think
 endorsement is still the better option.  Who knows if the deployer will
 have the ability to edit the java.security config.

Yeah I hear you, but in this case, endorsement is really a hack and is not being
used for the right reasons [1]. The org.jcp APIs are not standard APIs. It just
happens to work because the implementation packages are named the same.

--Sean

[1]: http://download.oracle.com/javase/1.5.0/docs/guide/standards/index.html

 
 On 11/3/11 11:22 AM, Colm O hEigeartaigh wrote:
 Hi Chad,

 Yep that's pretty much correct I think. One clarification to the first
 method, is that you would need to install the provider before the
 XMLDSig provider in JDK 1.6+ to use the Santuario provider, or
 explicitly name the provider when instantiating XMLSignatureFactory
 etc.

 Colm.

 On Thu, Nov 3, 2011 at 2:44 PM, Chad La Joie laj...@itumi.biz wrote:
 Colm, can you describe how you'd install the provider?  My understanding
 is that there are two possible ways in which one could this.

 1. You make code modifications to explicitly add the provider via the
 Provider API.  So, as long as the logging libs are on your classpath
 before you do this, everything works okay.

 2. You register the provider via the java.security config file and drop
 the library in the $JAVA_HOME/lib/ext directory.  This method has the
 benefit of not having to modify code but the drawback that you'd still
 have to put the logging jar in the ext directory and you'd still end up
 polluting the classpath.

 On 11/3/11 10:32 AM, Colm O hEigeartaigh wrote:
 There is no longer any need to endorse anything, as it's a simple
 matter of installing the JSR-105 provider that ships with Santuario
 before the JDK XMLDSig provider, if you want to use the Santuario
 implementation.


 --
 Chad La Joie
 www.itumi.biz
 trusted identities, delivered




 

Re: Issue Endorsing Santuario

[Sean Mullan]

On 11/2/11 12:40 PM, Chad La Joie wrote:
 I've been planning to move our Shib code over to use the JSR105 APIs
 for signature work.  One of our testers today was trying to use SHA256
 within their signatures and received the error that this wasn't
 supported by the JVM-shipped implementation of those APIs.  So, I
 figured we'd just endorse xmlsec in order to use it at the JVM's
 JSR105 impl.
 
 However, when we tried this, we received the error that Apache
 Common's Logging was not available.  This, of course, is true.  That
 library isn't available in the JVM's internal classpath.
 
 So, the question is, should it be possible to use xmlsec as a JVM's
 JSR105 implementation?

Yes, but you need to also put commons-logging.jar in the endorsed dir. See my
blog for more info:

http://blogs.oracle.com/mullan/entry/using_more_recent_apache_xml

--Sean

Re: Issue Endorsing Santuario

[Sean Mullan]

The JDK and Santuario implementations use different logging APIs.

Part of the problem is also that the org.jcp.xml.dsig classes are named the same
in the JDK and Santuario, so it loads the JDK classes first - we're planning on
fixing this in the 1.5 release of Santuario by renaming these classes so they
are distinct from the JDK.

In the meantime, you may be able to hack around this by creating a JCA provider
for XMLDSig which loads the JSR 105 implementation SPI classes from xmlsec.jar.

--Sean

On 11/2/11 4:59 PM, Chad La Joie wrote:
 This is pretty suboptimal.  Classes (or JARs of classes) within the
 endorsed directory are visible on the classpath and obviously logging
 frameworks are one of those things where there is a lot of
 variability.
 
 On Wed, Nov 2, 2011 at 12:50, Sean Mullan sean.mul...@oracle.com wrote:
 On 11/2/11 12:40 PM, Chad La Joie wrote:
 I've been planning to move our Shib code over to use the JSR105 APIs
 for signature work.  One of our testers today was trying to use SHA256
 within their signatures and received the error that this wasn't
 supported by the JVM-shipped implementation of those APIs.  So, I
 figured we'd just endorse xmlsec in order to use it at the JVM's
 JSR105 impl.

 However, when we tried this, we received the error that Apache
 Common's Logging was not available.  This, of course, is true.  That
 library isn't available in the JVM's internal classpath.

 So, the question is, should it be possible to use xmlsec as a JVM's
 JSR105 implementation?

 Yes, but you need to also put commons-logging.jar in the endorsed dir. See my
 blog for more info:

 http://blogs.oracle.com/mullan/entry/using_more_recent_apache_xml

 --Sean

 
 
 

Re: Question on DOMXMLObject implementation in 1.4.6

[Sean Mullan]

On 10/28/11 3:44 PM, Eric Johnson wrote:
 Hi Sean,
 
 Thanks for the feedback.
 
 I ended solving this by wrapping all the declared namespaces in an 
 instance of a class that extends XMLStructure (actually, the default one 
 - this would have been javax.xml.crypto.dom.DOMStructure but for the 
 fact that with the GenXDM port we need a GenXDMStructure equivalent of 
 that.). I then add that object to the content of the XMLObject. Then, 
 when marshaling the object, I check to see if the referenced node is a 
 namespace declaration, and declare the namespace in the target output 
 (rather than inserting the source node).
 
 This isn't quite a perfect solution, because if the caller modifies the 
 namespace declaration, then that update will be reflected in the later 
 marshaling, but it works. And it isn't any different in that regard from 
 the solution in 1.4.6, except it is no longer destructive to the source 
 document used when unmarshaling.
 
 Here's a question - with the current implementation in 1.4.6, it strikes 
 me that attributes like xml:base, xml:id, and xml:lang would also be 
 preserved in the new marshaling - I'm not sure that's correct. Or is it? 
 Certainly, my change to preserve namespaces doesn't preserve those 
 attributes, but perhaps it should?

Yes, if you are using C14N 1.1 : http://www.w3.org/TR/xml-c14n11/

--Sean


 
 -Eric.
 
 On 10/26/11 5:40 PM, Sean Mullan wrote:
 On 10/26/11 8:30 AM, Eric Johnson wrote:
 In the 1.4.6 release of Santuario Java, the DOMXMLObject class underwent
 a small set of changes.

 Specifically, it appears that the class now holds on to the objElem
 passed to the constructor:

 public DOMXMLObject(Element objElem, XMLCryptoContext context, Provider
 provider);

 It appears to do this so that the objElem can be re-used upon calling
 the marshal method.

 Is this related to https://issues.apache.org/jira/browse/SANTUARIO-283 ?
 Yes.

 I've been changing the marshaling code in the GenXDM port so that it
 makes minimal assumptions about the implementation of the various
 javax.xml.crypto APIs.

 That is, in the GenXDM port, the equivalent marshal function looks like:

   public staticN   void marshal(XMLObject xmlObj, MutableModelN   
 model, N parent, String dsPrefix, XMLCryptoContext context)
 throws MarshalException {

 NodeFactoryN   factory = model.getFactory(parent);

   N objElem = factory.createElement
   (XMLSignature.XMLNS, Object, dsPrefix);

   // set attributes
   DOMUtils.setAttributeID(factory, model, objElem, Id, 
 xmlObj.getId());
   DOMUtils.setAttribute(factory, model, objElem, MimeType, 
 xmlObj.getMimeType());
   DOMUtils.setAttribute(factory, model, objElem, Encoding, 
 xmlObj.getEncoding() );

   // create and append any elements and mixed content, if necessary
   @SuppressWarnings(unchecked)
   ListXMLStructure   content = xmlObj.getContent();
   for (XMLStructure object : content) {
   Marshaller.marshal(object, model, objElem, dsPrefix, context);
   }
 
 model.appendChild(parent, objElem);
   }


 Note that this method is both static, and takes a generic XMLObject as a
 parameter, rather than the Apache implementation specific version of
 DOMXMLObject.

 I'm inclined to change my port so that upon unmarshalling the node, it
 captures the namespace declarations on the node, and then in the marshal
 code above, I add a check to see if the xmlObj is an instance of a
 DOMXMLObject, and only then see if the specific known implementation has
 unmarshalled any namespace declarations, and if it has, add those as
 part of what gets output.

 Alternately, I could add the namespace declarations as members of the
 getContent() collection, and if I detect them, write out the namespace
 declarations.

 Either of the above has the upside that you can then marshal the
 object as many times as you want, to as many target trees you want,
 without worrying that the same element will be used over and over again.

 Comments?
 The underlying problem is that you cannot access the namespace declarations 
 via
 JSR 105 XMLObject API. That should be fixed eventually but since there are no
 immediate plans for reving the API, we need to work around it.

 Your first solution seems better. The second solution is not compliant with 
 the
 XMLObject.getContent() API.

 --Sean

Re: Question on DOMXMLObject implementation in 1.4.6

[Sean Mullan]

On 10/26/11 8:30 AM, Eric Johnson wrote:
 In the 1.4.6 release of Santuario Java, the DOMXMLObject class underwent 
 a small set of changes.
 
 Specifically, it appears that the class now holds on to the objElem 
 passed to the constructor:
 
 public DOMXMLObject(Element objElem, XMLCryptoContext context, Provider 
 provider);
 
 It appears to do this so that the objElem can be re-used upon calling 
 the marshal method.
 
 Is this related to https://issues.apache.org/jira/browse/SANTUARIO-283 ?

Yes.

 I've been changing the marshaling code in the GenXDM port so that it 
 makes minimal assumptions about the implementation of the various 
 javax.xml.crypto APIs.
 
 That is, in the GenXDM port, the equivalent marshal function looks like:
 
  public staticN  void marshal(XMLObject xmlObj, MutableModelN  model, 
 N parent, String dsPrefix, XMLCryptoContext context)
   throws MarshalException {
 
   NodeFactoryN  factory = model.getFactory(parent);
 
  N objElem = factory.createElement
  (XMLSignature.XMLNS, Object, dsPrefix);
 
  // set attributes
  DOMUtils.setAttributeID(factory, model, objElem, Id, 
 xmlObj.getId());
  DOMUtils.setAttribute(factory, model, objElem, MimeType, 
 xmlObj.getMimeType());
  DOMUtils.setAttribute(factory, model, objElem, Encoding, 
 xmlObj.getEncoding() );
 
  // create and append any elements and mixed content, if necessary
  @SuppressWarnings(unchecked)
  ListXMLStructure  content = xmlObj.getContent();
  for (XMLStructure object : content) {
  Marshaller.marshal(object, model, objElem, dsPrefix, context);
  }
   
   model.appendChild(parent, objElem);
  }
 
 
 Note that this method is both static, and takes a generic XMLObject as a 
 parameter, rather than the Apache implementation specific version of 
 DOMXMLObject.
 
 I'm inclined to change my port so that upon unmarshalling the node, it 
 captures the namespace declarations on the node, and then in the marshal 
 code above, I add a check to see if the xmlObj is an instance of a 
 DOMXMLObject, and only then see if the specific known implementation has 
 unmarshalled any namespace declarations, and if it has, add those as 
 part of what gets output.
 
 Alternately, I could add the namespace declarations as members of the 
 getContent() collection, and if I detect them, write out the namespace 
 declarations.
 
 Either of the above has the upside that you can then marshal the 
 object as many times as you want, to as many target trees you want, 
 without worrying that the same element will be used over and over again.
 
 Comments?

The underlying problem is that you cannot access the namespace declarations via
JSR 105 XMLObject API. That should be fixed eventually but since there are no
immediate plans for reving the API, we need to work around it.

Your first solution seems better. The second solution is not compliant with the
XMLObject.getContent() API.

--Sean

Re: [VOTE] Release Apache XML Security for Java 1.4.6

[Sean Mullan]

+1

--Sean

On 10/17/11 6:14 AM, Colm O hEigeartaigh wrote:
 It's been a while since the 1.4.5 release of the Java library, so we
 might as well release 1.4.6 to get the bug fixes out.
 
 Svn tag:
 
 https://svn.apache.org/repos/asf/santuario/xml-security-java/tags/1.4.6/
 
 Issues fixed:
 
 https://issues.apache.org/jira/browse/SANTUARIO/fixforversion/12316461
 
 Distribution:
 
 http://people.apache.org/~coheigea/stage/xmlsec/1.4.6/dist/
 
 Maven artifacts:
 
 http://people.apache.org/~coheigea/stage/xmlsec/1.4.6/maven/
 
 Here is my +1.
 
 Colm.
 
 
 

Re: [VOTE] Release Apache XML Security for Java 1.4.5

[Sean Mullan]

Hi Colm,

Did we want to also try to address SANTUARIO-273 before releasing?

--Sean

On 05/19/2011 11:46 AM, Colm O hEigeartaigh wrote:

This is a vote to release Apache XML Security for Java 1.4.5. This
distribution was built from the following svn tag:

http://svn.apache.org/viewvc/santuario/xml-security-java/tags/1.4.5/

The changelog is here:

https://issues.apache.org/jira/browse/SANTUARIO/fixforversion/12315957

The distribution is here:

http://people.apache.org/~coheigea/stage/xmlsec/1.4.5/dist/

The maven artifacts are here:

http://people.apache.org/~coheigea/stage/xmlsec/1.4.5/maven/

Here is my +1 (binding).

Colm.

Re: Small milestone for genxdm-based port of Santuario - works with Axiom!

[Sean Mullan]

On 4/20/11 1:43 PM, Eric Johnson wrote:

A quick email to note an interesting milestone that we just achieved.

For those who missed my previous emails, over at Apache Extras [1], we've been
working on the santuario-genxdm [2] project, which is a port of the Santuario
project to work using GenXDM [3].

With our latest release of GenXDM, we introduced support for a new bridge to
the Axiom [4] data model. That meant, in theory, that the santuario-genxdm
project could now work with three different data models - Axiom, DOM, and our
reference implementation we call Cx.

In practice, Axiom didn't quite work. One security test case was failing.
Yesterday, we fixed that bug, so the next release of GenXDM, coupled with
santuario-genxdm, means that you can encrypt, decrypt, sign, and canonicalize
Axiom-based tree models with full compliance.

In any case, one reason for writing this post is that it seems like we've passed
a crucial milestone, and ought to do an official build of santuario-genxdm, so
that others don't have to grab the source to build it and play with it.

The trick is, the port really should be a drop-in replacement (plus the
requisite GenXDM JARs). We've attempted to maintain full API compatibility.
Except that actual drop-in replacement would imply keeping the same names as the
existing JARs. Not wanting to step on any toes, or pretend this release is
something it isn't, keeping the existing xml-security JAR file names seems like
a bad idea. What name changes should I introduce?


I agree that you should avoid using the existing xmlsec.jar name. But other than 
that, I don't have any specific recommendations, and I think the name is 
completely up to you.


--Sean



-Eric.

[1] https://code.google.com/a/apache-extras.org/hosting/
[2] https://code.google.com/a/apache-extras.org/p/santuario-genxdm/
[3] https://code.google.com/p/genxdm/
[4] https://ws.apache.org/axiom/

Re: SignatureMethod http://www.w3.org/2001/04/xmldsig-more#rsa-sha512

[Sean Mullan]

On 03/16/2011 12:56 PM, David Wall wrote:

I am using Java 6 with its bundled XML Digital Signature library, and
while I noted that there's a DigestMethod.SHA512, there is not
SignatureMethod.RSA_SHA512, and I'm limited to the older
SignatureMethod.RSA_SHA1.

Is this supported somehow that I don't understand?


Yes, it is supported, but you have to specify the URL String as there is 
no constant defined in the API yet. Ex:


http://www.w3.org/2001/04/xmldsig-more#rsa-sha512;

--Sean


Does the Apache
Santuario support it in a standard way? I want to be sure our digital
signatures are easily portable to other validators especially.

Thanks,
David