[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Updated: (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:all-tabpanel ]
Dennis Hamilton updated OFFICE-3027:
------------------------------------
Description:
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]
was:
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 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 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 <manifest:algorithm>
I propose to change section 3.5 to the following:
[Section 3.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 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 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 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 end]
Included the section numbers that apply to CD05 in the description. The section numbers of the comment are based on an earlier draft than ODF 1.2 CD05 Part 3.
> 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]