Re: [wpkops] Third draft charter proposal

Carl Wallace <carl@redhoundsoftware.com> Thu, 04 October 2012 15:48 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 6987921F8610 for <wpkops@ietfa.amsl.com>; Thu, 4 Oct 2012 08:48:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.418
X-Spam-Level:
X-Spam-Status: No, score=-4.418 tagged_above=-999 required=5 tests=[AWL=-2.216, 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 UVSfNYpX2OKe for <wpkops@ietfa.amsl.com>; Thu, 4 Oct 2012 08:48:35 -0700 (PDT)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0077C21F8504 for <wpkops@ietf.org>; Thu, 4 Oct 2012 08:48:34 -0700 (PDT)
Received: by mail-qc0-f172.google.com with SMTP id c10so597104qca.31 for <wpkops@ietf.org>; Thu, 04 Oct 2012 08:48:34 -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:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:x-gm-message-state; bh=K8PEivYAJBJahJ9nCVA3jjnBp7aZdTbCCnCM7nCY/dA=; b=Nl5UqGIlC6s7BU0ytI6bhLdRoxgrpzDjHd2j06+/eN+7oyJmlvETerrwszRof1IfBx 0Y/g0ynEucBtzrJb/7dE+dvvIT5OhfEEIoiJrbHbdBpO57tJ2AVU1tdMT+Z8UAafDee0 cUvl4jNN2+CK6v4RqHP0G0AQxbuRQjq6jRHysEv5DwIYG0zww9HayHNlF6hkMXN2i7sr dd0W69pFCAOrdmB2hBGcT26/VSGO/X3eMW3Jqdz9XPGOymJtpY+/coPTvwFv1lSxk1gw BGApXkvWMNM3kkyY9IAWcG08uJilZ8dM6fVDvIbtMC9tB+oUX4czL3Fbysopdth2EaHk JUBQ==
Received: by 10.49.132.65 with SMTP id os1mr19601114qeb.7.1349365714167; Thu, 04 Oct 2012 08:48:34 -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 gw9sm7484887qab.4.2012.10.04.08.48.30 (version=SSLv3 cipher=OTHER); Thu, 04 Oct 2012 08:48:32 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.2.4.120824
Date: Thu, 04 Oct 2012 11:48:23 -0400
From: Carl Wallace <carl@redhoundsoftware.com>
To: Tim Moses <tim.moses@entrust.com>
Message-ID: <CC9321A6.32E72%carl@redhoundsoftware.com>
Thread-Topic: [wpkops] Third draft charter proposal
In-Reply-To: <5B68A271B9C97046963CB6A5B8D6F62C3A595D11@SOTTEXCH10.corp.ad.entrust.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3432196113_1245578"
X-Gm-Message-State: ALoCoQnVTEzbdxZGmCN3mgwZYCuI6yiA1sMUdUTTsHuiTzp9QI+4QqlOfX25ktGm6Tp3OuBZmMEw
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:48:37 -0000

A few items come to mind.   The CAPI TA store is reused by many
applications.  The need to have it full of more or less unconstrained trust
anchors to avoid "breaking the internet" when browsing leaves users of other
applications (email, doc signing, etc) trusting an unnecessarily large and
unintended set of PKIs.  Problems can arise when reusing certificate stores,
including sluggish performance or misbehavior (for example, client
authentication is not possible in some cases without cleaning up
certificates in a shared certificate store).  Allocation of privileges to
reused trust anchors can cause problems too, such as settings that enable
TAs to terminate certification paths used to validate locally trusted OCSP
responses.  The settings may be appropriate in some scenarios, but not for
global, multi-application use.

I'm not sure my examples should be used to answer scope questions.  More
generally, reuse of documented mechanisms should be considered and noted as
this work proceeds.

From:  Tim Moses <tim.moses@entrust.com>
Date:  Thursday, October 4, 2012 11:09 AM
To:  Carl Wallace <carl@redhoundsoftware.com>
Cc:  "wpkops@ietf.org" <wpkops@ietf.org>
Subject:  RE: [wpkops] Third draft charter proposal

> 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>
> 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.
> 
>  
> 
>