ODF Toolkit
  1. ODF Toolkit
  2. ODFTOOLKIT-67

Add support for digital signature creation / verification

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: simple-odfdom-0.8
    • Fix Version/s: None
    • Component/s: java
    • Labels:
      None
    • Environment:
      Operating System: Windows
      Platform: PC

      Description

      Add support for digitally signing odf documents.
      Also support for parsing odf document to extract and verify digital signature groups and digital signatures.

        Activity

        Hide
        DaLi Liu added a comment -

        Verified status of this issue
        It seems this issue already be fixed -maybe can be closed;

        Show
        DaLi Liu added a comment - Verified status of this issue It seems this issue already be fixed -maybe can be closed;
        Hide
        rbonazzo added a comment -

        Created an attachment (id=408)
        resolve nullpointer exception

        Trying to sign an odf document the system crash due an nullpointer exception.
        The cause is that the file Configurations2/accelerator/current.xml sometime are not present.
        Change on the class org.odftoolkit.odfdom.pkg.signature.ODFURIDereferencer

        Show
        rbonazzo added a comment - Created an attachment (id=408) resolve nullpointer exception Trying to sign an odf document the system crash due an nullpointer exception. The cause is that the file Configurations2/accelerator/current.xml sometime are not present. Change on the class org.odftoolkit.odfdom.pkg.signature.ODFURIDereferencer
        Hide
        rbonazzo added a comment -

        yeah a patch the problem is how to made a patch?

        Show
        rbonazzo added a comment - yeah a patch the problem is how to made a patch?
        Hide
        rayback_2 added a comment -

        Hi , great you managed to solve it. maybe you can produce a patch with that amendment and put it here as attachment.

        Thnx

        Aziz GÖKTEPE

        Show
        rayback_2 added a comment - Hi , great you managed to solve it. maybe you can produce a patch with that amendment and put it here as attachment. Thnx Aziz GÖKTEPE
        Hide
        rbonazzo added a comment -

        Hi,
        solved in this way

        // return part content as octet stream data
        InputStream is = odfDoc.getPackage().getInputStream(partPath);
        OctetStreamData retData = null;
        if(is !null)

        { retData = new OctetStreamData(is); }

        return retData

        Regards

        Rinaldo

        Show
        rbonazzo added a comment - Hi, solved in this way // return part content as octet stream data InputStream is = odfDoc.getPackage().getInputStream(partPath); OctetStreamData retData = null; if(is !null) { retData = new OctetStreamData(is); } return retData Regards Rinaldo
        Hide
        rbonazzo added a comment -

        Hi Aziz thx,
        I found the patch and compile the project under eclipse.
        I have a problem when the program try to read Configurations2/accelerator/current.xml

        He give me the following error:

        javax.xml.crypto.dsig.XMLSignatureException: javax.xml.crypto.URIReferenceException: java.lang.NullPointerException: octetStream is null

        The code is
        // return part content as octet stream data
        InputStream is = odfDoc.getPackage().getInputStream(partPath);
        OctetStreamData retData = new OctetStreamData(is);

        Is it normal?

        Regards
        Rinaldo

        Show
        rbonazzo added a comment - Hi Aziz thx, I found the patch and compile the project under eclipse. I have a problem when the program try to read Configurations2/accelerator/current.xml He give me the following error: javax.xml.crypto.dsig.XMLSignatureException: javax.xml.crypto.URIReferenceException: java.lang.NullPointerException: octetStream is null The code is // return part content as octet stream data InputStream is = odfDoc.getPackage().getInputStream(partPath); OctetStreamData retData = new OctetStreamData(is); Is it normal? Regards Rinaldo
        Hide
        rayback_2 added a comment -

        Maybe you are using released binaries and not building from source code?

        The package and the class you are looking for did not make it to the release, so you should download source code and apply patch (then build to get the jar), to be able to see those classes. If you are already doing it this way, then there must be something wrong with the patch. can you please confirm ?

        Aziz GÖKTEPE

        Show
        rayback_2 added a comment - Maybe you are using released binaries and not building from source code? The package and the class you are looking for did not make it to the release, so you should download source code and apply patch (then build to get the jar), to be able to see those classes. If you are already doing it this way, then there must be something wrong with the patch. can you please confirm ? Aziz GÖKTEPE
        Hide
        rbonazzo added a comment -

        Hi Aziz
        Thx for your answer,
        the problem is that I can not found org.odftoolkit.odfdom.pkg.signature
        and also DigitalSignatureManager can not be found

        can you help me to find it
        thx

        rinaldo

        Show
        rbonazzo added a comment - Hi Aziz Thx for your answer, the problem is that I can not found org.odftoolkit.odfdom.pkg.signature and also DigitalSignatureManager can not be found can you help me to find it thx rinaldo
        Hide
        rayback_2 added a comment -

        (In reply to comment #7)

        Hi, long time passed since I sent patch, and lot changed in odfdom since then. Unfortunately I "never found time" to implement suggestions by Svante (guess I hoped someone would pick from there eventually).

        But patch should be usable for signing and verification purposes, as it is used in our project. I would be glad to help if you have any questions.

        Sincerely
        Aziz GÖKTEPE

        > Hi all I'm new in this project I need to digital sign a document so I try to
        > download the patch but I found nothing about it any help pls
        > Regards
        > Rinaldo

        Show
        rayback_2 added a comment - (In reply to comment #7) Hi, long time passed since I sent patch, and lot changed in odfdom since then. Unfortunately I "never found time" to implement suggestions by Svante (guess I hoped someone would pick from there eventually). But patch should be usable for signing and verification purposes, as it is used in our project. I would be glad to help if you have any questions. Sincerely Aziz GÖKTEPE > Hi all I'm new in this project I need to digital sign a document so I try to > download the patch but I found nothing about it any help pls > Regards > Rinaldo
        Hide
        rbonazzo added a comment -

        Hi all I'm new in this project I need to digital sign a document so I try to download the patch but I found nothing about it any help pls
        Regards
        Rinaldo

        Show
        rbonazzo added a comment - Hi all I'm new in this project I need to digital sign a document so I try to download the patch but I found nothing about it any help pls Regards Rinaldo
        Hide
        rayback_2 added a comment -

        Hi Svante,

        Thanks for suggestions and changes to the patch , I will look at it asap.

        Maybe I should have stated it from the beginning, but when writing the code I was modeling design from .NET's System.IO.Packaging API (you easily can see resemblance; PackageDigitalSignatureManager is our DocumentSignatureManager, PackageDigitalSignature is our DocumentSignature, well there's no counterpart for DocumentSignatureGroup in .NET because odf draft v1.2 introduces that but ooxml (opc) does not have it).

        Having said that ;

        I agree to 1) that is, moving of classes beyond org.odftoolkit.odfdom.pkg.signature (which I guess you already have done in changed patch)

        about 2) create a DOMrepresentation of the signature XML elements/attributes, I am not sure how it will work, since XMLSignature is pretty much self contained (you can access signedInfo, references and objects). And to be honest I've no idea of how to generate DESIG DOM (not deep dived into odfdom), so I need to read that (in manuals maybe?) if we choose to go that way.

        Also I chose to expose properties to be used most (such as signer certificate, signing time, file entries signed ) of XMLSignature through properties of DocumentSignature class, yet giving access to XMLSignature structure itself for more low level parsing maybe. I am really not sure about this, so I will let you decide which way you think is best for the project

        I agree to 3) that Constants.java hold some values, that already exist in ODFDOM (not all though), some refactoring is needed there indeed.

        as to 4) as I said I chose .NET's way of doing it, so all signing methods are in DocumentSignatureManager class ; signDocument signs all file entries in package (except for other signatures, and manifest), there's also sign method accepting List of FileEntryIdentifier , and signs only those file entries in a package (that is it can sign subset of package file entries if wished so). We can move those methods to OdfPackage (goes inline with 1 ), so they can be called (also verify, getSignatureGroups and all other methods of DocumentSignatureManager) on package object. I did not understand what you mean by "The signature: Have to existent on some trusted site." constraint though, maybe you can clarify as it seems that's something I missed doing.

        on 5) you are absolutely correct, that's my bad of not commenting everything , will do that.

        All the patch is doing now is adding digital signature to either specific file entries or the whole document as specified by odf v1.2 draft. Also parsing and verification of signatures in package is in place (core validation is there, but no certificate chain validation since that's totally out of odfdom's scope I think. but one can get signing certificate and validate it using well known libraries if wished easily). It has compatibility mode for OpenOffice3.1 (which might be better named odfv1.1 maybe), where the only restriction is to place all signatures in META-INF/documentsignatures.xml.

        For future ,implementing xades will be valuable addition I think.

        as per your previous post about odfv1.2 draft's signature proposal, I have some thoughts to share but unfortunately had not time yet to formulate them (specifically regarding signature file placements and dicsovery, and signature time property), and I suspect this is not a right place to post them. I will try to write those soon.

        Sincerely
        Aziz GÖKTEPE

        Show
        rayback_2 added a comment - Hi Svante, Thanks for suggestions and changes to the patch , I will look at it asap. Maybe I should have stated it from the beginning, but when writing the code I was modeling design from .NET's System.IO.Packaging API (you easily can see resemblance; PackageDigitalSignatureManager is our DocumentSignatureManager, PackageDigitalSignature is our DocumentSignature, well there's no counterpart for DocumentSignatureGroup in .NET because odf draft v1.2 introduces that but ooxml (opc) does not have it). Having said that ; I agree to 1) that is, moving of classes beyond org.odftoolkit.odfdom.pkg.signature (which I guess you already have done in changed patch) about 2) create a DOMrepresentation of the signature XML elements/attributes, I am not sure how it will work, since XMLSignature is pretty much self contained (you can access signedInfo, references and objects). And to be honest I've no idea of how to generate DESIG DOM (not deep dived into odfdom), so I need to read that (in manuals maybe?) if we choose to go that way. Also I chose to expose properties to be used most (such as signer certificate, signing time, file entries signed ) of XMLSignature through properties of DocumentSignature class, yet giving access to XMLSignature structure itself for more low level parsing maybe. I am really not sure about this, so I will let you decide which way you think is best for the project I agree to 3) that Constants.java hold some values, that already exist in ODFDOM (not all though), some refactoring is needed there indeed. as to 4) as I said I chose .NET's way of doing it, so all signing methods are in DocumentSignatureManager class ; signDocument signs all file entries in package (except for other signatures, and manifest), there's also sign method accepting List of FileEntryIdentifier , and signs only those file entries in a package (that is it can sign subset of package file entries if wished so). We can move those methods to OdfPackage (goes inline with 1 ), so they can be called (also verify, getSignatureGroups and all other methods of DocumentSignatureManager) on package object. I did not understand what you mean by "The signature: Have to existent on some trusted site." constraint though, maybe you can clarify as it seems that's something I missed doing. on 5) you are absolutely correct, that's my bad of not commenting everything , will do that. All the patch is doing now is adding digital signature to either specific file entries or the whole document as specified by odf v1.2 draft. Also parsing and verification of signatures in package is in place (core validation is there, but no certificate chain validation since that's totally out of odfdom's scope I think. but one can get signing certificate and validate it using well known libraries if wished easily). It has compatibility mode for OpenOffice3.1 (which might be better named odfv1.1 maybe), where the only restriction is to place all signatures in META-INF/documentsignatures.xml. For future ,implementing xades will be valuable addition I think. as per your previous post about odfv1.2 draft's signature proposal, I have some thoughts to share but unfortunately had not time yet to formulate them (specifically regarding signature file placements and dicsovery, and signature time property), and I suspect this is not a right place to post them. I will try to write those soon. Sincerely Aziz GÖKTEPE
        Hide
        Svante Schubert added a comment -

        Created an attachment (id=147)
        Suggestion of Java Package name change

        This patch just slightly changes the previous given patch

        Show
        Svante Schubert added a comment - Created an attachment (id=147) Suggestion of Java Package name change This patch just slightly changes the previous given patch
        Hide
        Svante Schubert added a comment -

        Never mind about the first patch, I did worse, when I started with Mercurial

        I have started to look over your patch. As well I have read the ODF 1.2 package specification/schema and took a look into the W3C XML Digital Signature specification (ie. http://www.w3.org/TR/xmldsig-core ).

        So much I understand: you have really not started with something trivial to contribute, Aziz.

        As I am not an expert on signing, perhaps you might summarize in short what kind of subfeatures, the feature package signature does have from your point of view.

        Certain is that I need more time to work myself further into your work, but even from a bird perspective I am already able to give suggestions of slight modifications, how your patch be adapted to the existing ODFDOM architecture:
        to make, to adapt your work into the existing design:

        1) As signatures are a package feature, all the classes might be moved into a directory, beyond org.odftoolkit.odfdom.pkg.signature
        (I had done some refactorings using Netbeans refactoring feature and will add them as suggestion/patch soon.)

        2) As signature depend on an XML schema, perhaps it makes sense to create a DOM representation of the signature XML elements/attributes as well?
        I have not seen through the complete structure yet to be certain about it.
        It might be possible by generating the DESIG DOM via the new generator (that might delay this patch a little more, but its definitely a feature for the next 0.8 release.
        The generated classes might reside beyond:
        org.odftoolkit.odfdom.pkg.signature.element

        3)
        The class Constants.java hold some values, that already exist in ODFDOM and might be hidden/refactored away. For now I used the package modifier to remove them from the JavaDoc API. (Similar works for FileEntryIdentifier.java, which is as well something not dependent on signature, but is a common package thing, that most likely exist (latest when we generate a DOM for the manifest.xml).

        4)
        I was wondering that there was no new methods on the OdfPackage class to sign files from the package.
        Regarding the methods we might add OdfPackage, we might orientate ourselves on the subfeatures that are offered on having a signature.

        You are much more an expert on signature than I am, I simply read quickly some examples to identify a start for the (sub)features of the signature feature.

        Subfeature:
        SIGN Package or subset with one or more SIGNATURE

        Constraint:
        The file have to be existent!!
        The signature: Have to existent on some trusted site.

        5) Finally, I have realized that some of the public/protected methods have not complete JavaDoc (e.g. return value was not explained). Well, you might call me picky on this, but on the other hand, if we do not add it from the beginning, who will ever add it and it should look 100% professional, don't you think

        Good work! It's much easier to review, and slightly refactor than to write such code on oneself.

        Thanks again for your contribution, looking forward to look further into your patch (although this week the generator has precedence)..

        Cheers,
        Svante

        Show
        Svante Schubert added a comment - Never mind about the first patch, I did worse, when I started with Mercurial I have started to look over your patch. As well I have read the ODF 1.2 package specification/schema and took a look into the W3C XML Digital Signature specification (ie. http://www.w3.org/TR/xmldsig-core ). So much I understand: you have really not started with something trivial to contribute, Aziz. As I am not an expert on signing, perhaps you might summarize in short what kind of subfeatures, the feature package signature does have from your point of view. Certain is that I need more time to work myself further into your work, but even from a bird perspective I am already able to give suggestions of slight modifications, how your patch be adapted to the existing ODFDOM architecture: to make, to adapt your work into the existing design: 1) As signatures are a package feature, all the classes might be moved into a directory, beyond org.odftoolkit.odfdom.pkg.signature (I had done some refactorings using Netbeans refactoring feature and will add them as suggestion/patch soon.) 2) As signature depend on an XML schema, perhaps it makes sense to create a DOM representation of the signature XML elements/attributes as well? I have not seen through the complete structure yet to be certain about it. It might be possible by generating the DESIG DOM via the new generator (that might delay this patch a little more, but its definitely a feature for the next 0.8 release. The generated classes might reside beyond: org.odftoolkit.odfdom.pkg.signature.element 3) The class Constants.java hold some values, that already exist in ODFDOM and might be hidden/refactored away. For now I used the package modifier to remove them from the JavaDoc API. (Similar works for FileEntryIdentifier.java, which is as well something not dependent on signature, but is a common package thing, that most likely exist (latest when we generate a DOM for the manifest.xml). 4) I was wondering that there was no new methods on the OdfPackage class to sign files from the package. Regarding the methods we might add OdfPackage, we might orientate ourselves on the subfeatures that are offered on having a signature. You are much more an expert on signature than I am, I simply read quickly some examples to identify a start for the (sub)features of the signature feature. Subfeature: SIGN Package or subset with one or more SIGNATURE Constraint: The file have to be existent!! The signature: Have to existent on some trusted site. 5) Finally, I have realized that some of the public/protected methods have not complete JavaDoc (e.g. return value was not explained). Well, you might call me picky on this, but on the other hand, if we do not add it from the beginning, who will ever add it and it should look 100% professional, don't you think Good work! It's much easier to review, and slightly refactor than to write such code on oneself. Thanks again for your contribution, looking forward to look further into your patch (although this week the generator has precedence).. Cheers, Svante
        Hide
        rayback_2 added a comment -

        Created an attachment (id=145)
        patch to digitally sign and verify odf documents [corrected patch]

        Yes the patch was not good, sorry for that [and its my first mercurial experience].

        Here's the corrected patch

        Sincerely
        Aziz GÖKTEPE

        Show
        rayback_2 added a comment - Created an attachment (id=145) patch to digitally sign and verify odf documents [corrected patch] Yes the patch was not good, sorry for that [and its my first mercurial experience] . Here's the corrected patch Sincerely Aziz GÖKTEPE
        Hide
        Svante Schubert added a comment -

        I had problems to merge your patch, as the parent revision (starting with '3f36b8711fe12') can not be found.

        Let's take a look at the problem in detail and look at the head of your patch:

        1. HG changeset patch
        2. User rayback_2
        3. Date 1258669648 -7200
        4. Node ID 1bb75adcd6e81dcb1f72549ff4570fd29383a02d
        5. Parent 3f36b8711fe12da058eb134b2c12d254f806a3a0
          bug115-digital-signature

        If you clone the latest version via
        'hg clone https://odftoolkit.org/hg/odfdom~developer 115-signature'
        (where 115-signature would be the output dirctory)

        'cd 115-signature' (go to the fresh sources)
        'hg log > ../log-0-7-5.txt' (write the log messages into a file)

        You won't find the revision '3f36b8711fe12', that was mentioned to be the parent of your patch.

        You might as well create a log from your repository you created the patch from.
        You need to create a patch from all commits that are not part of the master, see
        http://odftoolkit.org/projects/odfdom/pages/Development#Mercurial

        We should indeed update the wiki about the basic developer scenarios (ie. creating/reviewing a patch with Mercurial). Perhaps someone volunteers, otherwise I will do it next week.

        Have a nice week-end!
        Svante

        Show
        Svante Schubert added a comment - I had problems to merge your patch, as the parent revision (starting with '3f36b8711fe12') can not be found. Let's take a look at the problem in detail and look at the head of your patch: HG changeset patch User rayback_2 Date 1258669648 -7200 Node ID 1bb75adcd6e81dcb1f72549ff4570fd29383a02d Parent 3f36b8711fe12da058eb134b2c12d254f806a3a0 bug115-digital-signature If you clone the latest version via 'hg clone https://odftoolkit.org/hg/odfdom~developer 115-signature' (where 115-signature would be the output dirctory) 'cd 115-signature' (go to the fresh sources) 'hg log > ../log-0-7-5.txt' (write the log messages into a file) You won't find the revision '3f36b8711fe12', that was mentioned to be the parent of your patch. You might as well create a log from your repository you created the patch from. You need to create a patch from all commits that are not part of the master, see http://odftoolkit.org/projects/odfdom/pages/Development#Mercurial We should indeed update the wiki about the basic developer scenarios (ie. creating/reviewing a patch with Mercurial). Perhaps someone volunteers, otherwise I will do it next week. Have a nice week-end! Svante
        Hide
        rayback_2 added a comment -

        Created an attachment (id=142)
        Patch to add and verify digital signatures for odf documents

        Patch to create digital signatures and verify signatures of odf documents.

        DigitalSignatureManager is an object that manages creation and verification of signatures.

        DocumentSignatureGroup is an object holding related document signatures, it corresponds to digital signature file entry. There's a relationship between signatures in same group as of odfv1.2 draft.

        DocumentSignature holds document signature (XMLSignature), that signs document.

        IMPORTANT :
        DigitalSignatureManager can operate in two compatibility modes in terms of signature creation.
        1) OpenOffice31CompatibilityMode
        in this mode there can be only one digital signature group, which corresponds to "META-INF/documentsignatures.xml" file as is required by OpenOffice3.1 to display signatures properly.

        2) OdfV12DraftCompatibilityMode
        this is the mode that follows advices of Odfv1.2 draft, that is signatures can be grouped by some defined relationships in same group, and there can be multiple signature groups (signature files). Signature files (groups) are placed in META-INF/ directory and have "signatures" in their file names.

        for signature verification and parsing, signature creation mode is irrelevant.

        Tried to comment heavily as possible

        Sincerely
        Aziz GÖKTEPE

        Show
        rayback_2 added a comment - Created an attachment (id=142) Patch to add and verify digital signatures for odf documents Patch to create digital signatures and verify signatures of odf documents. DigitalSignatureManager is an object that manages creation and verification of signatures. DocumentSignatureGroup is an object holding related document signatures, it corresponds to digital signature file entry. There's a relationship between signatures in same group as of odfv1.2 draft. DocumentSignature holds document signature (XMLSignature), that signs document. IMPORTANT : DigitalSignatureManager can operate in two compatibility modes in terms of signature creation. 1) OpenOffice31CompatibilityMode in this mode there can be only one digital signature group, which corresponds to "META-INF/documentsignatures.xml" file as is required by OpenOffice3.1 to display signatures properly. 2) OdfV12DraftCompatibilityMode this is the mode that follows advices of Odfv1.2 draft, that is signatures can be grouped by some defined relationships in same group, and there can be multiple signature groups (signature files). Signature files (groups) are placed in META-INF/ directory and have "signatures" in their file names. for signature verification and parsing, signature creation mode is irrelevant. Tried to comment heavily as possible Sincerely Aziz GÖKTEPE

          People

          • Assignee:
            issues
            Reporter:
            rayback_2
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:

              Development