Title: Message
Just
write a link between the serializer and an ostream&. Then you can dump to
cout or to a ostrstream or ostringstream and extract a char* from
that.
--
Scott
-Original Message-From: Milan
Tomic [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2003 11:29
AM
> I agree with that. I don't think the library should be guessing what an
> ID is in the signing case.
+1. With DOM3, the reasons for this hack are gone.
-- Scott
> What about a middle ground for transition. An explicit call has to be
> made into the library to enable the fudged Id in the signing case?
Yes, I could see making it optional behavior.
-- Scott
> For example, in the destructor of DSIGSignature, we have : delete[]
> mp_ecPrefixNS;
> It generates a bug .
Just curious, what did it do?
> if i replace with the code : XMLString::release(&mp_ecPrefixNS);
> i haven't got the problem.
>
> Have you got an idea ? did i have bad compilation
> My advice would be to remove the code that searches for
> attributes named id, or Id and force the application to
> manually register those ids.
+1.
But I'd add that Sun's inclusion of an XML parser in the JRE really
complicates this because it forces us to endorse a parser that does support
th
> Unfortunately the DOM API (regardless of level) has no way of
> registering that an attribute is of Type ID (except during parse with a
> DTD or schema). Level 2 and above have ways of finding (getElementById)
> and checking (isId), but no way of setting, other than at parse time.
DOM3 does.
> setAttributeId/setAttributeIdNS - was looking in the Java dox rather than
> C++. (Java dox on site seem rather old?)
> Thanks for pointing this out. I will look to see what we can do to remove
> this dependancy.
If you don't care about earlier Xerces versions, you can certainly rely on
it in t
> Back to square one :) Since we can't really wait for or
> depend on a specific Xerces version, we
> should fix the problem on our end.
Well, that would be nice, but I don't see how. There's no parser-independent
portable way to set ID attributes during document creation except for DOM3
which is
> I'm not sure I understand why it is tied to the parser.
> You can implement a solution for registering/retrieving
> IDs that is not dependent on DOM L3/Xerces, which is what
> we did for JSR 105. It is just a simple Map containing
> Elements and using the ID attribute value as a key...
Sorry, I
I guess the unstated point I'm trying make here is that the best world is
one in which the standard DOM calls are used in addition to whatever one-off
solution the libraries decide to implement.
It should be simple to conditionally call those methods (if they exist) as a
consequence of the proprie
> Version 2? There has been talk about a version 2 and what should be in
> there.. Hell I have been talking about it for months, but as far as I know
> there's not a single line of code in CVS for it.
There's a 2.0 jar sitting right on the download site, and we're using it
because of various iss
With the talk of a release, I'd note that the Java Base64 encoder in the
utility class is still adding an extra linefeed when the encoded data ends
up exactly on a line wrap boundary (e.g. last line of 72 chars if wrap
length is 72).
This is treated as invalid by the Xerces C++ base64 data type va
> For now I've fixed the bug in CVS - probably best to not introduce
> anything majorly new until after 1.1.
Thanks much. I'm hoping to be able to ship the next Shibboleth/OpenSAML
releases with the 1.1 versions of both languages, this will give me
additional incentive. ;-)
-- Scott
> Some time ago (6 weeks or so) I did some performance measures (WSS4J has
> timing logs build in) and we see here that Verification/Signature
> is real time consuming, followed by public KEy encryption, followed
> by symmetrical encryptionthis ordering comes with no surprise.
>
> Only the rea
> Is this an open-source effort? (JCE Interface to OpenSSL)?
> i'd like to use it as well.
Yeah, but it's not in the form of a complete solution so user beware. Just a
few needed algorithms and operations are implemented, and we don't implement
RSA crypto directly because it's not a signed JCE. Y
> You mentioned in your previous e-mail that you have seen significant
> performance improvements. Is this when interfaced with xml-security?
Yes, exactly. We edit the config.xml to reference the OpenSSL shim provider
for RSAwithSHA1, some hashing, etc. That static approach to the JCE
selection
> Can you please post your config.xml?
I don't actually have it configured in or tested yet, I was busy playing
with Phaos' JCE while they were building this thing. I'll ask them to give
me a copy.
I can tell you more or less what's involved. You just go down into the
section under providers and
> You're saying you need Linux support from PKCS11 hardware devices,
and
> haven't found any?
Rainbow is a fairly good example. They have a working PKCS11 library for
Linux but they won't give it to you without some real begging and no
support. More importantly, it turns out in Rainbow's cas
> Was reviewing the codeQuestion - If we write a class that
> extends SignatureAlgorithm (see SignatureBaseRSA$SignatureRSASHA1 for
> example, we should be able to use the NativeJCE jar without
> having to sign it first). Right?
Yes, signature providers can be unsigned, it's encryption provid
> 2. Allowable names for Id attributes are now stored in a list. This
> list can be added to by the calling program using new methods on
> DSIGSignature.
I like this. It lets you work around situations where you don't have DOM3
support, in Java especially.
> As an aside, the DSIGSignature cla
> Given the Java library is unlikely to happen this weekend (unless people
> help - hint hint :>), do people think we should try to get this ID
> handling functionality into it prior to a release?
I'm agnostic, since I don't generally rely on unreleased functionality. I'm
already using DOM3 calls
> Would it be useful to have the ability to have name based Id searching
> turned off?
In a release, yes, I would probably turn it off. I probably wouldn't be
relying on anything until it's officially out, so there's no need to rush
anything in on my account.
-- Scott
> > Could those who are interested have a look at :
> >
> http://nagoya.apache.org/wiki/apachewiki.cgi?XMLProjectPages/O
penSSLJCEProposal
> >
> > Make sure it all looks OK? Feel free to update, and come back to the
> > list if you are uncomfortable with the proposal?
Made a couple of minor ch
> Can you please send me the details of EXACTLY what kind of
> jar signing needs to be done to get the
> RSA stuff working? I dug/googled a bit but could not find the details.
Here's the relevant pointer:
http://java.sun.com/j2se/1.4.2/docs/guide/security/jce/HowToImplAJCEProvider
.html
Basical
> In my mind, the naming should somehow reflect the aim of the project
> (which is something that also seems to be less than clear to me in
> the proposal).
Make Java xmlsec usable for high-volume deployments. It's currently not, and
hardware acceleration for Java is hard to get for some platform
Is it me, or is the install-sh stuff in the package broken on Solaris? I get
errors from missing copies of install-sh and have to manually copy it from
the root into each subdirectory, which is a serious PITA.
-- Scott
> I thought I tested this.
>
> Will have a look-see tonight and see what is wrong.
On 2.8, I'm also getting failures in which the include tree isn't deep
copied during the install. Maybe some newer version of some GNU-related
package is needed?
-- Scott
> Make install works on the Solaris 2.8 system that we have access to, but
> I suspect that's because we have the GNU install (fileutils) on our
> system.
Probably so. I'll give it a try myself with that package installed. As long
as there's a relatively reasonable way to get make install to work
> In this signature, the Reference element in the SignedInfo has the
> attribute URI="". I understand that this references the current
> document, which is correct. In this case, I think I need to ensure the
> Transform directives exclude the Signature element itself via nested
> XPath elements. Fo
> So no quick fix. I'm going to have to play around to find something
> that works nicely.
Thanks for looking into it, it's definitely working better with GNU install
installed, but I did run into one other makefile bug that chokes that
version. There's a duplicate mention of XSECConfig.hpp in
s
> Noah/Walter/Scott - What's the right way to initially populate SVN? I'm
> happy to get the current version from CVS, add the appropriate ASF
> copyright and then populate. Does that sound OK?
I think that's probably ok. If they have any additional changes not checked
in, I imagine they can b
Heh, is there time to get this into 1.1 since it's not officially out yet?
We're getting ready to ship a new Shibboleth release. ;-)
-- Scott
> Scott, could you try and see if you can get some feel for the speed
> increases? They don't have to be perfect, but rough estimates
> would really help to make a decision.
I've got a copy of the 1.1 jar in our cvs now. I can try to get some timings
on SAML signing with that and then do a build
I looped over a Junit test I put into OpenSAML that reads in a SAML
assertion, signs it (RSA/SHA1), dumps it, reads it back in, verifies it, and
takes a time reading. Since the whole thing was CPU bound, the numbers are
practically identical across runs.
I used my laptop, a 1.8 GHz with 512MB, XP,
> Thank you for including the code, it was a great honour.
No, thank you. That rocked.
-- Scott
> Can anyone else run a couple tests too and confirm some of
> the finding?
The latest checkins lowered my 100 iteration test from 536 ms to 443 ms.
Significant, but nothing like the first one. Still, since it's not posted
yet anyway, I'd advocate running "ant dist" again. ;-)
-- Scott
> It hasn't made a big difference to ant test - but there is a difference,
> so I'll do a re-package and distribute today. (But that's it - no more
> for 1.1 :>.)
Thanks for getting all these in. I'll run another test when you post the new
version.
> These speed improvements have been fantasti
> If you have the time - have a look in
>
> xml.apache.org/security/1.1
>
> If you confirm it's OK, I'll do the final publish and release.
Sadly we share similar hours, but I'm not in OZ.
My test ran in 360 ms, down from 910 in the original 1.1 release.
-- Scott
> is it possible that this version signs seven times faster
> that the 1.04 ???
> because, I just replaced the old jars an obtained those times.
My test was about 3 times faster, but depending on the test case, I wouldn't
be surprised. 1.1 is a huge improvement thanks to those last minute patches
> No - there is no validity check between the two. And in fact, because
> of the potential uses of KeyInfo, it *might* be that incompatible key
> values are valid.
Well, technically there is in the sense that a single KeyInfo is only
supposed to represent one key. If you have a KeyValue and a c
> In particular: which implementation classes of the crypto
> algorithms did you use? IBM's or SUN's ?
Given the JDK concern, using Bouncy Castle probably would be the simplest
path. It's free and I assume it runs ok on IBM's VM.
www.bouncycastle.org
-- Scott
> Does anyone know what is going wrong ? This seems strange to me.
I can tell you that if you leave schema data type normalization on, any
base64 objects you may have in the signed data will be corrupted by the
validator. There may be other data types that get corrupted depending on
different fact
> As for normalization due to schema validation, I was under the impression
> that normalization done during schema validation is "virtual" and doesn't
> actually modify the actual bytes.
That's false. The parser will normalize the actual text nodes when it builds
the DOM, and it is those text nod
> I am currently working with Filter2 transforms and XPath
> transforms. And I have problems when namespace prefixes are used in some
> element that is present in a filter2-xpath value.
There's a way of specifying inclusive namespace prefixes, analagous to what
one does with Exclusive c14n when
> What I actually wanted to know was whether the XMLSec implementation of
> Transforms in general and Filter2 in particular, by default, supports
> locating elements that have a namespace prefix.
Yes, it does, but I'm guessing (but could be wrong) the canonicalizer may be
stripping your prefix de
> Hmm, canonicalizer... but, hmm, I am not using any canonicalizer.
You are, by definition, there's always at least the top level c14n of the
SignedInfo element. The part that confuses me is that I thought the default
there would be Inclusive, not Exclusive, which shouldn't be stripping your
names
> By default the c14n inclusive is used. There are no other c14n methods,
> but in the inclusive if namespace is selected it must be
> outputed.
Ok, but what's the definition of "selected"? My memory was that with
inclusive, if the namespace is declared in the path from the root to the
node in qu
> and what about the sun.misc.BASE64Decoder
And what if you're not on that JDK? The problem with using any other
decoder, including Xerces', is that not everybody uses those components.
Until Sun standardizes a BASE64 API in the JDK, there's no good answer.
-- Scott
> It includes afx.h, and afx.h includes MFC. Release configuration
> > builds, but Debug fails. I couldn't find a way to build it and I've
> > tried everything (include MFC, use different run-times...).
Try defining _AFXDLL in the project settings. I've always had to do that to
get my Debug buil
> My question is: Is there anyway I can use XML Security without using MFC?
> If that is so, how do I switch it off?
I would second this...the debug builds always pull in those AFX debugging things, and
it can be really painful to deal with in some
projects, as well as being pretty out of date.
> 2. My understanding is that the use of base64binary in a schema will
> cause a validating parser to callapse any whitespace during validation.
This is true as long as data type normalization is turned on. Most parsers
let you turn it off. This is required to verify signatures over base64
elem
> Or I suppose the other option would be to make sure you validate prior
> to sign. If I could think of some fancy way to do it, we could even
> mark base64binary elements somehow and have the security library convert
> them to normalised form as part of signing.
You mean verify first and then
> Scott indicated that it may be possible to turn off normalisation during
> the parsing process, but other than that the only other work-around is
> not to validate during parse.
It is possible with Xerces, we do it in OpenSAML to enable signing a signed
object, which of course includes base64
> whitespace-in-element-content? datatype-normalization?
It's datatype-normalization. The other one has to do with something that schema
processing overrides.
-- Scott
> Do you want me to change anything in Axis? WSS4J? xml-security? to
> support this switch?
I don't think there's anything you can change. Most of the operations in
xmlsec operate on a DOM, at which point it's already been parsed. The
parsing step is where you have to step in and prevent the corru
> By the way, it would nice ass you are releasing a new version if you
> were to adopt the convention of putting the release version in the Jar
> names.
> ie xml-security-1.1.0.jar is much better than xmlsec.jar
+1
We do this manually with xmlsec and Xerces when checking them into our cvs.
-- Sc
> Thanks for this quick response !
> Please can you send me the jar ?
Note the other work-around is just to endorse xalan to override the broken
JDK classes.
-- Scott
> Unfortunately this is a hack workaround since the xalan xslt apis are not
> part of the actual endorsed override apis.
Of course, but the hack is that Sun put these classes into the JDK in the
first place. One leads to another. Using a CVS build of a package is far
worse in many environments.
-
> I would like to hear what other members on the list think about going
> for this change.
I'm strongly in favor of it. We've been sort of fighting this mechanism and
having trouble with helping people that have unusual JCE requirements.
If I understand the change correctly, it will let people u
Before the new release is cut, would it be possible to add a section to
configure.ac for OS X? The code appears to build and work once configure
recognizes the platform.
The current line for -apple-darwin is commented out, but it can just be
replaced with the fragment below.
TIA...
-- Scott
*-ap
> My question is, is this something that the future version of
> xml-security will provide? Or is there other way to use
> wsu:Id with the xml-security library?
Hardcoding any values into the code is a mistake IMHO. The work-around
should probably be to have a system property set by the applicat
Hi,
Just testing the RC jarfile recently posted with OpenSAML. Something I just
noted because of how my test was written is that it appears to be harder
(impossible?) to verify a signature if the XML being signed isn't read in
from a DOM.
I used to be able to create a signature over a DOM and fil
> It's little strange but it's also true that it is good for testing. Can
> you post the stacktrace so i can take a look and see if there is something
> we can do about it?
Sure, it's pasted below, minus some Eclipse junk. The crash is in the
Manifest.verifyReferences method when it checks the siz
> This little patch will help your problems, I haven't committed it
> because my current CVS checkout is changed with some work I'm doing
> with SAX signatures, but it should work for you.
> Please test it and when I came back home I'll commit and test
> it in a clean tree.
Ok, thanks.
> Wel
> This little patch will help your problems, I haven't committed it
> because my current CVS checkout is changed with some work I'm doing
> with SAX signatures, but it should work for you.
> Please test it and when I came back home I'll commit and test
> it in a clean tree.
The patch worked f
> I've been thinking about this and the other one. The buffers should
> never be hard coded as to length in any way. I was being lazy when I
> wrote these bits of code, and now its burnt me.
+1
I patched this myself in the copy I'm distributing with some configure
fixes. I was dismayed to fin
> For anyone reading with a word wrapping mail client, the latter is one
> long line with the line-feeds adjacent to the entity tags missing and
> the mid-text line-feeds converted to spaces.
Are you validating the document while parsing it? If so, the only "fix" is
to turn off data type normaliza
> Argh. Okay, I've switched to using the DOM3 calls to parse the XML, but
> I can't work out which particular DOMConfiguration setting to use to
> stop this from happening. Do you know which particular one does it?
> Setting datatype-normalization to false doesn't seem to cut it...
Hmm, that shoul
> I am indeed validating. I've found a workaround, in the end, which
> consists of serializing and re-parsing every document before I sign it
> in the Java code, which at least ensures that I'm not signing any
> denormalized data, and then doing the same thing before actually
> emitting the documen
I'm starting to incoporate a few pieces of the XML Encryption classes into
some of my project, and I had a question about the XSECEnv class,
specifically about the DOMDocument parameter in the c'tor, and how to use
this class.
Is this object supposed to be created per XML instance being manipulate
> I'm attaching Win32 SSL URI resolver class and test code.
> I haven't still finished testing.
Are there hooks to override the SSL trust processing? That's a common
failing with these kinds of interfaces, and SSL is useless without
sufficient control over the authentication.
> I have some doubts
> The class that I have attached is for Windows OS. It will be
> soon in CVS. Berin will do OpenSSL version. The only things you can set
> up is client certificate (PCCERT_CONTEXT), protocol (PCT, SSL2, SSL3,
> TLS1) and key exchange alg type (RSA, DH). Server certificate is
> validated by se
> The March 2004 news item at
> http://xml.apache.org/security/c/index.html
> indicates that version 1.1 of the C++ library supports Xerces-C 2.3 -
> 2.5. Is it known whether Xerces-C 2.6 is supported?
It works, to some extent, but the change to base64 validation in 2.6 makes
super-signatures im
In light of the recent talk about SHA-1 being weakened, does the C++ xmlsec
library support the stronger SHA hashing algorithms at this point?
I see the constants defined in the Java version, but I can't use them if
they won't interop.
I suspect adding the support isn't too hard, but I don't have
> No, C++ lib doesn't support SHA-256 or stronger. It supports only MD5
> and SHA1 due to Windows CryptoAPI and OpenSSL limitations.
Thanks, didn't realize that.
> However, if you don't trust SHA1 anymore, you should consider that many
> digital certificates used for signing are signed using SHA1
> Interesting point. If one of the required algorithms is really broken,
> it may be difficult to reach consensus on what to use in its place.
> Implementation A may support algorithm 1 but not algorithm 2, while
> implementation B supports 2 but not 1, and the two no longer
> interoperate.
Right
> BTW - I have compiled up OpenSSL 0.9.8-dev and managed to get it to link
> against the library (some minor changes to structure definitions that
> required some minor changes in the library). All the tests run fine, so
> I'm going to try to add 256/512 support over the weekend.
Presumably in
> Is there a development version of Xsec available that is compatible with
> the latest Xalan and Xerces releases?
I can't speak for Xalan, but the 1.1 version does support Xerces 2.6 just
fine. Is your failure in the Xalan dependency?
-- Scott
> concerned about interoperability. No order is implied by the
> certificates stored in an X509Data element.
While this is strictly true, people that aren't using the fairly
well-established convention of signer/intermediate/intermediate/... should
be slapped with a fish. ;-)
Be strict in what y
> Scott - you are the person with the most experience in schema validation
> and signatures. Is it worthwhile adding some form of switch to tell the
> library to output base64 data in normalised form? (I.e. no line feeds
> etc.) That way normalisation won't touch the data and schema validatio
> I want to known, If someone experiments any performance change(either
> increase or decrease) or any error with the changes. And this is
> target for Scott if it is now possible to run xml-sec cvs in java 1.5
> without xalan(not doing any xpath transformation of course).
Thanks, Raul, I will de
No luck so far. When I try it with 1.5, I get this trace (leaving out the
parts before this library starts up):
java.lang.NoClassDefFoundError: org/apache/xml/utils/PrefixResolver
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:164)
at org.a
> I need more info, can you compile with debug to see what concrete line
> is invoking the class forName. I don't find any reference in Init,
> some reference in XPath related transformations but that's normal.
It's line 216. The problem is probably that when it loads the classes for
the Transform
> The canonicalizer produces output that is nothing like the canonicalized
> form produced by .NET and the Glue input based canonicalization:
They look pretty much the same except for whitespace, but whitespace is
significant. If the XML contains whitespace, c14n doesn't remove it. My
guess is t
> It was my understanding that if I could start with an XML file or String,
> use one of the xml parsers to load the file into a Document, and then
> produce a canonical version of the xml String using an algorithm implement
> in the Apache XML Security package. I also assumed that I could load,
>
> Using my test xml file, both Glue and .NET C# both produce all of these
>
elements, while the javax.xml apis produce no
entities.
Hmm. Reading the spec, it does say that text nodes get changed such that
"all #xD characters are replaced by
". So, heh, you're right. Guess I
never noticed, SAM
> For some reason, in my little test case, the canonicalizer renders a
> different result with the DOM from the JAXP api then from the Glue api.
> Apparently, the result from the JAXP DOM, produces something wrong, as far
> as the soap:encodingStyle attribute goes.
I guess a first sanity check wou
I'm still investigating, but is anybody else seeing problems signing a large
file (not huge, just 200k or so) with an enveloped signature? I'm seeing
crashes in the c14n transform step where it tries to flush the new
UnsyncBufferedOutputStream class, which tells the internal digester to
update itse
> Berin, can you send the stack trace?
Not Berin, but here's the trace...again, I'm still testing, but the same
signing program seems to work ok on small files with the same structure, so
I don't think I have a bug.
This is using both a build from last month and the latest cvs. The trace is
the s
> You are right in the bug, I think that now is fixed in CVS HEAD.
Seems to be working now, thanks. Hazards of relying on cvs code, but I
really want to avoid Xalan!
-- Scott
I'm in favor, but I'd like to try and get various autoconf patches I've done
for OS X support amongst other fixes into the release if possible. It sounds
like that's ok, if the release is planned for a couple of weeks out?
-- Scott
Something to consider for the future is that the use of proprietary
eumeration constants in the API for specifying signature and digest
algorithms makes application code on top of this very brittle in terms of
handling future evolution.
It would be better to let dependent code use the URI strings
> One of the things I wrote into the XML Encryption code was an "Algorithm
> Handler". It *can* still use the encryption constants, but it will also
> work if you pass in a URI to the (for example)
> XENCCipher::encryptElement() method. The AlgorithmHandler class is
> empty by default, and at
> Out of curiosity - what algorithms do you need?
At the moment, none, since OpenSSL doesn't support any of the newer hashes,
but I don't want to have to release a new version of the library just to
support them. It should all be URI based so I don't have to know about them.
-- Scott
> The beta of OpenSSL 0.9.8 does support the longer SHA hashes
> (224/256/384/512) - and they are supported by the library, if 0.9.8 is
> used (but you have to use the enumerated type to define what
> you want :>).
Right, but I don't expect people to run with two prerelease libraries when
C++ i
> I had also looked at the reference implementation that ships with the
JWSDP
> 1.5 but had problems in being able to specify a particular element via
URI.
> The sample given seems to specify the whole document with a "" blank
String
> but when I try a relative URI (#elementname) it falls on it's a
Berin,
Is 1.2 link/ABI compatible with 1.1? The VC6 project in the new tarball
outputs the same import lib and DLL names as 1.1 did, which seemed unlikely
to me.
The Unix build does not, it versioned the library out of the way of the old
one, so I assumed the same should be true of Windows.
-- S
> But does anyone feel they (the enum based creation calls) should be left
> in-perpetuity? (They won't be removed quickly, but they will eventually
> disappear.)
I'd expect them to be deprecated for one major release (1.3?) and then
potentially dropped afterward.
-- Scott
> I'm afraid that we are going to have the same discussin with java
> library(and bigger).
Really? I thought the Java library already used URIs. I'm using them now...
> Perhaps it is time to decide a little policy for this thing. I'd like
> Scott recomendation...
> What othe people think?
My mai
> Has anyone any experience validating this type of documents?
> I´d really appreciate any advice or idea.
My guess would be it's retrieving something from the network, a common
problem if you don't install your own entity resolver. You could disconnect
and try with no connectivity.
-- Scott
1 - 100 of 280 matches
Mail list logo
