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

Russ Housley <housley@vigilsec.com> Thu, 15 January 2009 16:22 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 1F3733A69E7; Thu, 15 Jan 2009 08:22:42 -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 282313A69E7 for <ietf@core3.amsl.com>; Thu, 15 Jan 2009 08:22:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.501
X-Spam-Level:
X-Spam-Status: No, score=-102.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 u9Z970R9GeoG for <ietf@core3.amsl.com>; Thu, 15 Jan 2009 08:22:40 -0800 (PST)
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by core3.amsl.com (Postfix) with SMTP id 3DEC23A67F1 for <ietf@ietf.org>; Thu, 15 Jan 2009 08:22:40 -0800 (PST)
Received: (qmail 13699 invoked by uid 0); 15 Jan 2009 16:22:21 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.143.189) by woodstock.binhost.com with SMTP; 15 Jan 2009 16:22:21 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 15 Jan 2009 11:05:05 -0500
To: Phil Pennock <ietf-spodhuis@spodhuis.org>, ietf@ietf.org
From: Russ Housley <housley@vigilsec.com>
Subject: Re: Fourth Last Call: draft-housley-tls-authz-extns
In-Reply-To: <20090115013244.GA20394@redoubt.spodhuis.org>
References: <20090114161820.BFA4228C1BB@core3.amsl.com> <20090115013244.GA20394@redoubt.spodhuis.org>
Mime-Version: 1.0
Message-Id: <20090115162240.3DEC23A67F1@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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Phil:

>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'll offer one based on attribute certificates (see RFC 3281).  If 
the attribute certificate policy does not use a critical certificate 
policy identifier that is within an arc registered to RedPhone 
Security (e.g. iso.org.dod.internet.private.enterprise.23106), then 
the most straightforward deployments would not encounter problems 
with this IPR Statement.  RFC 3281 specifies ways to carry access 
identities, group memberships, roles, and clearances in attribute 
certificates.  As long as these are not coupled to signed agreements 
such as contracts, as is their normal use, then I cannot see problems 
with this IPR statement.

This is one example.  I believe there are many more.

Russ

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf