You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pdfbox.apache.org by Vakhtang koroghlishvili <va...@gmail.com> on 2014/03/09 18:21:35 UTC

advanced signatures - the feature plans

Hello,

how are you? :)

You know , that I have already fix and implement some issues and new
features which was about digital signature. I have already  created another
new features too but I don't know  if I should create this patches in the
pdfbox example project. I think, it's time to create another project named
sign-box or something like that.  At the moment I have time and I can
create that project  with very good  design architect and show you a patch
or comitters  can create that project with existence features and then we
will add new features step by step.

I will write here, what we have at the moment, and what can we add too:

At the moment, if we want to use pdfbox for the document signing , we can
only do that thing:

1. create basic digital signature with the time of CPU. *done*
2. create digital signature with visible signature. *done* -that was my
first contribution :-)

This is very poor functionality and is not easy to use. It's just in the
project named "examples". It must have very easy API, as we sad before.

I have implement and  add another functionality  nd created patches  some
of them. some patches of new features is not updated in the jira, because I
don't now  whether this must be in the example project or not.  So, at the
moment I have that functionality:


1. signing document with PADES-BES or PADES-BASIC profile, with CPU signing
time.  *done*

2. signing document with PADES-BES or PADES-BASIC profile, with timeStamp
server time. Already *implemented* - I have uploaded a patch in our jira,
some classes are in the "pdfbox" project and some classes are in the
"example" project.

3. signing document with timestamp server.  Already *implemented* and patch
is uploaded in a jira ...

4. creted document secure store and PADES LTV profile implementation
(advanced signatures!).  I have already *implemented* this. I can create
patch in the example project or create patch for sign-box too :) Tell me
and I will create patch for one of them :)

5. certificate chain verification  while signing process, against OCSP, CRL
protocols (with advanced ocsp, crl certificate verifications too!) - I have
already *implemented* this.
I can create patch in the example project or create patch for sign-box and
etc.. :-) :-) :-)


Finally,   I want tell you that I like that project and I want to help you
as I can.   I'm very well with digital signatures and I have very good
experience with this. So, if you need, please tell me what should I do for
this apache project?  :) I am with you :)

Best regards,

Re: advanced signatures - the feature plans

Posted by John Hewson <jo...@jahewson.com>.
> And who will create new sub project? Should I create this or will you
> create this when you have spear time? :)
> I'm not committer, I can only create patches and show you the result. :)

I’m happy do do this for you.

-- John

Re: advanced signatures - the feature plans

Posted by Vakhtang koroghlishvili <va...@gmail.com>.
Hi,
Ok, I will do license things  too. :) thanks for explanations :)

And who will create new sub project? Should I create this or will you
create this when you have spear time? :)
I'm not committer, I can only create patches and show you the result. :)

Vakhtang,


On Mon, Mar 10, 2014 at 6:19 PM, Thomas Chojecki <in...@rayman2200.de> wrote:

> Am 2014-03-10 10:13, schrieb Vakhtang koroghlishvili:
>
>> Hello,
>>
> Hi Vakhtang,
>
> i'm quite busy right now at work and planing my vacation. But at least I
> got my internet back this month *wohoo*.
>
>
>  My codes have a CLA license, Tomas Chojecki have added it. At the moment
>> some of them are committed and some of them are not (Tomas was created
>> code
>> review and was adding Individual CLA [2] license to them, but might be he
>> was busy and some codes is not committed at the moment).
>>
>> What do you means about "signing"? Is there another procedure too? :)
>>
>
> The CLA license is a document that you need to sign. With this document
> you assure that the code that you provide, belong to you and can be used by
> apache. We need this document first, before we can commit larger parts of
> code. Patches are ok without the CLA but for new features we need this
> document.
>
> So please look at the site [1] and fill the "Individual Contributor
> License Agreement" [2].
>
> The other thing are licence header :-) Both are different things.
> Each class need to have this header. If such header are missing, we
> commiter will add these.
>
> Best regards
> Thomas
>
> [1] https://www.apache.org/licenses/
> [2] https://www.apache.org/licenses/icla.txt
>

Re: advanced signatures - the feature plans

Posted by Thomas Chojecki <in...@rayman2200.de>.
Am 2014-03-10 10:13, schrieb Vakhtang koroghlishvili:
> Hello,
Hi Vakhtang,

i'm quite busy right now at work and planing my vacation. But at least I 
got my internet back this month *wohoo*.

> My codes have a CLA license, Tomas Chojecki have added it. At the 
> moment
> some of them are committed and some of them are not (Tomas was created 
> code
> review and was adding Individual CLA [2] license to them, but might be 
> he
> was busy and some codes is not committed at the moment).
> 
> What do you means about "signing"? Is there another procedure too? :)

The CLA license is a document that you need to sign. With this document 
you assure that the code that you provide, belong to you and can be used 
by apache. We need this document first, before we can commit larger 
parts of code. Patches are ok without the CLA but for new features we 
need this document.

So please look at the site [1] and fill the "Individual Contributor 
License Agreement" [2].

The other thing are licence header :-) Both are different things.
Each class need to have this header. If such header are missing, we 
commiter will add these.

Best regards
Thomas

[1] https://www.apache.org/licenses/
[2] https://www.apache.org/licenses/icla.txt

Re: advanced signatures - the feature plans

Posted by Vakhtang koroghlishvili <va...@gmail.com>.
Hello,

>I remember you from some time ago without details, and that one of the
committers was very satisfied with your code.
Yes,  might be it was Thomas Chojecki. The architecture of the new features
was written using very beautiful design patterns and it was working very
well :)

>did Andreas already make you sign a CLA ( https://www.apache.org/licenses/ )
?

My codes have a CLA license, Tomas Chojecki have added it. At the moment
some of them are committed and some of them are not (Tomas was created code
review and was adding Individual CLA [2] license to them, but might be he
was busy and some codes is not committed at the moment).

What do you means about "signing"? Is there another procedure too? :)

>This is required when you submit real code, i.e. not just a small bugfix.
As I know, I have written and upload patches from 5 000 line  to 10 000
line of code.
For instance, when I implement  PDFBOX-1766  new feature, it was  for about
3500-3800 line of code. :)

>what JIRA issues are still open that you wish to have committed?
PDFBOX-1848 and PDFBOX-1847

>if not already there and if possible / applicable, attach a test PDF
it's already done in my open issues. :)

>Make sure that your code works with the current trunk, a lot was changed,
although not related to signatures
Off course, I will check  again. As I remember Thomas Chojecki was creating
code review :) We might wait for Tomas  Chojecki  :)

