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: Re: [office] Re: encryption


Hi Bob,

On 09/02/09 11:42, Bob Jolliffe wrote:
> 2009/9/1 Robert Weir/Cambridge/IBM <robert_weir@us.ibm.com 
> <mailto:robert_weir@us.ibm.com>>
> 
>     The reason to allow more than one algorithm, aside from preferences
>     (individual, corporate, national requirements etc.) is that an attack
>     could be found against any one of these algorithms and you don't want to
>     be in a situation where the only algorithms specified are weak or
>     broken.
>     The use of SHA1, in particular, does not seem to be a good algorithm
>     today.
> 
> 
> Agreed.  Being bound to SHA1 is not sensible.  And if the situation were 
> to be that all the algorithms we specified are somehow compromised, then 
> yes, we end up with egg on our faces if we have no way of allowing the 
> new stronger algorithm.
> 
> But to be honest, I really don't think that's a fair reflection of the 
> situation.
> 
> If you look at actual public sector requirements (eg. the South African 
> MIOS, the Brazilian Ping, European EIF etc) I think the usual practice 
> is to specify a list of acceptable algorithms and to update and maintain 
> that list from time to time.  I haven't seen any example of allowances 
> for additional as yet undefined algorithms.  So long as ODF specifies a 
> reasonable subset of those algorithms (not just one) I believe we 
> effectively meet the requirements.

I think this very well summarized the situation we are in. The lists of 
what are acceptable algorithms are not maintained by us, the ODF TC, 
there are multiple of them (which I assume are different), and they may 
change over time.

If we could find a set of algorithms where we believe that our subset 
contains at least one algorithm from all lists of acceptable algorithms 
that do exist, and if we further believe that these lists will remain 
stable until we have approved "ODF-Next", then I'm fine with restricting 
the set of permitted algorithms.

But if we believe that the lists of acceptable algorithms may move away 
from any list of acceptable algorithms we can define today, then I 
actually feel more comfortable by being allowing additional algorithms, 
provided that there is a (possibly small) set of algorithms that are 
mandatory, so that implementors and users know that these algorithm(s) 
are supported by all applications that support encryption.

Best regards

