dss-x — archive

[Andreas Kuehne]

Hi Ezer ! > - a visual representation ( within the doument ) of a signature, > embedded or detached. Usually a trust-assoiated icon like a seal or > such. Maybe clickable to see some more informations ... > > EF - The visual signature should contain also following information: > signer's name, Signature time, Reason for signing, image of handwritten > signature, and all other information as presented in Konrad's document > and others. I guess I didn't made my standpoint clear enough : Visual representation of a signature ( e.g. a bitmap of a seal ) without any cryptographic stuff should _not_ be part of a DSS-X profile. Dtmo that's just design of a document ... but Konrad's document is talking about the second topic, a visible signature ... > - a visible signature, like a two-dimensional bar code or a > machine-readable hex value or such. > > EF - Why this class is separated from the above? The way I see this > type > of information may be incompatible with cases (such as PDF documents or > others) that the digital signature of the document includes the visual > signature's content. I would like to distinct he pretty printing stuff mentioned above and the crypto content made visible and hopefully computer processable from a printed instance. Konrad sent his example with hex values, another common one is the 2D bar code ( btw. successfully used in german train tickets ). This visible signature can be verified somehow, in contrast to the visual representation mentioned above. > - all the stuff around signatures within the PDF file and the related > issues. Visible or not. > > EF - I think again, that PDF signatures or other similar existing > signatures (such as MS Office 2007 signatures) should fit into the > first > classification. We should discuss whether to include non-visual > signature fields in documents. Don't agree ! In my view e.g. a PDF is a container format embedding signature data like an XMLDSig can be embedded into an XML document. There is no need to have any idea about an applied signature when you printout such a PDF. As PDF is intended for showing something it's likely that the document has a visible hint that there is a signature applied, but there is no need for it ! So why should a PDF with a signature be created using a 'visible signature' profile when there is no visible bit of this signature around ? Should we include an 'invisible' flag into a 'visible signature' profile ? Sounds strange, doesn't it ? > EF - But Visual signatures are part of the PDF offering. I do not > understand why do you want to separate between a Visual Signature that > is displayed in a PDF file or in another file format? See above : Because I doesn't need to be visible ! > EF - I think there are two issues that I would like to say here > - It is true that the Digital Signature "Strength" in the "bytes" of > the > digital signature, but a Visual Display of some of the content that are > related to the act of digital signature are important for the > acceptance > of digital signatures by organizations. If eventually the visual > signature will only include a seal, there no much point for the Visual > Signatures profile. Agreed ! [...] > EF - If the issues of "Signature Fields" and Visual Signature structure > are introduced in the profile, we cannot avoid supplying the mechanisms > to create these fields, remove and enumerate fields in the given > document. I would like to avoid most of the PDF-specific functionality, but concentrate on signing itself : If there is a signature field within the given PDF document, we can do the crypto stuff on it. That's it ! We don't need to care about all the PDF layers, dictionaries, versions of forms ... We get along best if we proceed like in the real world : 'Show me the box where I can put my moniker' If you ask your boss to sign your vacation form, you don't ask him to paint half the form ! You'll have it filled out nicely and present it with a sweet 'just sign here ...'. That's the way I would image it for our signing server. 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