Vakhtang,


On Mon, Mar 10, 2014 at 10:58 AM, Tilman Hausherr <TH...@t-online.de>wrote:

> Hello Vakhtang,
>
> I remember you from some time ago without details, and that one of the
> committers was very satisfied with your code. Maybe that person will come
> back later, the weekend seems to be very quiet here.
>
> I'm answering you that you don't get frustrated. A few thoughts:
>
> - did Andreas already make you sign a CLA ( https://www.apache.org/
> licenses/ ) ? This is required when you submit real code, i.e. not just a
> small bugfix.
> - what JIRA issues are still open that you wish to have committed? Please
> name the ones with the smallest code first
> - if not already there and if possible / applicable, attach a test PDF
> (that isn't copyrighted except by you) or a unit test or whatever . This is
> just a general thought, e.g. you wrote code to create a new type of
> signature for a PDF. Then (if possible) you should also create a unit test
> that creates a signature for that PDF (if possible without user
> interaction), verifies that signature, modifies the PDF, and verifies the
> signature again and of course fails.
> - make sure that your code works with the current trunk, a lot was
> changed, although not related to signatures
>
> Tilman
>
> Am 09.03.2014 18:21, schrieb Vakhtang koroghlishvili:
>
>> Hello,
>>
>> how are you? :)
>>
>> You know , that I have already fix and implement some issues and new
>> features which was about digital signature. I have already  created
>> another
>> new features too but I don't know  if I should create this patches in the
>> pdfbox example project. I think, it's time to create another project named
>> sign-box or something like that.  At the moment I have time and I can
>> create that project  with very good  design architect and show you a patch
>> or comitters  can create that project with existence features and then we
>> will add new features step by step.
>>
>> I will write here, what we have at the moment, and what can we add too:
>>
>> At the moment, if we want to use pdfbox for the document signing , we can
>> only do that thing:
>>
>> 1. create basic digital signature with the time of CPU. *done*
>> 2. create digital signature with visible signature. *done* -that was my
>>
>> first contribution :-)
>>
>> This is very poor functionality and is not easy to use. It's just in the
>> project named "examples". It must have very easy API, as we sad before.
>>
>> I have implement and  add another functionality  nd created patches  some
>> of them. some patches of new features is not updated in the jira, because
>> I
>> don't now  whether this must be in the example project or not.  So, at the
>> moment I have that functionality:
>>
>>
>> 1. signing document with PADES-BES or PADES-BASIC profile, with CPU
>> signing
>> time.  *done*
>>
>>
>> 2. signing document with PADES-BES or PADES-BASIC profile, with timeStamp
>> server time. Already *implemented* - I have uploaded a patch in our jira,
>>
>> some classes are in the "pdfbox" project and some classes are in the
>> "example" project.
>>
>> 3. signing document with timestamp server.  Already *implemented* and
>> patch
>>
>> is uploaded in a jira ...
>>
>> 4. creted document secure store and PADES LTV profile implementation
>> (advanced signatures!).  I have already *implemented* this. I can create
>>
>> patch in the example project or create patch for sign-box too :) Tell me
>> and I will create patch for one of them :)
>>
>> 5. certificate chain verification  while signing process, against OCSP,
>> CRL
>> protocols (with advanced ocsp, crl certificate verifications too!) - I
>> have
>> already *implemented* this.
>>
>> I can create patch in the example project or create patch for sign-box and
>> etc.. :-) :-) :-)
>>
>>
>> Finally,   I want tell you that I like that project and I want to help you
>> as I can.   I'm very well with digital signatures and I have very good
>> experience with this. So, if you need, please tell me what should I do for
>> this apache project?  :) I am with you :)
>>
>> Best regards,
>>
>>
>

Re: advanced signatures - the feature plans

Posted by John Hewson <jo...@jahewson.com>.
Great, I will take a look at your patches today.

Thanks!

-- John

> On 12 Mar 2014, at 07:10, Vakhtang koroghlishvili <va...@gmail.com> wrote:
> 
> Hello again,
> 
> 
> "This message acknowledges receipt of your ICLA, which has been filed in
> the Apache Software Foundation records.
> If you have been invited as a committer, please advise the project PMC that
> your ICLA has been filed."
> 
> 
> Vakhtang
> 
> 
> On Mon, Mar 10, 2014 at 10:58 AM, Tilman Hausherr <TH...@t-online.de>wrote:
> 
>> Hello Vakhtang,
>> 
>> I remember you from some time ago without details, and that one of the
>> committers was very satisfied with your code. Maybe that person will come
>> back later, the weekend seems to be very quiet here.
>> 
>> I'm answering you that you don't get frustrated. A few thoughts:
>> 
>> - did Andreas already make you sign a CLA ( https://www.apache.org/
>> licenses/ ) ? This is required when you submit real code, i.e. not just a
>> small bugfix.
>> - what JIRA issues are still open that you wish to have committed? Please
>> name the ones with the smallest code first
>> - if not already there and if possible / applicable, attach a test PDF
>> (that isn't copyrighted except by you) or a unit test or whatever . This is
>> just a general thought, e.g. you wrote code to create a new type of
>> signature for a PDF. Then (if possible) you should also create a unit test
>> that creates a signature for that PDF (if possible without user
>> interaction), verifies that signature, modifies the PDF, and verifies the
>> signature again and of course fails.
>> - make sure that your code works with the current trunk, a lot was
>> changed, although not related to signatures
>> 
>> Tilman
>> 
>> Am 09.03.2014 18:21, schrieb Vakhtang koroghlishvili:
>> 
>>> Hello,
>>> 
>>> how are you? :)
>>> 
>>> You know , that I have already fix and implement some issues and new
>>> features which was about digital signature. I have already  created
>>> another
>>> new features too but I don't know  if I should create this patches in the
>>> pdfbox example project. I think, it's time to create another project named
>>> sign-box or something like that.  At the moment I have time and I can
>>> create that project  with very good  design architect and show you a patch
>>> or comitters  can create that project with existence features and then we
>>> will add new features step by step.
>>> 
>>> I will write here, what we have at the moment, and what can we add too:
>>> 
>>> At the moment, if we want to use pdfbox for the document signing , we can
>>> only do that thing:
>>> 
>>> 1. create basic digital signature with the time of CPU. *done*
>>> 2. create digital signature with visible signature. *done* -that was my
>>> 
>>> first contribution :-)
>>> 
>>> This is very poor functionality and is not easy to use. It's just in the
>>> project named "examples". It must have very easy API, as we sad before.
>>> 
>>> I have implement and  add another functionality  nd created patches  some
>>> of them. some patches of new features is not updated in the jira, because
>>> I
>>> don't now  whether this must be in the example project or not.  So, at the
>>> moment I have that functionality:
>>> 
>>> 
>>> 1. signing document with PADES-BES or PADES-BASIC profile, with CPU
>>> signing
>>> time.  *done*
>>> 
>>> 
>>> 2. signing document with PADES-BES or PADES-BASIC profile, with timeStamp
>>> server time. Already *implemented* - I have uploaded a patch in our jira,
>>> 
>>> some classes are in the "pdfbox" project and some classes are in the
>>> "example" project.
>>> 
>>> 3. signing document with timestamp server.  Already *implemented* and
>>> patch
>>> 
>>> is uploaded in a jira ...
>>> 
>>> 4. creted document secure store and PADES LTV profile implementation
>>> (advanced signatures!).  I have already *implemented* this. I can create
>>> 
>>> patch in the example project or create patch for sign-box too :) Tell me
>>> and I will create patch for one of them :)
>>> 
>>> 5. certificate chain verification  while signing process, against OCSP,
>>> CRL
>>> protocols (with advanced ocsp, crl certificate verifications too!) - I
>>> have
>>> already *implemented* this.
>>> 
>>> I can create patch in the example project or create patch for sign-box and
>>> etc.. :-) :-) :-)
>>> 
>>> 
>>> Finally,   I want tell you that I like that project and I want to help you
>>> as I can.   I'm very well with digital signatures and I have very good
>>> experience with this. So, if you need, please tell me what should I do for
>>> this apache project?  :) I am with you :)
>>> 
>>> Best regards,
>> 

Re: advanced signatures - the feature plans

Posted by Vakhtang koroghlishvili <va...@gmail.com>.
Hello again,


"This message acknowledges receipt of your ICLA, which has been filed in
the Apache Software Foundation records.
If you have been invited as a committer, please advise the project PMC that
your ICLA has been filed."


Vakhtang


On Mon, Mar 10, 2014 at 10:58 AM, Tilman Hausherr <TH...@t-online.de>wrote:

> Hello Vakhtang,
>
> I remember you from some time ago without details, and that one of the
> committers was very satisfied with your code. Maybe that person will come
> back later, the weekend seems to be very quiet here.
>
> I'm answering you that you don't get frustrated. A few thoughts:
>
> - did Andreas already make you sign a CLA ( https://www.apache.org/
> licenses/ ) ? This is required when you submit real code, i.e. not just a
> small bugfix.
> - what JIRA issues are still open that you wish to have committed? Please
> name the ones with the smallest code first
> - if not already there and if possible / applicable, attach a test PDF
> (that isn't copyrighted except by you) or a unit test or whatever . This is
> just a general thought, e.g. you wrote code to create a new type of
> signature for a PDF. Then (if possible) you should also create a unit test
> that creates a signature for that PDF (if possible without user
> interaction), verifies that signature, modifies the PDF, and verifies the
> signature again and of course fails.
> - make sure that your code works with the current trunk, a lot was
> changed, although not related to signatures
>
> Tilman
>
> Am 09.03.2014 18:21, schrieb Vakhtang koroghlishvili:
>
>> Hello,
>>
>> how are you? :)
>>
>> You know , that I have already fix and implement some issues and new
>> features which was about digital signature. I have already  created
>> another
>> new features too but I don't know  if I should create this patches in the
>> pdfbox example project. I think, it's time to create another project named
>> sign-box or something like that.  At the moment I have time and I can
>> create that project  with very good  design architect and show you a patch
>> or comitters  can create that project with existence features and then we
>> will add new features step by step.
>>
>> I will write here, what we have at the moment, and what can we add too:
>>
>> At the moment, if we want to use pdfbox for the document signing , we can
>> only do that thing:
>>
>> 1. create basic digital signature with the time of CPU. *done*
>> 2. create digital signature with visible signature. *done* -that was my
>>
>> first contribution :-)
>>
>> This is very poor functionality and is not easy to use. It's just in the
>> project named "examples". It must have very easy API, as we sad before.
>>
>> I have implement and  add another functionality  nd created patches  some
>> of them. some patches of new features is not updated in the jira, because
>> I
>> don't now  whether this must be in the example project or not.  So, at the
>> moment I have that functionality:
>>
>>
>> 1. signing document with PADES-BES or PADES-BASIC profile, with CPU
>> signing
>> time.  *done*
>>
>>
>> 2. signing document with PADES-BES or PADES-BASIC profile, with timeStamp
>> server time. Already *implemented* - I have uploaded a patch in our jira,
>>
>> some classes are in the "pdfbox" project and some classes are in the
>> "example" project.
>>
>> 3. signing document with timestamp server.  Already *implemented* and
>> patch
>>
>> is uploaded in a jira ...
>>
>> 4. creted document secure store and PADES LTV profile implementation
>> (advanced signatures!).  I have already *implemented* this. I can create
>>
>> patch in the example project or create patch for sign-box too :) Tell me
>> and I will create patch for one of them :)
>>
>> 5. certificate chain verification  while signing process, against OCSP,
>> CRL
>> protocols (with advanced ocsp, crl certificate verifications too!) - I
>> have
>> already *implemented* this.
>>
>> I can create patch in the example project or create patch for sign-box and
>> etc.. :-) :-) :-)
>>
>>
>> Finally,   I want tell you that I like that project and I want to help you
>> as I can.   I'm very well with digital signatures and I have very good
>> experience with this. So, if you need, please tell me what should I do for
>> this apache project?  :) I am with you :)
>>
>> Best regards,
>>
>>
>

Re: advanced signatures - the feature plans

Posted by Tilman Hausherr <TH...@t-online.de>.
Hello Vakhtang,

I remember you from some time ago without details, and that one of the 
committers was very satisfied with your code. Maybe that person will 
come back later, the weekend seems to be very quiet here.

I'm answering you that you don't get frustrated. A few thoughts:

