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

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?


2009/9/1 Ming Fei Jia <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
    Address: No.28 Building, Zhong Guan Cun Software Park, No.8 Dong Bei Wang West Road, ShangDi, Haidian District, Beijing 100193, P.R.China

Inactive hide details for Bob Jolliffe ---2009-08-31 22:46:31---In addition - I don't know the answer to this, but in the interBob 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


Bob Jolliffe <bobjolliffe@gmail.com>




2009-08-31 22:46


[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>
    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.



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