incubator-odf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: Ready for ODF Toolkit crypto declaration
Date Wed, 15 Feb 2012 15:15:15 GMT
On Wed, Feb 15, 2012 at 7:02 AM, Nick Burch <> wrote:
> On Tue, 14 Feb 2012, Rob Weir wrote:
>> If I understand correctly, since we are not including Java Crypto API
>> libraries in our code, we don't need to declare them specifically. But since
>> we're "designed to use" such libraries we need to register the ODF Toolkit
>> as 5D002.
> I think this case is actually a 5x992 one, rather than a 5d002 one, but the
> rules did change fairly recently and we're in the process of figuring out
> the new policy.
>> Note that we do have our own implementation of PKCS #5, per RFC 2898.
>> This is a "password-based key derivation function", which is applied
>> prior to encryption in order to convert "weak" passcodes entered by
>> end users into higher entropy ones.   I don't see this as restricted
>> under the export regulations, so I don't think we should declare it.
> I think that's correct. What you feed the password bytes too may well be
> 5D002 / 5x992 restricted (or similar), but I don't think the work to turn
> the string into bytes is
>> Looking at the process [1] for doing this paperwork, it looks like we
>> need to update this [2] page by updating this [3] source.
>> [1]
>> [2]
>> [3]
> Those guides refer to the old system, and are probably not now appropriate
> for this case. What should now be done is being discussed on the
> legal-discuss list:
> <>

What I don't see is anything that removes the old TSU exception for
open source.  It is one thing if the revision adds a new path, but
keeps the old option, versus a revision that eliminates TSU.

> Are you able and willing to put a bit of work in on this?  The 5d002 and
> based-on-5d002 cases are going to be a bit harder, but the 5x992 case (like
> this one) ought to be simpler. It does need someone to read up on the rules,
> check if the current understanding on legal-discuss looks correct, verify
> this with the BIS, and then finally we can update the documentation.

I have no background in US Federal trade regulations.  I assume this
is true of most of us.  Since this impacts all of ASF, not just this
podling, there must be a way to revise current policy at a
foundation-wide level.  In other words, ASF is the legal distributor
of the code, they claim the copyright on the aggregated code, so it is
ASF interest to get this right.  I'm happy to help, but this might be
a good area to get confirming advice from a competent source (e.g.,
not me, but an attorney), to sign off on what we think the regulation

In any case, I'll try to understand what the new rules are.  It might
be that the TSU exception still exists, and that path, although it
requires some paper work, is easier than proving to ourselves that the
new path, without paperwork, could apply.  The devil we know versus
the one we don't...


> Nick

View raw message