Re: Compiling CPP Samples under Ubuntu 8.0.4
Heya, Out of curiosity - should the subversion trunk compile under Linux at the moment? I was going to have a look at the problem below, but I've got some problems that look like the makefiles might not have been updated for the EC stuff? But before I touch anything I want to make sure I'm not just doing something stupid :). Cheers, Berin On 21/08/2010, at 2:33 AM, Scott Cantor wrote: Thanks for the response. Unfortunately (as for as I can tell), the master configuration script is not generating a makefile for the samples. You can go ahead and file a bug on that, I don't know if I'll be able to fix it in the time I'd have alotted, but it should at be tracked at least. At minimum you certainly would need to copy settings over from the test/utility makefiles if you were to build them by hand. -- Scott
Re: Compiling CPP Samples under Ubuntu 8.0.4
Current trunk does - but the makefile goes into the bin directory off the root. Just doing a make in the base will make the samples as well as the library and *should* place them into the bin directory. Cheers, Berin On 21/08/2010, at 2:29 AM, Arend van der Veen wrote: Hi Scott, Thanks for the response. Unfortunately (as for as I can tell), the master configuration script is not generating a makefile for the samples. Thanks, Arend On Fri, Aug 20, 2010 at 12:16 PM, Scott Cantor canto...@osu.edu wrote: I now wish to compile and test one of the samples. I switched to the following directory and compile: cd src/samples gcc simpleDecrypt.cpp If that's literally the command you used, I don't know why you think that would work, it's missing a half dozen flags or more. I haven't looked lately, but I assume that the master configure script generates makefiles for the samples as well, and that's what you should be using to build them. -- Scott
Re: [Fwd: [Fwd: ASF Board Report - Initial Reminder for May 2009]]
OK - That's 3 +1 no negatives. I will put the thing together for the board in this month's report 'grats Raul :) Cheers, Berin Sean Mullan wrote: +1 Berin Lautenbach wrote: +1 from me :) Raul Benito wrote: Ok, I will regret to say that but I'm in. What are the next steps, a vote between PMC members? Regards, Raul On Tue, May 19, 2009 at 12:29 PM, Berin Lautenbach be...@wingsofhermes.org wrote: Have a look-see at: http://www.apache.org/dev/pmc.html#chair Cheers, Berin Raul Benito wrote: Ok, I can take one day a month as PMC chairman, does it will be enough? what are the other responsibilities beside the monthly reports? On Fri, May 8, 2009 at 11:49 AM, Berin Lautenbach be...@wingsofhermes.org wrote: Heya all, Anyone going to pick this up? Any volunteers for chair? Cheers, Berin Original Message Subject: [Fwd: ASF Board Report - Initial Reminder for May 2009] Date: Mon, 04 May 2009 19:13:46 +1000 From: Berin Lautenbach be...@wingsofhermes.org Reply-To: security-dev@xml.apache.org To: security-dev@xml.apache.org Hey guys, I think I missed the last one of these. I'm not getting a chance to get to these so I am going to look to someone else to step up and take this on. I've mentioned a couple of times I want to step down as chair - this is it guys :). Someone needs to take over the chair position or I guess we apply to the board to have the project moved to the attic. Cheers, Berin Original Message Subject: ASF Board Report - Initial Reminder for May 2009 Date: 1 May 2009 00:50:05 - From: ASF Board bo...@apache.org To: Berin Lautenbach blaut...@apache.org This email was sent by an automated system on behalf of the ASF Board. It is an initial reminder to give you plenty of time to prepare the report. The meeting is scheduled for Wed, 20 May 2009, 10 am PST and the deadline for submitting your report is two full days prior to that! According to board records, you are listed as the chair of at least one committee that is due to submit a report this month. [1] [2] Details on which project reports are due and how to submit a report are enclosed below. Please submit your report with sufficient time to allow the board members to review and digest. Again, the very latest you should submit your report is two full days (48h) prior to the board meeting. The exact date of the board meeting can be found in the calendar.txt file in the board directory of the committers repository [2]. If you feel that an error has been made, please consult [1] and if there is still an issue then contact the board directly. Thanks, The ASF Board [1] - https://svn.apache.org/repos/private/committers/board/committee-info.txt [2] - https://svn.apache.org/repos/private/committers/board/calendar.txt Submitting your Report -- Full details about the process and schedule are in [1]. Your report should be sent in plain-text format to bo...@apache.org with a Subject line that follows the below format: Subject: [REPORT] Project Name Cutting and pasting directly from a Wiki is not acceptable due to formatting issues. Line lengths should be limited to 77 characters. The content should also be committed to the meeting agenda in the board directory in the foundation repository. ASF Board Reports - Reports are due from you for the following committees: - Santuario
Re: [Fwd: [Fwd: [Fwd: ASF Board Report - Initial Reminder for May 2009]]]
Hiya, It sounds like a reasonable idea - but the main thing is someone needs to take on the accountability to do it. I just don't have the free time anymore to give the project the attention it deserves :(. We've just missed another board report - either someone takes on the responsibility to work out what to do with the project/code or we should recommend the project be shut down. Cheers, Berin Sean Mullan wrote: Hi Berin, What are the benefits of being our own project? We used to be part of xml.apache.org and I really see no difference since we became our own project. Also, what are the implications of being archived? This is still a very important and active project and should not be relegated to the attic or discontinued in any way. Can we go back to being a project under xml.apache.org? Thanks, Sean Berin Lautenbach wrote: Does this mean we want to wind up the project? If there is no interest in anyone taking on the chair role I will recommend to the board that the project be moved to the archives. Cheers, Berin Original Message Subject: [Fwd: [Fwd: ASF Board Report - Initial Reminder for May 2009]] Date: Fri, 08 May 2009 19:49:15 +1000 From: Berin Lautenbach be...@wingsofhermes.org Reply-To: security-dev@xml.apache.org To: security-dev@xml.apache.org Heya all, Anyone going to pick this up? Any volunteers for chair? Cheers, Berin Original Message Subject: [Fwd: ASF Board Report - Initial Reminder for May 2009] Date: Mon, 04 May 2009 19:13:46 +1000 From: Berin Lautenbach be...@wingsofhermes.org Reply-To: security-dev@xml.apache.org To: security-dev@xml.apache.org Hey guys, I think I missed the last one of these. I'm not getting a chance to get to these so I am going to look to someone else to step up and take this on. I've mentioned a couple of times I want to step down as chair - this is it guys :). Someone needs to take over the chair position or I guess we apply to the board to have the project moved to the attic. Cheers, Berin Original Message Subject: ASF Board Report - Initial Reminder for May 2009 Date: 1 May 2009 00:50:05 - From: ASF Board bo...@apache.org To: Berin Lautenbach blaut...@apache.org This email was sent by an automated system on behalf of the ASF Board. It is an initial reminder to give you plenty of time to prepare the report. The meeting is scheduled for Wed, 20 May 2009, 10 am PST and the deadline for submitting your report is two full days prior to that! According to board records, you are listed as the chair of at least one committee that is due to submit a report this month. [1] [2] Details on which project reports are due and how to submit a report are enclosed below. Please submit your report with sufficient time to allow the board members to review and digest. Again, the very latest you should submit your report is two full days (48h) prior to the board meeting. The exact date of the board meeting can be found in the calendar.txt file in the board directory of the committers repository [2]. If you feel that an error has been made, please consult [1] and if there is still an issue then contact the board directly. Thanks, The ASF Board [1] - https://svn.apache.org/repos/private/committers/board/committee-info.txt [2] - https://svn.apache.org/repos/private/committers/board/calendar.txt Submitting your Report -- Full details about the process and schedule are in [1]. Your report should be sent in plain-text format to bo...@apache.org with a Subject line that follows the below format: Subject: [REPORT] Project Name Cutting and pasting directly from a Wiki is not acceptable due to formatting issues. Line lengths should be limited to 77 characters. The content should also be committed to the meeting agenda in the board directory in the foundation repository. ASF Board Reports - Reports are due from you for the following committees: - Santuario
Re: [Fwd: [Fwd: ASF Board Report - Initial Reminder for May 2009]]
+1 from me :) Raul Benito wrote: Ok, I will regret to say that but I'm in. What are the next steps, a vote between PMC members? Regards, Raul On Tue, May 19, 2009 at 12:29 PM, Berin Lautenbach be...@wingsofhermes.org wrote: Have a look-see at: http://www.apache.org/dev/pmc.html#chair Cheers, Berin Raul Benito wrote: Ok, I can take one day a month as PMC chairman, does it will be enough? what are the other responsibilities beside the monthly reports? On Fri, May 8, 2009 at 11:49 AM, Berin Lautenbach be...@wingsofhermes.org wrote: Heya all, Anyone going to pick this up? Any volunteers for chair? Cheers, Berin Original Message Subject: [Fwd: ASF Board Report - Initial Reminder for May 2009] Date: Mon, 04 May 2009 19:13:46 +1000 From: Berin Lautenbach be...@wingsofhermes.org Reply-To: security-dev@xml.apache.org To: security-dev@xml.apache.org Hey guys, I think I missed the last one of these. I'm not getting a chance to get to these so I am going to look to someone else to step up and take this on. I've mentioned a couple of times I want to step down as chair - this is it guys :). Someone needs to take over the chair position or I guess we apply to the board to have the project moved to the attic. Cheers, Berin Original Message Subject: ASF Board Report - Initial Reminder for May 2009 Date: 1 May 2009 00:50:05 - From: ASF Board bo...@apache.org To: Berin Lautenbach blaut...@apache.org This email was sent by an automated system on behalf of the ASF Board. It is an initial reminder to give you plenty of time to prepare the report. The meeting is scheduled for Wed, 20 May 2009, 10 am PST and the deadline for submitting your report is two full days prior to that! According to board records, you are listed as the chair of at least one committee that is due to submit a report this month. [1] [2] Details on which project reports are due and how to submit a report are enclosed below. Please submit your report with sufficient time to allow the board members to review and digest. Again, the very latest you should submit your report is two full days (48h) prior to the board meeting. The exact date of the board meeting can be found in the calendar.txt file in the board directory of the committers repository [2]. If you feel that an error has been made, please consult [1] and if there is still an issue then contact the board directly. Thanks, The ASF Board [1] - https://svn.apache.org/repos/private/committers/board/committee-info.txt [2] - https://svn.apache.org/repos/private/committers/board/calendar.txt Submitting your Report -- Full details about the process and schedule are in [1]. Your report should be sent in plain-text format to bo...@apache.org with a Subject line that follows the below format: Subject: [REPORT] Project Name Cutting and pasting directly from a Wiki is not acceptable due to formatting issues. Line lengths should be limited to 77 characters. The content should also be committed to the meeting agenda in the board directory in the foundation repository. ASF Board Reports - Reports are due from you for the following committees: - Santuario
[Fwd: [Fwd: ASF Board Report - Initial Reminder for May 2009]]
Heya all, Anyone going to pick this up? Any volunteers for chair? Cheers, Berin Original Message Subject: [Fwd: ASF Board Report - Initial Reminder for May 2009] Date: Mon, 04 May 2009 19:13:46 +1000 From: Berin Lautenbach be...@wingsofhermes.org Reply-To: security-dev@xml.apache.org To: security-dev@xml.apache.org Hey guys, I think I missed the last one of these. I'm not getting a chance to get to these so I am going to look to someone else to step up and take this on. I've mentioned a couple of times I want to step down as chair - this is it guys :). Someone needs to take over the chair position or I guess we apply to the board to have the project moved to the attic. Cheers, Berin Original Message Subject: ASF Board Report - Initial Reminder for May 2009 Date: 1 May 2009 00:50:05 - From: ASF Board bo...@apache.org To: Berin Lautenbach blaut...@apache.org This email was sent by an automated system on behalf of the ASF Board. It is an initial reminder to give you plenty of time to prepare the report. The meeting is scheduled for Wed, 20 May 2009, 10 am PST and the deadline for submitting your report is two full days prior to that! According to board records, you are listed as the chair of at least one committee that is due to submit a report this month. [1] [2] Details on which project reports are due and how to submit a report are enclosed below. Please submit your report with sufficient time to allow the board members to review and digest. Again, the very latest you should submit your report is two full days (48h) prior to the board meeting. The exact date of the board meeting can be found in the calendar.txt file in the board directory of the committers repository [2]. If you feel that an error has been made, please consult [1] and if there is still an issue then contact the board directly. Thanks, The ASF Board [1] - https://svn.apache.org/repos/private/committers/board/committee-info.txt [2] - https://svn.apache.org/repos/private/committers/board/calendar.txt Submitting your Report -- Full details about the process and schedule are in [1]. Your report should be sent in plain-text format to bo...@apache.org with a Subject line that follows the below format: Subject: [REPORT] Project Name Cutting and pasting directly from a Wiki is not acceptable due to formatting issues. Line lengths should be limited to 77 characters. The content should also be committed to the meeting agenda in the board directory in the foundation repository. ASF Board Reports - Reports are due from you for the following committees: - Santuario
[Fwd: ASF Board Report - Initial Reminder for May 2009]
Hey guys, I think I missed the last one of these. I'm not getting a chance to get to these so I am going to look to someone else to step up and take this on. I've mentioned a couple of times I want to step down as chair - this is it guys :). Someone needs to take over the chair position or I guess we apply to the board to have the project moved to the attic. Cheers, Berin Original Message Subject: ASF Board Report - Initial Reminder for May 2009 Date: 1 May 2009 00:50:05 - From: ASF Board bo...@apache.org To: Berin Lautenbach blaut...@apache.org This email was sent by an automated system on behalf of the ASF Board. It is an initial reminder to give you plenty of time to prepare the report. The meeting is scheduled for Wed, 20 May 2009, 10 am PST and the deadline for submitting your report is two full days prior to that! According to board records, you are listed as the chair of at least one committee that is due to submit a report this month. [1] [2] Details on which project reports are due and how to submit a report are enclosed below. Please submit your report with sufficient time to allow the board members to review and digest. Again, the very latest you should submit your report is two full days (48h) prior to the board meeting. The exact date of the board meeting can be found in the calendar.txt file in the board directory of the committers repository [2]. If you feel that an error has been made, please consult [1] and if there is still an issue then contact the board directly. Thanks, The ASF Board [1] - https://svn.apache.org/repos/private/committers/board/committee-info.txt [2] - https://svn.apache.org/repos/private/committers/board/calendar.txt Submitting your Report -- Full details about the process and schedule are in [1]. Your report should be sent in plain-text format to bo...@apache.org with a Subject line that follows the below format: Subject: [REPORT] Project Name Cutting and pasting directly from a Wiki is not acceptable due to formatting issues. Line lengths should be limited to 77 characters. The content should also be committed to the meeting agenda in the board directory in the foundation repository. ASF Board Reports - Reports are due from you for the following committees: - Santuario
Taking on the PMC Chair role
Hi all, The time has come for me to hand the chair role over to someone else - my involvement in the project has been almost nil for the past 12 months and I think it's inappropriate that someone with that little involvement be chairing the project as a whole. Looking for volunteers and then we will vote. As an aside - we need someone for this - it is a requirement of being an ASF project. I will be standing down, so we really need someone to step forward - but it must be someone with current commit access. Cheers, Berin
Board Update
Hi all, Very quickly - I just realised I need to do the update to the board. Aything of importance from the last 3 months that I need to put in there? We are working towards a 1.4.2 release, but anything else? Cheers, Berin
Re: Java XMLSec 1.4.2 Release
+1 - but can we add the verbage we need to add for the crypto policy? Cheers, Berin Sean Mullan wrote: Hi all, It has been almost a year since 1.4.1 was released, and many bugs and rfes have been fixed and integrated since then. Therefore, I would like to make a 1.4.2 release available soon, and have at least one or two beta candidate releases before doing that. Please let me know if you are ok with this plan: [ ] +1 [ ] 0 [ ] -1 If -1, please explain why (such as I really need a fix for bug ). FYI, here are the bugs and rfes that have been fixed since 1.4.1: Fixed rfe 42653: Add support for C14N 1.1 to Java implementation. Fixed bug 44205: XMLX509Certificate.getX509Certificate() results in certificate parsing error. Fixed Bug 44177: when using xslt transformation there is problem with xalan newline. Small refactor for ElementProxy to get rid of the state, it was an old vestige that where taking space and obfuscating the code. Fixed bug 40897: String comparisons using '==' causes validation errors with some parsers. Fixed bug 43056: Library does not allow specify provider for private key operations. Fixed bug 44102: XMLCipher loadEncryptedKey error. Fixed bug 43239: No installed provider supports this key when checking a RSA signature against a DSA key before RSA key. Fixed bug 42597: Unnecessary namespace declarations on Signature children. Fixed bug 42061: Method to disable XMLUtils.addReturnToElement. Fixed bug 42865: Problem with empty BaseURI in ResolverLocalFilesystem. Fixed bug 43230: Inclusive C14n doesn't always handle xml:space xml:lang attributes correctly Fixed bug 38668: Add XMLCipher.encryptData method that takes serialized data as parameter. Fixed bug 42866: Error when removing encrypted content in 1.4.1. Fixed bug 42820: ClassLoader issue causing NoSuchAlgorithmException loading Provider Implementation. Thanks, Sean
Nov board report
Hi all, My apologies - I have almost no time at all to put together the quarterly board report. I never got the reminder that I've received in the past, and then just generally dropped the ball. Any major hilights? I'll post something to the board list tomorrow. Cheers, Berin
Re: XML Security C++: Incomplete cleanup in XSECC14n20010315 destructor
Hmm. That's an interesting one. Have you seen a case where the
mp_attributes list is not already clear when the destructor is called?
I can see how it could occur if the canonicalisation gets interrupted in
the midst of outputting Attribute nodes. This fix would work nicely,
and I think it should be safe as the code that normally cleans up
ensures mp_attributes is NULL, so it won't get called unnecessarily.
Cheers,
Berin
Vitaly Prapirny wrote:
Hi!
XSECC14n20010315 destructor performs delete [] m_exclNSList[i] but
m_exclNSList items was allocated with strdup and must be released
with free(). And mp_attributes cleanup is absent in code. So I
propose this version of destructor:
XSECC14n20010315::~XSECC14n20010315() {
if (mp_formatter != NULL)
delete mp_formatter;
// Clear out the exclusive namespace list
int size = (int) m_exclNSList.size();
for (int i = 0; i size; ++i) {
free(m_exclNSList[i]);
}
m_exclNSList.clear();
while (mp_attributes != NULL) {
mp_currentAttribute = mp_attributes-next;
delete mp_attributes;
mp_attributes = mp_currentAttribute;
}
mp_attributes = mp_currentAttribute = mp_firstNonNsAttribute = NULL;
}
Good luck!
Vitaly
Re: [VOTE] Put Apache Juice into dormant status
Hiya, Nobody on the project has the bandwidth at the moment to take this on, so +1 to put it dormant. If the bandwidth becomes available we will re-open. Cheers, Berin Noel J. Bergman wrote: Berin Lautenbach wrote: I have forwarded into the santuario dev list to see what people want to do. My feeling is dormant is a good thing for now. OK. Let us know. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: [VOTE] Put Apache Juice into dormant status]
I'll leave this another 24 hours, and then if nobody objects I'll +1 the vote to hibernate. If we want to resurrect the idea when someone has the bandwidth we can. Cheers, Berin Berin Lautenbach wrote: Note that this won't kill JuiCE, just hibernate it until such time as someone comes along to reopen it, or fork it in another location. Cheers, Berin Werner Dittmann wrote: Berin, all, just a few days ago I got an e-mail from OSSI (this organization prepared and drove the FIPS certification for openSSL) asking us if somebody would can improve JuiCE to have it FIPS certified as well. As far as I understood JuICE is often used by US administration because it is a Java JCE compliant interface to openSSL. Pls have a look to the latest e-mail conversation. If anbbody with some know-how would like to volounteer pls get in contace with Steve ([EMAIL PROTECTED]) and myself. This I would ask to keep JuICE until this issue is sorted out. Regards, Werner quote Steve, unfortunatly I'm not able to do this completely on my own. JuiCE and other Open source acivities are just a hobby of mine and I do it in parallel to my normal job. I would appreciate if somebody else can take over the main activities. Of course I would be happy to support the person who takes the burden to enable JuiCE to be FIPS compliant. Coordination could be done via e-mail or VoIP calls, depending on the time zone of the participating persons :-) . And yes: http://svn.apache.org/viewvc/incubator/juice/ is the latest version of the source. Regards, Werner Steve Marquess wrote: Steve Marquess wrote: Werner: One of the activities that occupies much of our time here at OSSI is matching up the needs of commercial and government entities with the appropriate resources in the open source community. Usually the sponsor requirements are pretty clear cut (obtain FIPS 140-2 validation for X, add support for platform Y to product Z, etc.). This situation is a little different in that the prospective sponsor, a large U.S. government research laboratory, appears to just want JuiCE to be a viable actively maintained product. Apparently they want to use it extensively but are concerned about the lack of activity and unpolished state. Here specifically is what my contact there asked for: Besides work on supporting FIPS mode, I'd like to see money put towards more documentation, tutorials, and a more collaborative project home page to attract wider adoption. The only actual functional enhancement they're asking for, FIPS mode support, is relatively simple, as most a few day's work. This contact went on to ask me to write a Statement of Work (SOW, a description of tasks to be performed for specified payment) which would be the basis for a contract. If you're interested, here's how we can work it. If you can give me some details along the following lines... 1) Cost to implement FIPS mode support (see http://www.openssl.org/docs/fips/UserGuide-1.1.1.pdf for details, it can be as simple as adding a FIPS_mode_set() call. 2) Some elaboration on the documentation, tutorials objective, and what you and/or your collaborators would expect to be paid for same; 3) Brief description of what the project home page would look like; ok to just reference an existing project as a model, and cost to implement; 4) Any other enhancements that have been contemplated that would be of interest to the general end user community, and cost for same ...then I will prepare a formal proposal for our prospective sponsor and see what funding they will commit to. Note we can host the project web site on OSSI hardware, if appropriate, but are not in a position to generate or maintain much content. For funding think in terms of thousands of dollars (or euros), not hundreds. I believe that if they feel they are receiving value that they would be willing to fund this effort on a long term basis to the tune of thousands or even tens of thousands per year. We won't know for sure until they are presented with a formal contract, of course, and there will undoubtedly be some back-and-forth negotiation. As many project contributors or collaborators can contribute as appropriate. We prefer to work with a projects original contributors and their circle of collaborators where possible. We'll want a single point of contact with OSSI, but end results that please the sponsor are all that really matters. Speaking of which, I don't want to step on any toes at Apache. If we do succeed in securing financial support for JuiCE we would not want to disturb the relationship with the Apache Incubator. Is there anyone at Apache I should sound out for permission/participation? OSSI has not had the opportunity to work with the ASF yet, but we expect to in the near future for other initiatives so I don't want to offend anyone there. Oh, I take it that http://svn.apache.org/viewvc/incubator/juice/ is the latest
Re: [Fwd: [VOTE] Put Apache Juice into dormant status]
to secure the funding they have indicated would be forthcoming? If none of the original maintainers are able to participate we can engage Java developers elsewhere, but we'd prefer to work with the original team if at all possible. Thanks, -Steve M. /quote Berin Lautenbach wrote: If we want to keep this going - we need to call it out now. Cheers, Berin Original Message Subject: [VOTE] Put Apache Juice into dormant status Date: Mon, 16 Jul 2007 00:12:13 -0400 From: Noel J. Bergman [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED],[EMAIL PROTECTED] To: [EMAIL PROTECTED] Nothing appears to be happening, and there is no one around to provide status or anything else. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Fwd: [VOTE] Put Apache Juice into dormant status]
If we want to keep this going - we need to call it out now. Cheers, Berin Original Message Subject: [VOTE] Put Apache Juice into dormant status Date: Mon, 16 Jul 2007 00:12:13 -0400 From: Noel J. Bergman [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED],[EMAIL PROTECTED] To: [EMAIL PROTECTED] Nothing appears to be happening, and there is no one around to provide status or anything else. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Namespaces
OK - first up I'm not an expert on the Java library, more on the C++
library.
The two examples you sent through are completely separate - one is for
sig and one encryption. So my guess is that in your situation you could
set the namespace prefix to for the dsig namespace when you are doing
a signature and to for the xenc namespace when you are doing
encryption. I.e. do one or the other - not both. If you need to do
both encryption and signature in one document, I'm not sure whether the
library will let you do that easily. I know you can't have both
namespaces as the default, but maybe you can switch between each other
as the default depending on what you are trying to do.
Hopefully someone else can comment in that case.
As a side note - namespace support is mandatory according to the spec.
What is optional is the use of dsig as the namespace prefix. So in
reality a compliant implementation needs to support the use of a prefix
for the signature and encryption namespaces.
Cheers,
Berin
Eric Tournier wrote:
Hi Berin :)
I hope your baby goes well and let you sleep :)
Was the previously posted XML useful ? I checked the W3 XMLEnc and XMLDSig
references and found that thes two namespaces were optional (§1.3), so could
you help me to configure XMLSecurity classe to produce signed XML without ds:
then produce with this doc a encrypted XML without xenc: ?
Thanks in advance
Eric
-Message d'origine-
De : Berin Lautenbach [mailto:[EMAIL PROTECTED]
Envoyé : mercredi 18 avril 2007 14:05
À : security-dev@xml.apache.org
Objet : Re: Namespaces
Can you post a signature from the implementation you use to
see what it looks like?
Cheers,
Berin
Eric Tournier wrote:
Hi Berin :)
I'm using a home-made XML Encryption implementation but
unfortunately I'm not the developer of it. This
implementation does not support ds: and xenc: prefixes, so I
try not to have them. In order to test interoperability of it
with well-known API, I'm trying to encrypt a XML document
with XML Security and decrypt the result with my
implementation, and vice-versa.
My intent is not to have two different namespaces as the
default namespace for the Signature element, but trying not
to have any of the ds: and xenc: prefix into the final
encrypted then signed XML document : element Signature
instead of ds:Signature and CipherValue instead of
xenc:CipherValue.
Thanks for your help
Eric
-Message d'origine-
De : Berin Lautenbach [mailto:[EMAIL PROTECTED] Envoyé :
mercredi 18 avril 2007 11:36 À :
security-dev@xml.apache.org Objet :
Re: Namespaces
As far as I can see - effectively your trying to have two
different
namespaces as the default namespace for the Signature
element. Which
can't really be done. Or am I misreading your intent?
Why do you not want the namespaces? Both specs exist inside a
specific namespace, so you can't not use them.
Cheers,
Berin
Eric Tournier wrote:
Hi :)
I wish to encrypt then sign a XML document without the
'ds;' and
'xenc:' namespaces. Unfortunately, I can only suppress on
of these
namespaces :| The following code throws
XmlSecurityException always on
the second line independent from its nature
(EncryptionConstants.setEncryptionSpecNSprefixor or
Constants.setSignatureSpecNSprefix) :
(...)
static
{
org.apache.xml.security.Init.init();
JCA.setProvider();
}
public XMLSecurityResource() throws XMLSecurityException
{
// Suppression du namespace 'xenc:'
EncryptionConstants.setEncryptionSpecNSprefix();
// Suppression du namespace 'ds:'
Constants.setSignatureSpecNSprefix();
}
(...)
Could someone tell me how to resolve this ?
Thanks
Eric
Eric TOURNIER
Ingénieur concepteur objet senior - Expertise technique
Java/J2EE/XML/AOP - Spring/Hibernate/Maven
STERIA
Département Banque, Assurance et Finance 46, rue Camille
Desmoulins -
92782 Issy-Les-Moulineaux Cedex 9 Tél : 01 53 94 22 94 -
Mob : 06 17
98 32 51 [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
//
Re: Namespaces
As far as I can see - effectively your trying to have two different
namespaces as the default namespace for the Signature element. Which
can't really be done. Or am I misreading your intent?
Why do you not want the namespaces? Both specs exist inside a specific
namespace, so you can't not use them.
Cheers,
Berin
Eric Tournier wrote:
Hi :)
I wish to encrypt then sign a XML document without the 'ds;' and
'xenc:' namespaces. Unfortunately, I can only suppress on of these
namespaces :| The following code throws XmlSecurityException always on
the second line independent from its nature
(EncryptionConstants.setEncryptionSpecNSprefixor or
Constants.setSignatureSpecNSprefix) :
(...)
static
{
org.apache.xml.security.Init.init();
JCA.setProvider();
}
public XMLSecurityResource() throws XMLSecurityException
{
// Suppression du namespace 'xenc:'
EncryptionConstants.setEncryptionSpecNSprefix();
// Suppression du namespace 'ds:'
Constants.setSignatureSpecNSprefix();
}
(...)
Could someone tell me how to resolve this ?
Thanks
Eric
Eric TOURNIER
Ingénieur concepteur objet senior - Expertise technique
Java/J2EE/XML/AOP - Spring/Hibernate/Maven
STERIA
Département Banque, Assurance et Finance
46, rue Camille Desmoulins - 92782 Issy-Les-Moulineaux Cedex 9
Tél : 01 53 94 22 94 - Mob : 06 17 98 32 51
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
//
Re: Does the XML security package work with Xerces-C v1.6 ?
Hmm. Brain failure. Very sorry :. Of course the current version is 2.7 (not 1.7). I'm assuming you mean 2.6 rather than 1.6? If you really do mean 1.6 then it won't work. It's been a long time (and someone will correct me I'm sure) but 1.6 used a completed different structure for the DOMNode that is incompatible with the 2.x series. If that's the case, then you might want to try compiling up 2.7 as a separate library on your system. The libraries are versioned, so you should actually be able to run them in parallel. I commonly compile the library using specific versions of Xerces, regardless of what is on the system as the default, and you can configure the library that it compiles against using ./configure options. (--with-xerces=) Apologies for the incorrect response the first time around. My excuse is new baby and no sleep! Cheers, Berin Berin Lautenbach wrote: The library has a bunch of #ifdef statements in there for various aspects and will detect the version of Xerces it is working against during the ./configure operation. The general aim has always been to support Xerces N (currently 1.7) and N-1 (currently 1.6). So you should be fine. Cheers, Berin Cliff1016 wrote: Hi All, My supervisor is asking me to implement some functions doing the XML signature. I was thinking about using the Apache XML security library but then my supervisor said that our server has Xerces-C v1.6 installed and I cannot upgrade it since we have lots of old programs depending on it. So, does anybody know if I could use Xerces-C v1.6 or if there is any other work around for this. Your replies will be greatly appreciated. Cliff
New Committer
Hi all, I am pleased to announce that Scott Cantor will be joining us as a committer on the xml-security library, with a focus on the C++ code. Scott has been active on the mailing list for a number of years, providing advice and ideas as well as submitting bugs and feature requests. Welcome aboard! Cheers, Berin
Re: signature elements indent
You need to do your indenting before you sign, which means you can really only indent your own XML prior to attaching the signature node. The library handles the indenting of the Signature elements. Off the top of my head I'm not sure how much control you can have of that for the Java library. For the C++ library you can turn indenting on and off, but when it's on there no way to tell it how to indent. The merlin signature below was all indented before the final signature was made. If you were to change even one space in the indenting, the signature would fail. Cheers, Berin Jorge Martín Cuervo wrote: Hola Raul i understand, but after check the xml files used in the samples i found several like this in merlin directory: ?xml version=1.0 encoding=UTF-8? Signature xmlns=http://www.w3.org/2000/09/xmldsig#; SignedInfo CanonicalizationMethod Algorithm=http://www.w3.org/TR/2001/REC-xml-c14n-20010315; / SignatureMethod Algorithm=http://www.w3.org/2000/09/xmldsig#rsa-sha1; / Reference URI=http://www.w3.org/TR/xml-stylesheet; DigestMethod Algorithm=http://www.w3.org/2000/09/xmldsig#sha1; / DigestValue60NvZvtdTB+7UnlLp/H24p7h4bs=/DigestValue /Reference /SignedInfo SignatureValue KTe1H5Hjp8hwahNFoUqHDuPJNNqhS1U3BBBH5/gByItNIwV18nMiLq4KunzFnOqD xzTuO0/T+wsoYC1xOEuCDxyIujNCaJfLh+rCi5THulnc8KSHHEoPQ+7fA1VjmO31 2iw1iENOi7m//wzKlIHuxZCJ5nvolT21PV6nSE4DHlA= /SignatureValue KeyInfo KeyNameLugh/KeyName /KeyInfo /Signature I seems to be indented, and (i supose) still works. How did Merlin get that signatures? thanks El lun, 12 de 02 de 2007 a las 18:32, Raul Benito escribió: /Hola Jorge, Sorry no luck, If you change the signature it will be void. No matter what books have told, spaces are an important part of the XML. And it means a lot. You cannot change it without changing the signature. Regards, Raul On 12 Feb 2007 12:00:20 +0100, *Jorge Martín Cuervo* //[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: / / Hi all, I want to create a signature inside an xml file, i use several transforms to get a portion of the original xml with xpath, and to canonize. I decided to don't attach the public keys. / /?xml version=1.0 encoding=UTF-8? hr:Candidate xmlns:df=http://defactops.com; xmlns:hr=http://ns.hr-xml.org/2004-08-02; xmlns:xs= http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; hr:CandidateRecordInfo hr:Id hr:IdValue name=id1158138667963/hr:IdValue /hr:Id hr:Id hr:IdValue name=version 0.9.0/hr:IdValue /hr:Id hr:Id hr:IdValue name=model0.9.0/hr:IdValue /hr:Id hr:Id hr:IdValue name=host 127.0.0.1 http://127.0.0.1/hr:IdValue /hr:Id /hr:CandidateRecordInfo hr:CandidateProfile [...] /hr:UserArea HRSignature id=protean-xmldsig-01ds:Signature xmlns:ds= http://www.w3.org/2000/09/xmldsig#; ds:SignedInfo xmlns:ds=http://www.w3.org/2000/09/xmldsig#; ds:CanonicalizationMethod Algorithm=http://www.w3.org/TR/2001/REC-xml-c14n-20010315; xmlns:ds=http://www.w3.org/2000/09/xmldsig#/ ds:SignatureMethod Algorithm= http://www.w3.org/2000/09/xmldsig#dsa-sha1; xmlns:ds= http://www.w3.org/2000/09/xmldsig#/ ds:Reference URI= xmlns:ds=http://www.w3.org/2000/09/xmldsig#; ds:Transforms xmlns:ds=http://www.w3.org/2000/09/xmldsig#; ds:Transform Algorithm= http://www.w3.org/2002/06/xmldsig-filter2; xmlns:ds= http://www.w3.org/2000/09/xmldsig#; dsig-xpath:XPath Filter=intersect xmlns:dsig-xpath= http://www.w3.org/2002/06/xmldsig-filter2;/hr:Candidate/hr:CandidateRecordInfo/dsig-xpath:XPath /ds:Transform ds:Transform Algorithm= http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments; xmlns:ds=http://www.w3.org/2000/09/xmldsig#/ /ds:Transforms ds:DigestMethod Algorithm=http://www.w3.org/2000/09/xmldsig#sha1; xmlns:ds=http://www.w3.org/2000/09/xmldsig#/ ds:DigestValue xmlns:ds= http://www.w3.org/2000/09/xmldsig#;ICBDC9GdWcp8S373I1jlKCilSbI=/ds:DigestValue /ds:Reference /ds:SignedInfo ds:SignatureValue xmlns:ds=http://www.w3.org/2000/09/xmldsig# l0N6Ll3/tlSoBz26QdIHyWMA1D95xcPClBz8oy8y7Oj69QQxTVF9GA==/ds:SignatureValue /ds:Signature/HRSignature/hr:Resume /hr:Candidate/ / It works pretty well, (the sign and the verification process) but, when i indent the whole file, the *Signature* element content is indented too and the validation process fails. is there any way to canonice the Signature element? is this a common problem? how can i solve this? thank you! pd: i'm new in this mailing list, and sorry if this issue was commented before./ -- ;-) Jorge Martin
Re: xquery transforms
There is are XPath and XSLT transforms, but that's as close as the xml-sig spec gets. In theory it should be possible to specify a new transform that uses xquery to extract data from an xml document and then put that data into a form that it could be signed. Is there something you want to do with XQuery that you can't do with XPath or XSLT transforms? Cheers, Berin Jorge Martín Cuervo wrote: is there any way to use xquery in transforms? is this a crazy idea? thanks -- ;-) Jorge Martin Cuervo Analista Programador Outsourcing Emarketplace deFacto Powered by Standards email [EMAIL PROTECTED] voz +34 985 129 820 voz +34 660 026 384
Re: signature elements indent
I'm not sure what can be done in the Java library to control or turn off indenting. Anyone else able to assist? Cheers, Berin Jorge Martín Cuervo wrote: Hi Berin, Maybe for me, a solution would be eliminate all line feeds and carriage returns in the Signature element. So, the xml can be indented and before the validation i can clean up again this LF/CR. is it posible? is there any posibility to configure the API like this? thanks again! El mar, 13 de 02 de 2007 a las 09:32, Berin Lautenbach escribió: /You need to do your indenting before you sign, which means you can really only indent your own XML prior to attaching the signature node. The library handles the indenting of the Signature elements. Off the top of my head I'm not sure how much control you can have of that for the Java library. For the C++ library you can turn indenting on and off, but when it's on there no way to tell it how to indent. The merlin signature below was all indented before the final signature was made. If you were to change even one space in the indenting, the signature would fail. Cheers, Berin Jorge Martín Cuervo wrote: Hola Raul i understand, but after check the xml files used in the samples i found several like this in merlin directory: ?xml version=1.0 encoding=UTF-8? Signature xmlns=//http://www.w3.org/2000/09/xmldsig#; SignedInfo CanonicalizationMethod Algorithm=http://www.w3.org/TR/2001/REC-xml-c14n-20010315; / SignatureMethod Algorithm=http://www.w3.org/2000/09/xmldsig#rsa-sha1; / Reference URI=http://www.w3.org/TR/xml-stylesheet; DigestMethod Algorithm=http://www.w3.org/2000/09/xmldsig#sha1; / DigestValue60NvZvtdTB+7UnlLp/H24p7h4bs=/DigestValue /Reference /SignedInfo SignatureValue KTe1H5Hjp8hwahNFoUqHDuPJNNqhS1U3BBBH5/gByItNIwV18nMiLq4KunzFnOqD xzTuO0/T+wsoYC1xOEuCDxyIujNCaJfLh+rCi5THulnc8KSHHEoPQ+7fA1VjmO31 2iw1iENOi7m//wzKlIHuxZCJ5nvolT21PV6nSE4DHlA= /SignatureValue KeyInfo KeyNameLugh/KeyName /KeyInfo /Signature I seems to be indented, and (i supose) still works. How did Merlin get that signatures? thanks El lun, 12 de 02 de 2007 a las 18:32, Raul Benito escribió: /Hola Jorge, Sorry no luck, If you change the signature it will be void. No matter what books have told, spaces are an important part of the XML. And it means a lot. You cannot change it without changing the signature. Regards, Raul On 12 Feb 2007 12:00:20 +0100, *Jorge Martín Cuervo* //[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: / / Hi all, I want to create a signature inside an xml file, i use several transforms to get a portion of the original xml with xpath, and to canonize. I decided to don't attach the public keys. / /?xml version=1.0 encoding=UTF-8? hr:Candidate xmlns:df=http://defactops.com; xmlns:hr=http://ns.hr-xml.org/2004-08-02; xmlns:xs= http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; hr:CandidateRecordInfo hr:Id hr:IdValue name=id1158138667963/hr:IdValue /hr:Id hr:Id hr:IdValue name=version 0.9.0/hr:IdValue /hr:Id hr:Id hr:IdValue name=model0.9.0/hr:IdValue /hr:Id hr:Id hr:IdValue name=host 127.0.0.1 http://127.0.0.1/hr:IdValue http://127.0.0.1/hr:IdValue /hr:Id /hr:CandidateRecordInfo hr:CandidateProfile [...] /hr:UserArea HRSignature id=protean-xmldsig-01ds:Signature xmlns:ds= http://www.w3.org/2000/09/xmldsig#; ds:SignedInfo xmlns:ds=http://www.w3.org/2000/09/xmldsig#; ds:CanonicalizationMethod Algorithm=http://www.w3.org/TR/2001/REC-xml-c14n-20010315; xmlns:ds=http://www.w3.org/2000/09/xmldsig#/ ds:SignatureMethod Algorithm= http://www.w3.org/2000/09/xmldsig#dsa-sha1; xmlns:ds= http://www.w3.org/2000/09/xmldsig#/ ds:Reference URI= xmlns:ds=http://www.w3.org/2000/09/xmldsig#; ds:Transforms xmlns:ds=http://www.w3.org/2000/09/xmldsig#; ds:Transform Algorithm= http://www.w3.org/2002/06/xmldsig-filter2; xmlns:ds= http://www.w3.org/2000/09/xmldsig#; dsig-xpath:XPath Filter=intersect xmlns:dsig-xpath= http://www.w3.org/2002/06/xmldsig-filter2;/hr:Candidate/hr:CandidateRecordInfo/dsig-xpath:XPath /ds:Transform ds:Transform Algorithm= http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments; xmlns:ds=http://www.w3.org/2000/09/xmldsig#/ /ds:Transforms ds:DigestMethod Algorithm=http://www.w3.org/2000/09/xmldsig#sha1; xmlns:ds=http://www.w3.org/2000/09/xmldsig#/ ds:DigestValue xmlns:ds= http://www.w3.org/2000/09/xmldsig#;ICBDC9GdWcp8S373I1jlKCilSbI=/ds:DigestValue /ds:Reference /ds:SignedInfo ds:SignatureValue xmlns:ds=http://www.w3.org
Re: C++ 1.3.1 release archive
Cool! I will update the site later this week. Cheers, Berin Scott Cantor wrote: Is in http://xml.apache.org/security/dist/c-library I'll update the site later in the week - give people a chance to check the new build process before I release fully. So far it's working for me on Windows and Solaris 2.8, so I'd say it's good to go. -- Scott
Re: problems with configure
Paul Cameron wrote: BTW, if the API binaries on nagoya.apache.org were accessible, it would make my life a lot easier. Do you know what's wrong with this site? Nagoya is no longer available. I'll remove that link from the site until I can figure out another place I can generate the API docs. Cheers, Berin
Re: Error allocating memory
Can you send me a copy of the signature XML that you are verifying? The -x kicks in the interop resolver. But it should definitely not give an out of mem error. Cheers, Berin Travis Reid wrote: I am currently using the xml-security-c 1.3.1 library to check a signature I created using the java xml security library. I have built the library without xalan-support. I have references ( relative URI's) in a manifest object of the signature. I am expecting to write my own resolver to resolve these references for the signature to be valid. When I run the 'checksig -x sig.xml' tool included with the library, I would expect to get an error stating it couldn't resolve the reference. Instead I get An error occured during signature verification Message: Error allocating memory If I run 'checksig -s sig.xml' the signature is valid. Any ideas what is causing this error?
C++ 1.3.1 release archive
Is in http://xml.apache.org/security/dist/c-library I'll update the site later in the week - give people a chance to check the new build process before I release fully. Cheers, Berin
Re: interop problem java to C++
Sorry - I've not been close to email lately :. Does the code in SVN fix the problem? If not - let me know, and if you can provide a test signature as a separate file that should validate but which doesn't and I'll look see if I can track it down. Cheers, Berin Bradley Beddoes wrote: Hi, Seems my suspicions were correct it was a c14n issue. I just found this post from Scott, http://mail-archives.apache.org/mod_mbox/xml-security-dev/200610.mbox/[EMAIL PROTECTED] With my few small tests tonight (I intend to thrash it out more in the morning) it seems to have also corrected my issues. regards, Bradley Bradley Beddoes wrote: Bradley Beddoes wrote: After more investigation I found a few problems with my usage of Xerces and also some issues with the JAXP validator which I have now stopped using which were causing problems with root node signatures. Verification of a signature at the root node is now successful in both C++ and Java, Just in case this wasn't 100% clear a signature on the root node is successful with or without additional enveloped signatures on child nodes in both languages. however embedded enveloped signatures continue to fail with incorrect references. (The documents however still fully validate in the language they were created in) Additionally an embedded sig reference will fail even when it is not wrapped inside a root node signature and there is definitely no base64 content present in my current test documents regular child nodes. I intend to do some more work tomorrow I am currently suspicious of c14n inconsistencies, but I thought I might ask if anyone may have any suggestions for other areas I should perhaps be looking at so I don't waste a lot of time I don't really have. regards, Bradley Scott Cantor wrote: The problem of invalid references arises in xmlsec-c code base when either a document has a single signature whose reference URI is some child node of the document or when the root node has a signature AND some child node of the document has a signature. (Validation with xerces 2.7 always comes out correct) If you're validating, that might be your problem, but most of the issues around that were fixed in Xerces-C 2.7. Earlier versions would require that you disable data type normalization, and that would break any nested signature cases where you were signing base-64. But I would try disabling validation and make sure that's not involved. Otherwise, what you want to do is actually get a trace of the octet string being digested in C++ and compare that XML to what you think the c14n should produce. -- Scott
Re: interop problem java to C++
I was hoping to do it on the weekend just gone past. If all goes well - this weekend. Cheers, Berin Bradley Beddoes wrote: Hi Berin, Yes confirmed to solve the problem with the latest svn code. Any rough eta on 1.3.1 official release yet? bradley
[Fwd: RE: Last Call for C14N 1.1 (and updated WG notes)]
Anyone looked at this? Original Message Subject: RE: Last Call for C14N 1.1 (and updated WG notes) Resent-Date: Thu, 21 Dec 2006 19:34:15 + Resent-From: w3c-ietf-xmldsig@w3.org Date: Thu, 21 Dec 2006 14:33:49 -0500 From: Grosso, Paul [EMAIL PROTECTED] To: w3c-ietf-xmldsig@w3.org,[EMAIL PROTECTED] Some information about changes to the latest versions: Canonical XML 1.1 - The *First* Public Working Draft of C14N 1.1 available at http://www.w3.org/TR/2006/WD-xml-c14n11-20060915/ was marked up to show the changes between C14N 1.0 and that first public WD of C14N 1.1. I have just made available a version showing the changes between the First Public Working Draft of C14N 1.1 and this Last Call Working Draft of C14N 1.1 at http://www.w3.org/XML/Group/2006/12/WD-xml-c14n11-20061220-review.html (member only) which I soon hope to have also available at http://www.w3.org/XML/2006/12/WD-xml-c14n11-20061220-review.html (publicly accessible) as soon as someone with permissions can do that. Known Issues with Canonical XML 1.0 (C14N/1.0) -- There were no substantive changes between the first WD at http://www.w3.org/TR/2006/WD-C14N-issues-20060915/ and this latest version other than formatting it as a WG Note. Using XML Digital Signatures in the 2006 XML Environment There were no substantive changes between the first WD at http://www.w3.org/TR/2006/WD-DSig-usage-20060915/ and this latest version. The editorial changes were: - clarifying that it's just a note - changing the URI proposed for C14N-1.1 to www.w3.org/2006/12/xml-c14n11 paul -Original Message- From: Grosso, Paul Sent: Wednesday, 2006 December 20 11:23 To: 'w3c-ietf-xmldsig@w3.org'; '[EMAIL PROTECTED]' Subject: Last Call for C14N 1.1 (and updated WG notes) The XML Core WG announces the publication of and requests review of the Last Call WD of: Canonical XML 1.1 - This version: http://www.w3.org/TR/2006/WD-xml-c14n11-20061220 Latest version: http://www.w3.org/TR/xml-c14n11 Also published at this time are the following related Working Group Notes: Known Issues with Canonical XML 1.0 (C14N/1.0) -- This version: http://www.w3.org/TR/2006/NOTE-C14N-issues-20061220/ Latest version: http://www.w3.org/TR/C14N-issues/ Using XML Digital Signatures in the 2006 XML Environment This version: http://www.w3.org/TR/2006/NOTE-DSig-usage-20061220/ Latest version: http://www.w3.org/TR/DSig-usage/
Re: VOTE C++ 1.3.1 release
Hi all - so far it's Dims and me. I need one more to make it official Cheers, Berin Davanum Srinivas wrote: +1 On 11/19/06, Berin Lautenbach [EMAIL PROTECTED] wrote: Hi all, I want to do a cut of the C++ library with the new build process and bug fixes. Please vote one way or t'other! +1 from me. Cheers, Berin Berin Lautenbach wrote: Scott Cantor wrote: Oh, and it *installs* clean on Solaris, finally (thank you!) GRIN. I'm glad - it was one of the main drivers for doing the conversion! Thanks for testing. Cheers, Berin
VOTE C++ 1.3.1 release
Hi all, I want to do a cut of the C++ library with the new build process and bug fixes. Please vote one way or t'other! +1 from me. Cheers, Berin Berin Lautenbach wrote: Scott Cantor wrote: Oh, and it *installs* clean on Solaris, finally (thank you!) GRIN. I'm glad - it was one of the main drivers for doing the conversion! Thanks for testing. Cheers, Berin
Re: DO NOT REPLY [Bug 40921] - XML X509Certificate contents modified and signature normallly validated.
Scott Cantor wrote: So out of curiosity, how does one verify the Signature/KeyInfo match up in the JDK 1.6 code? I don't think that's how I would approach the question. In all cases, I think the application needs to supply the verification key. The application MAY choose to examine KeyInfo as part of determining what key to try, but that's up to it. In that light, KeyInfo is simply one of many inputs into the process of determining the key. The critical difference is that in my mind, you start by identifying the signer, usually based on the message itself, not based on KeyInfo. From there, you get keying material, or policy to control certificates that might be in KeyInfo. +1. I cannot think of any case where I would trust a message purely because *the message* told me it was OK. That's effectively what you do if you base a trust decision on a key info element. The KeyInfo is like the keyid for a PGP/GPG signed message. It's a pointer into your own keyring (or key management approach - whatever) that lets *you* make a decision based on something outside the message as to whether the message is signed by someone you know. And FWIW - the match between key info and signature is trivial. If the key that you determine from the keyinfo validates the signature then it matches. Otherwise it doesn't. Incorporating the keyinfo into the signed information tells you precisely nothing - if someone has inserted their own key into KeyInfo, then they can obviously re-sign the message and send it to you in its new form. So putting the KeyInfo inside the signature tells you nothing about the validity of the key. Given that fact - it would actually be dangerous for the spec to do it by default as it would give a false sense of security to end users. The key info is included in the signature and the signature verified, therefore the key is correct. Badness. Cheers, Berin
C++ 1.3.1-rc2
Hi all, For those that are interested - rc2 is in the directory, with the Solaris build issues rectified. Cheers, Berin
Re: C++ 1.3.1-rc2
Should have said what directory! http://people.apache.org/~blautenb Cheers, Berin Berin Lautenbach wrote: Hi all, For those that are interested - rc2 is in the directory, with the Solaris build issues rectified. Cheers, Berin
Re: C++ 1.3.1-RC1
Hi all, I will be doing a 1.3.1 release this weekend - so let me know if you find any problems with the rc-1 build! Cheers, Berin Berin Lautenbach wrote: Hiya, For those interested in the C++ library there is a release candidate for 1.3.1 in http://people.apache.org/~blautenb Includes - NIX build now based on Automake (aimed at making it more robust) - Initial support for the Xerces 3.0 codebase (not official, as 3.0 is not yet released) - Bug fixes Please try it out and let me know how it builds and runs. Cheers, Berin
C++ 1.3.1-RC1
Hiya, For those interested in the C++ library there is a release candidate for 1.3.1 in http://people.apache.org/~blautenb Includes - NIX build now based on Automake (aimed at making it more robust) - Initial support for the Xerces 3.0 codebase (not official, as 3.0 is not yet released) - Bug fixes Please try it out and let me know how it builds and runs. Cheers, Berin
Re: Possible signature verify bug?
Scott Cantor wrote: If you mean the XML itself, you're welcome to that, and it shouldn't be that difficult to write a small test to just verify the signature in it. Yup - just the XML. I have a simple harness that takes standalone XML signature/encryption files and then calls the appropriate tool to validate or decrypt the file. And many thanks! Cheers, Berin
Re: Possible signature verify bug?
That definitely looks wrong. I will take a look. It's very wierd - this is straight excl c14n and a very simple case. It's exactly the sort of thing the basic test cases look at. Cheers, Berin Scott Cantor wrote: Berin, I think there's a really blatant bug in the C++ c14n code that's running during signature verification. I think I only missed it before because I had so much defensive code in place to output namespaces. I had a bug in my new code that caused a namespace to be left off because the parent declared it, and stumbled on to this test case. I ran it through a vanilla test case that just parses the DOM and verifies the signature, and the Reference isn't digesting properly. When I debugged it, the bytes fed into the hash were missing a namespace declaration that should have been pulled in from the parent of the node being referenced. I've attached the test case, which is a nested SAML message with the signature on the second-level element. What's happening is that I have this declared (edited for brevity): samlp:ArtifactResponse xmlns:samlp=... samlp:Response xmlns:saml=... saml:Issuer saml:Assertion ... The signature references the samlp:Response by ID. The bug is that the transform chain produces this: samlp:Response saml:Issuer xmlns:saml=... saml:Assertion xmlns:saml=... As you can see, xmlns:samlp isn't included from the parent/root element. I think it should be, even though the reference is being transformed with exclusive c14n. It's visibly used by the Response element, and so it should get pulled in from the enclosing node. If I parse the DOM with that namespace declaration manually added, the signature verifies, which tells me that's the missing piece. The document I attached verifies with the Java xmlsec code from what I can tell. Oxygen is ok with it, anyway. I haven't done any tests of the c14n engine by itself to produce test output, but I would assume that's where the bug is. -- Scott samlp:ArtifactResponse xmlns:samlp=urn:oasis:names:tc:SAML:2.0:protocol ID=_e5e553f51fe1a009374bdf2186a685d8 IssueInstant=2006-10-11T03:12:59Z Version=2.0samlp:Statussamlp:StatusCode Value=urn:oasis:names:tc:SAML:2.0:status:Success//samlp:Statussamlp:Response Destination=https://sp.example.org/SAML/POST; ID=rident IssueInstant=1970-01-02T01:01:02.100Z Version=2.0 xmlns:saml=urn:oasis:names:tc:SAML:2.0:assertionsaml:Issuerhttps://idp.example.org//saml:Issuerds:Signature xmlns:ds=http://www.w3.org/2000/09/xmldsig#; ds:SignedInfo ds:CanonicalizationMethod Algorithm=http://www.w3.org/2001/10/xml-exc-c14n#/ ds:SignatureMethod Algorithm=http://www.w3.org/2000/09/xmldsig#rsa-sha1/ ds:Reference URI=#rident ds:Transforms ds:Transform Algorithm=http://www.w3.org/2000/09/xmldsig#enveloped-signature/ ds:Transform Algorithm=http://www.w3.org/2001/10/xml-exc-c14n#/ /ds:Transforms ds:DigestMethod Algorithm=http://www.w3.org/2000/09/xmldsig#sha1/ ds:DigestValueU562AIbwQ8i5kQcxOjTfYAsqbOs=/ds:DigestValue /ds:Reference /ds:SignedInfo ds:SignatureValuen5AGrOWy1WkZWaIVrXlr1iBeZ8YsGJLHsS+n472wmFxHn/GT8PsCDS78UjpIFVxY qK4G3O5p7rQwe8IGYeWeG3pjclvXcP6KH1CwjlJL3ndaZqu1tVdYqx3fbTAK5QRV gDUlyje2TRAgF1YSyyunRmJgOEXJ+JTe8brCmTrkr0E=/ds:SignatureValue ds:KeyInfods:X509Datads:X509CertificateMIICjzCCAfigAwIBAgIJAKk8t1hYcMkhMA0GCSqGSIb3DQEBBAUAMDoxCzAJBgNV BAYTAlVTMRIwEAYDVQQKEwlJbnRlcm5ldDIxFzAVBgNVBAMTDnNwLmV4YW1wbGUu b3JnMB4XDTA1MDYyMDE1NDgzNFoXDTMyMTEwNTE1NDgzNFowOjELMAkGA1UEBhMC VVMxEjAQBgNVBAoTCUludGVybmV0MjEXMBUGA1UEAxMOc3AuZXhhbXBsZS5vcmcw gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANlZ1L1mKzYbUVKiMQLhZlfGDyYa /jjCiaXP0WhLNgvJpOTeajvsrApYNnFX5MLNzuC3NeQIjXUNLN2Yo2MCSthBIOL5 qE5dka4z9W9zytoflW1LmJ8vXpx8Ay/meG4z//J5iCpYVEquA0xl28HUIlownZUF 7w7bx0cF/02qrR23AgMBAAGjgZwwgZkwHQYDVR0OBBYEFJZiO1qsyAyc3HwMlL9p JpN6fbGwMGoGA1UdIwRjMGGAFJZiO1qsyAyc3HwMlL9pJpN6fbGwoT6kPDA6MQsw CQYDVQQGEwJVUzESMBAGA1UEChMJSW50ZXJuZXQyMRcwFQYDVQQDEw5zcC5leGFt cGxlLm9yZ4IJAKk8t1hYcMkhMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEEBQAD gYEAMFq/UeSQyngE0GpZueyD2UW0M358uhseYOgGEIfm+qXIFQF6MYwNoX7WFzhC LJZ2E6mEvZZFHCHUtl7mGDvsRwgZ85YCtRbvleEpqfgNQToto9pLYe+X6vvH9Z6p gmYsTmak+kxO93JprrOd9xp8aZPMEprL7VCdrhbZEfyYER0=/ds:X509Certificate/ds:X509Data/ds:KeyInfo/ds:Signaturesamlp:Statussamlp:StatusCode Value=urn:oasis:names:tc:SAML:2.0:status:Success//samlp:Statussaml:Assertion ID=aident IssueInstant=1970-01-02T01:01:02.100Z Version=2.0saml:Issuerhttps://idp.example.org//saml:Issuersaml:Subjectsaml:NameIDJohn Doe/saml:NameID/saml:Subjectsaml:AuthnStatement AuthnInstant=1970-01-02T01:01:02.100Zsaml:AuthnContextsaml:AuthnContextClassReffoo/saml:AuthnContextClassRef/saml:AuthnContext/saml:AuthnStatement/saml:Assertion/samlp:Response/samlp:ArtifactResponse
Re: Possible signature verify bug?
Scott, Very interesting. The issue is because you take an identifier (essentially a document subset) and then apply an envelope transform. In dsig terms that means there is an intersection of two nodesets, so the XPath handling kicks in within the canonicaliser. Unfortunately, there was a bug in the way the envelope transform built its input nodeset from the document fragment. By definition, namespace nodes promulgate from where they are defined into each child element etc. DOM doesn't do that - it's a continual bugbear. So in XPath terms, the namespace node that is in question *is* defined in the input document fragment - even though in DOM terms it's defined earlier in the document. That's probably not explained it well - suffice to say the attached patch will add ancestor namespaces into the XPath nodeset that is handled by the canonicaliser. Cheers, Berin Scott Cantor wrote: Berin, I think there's a really blatant bug in the C++ c14n code that's running during signature verification. I think I only missed it before because I had so much defensive code in place to output namespaces. I had a bug in my new code that caused a namespace to be left off because the parent declared it, and stumbled on to this test case. I ran it through a vanilla test case that just parses the DOM and verifies the signature, and the Reference isn't digesting properly. When I debugged it, the bytes fed into the hash were missing a namespace declaration that should have been pulled in from the parent of the node being referenced. I've attached the test case, which is a nested SAML message with the signature on the second-level element. What's happening is that I have this declared (edited for brevity): samlp:ArtifactResponse xmlns:samlp=... samlp:Response xmlns:saml=... saml:Issuer saml:Assertion ... The signature references the samlp:Response by ID. The bug is that the transform chain produces this: samlp:Response saml:Issuer xmlns:saml=... saml:Assertion xmlns:saml=... As you can see, xmlns:samlp isn't included from the parent/root element. I think it should be, even though the reference is being transformed with exclusive c14n. It's visibly used by the Response element, and so it should get pulled in from the enclosing node. If I parse the DOM with that namespace declaration manually added, the signature verifies, which tells me that's the missing piece. The document I attached verifies with the Java xmlsec code from what I can tell. Oxygen is ok with it, anyway. I haven't done any tests of the c14n engine by itself to produce test output, but I would assume that's where the bug is. -- Scott samlp:ArtifactResponse xmlns:samlp=urn:oasis:names:tc:SAML:2.0:protocol ID=_e5e553f51fe1a009374bdf2186a685d8 IssueInstant=2006-10-11T03:12:59Z Version=2.0samlp:Statussamlp:StatusCode Value=urn:oasis:names:tc:SAML:2.0:status:Success//samlp:Statussamlp:Response Destination=https://sp.example.org/SAML/POST; ID=rident IssueInstant=1970-01-02T01:01:02.100Z Version=2.0 xmlns:saml=urn:oasis:names:tc:SAML:2.0:assertionsaml:Issuerhttps://idp.example.org//saml:Issuerds:Signature xmlns:ds=http://www.w3.org/2000/09/xmldsig#; ds:SignedInfo ds:CanonicalizationMethod Algorithm=http://www.w3.org/2001/10/xml-exc-c14n#/ ds:SignatureMethod Algorithm=http://www.w3.org/2000/09/xmldsig#rsa-sha1/ ds:Reference URI=#rident ds:Transforms ds:Transform Algorithm=http://www.w3.org/2000/09/xmldsig#enveloped-signature/ ds:Transform Algorithm=http://www.w3.org/2001/10/xml-exc-c14n#/ /ds:Transforms ds:DigestMethod Algorithm=http://www.w3.org/2000/09/xmldsig#sha1/ ds:DigestValueU562AIbwQ8i5kQcxOjTfYAsqbOs=/ds:DigestValue /ds:Reference /ds:SignedInfo ds:SignatureValuen5AGrOWy1WkZWaIVrXlr1iBeZ8YsGJLHsS+n472wmFxHn/GT8PsCDS78UjpIFVxY qK4G3O5p7rQwe8IGYeWeG3pjclvXcP6KH1CwjlJL3ndaZqu1tVdYqx3fbTAK5QRV gDUlyje2TRAgF1YSyyunRmJgOEXJ+JTe8brCmTrkr0E=/ds:SignatureValue ds:KeyInfods:X509Datads:X509CertificateMIICjzCCAfigAwIBAgIJAKk8t1hYcMkhMA0GCSqGSIb3DQEBBAUAMDoxCzAJBgNV BAYTAlVTMRIwEAYDVQQKEwlJbnRlcm5ldDIxFzAVBgNVBAMTDnNwLmV4YW1wbGUu b3JnMB4XDTA1MDYyMDE1NDgzNFoXDTMyMTEwNTE1NDgzNFowOjELMAkGA1UEBhMC VVMxEjAQBgNVBAoTCUludGVybmV0MjEXMBUGA1UEAxMOc3AuZXhhbXBsZS5vcmcw gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANlZ1L1mKzYbUVKiMQLhZlfGDyYa /jjCiaXP0WhLNgvJpOTeajvsrApYNnFX5MLNzuC3NeQIjXUNLN2Yo2MCSthBIOL5 qE5dka4z9W9zytoflW1LmJ8vXpx8Ay/meG4z//J5iCpYVEquA0xl28HUIlownZUF 7w7bx0cF/02qrR23AgMBAAGjgZwwgZkwHQYDVR0OBBYEFJZiO1qsyAyc3HwMlL9p JpN6fbGwMGoGA1UdIwRjMGGAFJZiO1qsyAyc3HwMlL9pJpN6fbGwoT6kPDA6MQsw CQYDVQQGEwJVUzESMBAGA1UEChMJSW50ZXJuZXQyMRcwFQYDVQQDEw5zcC5leGFt cGxlLm9yZ4IJAKk8t1hYcMkhMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEEBQAD gYEAMFq/UeSQyngE0GpZueyD2UW0M358uhseYOgGEIfm+qXIFQF6MYwNoX7WFzhC LJZ2E6mEvZZFHCHUtl7mGDvsRwgZ85YCtRbvleEpqfgNQToto9pLYe+X6vvH9Z6p
Re: Possible signature verify bug?
Do you mind if I add the test case into our data set? I'd like to have it as one of the standard interop tests. (And yes the fix will go into 1.3.1 :.) Cheers, Berin Scott Cantor wrote: Berin, The patch you sent fixes my test case, thanks. -- Scott
Re: Signer name and Signed date assertion (SignerName SignedDate/SigningTime) - XAdES
I'm not an expert on the Java library, but I don't believe any of the XAdES has been implemented. On the other hand - we are *always* happy to have people submitting code to be added! : Cheers, Berin Miroslav Nachev wrote: Hi, I can't find any support in Java XML Security libraries and requirements of SignerName SignedDate/SigningTime which are specified and REQUIRED in XAdES. Are there any plans for that or I have to do that myself? If I do that mayself, can you insert it as part in Java XML Security? Best Regards, Miroslav Nachev
Re: Compile Error Fix
Hi Vishal!
Do you still have login access to people.apache.org? You are defintely
in the authorisation file for svn, so if you log in to people.apache.org
you should be able to change your subversion password as per:
https://svn.apache.org/change-password
If that doesn't work, let me know and I will reset.
Cheers,
Berin
Vishal Mahajan wrote:
I don't seem to have the commit access in svn, and it has been long
period of inactivity on the list for me. Anyways, attached is a small
compile error fix in the project main branch.
Vishal
Index: org/apache/xml/security/transforms/implementations/TransformXPath.java
===
--- org/apache/xml/security/transforms/implementations/TransformXPath.java
(revision 451991)
+++ org/apache/xml/security/transforms/implementations/TransformXPath.java
(working copy)
@@ -120,7 +120,7 @@
private boolean needsCircunvent(String str) {
//return true;
//return false;
- return str.contains(namespace) || str.contains(name());
+ return (str.indexOf(namespace) != -1) || (str.indexOf(name()) !=
-1);
}
static class XPathNodeFilter implements NodeFilter {
VOTE: C++ 1.3.1 release
Hi all, I want to do a quick follow up to 1.3 with a maintenance version that fixes a few bugs and adds preliminary support for the new Xerces 3.0 code base. It also has a new build process under UNIX, so I will need to do an RC or two just to make sure everyone can build OK. +1 from me. Cheers, Berin
C++ - Moving to Automake
Hi all, For those that are interested, I am halfway through refactoring the UNIX build over to an automake based build. A few things are changing - in particular the build will now happen from the base directory of the package, rather than the src directory. I'm also now letting automake handle how installation works, so my hope is that this will be kinder on UNIX. I am going to also update to support the current Xerces 3.0 source tree (not yet released) and fix the RSA bug and then release a 1.3.1. My question - are there any objections to this being a 1.3.1? Or would people prefer it to be 1.4 if the build has drastically changed? Other than some patches, nothing should change at a source code level, so I'm not expecting a modification to the API. (I may update xklient a bit, but that doesn't affect the library.) Cheers, Berin
Re: C++ 1.3.0 archive, XKMS
Martin, The only thing I would be comfortable to say is all there at the moment is the actual message set load and read inside the library. The xklient code is OK just to prove it all works, but as you can see it still needs a lot of work to get up to anything useful. The NetAcccessor exception sounds right - the client will try to access that site to perform the request you are asking for - so it will attempt to connect to blah.blah. Try ./xklient req lr http://www.wingsofhermes.org:81/xkmsd/soap11 -n Berin Lautenbach If you want to see the generated/received messages, add a -t after the initial ./xklient Cheers, Berin Martin Pirker wrote: Hi list... Berin Lautenbach wrote: I've now tarred up the 1.3.0 code and placed in http://people.apache.org/~blautenb/ Took a quick look at this package. CHANGELOG offers: * Complete implementation of XKMS message set Yep, they seem all to be there. Looking at xclient.cpp, function doMsgCreate, looks incomplete with only LocateRequest? function evaluate, copypaste comments :-) try to run: $ LD_PRELOAD=./libxml-security-c.so ./xklient req rr http://bla.bla XKMS Client (Using Apache XML-Security-C Library v1.3.0) terminate called after throwing an instance of 'xercesc_2_6::NetAccessorException' Aborted ... To distinguish which may be bug and which is feature, may I ask, what is the status of XKMS, what is already implemented, what is TODO? Thanks, Martin
C++ 1.3.0 archive
Hi all, Sorry for going so quiet for a while. Been a bit crazy here. I've now tarred up the 1.3.0 code and placed in http://people.apache.org/~blautenb/ I'll move to the download directory and update the web site in the next couple of days. Cheers, Berin
Santuario mailing lists
Peoples, This is the last message that will be put into this list about general Santuario things. There are now two new mailing lists - [EMAIL PROTECTED] and [EMAIL PROTECTED] PMC members have already been subscribed to [EMAIL PROTECTED] If you are on the PMC and did not receive an email, please let me know. Nobody has been subcribed to general@ - it is open to everyone, so please do subscribe if you are interested in where we go with this project as a whole. It think we will also move this mailing list to [EMAIL PROTECTED] or similar, but if that happens I'll make sure there are redirects in place to ensure anything addressed to [EMAIL PROTECTED] gets through. Open to thoughts on that one. Cheers, Berin
Re: Use of exclusive c14n when encrypting elements in C++ lib
Scott Cantor wrote: If you want to cut a final RC, I can try and do a final round of source and RPM builds and make sure it's clean. Red Hat is apparently going to put EL5 on top of gcc4.1, so I have to make sure things are ok. RC3 sitting in people.apache.org/~blautenb Cheers, Berin
Re: Use of exclusive c14n when encrypting elements in C++ lib
Scott, I was thinking about this during the day. I'm going to add a method to allow the exclusive use to be turned off and that way it can be deactivated if it makes sense. I've been wracking my brains to think about why I used it in the first place, and I know there was a really good reason but I just can't remember it :. On another note - I'm want to get this release done so I can start on tidying up a few things in the code - which is my personal focus for 1.4. I know you were having a look at other things in encryption so just wanted to touch base before I moved it forward. Cheers, Berin Scott Cantor wrote: The whole thing about serialisation of data prior to encryption is fraught with problems. Exc-c14n fixed some of them for me - but obviously there are others I missed! I know, it's only my intuition that suggests to me that inclusive works better for this use case, because signatures contain their own tranforms and c14n directives. So sucking in additional namespaces during encryption *shouldn't* cause breakage. Are you able to give me a fragment of something that breaks? I think I can see what you are getting at below, but a concrete example would make it easier for me :. Here's a simple example that *should* break: foo:bar xmlns:foo=... xmlns:typens=... xsi:type=typens:extension ... /foo If I encrypt that element, your API will run excl c14n on the DOM to get the octets. But under exclusive c14n, xmlns:typens is not visibly used, so it will be stripped. On the other end when I decrypt it, I'll get back this: foo:bar xmlns:foo=... xsi:type=typens:extension ... /foo If I don't validate, it will parse, because the parser isn't QName aware. But my code will expect to process xsi:type properly, and won't find typens. The usual solution of course is the inclusive prefix list, but I think here your best bet is just use inclusive, so taking out the setExclusive() call inside the encryption routine should work. -- Scott
Re: WG: help
Out of curiosity - C library or Java? If all else fails can read directly from the DOM. Having said that, we should probably have a method to read out the digest. Cheers, Berin Djelloul Aroui wrote: Hallo every body, I have used the xml security of apache to sign xml files. I want to check, if a xml is changed or not. To do this, I want to compare the signatures and the digest values: 1. I generate a new signature for the giving xml 2. I compare the new generated xml signature with the old one. 3. I cant compare the digest values, because the object SignedInfo doesnt deliver a digestValue object? How can I get the digest value from signedInfo? Tanks for your help Djelloul
Re: Patch for xml-security-c 1.2.1 compilation with g++ 4.1
Russ, Have you tried RC2 for 1.3? http://people.apache.org/~blautenb/ - this should compile under gcc 4.1 Cheers, Berin Russ Allbery wrote: g++ 4.1 requires the following patch to xml-security-c 1.2.1: Index: xml-security-c/src/canon/XSECC14n20010315.hpp === --- xml-security-c.orig/src/canon/XSECC14n20010315.hpp2006-06-26 20:56:03.0 -0700 +++ xml-security-c/src/canon/XSECC14n20010315.hpp 2006-06-26 20:58:16.0 -0700 @@ -124,7 +124,7 @@ protected: private: - void XSECC14n20010315::init(); + void init(); bool checkRenderNameSpaceNode(XERCES_CPP_NAMESPACE_QUALIFIER DOMNode *e, XERCES_CPP_NAMESPACE_QUALIFIER DOMNode *a); Index: xml-security-c/src/transformers/TXFMXPathFilter.hpp === --- xml-security-c.orig/src/transformers/TXFMXPathFilter.hpp 2006-06-26 20:56:03.0 -0700 +++ xml-security-c/src/transformers/TXFMXPathFilter.hpp 2006-06-26 20:58:16.0 -0700 @@ -77,7 +77,7 @@ public: // XPathFilter unique void evaluateExprs(DSIGTransformXPathFilter::exprVectorType * exprs); - XSECXPathNodeList * TXFMXPathFilter::evaluateSingleExpr(DSIGXPathFilterExpr *expr); + XSECXPathNodeList * evaluateSingleExpr(DSIGXPathFilterExpr *expr); // Methods to get output data Index: xml-security-c/src/dsig/DSIGKeyInfoList.hpp === --- xml-security-c.orig/src/dsig/DSIGKeyInfoList.hpp 2006-06-26 20:56:03.0 -0700 +++ xml-security-c/src/dsig/DSIGKeyInfoList.hpp 2006-06-26 20:58:16.0 -0700 @@ -232,7 +232,7 @@ public: */ XERCES_CPP_NAMESPACE_QUALIFIER DOMElement * - DSIGKeyInfoList::createKeyInfo(void); + createKeyInfo(void); /** * \brief Append a DSA KeyValue element Index: xml-security-c/src/dsig/DSIGKeyInfoValue.hpp === --- xml-security-c.orig/src/dsig/DSIGKeyInfoValue.hpp 2006-06-26 20:56:03.0 -0700 +++ xml-security-c/src/dsig/DSIGKeyInfoValue.hpp 2006-06-26 20:58:16.0 -0700 @@ -232,7 +232,7 @@ public: */ XERCES_CPP_NAMESPACE_QUALIFIER DOMElement * - DSIGKeyInfoValue::createBlankRSAKeyValue(const XMLCh * modulus, + createBlankRSAKeyValue(const XMLCh * modulus, const XMLCh * exponent); /** @@ -243,7 +243,7 @@ public: * @param modulus Base64 encoded value to set */ - void DSIGKeyInfoValue::setRSAModulus(const XMLCh * modulus); + void setRSAModulus(const XMLCh * modulus); /** * \brief Set the exponent @@ -253,7 +253,7 @@ public: * @param exponent Base64 encoded value to set */ - void DSIGKeyInfoValue::setRSAExponent(const XMLCh * exponent); + void setRSAExponent(const XMLCh * exponent); //@} Index: xml-security-c/src/dsig/DSIGReference.hpp === --- xml-security-c.orig/src/dsig/DSIGReference.hpp2006-06-26 20:56:03.0 -0700 +++ xml-security-c/src/dsig/DSIGReference.hpp 2006-06-26 20:58:16.0 -0700 @@ -385,7 +385,7 @@ public: * transforms. */ - static TXFMChain * DSIGReference::createTXFMChainFromList(TXFMBase * input, + static TXFMChain * createTXFMChainFromList(TXFMBase * input, DSIGTransformList * lst); /** Index: xml-security-c/src/dsig/DSIGTransformC14n.hpp === --- xml-security-c.orig/src/dsig/DSIGTransformC14n.hpp2006-06-26 20:56:03.0 -0700 +++ xml-security-c/src/dsig/DSIGTransformC14n.hpp 2006-06-26 20:58:16.0 -0700 @@ -187,7 +187,7 @@ public: * @param ns The (space separated) list of prefixes to set. */ - void DSIGTransformC14n::setInclusiveNamespaces(XMLCh * ns); + void setInclusiveNamespaces(XMLCh * ns); /** * \brief Get the string containing the inclusive namespaces. Index: xml-security-c/src/xkms/impl/XKMSResultTypeImpl.hpp === --- xml-security-c.orig/src/xkms/impl/XKMSResultTypeImpl.hpp 2006-06-26 20:58:32.0 -0700 +++ xml-security-c/src/xkms/impl/XKMSResultTypeImpl.hpp 2006-06-26 20:58:44.0 -0700 @@ -53,7 +53,7 @@ public: void load(void); XERCES_CPP_NAMESPACE_QUALIFIER DOMElement * - XKMSResultTypeImpl::createBlankResultType( + createBlankResultType( const XMLCh * tag,
We are now a TLP
Hi all, The board met yesterday and the resolution to make xml-security (now known as Santuario) a TLP. The scope is limited to the xml-security piece, so not the broad security project. I'll put some thoughts together about where to from here over the next few days. Cheers, Berin
[Fwd: XML-Security TLP - Santuario]
Updated resolution that just covers xml-security. I've pasted the original trail, so you can keep both in and tell us which one you go for :. Cheers, Berin WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to XML security technologies, for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Santuario PMC, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Santuario PMC be and hereby is responsible for the creation and maintenance of software related to XML security technologies, based on software licensed to the Foundation; and be it further RESOLVED, that the office of Vice President, Apache Santuario be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Santuario PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Santuario PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Santuario PMC: Axl Mattheus [EMAIL PROTECTED] Berin Lautenbach [EMAIL PROTECTED] Davanum Srinivas [EMAIL PROTECTED] Raul Benito [EMAIL PROTECTED] Sean Mullan [EMAIL PROTECTED] Werner Dittman [EMAIL PROTECTED] NOW, THEREFORE, BE IT FURTHER RESOLVED, that Berin Lautenbach [EMAIL PROTECTED] is appointed to the office of Vice President, Apache Santuario, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Santuario PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Santuario Project; and be it further RESOLVED, that the initial Apache Santuario PMC be and hereby is tasked with the migration and rationalization of the Apache XML PMC, XML Security subproject; and be it further RESOLVED, that all responsibility pertaining to the Apache XML, XML Security sub-project and encumbered upon the Apache XML PMC are hereafter discharged. Cheers, Berin Original Message Subject: XML-Security TLP - Santuario Date: Wed, 21 Jun 2006 21:28:58 +1000 From: Berin Lautenbach [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED], security-dev@xml.apache.org Board peoples, Another TLP proposal from the XML project - but with a slight difference. We are proposing to create a general security software project that has the xml-security project as a core to build from. As I mentioned in a previous email - this is not about creating another super-project (been through that once :) - it's about having a project to foster and provide a focal point for security related software within the foundation. From our XML experiences we have become quite good at spinning off sub projects - we can use that experience to gauge when promotion is necessary to defend against inadequate oversite. (Asssuming it is necessary - I'm not really seeing this as a project factory.) The proposal has been put to the vote both within the xml-security group and within the XML PMC. (History forwarded as part of this email.) Something to discuss in the inaugural meeting of the new board! Cheers, Berin WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to security technologies, for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Santuario PMC, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Santuario PMC be and hereby is responsible for the creation and maintenance of software related to security technologies, based on software licensed to the Foundation; and be it further RESOLVED, that the office of Vice President, Apache Santuario be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Santuario PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Santuario PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache
Re: XML-Security TLP - Santuario
Roy T. Fielding wrote: It sounds like a decent idea for a federation, but a terrible idea for a project. Projects need to be responsible for a product or they just end up in the weeds. A federation of projects can simply maintain a general mailing list and website. It would be responsible for code - the current xml-security stuff that sits within the XML project/federation. And it would look to start new things as well - with an absolute intent to move them to TLP when necessary (i.e. when it became clear the Santuario PMC did not have direct oversite). I know we are trying not to create umbrella projects - I'm trying to walk a middle ground to see if we can make something like this work with a community that fosters this area. It's a bit of a community experiment as well as a technical one. Cheers, Berin
Re: XML-Security TLP - Santuario
Sanjiva, From the perspective of WS and the ws-* projects you mention, no change at all, unless you want to link back and reference to the activities in Santuario. On the other hand, one thing the security project would want to do would be to create a single point where people can come to to get a picture of all the various security software activities withiin the ASF. So I would envisage a set of pointers linking to the various pages within the ASF web related to the activities such as you mention below. And as far as I'm concerend, the more input the WS groups want to have in how we build Santuario the better - hint hint hint :. Cheers, Berin Sanjiva Weerawarana wrote: Berin, there security stuff happening in WS land as well: we're implementing WS-Security, WS-Secure Conversation, WS-Trust and WS-Security Policy .. in both Java and C (and thru the latter for PHP etc.). Once those are done then we can do InfoCard and other stuff that's coming down the pipe (like WS-Federation). What's the right way to relate those to the new security TLP? Sanjiva. On Wed, 2006-06-21 at 21:28 +1000, Berin Lautenbach wrote: Board peoples, Another TLP proposal from the XML project - but with a slight difference. We are proposing to create a general security software project that has the xml-security project as a core to build from. As I mentioned in a previous email - this is not about creating another super-project (been through that once :) - it's about having a project to foster and provide a focal point for security related software within the foundation. From our XML experiences we have become quite good at spinning off sub projects - we can use that experience to gauge when promotion is necessary to defend against inadequate oversite. (Asssuming it is necessary - I'm not really seeing this as a project factory.) The proposal has been put to the vote both within the xml-security group and within the XML PMC. (History forwarded as part of this email.) Something to discuss in the inaugural meeting of the new board! Cheers, Berin WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to security technologies, for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Santuario PMC, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Santuario PMC be and hereby is responsible for the creation and maintenance of software related to security technologies, based on software licensed to the Foundation; and be it further RESOLVED, that the office of Vice President, Apache Santuario be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Santuario PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Santuario PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Santuario PMC: Axl Mattheus [EMAIL PROTECTED] Berin Lautenbach [EMAIL PROTECTED] Davanum Srinivas [EMAIL PROTECTED] Raul Benito [EMAIL PROTECTED] Sean Mullan [EMAIL PROTECTED] Werner Dittman [EMAIL PROTECTED] NOW, THEREFORE, BE IT FURTHER RESOLVED, that Berin Lautenbach [EMAIL PROTECTED] is appointed to the office of Vice President, Apache Santuario, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Santuario PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Santuario Project; and be it further RESOLVED, that the initial Apache Santuario PMC be and hereby is tasked with the migration and rationalization of the Apache XML PMC, XML Security subproject; and be it further RESOLVED, that all responsibility pertaining to the Apache XML, XML Security sub-project and encumbered upon the Apache XML PMC are hereafter discharged. Original Message Subject: Re: VOTE: XML-Security TLP - Santuario Date: Tue, 20 Jun 2006 08:21:48 +1000 From: Berin Lautenbach [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] Calling it. 8 +1s (including me) and no dissenting votes. I will fix the resolution and send to the board for the meeting next week. Thanks all! Cheers, Berin Berin Lautenbach wrote: Hi all - I'm going to call this in another 24 hours and put
[Fwd: Fwd: VOTE: TLP Resolution]
Hi all, Axl actually voted as well, but his emails didn't get through. So here is a forwarded copy of Axl's vote, and I will add him onto the initial PMC list that gets put forward. Cheers, Berin Original Message Subject:Fwd: VOTE: TLP Resolution Date: Tue, 13 Jun 2006 16:29:14 +0200 From: Axl Mattheus [EMAIL PROTECTED] To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] This was my vote! ax/ -- Forwarded message -- From: *Axl Mattheus* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Date: 31-May-2006 14:27 Subject: Re: VOTE: TLP Resolution To: security-dev@xml.apache.org mailto:security-dev@xml.apache.org 1 +1 2 Santaurio 3 +1 ax/ On 31/05/06, *Raul Benito* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: 1)+1 2) Santuario 3) +1 On 5/31/06, Dittmann, Werner [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Here are my votes: 1) +1 2) Santuario 3) +1 Regards, Werner -Ursprüngliche Nachricht- Von: Berin Lautenbach [mailto: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 31. Mai 2006 12:22 An: security-dev@xml.apache.org mailto:security-dev@xml.apache.org Betreff: VOTE: TLP Resolution All, I'm going to make this happen by hook or by crook. I've floated the idea on board@ and got no objections, so lets make it formal. All committers need to cast a vote on the following. 1) Support for going to TLP as a broad Security project (+1 or -1) 2) The name of the project. See list of proposed names below. 3) The chair. At the moment the only volunteer is myself, so you can vote +1/-1 to that or you can propose other names :. I've pasted the board proposal at the end of this email. I've included a list of current committers on JuiCE (is this OK?) and XML-Security in the PMC list. To make sure the list is valid, I will be using this vote to confirm people are interested in being in the PMC. IF YOU DO NOT VOTE I WILL ASSUME THAT YOU ARE NOT INTERESTED ON BEING ON THE PMC! (Sorry for shouting :.) Proposed Names (feel free to add if you have strong feelings) : - Raksha - Security Software - Santuario Cheers, Berin WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to security technologies, for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache XX INSERT NAME XX PMC, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache XXX INSERT NAME XX PMC be and hereby is responsible for the creation and maintenance of software related to creation and maintenance of open-source software related to XML security technologies based on software licensed to the Foundation; and be it further RESOLVED, that the office of Vice President, Apache XX INSERT NAME XX be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache XX INSERT NAME XX PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache XX INSERT NAME XX PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache XX INSERT NAME XX PMC: Erwin van der Koogh [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Axl Mattheus [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Berin Lautenbach [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Vishal Mahajan [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Davanum Srinivas [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Raul Benito [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Milan Tomic [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Sean Mullan [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Karel Wouters [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Noah Levitt [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Walter Hoehn [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Werner Dittman [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] NOW, THEREFORE, BE IT FURTHER RESOLVED, that XX INSERT CHAIR XX [EMAIL PROTECTED] http://apache.org appointed to the office of Vice President, Apache XX INSERT NAME XX, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache XX INSERT NAME XX PMC be and hereby is tasked with the creation of a set of bylaws intended
Re: Unexported class in C++ library
Scott Cantor wrote: The XSECAlgorithmMapper class seems to be non-exported from the Windows version of the library, marked internal, but if that's the case, why is the g_algorithmMapper member in XSECPlatformUtils public, and why is the class' header itself visible? I'd like to make use of the Mapper myself, so I'd prefer that it be exported, but if that's a concern, I'd suggest hiding the use of it entirely. It was originally intended to be purely internal (thus the marking in the dox). But making it available outside the library makes sense - I'll export it. Cheers, Berin
Re: VOTE: TLP Resolution
OK Calling it. Following people voted: Dims, Berin, Werner, Raul, Sean, Ceki, Steve 7 x +1 for TLP. (2 non-binding) 7 x +1 for BL as chair (2 non-binding) 6 x +1 for Santuario (2 non-binding) and 1 for Raksha. So I will take to the XML PMC and then to then board with the TLP project name of Santuario and the PMC as: Dims Werner Raul Sean Berin Cheers, Berin Berin Lautenbach wrote: All, I'm going to make this happen by hook or by crook. I've floated the idea on board@ and got no objections, so lets make it formal. All committers need to cast a vote on the following. 1) Support for going to TLP as a broad Security project (+1 or -1) 2) The name of the project. See list of proposed names below. 3) The chair. At the moment the only volunteer is myself, so you can vote +1/-1 to that or you can propose other names :. I've pasted the board proposal at the end of this email. I've included a list of current committers on JuiCE (is this OK?) and XML-Security in the PMC list. To make sure the list is valid, I will be using this vote to confirm people are interested in being in the PMC. IF YOU DO NOT VOTE I WILL ASSUME THAT YOU ARE NOT INTERESTED ON BEING ON THE PMC! (Sorry for shouting :.) Proposed Names (feel free to add if you have strong feelings) : - Raksha - Security Software - Santuario Cheers, Berin WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to security technologies, for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache XX INSERT NAME XX PMC, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache XXX INSERT NAME XX PMC be and hereby is responsible for the creation and maintenance of software related to creation and maintenance of open-source software related to XML security technologies based on software licensed to the Foundation; and be it further RESOLVED, that the office of Vice President, Apache XX INSERT NAME XX be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache XX INSERT NAME XX PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache XX INSERT NAME XX PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache XX INSERT NAME XX PMC: Erwin van der Koogh [EMAIL PROTECTED] Axl Mattheus [EMAIL PROTECTED] Berin Lautenbach [EMAIL PROTECTED] Vishal Mahajan [EMAIL PROTECTED] Davanum Srinivas [EMAIL PROTECTED] Raul Benito [EMAIL PROTECTED] Milan Tomic [EMAIL PROTECTED] Sean Mullan [EMAIL PROTECTED] Karel Wouters [EMAIL PROTECTED] Noah Levitt [EMAIL PROTECTED] Walter Hoehn [EMAIL PROTECTED] Werner Dittman [EMAIL PROTECTED] NOW, THEREFORE, BE IT FURTHER RESOLVED, that XX INSERT CHAIR XX [EMAIL PROTECTED] appointed to the office of Vice President, Apache XX INSERT NAME XX, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache XX INSERT NAME XX PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache XX INSERT NAME XX Project; and be it further RESOLVED, that the initial Apache XX INSERT NAME XX PMC be and hereby is tasked with the migration and rationalization of the Apache XML PMC XML Security subproject; and be it further RESOLVED, that all responsibility pertaining to the XML XML Security sub-project and encumbered upon the Apache XML PMC are hereafter discharged. Original Message Subject: Re: TLP Resolution Date: Tue, 02 May 2006 21:05:09 +1000 From: Berin Lautenbach [EMAIL PROTECTED] Reply-To: security-dev@xml.apache.org To: security-dev@xml.apache.org References: [EMAIL PROTECTED] [EMAIL PROTECTED] All, So we have two names that people seem to like Raksha Santuary Any other takers? We also have a scope of ...open-source software related to security... Thoughts welcome! If no more ideas come forth on either of these, I'm going to start a vote covering: 1. The proposal - do people support it to go to the board 2. The name 3. A PMC Chair. My thinking is all current committers become PMC members. On #3 - I'm going to volunteer, but I'd also encourage anyone else who is interested to put their names or the names
Re: VOTE: TLP Resolution
Ceki, Welcome :. Cheers, Berin [EMAIL PROTECTED] wrote: Here are my (non-binding) votes. 1) +1 2) Santuario 3) +1 Given that my current project will be heavily relying on XML-security and WS-Security and also as a former cryptography enthusiast, I would like to devote part of my time and energy contributing to XML-security and WS-security projects. For those who do not know me (Ceki Gülcü, ceki @ apache.org), I am the founder of the log4j and Apache Logging Services projects. An ASF member since 2001, I've also contributed to various other ASF projects along the way. Cheers, 1) +1 2) Santuario 3) +1 Berin Lautenbach wrote: All, I'm going to make this happen by hook or by crook. I've floated the idea on board@ and got no objections, so lets make it formal. All committers need to cast a vote on the following. 1) Support for going to TLP as a broad Security project (+1 or -1) 2) The name of the project. See list of proposed names below. 3) The chair. At the moment the only volunteer is myself, so you can vote +1/-1 to that or you can propose other names :. I've pasted the board proposal at the end of this email. I've included a list of current committers on JuiCE (is this OK?) and XML-Security in the PMC list. To make sure the list is valid, I will be using this vote to confirm people are interested in being in the PMC. IF YOU DO NOT VOTE I WILL ASSUME THAT YOU ARE NOT INTERESTED ON BEING ON THE PMC! (Sorry for shouting :.) Proposed Names (feel free to add if you have strong feelings) : - Raksha - Security Software - Santuario Cheers, Berin WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to security technologies, for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache XX INSERT NAME XX PMC, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache XXX INSERT NAME XX PMC be and hereby is responsible for the creation and maintenance of software related to creation and maintenance of open-source software related to XML security technologies based on software licensed to the Foundation; and be it further RESOLVED, that the office of Vice President, Apache XX INSERT NAME XX be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache XX INSERT NAME XX PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache XX INSERT NAME XX PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache XX INSERT NAME XX PMC: Erwin van der Koogh [EMAIL PROTECTED] Axl Mattheus [EMAIL PROTECTED] Berin Lautenbach [EMAIL PROTECTED] Vishal Mahajan [EMAIL PROTECTED] Davanum Srinivas [EMAIL PROTECTED] Raul Benito [EMAIL PROTECTED] Milan Tomic [EMAIL PROTECTED] Sean Mullan [EMAIL PROTECTED] Karel Wouters [EMAIL PROTECTED] Noah Levitt [EMAIL PROTECTED] Walter Hoehn [EMAIL PROTECTED] Werner Dittman [EMAIL PROTECTED] NOW, THEREFORE, BE IT FURTHER RESOLVED, that XX INSERT CHAIR XX [EMAIL PROTECTED] appointed to the office of Vice President, Apache XX INSERT NAME XX, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache XX INSERT NAME XX PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache XX INSERT NAME XX Project; and be it further RESOLVED, that the initial Apache XX INSERT NAME XX PMC be and hereby is tasked with the migration and rationalization of the Apache XML PMC XML Security subproject; and be it further RESOLVED, that all responsibility pertaining to the XML XML Security sub-project and encumbered upon the Apache XML PMC are hereafter discharged. DISCLAIMER This message is intended only for use by the person to whom it is addressed. It may contain information that is privileged and confidential. Its content does not constitute a formal commitment by Lombard Odier Darier Hentsch Group and any of its affiliates. If you are not the intended recipient of this message, kindly notify the sender immediately and destroy this message. Thank You. *
RC3 for 1.3.0 C++ Library
RC2 now in http://people.apache.org/~blautenb/ Includes fixes from RC1 as follows: - Reorder hashing in DSIGReference.cpp as per suggestion by Peter Gubis - Update microsoft project files to reflect new version as per Scott Cantor - Replace setAttribute with setAttributeNS calls - Add methods to OpenSSL classes to extract OpenSSL objects - Fix handling of libcrypto on Solaris platform - Fix bug in Canoncicalisation courtesy of Scott Cantor Cheers, Berin Berin Lautenbach wrote: Peoples, I have pulled the latest source together into an rc1 for v 1.3 of the C++ library. Can be found at: http://people.apache.org/~blautenb/ The docs have not been updated (other than the generated doxygen stuff). Any thougts/feedback welcome! Cheers, Berin
[Fwd: RC3 for 1.3.0 C++ Library]
That subject line should (of course) have been RC2 for 1.3.0 C++ library rather than RC3 Apologies. Cheers, Beirn Original Message Subject: RC3 for 1.3.0 C++ Library Date: Sun, 04 Jun 2006 20:46:05 +1000 From: Berin Lautenbach [EMAIL PROTECTED] Reply-To: security-dev@xml.apache.org To: security-dev@xml.apache.org References: [EMAIL PROTECTED] RC2 now in http://people.apache.org/~blautenb/ Includes fixes from RC1 as follows: - Reorder hashing in DSIGReference.cpp as per suggestion by Peter Gubis - Update microsoft project files to reflect new version as per Scott Cantor - Replace setAttribute with setAttributeNS calls - Add methods to OpenSSL classes to extract OpenSSL objects - Fix handling of libcrypto on Solaris platform - Fix bug in Canoncicalisation courtesy of Scott Cantor Cheers, Berin Berin Lautenbach wrote: Peoples, I have pulled the latest source together into an rc1 for v 1.3 of the C++ library. Can be found at: http://people.apache.org/~blautenb/ The docs have not been updated (other than the generated doxygen stuff). Any thougts/feedback welcome! Cheers, Berin
Re: VOTE: TLP Resolution
Still need votes from: Erwin van der Koogh [EMAIL PROTECTED] Axl Mattheus [EMAIL PROTECTED] Vishal Mahajan [EMAIL PROTECTED] Milan Tomic [EMAIL PROTECTED] Karel Wouters [EMAIL PROTECTED] Noah Levitt [EMAIL PROTECTED] Walter Hoehn [EMAIL PROTECTED] I'll give it another 48 hours then I will call it. Remember - if I don't get a vote, I'm assuming you don't want to be on the PMC initially. (But we can always add later:.) Cheers, Berin Berin Lautenbach wrote: All, I'm going to make this happen by hook or by crook. I've floated the idea on board@ and got no objections, so lets make it formal. All committers need to cast a vote on the following. 1) Support for going to TLP as a broad Security project (+1 or -1) 2) The name of the project. See list of proposed names below. 3) The chair. At the moment the only volunteer is myself, so you can vote +1/-1 to that or you can propose other names :. I've pasted the board proposal at the end of this email. I've included a list of current committers on JuiCE (is this OK?) and XML-Security in the PMC list. To make sure the list is valid, I will be using this vote to confirm people are interested in being in the PMC. IF YOU DO NOT VOTE I WILL ASSUME THAT YOU ARE NOT INTERESTED ON BEING ON THE PMC! (Sorry for shouting :.) Proposed Names (feel free to add if you have strong feelings) : - Raksha - Security Software - Santuario Cheers, Berin WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to security technologies, for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache XX INSERT NAME XX PMC, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache XXX INSERT NAME XX PMC be and hereby is responsible for the creation and maintenance of software related to creation and maintenance of open-source software related to XML security technologies based on software licensed to the Foundation; and be it further RESOLVED, that the office of Vice President, Apache XX INSERT NAME XX be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache XX INSERT NAME XX PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache XX INSERT NAME XX PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache XX INSERT NAME XX PMC: Erwin van der Koogh [EMAIL PROTECTED] Axl Mattheus [EMAIL PROTECTED] Berin Lautenbach [EMAIL PROTECTED] Vishal Mahajan [EMAIL PROTECTED] Davanum Srinivas [EMAIL PROTECTED] Raul Benito [EMAIL PROTECTED] Milan Tomic [EMAIL PROTECTED] Sean Mullan [EMAIL PROTECTED] Karel Wouters [EMAIL PROTECTED] Noah Levitt [EMAIL PROTECTED] Walter Hoehn [EMAIL PROTECTED] Werner Dittman [EMAIL PROTECTED] NOW, THEREFORE, BE IT FURTHER RESOLVED, that XX INSERT CHAIR XX [EMAIL PROTECTED] appointed to the office of Vice President, Apache XX INSERT NAME XX, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache XX INSERT NAME XX PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache XX INSERT NAME XX Project; and be it further RESOLVED, that the initial Apache XX INSERT NAME XX PMC be and hereby is tasked with the migration and rationalization of the Apache XML PMC XML Security subproject; and be it further RESOLVED, that all responsibility pertaining to the XML XML Security sub-project and encumbered upon the Apache XML PMC are hereafter discharged. Original Message Subject: Re: TLP Resolution Date: Tue, 02 May 2006 21:05:09 +1000 From: Berin Lautenbach [EMAIL PROTECTED] Reply-To: security-dev@xml.apache.org To: security-dev@xml.apache.org References: [EMAIL PROTECTED] [EMAIL PROTECTED] All, So we have two names that people seem to like Raksha Santuary Any other takers? We also have a scope of ...open-source software related to security... Thoughts welcome! If no more ideas come forth on either of these, I'm going to start a vote covering: 1. The proposal - do people support it to go to the board 2. The name 3. A PMC Chair. My thinking is all current committers become PMC members. On #3 - I'm going to volunteer, but I'd also encourage
Re: AW: Help with X.509 public key decryption of XML
Does it work with a 1024 bit key? Dave Oxley wrote: Werner, Thanks for the response. I have confirmed that the unlimited JCE is installed and I also copied the BC provider and all apache xml jar's into jre/lib/ext for good measure. I'm still getting the same problem. By the way I'm using JDK 1.5.0_06. Is there anything else that can cause this problem? Cheers, Dave. Dittmann, Werner wrote: Dave, sometimes this happens if one forgot to install the unlimited strength JCE policy (at least this happens to me sometimes when I install a new java version - I have to reinstall in every time in the new install directory). Regards, Werner -Ursprüngliche Nachricht- Von: Dave Oxley [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 1. Juni 2006 12:02 An: security-dev@xml.apache.org Betreff: Re: Help with X.509 public key decryption of XML I have been doing an awful lot of reading and experimenting and still have problems. I am now trying to sign an xml document with an RSA key. The key's generated like this: KeyPairGenerator keyGen = KeyPairGenerator.getInstance(RSA); keyGen.initialize(2048, sr); KeyPair keypair = keyGen.generateKeyPair(); PrivateKey privKey = keypair.getPrivate(); And when I call: sig.sign(privKey); I get this exception: org.apache.xml.security.signature.XMLSignatureException: No installed provider supports this key: sun.security.rsa.RSAPrivateCrtKeyImpl Original Exception was org.apache.xml.security.signature.XMLSignatureException: No installed provider supports this key: sun.security.rsa.RSAPrivateCrtKeyImpl Original Exception was java.security.InvalidKeyException: No installed provider supports this key: sun.security.rsa.RSAPrivateCrtKeyImpl at org.apache.xml.security.signature.XMLSignature.sign(Unknown Source) or this exception with BC: org.apache.xml.security.signature.XMLSignatureException: No installed provider supports this key: org.bouncycastle.jce.provider.JCERSAPrivateCrtKey Original Exception was org.apache.xml.security.signature.XMLSignatureException: No installed provider supports this key: org.bouncycastle.jce.provider.JCERSAPrivateCrtKey Original Exception was java.security.InvalidKeyException: No installed provider supports this key: org.bouncycastle.jce.provider.JCERSAPrivateCrtKey at org.apache.xml.security.signature.XMLSignature.sign(Unknown Source) What am I doing wrong? This is driving me nuts, I've been working on this 4 days straight now. Cheers, Dave.
VOTE: TLP Resolution
All, I'm going to make this happen by hook or by crook. I've floated the idea on board@ and got no objections, so lets make it formal. All committers need to cast a vote on the following. 1) Support for going to TLP as a broad Security project (+1 or -1) 2) The name of the project. See list of proposed names below. 3) The chair. At the moment the only volunteer is myself, so you can vote +1/-1 to that or you can propose other names :. I've pasted the board proposal at the end of this email. I've included a list of current committers on JuiCE (is this OK?) and XML-Security in the PMC list. To make sure the list is valid, I will be using this vote to confirm people are interested in being in the PMC. IF YOU DO NOT VOTE I WILL ASSUME THAT YOU ARE NOT INTERESTED ON BEING ON THE PMC! (Sorry for shouting :.) Proposed Names (feel free to add if you have strong feelings) : - Raksha - Security Software - Santuario Cheers, Berin WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to security technologies, for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache XX INSERT NAME XX PMC, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache XXX INSERT NAME XX PMC be and hereby is responsible for the creation and maintenance of software related to creation and maintenance of open-source software related to XML security technologies based on software licensed to the Foundation; and be it further RESOLVED, that the office of Vice President, Apache XX INSERT NAME XX be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache XX INSERT NAME XX PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache XX INSERT NAME XX PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache XX INSERT NAME XX PMC: Erwin van der Koogh [EMAIL PROTECTED] Axl Mattheus [EMAIL PROTECTED] Berin Lautenbach [EMAIL PROTECTED] Vishal Mahajan [EMAIL PROTECTED] Davanum Srinivas [EMAIL PROTECTED] Raul Benito [EMAIL PROTECTED] Milan Tomic [EMAIL PROTECTED] Sean Mullan [EMAIL PROTECTED] Karel Wouters [EMAIL PROTECTED] Noah Levitt [EMAIL PROTECTED] Walter Hoehn [EMAIL PROTECTED] Werner Dittman [EMAIL PROTECTED] NOW, THEREFORE, BE IT FURTHER RESOLVED, that XX INSERT CHAIR XX [EMAIL PROTECTED] appointed to the office of Vice President, Apache XX INSERT NAME XX, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache XX INSERT NAME XX PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache XX INSERT NAME XX Project; and be it further RESOLVED, that the initial Apache XX INSERT NAME XX PMC be and hereby is tasked with the migration and rationalization of the Apache XML PMC XML Security subproject; and be it further RESOLVED, that all responsibility pertaining to the XML XML Security sub-project and encumbered upon the Apache XML PMC are hereafter discharged. Original Message Subject: Re: TLP Resolution Date: Tue, 02 May 2006 21:05:09 +1000 From: Berin Lautenbach [EMAIL PROTECTED] Reply-To: security-dev@xml.apache.org To: security-dev@xml.apache.org References: [EMAIL PROTECTED] [EMAIL PROTECTED] All, So we have two names that people seem to like Raksha Santuary Any other takers? We also have a scope of ...open-source software related to security... Thoughts welcome! If no more ideas come forth on either of these, I'm going to start a vote covering: 1. The proposal - do people support it to go to the board 2. The name 3. A PMC Chair. My thinking is all current committers become PMC members. On #3 - I'm going to volunteer, but I'd also encourage anyone else who is interested to put their names or the names of others forward! Cheers, Berin Davanum Srinivas wrote: Here's one i was thinking about - Raksha (http://en.wikipedia.org/wiki/Raksha) thanks, dims On 3/15/06, Jesse Pelton [EMAIL PROTECTED] wrote: Some random ideas to get the name game going, based on your indicated vision for the project: SecureSoft, Security Software, Vault, Shield, Armor, Guard, Sanctuary, ,Citadel, Surety, Security Blanket (or Linus, with a nod to Charles Schulz' Peanuts, but you'd want to get permission). With the possible exception
Re: Debian packaging, quick naming question
Scott Cantor wrote: Second, and this is one of those things that doesn't really matter but I promised to at least ask, there were a few Debian developers who responded to my Intent to Package notification who were wondering why the package was called XML-Security-C when it was written in C++. Just a guess on my part, but Xerces is called Xerces-C in various places, Xerces C++ in others. All the directories on the Apache site, cvs/svn, etc. use xerces-c or xerces/c/ as a designation. Just seems to be the approach for better or worse. That's pretty much it. And the name was already so long I didn't want to add yet more onto the filename. Just lazy I guess. BTW - Am really glad someone has picked up the debian thing. I had an ITP filed for a long time, but I never got around to actually doing the packaging. But I do look after the Xalan package, and I know the main person who looks after Xerces, so if there are any dependency problems give me a hoy. Cheers, Berin
Re: TLP Resolution
Is that sufficiently different do you think? (Never quite known how far you have to take it.) Either way - it's the only think I could find out there. If we believe it's not close enough to warrant concern I'll leave it on the list! Cheers, Berin Davanum Srinivas wrote: Berin, their stuff is Info-Raksha...we'd be going for Apache Raksha -- dims On 5/5/06, Berin Lautenbach [EMAIL PROTECTED] wrote: And I've just found this http://harishinfotech.com/index.htm# Which uses Raksha in the name. So the options are starting to get more limited! Cheers, Berin Raul Benito wrote: You're a poet, less cool than santuary, but +1 for me. On 5/4/06, Berin Lautenbach [EMAIL PROTECTED] wrote: What about asylum? (I know - taken, it just tickled my funny bone). Santuario I quite like! Cheers, Berin Raul Benito wrote: Sad, I like the name, Perhaps a translation: Santuario(Spanish), Santuarium(Latin) or a synonym Tabernaculum... Just wild guessing.. On 5/3/06, Jesse Pelton [EMAIL PROTECTED] wrote: Good catch. It's a registered trademark, no less, and in a related field, so I doubt SecureWave would be pleased to have Apache use it for a project name. Too bad. -jesse- -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 03, 2006 10:26 AM To: security-dev@xml.apache.org Subject: Re: TLP Resolution Sanctuary is a cool name. However there is a product named Sanctuary by SecureWave: http://www.securewave.com/endpoint_security_solutions.jsp --Sean -- http://r-bg.com -- http://r-bg.com -- Davanum Srinivas : http://wso2.com/blogs/
Re: TLP Resolution
And I've just found this http://harishinfotech.com/index.htm# Which uses Raksha in the name. So the options are starting to get more limited! Cheers, Berin Raul Benito wrote: You're a poet, less cool than santuary, but +1 for me. On 5/4/06, Berin Lautenbach [EMAIL PROTECTED] wrote: What about asylum? (I know - taken, it just tickled my funny bone). Santuario I quite like! Cheers, Berin Raul Benito wrote: Sad, I like the name, Perhaps a translation: Santuario(Spanish), Santuarium(Latin) or a synonym Tabernaculum... Just wild guessing.. On 5/3/06, Jesse Pelton [EMAIL PROTECTED] wrote: Good catch. It's a registered trademark, no less, and in a related field, so I doubt SecureWave would be pleased to have Apache use it for a project name. Too bad. -jesse- -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 03, 2006 10:26 AM To: security-dev@xml.apache.org Subject: Re: TLP Resolution Sanctuary is a cool name. However there is a product named Sanctuary by SecureWave: http://www.securewave.com/endpoint_security_solutions.jsp --Sean -- http://r-bg.com -- http://r-bg.com
Re: TLP Resolution
Oh - rude words. I really liked Sanctuary. As Jesse said - good catch! Cheers, Berin Sean Mullan wrote: Sanctuary is a cool name. However there is a product named Sanctuary by SecureWave: http://www.securewave.com/endpoint_security_solutions.jsp --Sean Berin Lautenbach wrote: All, So we have two names that people seem to like Raksha Santuary Any other takers? We also have a scope of ...open-source software related to security... Thoughts welcome! If no more ideas come forth on either of these, I'm going to start a vote covering: 1. The proposal - do people support it to go to the board 2. The name 3. A PMC Chair. My thinking is all current committers become PMC members. On #3 - I'm going to volunteer, but I'd also encourage anyone else who is interested to put their names or the names of others forward! Cheers, Berin Davanum Srinivas wrote: Here's one i was thinking about - Raksha (http://en.wikipedia.org/wiki/Raksha) thanks, dims On 3/15/06, Jesse Pelton [EMAIL PROTECTED] wrote: Some random ideas to get the name game going, based on your indicated vision for the project: SecureSoft, Security Software, Vault, Shield, Armor, Guard, Sanctuary, ,Citadel, Surety, Security Blanket (or Linus, with a nod to Charles Schulz' Peanuts, but you'd want to get permission). With the possible exception of the last, none of these indulge the Apache penchant for obscure references, though. But the name is really the last piece. You need a clearly articulated purpose and scope before you can come up with a name that fits. -Original Message- From: Berin Lautenbach [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 15, 2006 3:13 AM To: security-dev@xml.apache.org Subject: Re: TLP Resolution Thoughts welcome :. Berin Lautenbach wrote: OK - I'm going to take the idea to the board. Before I do - we need a couple of things. 1. A name. I'd personally be against anything fancy or non-obvious. But I don't really want to use Apache Security as I think it will get too confusing against the security group within the ASF (the group that looks after security bug reports etc.) Apache Infosec? Apache Secure? Obviously there is a reason I never went into marketing :. 2. A scope. Probably not hard. ...open-source software related to security... is a good place to start I suspect :. I also wouldn't mind to take some first steps as to what we want to do. Obviously set up xml-security and JuiCE, but I'd personally like to see the ASF become a source of best practice for security software as well. Longer term - but an interesting goal for a tlp within the ASF. And if we are going to use this as an exercise in raising interest in what we are doing inside/outside the ASF, then we want to think about what kind of message we want to give people when the project goes to top level. I'd also like to use it as a central point people can go to in order to see all security related software in the ASF. Not to have projects like WS-Security under the security project, but to have links to other projects/efforts in the ASF that are related to security software. Thoughts welcome! Cheers, Berin Ben Laurie wrote: Davanum Srinivas wrote: Dear Ben and Dear Ben, what do you guys think? A Security Federation/TLP/PMC. Starting with Apache XML-Security and Apache Juice. It sounds like a very good idea to me, I'd certainly support it. Of course, we already have a CA. Written in, errr, perl :-) Cheers, Ben. thanks, -- dims On 3/11/06, Berin Lautenbach [EMAIL PROTECTED] wrote: I would be interested in widening it as well - with the proviso that it is like a federation. I.e. we use it to seed projects then build them and spawn them into TLPs once they grow to size. I might start sounding some people out. Dims - what's your thoughts? On the subject - having spent the most of Saturday searching for a decent Open Source CA, I'd now be interested in building one that doesn't use [EMAIL PROTECTED] perl. I.e. do the core in C++ with perl/PHP being used for the interfacing only. Cheers, Berin Werner Dittmann wrote: +1 from me. Just a comment regarding the charter: is it really only Apache XML Security? IMHO this would be a bit too narrow, for example JuiCE is not dependent on XML, maybe other security related software will be pop up later as well. I would like to see an Apache Security PMC that would address all kind of security relevant software and act as a solid base to deliver security functions to other Apache projects. Also we may think to browse existing Apache projects to see if there is already software (maybe even multiply implemented) and pool them here. BTW, I would be happy to be a part of this activity. Regards, Werner Berin Lautenbach wrote: Peoples, Sometime back we talked about becoming a TLP. With the recent
Re: TLP Resolution
What about asylum? (I know - taken, it just tickled my funny bone). Santuario I quite like! Cheers, Berin Raul Benito wrote: Sad, I like the name, Perhaps a translation: Santuario(Spanish), Santuarium(Latin) or a synonym Tabernaculum... Just wild guessing.. On 5/3/06, Jesse Pelton [EMAIL PROTECTED] wrote: Good catch. It's a registered trademark, no less, and in a related field, so I doubt SecureWave would be pleased to have Apache use it for a project name. Too bad. -jesse- -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 03, 2006 10:26 AM To: security-dev@xml.apache.org Subject: Re: TLP Resolution Sanctuary is a cool name. However there is a product named Sanctuary by SecureWave: http://www.securewave.com/endpoint_security_solutions.jsp --Sean -- http://r-bg.com
Re: TLP Resolution
Werner just stired the pot on this in another forum, so I thought I'd come back to it again. Name aside (although I kinda like Sanctuary or some variant thereof), I could just update the charter at the end of this trail and remove XML from the words XML Security - so we end up with just stuff about security technologies. That's a simple way forward - we create software relating to security. I note also Raul's thought on lack of resources. My take on that is that by promoting to TLP we are not immediately doing more - but we are providing more visibility of what we are doing. That's probably the best way to start getting a broader audience interested in what we are doing. Thoughts welcome. Cheers, Berin Jesse Pelton wrote: Some random ideas to get the name game going, based on your indicated vision for the project: SecureSoft, Security Software, Vault, Shield, Armor, Guard, Sanctuary, ,Citadel, Surety, Security Blanket (or Linus, with a nod to Charles Schulz' Peanuts, but you'd want to get permission). With the possible exception of the last, none of these indulge the Apache penchant for obscure references, though. But the name is really the last piece. You need a clearly articulated purpose and scope before you can come up with a name that fits. -Original Message- From: Berin Lautenbach [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 15, 2006 3:13 AM To: security-dev@xml.apache.org Subject: Re: TLP Resolution Thoughts welcome :. Berin Lautenbach wrote: OK - I'm going to take the idea to the board. Before I do - we need a couple of things. 1. A name. I'd personally be against anything fancy or non-obvious. But I don't really want to use Apache Security as I think it will get too confusing against the security group within the ASF (the group that looks after security bug reports etc.) Apache Infosec? Apache Secure? Obviously there is a reason I never went into marketing :. 2. A scope. Probably not hard. ...open-source software related to security... is a good place to start I suspect :. I also wouldn't mind to take some first steps as to what we want to do. Obviously set up xml-security and JuiCE, but I'd personally like to see the ASF become a source of best practice for security software as well. Longer term - but an interesting goal for a tlp within the ASF. And if we are going to use this as an exercise in raising interest in what we are doing inside/outside the ASF, then we want to think about what kind of message we want to give people when the project goes to top level. I'd also like to use it as a central point people can go to in order to see all security related software in the ASF. Not to have projects like WS-Security under the security project, but to have links to other projects/efforts in the ASF that are related to security software. Thoughts welcome! Cheers, Berin Ben Laurie wrote: Davanum Srinivas wrote: Dear Ben and Dear Ben, what do you guys think? A Security Federation/TLP/PMC. Starting with Apache XML-Security and Apache Juice. It sounds like a very good idea to me, I'd certainly support it. Of course, we already have a CA. Written in, errr, perl :-) Cheers, Ben. thanks, -- dims On 3/11/06, Berin Lautenbach [EMAIL PROTECTED] wrote: I would be interested in widening it as well - with the proviso that it is like a federation. I.e. we use it to seed projects then build them and spawn them into TLPs once they grow to size. I might start sounding some people out. Dims - what's your thoughts? On the subject - having spent the most of Saturday searching for a decent Open Source CA, I'd now be interested in building one that doesn't use [EMAIL PROTECTED] perl. I.e. do the core in C++ with perl/PHP being used for the interfacing only. Cheers, Berin Werner Dittmann wrote: +1 from me. Just a comment regarding the charter: is it really only Apache XML Security? IMHO this would be a bit too narrow, for example JuiCE is not dependent on XML, maybe other security related software will be pop up later as well. I would like to see an Apache Security PMC that would address all kind of security relevant software and act as a solid base to deliver security functions to other Apache projects. Also we may think to browse existing Apache projects to see if there is already software (maybe even multiply implemented) and pool them here. BTW, I would be happy to be a part of this activity. Regards, Werner Berin Lautenbach wrote: Peoples, Sometime back we talked about becoming a TLP. With the recent JuiCE efforts, + JSR 105 + XKMS we are starting to see a few different things occuring. I'd be hugely in favour of starting something at a higher level in Apache to get some visibility. I'm also toying with the idea of creating a broader security project/federation to encourage that kind of software within
Re: configure.ac issues in xmlsec-c
Scott Cantor wrote: Basically I get undefined symbols that are in the libCrun library because it tries to link the openssl func test program with cc, but with -lxerces-c. Got it. I've been using CC as the c compiler as well as the C++ compiler (cheating :). Will fix. Cheers, Berin
Re: configure.ac issues in xmlsec-c
I'll take you up on that. I'm very close. I want to cut a RC this
weekend and get on the list. I'll then separately update the docs. But
I've changed a bit in configure.ac, so the more testing it gets the
happier I will be.
As an aside - are you interested in committer access to the code base?
If you run into things like this I'm always happy to put the fixes in,
but it might be quicker for you to just commit the changes directly.
You're call - I just appreciate the feedback :.
Cheers - and thanks!
Berin
Scott Cantor wrote:
I've run into a number of configure issues in the past porting to various
platforms, particular when not using gcc/g++.
A couple of noteworthy ones on Solaris using Sun's compiler:
You have gcc-specific flags here:
if test $enable_debug = yes ; then
CFLAGS=${CFLAGS} -g
CXXFLAGS=${CXXFLAGS} -g
else
CFLAGS=${CFLAGS} -O2 -DNDEBUG
CXXFLAGS=${CXXFLAGS} -O2 -DNDEBUG
fi
-O2 isn't legal on Sun's compiler (it's -xO2) so I would suggest you add a
conditional around this for at least that flag and not include it unless gcc
is used.
Also, for Sun CC, you can't properly link test cases that run with
AC_LANG(C) if your LDFLAGS already includes C++ code, like Xerces or Xalan.
This results in the openssl func checks failing because AC_LANG(C) appears
ahead of those tests.
I would suggest either moving the OpenSSL tests ahead of the C++ library
checks, or removing AC_LANG(C), which works ok too.
-- Scott
Re: Change suggestion
Matthias,
It's taken me a while - but I have added this into the svn in
preparation for the 1.3 release.
Thanks!
Cheers,
Berin
Matthias Niggemeier wrote:
Hi there!
I would suggest the following change to xsecerror.hpp:
#define XSECnew(a, b) \
try \
{\
if ((a = new b) == NULL) \
{ \
throw XSECException (XSECException::MemoryAllocationFail); \
} \
} \
catch (XSECException e) \
{\
throw XSECException (XSECException::InternalError, e.getMsg()); \
}\
catch (...) \
{ \
throw XSECException (XSECException::MemoryAllocationFail); \
}
(the new part is catch (XSECException e))
I would suggest that to ensure that exceptions thrown in a constructor
(as e.g. in WinCAPICryptoProvider) can be properly handled. Without the
new catch, the error message generated in the constructor is thrown away.
Regards
Matthias
Re: xsec-c manifest digest calculation
Hmm. Nice pickup. This used to be fine because the interlocking was
assumed to be required, so on the second run through, the actual
manifest references would have settled and wouldn't change. Thus the
setting of the overall manifest hash would work fine.
Of course, when I introduced the interlocking flag, that logic broke
Thanks for that! I will make this change in svn as well.
To actually answer your question - no I cannot see any other impact this
would have - other than to make it work correctly :.
Cheers,
Berin
Peter Gubis wrote:
Hi,
I had problems with signing messages using manifest references. If
signature element contains more than one manifest references, the digest
of the last reference pointing to the last manifest object is not
correctly calculated. After some debugging I found, that the digest in
Reference node is calculated from Manifest node before the correct
digest is inserted.
In xsec source code I found one recursive method, that calculates hashes
for references and sets that hash to the proper place in the DOM
structure. I think, that there is a bug, which firstly sets the hash of
the reference and after that calculates hashes in referenced manifests.
In the file src\dsig\DSIGReference.cpp in method
DSIGReference::hashReferenceList on line 855 you can see:
for (int j = 0; j i; ++j) {
r = lst-item(j);
r-setHash();
// If this is a manifest we need to set all the references in
the manifest as well
if (r-isManifest())
hashReferenceList(r-getManifestReferenceList());
}
I changed sequence to firstly calculate the hash in Manifests and just
after that to set the hash of the reference node, and now it seems that
it's working correctly.
Updated code:
for (int j = 0; j i; ++j) {
r = lst-item(j);
// If this is a manifest we need to set all the references in
the manifest as well
if (r-isManifest())
hashReferenceList(r-getManifestReferenceList());
r-setHash();
}
Now it seems, that both the hash of manifest and the hash of reference
are correct. Either signature is processed correctly. Can this change
have impact to another unexpected behavior of this method?
Thank you and best regards,
Peter.
Re: Using XERCES with XPath support
Yes - if you want XPath you need to use the Xalan library. The Xalan DOM cab be a wrapper around the Xerces DOM - which means you can use XPath to find what you want in the DOM and then map the Xalan node back to a Xerces node that allows you to then change the DOM. (At that point you need to re-wrap the Xalan DOM, but generally it's passed its use by then anyway). There are some examples in the Xalan site, and there is some code in the xml-security library that calls on Xalan for some of the transformations that might provide some pointers as well. Have a look at the txfmxpath.cpp file. Cheers, Berin Reuven Nisser wrote: Hello, I have an application relying heavily on XML. I am currently using MS-XML4. The application imports, builds, changes and exports XML documents and uses XPATH to find notes. The main reason for switching to XERCES is using Apache XML Security later. I am trying to migrate the application, I started with XERCES and then found out it has no XPATH support. I continued with XALAN but it does not allow to change the XML and if I use a wrapper I will need to rebuild it after each XML change. Do, where do I go from here? Is it possible to use Apache XML Security with other XML libraries? Especially with MS-XML 4? Thanks, Reuven Nisser
Re: C++ feature request
Scott Cantor wrote: What about another three methods on XENCCipher DOMNode * encryptElementDetached(.) DOMNode * encryptElementContentDetached() DOMNode * decryptElementDetached(..) These have been checked into svn - very simple but seem to work OK. Cheers, Berin
Re: How to encrypt an external reference ?
Hmm. Is this the Java library you are using or the C++ library? I'm not sure if either allows this directly! They can both decrypt a reference but I'm not sure if they can encrypt one. Cheers, Berin Hess Yvan wrote: Hi, I have an external document attached to my XML document and I would to encrypt it. Finally, I expect to have in my XML document the following result bellow. How do I have to proceed, I didn't find a way how to encrypt an external reference using Apache XML security. Thanks for your help. Yvan Hess edoc:EncryptionBlock xmlns:ds=http://www.w3.org/2000/09/xmldsig#; xmlns:xenc=http://www.w3.org/2001/04/xmlenc#; id=Revision-1-Encryption-1 xenc:EncryptedKey Id=Revision-1-Encryption-1-EncryptedKey-1 xenc:EncryptionMethod Algorithm=http://www.w3.org/2001/04/xmlenc#rsa-1_5/ ds:KeyInfo ds:KeyNameSphinxTest/ds:KeyName /ds:KeyInfo xenc:CipherData xenc:CipherValueyWyiuB02b2P2p8jqJhE./xenc:CipherValue /xenc:CipherData xenc:CarriedKeyNameGenerated-AES-SecretKey/xenc:CarriedKeyName /xenc:EncryptedKey xenc:EncryptedData Id=Revision-1-Encryption-1-EncryptedData-1 xenc:EncryptionMethod Algorithm=http://www.w3.org/2001/04/xmlenc#aes128-cbc/ ds:KeyInfo ds:KeyNameGenerated-AES-SecretKey/ds:KeyName /ds:KeyInfo xenc:CipherData xenc:CipherReference URI=urn:hypersuite:534177D3-C0A8027601B4E829-57982AC1/ /xenc:CipherData /xenc:EncryptedData /edoc:EncryptionBlock
Re: xml encryption/decryption of binary data
Hess Yvan wrote: 3. Then I have to encrypt the external binary urn:hypersuite:534177D3-C0A8027601B4E829-57982AC1 MANUALLY. I didnt find a chance to do it using XML security. It seems that the functionalilty is implemented into Apache xml-signature but not into Apache xml-encryption. I thing I will have the same problem for decryption :-) The reason it currently has to be done manually is that encryption is very different to reading a URL for signing. For signature, we just read the reference URL and create the signature completely separately - it does not impact the source data in any way. In the encryption case, we not only have to read the data from the URL, we have to overwrite it with the encrypted data. There are cases where that's possible, but it's definitely not trivial! I can't speak for the Java library off the top of my head, but the C++ library allows you to decrypt. However the return data is a byte stream - not an overwrite of the referenced URL. Cheers, Berin
Re: xml encryption/decryption of binary data
Larchier Christophe wrote: I have to sign then encrypt the documents, so they must be exactly the same before and after encryption/decryption. If the start document has an xml header, the finish document must have the xml header (even if it is superfluous). snip Now, as the 2 documents are not identical it's not possible to verify the signature. How are you signing the document? Obviously not with XML-Signature, so must be PGP or some such? Cheers, Berin
Re: xml encryption/decryption of binary data
Christophe, I'm not 100% sure I understand the problems, but I'll try to give some thoughts. The xml header is added (or not added) as part of the serialisation process. How do you serialise your document once you have done the encryption? For the decrypt - that looks fine. Can you post more code? I'm not an expert on the Java library, but others on the list may be able to assist with more code to look at. It is possible to do encryption of binary data, but you cannot simply add it to the document. If you want it inside the XML, you need to encode it (generally base64) and then add it. The resultant XML can then be encrypted. The alternative is to place the binary data in a separate file and have a reference to that file in the XML document. But I don't think that is quite what you want. Cheers, Berin Larchier Christophe wrote: Nobody uses xml encryption with binary datas ??? -Message d'origine- *De :* Larchier Christophe [mailto:[EMAIL PROTECTED] *Envoyé :* mercredi 29 mars 2006 17:41 *À :* security-dev@xml.apache.org *Objet :* xml encryption/decryption of binary data Hi all, When I use apache xml security library to encrypt an xml document like the following one, the xml header is loosen. ?xml version=1.0 encoding=UTF-8? PurchaseOrder ... /PurchaseOrder After encrypting/decrypting, I get only : PurchaseOrder ... /PurchaseOrder I use the doFinal() method to encrypt/decrypt with the all document as parameter : xmlCipher.doFinal(doc, doc); How do you manage this ? Is it possible to do xml encryption with binary datas ? I have tried to insert my binary datas into a dom document, but some special characters are added (to replace \). Thanks, Christophe
Re: xml encryption/decryption of binary data
Larchier Christophe wrote: Thanks for your answer, Berin. My need is to encrypt a complete xml file (with the xml header, the blank lines etc.) and not only a DOM document (which is the xml file parsed) because when the file is parsed some informations are loosen. Just so I understand - what information is lost in your application? The xml header is not necessary if the encoding is UTF-8, as the XML version is 1.0, so all the information contained in the header is known. The encryption process should not throw any blank lines away unless they are in places where the spec defines that they do not matter - e.g. the_element attribute1=1 attribute2=2 /the_element Will get transformed to the_element attribute1=1 attribute2=2 /the_element as lines between attributes do not count as information in XML. But the lines in the text node are definitely kept. If I can understand what information is being lost during parsing I might be able to come up with something that will work. Cheers, Berin So, I think that I must consider the xml file as binary datas. If I understand your answer, I have to create a DOM document with a dummy element containing the binary datas base64 encoded and then encrypt with doFinal(doc, dummyElt, true). I will get something like that : dummy xenc:EncryptedData xmlns:xenc=http://www.w3.org/2001/04/xmlenc#; MimeType=application/XML Type=http://www.w3.org/2001/04/xmlenc#Content; ... /xenc:EncryptedData /dummy It's not a very interoperable solution because the receiver must know that the dummy element must be removed and that the datas must be base64 decoded. An improvement could be perhaps to remove the dummy level node and remove the Type attribute (Type=http://www.w3.org/2001/04/xmlenc#Content;), but there is still the problem of base64 encoding/decoding. Do you have a better idea/solution ? Christophe -Message d'origine- De : Berin Lautenbach [mailto:[EMAIL PROTECTED] Envoyé : vendredi 31 mars 2006 10:59 À : security-dev@xml.apache.org Objet : Re: xml encryption/decryption of binary data Christophe, I'm not 100% sure I understand the problems, but I'll try to give some thoughts. The xml header is added (or not added) as part of the serialisation process. How do you serialise your document once you have done the encryption? For the decrypt - that looks fine. Can you post more code? I'm not an expert on the Java library, but others on the list may be able to assist with more code to look at. It is possible to do encryption of binary data, but you cannot simply add it to the document. If you want it inside the XML, you need to encode it (generally base64) and then add it. The resultant XML can then be encrypted. The alternative is to place the binary data in a separate file and have a reference to that file in the XML document. But I don't think that is quite what you want. Cheers, Berin Larchier Christophe wrote: Nobody uses xml encryption with binary datas ??? -Message d'origine- *De :* Larchier Christophe [mailto:[EMAIL PROTECTED] *Envoyé :* mercredi 29 mars 2006 17:41 *À :* security-dev@xml.apache.org *Objet :* xml encryption/decryption of binary data Hi all, When I use apache xml security library to encrypt an xml document like the following one, the xml header is loosen. ?xml version=1.0 encoding=UTF-8? PurchaseOrder ... /PurchaseOrder After encrypting/decrypting, I get only : PurchaseOrder ... /PurchaseOrder I use the doFinal() method to encrypt/decrypt with the all document as parameter : xmlCipher.doFinal(doc, doc); How do you manage this ? Is it possible to do xml encryption with binary datas ? I have tried to insert my binary datas into a dom document, but some special characters are added (to replace \). Thanks, Christophe
Re: Problem with rsa-1_5 padding mechanism
Hess Yvan wrote: - Does it means that XML apache security using RSA/ECB/PKCS1Padding is the correct one and that IBM XSS4J contains a critical bug ? - Is it right to map RSA 1.5 alg to a Java Cipher RSA/ECB/PKCS1Padding ? PKCS1Padding is the most common form of padding for RSA. There is also OAEP, which is supported within the dsig spec. Using RSA without padding is potentially dangerous - lack of padding can lead to potentially easy to decipher ciphertext when the plain text sizes are small. So to answer your questions - PKCS1 padding is correct, and if XSS4J is uing no padding, it is an error. However I would be surprised if this were the case - would be interesting to understand some background. - Needs to be answered by the more Java minded people, but from memory that is correct. Cheers, Berin
Re: Signing only a few nodes, not the whole document
[EMAIL PROTECTED] wrote: I want to sign only some nodes in my document. As I understand it, this can be made with an id-attribute. This is not really the way I want to do it. If I got it right, it should be possible to do something like this if I want to sign all creditCardNo nodes: DSIGReference* ref = sig-createReference(MAKE_UNICODE_STRING(#xpointer(//creditCardNo))); which now results in the following error: = Message: Unsupported Xpointer expression found The xpointer support is not that complex. The standard requires support for barename Xpointer URIs (#id) and recommends support for #xpointer(/) and $xpointer(id(id)). So you either need to use an Id (the common way to do it) or use an XPath transform to select the nodes you want to use. Cheers, Berin
Re: svn / cvs help
I will try to get this updated this weekend. Raul Benito wrote: We must change this Are there any people in the list(with good English skills) that want to update the documentation? - The svn info - More examples, articles.. - Links to articles... They will be very appreciated.. I will pay with virtual beers ;) On 3/22/06, Davanum Srinivas [EMAIL PROTECTED] wrote: plz run svn co http://svn.apache.org/repos/asf/xml/security/trunk xml-security On 3/22/06, Chris Black [EMAIL PROTECTED] wrote: I am trying to pull down the latest devel version of the xml security java library, but am having issues. I am trying to follow the directions on http://xml.apache.org/security/download.html but they don't seem to be working (I am unable to do a cvs login with those directions). There are also broken links to viewcvs in both the main site and the java-specific section. I notice in some bugzilla entries there are references to svn, which makes me think that the project has moved to svn but the page has not been updated. Could someone please let me know how to pull down the devel tree? Thanks, Chris -- Davanum Srinivas : http://wso2.com/blogs/ -- http://r-bg.com
Re: [C++] Full XKMS Message Set Implemented
Scott Cantor wrote: Berin Lautenbach wrote: Have you built Xerces 2.7.0 on VS 2005? If so - did you just convert the 7.0 project files? Or are you linking against Xerces 2.7 built on 7.0 or 6.0? Yes, I rebuilt it on 2005 by converting the projects. I don't recall any major trouble with it. No - fairly easy. Xalan on the other hand is a beast to convert. Not going to bother. Unless someone else volunteers to do the work (:) VC 2005 support will only be for a Xerces build until Xalan 1.11 (or 2.0) is released. Cheers, Berin
Re: [C++] Full XKMS Message Set Implemented
Scott Cantor wrote: At a minimum, I'd suggest some minor fixes needed so the code will build cleanly on the latest MS compiler (VS 2005), which I can supply for the no-xalan build, at least. Also optionally check in some project files for that version instead of forcing people to convert the 7.0 projects files, although that mostly works fine. Have you built Xerces 2.7.0 on VS 2005? If so - did you just convert the 7.0 project files? Or are you linking against Xerces 2.7 built on 7.0 or 6.0? As an aside, I've been having a look at the svn version of Xerces and there appears to be a fair few changes in preparation for a 3.0 release. So I'm currently planning to support 2.7, not 3.0. I think we can release another 1.3.x version once Xerces 3.0 is released. Cheers, Berin
Re: Support for OpenSSL 0.9.6
Scott Cantor wrote: What's people's thoughts? There are some deprecated calls into OpenSSL that I'd like to drop out of the library, but it would break 0.9.6 support. Should we keep supporting it, or just make the call that we support n-1 and go with that? I would have to vote against dropping it, mainly because I'm still stuck supporting some platforms that shipped with 0.9.6. Can you ifdef around the deprecated calls? Yes - I was hoping to get away with being lazy :. I will work around it. Cheers, Berin
Re: C++ feature request
Actually makes good sense, and shouldn't be a big deal to do. It's just a matter of breaking the existing functions in two. What about another three methods on XENCCipher DOMNode * encryptElementDetached(.) DOMNode * encryptElementContentDetached() DOMNode * decryptElementDetached(..) The result is passed back as a DOMNode because the result of a decrypt might be a Document Fragment or an element. The returned DOM structures would be owned by the original document, but detached from that document, and nothing in the original document will have been modified. How does that sound? Cheers, Berin Scott Cantor wrote: Probably too late to be considered for 1.3, but I thought I'd ask anyway... I'm seeing an upcoming problem in that the Encryption/Decryption calls assume that I want to replace the nodes being fed in with the result (in either direction). In my particular library, this will cause some problems because of the objects I've got wrapped around the DOM and I'd prefer to manage the node replacement myself when I'm ready to do it. It occurs to me that I could maybe work around it if the old nodes aren't explicitly wrecked or disposed of by the API calls, but I haven't tried it yet, and it would be simpler to be able to signal that somehow. Is that possible? -- Scott
Re: Build issues on RedHat enterprise 4
Peter, On the second issue - where the include files were installed but not the library - did you get /work/xml-security/1.2.1/lib created, but where lib was actually a file, not a directory? I've found that if the directory structure does not exist, the install breaks after create the library as the lib component of the path structure. Cheers, Berin [EMAIL PROTECTED] wrote: Dear XMLSEC developers, I am new here so forgive me if I am wrong here, but I have a few problems First of all I can't build xalan 1.9.0 with gcc 3.4.4. That has been reported as a bug and fixed in r342313 in svn. So this led me to checking out r342313 from svn. I usually build with --prefix to be able to have several versions of all stuff in a neat order. This goes ok as expected with both xalan and xerces. I ran runConfigure with -P/work/xalan/1.9.0 Now when I try to point out these directories where I have installed xerces and xalan for XMLSEC, by setting XALANCROOT nad XERCESCROOT to the directories where I have installed xerces and xalan the configure script complains. Obviously the configure script want me to point out the source distribution directory, not the place where I have installed. My first question: Is it a correct behaviour to expect the source distro to be present in XALANCROOT and XERCESCROOT? Shouldn't it be enough with the installed stuff ( in my case the dir /work/xalan/1.9.0 where I have the dirs bin, include, lib.) My second question: running configure --prefix=/work/xml-security/1.2.1. Then compiling will only result in installing the dir named include. It seems like lib and bin are missing here. Shouldn't at least lib also be installed in /work/xml-security/1.2.1? Best regards, Peter ***Internet Email Confidentiality Footer*** The contents of this e-mail message (including any attachments hereto) are confidential to and are intended to be conveyed for the use of the recipient to whom it is addressed only. If you receive this transmission in error, please notify the sender of this immediately and delete the message from your system. Any distribution, reproduction or use of this message by someone other than recipient is not authorized and may be unlawful.
Re: TLP Resolution
Thoughts welcome :. Berin Lautenbach wrote: OK - I'm going to take the idea to the board. Before I do - we need a couple of things. 1. A name. I'd personally be against anything fancy or non-obvious. But I don't really want to use Apache Security as I think it will get too confusing against the security group within the ASF (the group that looks after security bug reports etc.) Apache Infosec? Apache Secure? Obviously there is a reason I never went into marketing :. 2. A scope. Probably not hard. ...open-source software related to security... is a good place to start I suspect :. I also wouldn't mind to take some first steps as to what we want to do. Obviously set up xml-security and JuiCE, but I'd personally like to see the ASF become a source of best practice for security software as well. Longer term - but an interesting goal for a tlp within the ASF. And if we are going to use this as an exercise in raising interest in what we are doing inside/outside the ASF, then we want to think about what kind of message we want to give people when the project goes to top level. I'd also like to use it as a central point people can go to in order to see all security related software in the ASF. Not to have projects like WS-Security under the security project, but to have links to other projects/efforts in the ASF that are related to security software. Thoughts welcome! Cheers, Berin Ben Laurie wrote: Davanum Srinivas wrote: Dear Ben and Dear Ben, what do you guys think? A Security Federation/TLP/PMC. Starting with Apache XML-Security and Apache Juice. It sounds like a very good idea to me, I'd certainly support it. Of course, we already have a CA. Written in, errr, perl :-) Cheers, Ben. thanks, -- dims On 3/11/06, Berin Lautenbach [EMAIL PROTECTED] wrote: I would be interested in widening it as well - with the proviso that it is like a federation. I.e. we use it to seed projects then build them and spawn them into TLPs once they grow to size. I might start sounding some people out. Dims - what's your thoughts? On the subject - having spent the most of Saturday searching for a decent Open Source CA, I'd now be interested in building one that doesn't use [EMAIL PROTECTED] perl. I.e. do the core in C++ with perl/PHP being used for the interfacing only. Cheers, Berin Werner Dittmann wrote: +1 from me. Just a comment regarding the charter: is it really only Apache XML Security? IMHO this would be a bit too narrow, for example JuiCE is not dependent on XML, maybe other security related software will be pop up later as well. I would like to see an Apache Security PMC that would address all kind of security relevant software and act as a solid base to deliver security functions to other Apache projects. Also we may think to browse existing Apache projects to see if there is already software (maybe even multiply implemented) and pool them here. BTW, I would be happy to be a part of this activity. Regards, Werner Berin Lautenbach wrote: Peoples, Sometime back we talked about becoming a TLP. With the recent JuiCE efforts, + JSR 105 + XKMS we are starting to see a few different things occuring. I'd be hugely in favour of starting something at a higher level in Apache to get some visibility. I'm also toying with the idea of creating a broader security project/federation to encourage that kind of software within the ASF. Thoughts? Draft proposal for the board below. If we want to do this - all active committers will need to vote either on this or on a broader (or even narrower!) charter terms of reference that we all can agree to. Cheers, Berin WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to XML security technologies, for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache XML Security PMC, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache XML Security PMC be and hereby is responsible for the creation and maintenance of software related to creation and maintenance of open-source software related to XML security technologies based on software licensed to the Foundation; and be it further RESOLVED, that the office of Vice President, Apache XML Security be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache XML Security PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache XML Security PMC; and be it further
Re: Build issues on RedHat enterprise 4
[EMAIL PROTECTED] wrote: My first question: Is it a correct behaviour to expect the source distro to be present in XALANCROOT and XERCESCROOT? Shouldn't it be enough with the installed stuff ( in my case the dir /work/xalan/1.9.0 where I have the dirs bin, include, lib.) It is the expected behaviour - but I'd agree it's not correct. I will look at it (probably on the weekend). Really configure should be able to work out whether it is pointed at a source distro or an install. My second question: running configure --prefix=/work/xml-security/1.2.1. Then compiling will only result in installing the dir named include. It seems like lib and bin are missing here. Shouldn't at least lib also be installed in /work/xml-security/1.2.1? That is not even expected behaviour. Let me look at this one a bit closer. Best regards, Peter ***Internet Email Confidentiality Footer*** The contents of this e-mail message (including any attachments hereto) are confidential to and are intended to be conveyed for the use of the recipient to whom it is addressed only. If you receive this transmission in error, please notify the sender of this immediately and delete the message from your system. Any distribution, reproduction or use of this message by someone other than recipient is not authorized and may be unlawful.
Re: [C++] Full XKMS Message Set Implemented
Scott Cantor wrote: Most of the 64-bit warnings are probably from Xerces, but if you have anything you can fix there, it would also be appreciated. I'm getting more demand for 64-bit builds lately. Hmm. Don't have a 64 bit system to do a build on. Must try and see if I can track something down. That's part of it, particularly making sure things are as stateless as possible. Right now, I have this extra XSECProvider thing I'm lugging around as a (nearly) global variable just to create and release signatures, but it doesn't seem to add any actual value. The original idea was that it could re-use objects rather than completely deleting and re-allocating all the time. That was the idea - but I haven't yet had time to make it work. The other part was as a message factory - I'm trying to hide the implementation from the user. If you look at the XKMS classes they are completely interface only now. That's where I want the Signature classes to be as well. The message factory side of it could potentially be done using static methods, but I wanted to avoid that to keep thread handling simpler in complex applications. (Mind you, if we passed ownership straight to the caller then thread issues are pretty much non-existant - it's only an issue if we continue to keep a memory of all signatures we have allocated.) I've also been looking ahead to the encryption stuff, and I'm not sure I understand the implications of the XSECEnv yet. I'm generally sensitive to lugging around other objects I need to manage because of the hairiness of DOM management in Xerces-C. Anyway, I don't have much to suggest yet, and it wouldn't be on this timeline. Where are you seeing an XSECEnv? That should be completely hidden unless you are manipulating the implementation classes directly! If you are having to manipulate the Env class directly for normal operations then I have a bug somewhere. For encryption the only things you should need are the Cipher and provider classes. I need the env class within the implementation classes to link the various parts of a Cipher object together. As an example, if we need to create a CipherReference, it needs to be a part of the document for the EncryptedType. Similarly, I needed a place to store information about namespace qnames without having to look at the owning object. I started out by always going back to the parent class, but that gets really ugly in a few places (some objects can have different parent classes in the message sense) and I found the easiest way to handle things was to have an environment object that exists as a part of a particular message. There is a super object from which all the others are derived during message creation (to keep consistent qnames and the like), but again you shouldn't have to worry about it. Generally only the EncryptedType has an actual env object - all the sub-objects have a link only. Really it just encapsulates all the information that is common for all the objects that make up an EncryptedType object. There is probably a nicer way to do it, but I couldn't see it :. Cheers, Berin
Re: [C++] Full XKMS Message Set Implemented
Scott Cantor wrote: At a minimum, I'd suggest some minor fixes needed so the code will build cleanly on the latest MS compiler (VS 2005), which I can supply for the no-xalan build, at least. Also optionally check in some project files for that version instead of forcing people to convert the 7.0 projects files, although that mostly works fine. Yup - already working on it. I tend to do most of my work on Linux and VC 6.0 and then when it's all looking OK build up the other compilers/platforms. Otherwise I waste a lot of cycles doing point fixes to projects. There were some new source files not added to the MS project in svn as well, but that's easy to fix also. I'd also suggest copying some more of the Xerces version header machinery into the XMLSec one. That makes it easier for people to do autoconf version checks, and since 1.3 has some good new APIs, I know I at least need to check for it. Hmm. Good idea. Will have a look-see. Most of the rest of my thoughts center on a bit of reworking of the whole document management approach, the XSECProvider concept, and some of that, but I haven't had a chance to really formally propose anything, so I'd say do a 1.3 and then maybe look at that stuff later if anybody is so inclined. Most interested to hear thoughts. I have been wanting for a while to head back to DSIGSignature and rework that into more of a factory approach than currently exists but I think you mean more than that? Cheers, Berin
Re: TLP Resolution
Ben Laurie wrote: It sounds like a very good idea to me, I'd certainly support it. Of course, we already have a CA. Written in, errr, perl :-) GRIN. Was waiting for the perl comment :. To put into context, my original comment was after spending 5 hours fighting with OpenCA. Cheers, Berin
Re: TLP Resolution
I would be interested in widening it as well - with the proviso that it is like a federation. I.e. we use it to seed projects then build them and spawn them into TLPs once they grow to size. I might start sounding some people out. Dims - what's your thoughts? On the subject - having spent the most of Saturday searching for a decent Open Source CA, I'd now be interested in building one that doesn't use [EMAIL PROTECTED] perl. I.e. do the core in C++ with perl/PHP being used for the interfacing only. Cheers, Berin Werner Dittmann wrote: +1 from me. Just a comment regarding the charter: is it really only Apache XML Security? IMHO this would be a bit too narrow, for example JuiCE is not dependent on XML, maybe other security related software will be pop up later as well. I would like to see an Apache Security PMC that would address all kind of security relevant software and act as a solid base to deliver security functions to other Apache projects. Also we may think to browse existing Apache projects to see if there is already software (maybe even multiply implemented) and pool them here. BTW, I would be happy to be a part of this activity. Regards, Werner Berin Lautenbach wrote: Peoples, Sometime back we talked about becoming a TLP. With the recent JuiCE efforts, + JSR 105 + XKMS we are starting to see a few different things occuring. I'd be hugely in favour of starting something at a higher level in Apache to get some visibility. I'm also toying with the idea of creating a broader security project/federation to encourage that kind of software within the ASF. Thoughts? Draft proposal for the board below. If we want to do this - all active committers will need to vote either on this or on a broader (or even narrower!) charter terms of reference that we all can agree to. Cheers, Berin WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to XML security technologies, for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache XML Security PMC, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache XML Security PMC be and hereby is responsible for the creation and maintenance of software related to creation and maintenance of open-source software related to XML security technologies based on software licensed to the Foundation; and be it further RESOLVED, that the office of Vice President, Apache XML Security be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache XML Security PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache XML Security PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache XML Security PMC: !-- List out all committers in format of Berin Lautenbach [EMAIL PROTECTED] -- NOW, THEREFORE, BE IT FURTHER RESOLVED, than ?? [EMAIL PROTECTED] appointed to the office of Vice President, Apache XML Security, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache XML Security PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache XML Security Project; and be it further RESOLVED, that the initial Apache XML Security PMC be and hereby is tasked with the migration and rationalization of the Apache XML PMC XML Security subproject; and be it further RESOLVED, that all responsibility pertaining to the XML XML Security sub-project and encumbered upon the Apache XML PMC are hereafter discharged.
Re: TRANSFORM_XPATH2FILTER question
Stefano Del Sal wrote:
I'm trying to sign a document using the transform TRANSFORM_XPATH2FILTER,
but I get a bad signature if I try to use ONLY the filter
XPath2FilterContainer.SUBTRACT
1) Ex:
String filters[][] = {
{XPath2FilterContainer.SUBTRACT, //NotToBeSigned}
};
transforms.addTransform(
Transforms.TRANSFORM_XPATH2FILTER,
XPath2FilterContainer.newInstances(doc, filters)
);
I'm assuming that the input nodeset is everything in the document?
(E.g. URI=). If that's the case then this is a bug. Adding a union
(as in your second example) should not change the input node set for the
subtraction filter.
Unfortunately I'm not close enough to this code to fix it quickly.
Raul - do you know if anything changed in this area with the
optimisation work?
Cheers,
Berin
Re: base64 elements linebreak
Tech Rams wrote: BTW, OpenSSL has a flag for such cases - BIO_FLAGS_BASE64_NO_NL. Setting this flag would allow data with no line breaks to be decoded. I tried using this at one point. It caused yet more problems in that something *with* a line break at the correct point broke. So if you have something that is non-spec with where it puts the line break, you are out of luck. It also means you have to pre-scan the base64 text to work out what you are going to do - which is just plain ugly. Cheers, Berin
Re: Binary files corrupted
Sean, I have this memory of running into this somewhere as well and having to work around the issue - but I can't remember what I did :. One thing I vaguely remember is that some of the Junit test broke if you were not very careful about the files due to being used as input for actual signatures (i.e. not just as keys for signatures but as actual signed objects). Cheers, Berin Sean Mullan wrote: Correction: it appears these files were corrupted in cvs too (they also were not tagged as binary which may be the underlying problem). I guess I am the first to notice this as some new tests that I am including with JSR 105 try to parse these files. --Sean Sean Mullan wrote: Some of the binary files appear to have been corrupted in the transition from cvs to svn, such as the DER-encoded X.509 certificates in the test data directory (they are all off by a single byte). Has anyone else seen this and/or is this a known issue when converting cvs repositories to svn? I'm in the process of fixing these. --Sean
Re: [VOTE] Werner as juice committer
Geez - for some reason I thought he already was!!! +1 Cheers, Berin Davanum Srinivas wrote: As part of reviving juice, can we please VOTE werner as a committer to enable him to continue his offline work? [1] Here's my +1. thanks, dims [1] : http://www.nabble.com/Status-of-my-upgrades-and-so-on-t945224.html -- Davanum Srinivas : http://wso2.com/blogs/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
