RE: [office-comment] OFFICE-3869: Relationship of Encryption and Digital Signatures

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

Hi Patrick,

I didn't see your comment until I checked on my response to Regina's proposal.

Right, the note is informative and I used "must" in a different sense.  I have proposed a wording that explains it as a necessity, not a requirement [;<).

 - Dennis

-----Original Message-----
From: Patrick Durusau [mailto:patrick@durusau.net] 
Sent: Monday, January 5, 2015 06:57
To: office-comment@lists.oasis-open.org
Subject: Re: [office-comment] OFFICE-3869: Relationship of Encryption and Digital Signatures

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dennis,

Hope you had a great holiday season!

Question on:

> "If a digital signature file is encrypted using the encryption
> means specified for ODF 1.2 Packages, then the digital signature
> applies to the decrypted forms of all encrypted files in the
> package exactly as if they had not been encrypted.  (Note that in
> this case, the manifest, which is never encrypted, is different
> when there are encrypted files than when there are not.  In
> particular, the manifest must include the parameters that must be
> known to decrypt the encrypted digital signature files.)"

The "Note" language - is this a non-normative note? I ask because of
the "must" in the text, which I can remove if it is non-normative and
change to shall if this should be normative.

Thanks!

Hope you are having a great week!

Patrick

On 09/28/2014 05:02 PM, Dennis E. Hamilton wrote:
> Late in development of ODF 1.2 Part 3: Packages, there was an
> attempt to distinguish between pre-encryption signing (a desirable
> case) and post-encryption signing (the currently-supported case).
> The last two paragraphs of 1.2-3 section 5.2 are the result.
> 
> I believe these are better wordings:
> 
> "If a digital signature file is not encrypted, any encrypted files
> covered by the digital signature are signed in their encrypted form
> as identified in META-INF/manifest.xml.
> 
> "If a digital signature file is encrypted using the encryption
> means specified for ODF 1.2 Packages, then the digital signature
> applies to the decrypted forms of all encrypted files in the
> package exactly as if they had not been encrypted.  (Note that in
> this case, the manifest, which is never encrypted, is different
> when there are encrypted files than when there are not.  In
> particular, the manifest must include the parameters that must be
> known to decrypt the encrypted digital signature files.)"
> 
> The rewording seem to be compatible with the OASIS limitations on
> maintenance versus modification of the specification.  I'm
> reasonably confident that this is consistent with what Michael
> Brauer had in mind. The note simply points out a consequence of the
> current specification.
> 
> 
> -- Dennis E. Hamilton dennis.hamilton@acm.org    +1-206-779-9430 
> https://keybase.io/orcmid  PGP F96E 89FF D456 628A X.509 certs used
> and requested for signed e-mail
> 
> BACKGROUND ANALYSIS
> 
> It is useful to note that, in practice, if encryption it is done,
> it is done before the digital signature. Encryption is done when
> the document is saved.  Signing is done on the saved document and
> all it adds is a META-INF/digitalsignatures.xml file to the package
> (which, consequently is not itself in manifest.xml).  This is the
> form of signing that applies for production and verification of
> digital signatures on ODF 1.2 documents by Apache OpenOffice,
> LibreOffice, and Microsoft Office.
> 
> One provision of existing implementations of the ODF 1.2 Digital
> Signature is that the signature includes everything in
> META-INF/manifest.xml and META-INF/manifest.xml itself.  Since
> META-INF/digitalsignatures.xml is *not* included in the
> manifest.xml, this all works and it allows signatures to be added
> and removed, including in an existing signature file, without
> disturbing the rest of the package at all.
> 
> Consider the following constraints: If encryption occurs *after*
> signing and META-INF/digitalsignatures.xml is encrypted using the
> means specified for ODF 1.2 Packages,
> META-INF/digitalsignatures.xml encryption must be specified in a
> manifest.xml <manifest:file-entry> element.  So either the
> manifest.xml is not signed or it is created and signed before
> META-INF/digitalsignature.xml is created and then encrypted.
> 
> If, in fact, we have a previously-signed document that is then to
> be encrypted, that case is impossible for current implementations
> because the existing signatures include the manifest.xml for that
> unencrypted package and there may be multiple signatures applicable
> to the unencrypted form of the package.
> 
> The problem is that the manifest.xml is different when there are
> encrypted files than when there are not.  And I don't think one
> wants to abandon including manifest.xml in the digital signature.
> There are ways around this problem, but not without adding
> additional provisions for encryption of already-created and signed
> packages.
> 
> There are ways around this, but they go beyond maintenance.
> 
> -- end --
> 
> 

- -- 
Patrick Durusau
patrick@durusau.net
Technical Advisory Board, OASIS (TAB)
Co-Chair, OpenDocument Format TC (OASIS)
Editor, OpenDocument Format TC, Project Editor ISO/IEC 26300
Former Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Co-Editor, ISO 13250-5 (Topic Maps)

Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJUqqY6AAoJEAudyeI2QFGo6RAQAMGfjuSccfEk0uXJVGekZGk7
gDzYQIgliQzw4f/LNy4l5KJZXfOrDE5QHdwzOvor5pEQn2ul5uONbMp8P7ATGaNV
TfFyp6t2KFnY6HLl3Cid75VkbEp2DwAnfLvr/RoT7TSPcVeHisKR1DUwzY6ScV2t
gQ8J7oQKVnapcOGCbyxVnD3jWYJzSxf2X3f8HRPyYLJkwcRdNtjmsYkCLArsw2oa
LZRSXG0AUBqymdVCUkUYSj8hEOjtLv8XIS1G7vJE7HoxaZz3KwcUkWNNMqGu71mi
4b+a5iaumG9CWooTkXt9pHESJcyGrhhgsJA1cQpgNpfyBRtKTg9lZtneYy4ao/Kw
jdPxGUNaOjWqWHkYnbTFNGquHDC6KNceJZUvbl9wdJmVQBb2FIbQLpCdvlL9lDUq
V2vnwyOgx4tyD2+inEi9LobDtmPz5xBX+ija+ASn01iegpzBNhtgsWLqi8x/3Yfv
xI3olDboMg/UzttKG43PlZiJiMJ95SdQK9XcqhA/V6xlDMfyeSHxC/5Dqfe/6a0e
txx0r/Nn7MqUyhRsZjnPdttRwrm2S4Jr7/cMDGbXVC+amh7RXI6pAz89JWJ0mLV0
jKiBvtoTyqT02NwINXzaRusZBWm5r3PF1c4cnaLhpbAkLm4hHXMoDmRhcLYYRShB
LsBXomXFLZx6qorynsNn
=Zvhv
-----END PGP SIGNATURE-----

-- 
This publicly archived list offers a means to provide input to the
OASIS Open Document Format for Office Applications (OpenDocument) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: office-comment-subscribe@lists.oasis-open.org
Unsubscribe: office-comment-unsubscribe@lists.oasis-open.org
List help: office-comment-help@lists.oasis-open.org
List archive: http://lists.oasis-open.org/archives/office-comment/
Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Committee: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office
Join OASIS: http://www.oasis-open.org/join/