On 8/23/2012 1:29 AM, Hill, Brad wrote:
Moudrick Dadashov wrote:
>Right, but obviously seeking to narrow the scope we need a wider
vision, right?
>Exclusion of "documents etc." has its historical reasons, not
technological.
I think it does have technological reasons: Document and code signing
has to:
* Deal with problems of long-lived artifacts -- including signed
objects that may outlive the certificates used to sign them
* Work by default without a direct connection to the entity in control
of the certificate
* Support entirely offline verification
or just to identify those generic building blocks that are common to
many similar use scenarios. If web client authentication fits into the
"narrowed scope" why web signing doesn't?
This has also led to different practices about revocation and
blacklisting, use of third party time stamping authorities, etc. The
differences are substantial.
Sure, service/application specific specialties are obviously out of scope.
Code signing in particular is also HIGHLY vendor-specific. I may be
mistaken, but my impression is that it's not meaningful at all to talk
about a single set of practices around code signing that is common
across multiple platforms -- Java, Apple App Store, Android Apps,
Microsoft Authenticode, Strong Named Assemblies in .NET, etc.
Java and Authenticode may have interoperable certificate formats, but
how they are used still differs greatly. Individual vendors remain in
the best position to provide authoritative guidance on their own
implementations.
Document signing is a bit more interoperable, though still more
fragmented than the Web by regulatory requirements and jurisdictional
boundaries, and often additionally by document formats. (PDF vs. Word
vs. XML)
whatever the difference is, the underlying lower level operations
(building blocks) are almost the same or very close, all we need at this
stage is to identify them.
I think "the Web" / HTTPS is the only PKI (other than the work PKIX
does/did) with enough actually interoperating implementations that a
body like the IETF is best-positioned to document current and
historical practices.
No doubt. Web client authentication, web content signing are second to
that IMO.
Thanks,
M.D.
-Brad
*From:*Moudrick M. Dadashov [mailto:m...@ssc.lt]
*Sent:* Wednesday, August 22, 2012 2:42 PM
*To:* Hill, Brad
*Cc:* Tim Moses; 'wpkops@ietf.org'
*Subject:* Re: [wpkops] First draft charter proposal
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:*wpkops-boun...@ietf.org <mailto:wpkops-boun...@ietf.org>
[mailto:wpkops-boun...@ietf.org] *On Behalf Of *Tim Moses
*Sent:* Wednesday, August 22, 2012 5:45 AM
*To:* 'wpkops@ietf.org <mailto:wpkops@ietf.org>'
*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
wpkops@ietf.org <mailto:wpkops@ietf.org>
https://www.ietf.org/mailman/listinfo/wpkops
_______________________________________________
wpkops mailing list
wpkops@ietf.org
https://www.ietf.org/mailman/listinfo/wpkops
