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: [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/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/.
>             <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]