- did Andreas already make you sign a CLA ( 
https://www.apache.org/licenses/ ) ? This is required when you submit 
real code, i.e. not just a small bugfix.
- what JIRA issues are still open that you wish to have committed? 
Please name the ones with the smallest code first
- if not already there and if possible / applicable, attach a test PDF 
(that isn't copyrighted except by you) or a unit test or whatever . This 
is just a general thought, e.g. you wrote code to create a new type of 
signature for a PDF. Then (if possible) you should also create a unit 
test that creates a signature for that PDF (if possible without user 
interaction), verifies that signature, modifies the PDF, and verifies 
the signature again and of course fails.
- make sure that your code works with the current trunk, a lot was 
changed, although not related to signatures

Tilman

Am 09.03.2014 18:21, schrieb Vakhtang koroghlishvili:
> Hello,
>
> how are you? :)
>
> You know , that I have already fix and implement some issues and new
> features which was about digital signature. I have already  created another
> new features too but I don't know  if I should create this patches in the
> pdfbox example project. I think, it's time to create another project named
> sign-box or something like that.  At the moment I have time and I can
> create that project  with very good  design architect and show you a patch
> or comitters  can create that project with existence features and then we
> will add new features step by step.
>
> I will write here, what we have at the moment, and what can we add too:
>
> At the moment, if we want to use pdfbox for the document signing , we can
> only do that thing:
>
> 1. create basic digital signature with the time of CPU. *done*
> 2. create digital signature with visible signature. *done* -that was my
> first contribution :-)
>
> This is very poor functionality and is not easy to use. It's just in the
> project named "examples". It must have very easy API, as we sad before.
>
> I have implement and  add another functionality  nd created patches  some
> of them. some patches of new features is not updated in the jira, because I
> don't now  whether this must be in the example project or not.  So, at the
> moment I have that functionality:
>
>
> 1. signing document with PADES-BES or PADES-BASIC profile, with CPU signing
> time.  *done*
>
> 2. signing document with PADES-BES or PADES-BASIC profile, with timeStamp
> server time. Already *implemented* - I have uploaded a patch in our jira,
> some classes are in the "pdfbox" project and some classes are in the
> "example" project.
>
> 3. signing document with timestamp server.  Already *implemented* and patch
> is uploaded in a jira ...
>
> 4. creted document secure store and PADES LTV profile implementation
> (advanced signatures!).  I have already *implemented* this. I can create
> patch in the example project or create patch for sign-box too :) Tell me
> and I will create patch for one of them :)
>
> 5. certificate chain verification  while signing process, against OCSP, CRL
> protocols (with advanced ocsp, crl certificate verifications too!) - I have
> already *implemented* this.
> I can create patch in the example project or create patch for sign-box and
> etc.. :-) :-) :-)
>
>
> Finally,   I want tell you that I like that project and I want to help you
> as I can.   I'm very well with digital signatures and I have very good
> experience with this. So, if you need, please tell me what should I do for
> this apache project?  :) I am with you :)
>
> Best regards,
>


Re: advanced signatures - the feature plans

Posted by John Hewson <jo...@jahewson.com>.
Vakhtang

