I agree with Brad and Stephen. We need to be addressing pressing practical problems. And (in my mind) site-authentication qualifies. I understand Stephen's concern about code-signing. But, it seems like significant extra work. I wonder if it should be left out of the initial charter. Once we have a better grasp of the type and quantity of resources that we can draw on, we could consider a re-chartering exercise to include it. All the best. Tim.
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Randy Turner Sent: Thursday, August 23, 2012 9:55 AM To: [email protected] Subject: Re: [wpkops] First draft charter proposal Yes, that was my question....they were doing signature-like things, but I wasn't sure about the size of any deployment....(i.e, "shipping products") R. On Aug 23, 2012, at 2:44 AM, Stephen Farrell <[email protected]> wrote: > > FWIW, I'd be *highly* skeptical that an OPS area WG is needed to > address anything whatsoever about LTANS. While it might be fine work, > its just not sufficiently deployed for that to be useful. > > S. > > On 08/23/2012 05:23 AM, Randy Turner wrote: >> >> Yes, I was specifically referring to signing timestamps and/or content as a >> part of the LTANS work...I just wasn't sure if there were products in the >> marketplace that could be called "LTANS-compliant" >> >> R. >> >> On Aug 22, 2012, at 7:05 PM, Santosh Chokhani wrote: >> >>> I do not know what you mean by "shipping" here, but LTANS did work on long >>> term non repudiation and time stamp resulting Evidence Record Structure RFC. >>> >>> From: [email protected] [mailto:[email protected]] On >>> Behalf Of Randy Turner >>> Sent: Wednesday, August 22, 2012 6:38 PM >>> To: [email protected] >>> Subject: Re: [wpkops] First draft charter proposal >>> >>> >>> I would agree with the scope that "signing" brings into the potential work >>> of a WG, but I think there might be a fair amount of interoperable S/MIME >>> experience as well that could be discussed. >>> >>> Code signing is a bit fragmented, although there have been >>> discussions on using CMS for generating signed code containers, but >>> vendors largely do what they want (as you mentioned) >>> >>> The LTANS working group looked at document archival awhile back, and >>> did some work on timestamping, but I'm not aware of any shipping >>> implementations that standardized their long-term archival >>> strategies regarding signatures or timestamping (not that there >>> aren't any, I just don't keep up with this) >>> >>> R. >>> >>> >>> On Aug 22, 2012, at 3:29 PM, 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 >>> >>> This has also led to different practices about revocation and >>> blacklisting, use of third party time stamping authorities, etc. The >>> differences are substantial. >>> >>> 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) >>> >>> 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. >>> >>> -Brad >>> >>> From: Moudrick M. Dadashov [mailto:[email protected]] >>> Sent: Wednesday, August 22, 2012 2:42 PM >>> To: Hill, Brad >>> Cc: Tim Moses; '[email protected]' >>> 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: [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 >>> >> >> >> >> >> _______________________________________________ >> wpkops mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/wpkops >> > _______________________________________________ > wpkops mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/wpkops > _______________________________________________ wpkops mailing list [email protected] https://www.ietf.org/mailman/listinfo/wpkops _______________________________________________ wpkops mailing list [email protected] https://www.ietf.org/mailman/listinfo/wpkops
