Re: [wpkops] Third draft charter proposal

Carl Wallace <carl@redhoundsoftware.com> Mon, 17 September 2012 18:59 UTC

Return-Path: <carl@redhoundsoftware.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 7408421F8674 for <wpkops@ietfa.amsl.com>; Mon, 17 Sep 2012 11:59:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.861
X-Spam-Level:
X-Spam-Status: No, score=-4.861 tagged_above=-999 required=5 tests=[AWL=-2.659, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1]
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 6+4eUr404YK8 for <wpkops@ietfa.amsl.com>; Mon, 17 Sep 2012 11:59:18 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id B987721F8668 for <wpkops@ietf.org>; Mon, 17 Sep 2012 11:59:17 -0700 (PDT)
Received: by vbbfc26 with SMTP id fc26so8487596vbb.31 for <wpkops@ietf.org>; Mon, 17 Sep 2012 11:59:17 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic:in-reply-to :mime-version:content-type:x-gm-message-state; bh=LYGm0jealeG70302DSmWV5Yizzhs49D/h49p0Eoqcr8=; b=MSkZV1Irfz0fNrzzgSirgFlrMr9dNEICLBdUghS+NfDZRWnm9xmvW78P54BE4TN8Qb JUNQeHIIAxnql//lynJvJUPbhYKXUasARtyvvTNyrG/Fe8R80vF+hJRT3F38aDd2vUNb hwCkz0s5CSkGINj/gGDvSIuBxcVeO3QEE7CtyglLoITvVjNSVsb1leDPGvV6wLn9e2VH dMLtHNpXVA6yKlE/Zc7atPkY/W09xpcsLeOgftaMScQkHD6yO0KfrehqSaDXfsUs3rmO o1w5XDd7FvPlXm5nCIrXVLE1fxvQXChN/THj9RvlZ3A13yocoImdFIJA1zPlurOLT4x9 JQTg==
Received: by 10.220.107.136 with SMTP id b8mr7919027vcp.17.1347908357031; Mon, 17 Sep 2012 11:59:17 -0700 (PDT)
Received: from [192.168.2.8] (pool-72-66-83-116.washdc.fios.verizon.net. [72.66.83.116]) by mx.google.com with ESMTPS id f10sm1614792vdk.5.2012.09.17.11.59.13 (version=SSLv3 cipher=OTHER); Mon, 17 Sep 2012 11:59:15 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.2.3.120616
Date: Mon, 17 Sep 2012 14:59:10 -0400
From: Carl Wallace <carl@redhoundsoftware.com>
To: Tim Moses <tim.moses@entrust.com>, "wpkops@ietf.org" <wpkops@ietf.org>
Message-ID: <CC7CE89D.2EFF7%carl@redhoundsoftware.com>
Thread-Topic: [wpkops] Third draft charter proposal
In-Reply-To: <CC7B50EA.2D22F%tim.moses@entrust.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3430738754_3417413"
X-Gm-Message-State: ALoCoQntAgNfjsyG4va3P5EVeVw++nNiYU40GlFIRNX0f+j5KMyuqXXr+eVpgXy/bNy8teu1Gc30
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: Mon, 17 Sep 2012 18:59:18 -0000

From:  Tim Moses <tim.moses@entrust.com>
Date:  Saturday, September 15, 2012 12:00 PM
To:  "wpkops@ietf.org" <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.