Opposing the TLS authorization standard

Brendan Ribera <brendan.ribera@gmail.com> Tue, 10 February 2009 21:32 UTC

Return-Path: <brendan.ribera@gmail.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A1E528C1EE for <ietf@core3.amsl.com>; Tue, 10 Feb 2009 13:32:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Jq7VFKhQ1nf for <ietf@core3.amsl.com>; Tue, 10 Feb 2009 13:32:38 -0800 (PST)
Received: from mail-ew0-f21.google.com (mail-ew0-f21.google.com [209.85.219.21]) by core3.amsl.com (Postfix) with ESMTP id DE4633A6852 for <ietf@ietf.org>; Tue, 10 Feb 2009 13:32:37 -0800 (PST)
Received: by ewy14 with SMTP id 14so75425ewy.13 for <ietf@ietf.org>; Tue, 10 Feb 2009 13:32:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=waijH/zprqZ8CMgoqYuLq/x7P7rVt64XmMIvyQCohSQ=; b=BRWlzvaqDN/unnZdIEf4mIoBRCWt4soq8nArUmk5sCFTy3h5uYG1OtsPG+BIhUeZwI 9q5iOdzxH79IAp5OJ77BeBp5gOGj8INiVcjd65C7V9T+tCfRGxPJM7a+wsoR18gT+N8j 3zQHr8HwMGThiyR9WLOqTY+nBhfH646S136E8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=NlNWlkums1h6aXTIID+RgEw8XKtSdmxl79IIKKyX9fxHzKmOrINMASeHcfeRK2t9Rq qXdZScZddomD2uTNop9v9+2QLqc7eIwk6LafhSOCwp1XHdfwg+ucn0LuoDV0mdp4P86z K/n8ylYIBwtfLdaWyM8ZbKOIG6ZKJbW33+Bo8=
MIME-Version: 1.0
Received: by 10.142.162.9 with SMTP id k9mr3709138wfe.309.1234301217650; Tue, 10 Feb 2009 13:26:57 -0800 (PST)
Date: Tue, 10 Feb 2009 13:26:57 -0800
Message-ID: <ccad12500902101326g2041074dhfca5b84971cff2e8@mail.gmail.com>
Subject: Opposing the TLS authorization standard
From: Brendan Ribera <brendan.ribera@gmail.com>
To: ietf@ietf.org
Content-Type: multipart/alternative; boundary="000e0cd150b69fb6b80462972518"
X-Mailman-Approved-At: Tue, 10 Feb 2009 16:51:53 -0800
Cc: campaigns@fsf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Feb 2009 21:33:41 -0000

Hello,

I am writing because I am concerned about the proposed TLS authorization
standard (draft-housley-tls-authz-extns) that the IETF is considering.  I
understand that the IETF rejected a similar standard in 2006 due to
potential patent conflicts with RedPhone Security.  Despite the fact that
RedPhone Security have filed IPR Disclosure 1026 indicating that the
proposed standard does not infringe upon their intellectual property rights,
the IETF ought to take the same course as in 2006 and eschew this standard.

The potential for future conflict is too high to ignore in good conscience,
and it would be unconscionable to standardize around any company's
proprietary information.  Unless RedPhone Security is willing to provide --
to all users -- a royalty-free license of the patent in question, users of
this proposed standard will be threatened by the patent.  It hangs the
threat of lawsuits over the heads of users, and provides undue input and
control over the standard and its future to a single patent-holder.  It is
very dangerous to put forth a standard with such dubious future prospects.

Users of standards put forth by the IETF necessarily and rightfully expect
to be unencumbered by patent concerns.  Because of the obvious and
intractible concerns with RedPhone Security's patent, the IETF should only
consider approving this standard (on any level) if all users are granted a
royalty-free license of the patent.  Otherwise, the standard is only
available to those who can afford it, and its future is ultimately
controlled by RedPhone Security.

Sincerely,
Brendan Ribera