Re: [dss-comment] DSS for PDF

[Andreas Kuehne <kuehne@trustable.de>]

Hi Pim,

>  In a project we are looking at applying DSS to sealing (and in the 
> future,
>  signing) of PDF documents.
Don't know what the term 'sealing' exactly means ..

>  DSS can sign arbitrary binary documents using an XML digital 
> signature.
>  However, we are looking at having the service return PDF documents 
> with the
>  electronic signature added inside a modified document, conform the PDF
>  standard, rather than as a separate XML digital signature of the BLOB.
>  There does not seem to be a DSS profile to support this PDF specific 
> type of
>  processing.
>  Is that correct?
Yes, this is planned for the forthcoming DSS/X version.

Anyway, we do support native PDF signing with our open source signing 
server, yet.

Furthermore we run our SigningServer in SaaS mode for users with low 
volume and minor interest in big investments.

But enough sales activity for now : For simple usage scenarios I would 
recommend to take a look a the free iText library, it supports some 
basic signing functionality.


>  Some products seem to support PDF signing.  Is there any information 
> on how
>  they support this in DSS?
>
>  Here's how we are thinking of using it:
>  The PDF document to be signed could be passed in the request as:
>
>      <dss:InputDocuments>
>          <dss:Document ID="doc2">
>              <dss:Base64Data> .. </dss:Base64Data>
>          </dss:Document>
>      </dss:InputDocuments>
>
>  The profile name could then indicate a request to do PDF specific 
> signing.
>  Or, we could extend the DSS schema using something like the following:
>
>      <dss:InputDocuments>
>          <dss:Document ID="doc2">
>              <dss:Base64PDF> .. </dss:Base64PDF>
>          </dss:Document>
>      </dss:InputDocuments>
>
>  What would be the best approach?
>
>  An embedded signature could be requested using something like:
>
>  <dss:OptionalInputs>
>      <dss:SignaturePlacement>
>          ...
>      </dss:SignaturePlacement>
>  </dss:OptionalInputs>
>
>  The dss:SignaturePlacement element from DSS 1.0 now allows a 
> dss:XpathAfter
>  or a dss:XpathFirstChildOf element content.
>  It looks as if for PDF signing this should be extended with elements 
> to
>  specify the requested type of PDF signature.
>  For instance, the signature field in which the document (ordinary) 
> signature
>  is to be placed could be encoded using something like:
>
>  <dss:OptionalInputs>
>      <dss:SignaturePlacement>
>
>  <dss:PDFSignatureFieldName>SecondReviewer</dss:PDFSignatureFieldName>
>      </dss:SignaturePlacement>
>  </dss:OptionalInputs>
>
>  This hypothetical example would request a signature to be placed in 
> the PDF
>  signature field name for a "second reviewer".
>
>  The signed PDF could be returned using the following structure:
>
>      <dss:OptionalOutputs>
>          <dss:DocumentWithSignature>
>              <dss:Document><dss:Base64Data> ...
>  </dss:Base64Data></dss:Document>
>          </dss:DocumentWithSignature>
>      </dss:OptionalOutputs>
>
>  Or again explicitly encode the fact that the dss:Document is a PDF 
> document:
>
>      <dss:OptionalOutputs>
>          <dss:DocumentWithSignature>
>              <dss:Document><dss:Base64PDF> ...
>  </dss:Base64PDF></dss:Document>
>          </dss:DocumentWithSignature>
>      </dss:OptionalOutputs>
>
>
>  To encode that we would be using an extension for PDF, one approach 
> would be
>  to have a distinct profile ID, like
>  "urn:ourproprietaryextensions:dss:1.0:profiles:pdfeseal".
>  But it looks as if the PDF versus other document types distinction is
>  orthogonal to profiles.
>  PDF documents can also be signed, sealed, signed using Xades, be 
> signed
>  subject to German signature law etc.
>  So some way to use another mechanism than profile name seem 
> appropriate.

Your proposal seems to be a good starting point for the DSS/X 
discussions ;-)

Yes, your point of non-orthogonality seems valid for me, too. But on the 
other hand it was the intention to keep the core clear of too domain 
specific aspects. I would like to see the DSS core as a 'must 
understand' base for all implementors. The support for special profiles 
is not mandatory. For me the support of PDF clearly belongs into the 
second category !

Greetings

Andreas



___________________________________________________
Andreas Kühne
phone: +49 177 293 24 97
mailto: kuehne@trustable.de


Trustable Ltd.
Niederlassung Deutschland
Ströverstr. 18 - 59427 Unna
Amtsgericht Hamm HRB 5868

Directors
Andreas Kühne
Heiko Veit

Company UK
Company No: 5218868
Registered in England and Wales