Michael
> 
> To hold open a place holder for the as yet unnamed Uber-algorithm which 
> is just around the corner and which will displace the existing ones 
> might seem on the surface to make sense and that is the argument which 
> is frequently used.  But what may be more likely is the mechanism being 
> used in the exact opposite way ie. the space will be used by 
> implementation defined (and weaker), "legacy" algorithms.  We have 
> already seen the real difficulties raised by supporting the legacy 
> hashing algorithm in OOXML.
> 
> 
>     Of course, this doesn't mean you need to leave it open ended.
> 
>     It really boils down to three questions:
> 
>     1) For each algorithm type (hash, encryption, etc.), what unique
>     identifier to we associate with each algorithm?
> 
>     2) For the sake of encouraging interoperability do we recommend or
>     mandate
>     that a subset of these algorithms be supported?
> 
>     3) Do we allow implementation-defined algorithms beyond those which we
>     have assigned identifiers to?
> 
> 
> I am happy that we do, BUT that would fall into the category of an 
> extension which implies a different conformance level.  Either that or 
> disallow it.
> 
> Regards
> Bob
>  
> 
> 
>     But remember, there is nothing in the standard that mandates the support
>     of the document encryption feature at all, so #2 doesn't really help us
>     much here, does it?
> 
>     -Rob
> 
> 
> 
> 
>     From:
>     Bob Jolliffe <bobjolliffe@gmail.com <mailto:bobjolliffe@gmail.com>>
>     To:
>     Ming Fei Jia <jiamingf@cn.ibm.com <mailto:jiamingf@cn.ibm.com>>
>     Cc:
>     office@lists.oasis-open.org <mailto:office@lists.oasis-open.org>
>     Date:
>     09/01/2009 12:39 PM
>     Subject:
>     Re: [office] Re: encryption
> 
> 
> 
>     Thanks Ming Fei.  You summarized my concerns much better than I ..
> 
>     What was the original intent in specifying SHA1 and Blowfish?  It
>     seems to
>     me, though I wasn't around at the time, that the idea was primarily to
>     ensure interoperability, perhaps above other plausible goals.  The
>     selection of a widely available public domain cipher seems to reinforce
>     that interpretation.
> 
>     The casualty of interoperability here was choice.  There was no choice.
>     By allowing documented algorithms (as per xmlenc-core) we open the
>     window
>     of choice slightly whilst maintaining some hope of interoperability.
>      This
>     seems like it might be a good thing.
> 
>     By opening up the third option (implementation defined algorithms) we
>     maximize the choice but, as Ming Fei says, we risk the standard
>     having no
>     meaning or relevance regarding encryption.  This might be reasonable
>     tradeoff under some conditions.  In the case of hashed passwords
>     there is
>     use case of conversion of legacy documents (which I'm still not that
>     comfiortable with).  In the case of encrypted XML streams I don't think
>     the same argument applies.
> 
>     Is this perhaps yet another case for discrimination on the grounds of
>     conformance class, where the use of an implementation defined
>     algorithm is
>     not disbarred, but it is treated essentially as an extension
>     conforming to
>     a different, less strict, class of document?
> 
>     Regards
>     Bob
> 
>     2009/9/1 Ming Fei Jia <jiamingf@cn.ibm.com <mailto:jiamingf@cn.ibm.com>>
>     In the proposal:
>     The defined value for the "algorithm" attribute is 3 options:
>     ? The Blowfish algorithm in CFB mode.
>     ? An IRI defined in 5.2 or 5.3 of [xmlenc-core]: The algorithm
>     specified
>     in 5.2 or 5.3 of [xmlenc-core] for this IRI.
>     ? An IRI specifying an implementation defined algorithm.
>     ----------------
>     Actually I think the proposal means ODF has no restriction for
>     encryption
>     algorithm and ODF encryption algorithm could be anything. Then, does the
>     standard have meaning here? Of course, that is OK if there is some
>     exception that everyone believes:
>     (1)Encryption algorithm does not have any interoperability issue in
>     reality;
>     (2)Encryption algorithm will have no interoperability issue in the
>     future
>     (3)Implementation defined algorithm is not conforming to ODF
>     (4)Standard here can not solve problems at all even the issues are
>     there.
>     or anything else?
> 
>     We could have some trade-off for the real complexity, but I suggest
>     to be
>     careful to evaluate this extending. thanks a lot.
>     Best Regards,
> 
>     Mingfei Jia(???)
>     IBM Lotus Symphony Development
>     IBM China Software Development LAB, Beijing
>     Tel: 86-10-82452493 Fax: 86-10-82452887
>     NOTES:Ming Fei Jia/China/IBM E-mail: jiamingf@cn.ibm.com
>     <mailto:jiamingf@cn.ibm.com>
>     Address: No.28 Building, Zhong Guan Cun Software Park, No.8 Dong Bei
>     Wang
>     West Road, ShangDi, Haidian District, Beijing 100193, P.R.China
> 
>     Bob Jolliffe ---2009-08-31 22:46:31---In addition - I don't know the
>     answer to this, but in the interest of uniformity, is there also an IRI
>     which can used to indica
> 
> 
>     From:
> 
> 
>     Bob Jolliffe <bobjolliffe@gmail.com <mailto:bobjolliffe@gmail.com>>
> 
>     To:
> 
>     office@lists.oasis-open.org <mailto:office@lists.oasis-open.org>
> 
> 
>     Date:
> 
>     2009-08-31 22:46
> 
> 
>     Subject:
> 
>     [office] Re: encryption
> 
> 
> 
> 
> 
>     In addition - I don't know the answer to this, but in the interest of
>     uniformity, is there also an IRI which can used to indicate blowfish?
>     Then we are clear the value of the attribute is an IRI.
> 
>     2009/8/31 Bob Jolliffe <bobjolliffe@gmail.com
>     <mailto:bobjolliffe@gmail.com>>
>     what I was trying to say on the call is that we now have 3 options for
>     each algorithm, including a catchall "implementation defined" IRI.  I
>     would prefer to see this last option allowed but not recommended.
> 
>     Regards
>     Bob
> 
> 
> 
> 
> 
>     ---------------------------------------------------------------------
>     To unsubscribe from this mail list, you must leave the OASIS TC that
>     generates this mail.  Follow this link to all your TCs in OASIS at:
>     https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 
> 


-- 
Michael Brauer, Technical Architect Software Engineering
StarOffice/OpenOffice.org
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500
http://blogs.sun.com/GullFOSS

Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
	   D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin Haering


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]