[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss-x] FW: Late comments on OASIS DSS-X Profile on visible signatures Committee Draft
Hello Ezer,
Since I cannot attend tomorrow's meeting due to travel, this
email is to indicate that I agree with your replies.
Kind regards,
Pim
-----Original Message-----
From: Ezer Farhi [mailto:Ezer@arx.com]
Sent: 15 November 2009 08:38
To: Juan Carlos Cruellas
Cc: dss-x
Subject: RE: [dss-x] FW: Late comments on OASIS DSS-X
Profile on visible signatures Committee Draft
Hello Juan Carlos,
The intention was to get the members' opinion on this
matter.
Thanks,
Ezer
-----Original Message-----
From: Juan Carlos Cruellas [mailto:cruellas@ac.upc.edu]
Sent: Sunday, November 15, 2009 1:45 AM
To: Ezer Farhi
Cc: dss-x
Subject: Re: [dss-x] FW: Late comments on OASIS DSS-X
Profile on visible signatures Committee Draft
Hi Ezer,
Sorry for my late reply...
I agree with your answers.
May I suggest that the members of the committee take a look
to this so that we may resolve the issue at the next call?
Regards
Juan Carlos
Ezer Farhi escribi�:
> Hi,
>
>
>
> Follows a list of requirements raised by Denis Pinkas.
>
> Every requirement has a matching response of the DSS-X
committee.
> Please pay attention to the third item, which I did not
mention in the
> last committee call. I think the address of this item
might by the
> STF-364 or other ETSI's advanced signature committees.
>
> Please raise any comment you have.
>
> Thanks,
>
> Ezer
>
>
>
> "
>
>
>
> 1. Request: The Visible Signature profile should not be
bounded by
> any existing implementation of visible signature. A
standard body
> should define the standard according to its
judgment.
>
> Answer: The visible signature profile as well as any
standard
> defined by the DSS-X committee defines the protocol
for sending
> request/response to a signature/verification
service. The scope of
> the committee does not handle document formats.
> The profile supports several exiting implementations
of visible
> signatures in existing documents types.
> There is no fundamental reason why any future
document
> implementation that supports visible signatures,
will not be
> supported by the visible signature profile. It may
that some
> adjustments will need to be made to the Visible
Signature profile
> to support such future document types.
>
> 2. Request: Visible information will be encoded as a
Meta data into
> the document. Upon verify requests certain level of
information
> will be displayed in the visible signature. Also,
depending on
> lingual environment or other context textual
information will be
> displayed according to the context.
>
> Answer: Such document implementation or standard
does not exist
> today, and it is not in the scope of the committee
to define such
> standard or document type.
> As specified in item number 1, when such a standard
or document
> type exists, the committee thinks that the visible
signature
> profile will not require extensive modifications to
support such
> document standard.
>
> 3. Request: In addition to item 2, a detached Visible
Signature that
> goes along with the digital signature itself and
that does not
> care which the underlying document type is is a
better approach
> than embedding a visible signature into the
document. This way you
> do not have to define a different standard of
embedding a visible
> signature into different document types.
> One of the solutions might be to extend the advanced
signature
> standard to support visible information.
>
> Answer: Again, this issue is not in the scope of the
committee. If
> indeed the advanced signature standard to any other
"detached
> signature" standard will include visible content,
the visible
> signature protocol will be adjusted to support this
standard.
> The request should probably be directed to other
standardization
> bodies such as ETSI's committees that handles the
standardization
> of advanced electronic signatures.
>
> 4. Request: All visible items must be included in the
digital
> signature
>
> Answer: The committee agrees with this concept
except for a
> certain element type, which is a visible
representation of the
> digital signature itself, which might be represented
as a barcode
> image or any other encoded image.
> This certain image cannot be protected by the
document's digital
> signature.
> There are some existing implementations that involve
external
> scanners that will be able to decode the barcode
image and perform
> signature verification.
> The committee found no reason not to support such
implementations
> that use this exception.
>
> "
>
> <http://www.arx.com/>
>
>
>
> -----Original Message-----
> *From:* Denis Pinkas [mailto:denis.pinkas@bull.net]
> *Sent:* Wednesday, November 04, 2009 6:56 PM
> *To:* Ezer Farhi
> *Cc:* Juan Carlos Cruellas; dss-x
> *Subject:* RE: Late comments on OASIS DSS-X Profile on
visible
> signatures Committee Draft
>
>
>
> Ezer,
>
>
>
> It seems that we have rather different approaches.
>
>
>
> You make the assumption that visible signatures are in the
signed
> document. I don't make the same assumption.
>
>
>
> Anyway, if it is in the signed document, how is it
possible to make
> the difference between a "real visible signature field"
> and fake one that is burried in the text ? Does it mean
that such a
> field is interpreted/presented in a different window and
does not
> appear in the displayed text, video or recording ?
>
>
>
> Another problem is that, IMO, there should be different
ways to
> display a visible signature field (remember my proposal
with different
> levels of view). This is not possible if it is within the
document.
>
>
>
> You are talking of "existing product that implement
visible signatures"
>
> You are making the assumption that the approach from Adobe
and
> Microsoft is correct.
>
> These two companies have build their products originally
by not
> supporting AdES formats.
> So their approach is not necessarilly correct.
>
>
>
> We do not speak the same language. I asked a question and
instead of
> responding to it, your raise a different question.
>
>
>
> My question was: "Do you believe that the document does
not support
> visible signature for detached signatures and embedding
signatures ? "
>
>
>
> Your answer to my question was another question: 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?
>
>
>
> I presume that your opinion is the following: since
visible signatures
> are embedded in the document they can be supported with
any kind of
> signatures, e.g. detached signatures or embedding
signatures.
>
>
>
> I believe that it is possible to define extensions to the
current
> formats of AdES to incorportae visible signatures.
>
>
>
> The implications, which are _very important_, are the
following:
>
>
>
> a) with my approach, it is possible to present the visible
signature
> without "opening" the document.
> this means that they can be supported with any kind of
document, e.g.
> a tiff document or some recording.
>
>
>
> b) with your approach, there is the need to open the
document to be
> able to present the visual signature.
>
> The way to present the visual signature would be
restricted to the two
> formats you consider: PDF/A and OOXML.
>
> If more formats need to be supported, more satndardization
work wil be
> needed. I believe it will be very difficult to support
visible
> signatures on video or on recordings.
>
>
>
> Then you said:
>
> the potocol 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.
>
>
>
> The probem is when interpreting the field. An OID can
easily be
> translated in any foreign language exactly in the same
way.
>
> If it is a text, this will not necessarilly be the case. I
do not want
> to include in the visible signature field all the
languages that exist
> on the Earth.
>
>
>
> But the important point is the following: I claim that a
visible
> signature presented in China will be different from a
visible
> signature presented in the UK. It does NOT follow the
property "what
> you see is what you sign".
>
>
>
> Later on you say:
>
> As said, there is no existing implementation
that enables
> you to visualize different
> visible signature depending on the current
language the
> user is using.
>
>
>
> I don't care what the existing implementations are doing.
> Standardization groups (like ETSI or OASIS) try to lead
the way, they
> do not necessarilly follow what has been done outside a
> standardization group.
>
>
>
> Then you say:
>
>
>
> 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
>
>
>
> I do'nt want to require this. See my explanations above.
>
>
>
> Finally, when you said:
>
>
>
> 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.
>
>
>
> I was completely lost. What is the advantage of presenting
a string
> like
> 12389413824388123468ABABABAB728342732379 ?
>
> How can it be useful ? Will a user notice the difference
with
> 12389413824388123468ABABABABA28342732379 (where I changed
one digit) ?
>
>
>
> Denis
>
>
>
> ----- Message re�u -----
>
> *De :* Ezer Farhi <mailto%20:Ezer@arx.com>
>
> *� :* denis.pinkas <mailto%20:denis.pinkas@bull.net>
>
> *Date :* 2009-10-15, 12:52:15
>
> *Sujet :* RE: Late comments on OASIS DSS-X Profile on
visible
> signaturesCommitteeDraft
>
>
>
> 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
>
>
>
> Ezer,
>
>
>
> I am fine after the surgery,working from home.
>
>
>
> See my responses embedded in the text.
>
>
>
> Denis
>
> ----- Message re�u -----
>
> *De :* Ezer Farhi <mailto%20:Ezer@arx.com>
>
> *� :* Denis Pinkas
<mailto%20:denis.pinkas@bull.net>
>
> *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
>
>
> ----------
>
> *De :* esi : etsi tc esi (electronic
signatures and
> infrastructures) <mailto%20:ESI@LIST.ETSI.ORG>
>
> *� :* ESI <mailto%20: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/cd0
1/oasis-ds
> sx-1.0-profiles-visualsig-cd1.doc
>
> PDF:
>
>
http://docs.oasis-open.org/dss-x/profiles/visualsig/v1.0/cd0
1/oasis-ds
> sx-1.0-profiles-visualsig-cd1.pdf
>
> HTML:
>
>
http://docs.oasis-open.org/dss-x/profiles/visualsig/v1.0/cd0
1/oasis-ds
> sx-1.0-profiles-visualsig-cd1.html
>
> Schema:
>
>
http://docs.oasis-open.org/dss-x/profiles/visualsig/v1.0/cd0
1/oasis-ds
> s-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=d
ss-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_a
bbrev=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/.
>
<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
>
>
------------------------------------------------------------
-------
>
------------------------------------------------------------
---------
To unsubscribe from this mail list, you must leave the OASIS
TC that generates this mail. Follow this link to all your
TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_work
groups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]