OASIS Digital Signature Services eXtended (DSS-X) TC

 View Only

RE: [dss-x] DSS-X Visible Signatures Profile

  • 1.  RE: [dss-x] DSS-X Visible Signatures Profile

    Posted 07-27-2007 03:13
    Konrad Lanz wrote:
    > Uri Resnitzky wrote:
    > > [...] Perhaps we need two different profiles to address 
    > > these two approaches.
    > 
    > I strongly disagree, for a couple of reasons ...
    > 
    > * There is only one visual signatures profile on our charter.
    
    The charter specifically allows the TC to expand the list of 
    profiles if we see the need for it.
    
    > * Visual XML Signatures are for us of paramount importance 
    >   to a DSS-X Visual Signature Profile.
    > * Plain Text Signatures that are easily verifiable from a 
    >   paper printout (e.g. of a PDF) are important in the DSS-X 
    >   Visual Signature Profile.
    
    I do not disagree. However to me these kinds of signatures 
    are fundamentally different than visual signature fields or 
    blocks as specified by existing document standards. So it is 
    not clear that they would all fit in the same profile. 
    These points raise the need to start creating a requirements 
    document for the visual signatures profile. Once we have a 
    clear understanding and agreement on the requirements, we can 
    map them to profiles.
    
    > * Binary PDF signatures should be supported as well
    
    Of course I agree. However, I'm not sure that what you mean 
    by "Binary PDF signatures" is the same as what I mean...
    
    > The approach for signing PDFs in their binary form in Austria is 
    > specified here (just in case you understand German) [...]
    > I'll have to check if I can get a translation for this.
    
    Please do, since the DSS-X TC official language is English, 
    all material submitted or contributed must be in that 
    language and using automated translation tools leads to a 
    poor level of understanding, and thus limits the ability to 
    collaborate and reach an agreement.
    
    > > The result would be a document that can be opened, viewed *and
    > > verified* by any standard application for that document type (for 
    > > example Adobe Reader).
    > 
    > Well I'd strongly doubt that many standard PDF application would 
    > support PDF signatures. Well Adobe does ... and some others. 
    > Btw, have you tried there to verify a document after the 
    > certificate was revoked or expired?
    
    While I believe the support in Acrobat for "proper" PKI 
    processing on the client is very good, it is not my place to 
    make that argument. My point is that the PDF spec already 
    defines a document format which supports "proper" signatures 
    including a visual representation. I propose to create a DSS 
    profile that implements sign/verify of this file type, 
    including handling of the visual part. The resulting signed 
    documents should be verifiable by any application which 
    adheres to the PDF standard on a client or server. You may be 
    surprised by the amount of already existing applications that 
    deal with PDF signatures, including open source implementations.
    
    > Well complete certificate checks including proper certificate 
    > revocation checking is a nontrivial task and exactly one of the 
    > reasons why DSS moves such a burden from a client to a server.
    
    I agree, but that is not a reason not to leverage or enable 
    using existing applications. Also note that not all such 
    applications are client applications.
    
    > Hence I'd advocate for making such a scenario not a general 
    > use-case for the DSS-X Visual Signature Profile.
    
    Sorry - I did not understand which scenario / use-case you 
    are advocating against.
    
    > > This is because the PDF standard defines that a signature 
    > > must cover all the bytes in the document in the hash calculation, 
    > > and that must also include the visual appearance. Therefore the 
    > > appearance cannot contain the signature value itself.
    > 
    > Well, fortunately there are byteranges for PDFs [...] 
    > #### 
    > The variable ranges between the byte of rank are called holes. 
    > These are substituted at the signing time by place holders, after 
    > successful signing the appropriate values are inserted, [...] 
    > ####
    
    From what I can understand of the spec you are quoting, it 
    seems to me that its use of the PDF ByteRange attribute and 
    holes to store parts of the visual appearance of the 
    signature is not consistent with the PDF spec, resulting in 
    signed files which cannot be verified by standard applications.
    
    > > I am working on a draft document for a "visual document 
    > > signatures" profile of DSS along the lines of my approach and 
    > > hope to post it to the list before the next TC meeting.
    > 
    > Well, that is very kind of you, and I'd kindly like to ask you to 
    > take visual XML Signatures (that should in the spirit of the dss 
    > core be the default) and also Plain Text Signatures just as well 
    > as binary PDF signatures into account.
    
    My document should be looked at just as a proposal and a 
    contribution from a single member. Naturally the TC will 
    decide how to proceed/expand/modify it. It would be very 
    difficult for me to incorporate your approach into it at this 
    stage since I'm not even sure I fully understand it.
    
    This discussion has so far centered around PDF, but I do not 
    think we should limit the visual document signatures profile 
    to that format alone. There are other relevant formats which 
    define signatures with a visual component. One of them is the 
    XML based OOXML used in the Microsoft Office 2007 signature 
    line feature. Another potential format to consider is the XML 
    based OASIS ODF. The current ODF 1.2 draft includes support 
    for document signatures (alas without a visual component so 
    far). Also, while the visual aspect is important, all the 
    above mentioned file formats also support 'invisible' 
    signatures, and I think the profile should also cover this 
    simpler case.
    
    On a more philosophical level, I think the main difference 
    between our approaches is our different look at the market 
    and problem domain. My approach tries to adopt and rely on 
    existing document format standards which have already defined 
    how a signature should be represented. I do not believe it is 
    our place here to specify file formats, and I believe that if 
    we try to, we will fail (in the sense that no one will use 
    it). There are other committees and standards bodies that 
    deal with file format issues. [FYI - personally I'm trying to 
    make a difference in the way ODF deals with signatures by 
    participating in the OASIS ODF TC]. The reason behind this 
    approach is that once the popular productivity applications 
    include signature functionality, the market will not tolerate 
    a competing signature format that must be verified only using 
    a specialized software/client/server. There may be different 
    views about the completeness and robustness of the way those 
    existing file / document format specifications define 
    signature support. However I am proposing that such 
    discussions be directed at the proper venues where those file 
    formats are defined, while our job here is to define the 
    protocol used to request a server to sign/verify those files 
    in the already specified format.
    
    To conclude I would like to say I am relived that finally 
    after more than 6 months of forced break we are finally 
    starting to discuss and work on real issues which is the 
    whole purpose of the TC!
    
    - Uri