Regarding Transport Layer Security (TLS) Authorization Extensions

Alex Loret de Mola <edgarverona@gmail.com> Mon, 09 February 2009 23:20 UTC

Return-Path: <edgarverona@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 967243A69A9 for <ietf@core3.amsl.com>; Mon, 9 Feb 2009 15:20:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 DJAS4bdgysGA for <ietf@core3.amsl.com>; Mon, 9 Feb 2009 15:20:37 -0800 (PST)
Received: from mail-gx0-f21.google.com (mail-gx0-f21.google.com [209.85.217.21]) by core3.amsl.com (Postfix) with ESMTP id 86CE63A6874 for <ietf@ietf.org>; Mon, 9 Feb 2009 15:20:37 -0800 (PST)
Received: by gxk14 with SMTP id 14so1986933gxk.13 for <ietf@ietf.org>; Mon, 09 Feb 2009 15:20:39 -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:content-type:content-transfer-encoding; bh=XA8psGQfa7j8MNRQtfGsF7dn/CTtrhWp7VueDhPUegE=; b=CEfNrcvOyKh6Cg1CacDCJNGGz6nrl29HeOnGK/+OEQpSbPOZF/tUOMGidKwkLWp110 Lk9zurmMFQzt0kj4PryBn6VEWIcIj+uRfKff54p94JhU+gHpyt/3nur4crQvAwG97a01 gPtQFQuARafa79fiygvcCetyxz3NxAlq+nDus=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=FHzsL+HOpie/buGW7uarwRg0g4SSs1U2Se1WT/+N5QcF0001WztjAXlmI5N1O4bp3W jF044GexyixKDMM6Q+i8/aaqvdeT9Y+FeUQX876SxLASi1rcUd1HacuofZIZr3pdZmEw ZGgMVO3e8of9f8EkckBY9O9CmF8KQFP3nURgE=
MIME-Version: 1.0
Received: by 10.90.53.4 with SMTP id b4mr621891aga.88.1234221639835; Mon, 09 Feb 2009 15:20:39 -0800 (PST)
Date: Mon, 09 Feb 2009 18:20:39 -0500
Message-ID: <789dbae90902091520r671a5670ud02a66dcf578eb5f@mail.gmail.com>
Subject: Regarding Transport Layer Security (TLS) Authorization Extensions
From: Alex Loret de Mola <edgarverona@gmail.com>
To: ietf@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
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: Mon, 09 Feb 2009 23:20:38 -0000

Fellow members of the IETF:

I would like to add my voice to those who have expressed discontent in
the proposed TLS Authorization Extensions.

The use of a Patented standard (especially one that may have such
patents legally enforced, as in the case of RedPhone) appears to me to
be in violation of our mission statement (RFC 3935).  Our mission
statement dictates that "when the IETF takes ownership of a protocol
or function, it accepts the responsibility for all aspects of the
protocol.."  Surely we cannot take ownership of a protocol which is
both proprietary and actively owned by a corporation.

Contrary to the opinions of some of my colleagues, even if RedPhone
grants all users a royalty-free license to implement and use such a
protocol, I assert that the IETF would never truly be able to take
*ownership* of said standard as is required by our mission statement.
The final say would always be the responsibility of RedPhone, the true
owners of the standard, and the IETF will have effectively given the
green light to standardize a protocol that it can hold no influence
over.

This standard should not be accepted, even for experimental use, while
a patent is held (and control assertable) by an external corporation
over the will of the IETF.

Please consider this fact, and preserve the solvency of the IETF's
mission statement by disallowing the standardization of proprietary
protocols such as those defined in the Transport Layer Security (TLS)
Authorization Extensions internet draft.

Sincerely,

Alexander Loret de Mola
Lead Software Engineer, iScan Services