>> Ok. If these classes are not for signing then why are they in the
>> digitalsignature package? Should they be moved elsewhere?
>> 
> This classes is essential for signature but this classes does not signs
> document (cryptography signing is creating in the "example-project”)

Ok, so the classes are used for signing - good - just checking!

> In my opinion, it will be better if we move all the signature classes and
> interfaces in the new sub project not only *visible* package. I thought
> that you asked me only for *visible* package.

Yes, that’s what I was trying to figure out, I agree.

-- John

Re: advanced signatures - the feature plans

Posted by Vakhtang koroghlishvili <va...@gmail.com>.
>Ok. If these classes are not for signing then why are they in the
digitalsignature package? Should they be moved elsewhere?

This classes is essential for signature but this classes does not signs
document (cryptography signing is creating in the "example-project").

The same is for about
*org.apache.pdfbox.pdmodel.interactive.digitalsignature* classes.  For
instance, PDSignature  or SignatureInterface class is auxiliary class to
create digital signature, but with cryptography signature is creating in
the example project. The same is about .visible package *BUT*:

In conclusion:

I think,  because of there was no sub-project when digital signature
profile was writing,  all the signature interfaces and classes were created
in the *org.apache.pdfbox.pdmodel.**interactive.digitalsignature *package.

if we move *org.apache.pdfbox.pdmodel.interactive.digitalsignature.*
*visible* then we should move *org.apache.pdfbox.pdmodel.*
*interactive.digitalsignature* classes too.

In my opinion, it will be better if we move all the signature classes and
interfaces in the new sub project not only *visible* package. I thought
 that you asked me only for *visible* package.




On Mon, Mar 10, 2014 at 1:26 PM, John Hewson <jo...@jahewson.com> wrote:

> > Because of this classes is for creating visible signature fields (not for
> > signing) we can not to move that classes. sign-box will be for only
> signing.
>
> Ok. If these classes are not for signing then why are they in the
> digitalsignature package? Should they be moved elsewhere?
>
> >> JIRA issue number?
> > PDFBOX-1847 and PDFBOX-1848
>
> Great, I'll take a look.
>
> > Yes, but sub-project architecture must not be the same because that
> > sub-project API  must be very easy to use. So we might change some
> > structures.
>
> That's fine, we can iterate and make changes. Getting a nice easy to use
> API always takes a number of refactorings, you can always submit more
> patches later on.
>
> > As I see, that interfaces and classes are written very well.  We will add
> > another classes and interfaces for another signature functionality. But
> > most of them will be in the new sub-project.  We will move some classes
> > from example-project to new sub-project, with different architecture.
>
> Well, two of the interfaces are only implemented by one class, so they are
> redundant - unless your new sub-project has some new classes which
> implement them (I guess it probably does?).
>
> -- John
>
> On 10 Mar 2014, at 01:49, Vakhtang koroghlishvili <
> vakhtang.koroghlishvili@gmail.com> wrote:
>
> >> Should the classes in org.apache.pdfbox.pdmodel.
> > interactive.digitalsignature.visible be moved into this new project also
> >
> > Because of this classes is for creating visible signature fields (not for
> > signing) we can not to move that classes. sign-box will be for only
> signing.
> >
> >> is this already in PDFBox?
> > As I remember Thomas Chojecki have implemented this in the example
> project
> > of pdfbox like BASIC profile.  We can make it BES with some changes. I
> have
> > implemented PADES LTV in my computer (this profile is based on this
> issues
> > PDFBOX-1847  and PDFBOX-1848) and we will add this too.
> >
> >> JIRA issue number?
> > PDFBOX-1847 and PDFBOX-1848
> >
> >> Creating your patches in the example project is fine, we can move them
> to
> > a different sub-project for you.
> >
> > Yes, but sub-project architecture must not be the same because that
> > sub-project API  must be very easy to use. So we might change some
> > structures.  Finally the architect will be like that:  you will just
> create
> > signature object and then you will call signing method with your
> signature
> > profile and parameters, and that's all it is very simplified. So we must
> > create different architecture of that.  As I remember Thomas Chojecki was
> > creating  code review of that patches.  :) So we should wait :)
> >
> >> Perhaps the org.apache.pdfbox.pdmodel.interactive.digitalsignature is in
> > need of simplification, what do you think?
> >
> > As I see, that interfaces and classes are written very well.  We will add
> > another classes and interfaces for another signature functionality. But
> > most of them will be in the new sub-project.  We will move some classes
> > from example-project to new sub-project, with different architecture.
> >
> >
> > On Mon, Mar 10, 2014 at 10:54 AM, John Hewson <jo...@jahewson.com> wrote:
> >
> >> Hi Vakhtang,
> >>
> >>> I think, it's time to create another project named sign-box or
> something
> >> like that.
> >>
> >> Should the classes in
> >> org.apache.pdfbox.pdmodel.interactive.digitalsignature.visible be moved
> >> into this new project also?
> >>
> >> My understanding is that the PDF spec defines a basic signature
> container
> >> which is extensible and can embed signature formats defined by others,
> e.g.
> >> the PAdES standard defined by ETSI. This seems like a good candidate
> for a
> >> new sub-project e.g. "pdfbox-signing".
> >>
> >>> 1. create basic digital signature with the time of CPU. *done*
> >>> 2. create digital signature with visible signature. *done*
> >>>
> >>
> >>> This is very poor functionality and is not easy to use. It's just in
> the
> >>> project named "examples". It must have very easy API, as we said
> before.
> >>
> >> It would be nice to have a command-line program e.g. "SignPDF" in
> >> pdfbox-tools.
> >>
> >>> So, at the moment I have that functionality:
> >>>
> >>> 1. signing document with PADES-BES or PADES-BASIC profile, with CPU
> >> signing
> >>> time.  *done*
> >>
> >> Just checking: is this already in PDFBox?
> >>
> >>> 2. signing document with PADES-BES or PADES-BASIC profile, with
> timeStamp
> >>> server time. Already *implemented* - I have uploaded a patch in our
> jira,
> >>> some classes are in the "pdfbox" project and some classes are in the
> >>> "example" project.
> >>
> >> Great, what is the JIRA issue number?
> >>
> >>> 3. signing document with timestamp server.  Already *implemented* and
> >> patch
> >>> is uploaded in a jira ...
> >>
> >> Same question:  JIRA issue number?
> >>
> >>> 4. creted document secure store and PADES LTV profile implementation
> >>> (advanced signatures!).  I have already *implemented* this. I can
> create
> >>> patch in the example project or create patch for sign-box too :) Tell
> me
> >>> and I will create patch for one of them :)
> >>
> >> Creating your patches in the example project is fine, we can move them
> to
> >> a different sub-project for you.
> >>
> >>> 5. certificate chain verification  while signing process, against OCSP,
> >> CRL
> >>> protocols (with advanced ocsp, crl certificate verifications too!) - I
> >> have
> >>> already *implemented* this.
> >>> I can create patch in the example project or create patch for sign-box
> >> and
> >>> etc.. :-) :-) :-)
> >>
> >> Once again, the example project is fine, we can change the packages.
> >>
> >>> Finally,   I want tell you that I like that project and I want to help
> >> you
> >>> as I can.   I'm very well with digital signatures and I have very good
> >>> experience with this. So, if you need, please tell me what should I do
> >> for
> >>> this apache project?  :) I am with you :)
> >>
> >> Perhaps the org.apache.pdfbox.pdmodel.interactive.digitalsignature is in
> >> need of simplification, what do you think?
> >>
> >> Thanks for your efforts!
> >>
> >> -- John
> >>
> >> On 9 Mar 2014, at 10:21, Vakhtang koroghlishvili <
> >> vakhtang.koroghlishvili@gmail.com> wrote:
> >>
> >>> Hello,
> >>>
> >>> how are you? :)
> >>>
> >>> You know , that I have already fix and implement some issues and new
> >>> features which was about digital signature. I have already  created
> >> another
> >>> new features too but I don't know  if I should create this patches in
> the
> >>> pdfbox example project. I think, it's time to create another project
> >> named
> >>> sign-box or something like that.  At the moment I have time and I can
> >>> create that project  with very good  design architect and show you a
> >> patch
> >>> or comitters  can create that project with existence features and then
> we
> >>> will add new features step by step.
> >>>
> >>> I will write here, what we have at the moment, and what can we add too:
> >>>
> >>> At the moment, if we want to use pdfbox for the document signing , we
> can
> >>> only do that thing:
> >>>
> >>> 1. create basic digital signature with the time of CPU. *done*
> >>> 2. create digital signature with visible signature. *done* -that was my
> >>> first contribution :-)
> >>>
> >>> This is very poor functionality and is not easy to use. It's just in
> the
> >>> project named "examples". It must have very easy API, as we sad before.
> >>>
> >>> I have implement and  add another functionality  nd created patches
>  some
> >>> of them. some patches of new features is not updated in the jira,
> >> because I
> >>> don't now  whether this must be in the example project or not.  So, at
> >> the
> >>> moment I have that functionality:
> >>>
> >>>
> >>> 1. signing document with PADES-BES or PADES-BASIC profile, with CPU
> >> signing
> >>> time.  *done*
> >>>
> >>> 2. signing document with PADES-BES or PADES-BASIC profile, with
> timeStamp
> >>> server time. Already *implemented* - I have uploaded a patch in our
> jira,
> >>> some classes are in the "pdfbox" project and some classes are in the
> >>> "example" project.
> >>>
> >>> 3. signing document with timestamp server.  Already *implemented* and
> >> patch
> >>> is uploaded in a jira ...
> >>>
> >>> 4. creted document secure store and PADES LTV profile implementation
> >>> (advanced signatures!).  I have already *implemented* this. I can
> create
> >>> patch in the example project or create patch for sign-box too :) Tell
> me
> >>> and I will create patch for one of them :)
> >>>
> >>> 5. certificate chain verification  while signing process, against OCSP,
> >> CRL
> >>> protocols (with advanced ocsp, crl certificate verifications too!) - I
> >> have
> >>> already *implemented* this.
> >>> I can create patch in the example project or create patch for sign-box
> >> and
> >>> etc.. :-) :-) :-)
> >>>
> >>>
> >>> Finally,   I want tell you that I like that project and I want to help
> >> you
> >>> as I can.   I'm very well with digital signatures and I have very good
> >>> experience with this. So, if you need, please tell me what should I do
> >> for
> >>> this apache project?  :) I am with you :)
> >>>
> >>> Best regards,
> >>
> >>
>
>

