Re: Fourth Last Call: draft-housley-tls-authz-extns

Phil Pennock <ietf-spodhuis@spodhuis.org> Thu, 15 January 2009 01:33 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FB1E3A6AA9; Wed, 14 Jan 2009 17:33:03 -0800 (PST)
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 919333A6A65 for <ietf@core3.amsl.com>; Wed, 14 Jan 2009 17:33:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 8xaczxqy5WuO for <ietf@core3.amsl.com>; Wed, 14 Jan 2009 17:33:01 -0800 (PST)
Received: from mx.spodhuis.org (smtp.spodhuis.org [IPv6:2001:980:fff:31::a]) by core3.amsl.com (Postfix) with ESMTP id 5E2523A6A55 for <ietf@ietf.org>; Wed, 14 Jan 2009 17:33:01 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=d200807; d=spodhuis.org; h=Received:Date:From:To:Subject:Message-ID:Mail-Followup-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To; b=NWdzIeIWz2jvfbe5yMjzoYXAhIgmEgOEB7PSislmX6G+fOMs9QZCxj8VMb23Xa3oH+Xu0z1F70UcW2L8ZI7l1YP7bVoeQts5IZxrlPk5cdriJzfVHjq+6PxbrVjgwS8II3jRiyqfMI1MtBMNcxnmj7QvGfqypHaJgtgMarEH9k4=;
Received: by smtp.spodhuis.org with local id 1LNH6C-0005O1-AZ; Thu, 15 Jan 2009 01:32:44 +0000
Date: Wed, 14 Jan 2009 17:32:44 -0800
From: Phil Pennock <ietf-spodhuis@spodhuis.org>
To: ietf@ietf.org
Subject: Re: Fourth Last Call: draft-housley-tls-authz-extns
Message-ID: <20090115013244.GA20394@redoubt.spodhuis.org>
Mail-Followup-To: ietf@ietf.org
References: <20090114161820.BFA4228C1BB@core3.amsl.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20090114161820.BFA4228C1BB@core3.amsl.com>
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-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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On 2009-01-14 at 08:18 -0800, The IESG wrote:
> Since the third Last Call, RedPhone Security filed IETF IPR disclosure
> 1026.  This disclosure statement asserts in part that "the techniques
> for sending and receiving authorizations defined in TLS Authorizations
> Extensions (version draft-housley-tls-authz-extns-07.txt) do not
> infringe upon RedPhone Security's intellectual property rights".  The
> full text of IPR disclosure 1026 is available at:
> 
> 	https://datatracker.ietf.org/ipr/1026/

I've read through that.

So, implementing the part of any useful application which does the
protocol encoding/decoding is not encumbered, but doing anything
practical with it is?

In particular, RedPhone disavow patent encumbrance over
sending/receiving but not upon, eg, constructing the authorizations to
send or interpreting them; then, they explicitly note cases which may be
encumbered, such as looking up the claimed authorizer to ensure that
they are in fact permitted to make such an authorization, or using data
conveyed in the extension after checking the signature.

Either the security policy is statically configured, so a lookup needs
to be performed, or the security policy is carried in the TLS
transaction and the protocol signatures need to be verified so that
arbitrary assertions aren't trusted.

I'm not a stake-holder in this and haven't previously contributed, so
have no reasonable voice in objecting, but I am trying to understand the
situation.

It's of little value to be able to send data across the wire if that
data is not permitted to convey useful information.

For the people who want this draft published (and perhaps have a pending
implementation), would you please humour me by offering some usage
scenarios, other than debugging or toys, which would meet security
review and which are not covered by the four points which the
patent-holder notes as potentially encumbered?

I'm far from a subject matter expert, so there may well be such cases; I
hope that the act of laying out a counter-example or two will make it
clearer for all concerned parties what can and can't be done and
demonstrate practical use to publication.

Thanks,
-Phil
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf