You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Rob Weir <ro...@apache.org> on 2011/08/31 15:03:58 UTC
Request dev help: Info for required crypto export declaration
There is some paperwork we need to file based on OOo use of
cryptography. Details are on the Apache website [1]. I think I can
handle most of the paperwork, provided I can get some help, on this
thread, establishing the basic facts.
1) Was something similar every done for OpenOffice.org? Most software
companies are aware of this US export regulation and do this
declaration as a matter of routine. But not all open source projects
are as diligent as ASF is. So it is possible that OOo never did this
before. But if they did, we could reuse much of their paperwork.
2) We need a list of all uses of cryptographic methods in OOo,
including code that we include, but also where we enable 3rd party or
OS crypto modules to plugged in. This includes both symmetrical
algorithms (commonly used for encryption) as well as asymmetrical
algorithms (for example, public key uses like PGP, RSA, TLS, etc.)
3) For each method, it looks like we need to state whether we authored
the crypto, or name the origin of the code if it is a 3rd party.
The methods I suspect are in OOo are:
a) For password-protected ODF documents, we use the Blowfish block
encryption method. Where did that code come from?
b) What do we support for other document formats, such as DOC, OOXML
or legacy StarOffice formats? Any other encryption methods? If so,
what are they are what was their origin?
c) We support digital signatures with ODF files as well. What
algorithms are supported? Is this our original code or 3rd party?
d) Do we support digital signatures with any other file formats?
e) Any other uses of encryption?
f) Presumably we places that are at least enabled for SSL via OS-level
resolution of https protocol URLs. Is this correct?
g) But do we have any SSL (TLS) code included in our source code? If
so, what is the origin of this?
4) In general, are there any other areas of AOOo where we include or
enable the use of cryptographic methods?
[1]: http://www.apache.org/dev/crypto.html
Re: Request dev help: Info for required crypto export declaration
Posted by Rob Weir <ro...@apache.org>.
On Fri, Sep 2, 2011 at 2:00 PM, Donald Whytock <dw...@gmail.com> wrote:
> On Fri, Sep 2, 2011 at 11:25 AM, Rob Weir <ro...@apache.org> wrote:
>> I'd rather not file false information with the government. Of course,
>> you are welcome to do so, if you think the need is urgent.
>
> Can I cite that in my next indictment?
>
Consider it to be under ALv2 ;-)
And just thinking, if anyone is very concerned about this, another
option is to restrict ooo/trunk to committers only until this is
resolved. In other words, password protect that subtree.
> Don
>
Re: Request dev help: Info for required crypto export declaration
Posted by Donald Whytock <dw...@gmail.com>.
On Fri, Sep 2, 2011 at 11:25 AM, Rob Weir <ro...@apache.org> wrote:
> I'd rather not file false information with the government. Of course,
> you are welcome to do so, if you think the need is urgent.
Can I cite that in my next indictment?
Don
Re: Request dev help: Info for required crypto export declaration
Posted by Rob Weir <ro...@apache.org>.
On Fri, Sep 2, 2011 at 11:55 AM, Dennis E. Hamilton
<de...@acm.org> wrote:
> How about we worry about the downstream cases when there are any to worry about. We are not close to a release.
>
> The code is *now* on the SVN. Isn't there some in-scope case that can be covered it being there where people can lift it and do whatever they want with it?
>
> [OK, a shallow appraisal. But is the ODF Toolkit case much different, when those encryption implementations are committed?]
>
I've started a new thread on this at legal-discuss.
Maybe we can help them hurry things along if we all go over there and
post 4 or 5 messages saying that the code is already in SVN and they
should hurry up and do something, anything. On second, thought, let's
not do that. It really wouldn't help much at all.
> - Dennis
>
> -----Original Message-----
> From: Rob Weir [mailto:robweir@apache.org]
> Sent: Friday, September 02, 2011 08:26
> To: ooo-dev@incubator.apache.org
> Subject: Re: Request dev help: Info for required crypto export declaration
>
> On Fri, Sep 2, 2011 at 11:12 AM, Dennis E. Hamilton
> <de...@acm.org> wrote:
>> We're already behind the 8-ball on having not done this when it was expected. I suggest that the established procedure be followed so that the ASF requirement is satisfied, the XML files are updated, etc.
>>
>
> It is not clear to me that ECCN 5D992 follows the same procedures as
> 5D002, at least from the EAR perspective. Since I see no other Apache
> software classified as 5D992, it is also not clear to me that the same
> Apache procedures would apply.
>
> The Apache notifications are based on the exemption in EAR 740.13(e).
> But Mass Market software is covered by 740.13(d). This does not have
> the same reporting requirement as 740.13(e). But it appears to have a
> different requirement. Still trying to figure that out.
>
> http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfr&sid=ba2d5996d28cc22033ea2bfb857555cc&rgn=div5&view=text&node=15:2.1.3.4.25&idno=15#15:2.1.3.4.25.0.1.13
>
>> Then we can worry about whether there needs to be some expansion of scope or other adjustment.
>>
>
> I'd rather not file false information with the government. Of course,
> you are welcome to do so, if you think the need is urgent.
>
>
> -Rob
>
>> Perhaps legal-discuss@ or general-incubator is a place to take that additional concern?
>>
>> - Dennis
>>
>> PS: I suspect that notices in the released implementations would be appropriate, considering responsibilities that users of the software may also have in the jurisdiction where usage is occuring. But I think that we need to acquit ourselves of the fact that the various OO.o employment of cryptographic methodologies are now in source-code form on the Apache SVN.
>>
>> -----Original Message-----
>> From: Rob Weir [mailto:robweir@apache.org]
>> Sent: Friday, September 02, 2011 08:01
>> To: ooo-dev@incubator.apache.org
>> Subject: Re: Request dev help: Info for required crypto export declaration
>>
>> Starting fresh. The more I look into this the more I'm starting to
>> think that the Apache export control instructions [1] are leading us
>> in the wrong direction.
>>
>> From what I've been able to determine, the classification code comes
>> not only from the strength of the encryption, but also the use of the
>> software. For example, strong encryption (based on key length) might
>> end up in different classifications depending on whether it is a
>> general purpose encryption library, a "mass market" product, a server
>> product, etc. It is not just about key length.
>>
>> The Apache instructions seem to say that all paths lead to 5D002.
>> Maybe this is true for strong encryption in the typical Apache
>> developer libraries or server-side products. But OpenOffice.org is
>> not your typical Apache product, is it?
>>
>> If you look at how commercial derivatives of OpenOffice.org are
>> treated, such as IBM Lotus Symphony or LibreOffice Novell Edition, you
>> see that they are classified as 5D992, not 5D002. But I do not see
>> 5D992 mentioned at all on the Apache page on handling cryptography.
>> Until we better understand that discrepancy, I don't think we should
>> blindly follow the 5D002 route.
>>
>> Is there anyone at Apache who really understands these things in a
>> more general way, e.g., understands the implications of "mass market"
>> software?
>>
>> -Rob
>>
>> [1] http://www.apache.org/dev/crypto.html
>>
>>
>
>
RE: Request dev help: Info for required crypto export declaration
Posted by "Dennis E. Hamilton" <de...@acm.org>.
How about we worry about the downstream cases when there are any to worry about. We are not close to a release.
The code is *now* on the SVN. Isn't there some in-scope case that can be covered it being there where people can lift it and do whatever they want with it?
[OK, a shallow appraisal. But is the ODF Toolkit case much different, when those encryption implementations are committed?]
- Dennis
-----Original Message-----
From: Rob Weir [mailto:robweir@apache.org]
Sent: Friday, September 02, 2011 08:26
To: ooo-dev@incubator.apache.org
Subject: Re: Request dev help: Info for required crypto export declaration
On Fri, Sep 2, 2011 at 11:12 AM, Dennis E. Hamilton
<de...@acm.org> wrote:
> We're already behind the 8-ball on having not done this when it was expected. I suggest that the established procedure be followed so that the ASF requirement is satisfied, the XML files are updated, etc.
>
It is not clear to me that ECCN 5D992 follows the same procedures as
5D002, at least from the EAR perspective. Since I see no other Apache
software classified as 5D992, it is also not clear to me that the same
Apache procedures would apply.
The Apache notifications are based on the exemption in EAR 740.13(e).
But Mass Market software is covered by 740.13(d). This does not have
the same reporting requirement as 740.13(e). But it appears to have a
different requirement. Still trying to figure that out.
http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfr&sid=ba2d5996d28cc22033ea2bfb857555cc&rgn=div5&view=text&node=15:2.1.3.4.25&idno=15#15:2.1.3.4.25.0.1.13
> Then we can worry about whether there needs to be some expansion of scope or other adjustment.
>
I'd rather not file false information with the government. Of course,
you are welcome to do so, if you think the need is urgent.
-Rob
> Perhaps legal-discuss@ or general-incubator is a place to take that additional concern?
>
> - Dennis
>
> PS: I suspect that notices in the released implementations would be appropriate, considering responsibilities that users of the software may also have in the jurisdiction where usage is occuring. But I think that we need to acquit ourselves of the fact that the various OO.o employment of cryptographic methodologies are now in source-code form on the Apache SVN.
>
> -----Original Message-----
> From: Rob Weir [mailto:robweir@apache.org]
> Sent: Friday, September 02, 2011 08:01
> To: ooo-dev@incubator.apache.org
> Subject: Re: Request dev help: Info for required crypto export declaration
>
> Starting fresh. The more I look into this the more I'm starting to
> think that the Apache export control instructions [1] are leading us
> in the wrong direction.
>
> From what I've been able to determine, the classification code comes
> not only from the strength of the encryption, but also the use of the
> software. For example, strong encryption (based on key length) might
> end up in different classifications depending on whether it is a
> general purpose encryption library, a "mass market" product, a server
> product, etc. It is not just about key length.
>
> The Apache instructions seem to say that all paths lead to 5D002.
> Maybe this is true for strong encryption in the typical Apache
> developer libraries or server-side products. But OpenOffice.org is
> not your typical Apache product, is it?
>
> If you look at how commercial derivatives of OpenOffice.org are
> treated, such as IBM Lotus Symphony or LibreOffice Novell Edition, you
> see that they are classified as 5D992, not 5D002. But I do not see
> 5D992 mentioned at all on the Apache page on handling cryptography.
> Until we better understand that discrepancy, I don't think we should
> blindly follow the 5D002 route.
>
> Is there anyone at Apache who really understands these things in a
> more general way, e.g., understands the implications of "mass market"
> software?
>
> -Rob
>
> [1] http://www.apache.org/dev/crypto.html
>
>
Re: Request dev help: Info for required crypto export declaration
Posted by Rob Weir <ro...@apache.org>.
On Fri, Sep 2, 2011 at 11:12 AM, Dennis E. Hamilton
<de...@acm.org> wrote:
> We're already behind the 8-ball on having not done this when it was expected. I suggest that the established procedure be followed so that the ASF requirement is satisfied, the XML files are updated, etc.
>
It is not clear to me that ECCN 5D992 follows the same procedures as
5D002, at least from the EAR perspective. Since I see no other Apache
software classified as 5D992, it is also not clear to me that the same
Apache procedures would apply.
The Apache notifications are based on the exemption in EAR 740.13(e).
But Mass Market software is covered by 740.13(d). This does not have
the same reporting requirement as 740.13(e). But it appears to have a
different requirement. Still trying to figure that out.
http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfr&sid=ba2d5996d28cc22033ea2bfb857555cc&rgn=div5&view=text&node=15:2.1.3.4.25&idno=15#15:2.1.3.4.25.0.1.13
> Then we can worry about whether there needs to be some expansion of scope or other adjustment.
>
I'd rather not file false information with the government. Of course,
you are welcome to do so, if you think the need is urgent.
-Rob
> Perhaps legal-discuss@ or general-incubator is a place to take that additional concern?
>
> - Dennis
>
> PS: I suspect that notices in the released implementations would be appropriate, considering responsibilities that users of the software may also have in the jurisdiction where usage is occuring. But I think that we need to acquit ourselves of the fact that the various OO.o employment of cryptographic methodologies are now in source-code form on the Apache SVN.
>
> -----Original Message-----
> From: Rob Weir [mailto:robweir@apache.org]
> Sent: Friday, September 02, 2011 08:01
> To: ooo-dev@incubator.apache.org
> Subject: Re: Request dev help: Info for required crypto export declaration
>
> Starting fresh. The more I look into this the more I'm starting to
> think that the Apache export control instructions [1] are leading us
> in the wrong direction.
>
> From what I've been able to determine, the classification code comes
> not only from the strength of the encryption, but also the use of the
> software. For example, strong encryption (based on key length) might
> end up in different classifications depending on whether it is a
> general purpose encryption library, a "mass market" product, a server
> product, etc. It is not just about key length.
>
> The Apache instructions seem to say that all paths lead to 5D002.
> Maybe this is true for strong encryption in the typical Apache
> developer libraries or server-side products. But OpenOffice.org is
> not your typical Apache product, is it?
>
> If you look at how commercial derivatives of OpenOffice.org are
> treated, such as IBM Lotus Symphony or LibreOffice Novell Edition, you
> see that they are classified as 5D992, not 5D002. But I do not see
> 5D992 mentioned at all on the Apache page on handling cryptography.
> Until we better understand that discrepancy, I don't think we should
> blindly follow the 5D002 route.
>
> Is there anyone at Apache who really understands these things in a
> more general way, e.g., understands the implications of "mass market"
> software?
>
> -Rob
>
> [1] http://www.apache.org/dev/crypto.html
>
>
RE: Request dev help: Info for required crypto export declaration
Posted by "Dennis E. Hamilton" <de...@acm.org>.
We're already behind the 8-ball on having not done this when it was expected. I suggest that the established procedure be followed so that the ASF requirement is satisfied, the XML files are updated, etc.
Then we can worry about whether there needs to be some expansion of scope or other adjustment.
Perhaps legal-discuss@ or general-incubator is a place to take that additional concern?
- Dennis
PS: I suspect that notices in the released implementations would be appropriate, considering responsibilities that users of the software may also have in the jurisdiction where usage is occuring. But I think that we need to acquit ourselves of the fact that the various OO.o employment of cryptographic methodologies are now in source-code form on the Apache SVN.
-----Original Message-----
From: Rob Weir [mailto:robweir@apache.org]
Sent: Friday, September 02, 2011 08:01
To: ooo-dev@incubator.apache.org
Subject: Re: Request dev help: Info for required crypto export declaration
Starting fresh. The more I look into this the more I'm starting to
think that the Apache export control instructions [1] are leading us
in the wrong direction.
>From what I've been able to determine, the classification code comes
not only from the strength of the encryption, but also the use of the
software. For example, strong encryption (based on key length) might
end up in different classifications depending on whether it is a
general purpose encryption library, a "mass market" product, a server
product, etc. It is not just about key length.
The Apache instructions seem to say that all paths lead to 5D002.
Maybe this is true for strong encryption in the typical Apache
developer libraries or server-side products. But OpenOffice.org is
not your typical Apache product, is it?
If you look at how commercial derivatives of OpenOffice.org are
treated, such as IBM Lotus Symphony or LibreOffice Novell Edition, you
see that they are classified as 5D992, not 5D002. But I do not see
5D992 mentioned at all on the Apache page on handling cryptography.
Until we better understand that discrepancy, I don't think we should
blindly follow the 5D002 route.
Is there anyone at Apache who really understands these things in a
more general way, e.g., understands the implications of "mass market"
software?
-Rob
[1] http://www.apache.org/dev/crypto.html
Re: Request dev help: Info for required crypto export declaration
Posted by Rob Weir <ro...@apache.org>.
Starting fresh. The more I look into this the more I'm starting to
think that the Apache export control instructions [1] are leading us
in the wrong direction.
>From what I've been able to determine, the classification code comes
not only from the strength of the encryption, but also the use of the
software. For example, strong encryption (based on key length) might
end up in different classifications depending on whether it is a
general purpose encryption library, a "mass market" product, a server
product, etc. It is not just about key length.
The Apache instructions seem to say that all paths lead to 5D002.
Maybe this is true for strong encryption in the typical Apache
developer libraries or server-side products. But OpenOffice.org is
not your typical Apache product, is it?
If you look at how commercial derivatives of OpenOffice.org are
treated, such as IBM Lotus Symphony or LibreOffice Novell Edition, you
see that they are classified as 5D992, not 5D002. But I do not see
5D992 mentioned at all on the Apache page on handling cryptography.
Until we better understand that discrepancy, I don't think we should
blindly follow the 5D002 route.
Is there anyone at Apache who really understands these things in a
more general way, e.g., understands the implications of "mass market"
software?
-Rob
[1] http://www.apache.org/dev/crypto.html
Re: Request dev help: Info for required crypto export declaration
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Fri, Sep 2, 2011 at 4:11 AM, Joe Schaefer <jo...@yahoo.com> wrote:
> Off-topic. Please drop this line of inquiry and
> return to the Subject of this thread, which is
> about determining required info for the crypto export
> declaration.
Which is collecting a list of sources [1] :-)
OOo uses strong crypto so the OOo source will be in there
One way to establish an initial source list is to go through OOo
dependencies, separate out the cryptography libraries then find source
URLs. This should be good enough to allow an initial notification to
be sent.
Robert
[1] http://www.apache.org/dev/crypto.html#sources
Re: Request dev help: Info for required crypto export declaration
Posted by Joe Schaefer <jo...@yahoo.com>.
Off-topic. Please drop this line of inquiry and
return to the Subject of this thread, which is
about determining required info for the crypto export
declaration.
>________________________________
>From: Rob Weir <ro...@apache.org>
>To: ooo-dev@incubator.apache.org
>Sent: Thursday, September 1, 2011 11:07 PM
>Subject: Re: Request dev help: Info for required crypto export declaration
>
>On Thu, Sep 1, 2011 at 10:55 PM, Norbert Thiebaud <nt...@gmail.com> wrote:
>> On Thu, Sep 1, 2011 at 8:57 PM, Rob Weir <ro...@apache.org> wrote:
>>> On Thu, Sep 1, 2011 at 9:38 PM, Norbert Thiebaud <nt...@gmail.com> wrote:
>>>> On Thu, Sep 1, 2011 at 11:15 AM, Rob Weir <ro...@robweir.com> wrote:
>>>>>
>>>>> Looks like LO discussed it briefly [4], but dismissed it under the
>>>>> misapprehension that since they are not in the US, the regulation is
>>>>> irrelevant.
>>>>
>>>> I'm confused, how is that a 'misapprehension' exactly ?
>>>>
>>>> Are you concerned about compliance with
>>>> http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000000801164&dateTexte=#LEGISCTA000006136109
>>>> ?
>>>>
>>>> if not, why not ? are you "under the misapprehension that since [you]
>>>> are not in [France], the regulation is irrelevant." ?
>>>>
>>>
>>> You should take a look at the Wassenaar convention. There is a lot
>>> more similarity than you might think between French and US
>>> requirements.
>>
>> You're missing the point. The point is: it makes a lot of sens of
>> Apache, being legally established in the US, to comply with the export
>> regulation of its host country...
>> but claiming that not paying attention to US regulation for a
>> non-US-based entity is a 'misapprehension' does not make much sens to
>> me. 'France' here was just a convenient example to illustrate the
>> fallacy of the argument. one could find hundreds of jurisdictions with
>> each their own hoops and quirks... most likely some of them
>> contradicting each others.
>>
>
>You should read my response to Dennis. I think you miss the entire
>point of why this paperwork is important. It has almost zero to do
>with where your webserver is. That is maybe 5% of the significance of
>the paperwork. If that is all you see, then you are missing most of
>the big picture. This is about making the software consumable for
>repackaging and redistribution by large hardware and software
>distributors, who -- like it or not -- tend to be American, not
>French. If you are thinking only of end users downloading the
>software from your LO webserver in Germany (or wherever it is), then
>you are missing the vast majority of the consumer, public sector,
>academic and enterprise markets.
>
>>> The diligence you do to satisfy US regulations will
>>> also help you with the regulations in any other countries you, or your
>>> users, need to work with.
>>
>> The French term that best describe this vision of the world is
>> 'nombrilism' (I'm afraid the english translation doesn't quite does it
>> justice.. too literal, doesn't carry the larger meaning, I think)
>>
>> Norbert
>>
>
>
>
Re: Request dev help: Info for required crypto export declaration
Posted by Rob Weir <ro...@apache.org>.
On Thu, Sep 1, 2011 at 10:55 PM, Norbert Thiebaud <nt...@gmail.com> wrote:
> On Thu, Sep 1, 2011 at 8:57 PM, Rob Weir <ro...@apache.org> wrote:
>> On Thu, Sep 1, 2011 at 9:38 PM, Norbert Thiebaud <nt...@gmail.com> wrote:
>>> On Thu, Sep 1, 2011 at 11:15 AM, Rob Weir <ro...@robweir.com> wrote:
>>>>
>>>> Looks like LO discussed it briefly [4], but dismissed it under the
>>>> misapprehension that since they are not in the US, the regulation is
>>>> irrelevant.
>>>
>>> I'm confused, how is that a 'misapprehension' exactly ?
>>>
>>> Are you concerned about compliance with
>>> http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000000801164&dateTexte=#LEGISCTA000006136109
>>> ?
>>>
>>> if not, why not ? are you "under the misapprehension that since [you]
>>> are not in [France], the regulation is irrelevant." ?
>>>
>>
>> You should take a look at the Wassenaar convention. There is a lot
>> more similarity than you might think between French and US
>> requirements.
>
> You're missing the point. The point is: it makes a lot of sens of
> Apache, being legally established in the US, to comply with the export
> regulation of its host country...
> but claiming that not paying attention to US regulation for a
> non-US-based entity is a 'misapprehension' does not make much sens to
> me. 'France' here was just a convenient example to illustrate the
> fallacy of the argument. one could find hundreds of jurisdictions with
> each their own hoops and quirks... most likely some of them
> contradicting each others.
>
You should read my response to Dennis. I think you miss the entire
point of why this paperwork is important. It has almost zero to do
with where your webserver is. That is maybe 5% of the significance of
the paperwork. If that is all you see, then you are missing most of
the big picture. This is about making the software consumable for
repackaging and redistribution by large hardware and software
distributors, who -- like it or not -- tend to be American, not
French. If you are thinking only of end users downloading the
software from your LO webserver in Germany (or wherever it is), then
you are missing the vast majority of the consumer, public sector,
academic and enterprise markets.
>> The diligence you do to satisfy US regulations will
>> also help you with the regulations in any other countries you, or your
>> users, need to work with.
>
> The French term that best describe this vision of the world is
> 'nombrilism' (I'm afraid the english translation doesn't quite does it
> justice.. too literal, doesn't carry the larger meaning, I think)
>
> Norbert
>
Re: Request dev help: Info for required crypto export declaration
Posted by Norbert Thiebaud <nt...@gmail.com>.
On Thu, Sep 1, 2011 at 8:57 PM, Rob Weir <ro...@apache.org> wrote:
> On Thu, Sep 1, 2011 at 9:38 PM, Norbert Thiebaud <nt...@gmail.com> wrote:
>> On Thu, Sep 1, 2011 at 11:15 AM, Rob Weir <ro...@robweir.com> wrote:
>>>
>>> Looks like LO discussed it briefly [4], but dismissed it under the
>>> misapprehension that since they are not in the US, the regulation is
>>> irrelevant.
>>
>> I'm confused, how is that a 'misapprehension' exactly ?
>>
>> Are you concerned about compliance with
>> http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000000801164&dateTexte=#LEGISCTA000006136109
>> ?
>>
>> if not, why not ? are you "under the misapprehension that since [you]
>> are not in [France], the regulation is irrelevant." ?
>>
>
> You should take a look at the Wassenaar convention. There is a lot
> more similarity than you might think between French and US
> requirements.
You're missing the point. The point is: it makes a lot of sens of
Apache, being legally established in the US, to comply with the export
regulation of its host country...
but claiming that not paying attention to US regulation for a
non-US-based entity is a 'misapprehension' does not make much sens to
me. 'France' here was just a convenient example to illustrate the
fallacy of the argument. one could find hundreds of jurisdictions with
each their own hoops and quirks... most likely some of them
contradicting each others.
> The diligence you do to satisfy US regulations will
> also help you with the regulations in any other countries you, or your
> users, need to work with.
The French term that best describe this vision of the world is
'nombrilism' (I'm afraid the english translation doesn't quite does it
justice.. too literal, doesn't carry the larger meaning, I think)
Norbert
Re: Request dev help: Info for required crypto export declaration
Posted by Rob Weir <ro...@apache.org>.
On Thu, Sep 1, 2011 at 9:38 PM, Norbert Thiebaud <nt...@gmail.com> wrote:
> On Thu, Sep 1, 2011 at 11:15 AM, Rob Weir <ro...@robweir.com> wrote:
>>
>> Looks like LO discussed it briefly [4], but dismissed it under the
>> misapprehension that since they are not in the US, the regulation is
>> irrelevant.
>
> I'm confused, how is that a 'misapprehension' exactly ?
>
> Are you concerned about compliance with
> http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000000801164&dateTexte=#LEGISCTA000006136109
> ?
>
> if not, why not ? are you "under the misapprehension that since [you]
> are not in [France], the regulation is irrelevant." ?
>
You should take a look at the Wassenaar convention. There is a lot
more similarity than you might think between French and US
requirements. The diligence you do to satisfy US regulations will
also help you with the regulations in any other countries you, or your
users, need to work with.
http://www.wassenaar.org/
> Norbert
>
Re: Request dev help: Info for required crypto export declaration
Posted by Rob Weir <ro...@apache.org>.
On Thu, Sep 1, 2011 at 10:18 PM, Dennis E. Hamilton
<de...@acm.org> wrote:
> I think Article 32 is of particular interest in the case of OpenOffice.org distributions in France.
>
> It would appear that compliance with Article 30 is not difficult, since source code is available in all cases. It would be interesting to find out if the Apache process for declaring cryptographic provisions would be acceptable to the Prime Minister without further ceremony. It might be useful for us to package notice of where the details are found in future distributions so users could be aware that local conditions may apply to their use of such provisions.
>
> However, I think it is likely that, so long as the LibreOffice download sites are not in the US there is not an issue for TDF. If there are LibreOffice mirrors in the US, that might be reason for concern by the operators of the mirrors. But we don't get to resolve any of that here.
>
> It is clear that to be an Apache Software Foundation project, the US requirements must be satisfied in the manner specified by the ASF.
>
But I think that misses the real value of having this paperwork clean
and readily available. It isn't really about OpenOffice or
LibreOffice end users. And it really isn't about Apache or The
Document Foundation. Yes, it is partially about them. But the real
point of doing this and doing it well, is to make it possible for
others (not Apache and not end users or direct downloads) to
distribute/export Apache code. It is to allow Apache modules to be
embedded in other applications and then exported. It is to allow
OpenOffice.org to be pre-installed on a hardware vendor's laptops and
then exported. Pure open source gets off easy in the regulation this
days. The government realizes that the code is out there and they
accept that. But commercial software vendors and hardware vendors
still feel the full weight of these regulations. Having open source
components that have their export control paperwork in order makes
their lives much easier, and helps the underlying open source software
get used more, which in turn may drive more corporate-sponsored
developers into the project, more opportunities for consultants, etc.
It is part of making OSS easy to consume. It is a win-win situation.
-Rob
> - Dennis
>
> -----Original Message-----
> From: Norbert Thiebaud [mailto:nthiebaud@gmail.com]
> Sent: Thursday, September 01, 2011 18:38
> To: ooo-dev@incubator.apache.org
> Subject: Re: Request dev help: Info for required crypto export declaration
>
> On Thu, Sep 1, 2011 at 11:15 AM, Rob Weir <ro...@robweir.com> wrote:
>>
>> Looks like LO discussed it briefly [4], but dismissed it under the
>> misapprehension that since they are not in the US, the regulation is
>> irrelevant.
>
> I'm confused, how is that a 'misapprehension' exactly ?
>
> Are you concerned about compliance with
> http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000000801164&dateTexte=#LEGISCTA000006136109
> ?
>
> if not, why not ? are you "under the misapprehension that since [you]
> are not in [France], the regulation is irrelevant." ?
>
> Norbert
>
>
RE: Request dev help: Info for required crypto export declaration
Posted by "Dennis E. Hamilton" <de...@acm.org>.
I think Article 32 is of particular interest in the case of OpenOffice.org distributions in France.
It would appear that compliance with Article 30 is not difficult, since source code is available in all cases. It would be interesting to find out if the Apache process for declaring cryptographic provisions would be acceptable to the Prime Minister without further ceremony. It might be useful for us to package notice of where the details are found in future distributions so users could be aware that local conditions may apply to their use of such provisions.
However, I think it is likely that, so long as the LibreOffice download sites are not in the US there is not an issue for TDF. If there are LibreOffice mirrors in the US, that might be reason for concern by the operators of the mirrors. But we don't get to resolve any of that here.
It is clear that to be an Apache Software Foundation project, the US requirements must be satisfied in the manner specified by the ASF.
- Dennis
-----Original Message-----
From: Norbert Thiebaud [mailto:nthiebaud@gmail.com]
Sent: Thursday, September 01, 2011 18:38
To: ooo-dev@incubator.apache.org
Subject: Re: Request dev help: Info for required crypto export declaration
On Thu, Sep 1, 2011 at 11:15 AM, Rob Weir <ro...@robweir.com> wrote:
>
> Looks like LO discussed it briefly [4], but dismissed it under the
> misapprehension that since they are not in the US, the regulation is
> irrelevant.
I'm confused, how is that a 'misapprehension' exactly ?
Are you concerned about compliance with
http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000000801164&dateTexte=#LEGISCTA000006136109
?
if not, why not ? are you "under the misapprehension that since [you]
are not in [France], the regulation is irrelevant." ?
Norbert
Re: Request dev help: Info for required crypto export declaration
Posted by Norbert Thiebaud <nt...@gmail.com>.
On Thu, Sep 1, 2011 at 11:15 AM, Rob Weir <ro...@robweir.com> wrote:
>
> Looks like LO discussed it briefly [4], but dismissed it under the
> misapprehension that since they are not in the US, the regulation is
> irrelevant.
I'm confused, how is that a 'misapprehension' exactly ?
Are you concerned about compliance with
http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000000801164&dateTexte=#LEGISCTA000006136109
?
if not, why not ? are you "under the misapprehension that since [you]
are not in [France], the regulation is irrelevant." ?
Norbert
Re: Request dev help: Info for required crypto export declaration
Posted by Rob Weir <ro...@apache.org>.
On Thu, Sep 1, 2011 at 2:38 PM, Dennis E. Hamilton
<de...@acm.org> wrote:
> Please just do it this way:
>
> <http://www.apache.org/dev/crypto.html>
>
That's what I've been looking at from the start. I don't just make
these things up in my sleep.
> ASF is very clear on what is required for *its* releases and this page appears to be comprehensive.
>
Yes, and for the very first step, we need to classify per an ECCN
code. To do that we need to understand the cryptographic support the
code provides.
I think we should try to understand this in detail, even if it just
boils down ultimately to a code for this regulation. These details
are also relevant to procurement regulations for the Federal
government, and other governments as well. So it will be good have a
comprehensive list of what algorithms we are using in general.
-Rob
> (I finally found where I saw this before. It has also been discussed here or on the ooo-private list before. I remembered it as being simpler than it is.)
>
> - Dennis
>
>
> -----Original Message-----
> From: rabastus@gmail.com [mailto:rabastus@gmail.com] On Behalf Of Rob Weir
> Sent: Thursday, September 01, 2011 09:15
> To: ooo-dev@incubator.apache.org
> Subject: Re: Request dev help: Info for required crypto export declaration
>
> On Thu, Sep 1, 2011 at 11:51 AM, Danese Cooper <da...@gmail.com> wrote:
>> On Wed, Aug 31, 2011 at 9:30 AM, Rob Weir <ro...@robweir.com> wrote:
>>
>>> On Wed, Aug 31, 2011 at 12:29 PM, Dennis E. Hamilton
>>> <de...@acm.org> wrote:
>>>
>>
>>
>>> <snip>
>>>
>>
>>
>>> >> 1) Was something similar every done for OpenOffice.org? Most software
>>> >> companies are aware of this US export regulation and do this
>>> >> declaration as a matter of routine. But not all open source projects
>>> >> are as diligent as ASF is. So it is possible that OOo never did this
>>> >> before. But if they did, we could reuse much of their paperwork.
>>> >
>>> > AFAIR Sun did that some time ago, but I'm not 100% sure.
>>>
>>
>> Yes, Sun did this (probably for every official "release").
>>
>
> If so, this might have been kept on the corporate side, not on the
> community website.
>
> For example, searching Google for "site:openoffice.org ECCN" shows
> several requests for this information [1] [2] [3] over the years, but
> no useful responses.
>
> Looks like LO discussed it briefly [4], but dismissed it under the
> misapprehension that since they are not in the US, the regulation is
> irrelevant. We'll obviously want to do better here. It may not make
> a much of a difference to the individual downloaded of AOOo, but this
> paperwork is essential for anyone who might want to bundle AOOo with
> laptops, for example. The location of the project is not the solitary
> relevant fact. The location of the users and re-distributors is the
> key thing.
>
> [1] http://openoffice.org/projects/www/lists/users/archive/2004-12/message/24
>
> [2] http://openoffice.org/projects/marketing/lists/dev/archive/2005-11/message/204
>
> [3] http://openoffice.org/projects/www/lists/users/archive/2009-12/message/653
>
> [4] http://comments.gmane.org/gmane.comp.documentfoundation.discuss/6138
>
> I'll check what we did for IBM Lotus Symphony.
>
> -Rob
>
>
>> Danese
>>
>
>
Re: Request dev help: Info for required crypto export declaration
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Thu, Sep 1, 2011 at 8:40 PM, Donald Whytock <dw...@gmail.com> wrote:
> On Thu, Sep 1, 2011 at 3:25 PM, Robert Burrell Donkin
> <ro...@gmail.com> wrote:
>> EAR 740.13(e) should be on
>> http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfr&sid=bad7a54a31430303e17ce648c13e51b3&rgn=div5&view=text&node=15:2.1.3.4.25&idno=15#15:2.1.3.4.25.0.1.13
>>
>> Robert
>>
>
> Thanks, Robert.
>
> IANAL, but on that page I see reference to the phrase "publicly
> available encryption source code". ASF, by charter, is a repository
> of publicly available source code. If OOo is officially an ASF
> project, does that take it out of the category of a product for export
> and into the category of publicly available source code?
As our source is publicly available, the TSU exception applies [1]
Robert
[1] http://www.apache.org/dev/crypto.html
Re: Request dev help: Info for required crypto export declaration
Posted by Donald Whytock <dw...@gmail.com>.
On Thu, Sep 1, 2011 at 3:25 PM, Robert Burrell Donkin
<ro...@gmail.com> wrote:
> EAR 740.13(e) should be on
> http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfr&sid=bad7a54a31430303e17ce648c13e51b3&rgn=div5&view=text&node=15:2.1.3.4.25&idno=15#15:2.1.3.4.25.0.1.13
>
> Robert
>
Thanks, Robert.
IANAL, but on that page I see reference to the phrase "publicly
available encryption source code". ASF, by charter, is a repository
of publicly available source code. If OOo is officially an ASF
project, does that take it out of the category of a product for export
and into the category of publicly available source code?
Don
Re: Request dev help: Info for required crypto export declaration
Posted by Rob Weir <ro...@robweir.com>.
On Thu, Sep 1, 2011 at 4:11 PM, Dennis E. Hamilton
<de...@acm.org> wrote:
> I'm not aware of any "legacy encryption" in non-ODF formats being supported on output or input. I must try that.
>
> Rob,
>
> Is it your understanding that http is implemented directly in OpenOffice, or is the platform provider of http: and https: schemes relied upon? I would be amazed to learn that OpenOffice.org deals with SSL certifications, but I guess I should be prepared for anything.
>
It is still declarable even if we are simply enabled for using a 3rd
party service. So, for example, if we make calls into an OS-level URL
protocol handler that negotiates SSL for https URL's, then that would
count. That is my reading of it.
> - Dennis
>
> -----Original Message-----
> From: Rob Weir [mailto:robweir@apache.org]
> Sent: Thursday, September 01, 2011 12:32
> To: ooo-dev@incubator.apache.org
> Subject: Re: Request dev help: Info for required crypto export declaration
>
> So in general OpenOffice supports encryption and digital signatures
> and https/SSL. So we have support for standard algorithms, from
> one-way hashes like SHA-1, to block encryption like Blowfish and
> AES-256, to public key cryptography per the W3C's XML Digital
> Signatures. We also support legacy Microsoft Office encryption
> algorithms that are generally weaker and used only for backwards
> compatibility.
>
> I'm not a crypto expert, so I'm not sure what something exotic would
> look like. I think the strongest thing we have is AES-256.
>
> -Rob
>
> On Thu, Sep 1, 2011 at 3:25 PM, Robert Burrell Donkin
> <ro...@gmail.com> wrote:
>> On Thu, Sep 1, 2011 at 8:18 PM, Donald Whytock <dw...@gmail.com> wrote:
>>> On Thu, Sep 1, 2011 at 3:00 PM, Rob Weir <ro...@robweir.com> wrote:
>>>> On Thu, Sep 1, 2011 at 2:51 PM, Robert Burrell Donkin
>>>> <ro...@gmail.com> wrote:
>>>>> Following the instructions[3], step 1 is to work out whether OOo has
>>>>> any unusual cryptography beyond ECCN 5D002, which is:
>>>>>
>>>>> <blockquote cite='http://www.apache.org/dev/crypto.html#classify>
>>>>> Software specially designed or modified for the development,
>>>>> production or use of any of the other software of this list, or
>>>>> software designed to certify other software on this list; or
>>>>> Software using a "symmetric algorithm" employing a key length in
>>>>> excess of 56-bits; or
>>>>> Software using an "asymmetric algorithm" where the security of the
>>>>> algorithm is based on: factorization of integers in excess of 512 bits
>>>>> (e.g., RSA), computation of discrete logarithms in a multiplicative
>>>>> group of a finite field of size greater than 512 bits (e.g.,
>>>>> Diffie-Hellman over Z/pZ), or other discrete logarithms in a group in
>>>>> excess of 112 bits (e.g., Diffie-Hellman over an elliptic curve).
>>>>> </blockquote>
>>>>>
>>>>> Does OOo rely on cryptography more exotic than this?
>>>>>
>>>>
>>>> That is where it seems backwards to me. If I'm reading this
>>>> correctly, we are OK if we use a symmetrical algorithm with key length
>>>> greater than ("in excess of") 56-bits. But if we use an algorithm,
>>>> with less thanb 56-bits we're considered exotic? Really?
>>>>
>>>> For example, Calc has a ROT13() spreadsheet function, which
>>>> undoubtedly is a weak symmetrical encryption technique, certainly not
>>>> one with a key length in excess of 56-bits.
>>>>
>>>> So what now? In other words, I'm puzzled by the "in excess" part.
>>>> They seem to be saying that strong encryption is regulated less than
>>>> weak encryption.
>>>>
>>>> Could you explain where I'm getting this wrong?
>>>
>>>
>>> It looks to me like the key phrase is "any unusual cryptography beyond
>>> ECCN 5D002", and the definition of that phrase is the cited block, as
>>> opposed to the cited block being a definition of ECCN 5D002.
>>>
>>> I am having a remarkably hard time finding a definition of ECCN 5D002.
>>
>> EAR 740.13(e) should be on
>> http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfr&sid=bad7a54a31430303e17ce648c13e51b3&rgn=div5&view=text&node=15:2.1.3.4.25&idno=15#15:2.1.3.4.25.0.1.13
>>
>> Robert
>>
>
>
RE: Request dev help: Info for required crypto export declaration
Posted by "Dennis E. Hamilton" <de...@acm.org>.
Update. By golly, OpenOffice.org from 2.4.1 through OOo-Dev 3.4.0 will read (and unlock) .doc files that are encrypted with the Microsoft Office 97/2000 procedure. OO.o 2.4.1 will not produce such .doc files, but OOo-Dev 3.4.0 and LibreOffice 3.3.3 will.
The only case supported in and out is the Microsoft Office 97/2000 method. It appears that none of the better choices in Office 2003 (Base, Strict, and a variety RC4-oriented ones, all with specifiable key size) are supported. I didn't try the ancient XOR method to see if that would be ingested by any OO.o implementations.
More for the list of places to identify in the code.
- Dennis
-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]
Sent: Thursday, September 01, 2011 13:12
To: ooo-dev@incubator.apache.org
Subject: RE: Request dev help: Info for required crypto export declaration
I'm not aware of any "legacy encryption" in non-ODF formats being supported on output or input. I must try that.
Rob,
Is it your understanding that http is implemented directly in OpenOffice, or is the platform provider of http: and https: schemes relied upon? I would be amazed to learn that OpenOffice.org deals with SSL certifications, but I guess I should be prepared for anything.
- Dennis
-----Original Message-----
From: Rob Weir [mailto:robweir@apache.org]
Sent: Thursday, September 01, 2011 12:32
To: ooo-dev@incubator.apache.org
Subject: Re: Request dev help: Info for required crypto export declaration
So in general OpenOffice supports encryption and digital signatures
and https/SSL. So we have support for standard algorithms, from
one-way hashes like SHA-1, to block encryption like Blowfish and
AES-256, to public key cryptography per the W3C's XML Digital
Signatures. We also support legacy Microsoft Office encryption
algorithms that are generally weaker and used only for backwards
compatibility.
I'm not a crypto expert, so I'm not sure what something exotic would
look like. I think the strongest thing we have is AES-256.
-Rob
On Thu, Sep 1, 2011 at 3:25 PM, Robert Burrell Donkin
<ro...@gmail.com> wrote:
> On Thu, Sep 1, 2011 at 8:18 PM, Donald Whytock <dw...@gmail.com> wrote:
>> On Thu, Sep 1, 2011 at 3:00 PM, Rob Weir <ro...@robweir.com> wrote:
>>> On Thu, Sep 1, 2011 at 2:51 PM, Robert Burrell Donkin
>>> <ro...@gmail.com> wrote:
>>>> Following the instructions[3], step 1 is to work out whether OOo has
>>>> any unusual cryptography beyond ECCN 5D002, which is:
>>>>
>>>> <blockquote cite='http://www.apache.org/dev/crypto.html#classify>
>>>> Software specially designed or modified for the development,
>>>> production or use of any of the other software of this list, or
>>>> software designed to certify other software on this list; or
>>>> Software using a "symmetric algorithm" employing a key length in
>>>> excess of 56-bits; or
>>>> Software using an "asymmetric algorithm" where the security of the
>>>> algorithm is based on: factorization of integers in excess of 512 bits
>>>> (e.g., RSA), computation of discrete logarithms in a multiplicative
>>>> group of a finite field of size greater than 512 bits (e.g.,
>>>> Diffie-Hellman over Z/pZ), or other discrete logarithms in a group in
>>>> excess of 112 bits (e.g., Diffie-Hellman over an elliptic curve).
>>>> </blockquote>
>>>>
>>>> Does OOo rely on cryptography more exotic than this?
>>>>
>>>
>>> That is where it seems backwards to me. If I'm reading this
>>> correctly, we are OK if we use a symmetrical algorithm with key length
>>> greater than ("in excess of") 56-bits. But if we use an algorithm,
>>> with less thanb 56-bits we're considered exotic? Really?
>>>
>>> For example, Calc has a ROT13() spreadsheet function, which
>>> undoubtedly is a weak symmetrical encryption technique, certainly not
>>> one with a key length in excess of 56-bits.
>>>
>>> So what now? In other words, I'm puzzled by the "in excess" part.
>>> They seem to be saying that strong encryption is regulated less than
>>> weak encryption.
>>>
>>> Could you explain where I'm getting this wrong?
>>
>>
>> It looks to me like the key phrase is "any unusual cryptography beyond
>> ECCN 5D002", and the definition of that phrase is the cited block, as
>> opposed to the cited block being a definition of ECCN 5D002.
>>
>> I am having a remarkably hard time finding a definition of ECCN 5D002.
>
> EAR 740.13(e) should be on
> http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfr&sid=bad7a54a31430303e17ce648c13e51b3&rgn=div5&view=text&node=15:2.1.3.4.25&idno=15#15:2.1.3.4.25.0.1.13
>
> Robert
>
RE: Request dev help: Info for required crypto export declaration
Posted by "Dennis E. Hamilton" <de...@acm.org>.
I'm not aware of any "legacy encryption" in non-ODF formats being supported on output or input. I must try that.
Rob,
Is it your understanding that http is implemented directly in OpenOffice, or is the platform provider of http: and https: schemes relied upon? I would be amazed to learn that OpenOffice.org deals with SSL certifications, but I guess I should be prepared for anything.
- Dennis
-----Original Message-----
From: Rob Weir [mailto:robweir@apache.org]
Sent: Thursday, September 01, 2011 12:32
To: ooo-dev@incubator.apache.org
Subject: Re: Request dev help: Info for required crypto export declaration
So in general OpenOffice supports encryption and digital signatures
and https/SSL. So we have support for standard algorithms, from
one-way hashes like SHA-1, to block encryption like Blowfish and
AES-256, to public key cryptography per the W3C's XML Digital
Signatures. We also support legacy Microsoft Office encryption
algorithms that are generally weaker and used only for backwards
compatibility.
I'm not a crypto expert, so I'm not sure what something exotic would
look like. I think the strongest thing we have is AES-256.
-Rob
On Thu, Sep 1, 2011 at 3:25 PM, Robert Burrell Donkin
<ro...@gmail.com> wrote:
> On Thu, Sep 1, 2011 at 8:18 PM, Donald Whytock <dw...@gmail.com> wrote:
>> On Thu, Sep 1, 2011 at 3:00 PM, Rob Weir <ro...@robweir.com> wrote:
>>> On Thu, Sep 1, 2011 at 2:51 PM, Robert Burrell Donkin
>>> <ro...@gmail.com> wrote:
>>>> Following the instructions[3], step 1 is to work out whether OOo has
>>>> any unusual cryptography beyond ECCN 5D002, which is:
>>>>
>>>> <blockquote cite='http://www.apache.org/dev/crypto.html#classify>
>>>> Software specially designed or modified for the development,
>>>> production or use of any of the other software of this list, or
>>>> software designed to certify other software on this list; or
>>>> Software using a "symmetric algorithm" employing a key length in
>>>> excess of 56-bits; or
>>>> Software using an "asymmetric algorithm" where the security of the
>>>> algorithm is based on: factorization of integers in excess of 512 bits
>>>> (e.g., RSA), computation of discrete logarithms in a multiplicative
>>>> group of a finite field of size greater than 512 bits (e.g.,
>>>> Diffie-Hellman over Z/pZ), or other discrete logarithms in a group in
>>>> excess of 112 bits (e.g., Diffie-Hellman over an elliptic curve).
>>>> </blockquote>
>>>>
>>>> Does OOo rely on cryptography more exotic than this?
>>>>
>>>
>>> That is where it seems backwards to me. If I'm reading this
>>> correctly, we are OK if we use a symmetrical algorithm with key length
>>> greater than ("in excess of") 56-bits. But if we use an algorithm,
>>> with less thanb 56-bits we're considered exotic? Really?
>>>
>>> For example, Calc has a ROT13() spreadsheet function, which
>>> undoubtedly is a weak symmetrical encryption technique, certainly not
>>> one with a key length in excess of 56-bits.
>>>
>>> So what now? In other words, I'm puzzled by the "in excess" part.
>>> They seem to be saying that strong encryption is regulated less than
>>> weak encryption.
>>>
>>> Could you explain where I'm getting this wrong?
>>
>>
>> It looks to me like the key phrase is "any unusual cryptography beyond
>> ECCN 5D002", and the definition of that phrase is the cited block, as
>> opposed to the cited block being a definition of ECCN 5D002.
>>
>> I am having a remarkably hard time finding a definition of ECCN 5D002.
>
> EAR 740.13(e) should be on
> http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfr&sid=bad7a54a31430303e17ce648c13e51b3&rgn=div5&view=text&node=15:2.1.3.4.25&idno=15#15:2.1.3.4.25.0.1.13
>
> Robert
>
Re: Request dev help: Info for required crypto export declaration
Posted by Rob Weir <ro...@apache.org>.
So in general OpenOffice supports encryption and digital signatures
and https/SSL. So we have support for standard algorithms, from
one-way hashes like SHA-1, to block encryption like Blowfish and
AES-256, to public key cryptography per the W3C's XML Digital
Signatures. We also support legacy Microsoft Office encryption
algorithms that are generally weaker and used only for backwards
compatibility.
I'm not a crypto expert, so I'm not sure what something exotic would
look like. I think the strongest thing we have is AES-256.
-Rob
On Thu, Sep 1, 2011 at 3:25 PM, Robert Burrell Donkin
<ro...@gmail.com> wrote:
> On Thu, Sep 1, 2011 at 8:18 PM, Donald Whytock <dw...@gmail.com> wrote:
>> On Thu, Sep 1, 2011 at 3:00 PM, Rob Weir <ro...@robweir.com> wrote:
>>> On Thu, Sep 1, 2011 at 2:51 PM, Robert Burrell Donkin
>>> <ro...@gmail.com> wrote:
>>>> Following the instructions[3], step 1 is to work out whether OOo has
>>>> any unusual cryptography beyond ECCN 5D002, which is:
>>>>
>>>> <blockquote cite='http://www.apache.org/dev/crypto.html#classify>
>>>> Software specially designed or modified for the development,
>>>> production or use of any of the other software of this list, or
>>>> software designed to certify other software on this list; or
>>>> Software using a "symmetric algorithm" employing a key length in
>>>> excess of 56-bits; or
>>>> Software using an "asymmetric algorithm" where the security of the
>>>> algorithm is based on: factorization of integers in excess of 512 bits
>>>> (e.g., RSA), computation of discrete logarithms in a multiplicative
>>>> group of a finite field of size greater than 512 bits (e.g.,
>>>> Diffie-Hellman over Z/pZ), or other discrete logarithms in a group in
>>>> excess of 112 bits (e.g., Diffie-Hellman over an elliptic curve).
>>>> </blockquote>
>>>>
>>>> Does OOo rely on cryptography more exotic than this?
>>>>
>>>
>>> That is where it seems backwards to me. If I'm reading this
>>> correctly, we are OK if we use a symmetrical algorithm with key length
>>> greater than ("in excess of") 56-bits. But if we use an algorithm,
>>> with less thanb 56-bits we're considered exotic? Really?
>>>
>>> For example, Calc has a ROT13() spreadsheet function, which
>>> undoubtedly is a weak symmetrical encryption technique, certainly not
>>> one with a key length in excess of 56-bits.
>>>
>>> So what now? In other words, I'm puzzled by the "in excess" part.
>>> They seem to be saying that strong encryption is regulated less than
>>> weak encryption.
>>>
>>> Could you explain where I'm getting this wrong?
>>
>>
>> It looks to me like the key phrase is "any unusual cryptography beyond
>> ECCN 5D002", and the definition of that phrase is the cited block, as
>> opposed to the cited block being a definition of ECCN 5D002.
>>
>> I am having a remarkably hard time finding a definition of ECCN 5D002.
>
> EAR 740.13(e) should be on
> http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfr&sid=bad7a54a31430303e17ce648c13e51b3&rgn=div5&view=text&node=15:2.1.3.4.25&idno=15#15:2.1.3.4.25.0.1.13
>
> Robert
>
Re: Request dev help: Info for required crypto export declaration
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Thu, Sep 1, 2011 at 8:18 PM, Donald Whytock <dw...@gmail.com> wrote:
> On Thu, Sep 1, 2011 at 3:00 PM, Rob Weir <ro...@robweir.com> wrote:
>> On Thu, Sep 1, 2011 at 2:51 PM, Robert Burrell Donkin
>> <ro...@gmail.com> wrote:
>>> Following the instructions[3], step 1 is to work out whether OOo has
>>> any unusual cryptography beyond ECCN 5D002, which is:
>>>
>>> <blockquote cite='http://www.apache.org/dev/crypto.html#classify>
>>> Software specially designed or modified for the development,
>>> production or use of any of the other software of this list, or
>>> software designed to certify other software on this list; or
>>> Software using a "symmetric algorithm" employing a key length in
>>> excess of 56-bits; or
>>> Software using an "asymmetric algorithm" where the security of the
>>> algorithm is based on: factorization of integers in excess of 512 bits
>>> (e.g., RSA), computation of discrete logarithms in a multiplicative
>>> group of a finite field of size greater than 512 bits (e.g.,
>>> Diffie-Hellman over Z/pZ), or other discrete logarithms in a group in
>>> excess of 112 bits (e.g., Diffie-Hellman over an elliptic curve).
>>> </blockquote>
>>>
>>> Does OOo rely on cryptography more exotic than this?
>>>
>>
>> That is where it seems backwards to me. If I'm reading this
>> correctly, we are OK if we use a symmetrical algorithm with key length
>> greater than ("in excess of") 56-bits. But if we use an algorithm,
>> with less thanb 56-bits we're considered exotic? Really?
>>
>> For example, Calc has a ROT13() spreadsheet function, which
>> undoubtedly is a weak symmetrical encryption technique, certainly not
>> one with a key length in excess of 56-bits.
>>
>> So what now? In other words, I'm puzzled by the "in excess" part.
>> They seem to be saying that strong encryption is regulated less than
>> weak encryption.
>>
>> Could you explain where I'm getting this wrong?
>
>
> It looks to me like the key phrase is "any unusual cryptography beyond
> ECCN 5D002", and the definition of that phrase is the cited block, as
> opposed to the cited block being a definition of ECCN 5D002.
>
> I am having a remarkably hard time finding a definition of ECCN 5D002.
EAR 740.13(e) should be on
http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfr&sid=bad7a54a31430303e17ce648c13e51b3&rgn=div5&view=text&node=15:2.1.3.4.25&idno=15#15:2.1.3.4.25.0.1.13
Robert
Re: Request dev help: Info for required crypto export declaration
Posted by Donald Whytock <dw...@gmail.com>.
On Thu, Sep 1, 2011 at 3:00 PM, Rob Weir <ro...@robweir.com> wrote:
> On Thu, Sep 1, 2011 at 2:51 PM, Robert Burrell Donkin
> <ro...@gmail.com> wrote:
>> Following the instructions[3], step 1 is to work out whether OOo has
>> any unusual cryptography beyond ECCN 5D002, which is:
>>
>> <blockquote cite='http://www.apache.org/dev/crypto.html#classify>
>> Software specially designed or modified for the development,
>> production or use of any of the other software of this list, or
>> software designed to certify other software on this list; or
>> Software using a "symmetric algorithm" employing a key length in
>> excess of 56-bits; or
>> Software using an "asymmetric algorithm" where the security of the
>> algorithm is based on: factorization of integers in excess of 512 bits
>> (e.g., RSA), computation of discrete logarithms in a multiplicative
>> group of a finite field of size greater than 512 bits (e.g.,
>> Diffie-Hellman over Z/pZ), or other discrete logarithms in a group in
>> excess of 112 bits (e.g., Diffie-Hellman over an elliptic curve).
>> </blockquote>
>>
>> Does OOo rely on cryptography more exotic than this?
>>
>
> That is where it seems backwards to me. If I'm reading this
> correctly, we are OK if we use a symmetrical algorithm with key length
> greater than ("in excess of") 56-bits. But if we use an algorithm,
> with less thanb 56-bits we're considered exotic? Really?
>
> For example, Calc has a ROT13() spreadsheet function, which
> undoubtedly is a weak symmetrical encryption technique, certainly not
> one with a key length in excess of 56-bits.
>
> So what now? In other words, I'm puzzled by the "in excess" part.
> They seem to be saying that strong encryption is regulated less than
> weak encryption.
>
> Could you explain where I'm getting this wrong?
It looks to me like the key phrase is "any unusual cryptography beyond
ECCN 5D002", and the definition of that phrase is the cited block, as
opposed to the cited block being a definition of ECCN 5D002.
I am having a remarkably hard time finding a definition of ECCN 5D002.
Don
RE: Request dev help: Info for required crypto export declaration
Posted by "Dennis E. Hamilton" <de...@acm.org>.
I am not making a judgment in the case of encryption used as part of digital-signature PKI-based methods. We need to identify them regardless.
I also don't know if those particular encryptions are done in OpenOffice.org code or are handled by the platforms at runtime. This might vary depending on the platform. We need to comprehend such variations for interoperability purposes as well.
- Dennis
-----Original Message-----
From: rabastus@gmail.com [mailto:rabastus@gmail.com] On Behalf Of Rob Weir
Sent: Thursday, September 01, 2011 13:03
To: ooo-dev@incubator.apache.org
Subject: Re: Request dev help: Info for required crypto export declaration
On Thu, Sep 1, 2011 at 3:59 PM, Dennis E. Hamilton
<de...@acm.org> wrote:
> Let me see if I can help ground this.
>
Remember, the export could be of code, not just the binaries. So if
we have code that does asymmetrical encryption, then we are exporting
that, even if in the binaries we call it only in the context of
digital signatures. Or not. That seems obvious to me, but IANAL
-Rob
> Currently, digest algorithms are used for a variety of things. The common case is SHA1. These are not themselves a concern, as I understand it, since their function is not directly related to encryption even though they come into play in the use of encryption methods.
>
> There is no support for *document* *encryption* via asymmetric keys. It is not specified in ODF and there is no way to do it in current implementations as far as I know.
>
> There is *password-based* *document* *encryption*. The current default procedure generates a 128-bit (symmetrical, of course) key via PBKDF2 using HMAC-SHA1 and encrypts using Blowfish with 8-bit CFB. There are provisions, for ODF 1.2, to generate wider keys and use PBKDF2 with "rng" methods other than HMAC-SHA1. Substitutes for PBKDF2 and Blowfish are allowed but I don't know the status of any implementation-dependent variations in OpenOffice.org. I believe there are extensions in the builds but they are not currently enabled in the standard distributions.
>
> There is support for digital signatures using PKI methodologies and those do, of course, use *asymmetric encryption* as part of the signature procedure. We need to catalog what those flavors are that are accepted and that are produced. Implementations are allowed considerable license in this area and we need to inventory the actual support in OpenOffice.org.
>
> It is not clear to me that the asymmetrical encryption used for digital signatures is a concern, but it is useful to have all of these methods profiled and catalogued concerning their implementation in OpenOffice.org. Comprehensive profiling of digital signature provisions is required to ensure interoperability in any case.
>
> I am not aware of any other cases. There are proposals for some modest but valuable modifications in ODF 1.3 and as possible implementation-dependent introductions in products supporting earlier versions of ODF. Any such implementations would need to be identified too, although none of those I am aware of introduce additional encryption algoritms.
>
> - Dennis
>
> -----Original Message-----
> From: Robert Burrell Donkin [mailto:robertburrelldonkin@gmail.com]
> Sent: Thursday, September 01, 2011 12:14
> To: ooo-dev@incubator.apache.org
> Subject: Re: Request dev help: Info for required crypto export declaration
>
> On Thu, Sep 1, 2011 at 8:00 PM, Rob Weir <ro...@robweir.com> wrote:
>> On Thu, Sep 1, 2011 at 2:51 PM, Robert Burrell Donkin
>> <ro...@gmail.com> wrote:
>>> On Thu, Sep 1, 2011 at 7:38 PM, Dennis E. Hamilton
>>> <de...@acm.org> wrote:
>>>> Please just do it this way:
>>>>
>>>> <http://www.apache.org/dev/crypto.html>
>>>>
>>>> ASF is very clear on what is required for *its* releases and this page appears to be comprehensive.
>>>
>>> The Apache rules break down into reporting to users and notification.
>>> Informing users is important but notification is urgent (making source
>>> available [1] counts as export).
>>>
>>>> (I finally found where I saw this before. It has also been discussed here or on the ooo-private list before. I remembered it as being simpler than it is.)
>>>
>>> (It looks worse than it is)
>>>
>>> Following the instructions[3], step 1 is to work out whether OOo has
>>> any unusual cryptography beyond ECCN 5D002, which is:
>>>
>>> <blockquote cite='http://www.apache.org/dev/crypto.html#classify>
>>> Software specially designed or modified for the development,
>>> production or use of any of the other software of this list, or
>>> software designed to certify other software on this list; or
>>> Software using a "symmetric algorithm" employing a key length in
>>> excess of 56-bits; or
>>> Software using an "asymmetric algorithm" where the security of the
>>> algorithm is based on: factorization of integers in excess of 512 bits
>>> (e.g., RSA), computation of discrete logarithms in a multiplicative
>>> group of a finite field of size greater than 512 bits (e.g.,
>>> Diffie-Hellman over Z/pZ), or other discrete logarithms in a group in
>>> excess of 112 bits (e.g., Diffie-Hellman over an elliptic curve).
>>> </blockquote>
>>>
>>> Does OOo rely on cryptography more exotic than this?
>>>
>>
>> That is where it seems backwards to me. If I'm reading this
>> correctly, we are OK if we use a symmetrical algorithm with key length
>> greater than ("in excess of") 56-bits. But if we use an algorithm,
>> with less thanb 56-bits we're considered exotic? Really?
>
> Remember that we're only interested in strong cryptography :-)
>
> IIRC symmetric and asymmetric algorithms weaker than this are not
> considered strong cryptography, and so don't fall under ECCN 5D002.
> Cryptography which is neither weak nor covered by those definitions
> needs special handling.
>
> Robert
>
>
Re: Request dev help: Info for required crypto export declaration
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Thu, Sep 1, 2011 at 9:03 PM, Rob Weir <ro...@robweir.com> wrote:
> On Thu, Sep 1, 2011 at 3:59 PM, Dennis E. Hamilton
> <de...@acm.org> wrote:
>> Let me see if I can help ground this.
>>
>
> Remember, the export could be of code, not just the binaries. So if
> we have code that does asymmetrical encryption, then we are exporting
> that, even if in the binaries we call it only in the context of
> digital signatures. Or not. That seems obvious to me, but IANAL
Also code intended to work with cryptography libraries (whether shipped or not)
Robert
Re: Request dev help: Info for required crypto export declaration
Posted by Rob Weir <ro...@robweir.com>.
On Thu, Sep 1, 2011 at 3:59 PM, Dennis E. Hamilton
<de...@acm.org> wrote:
> Let me see if I can help ground this.
>
Remember, the export could be of code, not just the binaries. So if
we have code that does asymmetrical encryption, then we are exporting
that, even if in the binaries we call it only in the context of
digital signatures. Or not. That seems obvious to me, but IANAL
-Rob
> Currently, digest algorithms are used for a variety of things. The common case is SHA1. These are not themselves a concern, as I understand it, since their function is not directly related to encryption even though they come into play in the use of encryption methods.
>
> There is no support for *document* *encryption* via asymmetric keys. It is not specified in ODF and there is no way to do it in current implementations as far as I know.
>
> There is *password-based* *document* *encryption*. The current default procedure generates a 128-bit (symmetrical, of course) key via PBKDF2 using HMAC-SHA1 and encrypts using Blowfish with 8-bit CFB. There are provisions, for ODF 1.2, to generate wider keys and use PBKDF2 with "rng" methods other than HMAC-SHA1. Substitutes for PBKDF2 and Blowfish are allowed but I don't know the status of any implementation-dependent variations in OpenOffice.org. I believe there are extensions in the builds but they are not currently enabled in the standard distributions.
>
> There is support for digital signatures using PKI methodologies and those do, of course, use *asymmetric encryption* as part of the signature procedure. We need to catalog what those flavors are that are accepted and that are produced. Implementations are allowed considerable license in this area and we need to inventory the actual support in OpenOffice.org.
>
> It is not clear to me that the asymmetrical encryption used for digital signatures is a concern, but it is useful to have all of these methods profiled and catalogued concerning their implementation in OpenOffice.org. Comprehensive profiling of digital signature provisions is required to ensure interoperability in any case.
>
> I am not aware of any other cases. There are proposals for some modest but valuable modifications in ODF 1.3 and as possible implementation-dependent introductions in products supporting earlier versions of ODF. Any such implementations would need to be identified too, although none of those I am aware of introduce additional encryption algoritms.
>
> - Dennis
>
> -----Original Message-----
> From: Robert Burrell Donkin [mailto:robertburrelldonkin@gmail.com]
> Sent: Thursday, September 01, 2011 12:14
> To: ooo-dev@incubator.apache.org
> Subject: Re: Request dev help: Info for required crypto export declaration
>
> On Thu, Sep 1, 2011 at 8:00 PM, Rob Weir <ro...@robweir.com> wrote:
>> On Thu, Sep 1, 2011 at 2:51 PM, Robert Burrell Donkin
>> <ro...@gmail.com> wrote:
>>> On Thu, Sep 1, 2011 at 7:38 PM, Dennis E. Hamilton
>>> <de...@acm.org> wrote:
>>>> Please just do it this way:
>>>>
>>>> <http://www.apache.org/dev/crypto.html>
>>>>
>>>> ASF is very clear on what is required for *its* releases and this page appears to be comprehensive.
>>>
>>> The Apache rules break down into reporting to users and notification.
>>> Informing users is important but notification is urgent (making source
>>> available [1] counts as export).
>>>
>>>> (I finally found where I saw this before. It has also been discussed here or on the ooo-private list before. I remembered it as being simpler than it is.)
>>>
>>> (It looks worse than it is)
>>>
>>> Following the instructions[3], step 1 is to work out whether OOo has
>>> any unusual cryptography beyond ECCN 5D002, which is:
>>>
>>> <blockquote cite='http://www.apache.org/dev/crypto.html#classify>
>>> Software specially designed or modified for the development,
>>> production or use of any of the other software of this list, or
>>> software designed to certify other software on this list; or
>>> Software using a "symmetric algorithm" employing a key length in
>>> excess of 56-bits; or
>>> Software using an "asymmetric algorithm" where the security of the
>>> algorithm is based on: factorization of integers in excess of 512 bits
>>> (e.g., RSA), computation of discrete logarithms in a multiplicative
>>> group of a finite field of size greater than 512 bits (e.g.,
>>> Diffie-Hellman over Z/pZ), or other discrete logarithms in a group in
>>> excess of 112 bits (e.g., Diffie-Hellman over an elliptic curve).
>>> </blockquote>
>>>
>>> Does OOo rely on cryptography more exotic than this?
>>>
>>
>> That is where it seems backwards to me. If I'm reading this
>> correctly, we are OK if we use a symmetrical algorithm with key length
>> greater than ("in excess of") 56-bits. But if we use an algorithm,
>> with less thanb 56-bits we're considered exotic? Really?
>
> Remember that we're only interested in strong cryptography :-)
>
> IIRC symmetric and asymmetric algorithms weaker than this are not
> considered strong cryptography, and so don't fall under ECCN 5D002.
> Cryptography which is neither weak nor covered by those definitions
> needs special handling.
>
> Robert
>
>
Re: Request dev help: Info for required crypto export declaration
Posted by Reizinger Zoltán <zr...@hdsnet.hu>.
2011.09.01. 21:59 keltezéssel, Dennis E. Hamilton írta:
> Let me see if I can help ground this.
>
> Currently, digest algorithms are used for a variety of things. The common case is SHA1. These are not themselves a concern, as I understand it, since their function is not directly related to encryption even though they come into play in the use of encryption methods.
>
> There is no support for *document* *encryption* via asymmetric keys. It is not specified in ODF and there is no way to do it in current implementations as far as I know.
>
> There is *password-based* *document* *encryption*. The current default procedure generates a 128-bit (symmetrical, of course) key via PBKDF2 using HMAC-SHA1 and encrypts using Blowfish with 8-bit CFB. There are provisions, for ODF 1.2, to generate wider keys and use PBKDF2 with "rng" methods other than HMAC-SHA1. Substitutes for PBKDF2 and Blowfish are allowed but I don't know the status of any implementation-dependent variations in OpenOffice.org. I believe there are extensions in the builds but they are not currently enabled in the standard distributions.
If I know correctly, the changes implemented to OOo 3.4 version.
See:
http://blogs.oracle.com/malte/entry/aes_encryption_for_openoffice_org
http://openoffice.org/projects/www/lists/allfeatures/archive/2011-03/message/2
Zoltan
>
> There is support for digital signatures using PKI methodologies and those do, of course, use *asymmetric encryption* as part of the signature procedure. We need to catalog what those flavors are that are accepted and that are produced. Implementations are allowed considerable license in this area and we need to inventory the actual support in OpenOffice.org.
>
> It is not clear to me that the asymmetrical encryption used for digital signatures is a concern, but it is useful to have all of these methods profiled and catalogued concerning their implementation in OpenOffice.org. Comprehensive profiling of digital signature provisions is required to ensure interoperability in any case.
>
> I am not aware of any other cases. There are proposals for some modest but valuable modifications in ODF 1.3 and as possible implementation-dependent introductions in products supporting earlier versions of ODF. Any such implementations would need to be identified too, although none of those I am aware of introduce additional encryption algoritms.
>
> - Dennis
>
> -----Original Message-----
> From: Robert Burrell Donkin [mailto:robertburrelldonkin@gmail.com]
> Sent: Thursday, September 01, 2011 12:14
> To: ooo-dev@incubator.apache.org
> Subject: Re: Request dev help: Info for required crypto export declaration
>
> On Thu, Sep 1, 2011 at 8:00 PM, Rob Weir<ro...@robweir.com> wrote:
>> On Thu, Sep 1, 2011 at 2:51 PM, Robert Burrell Donkin
>> <ro...@gmail.com> wrote:
>>> On Thu, Sep 1, 2011 at 7:38 PM, Dennis E. Hamilton
>>> <de...@acm.org> wrote:
>>>> Please just do it this way:
>>>>
>>>> <http://www.apache.org/dev/crypto.html>
>>>>
>>>> ASF is very clear on what is required for *its* releases and this page appears to be comprehensive.
>>> The Apache rules break down into reporting to users and notification.
>>> Informing users is important but notification is urgent (making source
>>> available [1] counts as export).
>>>
>>>> (I finally found where I saw this before. It has also been discussed here or on the ooo-private list before. I remembered it as being simpler than it is.)
>>> (It looks worse than it is)
>>>
>>> Following the instructions[3], step 1 is to work out whether OOo has
>>> any unusual cryptography beyond ECCN 5D002, which is:
>>>
>>> <blockquote cite='http://www.apache.org/dev/crypto.html#classify>
>>> Software specially designed or modified for the development,
>>> production or use of any of the other software of this list, or
>>> software designed to certify other software on this list; or
>>> Software using a "symmetric algorithm" employing a key length in
>>> excess of 56-bits; or
>>> Software using an "asymmetric algorithm" where the security of the
>>> algorithm is based on: factorization of integers in excess of 512 bits
>>> (e.g., RSA), computation of discrete logarithms in a multiplicative
>>> group of a finite field of size greater than 512 bits (e.g.,
>>> Diffie-Hellman over Z/pZ), or other discrete logarithms in a group in
>>> excess of 112 bits (e.g., Diffie-Hellman over an elliptic curve).
>>> </blockquote>
>>>
>>> Does OOo rely on cryptography more exotic than this?
>>>
>> That is where it seems backwards to me. If I'm reading this
>> correctly, we are OK if we use a symmetrical algorithm with key length
>> greater than ("in excess of") 56-bits. But if we use an algorithm,
>> with less thanb 56-bits we're considered exotic? Really?
> Remember that we're only interested in strong cryptography :-)
>
> IIRC symmetric and asymmetric algorithms weaker than this are not
> considered strong cryptography, and so don't fall under ECCN 5D002.
> Cryptography which is neither weak nor covered by those definitions
> needs special handling.
>
> Robert
>
>
RE: Request dev help: Info for required crypto export declaration
Posted by "Dennis E. Hamilton" <de...@acm.org>.
Thanks Michael,
That's very helpful.
Do those cover the password protection of Microsoft Office files too (something that is implemented, much to my surprise)? The supported case may be too weak to be of interest in this context. I don't know if stronger methods are in the code but not enabled or not.
In general, have format converters been checked?
- Dennis
PS: I love your signature message, below (even if it is not accurate!). I had the opportunity to see Haskell Curry and Alonzo Church at separate events several years ago (several = ~30).
-----Original Message-----
From: Michael Stahl [mailto:mst@openoffice.org]
Sent: Thursday, September 22, 2011 09:18
To: ooo-dev@incubator.apache.org
Subject: Re: Request dev help: Info for required crypto export declaration
[this mail has managed to hide in a draft folder for weeks...]
On 01.09.2011 23:01, Robert Burrell Donkin wrote:
> On Thu, Sep 1, 2011 at 9:35 PM, Dennis E. Hamilton
> <de...@acm.org> wrote:
>> Technically, this was to have been resolved before the code was put
>> up on SVN. We need to audit specifically for this rather quickly,
>> and including the places that Rob also identified (import-export
>> filters and http TLS)..
>
> I definitely recommend a full crypto audit but IIRC it's not
> necessary before sending the initial notification.
>
> AIUI (from [1] and [2]) all that's needed is a list of the
> cryptographic libraries used by OOo. If the results of the full
> audit differ then we can just update the details and send an updated
> notification.
looking through the external modules the following are obviously crypto
related:
xmlsec1-1.2.14.tar.gz
openssl-0.9.8o.tar.gz
nss-3.12.6-with-nspr-4.8.4.tar.gz
seamonkey-1.1.14.source.tar.gz
(Seamonkey also contains NSS but i guess we don't ship this but the one
from the "nss" module)
the internal implementation of Blowfish (and also RC4 it seems) is in
these files:
sal/inc/rtl/cipher.h
sal/rtl/source/cipher.c
hope that should get us started...
--
<sieni> State?
<sieni> There is no state :-)
<shapr> Haskell separates Church and state.
Re: Request dev help: Info for required crypto export declaration
Posted by Michael Stahl <ms...@openoffice.org>.
[this mail has managed to hide in a draft folder for weeks...]
On 01.09.2011 23:01, Robert Burrell Donkin wrote:
> On Thu, Sep 1, 2011 at 9:35 PM, Dennis E. Hamilton
> <de...@acm.org> wrote:
>> Technically, this was to have been resolved before the code was put
>> up on SVN. We need to audit specifically for this rather quickly,
>> and including the places that Rob also identified (import-export
>> filters and http TLS)..
>
> I definitely recommend a full crypto audit but IIRC it's not
> necessary before sending the initial notification.
>
> AIUI (from [1] and [2]) all that's needed is a list of the
> cryptographic libraries used by OOo. If the results of the full
> audit differ then we can just update the details and send an updated
> notification.
looking through the external modules the following are obviously crypto
related:
xmlsec1-1.2.14.tar.gz
openssl-0.9.8o.tar.gz
nss-3.12.6-with-nspr-4.8.4.tar.gz
seamonkey-1.1.14.source.tar.gz
(Seamonkey also contains NSS but i guess we don't ship this but the one
from the "nss" module)
the internal implementation of Blowfish (and also RC4 it seems) is in
these files:
sal/inc/rtl/cipher.h
sal/rtl/source/cipher.c
hope that should get us started...
--
<sieni> State?
<sieni> There is no state :-)
<shapr> Haskell separates Church and state.
Re: Request dev help: Info for required crypto export declaration
Posted by Rob Weir <ro...@apache.org>.
On Thu, Sep 1, 2011 at 7:01 PM, Dennis E. Hamilton
<de...@acm.org> wrote:
> From <http://www.apache.org/dev/crypto.html> top of page, Overview, second paragraph:
>
> "PMCs considering including cryptographic functionality within their products or specially designing their products to use other software with cryptographic functionality should take the following steps *before* placing such code on any ASF server, including commits to subversion" [*emphasis* mine]
>
> From <http://incubator.apache.org/guides/mentor.html#crypto-audit>
> "Before the code base is committed into an Apache repository, the contribution MUST be checked and any restricted cryptography reported appropriately."
>
Yup. We did this in the wrong order. Nothing we can do about that now.
I hope to get to this soon, but probably not until the weekend at
earliest. If you (or anyone else) have cycles earlier, feel free to
grab this task. I don't mean to be sitting on it if someone else can
act sooner.
-Rob
> -----Original Message-----
> From: Robert Burrell Donkin [mailto:robertburrelldonkin@gmail.com]
> Sent: Thursday, September 01, 2011 14:01
> To: ooo-dev@incubator.apache.org
> Subject: Re: Request dev help: Info for required crypto export declaration
>
> On Thu, Sep 1, 2011 at 9:35 PM, Dennis E. Hamilton
> <de...@acm.org> wrote:
>> Technically, this was to have been resolved before the code was put up on SVN. We need to audit specifically for this rather quickly, and including the places that Rob also identified (import-export filters and http TLS).
>
> I definitely recommend a full crypto audit but IIRC it's not necessary
> before sending the initial notification.
>
> AIUI (from [1] and [2]) all that's needed is a list of the
> cryptographic libraries used by OOo. If the results of the full audit
> differ then we can just update the details and send an updated
> notification.
>
> Robert
>
> [1] http://www.apache.org/dev/crypto.html#sources
> [2] http://www.apache.org/licenses/exports/
>
>
RE: Request dev help: Info for required crypto export declaration
Posted by "Dennis E. Hamilton" <de...@acm.org>.
>From <http://www.apache.org/dev/crypto.html> top of page, Overview, second paragraph:
"PMCs considering including cryptographic functionality within their products or specially designing their products to use other software with cryptographic functionality should take the following steps *before* placing such code on any ASF server, including commits to subversion" [*emphasis* mine]
>From <http://incubator.apache.org/guides/mentor.html#crypto-audit>
"Before the code base is committed into an Apache repository, the contribution MUST be checked and any restricted cryptography reported appropriately."
-----Original Message-----
From: Robert Burrell Donkin [mailto:robertburrelldonkin@gmail.com]
Sent: Thursday, September 01, 2011 14:01
To: ooo-dev@incubator.apache.org
Subject: Re: Request dev help: Info for required crypto export declaration
On Thu, Sep 1, 2011 at 9:35 PM, Dennis E. Hamilton
<de...@acm.org> wrote:
> Technically, this was to have been resolved before the code was put up on SVN. We need to audit specifically for this rather quickly, and including the places that Rob also identified (import-export filters and http TLS).
I definitely recommend a full crypto audit but IIRC it's not necessary
before sending the initial notification.
AIUI (from [1] and [2]) all that's needed is a list of the
cryptographic libraries used by OOo. If the results of the full audit
differ then we can just update the details and send an updated
notification.
Robert
[1] http://www.apache.org/dev/crypto.html#sources
[2] http://www.apache.org/licenses/exports/
Re: Request dev help: Info for required crypto export declaration
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Thu, Sep 1, 2011 at 9:35 PM, Dennis E. Hamilton
<de...@acm.org> wrote:
> Technically, this was to have been resolved before the code was put up on SVN. We need to audit specifically for this rather quickly, and including the places that Rob also identified (import-export filters and http TLS).
I definitely recommend a full crypto audit but IIRC it's not necessary
before sending the initial notification.
AIUI (from [1] and [2]) all that's needed is a list of the
cryptographic libraries used by OOo. If the results of the full audit
differ then we can just update the details and send an updated
notification.
Robert
[1] http://www.apache.org/dev/crypto.html#sources
[2] http://www.apache.org/licenses/exports/
RE: Request dev help: Info for required crypto export declaration
Posted by "Dennis E. Hamilton" <de...@acm.org>.
Technically, this was to have been resolved before the code was put up on SVN. We need to audit specifically for this rather quickly, and including the places that Rob also identified (import-export filters and http TLS).
- Dennis
-----Original Message-----
From: Robert Burrell Donkin [mailto:robertburrelldonkin@gmail.com]
Sent: Thursday, September 01, 2011 13:13
To: ooo-dev@incubator.apache.org; dennis.hamilton@acm.org
Subject: Re: Request dev help: Info for required crypto export declaration
[ ... ]
So far, looks like OOo most likely has strong crypto but it's all
fairly standard stuff. We should press forward with the notification
required by law whilst auditing the code.
Robert
Re: Request dev help: Info for required crypto export declaration
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Thu, Sep 1, 2011 at 8:59 PM, Dennis E. Hamilton
<de...@acm.org> wrote:
> Let me see if I can help ground this.
>
> Currently, digest algorithms are used for a variety of things. The common case is SHA1. These are not themselves a concern, as I understand it, since their function is not directly related to encryption even though they come into play in the use of encryption methods.
AIUI only encryption is of concern
> There is no support for *document* *encryption* via asymmetric keys. It is not specified in ODF and there is no way to do it in current implementations as far as I know.
Ok
> There is *password-based* *document* *encryption*. The current default procedure generates a 128-bit (symmetrical, of course) key via PBKDF2 using HMAC-SHA1 and encrypts using Blowfish with 8-bit CFB. There are provisions, for ODF 1.2, to generate wider keys and use PBKDF2 with "rng" methods other than HMAC-SHA1. Substitutes for PBKDF2 and Blowfish are allowed but I don't know the status of any implementation-dependent variations in OpenOffice.org. I believe there are extensions in the builds but they are not currently enabled in the standard distributions.
Sounds likely to be strong cryptography falling under 'Software using
a "symmetric algorithm" employing a key length in excess of 56-bits'
> There is support for digital signatures using PKI methodologies and those do, of course, use *asymmetric encryption* as part of the signature procedure. We need to catalog what those flavors are that are accepted and that are produced. Implementations are allowed considerable license in this area and we need to inventory the actual support in OpenOffice.org.
+1
> It is not clear to me that the asymmetrical encryption used for digital signatures is a concern, but it is useful to have all of these methods profiled and catalogued concerning their implementation in OpenOffice.org. Comprehensive profiling of digital signature provisions is required to ensure interoperability in any case.
+1
> I am not aware of any other cases. There are proposals for some modest but valuable modifications in ODF 1.3 and as possible implementation-dependent introductions in products supporting earlier versions of ODF. Any such implementations would need to be identified too, although none of those I am aware of introduce additional encryption algoritms.
So far, looks like OOo most likely has strong crypto but it's all
fairly standard stuff. We should press forward with the notification
required by law whilst auditing the code.
Robert
RE: Request dev help: Info for required crypto export declaration
Posted by "Dennis E. Hamilton" <de...@acm.org>.
Let me see if I can help ground this.
Currently, digest algorithms are used for a variety of things. The common case is SHA1. These are not themselves a concern, as I understand it, since their function is not directly related to encryption even though they come into play in the use of encryption methods.
There is no support for *document* *encryption* via asymmetric keys. It is not specified in ODF and there is no way to do it in current implementations as far as I know.
There is *password-based* *document* *encryption*. The current default procedure generates a 128-bit (symmetrical, of course) key via PBKDF2 using HMAC-SHA1 and encrypts using Blowfish with 8-bit CFB. There are provisions, for ODF 1.2, to generate wider keys and use PBKDF2 with "rng" methods other than HMAC-SHA1. Substitutes for PBKDF2 and Blowfish are allowed but I don't know the status of any implementation-dependent variations in OpenOffice.org. I believe there are extensions in the builds but they are not currently enabled in the standard distributions.
There is support for digital signatures using PKI methodologies and those do, of course, use *asymmetric encryption* as part of the signature procedure. We need to catalog what those flavors are that are accepted and that are produced. Implementations are allowed considerable license in this area and we need to inventory the actual support in OpenOffice.org.
It is not clear to me that the asymmetrical encryption used for digital signatures is a concern, but it is useful to have all of these methods profiled and catalogued concerning their implementation in OpenOffice.org. Comprehensive profiling of digital signature provisions is required to ensure interoperability in any case.
I am not aware of any other cases. There are proposals for some modest but valuable modifications in ODF 1.3 and as possible implementation-dependent introductions in products supporting earlier versions of ODF. Any such implementations would need to be identified too, although none of those I am aware of introduce additional encryption algoritms.
- Dennis
-----Original Message-----
From: Robert Burrell Donkin [mailto:robertburrelldonkin@gmail.com]
Sent: Thursday, September 01, 2011 12:14
To: ooo-dev@incubator.apache.org
Subject: Re: Request dev help: Info for required crypto export declaration
On Thu, Sep 1, 2011 at 8:00 PM, Rob Weir <ro...@robweir.com> wrote:
> On Thu, Sep 1, 2011 at 2:51 PM, Robert Burrell Donkin
> <ro...@gmail.com> wrote:
>> On Thu, Sep 1, 2011 at 7:38 PM, Dennis E. Hamilton
>> <de...@acm.org> wrote:
>>> Please just do it this way:
>>>
>>> <http://www.apache.org/dev/crypto.html>
>>>
>>> ASF is very clear on what is required for *its* releases and this page appears to be comprehensive.
>>
>> The Apache rules break down into reporting to users and notification.
>> Informing users is important but notification is urgent (making source
>> available [1] counts as export).
>>
>>> (I finally found where I saw this before. It has also been discussed here or on the ooo-private list before. I remembered it as being simpler than it is.)
>>
>> (It looks worse than it is)
>>
>> Following the instructions[3], step 1 is to work out whether OOo has
>> any unusual cryptography beyond ECCN 5D002, which is:
>>
>> <blockquote cite='http://www.apache.org/dev/crypto.html#classify>
>> Software specially designed or modified for the development,
>> production or use of any of the other software of this list, or
>> software designed to certify other software on this list; or
>> Software using a "symmetric algorithm" employing a key length in
>> excess of 56-bits; or
>> Software using an "asymmetric algorithm" where the security of the
>> algorithm is based on: factorization of integers in excess of 512 bits
>> (e.g., RSA), computation of discrete logarithms in a multiplicative
>> group of a finite field of size greater than 512 bits (e.g.,
>> Diffie-Hellman over Z/pZ), or other discrete logarithms in a group in
>> excess of 112 bits (e.g., Diffie-Hellman over an elliptic curve).
>> </blockquote>
>>
>> Does OOo rely on cryptography more exotic than this?
>>
>
> That is where it seems backwards to me. If I'm reading this
> correctly, we are OK if we use a symmetrical algorithm with key length
> greater than ("in excess of") 56-bits. But if we use an algorithm,
> with less thanb 56-bits we're considered exotic? Really?
Remember that we're only interested in strong cryptography :-)
IIRC symmetric and asymmetric algorithms weaker than this are not
considered strong cryptography, and so don't fall under ECCN 5D002.
Cryptography which is neither weak nor covered by those definitions
needs special handling.
Robert
Re: Request dev help: Info for required crypto export declaration
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Thu, Sep 1, 2011 at 8:00 PM, Rob Weir <ro...@robweir.com> wrote:
> On Thu, Sep 1, 2011 at 2:51 PM, Robert Burrell Donkin
> <ro...@gmail.com> wrote:
>> On Thu, Sep 1, 2011 at 7:38 PM, Dennis E. Hamilton
>> <de...@acm.org> wrote:
>>> Please just do it this way:
>>>
>>> <http://www.apache.org/dev/crypto.html>
>>>
>>> ASF is very clear on what is required for *its* releases and this page appears to be comprehensive.
>>
>> The Apache rules break down into reporting to users and notification.
>> Informing users is important but notification is urgent (making source
>> available [1] counts as export).
>>
>>> (I finally found where I saw this before. It has also been discussed here or on the ooo-private list before. I remembered it as being simpler than it is.)
>>
>> (It looks worse than it is)
>>
>> Following the instructions[3], step 1 is to work out whether OOo has
>> any unusual cryptography beyond ECCN 5D002, which is:
>>
>> <blockquote cite='http://www.apache.org/dev/crypto.html#classify>
>> Software specially designed or modified for the development,
>> production or use of any of the other software of this list, or
>> software designed to certify other software on this list; or
>> Software using a "symmetric algorithm" employing a key length in
>> excess of 56-bits; or
>> Software using an "asymmetric algorithm" where the security of the
>> algorithm is based on: factorization of integers in excess of 512 bits
>> (e.g., RSA), computation of discrete logarithms in a multiplicative
>> group of a finite field of size greater than 512 bits (e.g.,
>> Diffie-Hellman over Z/pZ), or other discrete logarithms in a group in
>> excess of 112 bits (e.g., Diffie-Hellman over an elliptic curve).
>> </blockquote>
>>
>> Does OOo rely on cryptography more exotic than this?
>>
>
> That is where it seems backwards to me. If I'm reading this
> correctly, we are OK if we use a symmetrical algorithm with key length
> greater than ("in excess of") 56-bits. But if we use an algorithm,
> with less thanb 56-bits we're considered exotic? Really?
Remember that we're only interested in strong cryptography :-)
IIRC symmetric and asymmetric algorithms weaker than this are not
considered strong cryptography, and so don't fall under ECCN 5D002.
Cryptography which is neither weak nor covered by those definitions
needs special handling.
Robert
Re: Request dev help: Info for required crypto export declaration
Posted by Rob Weir <ro...@robweir.com>.
On Thu, Sep 1, 2011 at 2:51 PM, Robert Burrell Donkin
<ro...@gmail.com> wrote:
> On Thu, Sep 1, 2011 at 7:38 PM, Dennis E. Hamilton
> <de...@acm.org> wrote:
>> Please just do it this way:
>>
>> <http://www.apache.org/dev/crypto.html>
>>
>> ASF is very clear on what is required for *its* releases and this page appears to be comprehensive.
>
> The Apache rules break down into reporting to users and notification.
> Informing users is important but notification is urgent (making source
> available [1] counts as export).
>
>> (I finally found where I saw this before. It has also been discussed here or on the ooo-private list before. I remembered it as being simpler than it is.)
>
> (It looks worse than it is)
>
> Following the instructions[3], step 1 is to work out whether OOo has
> any unusual cryptography beyond ECCN 5D002, which is:
>
> <blockquote cite='http://www.apache.org/dev/crypto.html#classify>
> Software specially designed or modified for the development,
> production or use of any of the other software of this list, or
> software designed to certify other software on this list; or
> Software using a "symmetric algorithm" employing a key length in
> excess of 56-bits; or
> Software using an "asymmetric algorithm" where the security of the
> algorithm is based on: factorization of integers in excess of 512 bits
> (e.g., RSA), computation of discrete logarithms in a multiplicative
> group of a finite field of size greater than 512 bits (e.g.,
> Diffie-Hellman over Z/pZ), or other discrete logarithms in a group in
> excess of 112 bits (e.g., Diffie-Hellman over an elliptic curve).
> </blockquote>
>
> Does OOo rely on cryptography more exotic than this?
>
That is where it seems backwards to me. If I'm reading this
correctly, we are OK if we use a symmetrical algorithm with key length
greater than ("in excess of") 56-bits. But if we use an algorithm,
with less thanb 56-bits we're considered exotic? Really?
For example, Calc has a ROT13() spreadsheet function, which
undoubtedly is a weak symmetrical encryption technique, certainly not
one with a key length in excess of 56-bits.
So what now? In other words, I'm puzzled by the "in excess" part.
They seem to be saying that strong encryption is regulated less than
weak encryption.
Could you explain where I'm getting this wrong?
Thanks,
-Rob
> Robert
>
> [1] http://www.apache.org/dev/crypto.html#overview
> [2] http://www.apache.org/licenses/exports/
> [3] http://www.apache.org/dev/crypto.html#classify
>
Re: Request dev help: Info for required crypto export declaration
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Thu, Sep 1, 2011 at 7:38 PM, Dennis E. Hamilton
<de...@acm.org> wrote:
> Please just do it this way:
>
> <http://www.apache.org/dev/crypto.html>
>
> ASF is very clear on what is required for *its* releases and this page appears to be comprehensive.
The Apache rules break down into reporting to users and notification.
Informing users is important but notification is urgent (making source
available [1] counts as export).
> (I finally found where I saw this before. It has also been discussed here or on the ooo-private list before. I remembered it as being simpler than it is.)
(It looks worse than it is)
Following the instructions[3], step 1 is to work out whether OOo has
any unusual cryptography beyond ECCN 5D002, which is:
<blockquote cite='http://www.apache.org/dev/crypto.html#classify>
Software specially designed or modified for the development,
production or use of any of the other software of this list, or
software designed to certify other software on this list; or
Software using a "symmetric algorithm" employing a key length in
excess of 56-bits; or
Software using an "asymmetric algorithm" where the security of the
algorithm is based on: factorization of integers in excess of 512 bits
(e.g., RSA), computation of discrete logarithms in a multiplicative
group of a finite field of size greater than 512 bits (e.g.,
Diffie-Hellman over Z/pZ), or other discrete logarithms in a group in
excess of 112 bits (e.g., Diffie-Hellman over an elliptic curve).
</blockquote>
Does OOo rely on cryptography more exotic than this?
Robert
[1] http://www.apache.org/dev/crypto.html#overview
[2] http://www.apache.org/licenses/exports/
[3] http://www.apache.org/dev/crypto.html#classify
RE: Request dev help: Info for required crypto export declaration
Posted by "Dennis E. Hamilton" <de...@acm.org>.
Please just do it this way:
<http://www.apache.org/dev/crypto.html>
ASF is very clear on what is required for *its* releases and this page appears to be comprehensive.
(I finally found where I saw this before. It has also been discussed here or on the ooo-private list before. I remembered it as being simpler than it is.)
- Dennis
-----Original Message-----
From: rabastus@gmail.com [mailto:rabastus@gmail.com] On Behalf Of Rob Weir
Sent: Thursday, September 01, 2011 09:15
To: ooo-dev@incubator.apache.org
Subject: Re: Request dev help: Info for required crypto export declaration
On Thu, Sep 1, 2011 at 11:51 AM, Danese Cooper <da...@gmail.com> wrote:
> On Wed, Aug 31, 2011 at 9:30 AM, Rob Weir <ro...@robweir.com> wrote:
>
>> On Wed, Aug 31, 2011 at 12:29 PM, Dennis E. Hamilton
>> <de...@acm.org> wrote:
>>
>
>
>> <snip>
>>
>
>
>> >> 1) Was something similar every done for OpenOffice.org? Most software
>> >> companies are aware of this US export regulation and do this
>> >> declaration as a matter of routine. But not all open source projects
>> >> are as diligent as ASF is. So it is possible that OOo never did this
>> >> before. But if they did, we could reuse much of their paperwork.
>> >
>> > AFAIR Sun did that some time ago, but I'm not 100% sure.
>>
>
> Yes, Sun did this (probably for every official "release").
>
If so, this might have been kept on the corporate side, not on the
community website.
For example, searching Google for "site:openoffice.org ECCN" shows
several requests for this information [1] [2] [3] over the years, but
no useful responses.
Looks like LO discussed it briefly [4], but dismissed it under the
misapprehension that since they are not in the US, the regulation is
irrelevant. We'll obviously want to do better here. It may not make
a much of a difference to the individual downloaded of AOOo, but this
paperwork is essential for anyone who might want to bundle AOOo with
laptops, for example. The location of the project is not the solitary
relevant fact. The location of the users and re-distributors is the
key thing.
[1] http://openoffice.org/projects/www/lists/users/archive/2004-12/message/24
[2] http://openoffice.org/projects/marketing/lists/dev/archive/2005-11/message/204
[3] http://openoffice.org/projects/www/lists/users/archive/2009-12/message/653
[4] http://comments.gmane.org/gmane.comp.documentfoundation.discuss/6138
I'll check what we did for IBM Lotus Symphony.
-Rob
> Danese
>
Re: Request dev help: Info for required crypto export declaration
Posted by Rob Weir <ro...@robweir.com>.
On Thu, Sep 1, 2011 at 11:51 AM, Danese Cooper <da...@gmail.com> wrote:
> On Wed, Aug 31, 2011 at 9:30 AM, Rob Weir <ro...@robweir.com> wrote:
>
>> On Wed, Aug 31, 2011 at 12:29 PM, Dennis E. Hamilton
>> <de...@acm.org> wrote:
>>
>
>
>> <snip>
>>
>
>
>> >> 1) Was something similar every done for OpenOffice.org? Most software
>> >> companies are aware of this US export regulation and do this
>> >> declaration as a matter of routine. But not all open source projects
>> >> are as diligent as ASF is. So it is possible that OOo never did this
>> >> before. But if they did, we could reuse much of their paperwork.
>> >
>> > AFAIR Sun did that some time ago, but I'm not 100% sure.
>>
>
> Yes, Sun did this (probably for every official "release").
>
If so, this might have been kept on the corporate side, not on the
community website.
For example, searching Google for "site:openoffice.org ECCN" shows
several requests for this information [1] [2] [3] over the years, but
no useful responses.
Looks like LO discussed it briefly [4], but dismissed it under the
misapprehension that since they are not in the US, the regulation is
irrelevant. We'll obviously want to do better here. It may not make
a much of a difference to the individual downloaded of AOOo, but this
paperwork is essential for anyone who might want to bundle AOOo with
laptops, for example. The location of the project is not the solitary
relevant fact. The location of the users and re-distributors is the
key thing.
[1] http://openoffice.org/projects/www/lists/users/archive/2004-12/message/24
[2] http://openoffice.org/projects/marketing/lists/dev/archive/2005-11/message/204
[3] http://openoffice.org/projects/www/lists/users/archive/2009-12/message/653
[4] http://comments.gmane.org/gmane.comp.documentfoundation.discuss/6138
I'll check what we did for IBM Lotus Symphony.
-Rob
> Danese
>
Re: Request dev help: Info for required crypto export declaration
Posted by Danese Cooper <da...@gmail.com>.
On Wed, Aug 31, 2011 at 9:30 AM, Rob Weir <ro...@robweir.com> wrote:
> On Wed, Aug 31, 2011 at 12:29 PM, Dennis E. Hamilton
> <de...@acm.org> wrote:
>
> <snip>
>
> >> 1) Was something similar every done for OpenOffice.org? Most software
> >> companies are aware of this US export regulation and do this
> >> declaration as a matter of routine. But not all open source projects
> >> are as diligent as ASF is. So it is possible that OOo never did this
> >> before. But if they did, we could reuse much of their paperwork.
> >
> > AFAIR Sun did that some time ago, but I'm not 100% sure.
>
Yes, Sun did this (probably for every official "release").
Danese
Re: Request dev help: Info for required crypto export declaration
Posted by Rob Weir <ro...@robweir.com>.
On Thu, Sep 1, 2011 at 11:41 AM, Pedro F. Giffuni <gi...@tutopia.com> wrote:
> While here,
>
> Can Apache projects rely on Mozilla's nss (MPL)?
>
See this page on current view from Apache legal:
http://www.apache.org/legal/resolved.html#category-b
> I looked for alternatives but I only found the java based
> Bouncy Castle:
>
> http://www.bouncycastle.org/
>
> cheers,
>
> Pedro.
>
> --- On Thu, 9/1/11, Dennis E. Hamilton <de...@acm.org> wrote:
>
>> From: Dennis E. Hamilton <de...@acm.org>
>> Subject: RE: Request dev help: Info for required crypto export declaration
>> To: ooo-dev@incubator.apache.org
>> Date: Thursday, September 1, 2011, 12:00 AM
>> It is simplified and it isn't.
>> But we are doing it out of order.
>>
>> Here is the page that I couldn't remember the location of:
>>
>> <http://www.apache.org/dev/crypto.html>
>>
>> - Dennis
>>
>> -----Original Message-----
>> From: rabastus@gmail.com
>> [mailto:rabastus@gmail.com]
>> On Behalf Of Rob Weir
>> Sent: Wednesday, August 31, 2011 09:31
>> To: ooo-dev@incubator.apache.org
>> Subject: Re: Request dev help: Info for required crypto
>> export declaration
>>
>> On Wed, Aug 31, 2011 at 12:29 PM, Dennis E. Hamilton
>> <de...@acm.org>
>> wrote:
>> > I thought there was a short-circuit/umbrella process
>> that doesn't require all of these details. I thought
>> that came up on an old thread, either on the PPMC or in the
>> early days of this list.
>> >
>> > We do need to collect and update the details, but I am
>> not so sure we need to file a full-up declaration.
>> There is apparently a simplified procedure and we should
>> look for it. (I am not where I can do that right now.)
>> >
>>
>> Uh... but we need to know the details to know whether we
>> can use the
>> simplified procedure.
>>
>> -Rob
>>
>>
>> > -----Original Message-----
>> > From: Mathias Bauer [mailto:Mathias_Bauer@gmx.net]
>> > Sent: Wednesday, August 31, 2011 07:00
>> > To: ooo-dev@incubator.apache.org
>> > Subject: Re: Request dev help: Info for required
>> crypto export declaration
>> >
>> > Moin,
>> >
>> > please take my answers with a decent grain of salt,
>> I'm not an expert
>> > for that area, Matthias Hütsch and Malte Timmermann
>> certainly could
>> > answer that better, but I don't know if they are
>> currently contributing
>> > to this list. Hopefully my remarks can help to look at
>> the right places.
>> >
>> > Am 31.08.2011 15:03, schrieb Rob Weir:
>> >
>> >> There is some paperwork we need to file based on
>> OOo use of
>> >> cryptography. Details are on the Apache
>> website [1]. I think I can
>> >> handle most of the paperwork, provided I can get
>> some help, on this
>> >> thread, establishing the basic facts.
>> >>
>> >>
>> >> 1) Was something similar every done for
>> OpenOffice.org? Most software
>> >> companies are aware of this US export regulation
>> and do this
>> >> declaration as a matter of routine. But not
>> all open source projects
>> >> are as diligent as ASF is. So it is possible
>> that OOo never did this
>> >> before. But if they did, we could reuse much
>> of their paperwork.
>> >
>> > AFAIR Sun did that some time ago, but I'm not 100%
>> sure.
>> >
>> >> 2) We need a list of all uses of cryptographic
>> methods in OOo,
>> >> including code that we include, but also where we
>> enable 3rd party or
>> >> OS crypto modules to plugged in. This
>> includes both symmetrical
>> >> algorithms (commonly used for encryption) as well
>> as asymmetrical
>> >> algorithms (for example, public key uses like PGP,
>> RSA, TLS, etc.)
>> >>
>> >> 3) For each method, it looks like we need to state
>> whether we authored
>> >> the crypto, or name the origin of the code if it
>> is a 3rd party.
>> >>
>> >> The methods I suspect are in OOo are:
>> >>
>> >> a) For password-protected ODF documents, we use
>> the Blowfish block
>> >> encryption method. Where did that
>> code come from?
>> >
>> > It was an own implementation from someone who was
>> employed by Sun at
>> > that time.
>> >
>> > In the new 3.4 code we also use AES code from the
>> openssl library.
>> >
>> >> b) What do we support for other document formats,
>> such as DOC, OOXML
>> >> or legacy StarOffice formats? Any other
>> encryption methods? If so,
>> >> what are they are what was their origin?
>> >
>> > As none of the former Oracle employed MS filter
>> developers is listening
>> > here, maybe we could ask Kohei or Caolan from the
>> Libre Office crew.
>> >
>> >> c) We support digital signatures with ODF files as
>> well. What
>> >> algorithms are supported? Is this our
>> original code or 3rd party?
>> >
>> > The code we use is based on the SeaMonkey or nss
>> module. I always get
>> > confused about them, but in any way the code is
>> "external".
>> >
>> >> d) Do we support digital signatures with any
>> other file formats?
>> >
>> > No, only our own files format.
>> >
>> >> e) Any other uses of encryption?
>> >>
>> >> f) Presumably we places that are at least enabled
>> for SSL via OS-level
>> >> resolution of https protocol
>> URLs. Is this correct?
>> >>
>> >> g) But do we have any SSL (TLS) code included in
>> our source code? If
>> >> so, what is the origin of this?
>> >
>> > Open ssl, maybe something in neon, I don't know.
>> >
>> > Regards,
>> > Mathias
>> >
>> >
>>
>>
>>
>
RE: Request dev help: Info for required crypto export declaration
Posted by "Pedro F. Giffuni" <gi...@tutopia.com>.
While here,
Can Apache projects rely on Mozilla's nss (MPL)?
I looked for alternatives but I only found the java based
Bouncy Castle:
http://www.bouncycastle.org/
cheers,
Pedro.
--- On Thu, 9/1/11, Dennis E. Hamilton <de...@acm.org> wrote:
> From: Dennis E. Hamilton <de...@acm.org>
> Subject: RE: Request dev help: Info for required crypto export declaration
> To: ooo-dev@incubator.apache.org
> Date: Thursday, September 1, 2011, 12:00 AM
> It is simplified and it isn't.
> But we are doing it out of order.
>
> Here is the page that I couldn't remember the location of:
>
> <http://www.apache.org/dev/crypto.html>
>
> - Dennis
>
> -----Original Message-----
> From: rabastus@gmail.com
> [mailto:rabastus@gmail.com]
> On Behalf Of Rob Weir
> Sent: Wednesday, August 31, 2011 09:31
> To: ooo-dev@incubator.apache.org
> Subject: Re: Request dev help: Info for required crypto
> export declaration
>
> On Wed, Aug 31, 2011 at 12:29 PM, Dennis E. Hamilton
> <de...@acm.org>
> wrote:
> > I thought there was a short-circuit/umbrella process
> that doesn't require all of these details. I thought
> that came up on an old thread, either on the PPMC or in the
> early days of this list.
> >
> > We do need to collect and update the details, but I am
> not so sure we need to file a full-up declaration.
> There is apparently a simplified procedure and we should
> look for it. (I am not where I can do that right now.)
> >
>
> Uh... but we need to know the details to know whether we
> can use the
> simplified procedure.
>
> -Rob
>
>
> > -----Original Message-----
> > From: Mathias Bauer [mailto:Mathias_Bauer@gmx.net]
> > Sent: Wednesday, August 31, 2011 07:00
> > To: ooo-dev@incubator.apache.org
> > Subject: Re: Request dev help: Info for required
> crypto export declaration
> >
> > Moin,
> >
> > please take my answers with a decent grain of salt,
> I'm not an expert
> > for that area, Matthias Hütsch and Malte Timmermann
> certainly could
> > answer that better, but I don't know if they are
> currently contributing
> > to this list. Hopefully my remarks can help to look at
> the right places.
> >
> > Am 31.08.2011 15:03, schrieb Rob Weir:
> >
> >> There is some paperwork we need to file based on
> OOo use of
> >> cryptography. Details are on the Apache
> website [1]. I think I can
> >> handle most of the paperwork, provided I can get
> some help, on this
> >> thread, establishing the basic facts.
> >>
> >>
> >> 1) Was something similar every done for
> OpenOffice.org? Most software
> >> companies are aware of this US export regulation
> and do this
> >> declaration as a matter of routine. But not
> all open source projects
> >> are as diligent as ASF is. So it is possible
> that OOo never did this
> >> before. But if they did, we could reuse much
> of their paperwork.
> >
> > AFAIR Sun did that some time ago, but I'm not 100%
> sure.
> >
> >> 2) We need a list of all uses of cryptographic
> methods in OOo,
> >> including code that we include, but also where we
> enable 3rd party or
> >> OS crypto modules to plugged in. This
> includes both symmetrical
> >> algorithms (commonly used for encryption) as well
> as asymmetrical
> >> algorithms (for example, public key uses like PGP,
> RSA, TLS, etc.)
> >>
> >> 3) For each method, it looks like we need to state
> whether we authored
> >> the crypto, or name the origin of the code if it
> is a 3rd party.
> >>
> >> The methods I suspect are in OOo are:
> >>
> >> a) For password-protected ODF documents, we use
> the Blowfish block
> >> encryption method. Where did that
> code come from?
> >
> > It was an own implementation from someone who was
> employed by Sun at
> > that time.
> >
> > In the new 3.4 code we also use AES code from the
> openssl library.
> >
> >> b) What do we support for other document formats,
> such as DOC, OOXML
> >> or legacy StarOffice formats? Any other
> encryption methods? If so,
> >> what are they are what was their origin?
> >
> > As none of the former Oracle employed MS filter
> developers is listening
> > here, maybe we could ask Kohei or Caolan from the
> Libre Office crew.
> >
> >> c) We support digital signatures with ODF files as
> well. What
> >> algorithms are supported? Is this our
> original code or 3rd party?
> >
> > The code we use is based on the SeaMonkey or nss
> module. I always get
> > confused about them, but in any way the code is
> "external".
> >
> >> d) Do we support digital signatures with any
> other file formats?
> >
> > No, only our own files format.
> >
> >> e) Any other uses of encryption?
> >>
> >> f) Presumably we places that are at least enabled
> for SSL via OS-level
> >> resolution of https protocol
> URLs. Is this correct?
> >>
> >> g) But do we have any SSL (TLS) code included in
> our source code? If
> >> so, what is the origin of this?
> >
> > Open ssl, maybe something in neon, I don't know.
> >
> > Regards,
> > Mathias
> >
> >
>
>
>
RE: Request dev help: Info for required crypto export declaration
Posted by "Dennis E. Hamilton" <de...@acm.org>.
It is simplified and it isn't. But we are doing it out of order.
Here is the page that I couldn't remember the location of:
<http://www.apache.org/dev/crypto.html>
- Dennis
-----Original Message-----
From: rabastus@gmail.com [mailto:rabastus@gmail.com] On Behalf Of Rob Weir
Sent: Wednesday, August 31, 2011 09:31
To: ooo-dev@incubator.apache.org
Subject: Re: Request dev help: Info for required crypto export declaration
On Wed, Aug 31, 2011 at 12:29 PM, Dennis E. Hamilton
<de...@acm.org> wrote:
> I thought there was a short-circuit/umbrella process that doesn't require all of these details. I thought that came up on an old thread, either on the PPMC or in the early days of this list.
>
> We do need to collect and update the details, but I am not so sure we need to file a full-up declaration. There is apparently a simplified procedure and we should look for it. (I am not where I can do that right now.)
>
Uh... but we need to know the details to know whether we can use the
simplified procedure.
-Rob
> -----Original Message-----
> From: Mathias Bauer [mailto:Mathias_Bauer@gmx.net]
> Sent: Wednesday, August 31, 2011 07:00
> To: ooo-dev@incubator.apache.org
> Subject: Re: Request dev help: Info for required crypto export declaration
>
> Moin,
>
> please take my answers with a decent grain of salt, I'm not an expert
> for that area, Matthias Hütsch and Malte Timmermann certainly could
> answer that better, but I don't know if they are currently contributing
> to this list. Hopefully my remarks can help to look at the right places.
>
> Am 31.08.2011 15:03, schrieb Rob Weir:
>
>> There is some paperwork we need to file based on OOo use of
>> cryptography. Details are on the Apache website [1]. I think I can
>> handle most of the paperwork, provided I can get some help, on this
>> thread, establishing the basic facts.
>>
>>
>> 1) Was something similar every done for OpenOffice.org? Most software
>> companies are aware of this US export regulation and do this
>> declaration as a matter of routine. But not all open source projects
>> are as diligent as ASF is. So it is possible that OOo never did this
>> before. But if they did, we could reuse much of their paperwork.
>
> AFAIR Sun did that some time ago, but I'm not 100% sure.
>
>> 2) We need a list of all uses of cryptographic methods in OOo,
>> including code that we include, but also where we enable 3rd party or
>> OS crypto modules to plugged in. This includes both symmetrical
>> algorithms (commonly used for encryption) as well as asymmetrical
>> algorithms (for example, public key uses like PGP, RSA, TLS, etc.)
>>
>> 3) For each method, it looks like we need to state whether we authored
>> the crypto, or name the origin of the code if it is a 3rd party.
>>
>> The methods I suspect are in OOo are:
>>
>> a) For password-protected ODF documents, we use the Blowfish block
>> encryption method. Where did that code come from?
>
> It was an own implementation from someone who was employed by Sun at
> that time.
>
> In the new 3.4 code we also use AES code from the openssl library.
>
>> b) What do we support for other document formats, such as DOC, OOXML
>> or legacy StarOffice formats? Any other encryption methods? If so,
>> what are they are what was their origin?
>
> As none of the former Oracle employed MS filter developers is listening
> here, maybe we could ask Kohei or Caolan from the Libre Office crew.
>
>> c) We support digital signatures with ODF files as well. What
>> algorithms are supported? Is this our original code or 3rd party?
>
> The code we use is based on the SeaMonkey or nss module. I always get
> confused about them, but in any way the code is "external".
>
>> d) Do we support digital signatures with any other file formats?
>
> No, only our own files format.
>
>> e) Any other uses of encryption?
>>
>> f) Presumably we places that are at least enabled for SSL via OS-level
>> resolution of https protocol URLs. Is this correct?
>>
>> g) But do we have any SSL (TLS) code included in our source code? If
>> so, what is the origin of this?
>
> Open ssl, maybe something in neon, I don't know.
>
> Regards,
> Mathias
>
>
Re: Request dev help: Info for required crypto export declaration
Posted by Rob Weir <ro...@robweir.com>.
On Wed, Aug 31, 2011 at 12:29 PM, Dennis E. Hamilton
<de...@acm.org> wrote:
> I thought there was a short-circuit/umbrella process that doesn't require all of these details. I thought that came up on an old thread, either on the PPMC or in the early days of this list.
>
> We do need to collect and update the details, but I am not so sure we need to file a full-up declaration. There is apparently a simplified procedure and we should look for it. (I am not where I can do that right now.)
>
Uh... but we need to know the details to know whether we can use the
simplified procedure.
-Rob
> -----Original Message-----
> From: Mathias Bauer [mailto:Mathias_Bauer@gmx.net]
> Sent: Wednesday, August 31, 2011 07:00
> To: ooo-dev@incubator.apache.org
> Subject: Re: Request dev help: Info for required crypto export declaration
>
> Moin,
>
> please take my answers with a decent grain of salt, I'm not an expert
> for that area, Matthias Hütsch and Malte Timmermann certainly could
> answer that better, but I don't know if they are currently contributing
> to this list. Hopefully my remarks can help to look at the right places.
>
> Am 31.08.2011 15:03, schrieb Rob Weir:
>
>> There is some paperwork we need to file based on OOo use of
>> cryptography. Details are on the Apache website [1]. I think I can
>> handle most of the paperwork, provided I can get some help, on this
>> thread, establishing the basic facts.
>>
>>
>> 1) Was something similar every done for OpenOffice.org? Most software
>> companies are aware of this US export regulation and do this
>> declaration as a matter of routine. But not all open source projects
>> are as diligent as ASF is. So it is possible that OOo never did this
>> before. But if they did, we could reuse much of their paperwork.
>
> AFAIR Sun did that some time ago, but I'm not 100% sure.
>
>> 2) We need a list of all uses of cryptographic methods in OOo,
>> including code that we include, but also where we enable 3rd party or
>> OS crypto modules to plugged in. This includes both symmetrical
>> algorithms (commonly used for encryption) as well as asymmetrical
>> algorithms (for example, public key uses like PGP, RSA, TLS, etc.)
>>
>> 3) For each method, it looks like we need to state whether we authored
>> the crypto, or name the origin of the code if it is a 3rd party.
>>
>> The methods I suspect are in OOo are:
>>
>> a) For password-protected ODF documents, we use the Blowfish block
>> encryption method. Where did that code come from?
>
> It was an own implementation from someone who was employed by Sun at
> that time.
>
> In the new 3.4 code we also use AES code from the openssl library.
>
>> b) What do we support for other document formats, such as DOC, OOXML
>> or legacy StarOffice formats? Any other encryption methods? If so,
>> what are they are what was their origin?
>
> As none of the former Oracle employed MS filter developers is listening
> here, maybe we could ask Kohei or Caolan from the Libre Office crew.
>
>> c) We support digital signatures with ODF files as well. What
>> algorithms are supported? Is this our original code or 3rd party?
>
> The code we use is based on the SeaMonkey or nss module. I always get
> confused about them, but in any way the code is "external".
>
>> d) Do we support digital signatures with any other file formats?
>
> No, only our own files format.
>
>> e) Any other uses of encryption?
>>
>> f) Presumably we places that are at least enabled for SSL via OS-level
>> resolution of https protocol URLs. Is this correct?
>>
>> g) But do we have any SSL (TLS) code included in our source code? If
>> so, what is the origin of this?
>
> Open ssl, maybe something in neon, I don't know.
>
> Regards,
> Mathias
>
>
RE: Request dev help: Info for required crypto export declaration
Posted by "Dennis E. Hamilton" <de...@acm.org>.
I thought there was a short-circuit/umbrella process that doesn't require all of these details. I thought that came up on an old thread, either on the PPMC or in the early days of this list.
We do need to collect and update the details, but I am not so sure we need to file a full-up declaration. There is apparently a simplified procedure and we should look for it. (I am not where I can do that right now.)
-----Original Message-----
From: Mathias Bauer [mailto:Mathias_Bauer@gmx.net]
Sent: Wednesday, August 31, 2011 07:00
To: ooo-dev@incubator.apache.org
Subject: Re: Request dev help: Info for required crypto export declaration
Moin,
please take my answers with a decent grain of salt, I'm not an expert
for that area, Matthias Hütsch and Malte Timmermann certainly could
answer that better, but I don't know if they are currently contributing
to this list. Hopefully my remarks can help to look at the right places.
Am 31.08.2011 15:03, schrieb Rob Weir:
> There is some paperwork we need to file based on OOo use of
> cryptography. Details are on the Apache website [1]. I think I can
> handle most of the paperwork, provided I can get some help, on this
> thread, establishing the basic facts.
>
>
> 1) Was something similar every done for OpenOffice.org? Most software
> companies are aware of this US export regulation and do this
> declaration as a matter of routine. But not all open source projects
> are as diligent as ASF is. So it is possible that OOo never did this
> before. But if they did, we could reuse much of their paperwork.
AFAIR Sun did that some time ago, but I'm not 100% sure.
> 2) We need a list of all uses of cryptographic methods in OOo,
> including code that we include, but also where we enable 3rd party or
> OS crypto modules to plugged in. This includes both symmetrical
> algorithms (commonly used for encryption) as well as asymmetrical
> algorithms (for example, public key uses like PGP, RSA, TLS, etc.)
>
> 3) For each method, it looks like we need to state whether we authored
> the crypto, or name the origin of the code if it is a 3rd party.
>
> The methods I suspect are in OOo are:
>
> a) For password-protected ODF documents, we use the Blowfish block
> encryption method. Where did that code come from?
It was an own implementation from someone who was employed by Sun at
that time.
In the new 3.4 code we also use AES code from the openssl library.
> b) What do we support for other document formats, such as DOC, OOXML
> or legacy StarOffice formats? Any other encryption methods? If so,
> what are they are what was their origin?
As none of the former Oracle employed MS filter developers is listening
here, maybe we could ask Kohei or Caolan from the Libre Office crew.
> c) We support digital signatures with ODF files as well. What
> algorithms are supported? Is this our original code or 3rd party?
The code we use is based on the SeaMonkey or nss module. I always get
confused about them, but in any way the code is "external".
> d) Do we support digital signatures with any other file formats?
No, only our own files format.
> e) Any other uses of encryption?
>
> f) Presumably we places that are at least enabled for SSL via OS-level
> resolution of https protocol URLs. Is this correct?
>
> g) But do we have any SSL (TLS) code included in our source code? If
> so, what is the origin of this?
Open ssl, maybe something in neon, I don't know.
Regards,
Mathias
Re: Request dev help: Info for required crypto export declaration
Posted by Mathias Bauer <Ma...@gmx.net>.
Moin,
please take my answers with a decent grain of salt, I'm not an expert
for that area, Matthias Hütsch and Malte Timmermann certainly could
answer that better, but I don't know if they are currently contributing
to this list. Hopefully my remarks can help to look at the right places.
Am 31.08.2011 15:03, schrieb Rob Weir:
> There is some paperwork we need to file based on OOo use of
> cryptography. Details are on the Apache website [1]. I think I can
> handle most of the paperwork, provided I can get some help, on this
> thread, establishing the basic facts.
>
>
> 1) Was something similar every done for OpenOffice.org? Most software
> companies are aware of this US export regulation and do this
> declaration as a matter of routine. But not all open source projects
> are as diligent as ASF is. So it is possible that OOo never did this
> before. But if they did, we could reuse much of their paperwork.
AFAIR Sun did that some time ago, but I'm not 100% sure.
> 2) We need a list of all uses of cryptographic methods in OOo,
> including code that we include, but also where we enable 3rd party or
> OS crypto modules to plugged in. This includes both symmetrical
> algorithms (commonly used for encryption) as well as asymmetrical
> algorithms (for example, public key uses like PGP, RSA, TLS, etc.)
>
> 3) For each method, it looks like we need to state whether we authored
> the crypto, or name the origin of the code if it is a 3rd party.
>
> The methods I suspect are in OOo are:
>
> a) For password-protected ODF documents, we use the Blowfish block
> encryption method. Where did that code come from?
It was an own implementation from someone who was employed by Sun at
that time.
In the new 3.4 code we also use AES code from the openssl library.
> b) What do we support for other document formats, such as DOC, OOXML
> or legacy StarOffice formats? Any other encryption methods? If so,
> what are they are what was their origin?
As none of the former Oracle employed MS filter developers is listening
here, maybe we could ask Kohei or Caolan from the Libre Office crew.
> c) We support digital signatures with ODF files as well. What
> algorithms are supported? Is this our original code or 3rd party?
The code we use is based on the SeaMonkey or nss module. I always get
confused about them, but in any way the code is "external".
> d) Do we support digital signatures with any other file formats?
No, only our own files format.
> e) Any other uses of encryption?
>
> f) Presumably we places that are at least enabled for SSL via OS-level
> resolution of https protocol URLs. Is this correct?
>
> g) But do we have any SSL (TLS) code included in our source code? If
> so, what is the origin of this?
Open ssl, maybe something in neon, I don't know.
Regards,
Mathias