OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [dss-comment] DSS for PDF


 
Hello,

Thanks to all for your detailed comments, this helps a lot.
It is likely that people from this project will want to contribute when work
on this profile starts.

Pim

-----Original Message-----
From: Andreas Kuehne [mailto:kuehne@trustable.de] 
Sent: 04 July 2007 17:00
To: lists@sonnenglanz.net; dss-comment@lists.oasis-open.org;
dss-dev@lists.oasis-open.org
Subject: Re: [dss-comment] DSS for PDF

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]