[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [Fwd: Late comments on OASIS DSS-X Profile on visible signaturesCommittee Draft]
Dear all,
we have received the following message below by Denis Pinkas, commenting
the visible signature profile, mentioning a previous message sent to me,
which by some reason I missed and I do not find in my mailbox. My
appologies.
Regards
Juan Carlos.
-------- Mensaje original --------
Asunto: Late comments on OASIS DSS-X Profile on visible signatures
Committee Draft
Fecha: Fri, 24 Jul 2009 09:37:36 +0200
De: Denis Pinkas<denis.pinkas@bull.net>
Responder a: denis.pinkas@bull.net
Para: Juan Carlos Cruellas<cruellas@ac.upc.edu>,
stefan<stefan@drees.name>, ezer<ezer@arx.com>
Referencias: <4A2FD803.8050200@ac.upc.edu>
I sent the comments below to Juan-Carlos, but I got no reply from him.
So I send them directly to the people that have their e-mail address on
the front page of the document.
BTW, the e-mail address from Juan-Carlos on teh front page is wrong: it
should end with "edu" rather than "ede".
Regards,
Denis
=======================================================
Juan Carlos and all,
Please find below late comments.
Juan-Carlos would you be able to post them to the DSS-X committee
since the link indicated in the mail does not work ?
Denis
=======================================================
*Late comments on version 1.0 of the "Visible Signature Profile".
*
_Source_: Denis Pinkas. Bull SAS.
After two readings of the document, I still have difficulties to understand
how the protocol may be usable in practice with signature formats like
CAdES and XAdES.
Whatever the protocol may be, the end result should be incorporated
either into the signed document itself
or in the electronic signature.
The abstract is only addressing the embedding of "visible signature
characteristics into documents".
Should the abstract be left unchanged, then this would mean that support
of visible signatures
would not be supported for detached signatures and embedding signatures.
Secondly, the internationalization of such visible signatures is not
addressed. Since electronic signatures
are intended to be made visible, an electronic signature generated in
one country using a given language
should be made visible in another country using a different language.
Each field should thus be made visible
using a local language. This document is silent about this aspect.
Thirdly, all the characteristics of a signature should not necessarily
be made visible at once. There should be
a concept of a first level of visibility, and for each first level, a
second level of details. At the very end,
all the visible characteristics (as requested by the signer) should be
made visible.
These observations let me to conclude that the signer should be able to
incorporate a /template /for the visible signature
which will describe the first level, secondary level, etc ... of the
visible signature in a language independent manner.
Applications able to handle these visible signatures fields should be
able to interpret the template in a local language.
As already stated above, whatever the protocol may be, the end result
should be incorporated either into
the signed document itself or in the electronic signature.
If incorporated into the electronic signature, the basic question is
where to place that information ?
Should it be as signed attributes (or signed properties) or as unsigned
attributes (or signed properties) ?
Whatever the response to the question is, this means that new signed
attributes (or signed properties)
or new unsigned attributes (or signed properties) should be defined
respectively for CAdES and XAdES.
If incorporated into the document, the incorporation depends upon the
type of document. However, this approach
would be restricted to some types of documents and would not be as
general as the other approach.
Even if the electronic signature is embedded into the document (as it is
the case for PDF signatures), it appears better
to add the information related to the visible signature into the
electronic signature itself (placed within the document),
rather than placing it somewhere else in the document.
As stated above, this means that new signed attributes (or signed
properties) or new unsigned attributes
(or signed properties) should be defined respectively for CAdES and XAdES.
In the draft document, there is intent to add information like a
"scanned image of the user's hand-written signature".
While this is an interesting idea, this information, if added should be
incorporated as a signed attribute and a signed property.
The visible signature fields should not contain any value. Values should
always be computed by a verification service
using the signed attributes (or signed properties) or/and the unsigned
attributes (or signed properties), so that
there is no conflict or ambiguity between values placed in the
electronic signature and asserted values that would be placed
in the visible signature fields.
To summarize the suggested approach:
when used by a signer in a signing protocol, the service should be able
to incorporate a "visible signature template"
into the electronic signature, preferably as a signed attribute or a
signed property. This template would support
different levels of visibility.
when used by a verifier in a verifying protocol, the service should be
able to interpret in a local language
the "visible signature template" placed into the electronic signature,
to the desired level of visibility and say
whether the information that has been retrieved has been verified or has
simply been copied and pasted
from the unverified signature. In the later case, if the signature is
not verified as being valid, this would allow
to know more about the electronic signature. This interpretation would
also be faster in practice.
Application displaying the visible signature fields should take care to
make the difference between ?verified values?
and ?unverified values?.
Denis
----------
*De :* esi : etsi tc esi (electronic signatures and infrastructures)
<mailto :ESI@LIST.ETSI.ORG>
*À :* ESI <mailto :ESI@LIST.ETSI.ORG>
*Date :* 2009-06-10, 17:57:55
*Sujet :* [ESI] Deadline for commenting OASIS DSS-X Profile on
visible signaturesCommittee Draft
Dear all,
Just these few lines to remark that the window for raising comments on
the the DSS-X Profile on Visible Signatures **ENDS THE 30TH OF JUNE
2009**.
The OASIS DSS-X Technical Committee strongly encourages feedback
from you for the sake of improving the interoperability and quality of
OASIS work. Please feel free to distribute this announcement within
your organization and to other appropriate mail lists.
This profile is aimed to incorporate visible information into documents
as part of the digital signature operation.
Incorporating a visible signature as part of a digital signature
operation is mandatory for the acceptance of digital signatures in many
business scenarios and applications.
Today, there is an existing support in several document types such as
PDF and MS Office 2007, as well as non standard support in other
documents types. Eventually, many document types will support the both
visible and non-visible digital signature embedded in the document.
The target of the Visible Signature profile is to provide a general
interface to a digital signature service for incorporating a visible
signature to any type of document.
To ease the collaboration of a visible signature into applications, the
profile defines several types of scenarios/policies. Two of the most
outstanding usages of implementing a digital signature into documents
are application workflow scenario and a document submission scenario.
The committee will appreciate any submitted component as part of
reviewing the profile specifications.
For more information of how to access the content of the profile
use the
following details:
The specification document and related files are available here:
Editable Source:
http://docs.oasis-open.org/dss-x/profiles/visualsig/v1.0/cd01/oasis-dssx-1.0-profiles-visualsig-cd1.doc
PDF:
http://docs.oasis-open.org/dss-x/profiles/visualsig/v1.0/cd01/oasis-dssx-1.0-profiles-visualsig-cd1.pdf
HTML:
http://docs.oasis-open.org/dss-x/profiles/visualsig/v1.0/cd01/oasis-dssx-1.0-profiles-visualsig-cd1.html
Schema:
http://docs.oasis-open.org/dss-x/profiles/visualsig/v1.0/cd01/oasis-dss-vissig-schema-v1.0-cd1.xsd
Non-normative information about the specification and the technical
committee may be found at the public home page of the TC at:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=dss-x.
Comments may be submitted to the TC by any person through the use
of the
OASIS TC Comment Facility which can be located via the button marked
"Send A Comment" at the top of that page, or directly at:
http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=dss-x.
Submitted comments (for this work as well as other works of that
TC) are
publicly archived and can be viewed at:
http://lists.oasis-open.org/archives/dss-x-comment/. All comments
submitted to OASIS are subject to the OASIS Feedback License, which
ensures that the feedback you provide carries the same obligations at
least as the obligations of the TC members.
OASIS and the DSS-X TC welcome your comments.
Best regards,
Juan Carlos
-------------------------------------------------------------------
Mail archive for ESI can be browsed at the following url:
http://list.etsi.org/ESI.html
-------------------------------------------------------------------
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]