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-3027) Public Comment: ODF1.2 Part 3 Encryption Process and Default Concerns



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

Dennis Hamilton commented on OFFICE-3027:
-----------------------------------------

+1 on the direction being taken here.

I am going to apply all of the proposals that we have in this area to a copy of Part 3 and make sure that everything holds together.  I will then create resolutions that have the exact changes to carry out our areas of agreement.

If necessary, I will make any subtasks on the current issue needed to address any other parts.

SOME ANALYSIS:

We can allow AES-128-CBC and the other AES-nnn-CBC methods (and other block-cipher CBC methods, including 3DES, etc).  Padding for Block ciphers is specified in [xmlenc-core] section 5.2, Padding subsection (at the beginning).  This padding technique does allow the original plaintext size to be recovered exactly by examining the last byte of the decrypted ciphertext.  The ciphertext will be at least 1 byte and up to block-size bytes longer than the plaintext (that is, the DEFLATEd form of the package file).

Considerations on the use of Initialization Vectors are provided in 6.3 of [xmlenc-core] and we tend to comply with that by default.

ONE IMPORTANT CONCERN: [xmlenc-core] specifies that the IV is concatenated to the front of the ciphertext.  For the legacy Blowfish CFB, we carry the IV separately in the manifest.xml.  I SUSPECT WE NEED TO HONOR THOSE SPECIFICATIONS.  We should then define our IV attribute value to be optional when the identified algorithm already specifies a different method for delivery of the IV for use in decryption of the ciphertext.

ONE MINOR CONCERN: Oddly, with all of the care in [xmlenc-core] to cite references, CBC is *never* defined nor is any explicit reference provided for it.  It might be provided in one of the FIPS publications.  If not we can always reference [Schneier] for it.  There is a definition of CBC for DES at <http://www.itl.nist.gov/fipspubs/fip81.htm>.   A modern reference that applies to all US-approved block ciphers appears to be to NIST Special Publication 800-38A <http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf>, 2001 edition.  NIST does not specify padding, but we can use the [xmlenc-core] specification quite nicely.

> Public Comment: ODF 1.2 Part 3 Encryption Process and Default Concerns
> ----------------------------------------------------------------------
>
>                 Key: OFFICE-3027
>                 URL: http://tools.oasis-open.org/issues/browse/OFFICE-3027
>             Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
>          Issue Type: Sub-task
>          Components: Part 3 (Packages), Public Review, Security
>    Affects Versions: ODF 1.2 CD 05
>            Reporter: Dennis Hamilton
>            Assignee: Dennis Hamilton
>             Fix For: ODF 1.2 CD 06
>
>
> There are clarifications requested for portions of the Encryption process, with objection to the Blowfish default and proposal of an AES default.
> The full text is in the second attachment to the public comment posting at
> <http://lists.oasis-open.org/archives/office/201006/msg00071.html>.
> Here is the Complete Text extracted from the Microsoft Word Format document linked in the original comment:
> """
> Forslag til ændringer i ODF  1.2 Part 3:
> For
> * Section 2.4.2 [CD05 3.4.2] Default Encryption algorithm:
> Since the section deals with the steps involved in encrypting and not
> so much the encryption algorithm itself, I suggest changing the name
> of the section to "Encryption process".
> * Section 2.8 [CD05 3.8] Preview Image
> Simply editorial, but the last sentence should start with the word
> "They" and not "The". Also, there seems to be an extra [space] between
> the words "is" and "independant".
> * Section 3.5 [CD05 4.5] <manifest:algorithm>
> I propose to change section 3.5 [CD05 4.5] to the following:
> [Section 3.5 [CD05 4.5] start]
> The <manifest:algorithm> element specifies the algorithm used to encrypt data.
> The <manifest:algorithm>-element SHALL only contain child elements
> that are permitted child elements of an <EncryptionMethod> element as
> defined in §3.2 of [xmlenc-core], whose Algorithm-attribute has the
> value of the manifest:algorithm-name attribute.
> If the value of the manifest:algorithm-name attribute is Blowfish CFB
> the <manifest:algorithm> element shall not have child elements.
> (section describing schema at the end of the section remains the same)
> [Section 3.5 [CD05 4.5] end]
> Justification:
> The idea is basically to promote "standard" algorithms and XML
> constructs as those mentioned in [xmlenc-core] to "first class
> citizens" of ODF while making usage of Blowfish a second class citizen
> - while acknowledging that there are documents and applications out
> there using Blowfish.
> I have specifically chosen to substitute " SHOULD only contain child
> elements" with " SHALL only contain child elements" since I see no
> need for the more lose "should"-term. The definition of
> EncryptionMethod from xmlenc-core consists of optional child elements,
> so this fits nicely with "no child elements" when dealing with
> Blowfish. I believe a more strict set of element rules would
> facilitate interop better than the current lax way of specifying
> elements.
> * Section 3.8.1 [CD05 4.8.1] manifest:algorithm-name
> I like the idea of reusing already standardised functionality in "XML
> Encryption Syntax and Processing". Especially the reusage of the
> xmlenc-core way of specifiying algorithms look really good and
> facilitate interoperability and reuse of existing implementations of
> encryption algorithms in the best possible way.
> However, I do not understand the need to persist Blowfish as the
> preferred, default algorithm. I also do not understand the need to
> include usage of Blowfish in the list of possible algorithms complying
> with "standard OpenDocument conformance" (and not making it extended
> conformance) - especially since the creator of Blowfish (Bruce
> Schneier) himself discourages the usage of Blowfish today to other
> alternatives.
> I therefore propose the entire paragraph to be changed to:
> [Section 3.8.1 [CD05 4.8.1] start]
> The manifest:algorithm-name attribute specifies the name of the
> algorithm used to encrypt a file entry, and also specifies in which
> mode this algorithm was used.
> Defined values for the manifest:algorithm-name attribute are:
> * An IRI listed in §5.2 or §5.3 of [xmlenc-core]: The algorithm
> specified in §5.2 or §5.3 of [xmlenc-core] for this IRI, or
> * The IRI of an alternative algorithm as specified in §5.1 of  [xmlenc-core].
> To maintain compatibility with existing applications and documents
> conforming to earlier versions of this specification, an application
> may support Blowfish in CBC-code. The defined values for this
> algorithm are "Blowfish CBC" or
> "urn:oasis:names:tc:opendocument:xmlns:manifest:1.0#blowfish" See
> [Blowfish].
> Package producers and package consumers that support encryption shall
> support AES-128 CBC using the value
> http://www.w3.org/2001/04/xmlenc#aes128-cbc.
> Alternative algorithms other than an IRI listed in §5.2 or §5.3 of
> [xmlenc-core] may be specified by extended conforming documents only.
> They shall not be specified by conforming documents.
> (section describing schema at the end of the section remains the same)
> [Section 3.8.1 [CD05 4.8.1] end]

-- 
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]