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