You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pdfbox.apache.org by Thomas Chojecki <in...@rayman2200.de> on 2015/04/16 01:03:28 UTC
CryptoBox and ETSI PAdES Plugtest
Hello,
I've startet creating a crypto engine for pdfbox. The aim is to provide
a highlevel api for signing and verifying pdf documents.
The engine is called cryptobox and is splited into a 1.8.x and
main branch. After the basic functions are ready in the 1.8.x, I will
do a pdfbox 2.0.x port and clean up the signature interface.
The goal is to do a pdfbox reference implementation for PAdES [1] up to
part 4 of the specification or I will go straight to the Europen Union
Commision Decision [2]. I hope with the help of the community, we have a
chance to reach the goal.
At the moment the code is hosted on github [3] but I will move it to the
apache repository after the codebase reached a usable level. It is
easier for me to prepare the code and play with it on github (less
restrictions).
From 4 to 29 May 2015 ETSI is making a PAdES PlugTest [4], I'm already
a participant and will try to test the cryptobox. So I first try to go
through the specification and later port stuff like visual signatures.
Maybe we can participant as Apache at such plugtests, so we can gain
more publicity.
I don't made much planing, but I think this roadmap could be a good
start:
- Implement pdf signatures and verification for the ISO 32000-1:2008
specification.
- Implement the ETSI signature specification PAdES
(deadline is the PlugTest)
- Basic signature service, maybe webservice or gui application.
- Port the visual signature stuff that already exist and maybe start a
table based visualisation (without the need to create pictures)
- Port it to pdfbox 2.0.x with NonSeqParser
- Cleanup the existing pdfbox signature code
other parts that need to be done are:
- refactor signature interface and coswriter
- make pdf signature streamable without the dirty hooks that are needed now.
- there where already plans to move the pdf encryption from pdfbox
to a new module. Maybe we can move it into the cryptobox.
I don't want promise anything, so I try mainly get through the plugtest
and show how the feedback is.
If you have some ideas how the cryptobox can be improved or maybe how
the architecture may look like to provide best usability, then
please give me some suggestions.
Best regards
Thomas
[1]
http://www.etsi.org/news-events/news/324-news-release-14th-september-2009
[2] http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32011D0130
[3] https://github.com/Rayman2200/cryptobox/tree/1.8
[4] http://xades-portal.etsi.org/pub/index.shtml
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org
Re: CryptoBox and ETSI PAdES Plugtest
Posted by Maruan Sahyoun <sa...@fileaffairs.de>.
Hi,
> Am 16.04.2015 um 12:59 schrieb Thomas Chojecki <in...@rayman2200.de>:
>
>
> Zitat von Maruan Sahyoun <sa...@fileaffairs.de>:
>
>> Hi,
>>
>
> Hi Maruan,
>
>>> From 4 to 29 May 2015 ETSI is making a PAdES PlugTest [4], I'm already
>>> a participant and will try to test the cryptobox. So I first try to go
>>> through the specification and later port stuff like visual signatures.
>>>
>>> Maybe we can participant as Apache at such plugtests, so we can gain
>>> more publicity.
>>
>> good idea - what would we need to participate as Apache PDFBox?
>>
>
> The first registration should be done by the apache office. There is also a NDA that need to be signed. This means that all data from the plugtest are not public and the test would run in a kind of blackbox.
>
> Then the office need to register the participating members, so each member will get access to the plugtest and can use there infra. That's all.
>
> This plugtest is free of charge, but this wasn't always the case.
>
> The registration deadline is the end of april.
>
>>>
>>>
>>>
>>> I don't made much planing, but I think this roadmap could be a good
>>> start:
>>>
>>> - Implement pdf signatures and verification for the ISO 32000-1:2008
>>> specification.
>>> - Implement the ETSI signature specification PAdES
>>> (deadline is the PlugTest)
>>>
>>> - Basic signature service, maybe webservice or gui application.
>>> - Port the visual signature stuff that already exist and maybe start a
>>> table based visualisation (without the need to create pictures)
>>> - Port it to pdfbox 2.0.x with NonSeqParser
>>> - Cleanup the existing pdfbox signature code
>>>
>>> other parts that need to be done are:
>>> - refactor signature interface and coswriter
>>> - make pdf signature streamable without the dirty hooks that are needed now.
>>> - there where already plans to move the pdf encryption from pdfbox
>>> to a new module. Maybe we can move it into the cryptobox.
>>>
>>> I don't want promise anything, so I try mainly get through the plugtest
>>> and show how the feedback is.
>>>
>>> If you have some ideas how the cryptobox can be improved or maybe how
>>> the architecture may look like to provide best usability, then
>>> please give me some suggestions.
>>
>> I quickly scanned through the code - there are some features from Java 1.7 such as Objects.requireNonNull in CoreHelper.copy. As PDFBox is currently on 1.6 this might be an issue when bringing it over.
>>
>> Here are some of my initial thoughts
>>
>> API wise maybe there could be a class SignatureService with sign(), certify() and verify() methods loading a PDDocument.
>>
>> so the signing process would look something like
>>
>> PDDocument doc = PDDocument.load
>> SignatureService sigservice = SignatureService.newInstance(doc);
>> sigservice.sign(SignatureOptions, OutputStream);
>
> Yes such a service with PDDocument as base would be great, but we need to refactor first the signature part in the pdfbox. At the moment we are bound to files. So the 1.8.x and the first 2.0.x release will be file and stream-based. But I have this in mind.
>
> So at the moment we need to live with the fact that the SignatureService creates the PDDocument itself.
OK
>
>>
>> As for the packaging maybe it could live in org.apache.pdfbox.services.crypto as this would allow for additional services to be added at a later stage wo. having so many top level packages (services being a sample we'd need to decide on).
>
> What services are planed? I thought putting all stuff in crypto and do there the additional packages like sign, encrypt, verify would be ok. But if we plan more services that aren't covert by crypto, I would understand this step.
Don't know yet - but I'm also looking at doing form flattening - of course that could live inside interactive.forms - so that was only an initial thought.
>
>> As for the general naming maybe this could be renamed to pdfbox-crypto to utilize the PDFBox name fully and not only the box part.
>
> Are you sure? As it will be a submodule of the pdfbox, I thought it should match the other module names such fontbox, jempbox, xmpbox and so on. Naming the github project pdfbox-crypto will be indeed ok, but I think later we does not need the additional pdfbox- in the name.
Again something worth discussing. If there are more subproject IMHO the current naming won't scale.
>
>>
>>
>> BR
>> Maruan
>>
>
> Best regards
> Thomas
>
>>>
>>> [1]
>>> http://www.etsi.org/news-events/news/324-news-release-14th-september-2009
>>> [2] http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32011D0130
>>> [3] https://github.com/Rayman2200/cryptobox/tree/1.8
>>> [4] http://xades-portal.etsi.org/pub/index.shtml
>>>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: dev-help@pdfbox.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org
Re: CryptoBox and ETSI PAdES Plugtest
Posted by Thomas Chojecki <in...@rayman2200.de>.
Zitat von Maruan Sahyoun <sa...@fileaffairs.de>:
> Hi,
>
Hi Maruan,
>> From 4 to 29 May 2015 ETSI is making a PAdES PlugTest [4], I'm already
>> a participant and will try to test the cryptobox. So I first try to go
>> through the specification and later port stuff like visual signatures.
>>
>> Maybe we can participant as Apache at such plugtests, so we can gain
>> more publicity.
>
> good idea - what would we need to participate as Apache PDFBox?
>
The first registration should be done by the apache office. There is
also a NDA that need to be signed. This means that all data from the
plugtest are not public and the test would run in a kind of blackbox.
Then the office need to register the participating members, so each
member will get access to the plugtest and can use there infra. That's
all.
This plugtest is free of charge, but this wasn't always the case.
The registration deadline is the end of april.
>>
>>
>>
>> I don't made much planing, but I think this roadmap could be a good
>> start:
>>
>> - Implement pdf signatures and verification for the ISO 32000-1:2008
>> specification.
>> - Implement the ETSI signature specification PAdES
>> (deadline is the PlugTest)
>>
>> - Basic signature service, maybe webservice or gui application.
>> - Port the visual signature stuff that already exist and maybe start a
>> table based visualisation (without the need to create pictures)
>> - Port it to pdfbox 2.0.x with NonSeqParser
>> - Cleanup the existing pdfbox signature code
>>
>> other parts that need to be done are:
>> - refactor signature interface and coswriter
>> - make pdf signature streamable without the dirty hooks that are needed now.
>> - there where already plans to move the pdf encryption from pdfbox
>> to a new module. Maybe we can move it into the cryptobox.
>>
>> I don't want promise anything, so I try mainly get through the plugtest
>> and show how the feedback is.
>>
>> If you have some ideas how the cryptobox can be improved or maybe how
>> the architecture may look like to provide best usability, then
>> please give me some suggestions.
>
> I quickly scanned through the code - there are some features from
> Java 1.7 such as Objects.requireNonNull in CoreHelper.copy. As
> PDFBox is currently on 1.6 this might be an issue when bringing it
> over.
>
> Here are some of my initial thoughts
>
> API wise maybe there could be a class SignatureService with sign(),
> certify() and verify() methods loading a PDDocument.
>
> so the signing process would look something like
>
> PDDocument doc = PDDocument.load
> SignatureService sigservice = SignatureService.newInstance(doc);
> sigservice.sign(SignatureOptions, OutputStream);
Yes such a service with PDDocument as base would be great, but we need
to refactor first the signature part in the pdfbox. At the moment we
are bound to files. So the 1.8.x and the first 2.0.x release will be
file and stream-based. But I have this in mind.
So at the moment we need to live with the fact that the
SignatureService creates the PDDocument itself.
>
> As for the packaging maybe it could live in
> org.apache.pdfbox.services.crypto as this would allow for additional
> services to be added at a later stage wo. having so many top level
> packages (services being a sample we'd need to decide on).
What services are planed? I thought putting all stuff in crypto and do
there the additional packages like sign, encrypt, verify would be ok.
But if we plan more services that aren't covert by crypto, I would
understand this step.
> As for the general naming maybe this could be renamed to
> pdfbox-crypto to utilize the PDFBox name fully and not only the box
> part.
Are you sure? As it will be a submodule of the pdfbox, I thought it
should match the other module names such fontbox, jempbox, xmpbox and
so on. Naming the github project pdfbox-crypto will be indeed ok, but
I think later we does not need the additional pdfbox- in the name.
>
>
> BR
> Maruan
>
Best regards
Thomas
>>
>> [1]
>> http://www.etsi.org/news-events/news/324-news-release-14th-september-2009
>> [2] http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32011D0130
>> [3] https://github.com/Rayman2200/cryptobox/tree/1.8
>> [4] http://xades-portal.etsi.org/pub/index.shtml
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org
Re: CryptoBox and ETSI PAdES Plugtest
Posted by Isaias Barroso <is...@gmail.com>.
Hi Thomas,
For Timestamp you don't need to write a server, just use a online server,
for example http://services.globaltrustfinder.com/adss/tsa I have used it
with TSA Signature example os PDFBoxb 2.0 Codebase. Works fine, threre many
others available, just search for RFC 3161 online server.
Best regards
On Apr 17, 2015 4:15 AM, "Thomas Chojecki" <in...@rayman2200.de> wrote:
> Hello all,
> I got the first PAdES BES signature done :-) There is still lot of work to
> do, but it slowly picks up speed. Can't wait for the weekend.
>
> I forgot to say, that for signatures with long term support, some OCSP /
> CRL and Timestamp stuff need to be done. Maybe I can find some suitable
> free server that I can use for testing. The worst case will be to write a
> dummy server for the timestamp responses. I decided to use the PAdES
> Baseline Profile [1] for the PAdES implementation which is based on [2]. So
> this should be the newest version of PAdES.
>
> The next step will be the verification. I have no idea what informations I
> should write in the verification report, neither how the report should look
> like. There is already a verification report specification called "OASIS
> Verification Report" [3], but I think this would be oversized.
>
> Best regards
> Thomas
>
> [1]
> http://www.etsi.org/deliver/etsi_ts/103100_103199/103172/02.01.01_60/ts_103172v020101p.pdf
> [2]
> http://www.etsi.org/deliver/etsi_ts/102700_102799/10277803/01.01.01_60/ts_10277803v010101p.pdf
> [3]
> http://docs.oasis-open.org/dss-x/profiles/verificationreport/oasis-dssx-1.0-profiles-vr-cd01.html
>
>
> Zitat von Maruan Sahyoun <sa...@fileaffairs.de>:
>
> Hi,
>>
> Hi Maruan,
>
> Am 16.04.2015 um 01:03 schrieb Thomas Chojecki <in...@rayman2200.de>:
>>>
>>> I quickly scanned through the code - there are some features from Java
>> 1.7 such as Objects.requireNonNull in CoreHelper.copy. As PDFBox is
>> currently on 1.6 this might be an issue when bringing it over.
>>
>
> Thx for the hint. I fixed it. Can't understand why the code compiles and
> run through maven install.
>
> Nevertheless I found a missmatch in the parent pom. The compiler section
> in 1.8.10-SNAPSHOT states:
>
> <plugin>
> <artifactId>maven-compiler-plugin</artifactId>
> <configuration>
> <target>1.5</target>
> <source>1.5</source>
> </configuration>
> </plugin>
>
> So the project compiles again Java 5. Did I miss something or did someone
> forget to switch it to 1.6?
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: dev-help@pdfbox.apache.org
>
>
Re: CryptoBox and ETSI PAdES Plugtest
Posted by Thomas Chojecki <in...@rayman2200.de>.
Hello all,
I got the first PAdES BES signature done :-) There is still lot of
work to do, but it slowly picks up speed. Can't wait for the weekend.
I forgot to say, that for signatures with long term support, some OCSP
/ CRL and Timestamp stuff need to be done. Maybe I can find some
suitable free server that I can use for testing. The worst case will
be to write a dummy server for the timestamp responses. I decided to
use the PAdES Baseline Profile [1] for the PAdES implementation which
is based on [2]. So this should be the newest version of PAdES.
The next step will be the verification. I have no idea what
informations I should write in the verification report, neither how
the report should look like. There is already a verification report
specification called "OASIS Verification Report" [3], but I think this
would be oversized.
Best regards
Thomas
[1]
http://www.etsi.org/deliver/etsi_ts/103100_103199/103172/02.01.01_60/ts_103172v020101p.pdf
[2]
http://www.etsi.org/deliver/etsi_ts/102700_102799/10277803/01.01.01_60/ts_10277803v010101p.pdf
[3]
http://docs.oasis-open.org/dss-x/profiles/verificationreport/oasis-dssx-1.0-profiles-vr-cd01.html
Zitat von Maruan Sahyoun <sa...@fileaffairs.de>:
> Hi,
Hi Maruan,
>> Am 16.04.2015 um 01:03 schrieb Thomas Chojecki <in...@rayman2200.de>:
>>
> I quickly scanned through the code - there are some features from
> Java 1.7 such as Objects.requireNonNull in CoreHelper.copy. As
> PDFBox is currently on 1.6 this might be an issue when bringing it
> over.
Thx for the hint. I fixed it. Can't understand why the code compiles
and run through maven install.
Nevertheless I found a missmatch in the parent pom. The compiler
section in 1.8.10-SNAPSHOT states:
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<target>1.5</target>
<source>1.5</source>
</configuration>
</plugin>
So the project compiles again Java 5. Did I miss something or did
someone forget to switch it to 1.6?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org
Re: CryptoBox and ETSI PAdES Plugtest
Posted by Maruan Sahyoun <sa...@fileaffairs.de>.
> Am 23.04.2015 um 10:51 schrieb John Hewson <jo...@jahewson.com>:
>
>
>> On 16 Apr 2015, at 01:52, Maruan Sahyoun <sa...@fileaffairs.de> wrote:
>>
>> Hi,
>>
>>> Am 16.04.2015 um 01:03 schrieb Thomas Chojecki <in...@rayman2200.de>:
>>>
>>> Hello,
>>> I've startet creating a crypto engine for pdfbox. The aim is to provide
>>> a highlevel api for signing and verifying pdf documents.
>>
>> great - this is a very important use case for PDFBox.
>>
>>>
>>> The engine is called cryptobox and is splited into a 1.8.x and
>>> main branch. After the basic functions are ready in the 1.8.x, I will
>>> do a pdfbox 2.0.x port and clean up the signature interface.
>>>
>>> The goal is to do a pdfbox reference implementation for PAdES [1] up to
>>> part 4 of the specification or I will go straight to the Europen Union
>>> Commision Decision [2]. I hope with the help of the community, we have a
>>> chance to reach the goal.
>>>
>>> At the moment the code is hosted on github [3] but I will move it to the
>>> apache repository after the codebase reached a usable level. It is
>>> easier for me to prepare the code and play with it on github (less
>>> restrictions).
>>>
>>> From 4 to 29 May 2015 ETSI is making a PAdES PlugTest [4], I'm already
>>> a participant and will try to test the cryptobox. So I first try to go
>>> through the specification and later port stuff like visual signatures.
>>>
>>> Maybe we can participant as Apache at such plugtests, so we can gain
>>> more publicity.
>>
>> good idea - what would we need to participate as Apache PDFBox?
>>
>>>
>>>
>>>
>>> I don't made much planing, but I think this roadmap could be a good
>>> start:
>>>
>>> - Implement pdf signatures and verification for the ISO 32000-1:2008
>>> specification.
>>> - Implement the ETSI signature specification PAdES
>>> (deadline is the PlugTest)
>>>
>>> - Basic signature service, maybe webservice or gui application.
>>> - Port the visual signature stuff that already exist and maybe start a
>>> table based visualisation (without the need to create pictures)
>>> - Port it to pdfbox 2.0.x with NonSeqParser
>>> - Cleanup the existing pdfbox signature code
>>>
>>> other parts that need to be done are:
>>> - refactor signature interface and coswriter
>>> - make pdf signature streamable without the dirty hooks that are needed now.
>>> - there where already plans to move the pdf encryption from pdfbox
>>> to a new module. Maybe we can move it into the cryptobox.
>>>
>>> I don't want promise anything, so I try mainly get through the plugtest
>>> and show how the feedback is.
>>>
>>> If you have some ideas how the cryptobox can be improved or maybe how
>>> the architecture may look like to provide best usability, then
>>> please give me some suggestions.
>>
>> I quickly scanned through the code - there are some features from Java 1.7 such as Objects.requireNonNull in CoreHelper.copy. As PDFBox is currently on 1.6 this might be an issue when bringing it over.
>
> Well spotted.
>
>> Here are some of my initial thoughts
>>
>> API wise maybe there could be a class SignatureService with sign(), certify() and verify() methods loading a PDDocument.
>>
>> so the signing process would look something like
>>
>> PDDocument doc = PDDocument.load
>> SignatureService sigservice = SignatureService.newInstance(doc);
>> sigservice.sign(SignatureOptions, OutputStream);
>
> I see where you're coming from but we already have SignatureInterface and PDSignature which allow pluggable signing and provide a cleaner API than this. They can be enhanced to serve any further needs. It's fine for PDDocument to delegate the signing process (as it already does via SignatureInterface) but it would be a mistake to delegate the saving process too, as happens in your example above.
>
> In other words, any API like PDDocument::sign(SignatureInterface) will work nicely, but one like SignatureService:save(PDDocument) won't, because it has the delegation of responsibilities backwards.
OK - thought to have it for convenience as signing means that you also have to save.
>
>> As for the packaging maybe it could live in org.apache.pdfbox.services.crypto as this would allow for additional services to be added at a later stage wo. having so many top level packages (services being a sample we'd need to decide on).
>
> My experience has been that "services" are background processes or remote processes. What you're describing is simply an interface, which is often called a "provider" in Java. Either way, there's no need to include it in the package name, org.apache.pdfbox.crypto does the job nicely.
there is no need for it - and services was only an example - but as we might add new capabilities 'above' PD a consistent package might provide some additional structure to keep these together. Again technically that's not needed.
>
>> As for the general naming maybe this could be renamed to pdfbox-crypto to utilize the PDFBox name fully and not only the box part.
>
> I agree, especially as the code is specific to PDF and not general crypto.
>
>> BR
>> Maruan
>>
>>>
>>> Best regards
>>> Thomas
>>>
>>> [1]
>>> http://www.etsi.org/news-events/news/324-news-release-14th-september-2009
>>> [2] http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32011D0130
>>> [3] https://github.com/Rayman2200/cryptobox/tree/1.8
>>> [4] http://xades-portal.etsi.org/pub/index.shtml
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
>>> For additional commands, e-mail: dev-help@pdfbox.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
>> For additional commands, e-mail: dev-help@pdfbox.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: dev-help@pdfbox.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org
Re: CryptoBox and ETSI PAdES Plugtest
Posted by John Hewson <jo...@jahewson.com>.
> On 16 Apr 2015, at 01:52, Maruan Sahyoun <sa...@fileaffairs.de> wrote:
>
> Hi,
>
>> Am 16.04.2015 um 01:03 schrieb Thomas Chojecki <in...@rayman2200.de>:
>>
>> Hello,
>> I've startet creating a crypto engine for pdfbox. The aim is to provide
>> a highlevel api for signing and verifying pdf documents.
>
> great - this is a very important use case for PDFBox.
>
>>
>> The engine is called cryptobox and is splited into a 1.8.x and
>> main branch. After the basic functions are ready in the 1.8.x, I will
>> do a pdfbox 2.0.x port and clean up the signature interface.
>>
>> The goal is to do a pdfbox reference implementation for PAdES [1] up to
>> part 4 of the specification or I will go straight to the Europen Union
>> Commision Decision [2]. I hope with the help of the community, we have a
>> chance to reach the goal.
>>
>> At the moment the code is hosted on github [3] but I will move it to the
>> apache repository after the codebase reached a usable level. It is
>> easier for me to prepare the code and play with it on github (less
>> restrictions).
>>
>> From 4 to 29 May 2015 ETSI is making a PAdES PlugTest [4], I'm already
>> a participant and will try to test the cryptobox. So I first try to go
>> through the specification and later port stuff like visual signatures.
>>
>> Maybe we can participant as Apache at such plugtests, so we can gain
>> more publicity.
>
> good idea - what would we need to participate as Apache PDFBox?
>
>>
>>
>>
>> I don't made much planing, but I think this roadmap could be a good
>> start:
>>
>> - Implement pdf signatures and verification for the ISO 32000-1:2008
>> specification.
>> - Implement the ETSI signature specification PAdES
>> (deadline is the PlugTest)
>>
>> - Basic signature service, maybe webservice or gui application.
>> - Port the visual signature stuff that already exist and maybe start a
>> table based visualisation (without the need to create pictures)
>> - Port it to pdfbox 2.0.x with NonSeqParser
>> - Cleanup the existing pdfbox signature code
>>
>> other parts that need to be done are:
>> - refactor signature interface and coswriter
>> - make pdf signature streamable without the dirty hooks that are needed now.
>> - there where already plans to move the pdf encryption from pdfbox
>> to a new module. Maybe we can move it into the cryptobox.
>>
>> I don't want promise anything, so I try mainly get through the plugtest
>> and show how the feedback is.
>>
>> If you have some ideas how the cryptobox can be improved or maybe how
>> the architecture may look like to provide best usability, then
>> please give me some suggestions.
>
> I quickly scanned through the code - there are some features from Java 1.7 such as Objects.requireNonNull in CoreHelper.copy. As PDFBox is currently on 1.6 this might be an issue when bringing it over.
Well spotted.
> Here are some of my initial thoughts
>
> API wise maybe there could be a class SignatureService with sign(), certify() and verify() methods loading a PDDocument.
>
> so the signing process would look something like
>
> PDDocument doc = PDDocument.load
> SignatureService sigservice = SignatureService.newInstance(doc);
> sigservice.sign(SignatureOptions, OutputStream);
I see where you're coming from but we already have SignatureInterface and PDSignature which allow pluggable signing and provide a cleaner API than this. They can be enhanced to serve any further needs. It's fine for PDDocument to delegate the signing process (as it already does via SignatureInterface) but it would be a mistake to delegate the saving process too, as happens in your example above.
In other words, any API like PDDocument::sign(SignatureInterface) will work nicely, but one like SignatureService:save(PDDocument) won't, because it has the delegation of responsibilities backwards.
> As for the packaging maybe it could live in org.apache.pdfbox.services.crypto as this would allow for additional services to be added at a later stage wo. having so many top level packages (services being a sample we'd need to decide on).
My experience has been that "services" are background processes or remote processes. What you're describing is simply an interface, which is often called a "provider" in Java. Either way, there's no need to include it in the package name, org.apache.pdfbox.crypto does the job nicely.
> As for the general naming maybe this could be renamed to pdfbox-crypto to utilize the PDFBox name fully and not only the box part.
I agree, especially as the code is specific to PDF and not general crypto.
> BR
> Maruan
>
>>
>> Best regards
>> Thomas
>>
>> [1]
>> http://www.etsi.org/news-events/news/324-news-release-14th-september-2009
>> [2] http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32011D0130
>> [3] https://github.com/Rayman2200/cryptobox/tree/1.8
>> [4] http://xades-portal.etsi.org/pub/index.shtml
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
>> For additional commands, e-mail: dev-help@pdfbox.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: dev-help@pdfbox.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org
Re: CryptoBox and ETSI PAdES Plugtest
Posted by Maruan Sahyoun <sa...@fileaffairs.de>.
Hi,
> Am 16.04.2015 um 01:03 schrieb Thomas Chojecki <in...@rayman2200.de>:
>
> Hello,
> I've startet creating a crypto engine for pdfbox. The aim is to provide
> a highlevel api for signing and verifying pdf documents.
great - this is a very important use case for PDFBox.
>
> The engine is called cryptobox and is splited into a 1.8.x and
> main branch. After the basic functions are ready in the 1.8.x, I will
> do a pdfbox 2.0.x port and clean up the signature interface.
>
> The goal is to do a pdfbox reference implementation for PAdES [1] up to
> part 4 of the specification or I will go straight to the Europen Union
> Commision Decision [2]. I hope with the help of the community, we have a
> chance to reach the goal.
>
> At the moment the code is hosted on github [3] but I will move it to the
> apache repository after the codebase reached a usable level. It is
> easier for me to prepare the code and play with it on github (less
> restrictions).
>
> From 4 to 29 May 2015 ETSI is making a PAdES PlugTest [4], I'm already
> a participant and will try to test the cryptobox. So I first try to go
> through the specification and later port stuff like visual signatures.
>
> Maybe we can participant as Apache at such plugtests, so we can gain
> more publicity.
good idea - what would we need to participate as Apache PDFBox?
>
>
>
> I don't made much planing, but I think this roadmap could be a good
> start:
>
> - Implement pdf signatures and verification for the ISO 32000-1:2008
> specification.
> - Implement the ETSI signature specification PAdES
> (deadline is the PlugTest)
>
> - Basic signature service, maybe webservice or gui application.
> - Port the visual signature stuff that already exist and maybe start a
> table based visualisation (without the need to create pictures)
> - Port it to pdfbox 2.0.x with NonSeqParser
> - Cleanup the existing pdfbox signature code
>
> other parts that need to be done are:
> - refactor signature interface and coswriter
> - make pdf signature streamable without the dirty hooks that are needed now.
> - there where already plans to move the pdf encryption from pdfbox
> to a new module. Maybe we can move it into the cryptobox.
>
> I don't want promise anything, so I try mainly get through the plugtest
> and show how the feedback is.
>
> If you have some ideas how the cryptobox can be improved or maybe how
> the architecture may look like to provide best usability, then
> please give me some suggestions.
I quickly scanned through the code - there are some features from Java 1.7 such as Objects.requireNonNull in CoreHelper.copy. As PDFBox is currently on 1.6 this might be an issue when bringing it over.
Here are some of my initial thoughts
API wise maybe there could be a class SignatureService with sign(), certify() and verify() methods loading a PDDocument.
so the signing process would look something like
PDDocument doc = PDDocument.load
SignatureService sigservice = SignatureService.newInstance(doc);
sigservice.sign(SignatureOptions, OutputStream);
As for the packaging maybe it could live in org.apache.pdfbox.services.crypto as this would allow for additional services to be added at a later stage wo. having so many top level packages (services being a sample we'd need to decide on).
As for the general naming maybe this could be renamed to pdfbox-crypto to utilize the PDFBox name fully and not only the box part.
BR
Maruan
>
> Best regards
> Thomas
>
> [1]
> http://www.etsi.org/news-events/news/324-news-release-14th-september-2009
> [2] http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32011D0130
> [3] https://github.com/Rayman2200/cryptobox/tree/1.8
> [4] http://xades-portal.etsi.org/pub/index.shtml
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: dev-help@pdfbox.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org