OASIS Open Document Format for Office Applications (OpenDocument) TC

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

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

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 


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 

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,


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 


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 

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




From:
Bob Jolliffe 

2009/9/1 Robert Weir/Cambridge/IBM <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.

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>

To:

Ming Fei Jia <jiamingf@cn.ibm.com>

Cc:

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>

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


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

Hi Bob,

On 09/02/09 11:42, Bob Jolliffe wrote:
> 2009/9/1 Robert Weir/Cambridge/IBM 

Bob Jolliffe 

I think this is a good approach.  Even though it is an extended use, we
prescribe the manner of the extension so there is no weakening of the
most-interoperable level.

We need to make sure this differentiation is incorporated into the
conformance language of Part 3.

The nice thing about this scheme is that it makes it easy to add URIs that
turn out to be important to the defined recognized set in future revisions,
with minimal specification updating.

It is also a scheme that an interop profile for some community of use could
recognize in advance of the wheels of standards revision.

 - Dennis 



                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
From: Robert Weir/Cambridge/IBM [mailto:robert_weir@us.ibm.com] 
Sent: Wednesday, September 02, 2009 04:58
To: office@lists.oasis-open.org
Subject: Re: [office] Re: encryption

Bob Jolliffe 

2009/9/1 Bob Jolliffe 

Hi Bob,

On 08/31/09 16:45, Bob Jolliffe wrote:
> 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.

I don't think there is an IRI defined for blowfish, but it seems to be a 
good idea to define one. To provide backward compatibility we anyway 
would have to support the old non-IRI values, but we may deprecate them 
later if we define an IRI now.

Thank you for your feedback.

Michael
> 
> 2009/8/31 Bob Jolliffe