RE: [dss-comment] DSS for PDF

["Pope, Nick" <Nick.Pope@thales-esecurity.com>]

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
> 
> 
> 
> 
> 
> 
> This publicly archived list offers a means to provide input to the
> OASIS Digital Signature Services (DSS) TC.
> 
> In order to verify user consent to the Feedback License terms and
> to minimize spam in the list archive, subscription is required
> before posting.
> 
> Subscribe: dss-comment-subscribe@lists.oasis-open.org
> Unsubscribe: dss-comment-unsubscribe@lists.oasis-open.org
> List help: dss-comment-help@lists.oasis-open.org
> List archive: http://lists.oasis-open.org/archives/dss-comment/
> Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> Committee: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=dss
Consider the environment before printing this mail.
"Thales e-Security Limited is incorporated in England and Wales with company
registration number 2518805. Its registered office is located at 2 Dashwood
Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15
2NX.
The information contained in this e-mail is confidential. It may also be
privileged. It is only intended for the stated addressee(s) and access to it
by any other person is unauthorised. If you are not an addressee or the
intended addressee, you must not disclose, copy, circulate or in any other
way use or rely on the information contained in this e-mail. Such
unauthorised use may be unlawful. If you have received this e-mail in error
please delete it (and all copies) from your system, please also inform us
immediately on +44 (0)1844 201800 or email postmaster@thales-esecurity.com.
Commercial matters detailed or referred to in this e-mail are subject to a
written contract signed for and on behalf of Thales e-Security Limited".