[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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-----
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]