Re: advanced signatures - the feature plans

Posted by John Hewson <jo...@jahewson.com>.
> Because of this classes is for creating visible signature fields (not for
> signing) we can not to move that classes. sign-box will be for only signing.

Ok. If these classes are not for signing then why are they in the digitalsignature package? Should they be moved elsewhere?

>> JIRA issue number?
> PDFBOX-1847 and PDFBOX-1848

Great, I’ll take a look.

> Yes, but sub-project architecture must not be the same because that
> sub-project API  must be very easy to use. So we might change some
> structures.

That’s fine, we can iterate and make changes. Getting a nice easy to use API always takes a number of refactorings, you can always submit more patches later on.

> As I see, that interfaces and classes are written very well.  We will add
> another classes and interfaces for another signature functionality. But
> most of them will be in the new sub-project.  We will move some classes
> from example-project to new sub-project, with different architecture.

Well, two of the interfaces are only implemented by one class, so they are redundant - unless your new sub-project has some new classes which implement them (I guess it probably does?).

-- John

On 10 Mar 2014, at 01:49, Vakhtang koroghlishvili <va...@gmail.com> wrote:

>> Should the classes in org.apache.pdfbox.pdmodel.
> interactive.digitalsignature.visible be moved into this new project also
> 
> Because of this classes is for creating visible signature fields (not for
> signing) we can not to move that classes. sign-box will be for only signing.
> 
>> is this already in PDFBox?
> As I remember Thomas Chojecki have implemented this in the example project
> of pdfbox like BASIC profile.  We can make it BES with some changes. I have
> implemented PADES LTV in my computer (this profile is based on this issues
> PDFBOX-1847  and PDFBOX-1848) and we will add this too.
> 
>> JIRA issue number?
> PDFBOX-1847 and PDFBOX-1848
> 
>> Creating your patches in the example project is fine, we can move them to
> a different sub-project for you.
> 
> Yes, but sub-project architecture must not be the same because that
> sub-project API  must be very easy to use. So we might change some
> structures.  Finally the architect will be like that:  you will just create
> signature object and then you will call signing method with your signature
> profile and parameters, and that's all it is very simplified. So we must
> create different architecture of that.  As I remember Thomas Chojecki was
> creating  code review of that patches.  :) So we should wait :)
> 
>> Perhaps the org.apache.pdfbox.pdmodel.interactive.digitalsignature is in
> need of simplification, what do you think?
> 
> As I see, that interfaces and classes are written very well.  We will add
> another classes and interfaces for another signature functionality. But
> most of them will be in the new sub-project.  We will move some classes
> from example-project to new sub-project, with different architecture.
> 
> 
> On Mon, Mar 10, 2014 at 10:54 AM, John Hewson <jo...@jahewson.com> wrote:
> 
>> Hi Vakhtang,
>> 
>>> I think, it's time to create another project named sign-box or something
>> like that.
>> 
>> Should the classes in
>> org.apache.pdfbox.pdmodel.interactive.digitalsignature.visible be moved
>> into this new project also?
>> 
>> My understanding is that the PDF spec defines a basic signature container
>> which is extensible and can embed signature formats defined by others, e.g.
>> the PAdES standard defined by ETSI. This seems like a good candidate for a
>> new sub-project e.g. "pdfbox-signing".
>> 
>>> 1. create basic digital signature with the time of CPU. *done*
>>> 2. create digital signature with visible signature. *done*
>>> 
>> 
>>> This is very poor functionality and is not easy to use. It's just in the
>>> project named "examples". It must have very easy API, as we said before.
>> 
>> It would be nice to have a command-line program e.g. "SignPDF" in
>> pdfbox-tools.
>> 
>>> So, at the moment I have that functionality:
>>> 
>>> 1. signing document with PADES-BES or PADES-BASIC profile, with CPU
>> signing
>>> time.  *done*
>> 
>> Just checking: is this already in PDFBox?
>> 
>>> 2. signing document with PADES-BES or PADES-BASIC profile, with timeStamp
>>> server time. Already *implemented* - I have uploaded a patch in our jira,
>>> some classes are in the "pdfbox" project and some classes are in the
>>> "example" project.
>> 
>> Great, what is the JIRA issue number?
>> 
>>> 3. signing document with timestamp server.  Already *implemented* and
>> patch
>>> is uploaded in a jira ...
>> 
>> Same question:  JIRA issue number?
>> 
>>> 4. creted document secure store and PADES LTV profile implementation
>>> (advanced signatures!).  I have already *implemented* this. I can create
>>> patch in the example project or create patch for sign-box too :) Tell me
>>> and I will create patch for one of them :)
>> 
>> Creating your patches in the example project is fine, we can move them to
>> a different sub-project for you.
>> 
>>> 5. certificate chain verification  while signing process, against OCSP,
>> CRL
>>> protocols (with advanced ocsp, crl certificate verifications too!) - I
>> have
>>> already *implemented* this.
>>> I can create patch in the example project or create patch for sign-box
>> and
>>> etc.. :-) :-) :-)
>> 
>> Once again, the example project is fine, we can change the packages.
>> 
>>> Finally,   I want tell you that I like that project and I want to help
>> you
>>> as I can.   I'm very well with digital signatures and I have very good
>>> experience with this. So, if you need, please tell me what should I do
>> for
>>> this apache project?  :) I am with you :)
>> 
>> Perhaps the org.apache.pdfbox.pdmodel.interactive.digitalsignature is in
>> need of simplification, what do you think?
>> 
>> Thanks for your efforts!
>> 
>> -- John
>> 
>> On 9 Mar 2014, at 10:21, Vakhtang koroghlishvili <
>> vakhtang.koroghlishvili@gmail.com> wrote:
>> 
>>> Hello,
>>> 
>>> how are you? :)
>>> 
>>> You know , that I have already fix and implement some issues and new
>>> features which was about digital signature. I have already  created
>> another
>>> new features too but I don't know  if I should create this patches in the
>>> pdfbox example project. I think, it's time to create another project
>> named
>>> sign-box or something like that.  At the moment I have time and I can
>>> create that project  with very good  design architect and show you a
>> patch
>>> or comitters  can create that project with existence features and then we
>>> will add new features step by step.
>>> 
>>> I will write here, what we have at the moment, and what can we add too:
>>> 
>>> At the moment, if we want to use pdfbox for the document signing , we can
>>> only do that thing:
>>> 
>>> 1. create basic digital signature with the time of CPU. *done*
>>> 2. create digital signature with visible signature. *done* -that was my
>>> first contribution :-)
>>> 
>>> This is very poor functionality and is not easy to use. It's just in the
>>> project named "examples". It must have very easy API, as we sad before.
>>> 
>>> I have implement and  add another functionality  nd created patches  some
>>> of them. some patches of new features is not updated in the jira,
>> because I
>>> don't now  whether this must be in the example project or not.  So, at
>> the
>>> moment I have that functionality:
>>> 
>>> 
>>> 1. signing document with PADES-BES or PADES-BASIC profile, with CPU
>> signing
>>> time.  *done*
>>> 
>>> 2. signing document with PADES-BES or PADES-BASIC profile, with timeStamp
>>> server time. Already *implemented* - I have uploaded a patch in our jira,
>>> some classes are in the "pdfbox" project and some classes are in the
>>> "example" project.
>>> 
>>> 3. signing document with timestamp server.  Already *implemented* and
>> patch
>>> is uploaded in a jira ...
>>> 
>>> 4. creted document secure store and PADES LTV profile implementation
>>> (advanced signatures!).  I have already *implemented* this. I can create
>>> patch in the example project or create patch for sign-box too :) Tell me
>>> and I will create patch for one of them :)
>>> 
>>> 5. certificate chain verification  while signing process, against OCSP,
>> CRL
>>> protocols (with advanced ocsp, crl certificate verifications too!) - I
>> have
>>> already *implemented* this.
>>> I can create patch in the example project or create patch for sign-box
>> and
>>> etc.. :-) :-) :-)
>>> 
>>> 
>>> Finally,   I want tell you that I like that project and I want to help
>> you
>>> as I can.   I'm very well with digital signatures and I have very good
>>> experience with this. So, if you need, please tell me what should I do
>> for
>>> this apache project?  :) I am with you :)
>>> 
>>> Best regards,
>> 
>> 


