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