[License-review] For approval: The Cryptographic Autonomy License (Beta 4)

Christopher Lemmer Webber cwebber at dustycloud.org
Wed Feb 12 22:48:03 UTC 2020 

Hi Simon,

Thank you for your question.  I have done my best to give a more high
level series of questions in the last email I just sent in response to
Van:

  http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004675.html

I hope I have done a better job of detailing a set of concerns that
don't require going into the CS weeds.


Simon Phipps writes:

> Chris,
>
> Thanks for the engagement. For those of us who are not specialists in the
> computer science topics you're discussing, please can you summarise why you
> believe CAL does not satisfy the OSD, specifically citing the clauses
> involved?
>
> Thanks
>
> Simon
> (in-role)
>
> On Wed, Feb 12, 2020 at 12:08 AM Christopher Lemmer Webber <
> cwebber at dustycloud.org> wrote:
>
>> Hi Van,
>>
>> First of all, I have asked for review from a community I collaborate
>> with which actually works on cryptographic autonomy here:
>>
>>   https://groups.google.com/forum/#!topic/cap-talk/VE6nNhfwp_w
>>
>> The above thread outlines my concerns in detail.  It may be desirable
>> for me to bullet-point them in a follow-up email, but I'd encourage
>> reading that email.
>>
>> I will respond to some parts below.
>>
>> VanL writes:
>>
>> > I look forward to responding to your other concerns. But to respond
>> above:
>> >
>> > There are only two substantive locations where cryptographic keys are
>> > required. In the definition of source code, section 4.1:
>> >
>> > The “Source Code” of the Work means the form of the Work preferred for
>> > making modifications, including any comments, configuration information,
>> > documentation, help materials, installation instructions, cryptographic
>> > seeds or keys, and any information reasonably necessary for the Recipient
>> > to independently compile and use the Source Code and to have full access
>> to
>> > the functionality contained in the Work.
>> >
>> > This is essentially equivalent to the "complete corresponding source" of
>> > the GPL3. Quoting specifically from the GPL3: "'Installation Information'
>> > for a User Product means any methods, procedures,* authorization keys,*
>> or
>> > other information required to install and execute modified versions of a
>> > covered work in that User Product from a modified version of its
>> > Corresponding Source."
>> >
>> > So this first element is tied to the ability to "independently compile
>> and
>> > use the Source Code and have full access to the functionality contained
>> in
>> > the Work" -- i.e., no Tivoization.
>>
>> I agree that it is similar to GPLv3 in this particular section, however
>> there are some key differences.  The GPLv3 appears to specify the
>> requirement to "install and execute".  This is not the same as the
>> requirement to provide a broader requirement for documentation for
>> "use".  Usage is significantly broader than mere execution... how much
>> documentation need there be?  Is it a violation to add a feature then
>> not document how to use it?  There is also a broader number of
>> requirements here, including the requirements for configuration
>> information.
>>
>> This isn't the primary part I am concerned about, but it does concern
>> me.  As I expressed in the email above to cap-talk (and in my Copyleft
>> Conference talk last year), I am *already* concerned about the
>> requirements that network copyleft introduces in the AGPL for a
>> circumstance where there is little distinction between code and data,
>> and thus private configuration information might be considered part of
>> the complete and corresponding work.  In my talk last year I was making
>> an argument that we could see emacs lisp as being both configuration
>> information and code (but the lack of network requirement permitted
>> private modification).  Here that argument need not even be made since
>> the CAL *explicitly* requires configuration information.
>>
>> I'm definitely worried then about:
>>  - The introduction of a requirement for documentation for *use*
>>  - The introduction of a requirement for configuration information,
>>    *especially in the context of network distribution requirements*.
>>
>> These concerns compound with the following section.
>>
>> > The second substantive place where cryptographic keys are mentioned is in
>> > the user autonomy provisions, specifically 4.2.2:
>> >
>> > You may not, by the use of cryptographic methods applied to anything
>> > provided to the Recipient, by possession or control of cryptographic
>> keys,
>> > seeds, or hashes, by other technological protection measures, or by any
>> > other method, limit a Recipient's ability to access any functionality
>> > present in the Recipient's independent copy of the Work, or deny a
>> > Recipient full control of the Recipient's User Data.
>> >
>> > This is where the distinction arises. An operator must not use any
>> > technical measure, including the use of cryptographic protocols, to
>> "limit
>> > a Recipient's ability to access any functionality" or to "deny a
>> Recipient
>> > full control of the Recipient's User Data." However, securely
>> transmitting
>> > information to the Recipient (e.g. using TLS) does nothing to "limit a
>> > Recipient's ability to access any functionality" or "deny a Recipient
>> full
>> > control of the Recipient's User Data."
>>
>> Here is where I am very concerned.  Recipient is very broad.
>>
>> The use of the word "operator" tells me that the intended use of this
>> license has been seen within the scope of a client-server style
>> architecture, or has been flavored by the experience of seeing that
>> rolled out as the primary way we've seen networked applications in the
>> last couple of decades.  I explain in the above email to cap-talk why I
>> think this is going to be big trouble: I believe it *actually* prevents
>> applications and protocols that are persuing cryptographic autonomy.  In
>> particular:
>>
>>  - It does not seem to anticipate that *every user* should be running
>>    their own application... not client-to-server, but peer-to-peer, so
>>    these are not "server operator requirements", they are requirements
>>    for every user, including potentially ones just running some software
>>    on their phone or laptop.  If Bob holds some small amount of data on
>>    Alice's machine, is Bob able to persue an enforcement request from
>>    Alice's usage of her phone?  I do not see a good way to present this
>>    requirement to ordinary users, and it may even result in accidental
>>    privacy leaks.
>>
>>  - Assume that object access is managed by capability security.  This is
>>    to say, if you have a reference to an object, you can access its
>>    resources, but otherwise you cannot.  In order to uphold the
>>    Principle of Least Authority, varied and attenuated access is given
>>    out to many different objects in the system.  Which of them are
>>    "users", and what rights for what data do they have to extract which
>>    information?  This is not theoretical, this is the direction that
>>    sophisticated peer-to-peer, cryptographically secure distributed
>>    programs are going (eg the programming language E, the work that the
>>    Agoric company is doing, and my own work on Spritely Goblins).  While
>>    I (and many other security researchers) believe this is the
>>    healthiest direction for network security to go, I do not see a good
>>    way to be able to uphold this with the requirements for recipient
>>    data distribution and key distribution.
>>
>> Perhaps this sounds too technically abstract.  Let me put it more
>> simply: I believe I could use this license to coerce someone into giving
>> up private data or encryption keys in a peer to peer network.
>>
>> > Thus, the information that needs to be provided, including cryptographic
>> > keys, is limited to that information that would prevent compilation or
>> > access to functionality, or would deny the Recipient full control over
>> the
>> > Recipient's own user data. The normal system uses of cryptography are not
>> > implicated. Nor are the uses of cryptography in a distributed systems for
>> > addressing or authentication, excepting the use of a user's keys to
>> > validate an agent's actions (which belong to the user anyway).
>>
>> You seem more confident than I am in terms of what these categories are,
>> so I think it would be useful for you to give us some scenarios, then we
>> can work through them:
>>
>>  - A requirement for distributing "recipient data".
>>  - A situation where two peers communicate, but a requirement for
>>    recipient data distribution does not become invoked.
>>  - A scenario by which cryptographic key material, in relationship to
>>    user data, must be provided.
>>  - A scenario where the remote program has cryptographic key material
>>    that is not required to be distributed.  This one is very important
>>    in that the question must be asked: "what part of the license makes
>>    this categorically excluded from its requirement"?
>>
>> With those in place I think we can have a better analysis.
>>
>> Finally, I am going to repeat part of what I said in the cap-talk
>> thread: the choice of the license name is ironic, because though the
>> goals are good (ensure autonomy of users), it may actually create
>> difficulties in complying in the kinds of systems that actually are
>> doing so through cryptography and protocols (ocap actor model systems,
>> encrypted data vaults).  The problem is one that must be addressed for
>> the sake of user freedom, but I believe it is being addressed on the
>> incorrect layer.  Here we see an attempt to address it on the license
>> layer, but IMO this is wrong: there are active systems that exist and
>> are addressing this in such a way that the cryptographic tooling and
>> protocols themselves are the ones that help ensure greater user
>> autonomy.
>>
>> Thank you,
>>  - Chris
>>
>> > Thanks,
>> > Van
>> >
>> >
>> >
>> > On Tue, Feb 11, 2020 at 6:54 AM Christopher Lemmer Webber <
>> > cwebber at dustycloud.org> wrote:
>> >
>> >> Where in the license is this distinction made?
>> >>
>> >> At any rate, I'm not convinced such a distinction exists.  I
>> >> increasingly work with peer to peer systems where the distinction
>> >> between "user" and "system" and even "client" and "server" no longer
>> >> exist.  I don't believe it is possible to make a sound distinction, and
>> >> at any rate I don't see one in the license.  But perhaps I am missing
>> >> something?
>> >>
>> >> Regardless, these are not my only concerns.  I will write them up today.
>> >>
>> >>
>> >> VanL writes:
>> >>
>> >> > I definitely want to hear any concerns... but I will also note that
>> the
>> >> > crypto portions of the license were reviewed by a number of people who
>> >> are
>> >> > expert in that space and they approved.
>> >> >
>> >> > My best guess is that you are concerned that this requires the
>> disclosure
>> >> > of user-specific keys, and so you think that means that traditional
>> >> crypto
>> >> > which relies on a private key or private cert would need to be
>> disclosed.
>> >> > This is incorrect.
>> >> >
>> >> > They difference is between user keys and system keys. User keys form
>> the
>> >> > basis of a user's identity and control over computation or data. Under
>> >> the
>> >> > license, they must be controlled by the user alone.
>> >> >
>> >> > System keys, however, used for things like TLS and SSH, are not User
>> Data
>> >> > within the scope of that term. They may be kept confidential and
>> secure.
>> >> >
>> >> > Thanks,
>> >> > Van
>> >> >
>> >> > __________________________
>> >> > Van Lindberg
>> >> > van.lindberg at gmail.com
>> >> > m: 214.364.7985
>> >> >
>> >> > On Mon, Feb 10, 2020, 7:17 PM Christopher Lemmer Webber <
>> >> > cwebber at dustycloud.org> wrote:
>> >> >
>> >> >> Josh Berkus writes:
>> >> >>
>> >> >> > On 1/7/20 11:00 AM, Pamela Chestek wrote:
>> >> >> >> The discussion is still active so it will not be considered at the
>> >> next
>> >> >> >> Board meeting, which is this Friday. The soonest would be the
>> >> February
>> >> >> >> Board meeting.
>> >> >> >
>> >> >> > So, it's been a month since there's been any discussion about the
>> CAL.
>> >> >> > Pamela, can we take a poll of how people feel about the license?
>> >> >> > Pass/Reject/MoreDiscussionNeeded?
>> >> >>
>> >> >> I'm not very sure if I'm in the right place to state this, but I'd
>> say
>> >> >> "Reject" or at least "MoreDiscussionNeeded".  I believe there are
>> very
>> >> >> serious problems in the license that will (ironically, due to its
>> name)
>> >> >> prevent the ability to have safely private networks on
>> cryptographically
>> >> >> secure peer to peer networks.  I believe I can demonstrate the
>> privacy
>> >> >> risks, and spend most of tomorrow doing a detailed and longer writeup
>> >> >> about my concerns.  Note that I don't think it's any malicious
>> intention
>> >> >> of the author to introduce these problems; I think Van is acting in
>> good
>> >> >> faith and interest there, but nonetheless I think the concerns exist
>> and
>> >> >> are very grave, if I understand correctly.
>> >> >>
>> >> >> If I am going to air them before the board meeting, am I doing it in
>> the
>> >> >> right place here?  If so, I will follow up on the thread here
>> tomorrow.
>> >> >>
>> >> >>  - Chris
>> >> >>
>> >> >> PS: I'm sorry I haven't aired my very serious concerns earlier.  Van
>> >> >> asked me personally to review at last year's CopyleftConf and I never
>> >> >> got around to writing up my thoughts.  I regret that, and wish I had
>> >> >> done so sooner... maybe I could have prevented a lot of trouble.
>> >> >> Nonetheless I think it's important that I write them up now; I'm
>> >> >> guessing we're in the "speak now or forever hold your peace" moment
>> >> >> though, so I'm trying to articulate my concerns before it's too late.
>> >> >>
>> >> >> _______________________________________________
>> >> >> License-review mailing list
>> >> >> License-review at lists.opensource.org
>> >> >>
>> >> >>
>> >>
>> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
>> >> >>
>> >> > _______________________________________________
>> >> > License-review mailing list
>> >> > License-review at lists.opensource.org
>> >> >
>> >>
>> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
>> >>
>> >> _______________________________________________
>> >> License-review mailing list
>> >> License-review at lists.opensource.org
>> >>
>> >>
>> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
>> >>
>> > _______________________________________________
>> > License-review mailing list
>> > License-review at lists.opensource.org
>> >
>> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
>>
>> _______________________________________________
>> License-review mailing list
>> License-review at lists.opensource.org
>>
>> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
>>

More information about the License-review mailing list