[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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-----
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
Denis
=======================================================
Late comments on version 1.0 of the
"Visible Signature Profile".
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).
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.
EZER – The protocol mainly addresses documents types and not native XML, that inherently addresses visibility of information.
EZER – It is possible to include textual information in a variety of languages by indicating fonts for every textual element. Text can be either supplied by the client or incorporated by the server (for example, a common name can be extracted by the server from the user’s certificate). Usually the visible content is signed by existing implementation that forbids any modifications to the visible content, therefore it will not be possible to translate visible content from one language to another. So basically, I think that supporting different languages based on universal strings is possible.
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.
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.
EZER – yes.
EZER – The protocol address that by either supplying a position or an existing signature field, which is a placeholder for the visible signature.
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.
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).
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.
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.
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.
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.
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.
EZER – The visible signature profile mainly addresses the digital signature operation and has limited functionality in the validation processing. Currently, the only processing that is included is to mark the verification status of the digital signature, but this act by itself is mainly aimed for documents types that will not violate the digital signature. The proposal you raise is interesting, but I need to consult with the DSS committee to whether this approach should be defined and described in the visible signature profile. Are you familiar with such an implementation? What types of documents are used?
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]