RE: [dss-comment] DSS for PDF

["Uri Resnitzky" <Uri@arx.com>]

Hello Pim,

We have developed a DSS profile for signing PDF documents in the native
format including optional parameters which allow you to create the
signature field itself and to specify the page #, coordinates and size
of the field as well as specifying its appearance settings including
graphical signature image, signer name, date/time format, etc.

We have also added protocol elements to handle the related tasks of:
- enumerating and verifying all existing signature fields in a PDF
document including retrieving all the above attributes (signature field
name, location, etc).
- clearing and/or removing a signature field
- inserting an empty signature field
- signing an existing empty signature field

All the above work is going to be contributed to the new DSS-X so it can
be standardized as part of the future "Visual Signatures" DSS profile or
another profile as the TC will see fit.

Specifically to the issues you raised:
- We propose that the document type will be indicated using the MimeType
attribute of the Base64Data element:

<InputDocuments>
  <Document>
    <Base64Data MimeType="application/pdf"> ... </Base64Data> 
  </Document>
</InputDocuments>

Our implementation can handle other file types (DOC/TIFF and ODF/OOXML
in the future) so the profile is not PDF specific.

- Selecting an existing signature field to sign is done using a new
Optional Input called SignatureFieldName (string type).

- The type of the returned file is again indicated using the MimeType
attribute:

<OptionalOutputs>
  <DocumentWithSignature>
    <Document>
      <Base64Data MimeType="application/pdf"> ... </Base64Data>
    </Document>
  </DocumentWithSignature>
</OptionalOutputs>

But notice that in the case of PDF, the PDF spec specifies a method of
adding content to PDF files by appending data only. In fact this is
mandatory in case the file is already signed in order not to break
existing signatures. This allows for improved performance by returning
only the new "tail" bytes that needs to be concatenated to the original
file by the client. To support this we propose to add a new Optional
Input called ReturnPDFTailOnly of type boolean which if set would change
the behavior such that instead of returning the above
DocumentWithSignature element, the server would return the "tail" in the
SignatureObject element inside a Base64Signature subelement.

Thanks,

- Uri

Uri Resnitzky
Chief Scientist
ARX
http://www.arx.com


> -----Original Message-----
> From: Pope, Nick [mailto:Nick.Pope@thales-esecurity.com] 
> Sent: Wednesday, 04 July, 2007 14:06
> To: 'Pim van der Eijk'; dss-comment@lists.oasis-open.org; 
> dss-dev@lists.oasis-open.org
> Subject: RE: [dss-comment] DSS for PDF
> 
> Pim,
> 
> I believe the existing DSS protocol can support PDF signing, 
> although there is no specific DSS profile for this use case.  
> As you are probably aware there is a new follow on TC 
> concerned with DSS (called DSS-X) which will be working on a 
> number of new DSS profiles.  I know that PDF signing is of 
> interest to a number of founding members of the DSS-X so this 
> could be a potential activity for this new group.  If you 
> have specific proposals in this area you would like to submit 
> to the new DSS-X TC they would probably be received with 
> great interest.
> 
> Nick
> 
> > -----Original Message-----
> > From: Pim van der Eijk [mailto:lists@sonnenglanz.net]
> > Sent: 04 July 2007 11:55
> > To: dss-comment@lists.oasis-open.org; dss-dev@lists.oasis-open.org
> > Subject: [dss-comment] DSS for PDF
> > 
> > 
> > Hello,
> > 
> > In a project we are looking at applying DSS to sealing (and in the 
> > future,
> > signing) of PDF documents.
> > 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?
> > 
> > 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.
> > Comments welcome.
> > 
> > Pim