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.mo...@entrust.com> Date: Thursday, October 4, 2012 11:09 AM To: Carl Wallace <c...@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:c...@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.mo...@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. > > > >
_______________________________________________ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops
