Right, but obviously seeking to narrow the scope we need a wider vision,
right? Exclusion of "documents etc." has its historical reasons, not
technological. Why not to form a generic vision and based on that try to
figure out the scope of interest.
Thanks,
M.D.
On 8/23/2012 12:27 AM, Hill, Brad wrote:
I agree with Tim that we should start with a narrow scope focused on
the Web PKI rather than documents, etc., I also think there are cases
that are on the edge -- like the programmatic HTTP clients used by
mobile aps, embedded browsing contexts with different PKI error
handling logic than standalone ones, and, towards the more complex
end, web services that use HTTP and the web PKI explicitly but might
also use other transports and trust models. Not clear from the draft
charter where to draw the line among these, but there is plenty of
work to do and that needs doing urgently.
Brad Hill
*From:*[email protected] [mailto:[email protected]] *On
Behalf Of *Tim Moses
*Sent:* Wednesday, August 22, 2012 5:45 AM
*To:* '[email protected]'
*Subject:* [wpkops] First draft charter proposal
Colleagues -- Here is a first draft of a charter proposal. Please
give it some thought and share the results of your deliberations.
Thanks a lot. All the best. Tim.
The Web PKI is the set of systems and procedures most commonly used to
protect the confidentiality, integrity and authenticity of
communications between Web browsers and Web content servers. It 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
both for end-users and certificate issuers.
For end-users, there is no clear view whether certificate "problems"
remain when they see indication of a "good" connection. For instance,
in some browsers, a "good" indication may be displayed when a
"revoked" response has been received and "accepted" by the user.
Whereas, other browsers may refuse to display the contents under these
circumstances.
And for issuers, it can be difficult to predict what proportion of the
user population will accept a certificate chain with certain
characteristics. For instance, when a browser includes a nonce in an
OCSP request but the server supplies a response that does not include
the nonce, it is hard to know which browsers will accept and which
will reject the response.
Starting from the premise that more consistency in Web security
behavior is desirable, a natural first step would be to document
current and historic browser and server behavior.
Future activities may attempt to prescribe how the Web PKI "should"
work, and the prescription may turn out to be a proper subset of the
PKIX PKI. However, that task is explicitly not a goal of the proposed
working group. Instead, the group's goal is merely to describe how
the Web PKI "actually" works in the set of browsers and servers that
are in common use today.
Additionally, a number of applications (other than the Web) may use
the same trust anchors as the ones used by the Web. These
applications include: document signing; code signing; and email. They
may use PKI in a way that differs from the way in which the Web uses
it. Therefore, these applications are explicitly out of scope for the
working group.
Also, the reliability of the Web PKI depends critically on the
practices of its certificate issuers. However, the topic of practices
is outside the scope of the IETF. Therefore, this will be left to
other competent bodies.
That there are technical shortcomings with Web PKI, as it is practiced
today, is well recognized. And, that there is also some urgency in
addressing these shortcomings is also well recognized. But, it is
felt that too much haste can be counter-productive. The expectation
is that the work of this group will bring to light, in a systematic
way, aspects of the Web PKI that should be progressed in future
working groups of the IETF's Security Area, and that suppliers will be
willing to participate in those working groups and modify their
products to comply with their standards.
Given the urgency of the required developments and the scale of the
task, it is agreed that adherence to the published schedule should
take precedence over completeness of the results. The working group
should focus its initial attention on the browser and server versions
that make up the largest part of the desktop and mobile Web today.
The output documents will all be BCP-style RFCs.
1.Agree the working group charter (1 month).
2.Catalog the products and versions to be analyzed (1 month).
3.First WG draft of "trust model" document (4 months).
4.First WG draft of "public-key submission and certificate
installation" document (4 months).
5.First WG draft of "certificate, CRL, and OCSP profile" document (8
months).
6.First WG draft of "certificate, CRL, and OCSP processing" document
(12 months).
7.First WG draft of "certificate re-issuance" document (4 months).
8.First WG draft of "certificate renewal" document (4 months).
9.First WG draft of "certificate revocation" document (8 months).
10.IESG submission of "trust model" document (16 months).
11.IESG submission of "public-key submission and certificate
installation" document (16 months).
12.IESG submission of "certificate, CRL, and OCSP profile" document
(20 months).
13.IESG submission of "certificate, CRL, and OCSP processing" document
(24 months).
14.IESG submission of "certificate re-issuance" document (16 months).
15.IESG submission of "certificate renewal" document (16 months).
16.IESG submission of "certificate revocation" document (20 months)
The schedule is predicated upon the group's ability to recruit a
sufficient number of editors and engage either the relevant product
experts or other experts willing to test the selected product
configurations.
T: +1 613 270 3183
_______________________________________________
wpkops mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/wpkops
_______________________________________________
wpkops mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/wpkops
