Subject: Re: [wpkops] Third draft charter proposal

From: Tim Moses <[email-masked]>
Date: Thu, 4 Oct 2012 15:09:27 +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:[email-masked]]
Sent: Monday, September 17, 2012 2:59 PM
To: Tim Moses; [email-masked]
Subject: Re: [wpkops] Third draft charter proposal

From: Tim Moses <[email-masked]<mailto:[email-masked]>>
Date: Saturday, September 15, 2012 12:00 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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.

---

From: Carl Wallace <[email-masked]>
Date: Thu, 04 Oct 2012 11:48:23 -0400

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 <[email-masked]>
Date:  Thursday, October 4, 2012 11:09 AM
To:  Carl Wallace <[email-masked]>
Cc:  "[email-masked]" <[email-masked]>
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: Tim Moses <[email-masked]>
> To: "[email-masked]" <[email-masked]>
>> 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.
> 
>  
> 
>> 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.
> 
>  
> 
> 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.
> 
>  
> 
>