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] OFFICE-2656: Default Signing After Encryption isUnacceptable


On 05/06/10 00:48, Dennis E. Hamilton wrote:
> Patrick, the only proposal I would make is that the current signatures always happen before any encryption, whether or not the signature is encrypted (and it should be if there is any encryption).  That's with regard to the current state of affairs.  There would be no signing after encryption using the package-embedded ODF 1.2 digital signatures.

I've explained in my other mail why signing after encryption is 
reasonable. I definitively want to keep that option, which works well in 
practice. But I would have no objection to add the possibility to 
encrypt documents after signing them if you provide a use case and 
proposal for this.

Actually, I've tried to address this already by the clarification I've 
made in OFFICE-2656, which says:

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.
If a digital signature file is encrypted, consumers shall decrypt files 
that are referenced by <Reference> elements and that are encrypted 
before validating the signature.

The first clause covers the case that a signature is applied to an 
already encrypted document. In this case, the signature uses the 
encrypted stream for the reasons I've explained in my other mail.

The 2nd clause covers the case that a signed document is encrypted. In 
this case the full package needs to be decrypted (including the 
signature) before validating a signature.

I have to admit that I fail to see what is missing, and that I also 
don't understand your objections to providing the option to sign 
encrypted documents, or to let digital signatures operate on the 
encrypted data.

Best regards


> However, that will break every digital signature implementation in previous and current versions of OO.o, including any other implementation using that part of the code base, which is why I think removal from the ODF specification might be the only option (for now).
> Another solution, whether or not there is removal or repair, is to go to an external/wrapper signing and encryption model.  The signing part of that is a bit problematic because it has to deal with being outside of a Zip.  That may be simply unworkable, especially as more-sophisticated signature approaches are introduced, such as XadES.  (On the other hand, since we have adopted a sign-everything whatever its form for META-INF/documentsignatures.xml, an external signature can do that little rather easily.)  But either way, external/wrapper signatures/encryptions don't have to be on the ODF 1.2 critical path and don't even have to be done in the ODF TC.  The advantage of these models, at least for encryption, is that it just makes everything straightforward, the threat models are understandable, and it is possible to vet implementations much more easily than one snarled up inside the ODF 1.2 Package and document model. 
> Thanks for asking,
>  - Dennis
> -----Original Message-----
> From: Patrick Durusau [mailto:patrick@durusau.net] 
> Sent: Wednesday, May 05, 2010 15:02
> To: office@lists.oasis-open.org
> Subject: Re: [office] OFFICE-2656: Default Signing After Encryption is Unacceptable
> Dennis,
> I am trying to catch up on this issue.
> Do you have an alternative proposal?
> To the list: Discussion without the adjectives would be appreciated. I 
> have enough closing emails to review without having to wade through 
> non-substantive remarks. Simply stating the facts are enough. You 
> already have my attention.
> Hope you are having a great day!
> Patrick
> [ ... ] 
> ---------------------------------------------------------------------
> 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

Michael Brauer, Technical Architect Software Engineering
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500

Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
	   D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: J├╝rgen Kunz

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