[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=22680#action_22680 ] Michael Brauer commented on OFFICE-3027: ---------------------------------------- Since we seem to agree to the proposal (with the few corrections Malte mentions and one I will mention below), what prevents us from resolving this issue. I think we can adopt the proposal, with the following corrections/enhancements: - the "default algorithm" should be renamed "legacy algorithm", - "CBC" must read "CFB" - the references to §5.3 of [xmlenc-core] should be removed, and - to stay consistent with the formatting we should keep the two values er have for blowfish in the list of permitted values for manifest:algorithm, but we should move them to the end of the list. > 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]