RE: [dss-x] DSS-X Visible Signatures Profile

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

Konrad Lanz wrote:
> Uri Resnitzky wrote:
> > [...] Perhaps we need two different profiles to address 
> > these two approaches.
> 
> I strongly disagree, for a couple of reasons ...
> 
> * There is only one visual signatures profile on our charter.

The charter specifically allows the TC to expand the list of 
profiles if we see the need for it.

> * Visual XML Signatures are for us of paramount importance 
>   to a DSS-X Visual Signature Profile.
> * Plain Text Signatures that are easily verifiable from a 
>   paper printout (e.g. of a PDF) are important in the DSS-X 
>   Visual Signature Profile.

I do not disagree. However to me these kinds of signatures 
are fundamentally different than visual signature fields or 
blocks as specified by existing document standards. So it is 
not clear that they would all fit in the same profile. 
These points raise the need to start creating a requirements 
document for the visual signatures profile. Once we have a 
clear understanding and agreement on the requirements, we can 
map them to profiles.

> * Binary PDF signatures should be supported as well

Of course I agree. However, I'm not sure that what you mean 
by "Binary PDF signatures" is the same as what I mean...

> The approach for signing PDFs in their binary form in Austria is 
> specified here (just in case you understand German) [...]
> I'll have to check if I can get a translation for this.

Please do, since the DSS-X TC official language is English, 
all material submitted or contributed must be in that 
language and using automated translation tools leads to a 
poor level of understanding, and thus limits the ability to 
collaborate and reach an agreement.

> > The result would be a document that can be opened, viewed *and
> > verified* by any standard application for that document type (for 
> > example Adobe Reader).
> 
> Well I'd strongly doubt that many standard PDF application would 
> support PDF signatures. Well Adobe does ... and some others. 
> Btw, have you tried there to verify a document after the 
> certificate was revoked or expired?

While I believe the support in Acrobat for "proper" PKI 
processing on the client is very good, it is not my place to 
make that argument. My point is that the PDF spec already 
defines a document format which supports "proper" signatures 
including a visual representation. I propose to create a DSS 
profile that implements sign/verify of this file type, 
including handling of the visual part. The resulting signed 
documents should be verifiable by any application which 
adheres to the PDF standard on a client or server. You may be 
surprised by the amount of already existing applications that 
deal with PDF signatures, including open source implementations.

> Well complete certificate checks including proper certificate 
> revocation checking is a nontrivial task and exactly one of the 
> reasons why DSS moves such a burden from a client to a server.

I agree, but that is not a reason not to leverage or enable 
using existing applications. Also note that not all such 
applications are client applications.

> Hence I'd advocate for making such a scenario not a general 
> use-case for the DSS-X Visual Signature Profile.

Sorry - I did not understand which scenario / use-case you 
are advocating against.

> > This is because the PDF standard defines that a signature 
> > must cover all the bytes in the document in the hash calculation, 
> > and that must also include the visual appearance. Therefore the 
> > appearance cannot contain the signature value itself.
> 
> Well, fortunately there are byteranges for PDFs [...] 
> #### 
> The variable ranges between the byte of rank are called holes. 
> These are substituted at the signing time by place holders, after 
> successful signing the appropriate values are inserted, [...] 
> ####

From what I can understand of the spec you are quoting, it 
seems to me that its use of the PDF ByteRange attribute and 
holes to store parts of the visual appearance of the 
signature is not consistent with the PDF spec, resulting in 
signed files which cannot be verified by standard applications.

> > I am working on a draft document for a "visual document 
> > signatures" profile of DSS along the lines of my approach and 
> > hope to post it to the list before the next TC meeting.
> 
> Well, that is very kind of you, and I'd kindly like to ask you to 
> take visual XML Signatures (that should in the spirit of the dss 
> core be the default) and also Plain Text Signatures just as well 
> as binary PDF signatures into account.

My document should be looked at just as a proposal and a 
contribution from a single member. Naturally the TC will 
decide how to proceed/expand/modify it. It would be very 
difficult for me to incorporate your approach into it at this 
stage since I'm not even sure I fully understand it.

This discussion has so far centered around PDF, but I do not 
think we should limit the visual document signatures profile 
to that format alone. There are other relevant formats which 
define signatures with a visual component. One of them is the 
XML based OOXML used in the Microsoft Office 2007 signature 
line feature. Another potential format to consider is the XML 
based OASIS ODF. The current ODF 1.2 draft includes support 
for document signatures (alas without a visual component so 
far). Also, while the visual aspect is important, all the 
above mentioned file formats also support 'invisible' 
signatures, and I think the profile should also cover this 
simpler case.

On a more philosophical level, I think the main difference 
between our approaches is our different look at the market 
and problem domain. My approach tries to adopt and rely on 
existing document format standards which have already defined 
how a signature should be represented. I do not believe it is 
our place here to specify file formats, and I believe that if 
we try to, we will fail (in the sense that no one will use 
it). There are other committees and standards bodies that 
deal with file format issues. [FYI - personally I'm trying to 
make a difference in the way ODF deals with signatures by 
participating in the OASIS ODF TC]. The reason behind this 
approach is that once the popular productivity applications 
include signature functionality, the market will not tolerate 
a competing signature format that must be verified only using 
a specialized software/client/server. There may be different 
views about the completeness and robustness of the way those 
existing file / document format specifications define 
signature support. However I am proposing that such 
discussions be directed at the proper venues where those file 
formats are defined, while our job here is to define the 
protocol used to request a server to sign/verify those files 
in the already specified format.

To conclude I would like to say I am relived that finally 
after more than 6 months of forced break we are finally 
starting to discuss and work on real issues which is the 
whole purpose of the TC!

- Uri