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

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss-x message

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


Subject: RE: Fw: [dss-x] Visual Signatures profile


Hello Andreas,

Some more remarks below,

Regards,
Ezer

-----Original Message-----
From: Andreas Kuehne [mailto:kuehne@trustable.de]
Sent: Monday, March 31, 2008 1:33 PM
To: dss-x@lists.oasis-open.org
Subject: RE: Fw: [dss-x] Visual Signatures profile


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 ...

EF - The Visual Signature in Konrad's includes: Signer Name, Signature Time and other parameters that are not cryptographic stuff.  As I said above, some additional non cryptographic elements included in 
the Visual 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.

EF - OK. 

> - 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.

EF - There is a difference between an XMLDigSig-XML and PDF. XML is clearly data and PDF is an application that represents a document.
       I think we should discuss that.

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 Visual Signatures should be part of the DSS profile. If indeed they are, a signature field should be defined and we should take into account the available tools today that display Visual Signatures.
       The fact that PDF supports also non-visible signatures is an issue we can accept (and then the profile can be named signature fields profile) or not accept (there will be no way to generate a non-visual signature 
       through the DSS interface).

> 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.

EF - I am repeating myself, but there are important information that is part of the digital signature action that should be visually presented. For example, if I notary approve my signature on a contract I would like to visually see the time of the signature and the name of the notary.

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

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 



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