Thanks much for the detailed and speedy response guys. I am not seeing any sun-provided xmlenc impl at all...only apparently for signature. This is where we were 'stuck' as only ibm jre seemed to provide both encFactory and sigFactory...and we need something portable across JVMs as internally we use ibm or sun impls depending upon server role.
I am seeing good stuff and ease of use with apache xmlsec and will continue to use it for it's portability. We have a prior implementation on verisign's tsik? but am not sure if we will still use it due to licensing or perhaps some other reason (docs, cost, ...). The XMLCipher class was very straightforward and mirrors non-xml Cipher class so great paradigm there. I agree with your points on diligence regarding attempts to secure code and engrs making it more difficult than it needs to be or should be. Myself I have strived to provide high-level logical abstraction in 'envelope' apis so engr only deals with logical constructs as objectname/ version, algorithm/keysize (as enums) and clear/cipher/sign text....no ciphers/transforms/padding or other low level stuff to get them in trouble. Additionally all poor alg choices are removed. Have a good weekend and keep up the good work/fight, mike On 4/10/2010 11:11 AM, Arshad Noor wrote: > I'm sure a lot of specs are currently "dead" given the tight > economy and the fact that the remaining employed have double > or triple the work-load of better times - who can justify > many hours/days spent on standards as businesses are cutting > most non-revenue expenditures to the bone? > > That said, I would like to affirm support for XML Encryption. > We have been using it for nearly 5 years and while it can use > a little improvement, if you are working in the XML world, it > offers a ready-made choice with supported libraries/tools. > How else would one transfer XML content with encrypted data > in it between systems/partners? By the time you've defined > all the rules for the exchange of ciphertext, you've > reinvented a proprietary version of the XML Encryption XSD. > With the use of XMLENC, at least 90% of the work is done for > you and all you've got to define is the remaining 10%. > > While IBM and Sun's JDKs might differ in their implementations > (I haven't personally looked at IBMs implementation so I can't > speak authoritatively on it), it only requires one large paying > customer to get both vendors to get their act together (if their > implementations are incompatible) - or a few committed engineers > within these companies to do what's right. > > Yes, there is a need for XML Encryption and XML Signature - IMO > application developers are in their infancy wrt cryptography > and are writing some bizarre code (based on my readings at the > Cryptography forum at java.sun.com). As they mature, they will > realize the benefits of XML Signature and XML Encryption and > start using it - the refinements will surely come at that time. > > In the meantime, I would prefer not to declare XMLENC dead - > having worked in cryptographic key-management for the last > decade, we believe the opportunities are just starting to > open up for this technology. > > Arshad Noor > StrongAuth, Inc. > > Mike Klein wrote: >> Jsr 105 (signing) is 'finalized' and jsr 106 (enc) seems 'dead'. >> >> I have a need to provide xml signing and enc across IBM and Sun JREs. >> >> I see xmlsec only mentions 105 compliance (perhaps because spec is final >> after all) and no real mention of 106 compliance (which makes sense as >> spec is 'dead'). >> >> I am able to do certain kinds of xmlenc with xmlsec just fine, but is it >> based on any accepted standard at this point? Can xmlenc output from >> xmlsec be sent to 3rd parties w/o any issues? >> >> IBM jre seems to provide both kinds of functionality yet I don't believe >> this helps me on sun jre...seems bundled with jre. >> >> Is there even a need for xml enc on java or only sig? >> >> thanks in advance... >> >> mike