Re: advanced signatures - the feature plans

Posted by Vakhtang koroghlishvili <va...@gmail.com>.
> Should the classes in org.apache.pdfbox.pdmodel.
interactive.digitalsignature.visible be moved into this new project also

Because of this classes is for creating visible signature fields (not for
signing) we can not to move that classes. sign-box will be for only signing.

>  is this already in PDFBox?
As I remember Thomas Chojecki have implemented this in the example project
of pdfbox like BASIC profile.  We can make it BES with some changes. I have
implemented PADES LTV in my computer (this profile is based on this issues
PDFBOX-1847  and PDFBOX-1848) and we will add this too.

> JIRA issue number?
PDFBOX-1847 and PDFBOX-1848

> Creating your patches in the example project is fine, we can move them to
a different sub-project for you.

Yes, but sub-project architecture must not be the same because that
sub-project API  must be very easy to use. So we might change some
structures.  Finally the architect will be like that:  you will just create
signature object and then you will call signing method with your signature
profile and parameters, and that's all it is very simplified. So we must
create different architecture of that.  As I remember Thomas Chojecki was
creating  code review of that patches.  :) So we should wait :)

> Perhaps the org.apache.pdfbox.pdmodel.interactive.digitalsignature is in
need of simplification, what do you think?

As I see, that interfaces and classes are written very well.  We will add
another classes and interfaces for another signature functionality. But
most of them will be in the new sub-project.  We will move some classes
from example-project to new sub-project, with different architecture.















On Mon, Mar 10, 2014 at 10:54 AM, John Hewson <jo...@jahewson.com> wrote:

> Hi Vakhtang,
>
> > I think, it's time to create another project named sign-box or something
> like that.
>
> Should the classes in
> org.apache.pdfbox.pdmodel.interactive.digitalsignature.visible be moved
> into this new project also?
>
> My understanding is that the PDF spec defines a basic signature container
> which is extensible and can embed signature formats defined by others, e.g.
> the PAdES standard defined by ETSI. This seems like a good candidate for a
> new sub-project e.g. "pdfbox-signing".
>
> > 1. create basic digital signature with the time of CPU. *done*
> > 2. create digital signature with visible signature. *done*
> >
>
> > This is very poor functionality and is not easy to use. It's just in the
> > project named "examples". It must have very easy API, as we said before.
>
> It would be nice to have a command-line program e.g. "SignPDF" in
> pdfbox-tools.
>
> > So, at the moment I have that functionality:
> >
> > 1. signing document with PADES-BES or PADES-BASIC profile, with CPU
> signing
> > time.  *done*
>
> Just checking: is this already in PDFBox?
>
> > 2. signing document with PADES-BES or PADES-BASIC profile, with timeStamp
> > server time. Already *implemented* - I have uploaded a patch in our jira,
> > some classes are in the "pdfbox" project and some classes are in the
> > "example" project.
>
> Great, what is the JIRA issue number?
>
> > 3. signing document with timestamp server.  Already *implemented* and
> patch
> > is uploaded in a jira ...
>
> Same question:  JIRA issue number?
>
> > 4. creted document secure store and PADES LTV profile implementation
> > (advanced signatures!).  I have already *implemented* this. I can create
> > patch in the example project or create patch for sign-box too :) Tell me
> > and I will create patch for one of them :)
>
> Creating your patches in the example project is fine, we can move them to
> a different sub-project for you.
>
> > 5. certificate chain verification  while signing process, against OCSP,
> CRL
> > protocols (with advanced ocsp, crl certificate verifications too!) - I
> have
> > already *implemented* this.
> > I can create patch in the example project or create patch for sign-box
> and
> > etc.. :-) :-) :-)
>
> Once again, the example project is fine, we can change the packages.
>
> > Finally,   I want tell you that I like that project and I want to help
> you
> > as I can.   I'm very well with digital signatures and I have very good
> > experience with this. So, if you need, please tell me what should I do
> for
> > this apache project?  :) I am with you :)
>
> Perhaps the org.apache.pdfbox.pdmodel.interactive.digitalsignature is in
> need of simplification, what do you think?
>
> Thanks for your efforts!
>
> -- John
>
> On 9 Mar 2014, at 10:21, Vakhtang koroghlishvili <
> vakhtang.koroghlishvili@gmail.com> wrote:
>
> > Hello,
> >
> > how are you? :)
> >
> > You know , that I have already fix and implement some issues and new
> > features which was about digital signature. I have already  created
> another
> > new features too but I don't know  if I should create this patches in the
> > pdfbox example project. I think, it's time to create another project
> named
> > sign-box or something like that.  At the moment I have time and I can
> > create that project  with very good  design architect and show you a
> patch
> > or comitters  can create that project with existence features and then we
> > will add new features step by step.
> >
> > I will write here, what we have at the moment, and what can we add too:
> >
> > At the moment, if we want to use pdfbox for the document signing , we can
> > only do that thing:
> >
> > 1. create basic digital signature with the time of CPU. *done*
> > 2. create digital signature with visible signature. *done* -that was my
> > first contribution :-)
> >
> > This is very poor functionality and is not easy to use. It's just in the
> > project named "examples". It must have very easy API, as we sad before.
> >
> > I have implement and  add another functionality  nd created patches  some
> > of them. some patches of new features is not updated in the jira,
> because I
> > don't now  whether this must be in the example project or not.  So, at
> the
> > moment I have that functionality:
> >
> >
> > 1. signing document with PADES-BES or PADES-BASIC profile, with CPU
> signing
> > time.  *done*
> >
> > 2. signing document with PADES-BES or PADES-BASIC profile, with timeStamp
> > server time. Already *implemented* - I have uploaded a patch in our jira,
> > some classes are in the "pdfbox" project and some classes are in the
> > "example" project.
> >
> > 3. signing document with timestamp server.  Already *implemented* and
> patch
> > is uploaded in a jira ...
> >
> > 4. creted document secure store and PADES LTV profile implementation
> > (advanced signatures!).  I have already *implemented* this. I can create
> > patch in the example project or create patch for sign-box too :) Tell me
> > and I will create patch for one of them :)
> >
> > 5. certificate chain verification  while signing process, against OCSP,
> CRL
> > protocols (with advanced ocsp, crl certificate verifications too!) - I
> have
> > already *implemented* this.
> > I can create patch in the example project or create patch for sign-box
> and
> > etc.. :-) :-) :-)
> >
> >
> > Finally,   I want tell you that I like that project and I want to help
> you
> > as I can.   I'm very well with digital signatures and I have very good
> > experience with this. So, if you need, please tell me what should I do
> for
> > this apache project?  :) I am with you :)
> >
> > Best regards,
>
>

