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=22725#action_22725 ] 

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

See <http://csrc.nist.gov/groups/ST/toolkit/BCM/current_modes.html> for more on current modes.  Although there is an 800-38A supplement on ciphertext stealing, a favorite of mine, I don't think we should recommend it because it is not anything that [xmlenc-core] provides a URI and specification for.

[PS: Having the IV be prefixed to the ciphertext, as [xmlenc-core] does, is useful in that the IV is always the correct block size and it behaves very much as if it is ciphertext[0] in the way CBC works for both encryption and decryption.  It might as well be initialized from the stream with ciphertext[1] right behind it.  8-bit CFB doesn't provide such a simple setup. ]

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