> 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 <[email protected]> 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 <[email protected]> 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 < >> [email protected]> 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, >> >>
