[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] Re: encryption
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.
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?
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
Ming Fei Jia <jiamingf@cn.ibm.com>Cc:
09/01/2009 12:39 PM
Subject:
Re: [office] Re: encryption
Mingfei Jia(???)
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>
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,
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
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>
To:
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>
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]