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