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:] 

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.

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.

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

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.

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.

 

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

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.

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.

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

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.

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.

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. 

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.

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.

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

---------- 

De
: esi : etsi tc esi
(electronic signatures and infrastructures) 

À : ESI 

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

-------------------------------------------------------------------