Re: advanced signatures - the feature plans

Posted by John Hewson <jo...@jahewson.com>.
Hi Vakhtang,

> I think, it's time to create another project named sign-box or something like that.

Should the classes in org.apache.pdfbox.pdmodel.interactive.digitalsignature.visible be moved into this new project also?

My understanding is that the PDF spec defines a basic signature container which is extensible and can embed signature formats defined by others, e.g. the PAdES standard defined by ETSI. This seems like a good candidate for a new sub-project e.g. “pdfbox-signing”.

> 1. create basic digital signature with the time of CPU. *done*
> 2. create digital signature with visible signature. *done*
> 

> This is very poor functionality and is not easy to use. It's just in the
> project named "examples". It must have very easy API, as we said before.

It would be nice to have a command-line program e.g. “SignPDF” in pdfbox-tools.

> So, at the moment I have that functionality:
> 
> 1. signing document with PADES-BES or PADES-BASIC profile, with CPU signing
> time.  *done*

Just checking: is this already in PDFBox?

> 2. signing document with PADES-BES or PADES-BASIC profile, with timeStamp
> server time. Already *implemented* - I have uploaded a patch in our jira,
> some classes are in the "pdfbox" project and some classes are in the
> "example" project.

Great, what is the JIRA issue number?

> 3. signing document with timestamp server.  Already *implemented* and patch
> is uploaded in a jira …

Same question:  JIRA issue number?

> 4. creted document secure store and PADES LTV profile implementation
> (advanced signatures!).  I have already *implemented* this. I can create
> patch in the example project or create patch for sign-box too :) Tell me
> and I will create patch for one of them :)

Creating your patches in the example project is fine, we can move them to a different sub-project for you.

> 5. certificate chain verification  while signing process, against OCSP, CRL
> protocols (with advanced ocsp, crl certificate verifications too!) - I have
> already *implemented* this.
> I can create patch in the example project or create patch for sign-box and
> etc.. :-) :-) :-)

Once again, the example project is fine, we can change the packages.

> Finally,   I want tell you that I like that project and I want to help you
> as I can.   I'm very well with digital signatures and I have very good
> experience with this. So, if you need, please tell me what should I do for
> this apache project?  :) I am with you :)

Perhaps the org.apache.pdfbox.pdmodel.interactive.digitalsignature is in need of simplification, what do you think?

Thanks for your efforts!

-- John

On 9 Mar 2014, at 10:21, Vakhtang koroghlishvili <va...@gmail.com> wrote:

> Hello,
> 
> how are you? :)
> 
> You know , that I have already fix and implement some issues and new
> features which was about digital signature. I have already  created another
> new features too but I don't know  if I should create this patches in the
> pdfbox example project. I think, it's time to create another project named
> sign-box or something like that.  At the moment I have time and I can
> create that project  with very good  design architect and show you a patch
> or comitters  can create that project with existence features and then we
> will add new features step by step.
> 
> I will write here, what we have at the moment, and what can we add too:
> 
> At the moment, if we want to use pdfbox for the document signing , we can
> only do that thing:
> 
> 1. create basic digital signature with the time of CPU. *done*
> 2. create digital signature with visible signature. *done* -that was my
> first contribution :-)
> 
> This is very poor functionality and is not easy to use. It's just in the
> project named "examples". It must have very easy API, as we sad before.
> 
> I have implement and  add another functionality  nd created patches  some
> of them. some patches of new features is not updated in the jira, because I
> don't now  whether this must be in the example project or not.  So, at the
> moment I have that functionality:
> 
> 
> 1. signing document with PADES-BES or PADES-BASIC profile, with CPU signing
> time.  *done*
> 
> 2. signing document with PADES-BES or PADES-BASIC profile, with timeStamp
> server time. Already *implemented* - I have uploaded a patch in our jira,
> some classes are in the "pdfbox" project and some classes are in the
> "example" project.
> 
> 3. signing document with timestamp server.  Already *implemented* and patch
> is uploaded in a jira ...
> 
> 4. creted document secure store and PADES LTV profile implementation
> (advanced signatures!).  I have already *implemented* this. I can create
> patch in the example project or create patch for sign-box too :) Tell me
> and I will create patch for one of them :)
> 
> 5. certificate chain verification  while signing process, against OCSP, CRL
> protocols (with advanced ocsp, crl certificate verifications too!) - I have
> already *implemented* this.
> I can create patch in the example project or create patch for sign-box and
> etc.. :-) :-) :-)
> 
> 
> Finally,   I want tell you that I like that project and I want to help you
> as I can.   I'm very well with digital signatures and I have very good
> experience with this. So, if you need, please tell me what should I do for
> this apache project?  :) I am with you :)
> 
> Best regards,