← Prev in month
← Prev in thread
Comments on the Visible Signatures profile
Hello Nick, We plan to finalize the first committee draft in two weeks and start the process of defining the profile as a committee specification. You said a few months ago that the STF-364 may have comments by the end of September ’09, so if there will be comments to the specification in the incoming two weeks, the comments may be incorporated to the firs version of the committee specification. Thanks, Ezer -----Original Message----- From: Pope, Nick [mailto:] Sent: Thursday, November 12, 2009 11:36 AM To: Ezer Farhi; dss-x Subject: RE: [dss-x] FW: Late comments on OASIS DSS-X Profile on visible signatures Committee Draft Thanks Ezer, I am forwarding this to ETSI for their information as the issues raised in this document is very much of relevance to the work on visible signature in the ETSI PAdES specialist task force. Nick -----Original Message----- From: Ezer Farhi [mailto:] Sent: 12 November 2009 08:48 To: dss-x Subject: [dss-x] FW: Late comments on OASIS DSS-X Profile on visible signatures Committee Draft 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. " -----Original Message----- From: Denis Pinkas [mailto:] 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 À : denis.pinkas 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:] 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 À : Denis Pinkas 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; 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:] 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) À : 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 ------------------------------------------------------------------- Consider the environment before printing this mail. "Thales e-Security Limited is incorporated in England and Wales with company registration number 2518805. Its registered office is located at 2 Dashwood Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15 2NX. The information contained in this e-mail is confidential. It may also be privileged. It is only intended for the stated addressee(s) and access to it by any other person is unauthorised. If you are not an addressee or the intended addressee, you must not disclose, copy, circulate or in any other way use or rely on the information contained in this e-mail. Such unauthorised use may be unlawful. If you have received this e-mail in error please delete it (and all copies) from your system, please also inform us immediately on +44 (0)1844 201800 or email . Commercial matters detailed or referred to in this e-mail are subject to a written contract signed for and on behalf of Thales e-Security Limited".
← Prev in month
← Prev in thread