Hello Denis,
Some remarks below. I'm
sorry for the late response.
Thanks,
Ezer
-----Original Message-----
From: Denis Pinkas
[mailto:denis.pinkas@bull.net]
Sent: Monday, September
21, 2009 2:58 PM
To: Ezer Farhi
Cc: Juan Carlos Cruellas; dss-x
Subject: RE: Late comments on
OASIS DSS-X Profile on visible signatures CommitteeDraft
I am fine after the surgery,working
from home.
See my responses embedded in the
text.
Date :
2009-09-14, 18:54:33
Sujet : RE: Late
comments on OASIS DSS-X Profile on visible signatures CommitteeDraft
Hello
Denis,
If by
any chance you did not receive this email, it is right ahead.
Appreciate
any remark.
Thanks,
Ezer
-----Original Message-----
From: Ezer Farhi
Sent: Sunday, August
02, 2009 10:07 AM
To: 'Denis Pinkas'
Cc: Juan Carlos Cruellas; stefan;
dss-x@lists.oasis-open.org
Subject: FW: Late comments on
OASIS DSS-X Profile on visible signatures Committee Draft
Hello
Denis,
I'm very
sorry for the late response.
Please
see my comments below.
Thank
you very much for the detailed review and the detailed remarks.
Ezer
-----Original Message-----
From: Denis Pinkas
[mailto:denis.pinkas@bull.net]
Sent: Friday, July
24, 2009 10:38 AM
To: Juan Carlos Cruellas; stefan;
Ezer Farhi
Subject: Late comments on OASIS
DSS-X Profile on visible signatures Committee Draft
Importance: High
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.
EZER - The Visible
Signature profile performs is aimed to embed visible information upon a given
content such as PDF document, MS Office documents, etc in addition to the
actual digital signature operation that is handled through the DSS core
protocol.
In the case that the
client wishes to use an advanced signature (CAdES, XAdES), the client will need
to use two profiles in addition to the core:
The Advanced signature
profile, which is specified at http://docs.oasis-open.org/dss/v1.0/oasis-dss-profiles-AdES-spec-v1.0-os.html
and the visible signature profile.
As an example, you can
incorporate a visible signature to a PDF document in addition to an advanced
digital signature embedded in the PDF document (at the level of conformance
that is applicable today by PDF).
The current ETSI
standardization process that is aimed for enabling advanced signatures in PDF
files will probably incorporated into a new version of the advanced signature
profile (which also in combination with the visible signature profile, enable
supporting visible advanced signature in PDF files).
Whatever the protocol may be, the end result should be incorporated either into
the signed document itself
or in the electronic signature.
EZER - the protocol tries
to be aligned with existing document implementations such as PDF or Office
2007. And indded it is incorporated into the signed document itself.
[Denis] We are in
disagreement here.
As I said: "... should be incorporated either into the
signed document itself or in the
electronic signature itself.
[Denis] I see
difficulties to incorporate the visible signature inside the document. It means that the visible signature API must be
applied before the document is signed. It modifies the document to
be signed and the "What you see is what you sign" property
is no more applicable. Or should the visible signature become part of
"What you see is what you sign" property ? Does it mean that the end
user should be able to "see" the document with the visible
signature field before the document is signed ?
EZER - I see it
differently and it is also implemented that way in existing product that
implement visible signature such as
Adobe-PDF and MS Office.
As part of the digital signature ceremony both visible and non visible content
will be incorporated into the document (BTW, many of the existing documents
implementation contained non visible data this is also signed as part of the
digital signature operation - the "What you see is what you sign"
claim...).
The visible signature profile goes along with this direction (which I believe
is a correct one) and performs the both adding of visible content that is
related to the digital signature act and performs a digital signature operation
within a single transaction.
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.
EZER - The protocol
mainly addresses documents types and not native XML, that inherently addresses
visibility of information.
[Denis] You do not answer to my
question. Do you believe that the document does not support visible
signature
for detached signatures and embedding signatures ?
EZER - Denis, Can you refer me to a standard, a
document format or a data format that enables encoding/embedding a
digital signature along with a matching visible content or pointing to a
detached signature?
Currently the only existing implementations/standards that I'm aware
of are the PDF standard and the Microsoft OOXML standard (along with some
additional existing implementation).
The aim of the profile is not to create a standard for encoding visible
signature
content.
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.
EZER - It is possible to
include textual information in a variety of languages by indicating fonts for
every textual element. Text can be either supplied by the client or
incorporated by the server (for example, a common name can be extracted by the
server from the user's certificate).
[Denis] This is not what
I was thinking.The idea is to include only OIDs into the visible signature
that can be locally translated into any language.
As an example an OID for the "claimed signature time", that will be
translated into "date présumée de la signature" if the French
language is being used by the viewer of the visible signature field.
EZER -
Your remark is mainly relevant to "static" information such as the
above example, and the protocol does address
this issue by enabling the client specify the ID of the item to be incorporated
to the visible content (in this case the identity
Of the label is
<xs:enumeration value="SignatureTime" />).
It is up to the server implementation and the type of relevant document to use
to either incorporate a real text or an OID.
However, in the case of a dynamic type of data (such as the signature time
itself or a reason for signing), it is a bigger problem to implement a multi
lingual solution.
Maybe you actually mean that you expect the protocol that in any case that a string
is passed from the client, the client will have the possibility to pass the
string in several languages (for example, a reason in English and French), so
that the server
and document implementation will be able to incorporate several strings into the
documents?
Usually the visible
content is signed by existing implementation that forbids any modifications to
the visible content, therefore it will not be possible to translate visible
content from one language to another.
So basically, I think
that supporting different languages based on universal strings is possible.
[Denis] See my comment above. I got the impression that you want to be
backwards compatible with existing implementations.
However, it does not mean that existing implementations are "good".
:-)
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.
EZER - This
"visibility level" is not embedded in the protocol since currently no
existing implementation (PDF, MS Office) enables that. The protocol does enable
you to control (in the time of the digital signature act) which information
should be incorporated to the visible signature.
It is possible to incorporate
such a parameter to the protocol, which may be used by future
applications/implementations.
[Denis].
Once again, I got the feeling that you want only to support existing
implementations whether teh approach they have taken is "good" or
"bad".
EZER - Right. However, the protocol is not
limited only for these implementations, so it is possible to incorporate
additional
functionality. However, it is important to separate between the protocol and
the implementation of the server along with the
Certain document standard.
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.
EZER - Please see
previous remarks about languages. Since most existing and future
implementations sign the visible content, I think that the protocol should
handle actual textual content and not templates.
It is possible to bind a "display level" for every displayable
field (as described above).
[Denis] Since all people do not understand English, I do not see how the
approach you are taking may work.
Incorporating
all languages would not be acceptable either.
EZER - I do not see any problem of using any language. The issue
that you raised is how a certain visible signature can
address
several languages in parallel. As said, there is no existing implementation
that enables you to visualize different
visible
signature depending on the current language the user is using.
You may require
that the protocol will enable future implementations to support such
functionality by supplying different
text for the
same item as part of the ItemValueStringType
type.
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.
EZER - yes.
[Denis]
Do you really agree: "into the signed document itself or into the electronic signature"
?
EZER - I think it will
be more accurate to say that the visible signature is incorporated into the
document. This is dependant on the document format/standard.
If incorporated into the electronic
signature, the basic question is where to place that information ?
EZER - The protocol
address that by either supplying a position or an existing signature field,
which is a placeholder for the visible signature.
Should it be as signed attributes (or signed properties) or as unsigned
attributes (or signed properties) ?
EZER - If you referring
to whether the visible content is signed. It is very much depended on the
document implementation. The protocol addresses both implementation types (that
sign the visible content and do not sign the visible content). One of the
implementations that do not sign the visible content actually incorporate to
the visible content the actual digital signature in bar-code representation or
other type of representation. In this case the visible signature content cannot
be signed.
[Denis] I am confused here.You mean that there are two flavors. One that is
signed, the other one that is unsigned.
The unsigned one can be
chahged by anybody and so is not trustable. Do you plan to add a visible
information
saying whether it is signed or
unsigned ? Anyway, I do not see the value of an unsigned visible
signature: it can fool a verifier.
EZER - There are existing implementations that include
a certain particle of the visible information that is a direct output
of the digital signature
itself (for example, a bar-code image that is a representation of the digital
signature itself).
This certain
element cannot be signed.
I will
change the profile description to be more precise in this case, so that only
this type of element can be not signed.
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.
EZER - This issue will be
covered as well by the implementation and not the protocol. In most existing
applications today (PDF, Office), the visible signature is incorporated into
the document's content and not to the digital signature content (for example,
signed attributes).
[Denis] If so, then the visible signature is signed
EZER - Yes, in most
implementation. Please read my previous remark.
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.
EZER - This issue should
be addressed by the documents standards. The specification (which is also true
for other aspects of the DSS specification) addresses the protocol and not the
actual implementation. As I know there is an ETSI committee that will address
aspects of incorporating visible content into the PDF specification that may
address the issue that you raise.
[Denis] I do no beleive that is possible to define a protocol without thinking
at the same time what will/may be done
by implemtations. The actions should be done in parallel.
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.
EZER - As said above,
this direction should be handled by the document standards themselves. The
protocol is not aimed only for documents types that use advanced signatures,
but if the documents types do support CAdES/XAdES, the DSS server
implementation may use signed properties to include visible content.
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.
EZER - As said above, it
is up to the document implementation. Today, both PDF and Office sign this
content as well as any other content in the visible signature.
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.
EZER - In most of the
cases the claim is correct and most existing implementation assure that by
signing the visible content and make sure it is aligned with values that are
not part of the visible content. As I said, above, the protocol also addresses
implementation that produces a digital signature image. In this case this image
is not signed and content data.
[Denis] This does not work. The verification MUST always be done by the
signature verification software.
The signature
creation software MAY also do it, but the verification software cannot know
whether that software was "good" or "bad"
EZER - I agree with you.
I will be more specific about the digital signature image, which is the only
possible visible item that may be unsigned since it is a direct representation
of the digital signature itself.
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.
EZER - Please see the comments above. We can
highly consider incorporation a visible display level attribute for every item
in the visible content. The application can use this attribute to define the
level of visibility.
[Denis] Adding the notion of a visible display level would only solve one of my
concerns.
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".
EZER - The visible
signature profile mainly addresses the digital signature operation and has
limited functionality in the validation processing.
[Denis] I have
difficulties to understand what you mean here. I believe that what is important
is what a verifier will see. Any field that is displayed should be
marked verified or claimed. Let us take the example of a scanned manual
signature. If can simply be part of the document (or of the signature) and is
whatever manual signature has been added by the signer (so it is unverified).
Another possibility is to include the jpg of the scanned signature and verify
that it matches a hash included into the signer's certificate. In such a
case, if the digital signature has been verified, then the scanned manual
signature has been verified.
EZER - I refer to a scanning image of the
digital signature itself (not a scanning of the signer's handwritten
signature). For example, this visible string 12389413824388123468ABABABAB728342732379.
This item can be signed by the same digital signature.
Currently, the only
processing that is included is to mark the verification status of the digital
signature, but this act by itself is mainly aimed for documents types that will
not violate the digital signature.
[Denis] I don't
understand what you mean here.
EZER - The DSS core
performs that actual digital signature verification act. The profile is
currently doing some limited functionality, which is to add some visible
marking to the document that specifies whether the digital signature is valid.
We have some debates on this issue, since adding this marks will invalidate the
digital signature in existing implementations.
The proposal you raise is
interesting, but I need to consult with the DSS committee to whether this
approach should be defined and described in the visible signature profile.
Are you familiar with
such an implementation? What types of documents are used?
[Denis] I don't
understand your questions.
EZER - You described
functionality in the above paragraph ("when used by a verifier in a verifying protocol, the
service should...."). I asked whether you are
familiar with any implementation or standard that describes or implement it.
Denis
----------
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
-------------------------------------------------------------------