I think Stephen's reminder about the "OPS" designation in the proposed WG, is a good one.
If that's the case, then, by definition, it's probably existing pressing issues with deployed standards that's the target (or so it would seem). By eliminating signing we're saying one of the following: 1. Signatures are not deployed significantly to end-users, so it's not an OPS problem 2. Signatures "are" deployed significantly, but there are no perceived issues in the current deployment 3. The scope of web browser/server use of PKI (site authentication, etc.) by itself is enough for the WG I think it's #3 I'm ok with the go-forward "Once we have a better grasp…" strategy included in the Tim's note below. R. On Aug 23, 2012, at 7:22 AM, Tim Moses <[email protected]> wrote: > 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 > _______________________________________________ wpkops mailing list [email protected] https://www.ietf.org/mailman/listinfo/wpkops
