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: [OASIS Issue Tracker] Commented: (OFFICE-2656) NEEDS-DISCUSSION:Clarify when signatures operate on encrypted and when on unencrypted files.

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

Dennis Hamilton commented on OFFICE-2656:

With regard to #1 and the proposed additional statement,

The statement "If a digital signature file is not encrypted, consumers shall not decrypt files that are referenced by <Reference> elements and that are encrypted before validating the signature. " clearly applies to current implementations, because the digital signature files are not encrypted and there had been no option to encrypt them.

Are you telling me that this is the way the current OO.o digital signature works?  It always signs the encrypted form of Zip parts that there are <Reference> URI attributes to because they are seen as STORED binary files?  (I did nose around and I see that the ceremony requires encryption to be specified first, because it is part of Save As ..., and then signature has to be specified second because signing must be done on a stored docuemnt.)

You are telling me that this bizarre implementation artifact is now what you what us to memorialize in the ODF 1.2 standard?  By default, ODF 1.2 signatures are always *after* any encryption and the URIs are to whatever the Zip thinks it contains at that point?   So, are the Transforms adjusted to reflect this, or do they still specify XML canonicalization?  I must go look.

And this is the first time this interesting little factoid has surfaced in the specification?

If so, this is not only a hack, it is completely unacceptable. 

It breaks the abstraction around how URis are interpreted and what it means to refer to a file that is in the package (except for the manifest, which does not use URIs to do that).  It also immortalizes and enshrines a thoughtless signature practice that defeats the notion that people know what they are signing or that it could at least be possible for them to know.

If this is not quickly repairable in the ODF 1.2 Committee Drafts, I propose that the Digital Signature provsions of ODF 1.2 Part 3, and the reliance on them in ODF 1.2 Part 1 be withdrawn from ODF 1.2 and returned as a supplement at a future date.

> NEEDS-DISCUSSION: Clarify when signatures operate on encrypted and when on unencrypted files.
> ---------------------------------------------------------------------------------------------
>                 Key: OFFICE-2656
>                 URL: http://tools.oasis-open.org/issues/browse/OFFICE-2656
>             Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
>          Issue Type: Sub-task
>          Components: Packaging
>    Affects Versions: ODF 1.2 Part 3 CD 1
>            Reporter: Michael Brauer
>            Assignee: Michael Brauer
>             Fix For: ODF 1.2 Part 2 CD 3
> The ODF 1.2 part 3 CD01 specification currently does not explicitly state how references to encrypted files are handled.
> There are two uses cases:
> a) A signature is applied to an encrypted document. In this case, the signature would operate on the encrypted files.
> b) A signed document is encrypted. In this case, the signature would operate on the unencrypted files.

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


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