Subject: Re: [wpkops] Third draft charter proposal

From: =JeffH <[email-masked]>
Date: Mon, 17 Sep 2012 11:40:09 -0700

+1 to Stephen's comments.

Also, I think the first paragraph's definition of "Web PKI" merits a bit more 
full definition. Various folks that aren't quite as familiar with all this may 
well be reading and trying to understand the charter.

Suggested enhancement (first paragraph becomes two paragraphs)..

###
The Web PKI is the set of systems and procedures most commonly used, in 
conjunction with security protocols such as TLS, to protect the confidentiality, 
integrity and authenticity of communications between Web browsers and Web 
content servers. More specifically, the Web PKI (as considered here) consists of 
the actual contents of the certificates issued to Web application providers by 
Certification Authorities (CAs), the certificate validation services provided by 
the Authorities to web browsers and their users, and the TLS/SSL protocol stacks 
embedded in web servers and browsers.

The Web PKI first appeared in 1993 or thereabouts and has developed continuously 
in a somewhat organic fashion since then.  Across all the suppliers and the 
point releases of their products, there are now hundreds of variations on the 
Web PKI in regular use.  And this can be a source of problems for end-users, 
certificate holders, and certificate issuers.
###

(though, this isn't critial and shouldn't hold anything up)

HTH,

=JeffH

---

From: Carl Wallace <[email-masked]>
Date: Mon, 17 Sep 2012 14:59:10 -0400

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