OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [office] [OASIS Issue Tracker] Issue Comment Edited:(OFFICE-3417) Public Comment: Comment on ODF v1.2 CD 05 - Document Signatures


As you point out, it looks like they're trying to implement countersigning. Countersigning is already part of XAdES, and done in a way that's easier to implement (IMHO). To go back to a much earlier discussion, the more ways there are to do the same thing, the more difficult it will be to interoperate and have correct implementations.

BTW, in XAdES, it is possible to have fairly arbitrary trees of signatures where a base signature could have more than one countersignature on the base signature, and each of those can have countersignatures as well. I also don't think there would be anything stopping a countersignature from signing multiple countersignatures along with the base signature, either.

Given that we already have that flexibility, and it is very well defined, where this proposed mechanism is still a bit self-contradictory, I'd tend to stick with XAdES as a countersignature mechanism.

________________________________________
From: OASIS Issues Tracker [workgroup_mailer@lists.oasis-open.org]
Sent: Wednesday, September 22, 2010 7:39 PM
To: office@lists.oasis-open.org
Subject: [office] [OASIS Issue Tracker] Issue Comment Edited: (OFFICE-3417) Public Comment: Comment on ODF v1.2 CD 05 - Document Signatures

    [ http://tools.oasis-open.org/issues/browse/OFFICE-3417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21444#action_21444 ]

Dennis Hamilton edited comment on OFFICE-3417 at 9/22/10 10:37 PM:
-------------------------------------------------------------------

David's note is on the ODF TC List Archive at <http://lists.oasis-open.org/archives/office/201009/msg00486.html>.

Here's the part that I thought might be worth remembering to say something about in our DSig material too, although not all of it:

"""
Any or all files in the container can be signed in their entirety with the exception of the signatures.xml file because that file contains the computed signature information. Whether and how the signatures.xml file SHOULD be signed depends on the objective of the signer:

•  If the signer wants to allow signatures to be added or removed from the container without invalidating the signer's signature, the signatures.xml file SHOULD NOT be signed.

•  If the signer wants any addition or removal of a signature to invalidate the signer's signature, the Enveloped Signature transform (defined in Section 6.6.4 of XML-Signature Syntax and Processing) can be used to sign the entire preexisting signature file excluding the <Signature> being created. This transform would sign all previous signatures, and it would become invalid if a subsequent signature was added to the package.

•  If the signer wants the removal of an existing signature to invalidate the signer's signature but also wants to allow the addition of signatures, an XPath transform can be used to sign just the existing signatures. (This is only a suggestion. The particular XPath transform is not a part of UCF specification.)
"""

This provides for co-signing, assuming none of the existing signatures are set up to prevent it.

[My earlier observation about namespaces may simply be a defect in the example I looked at.  It appears that the ODF namespace for a root element that holds one or more XML DSigs is proposed to be used.  ]


      was (Author: orcmid):
    Here's the part that I thought might be worth remembering to say something about in our DSig material too, although not all of it:

"""
Any or all files in the container can be signed in their entirety with the exception of the signatures.xml file because that file contains the computed signature information. Whether and how the signatures.xml file SHOULD be signed depends on the objective of the signer:

•  If the signer wants to allow signatures to be added or removed from the container without invalidating the signer's signature, the signatures.xml file SHOULD NOT be signed.

•  If the signer wants any addition or removal of a signature to invalidate the signer's signature, the Enveloped Signature transform (defined in Section 6.6.4 of XML-Signature Syntax and Processing) can be used to sign the entire preexisting signature file excluding the <Signature> being created. This transform would sign all previous signatures, and it would become invalid if a subsequent signature was added to the package.

•  If the signer wants the removal of an existing signature to invalidate the signer's signature but also wants to allow the addition of signatures, an XPath transform can be used to sign just the existing signatures. (This is only a suggestion. The particular XPath transform is not a part of UCF specification.)
"""

This provides for co-signing, assuming none of the existing signatures are set up to prevent it.

[My earlier observation about namespaces may simply be a defect in the example I looked at.  It appears that the ODF namespace for a root element that holds one or more XML DSigs is proposed to be used.  ]


> Public Comment: Comment on ODF v1.2 CD 05 - Document Signatures
> ---------------------------------------------------------------
>
>                 Key: OFFICE-3417
>                 URL: http://tools.oasis-open.org/issues/browse/OFFICE-3417
>             Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
>          Issue Type: Bug
>          Components: Packaging
>    Affects Versions: ODF 1.2 CD 05
>            Reporter: Robert Weir
>             Fix For: ODF 1.2 CD 06
>
>
> Copied from office-comment list
> Original author: "Pope, Nick" <Nick.Pope@thales-esecurity.com>
> Original date: 6 Sep 2010 19:48:26 -0000
> Original URL: http://lists.oasis-open.org/archives/office-comment/201009/msg00001.html

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]