Re: [wpkops] Third draft charter proposal

Tim Moses <tim.moses@entrust.com> Thu, 04 October 2012 15:09 UTC

Return-Path: <tim.moses@entrust.com>
X-Original-To: wpkops@ietfa.amsl.com
Delivered-To: wpkops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 489A121F85FC for <wpkops@ietfa.amsl.com>; Thu, 4 Oct 2012 08:09:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.353
X-Spam-Level:
X-Spam-Status: No, score=-2.353 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q44iEcyfLTUO for <wpkops@ietfa.amsl.com>; Thu, 4 Oct 2012 08:09:42 -0700 (PDT)
Received: from ipedge2.entrust.com (ipedge2.entrust.com [216.191.252.25]) by ietfa.amsl.com (Postfix) with ESMTP id 5689D21F8539 for <wpkops@ietf.org>; Thu, 4 Oct 2012 08:09:42 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.80,535,1344225600"; d="scan'208,217";a="2109022"
Received: from unknown (HELO SOTTEXCHCAS2.corp.ad.entrust.com) ([10.4.51.224]) by ipedge2.entrust.com with ESMTP; 04 Oct 2012 11:09:27 -0400
Received: from SOTTEXCH10.corp.ad.entrust.com ([fe80::389b:f45b:7ea1:79b7]) by SOTTEXCHCAS2.corp.ad.entrust.com ([::1]) with mapi id 14.02.0318.001; Thu, 4 Oct 2012 11:09:27 -0400
From: Tim Moses <tim.moses@entrust.com>
To: 'Carl Wallace' <carl@redhoundsoftware.com>
Thread-Topic: [wpkops] Third draft charter proposal
Thread-Index: AQHNlQaFt+5+AKCyQmSih2MU3O89AZepVnCg
Date: Thu, 04 Oct 2012 15:09:27 +0000
Message-ID: <5B68A271B9C97046963CB6A5B8D6F62C3A595D11@SOTTEXCH10.corp.ad.entrust.com>
References: <CC7B50EA.2D22F%tim.moses@entrust.com> <CC7CE89D.2EFF7%carl@redhoundsoftware.com>
In-Reply-To: <CC7CE89D.2EFF7%carl@redhoundsoftware.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.4.160.88]
Content-Type: multipart/alternative; boundary="_000_5B68A271B9C97046963CB6A5B8D6F62C3A595D11SOTTEXCH10corpa_"
MIME-Version: 1.0
Cc: "wpkops@ietf.org" <wpkops@ietf.org>
Subject: Re: [wpkops] Third draft charter proposal
X-BeenThere: wpkops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <wpkops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/wpkops>, <mailto:wpkops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/wpkops>
List-Post: <mailto:wpkops@ietf.org>
List-Help: <mailto:wpkops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/wpkops>, <mailto:wpkops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Oct 2012 15:09:44 -0000

Hi Carl.  I am just taking a crack at updating the draft charter.  Can you provide some examples of "problems created by reuse"?  That, I think, will be important for dealing with scope questions when they come up.  Thanks a lot.  All the best.  Tim.

From: Carl Wallace [mailto:carl@redhoundsoftware.com]
Sent: Monday, September 17, 2012 2:59 PM
To: Tim Moses; wpkops@ietf.org
Subject: Re: [wpkops] Third draft charter proposal


From: Tim Moses <tim.moses@entrust.com<mailto:tim.moses@entrust.com>>
Date: Saturday, September 15, 2012 12:00 PM
To: "wpkops@ietf.org<mailto:wpkops@ietf.org>" <wpkops@ietf.org<mailto:wpkops@ietf.org>>
Subject: [wpkops] Third draft charter proposal

<snip>
Additionally, a number of applications (such as client authentication, document signing, code signing, and email) may use the same trust anchors and certificate-handling libraries as the ones used for server authentication on the Web.  Nevertheless, they may use the results in a way that is visibly different from the way in which they are used for server authentication.

I think the concern is that reused mechanisms can interfere with each other, not that results are used differently.

While these applications are considered outside the scope of this working group, deliverables should (wherever practical within the available expertise and time) identify other applications that exhibit identical behavior and identify the implications of that behavior where they differ from those for server authentication.

I don't understand the reference to identical behavior.  I suggest the following:


Additionally, a number of applications (such as client authentication, document signing, code signing, and email) use the same trust anchors and certificate processing mechanisms as used for server authentication on the Web.  This reuse creates problems in some situations.  While these applications are outside the scope of this working group, deliverables should (wherever practical within the available expertise and time) identify mechanisms that are reused by other applications and identify the implications of that reuse.