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

I still don't seem to be able to log in to comment - 

This is worth some detailed discussion. First, let's address the way encryption works - there are a number of information leaks which are present in the current approach. Applying an unencrypted signature to an encrypted document would expose some very serious PII, such as the signer name, information about the organization the signer belongs to, and even potentially extended certificate information, which could include addresses and phone numbers.

Clearly, if a document is encrypted, the signature needs to be encrypted as well. An additional concern is that you should be able to apply and remove encryption from a document without affecting the signature on the rest of the document. If you make the simplifying assumption that either the document and the signature are encrypted or decrypted, not mixed, then the processing order would be to decrypt the entire file (which could be done in stages), and then check the signature.

Ideally, a container file would be created that would only contain the encrypted stream and the encryption definition XML, and you'd just encrypt or decrypt the entire archive, which would not leak any information about the enclosed file. I'd suggest that it might be appropriate to document 2 forms of encryption - legacy, which works exactly the way it did in 1.1, and an updated approach, which could then be an entirely new process which overcomes the flaws in the existing encryption.

Working from memory, the flaws in the existing encryption are:

1) Information leakage
2) Dependence on Blowfish
3) Non-configurable iteration count on the KDF
4) Lack of an independent password verifier and integrity check (i.e., you should be able to distinguish between a document with some bits flipped and an incorrect password - you'd prefer to take different actions for each case)

I note that we've removed problems (2) and (3) from the current specification, but if we're going to make changes, I'd urge you to fix the entire problem as completely as possible. I maintain code right now for 5 different encryption/obfuscation approaches (1 configurable, 1 based on AES, 2 based on RC4 (both weak and flawed), and then there the legacy XOR), and that's not a happy place to be. It would be good for implementers of ODF encryption to only have to worry about 2 approaches. We don't currently implement encryption of ODF files, but I have a strong preference that the implementation be equivalent in strength to what we currently ship for the OOXML files. It isn't a good thing to have to explain to a customer that their choice of save-as format resulted in completely different encryption approaches and/or algorithms.

As long as you have an integrity checking mechanism (which you do have on the current encryption specification), there is no need to sign the outer encrypted data.

I'd agree with Dennis that the current implementation is in error and ought not be made a part of the standard. However, I'd tend to characterize it as an understandable mistake - encryption and signatures are hard to implement. An obvious breakage that would happen with that approach would be if someone encrypted a signed document after the signature had been applied. If a second signature were then applied, the transforms needed would be completely different, and it a very questionable thing from a cryptographic standpoint to do.

-----Original Message-----
From: OASIS Issues Tracker [mailto:workgroup_mailer@lists.oasis-open.org] 
Sent: Wednesday, May 05, 2010 1:59 PM
To: office@lists.oasis-open.org
Subject: [office] [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


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:

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