Bug 39029 - Stax verifier JSR105 implementation
Summary: Stax verifier JSR105 implementation
Status: NEW
Alias: None
Product: Security - Now in JIRA
Classification: Unclassified
Component: Signature (show other bugs)
Version: Java 1.3
Hardware: Other other
: P2 enhancement
Target Milestone: ---
Assignee: XML Security Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-03-19 12:14 UTC by Raul Benito
Modified: 2006-12-15 08:20 UTC (History)
0 users



Attachments
First version (80.00 KB, text/plain)
2006-03-19 12:16 UTC, Raul Benito
Details
A new version of the stax signature validator (68.77 KB, patch)
2006-05-27 17:09 UTC, Raul Benito
Details | Diff
A new patch with signature verification (62.89 KB, patch)
2006-12-15 08:20 UTC, Raul Benito
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Raul Benito 2006-03-19 12:14:53 UTC
Hi, 
I have just finished a first implementation of Stax verifier, it only works with
enveloping signatures(well any signature that appears before the signed data),
and exclusive c14n, and no transformations.

The TODO:
[ ] Do inclusive C14n
[ ] Design the API for signed data before signature describing it.
[ ] Do Transformations

For see how to use it untar the tar in a SVN head, and see the examples in
src_unitTest/com/r_bg/stax/*

Can people wanting to use stax verification(WS guys) see if the API fits its needs.
Comment 1 Raul Benito 2006-03-19 12:16:31 UTC
Created attachment 17918 [details]
First version
Comment 2 Chris Black 2006-03-22 19:56:49 UTC
I have started to review the Stax architecture for xml security submitted in the
attachment and have a few comments:
1. Change StaxSignatureVerifcator to StaxSignatureVerifier
2. I don't see how the current structure would work with an XMLStreamReader
containing more than one signature, the code seems to start from the current
position and seek until end. I think a better "contract" might be that the
factory or filtered reader just read until a matching pair of start sig / end
sig tags are found. That way the caller could get another sig verified by moving
the XMLStreamReader forward themselves.
3. I see plenty of 1.5-isms, this may be ok, but then we need to make sure the
documentation is clear that Java 1.5+ is needed to use this part of the library.
4. Unit tests use RSA, which I believe requires a 3rd-party JCE. Perhaps having
the unit tests use DSA so they work w/o an external JCE would be better. I also
plan to use DSA in my code for this reason (don't want to require a 3rd-party JCE).
Comment 3 Raul Benito 2006-03-23 19:05:49 UTC
(In reply to comment #2)
First of all thanks for your time and your comments. They are really appreciated.


> 1. Change StaxSignatureVerifcator to StaxSignatureVerifier
Done, Thanks

> 2. I don't see how the current structure would work with an XMLStreamReader
> containing more than one signature, the code seems to start from the current
> position and seek until end. I think a better "contract" might be that the
> factory or filtered reader just read until a matching pair of start sig / end
> sig tags are found. That way the caller could get another sig verified by moving
> the XMLStreamReader forward themselves.
You can ask the Filter wich signature you want using
StaxValidateContext.setSignatureNumber(int number) method, but right now is just
hardcode to the first one.
Regarding the sugestion for the "contract", I was thinking in two different Uses
cases:
  1.- Aspect oriented: A part of the code sets the expectations to the verifier
filter, and handles the stream reader to the rest of the program that are not
"Signature" aware. When the program finish reading the stream it asks the filter
for the correctness of the Signature expectations. This the current api, but
there's still a lot of things to do.
  2.- In the another use case the application is aware of the "Signature" and
notifies the Filter when the element referenced begins, and to what signature it
belongs. This API is still undone, and I want to wait to finish the "aspect" one
before begining with this.
> 3. I see plenty of 1.5-isms, this may be ok, but then we need to make sure the
> documentation is clear that Java 1.5+ is needed to use this part of the library.
My intention is that the library requires java 1.3 like the rest of the xml-sec
library. Using 1.5-ism was just for fun...

> 4. Unit tests use RSA, which I believe requires a 3rd-party JCE. Perhaps having
> the unit tests use DSA so they work w/o an external JCE would be better. I also
> plan to use DSA in my code for this reason (don't want to require a 3rd-party
JCE).
The RSA comes with sun java 1.4 and 1.5 it does not need any 3rd party JCE.
Perhaps IBM or BEA jce don't contain this cypher.


Again thanks for your sugestions. If you have more don't hesitate...
Comment 4 Raul Benito 2006-05-27 17:08:24 UTC
New PATCH
Hi, a new version of the patch that happens to decode and verify and SAML
assertion(a enveloped signature). So enveloped and detached-before-the-signature
signatures are supported right now. 
The API used is the signature/reference aware. 
I'm going to concetrate in:
  *Inclusive C14n support: it's going to be a parameter passed when obtaining
the filter as it slows the parsing, as it must store the xml:* attributes.
  *Refactor & Documentation: I'm going to do some refactor and create some
diagrams of the internal workings, I plan to publish all these things in my blog.

The TODO:
[ ] Do inclusive C14n
[X] Design the API for signed data before signature describing it.
[ ] Do Transformations
[ ] Refactor
[ ] And documentation
[ ] Optimize for speed not for easy debugging. :(
[ ] Keys/Cert decoding...
Comment 5 Raul Benito 2006-05-27 17:09:27 UTC
Created attachment 18360 [details]
A new version of the stax signature validator
Comment 6 Raul Benito 2006-12-15 08:20:07 UTC
Created attachment 19265 [details]
A new patch with signature verification

Hi,
As work related to my master thesis, I have been working on this patch a
little. Now it can check if the signature was tampered, and it is much faster
and can handler any length documents (that is the main point of my master
thesis). I will publish the doc, and the powerpoint of it in my webpage. But
sadly it is written in Spanish. But anyway I think is useful as it contains
some graphics showing the memory consumption of the DOM library versus the STAX
library. 

If anybody wants to play with it have fun.

Changelog:
* Siganture & reference validation (the patch before only does reference
validation) 
* Size & Performance improvement: the patch can handle now arbitrary big
documents, and the performance is better. 

TODO:
* Inclusive C14n
* Enveloped signature verification.
* UTF16->UTF8 optimizations