[wpkops] Browser behaviour draft
Colleagues - I would like to advance the Browser Behaviour draft ... http://datatracker.ietf.org/doc/draft-wilson-wpkops-browser-processing/ ... to WG draft. If you wish to comment, please do so by 2014-08-08. Thank you. All the best. Tim. ___ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops
Re: [wpkops] Preliminary Next Version of Browser Behavior Draft
Bruce/Inigo - Do you think the Transparency section in the revocation doc from Phill and David belongs in the Trust Model doc? All the best. Tim. On Jun 6, 2014, at 2:47 PM, Ben Wilson b...@digicert.com wrote: Iñigo and Bruce, Perhaps we should revise the Trust Model document to describe how browser, root store, and cryptolibrary are related? In addressing Gerv's comments, I am thinking of starting with the following This document reviews the current processing behaviors of cryptolibraries, and the browsers they support, with respect to SSL/TLS session establishment between a server and a browser, ... or something along those lines. Thoughts? Thanks, Ben -Original Message- From: wpkops [mailto:wpkops-boun...@ietf.org] On Behalf Of Gervase Markham Sent: Thursday, June 5, 2014 8:10 AM To: Tim Moses; b...@digicert.com Cc: wpkops@ietf.org Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft On 05/06/14 14:37, Tim Moses wrote: Hi Ben. We want to move this document to WG draft status. Do you want to address Gerv's comments before we hold a ballot? I suggest we do that. Again, apologies for lack of knowledge of the process, but: the doc is full of to be expanded, we plan to... etc. So there will be lots of further change. Is that what Draft means? My two examples were two of many; they were actually given to try and get clarity on the purpose and goals of the document. If that's written up somewhere, do point me to it. :-) Gerv ___ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops
Re: [wpkops] Preliminary Next Version of Browser Behavior Draft
Hi Ben. We want to move this document to WG draft status. Do you want to address Gerv's comments before we hold a ballot? I suggest we do that. All the best. Tim. -Original Message- From: wpkops [mailto:wpkops-boun...@ietf.org] On Behalf Of Gervase Markham Sent: Wednesday, June 04, 2014 3:54 PM To: b...@digicert.com; wpkops@ietf.org Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft Hi Ben, On 27/05/14 22:12, Ben Wilson wrote: Here is another draft with suggested changes from Santosh accepted, and the addition of “Security Considerations” subsections, based on our discussions of May 13^th . Sorry if I'm missing context here, but the intro to the document suggests that it's documentation of observed browser behaviour (i.e. a record of reality), but then as early as section 1.4 it starts by saying browsers should do X or Y. E.g.: A browser should only use its trust anchor store to determine the trust anchor for a Server’s certification path. Taking this particular statement as an example: what happens if the browser wants to use the OS store? Or both its own and the OSes? Or a remote store with auto-download such as Windows uses? To take another example from 1.4: Specifically, the browser should be able to use unsecure HTTP and unsecure LDAP method. I can confidently say that we have no plans to reintroduce LDAP fetching to Firefox, and the publication of an RFC would be unlikely (British understatement) to change that. (We are also pretty unlikely to do caIssuers chasing, but I am 0.1% less adamant about that.) As more constructive input: many of the behaviours you note are features of the underlying SSL implementation rather than the browser. This is, I believe, why Chrome and Safari on OS X don't do name constraints (they use the system SSL library) but Firefox does (which uses NSS). I agree it's difficult because the exact user experience _is_ defined by the individual browsers. But the document might be easier to understand and follow if you acknowledged the connection with the library being used. Gerv ___ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops ___ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops
Re: [wpkops] Preliminary Next Version of Browser Behavior Draft
Gerv: You have to look for that in the charter ... http://datatracker.ietf.org/wg/wpkops/charter/ The significance of WG Draft is that it identifies the single document (or sequence of documents) of the declared scope on which the group will focus its efforts. It is not expected that the first WG Draft will be complete or internally consistent. It is often stated that the experts in the community will not engage until a document achieves WG Draft status. So, we are hoping for, and expecting, a more vigorous debate once the document advances to WG Draft status. All the best. Tim. -Original Message- From: Gervase Markham [mailto:g...@mozilla.org] Sent: Thursday, June 05, 2014 10:10 AM To: Tim Moses; b...@digicert.com Cc: wpkops@ietf.org Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft On 05/06/14 14:37, Tim Moses wrote: Hi Ben. We want to move this document to WG draft status. Do you want to address Gerv's comments before we hold a ballot? I suggest we do that. Again, apologies for lack of knowledge of the process, but: the doc is full of to be expanded, we plan to... etc. So there will be lots of further change. Is that what Draft means? My two examples were two of many; they were actually given to try and get clarity on the purpose and goals of the document. If that's written up somewhere, do point me to it. :-) Gerv ___ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops
[wpkops] London meeting minutes
Colleagues - See the minutes here ... http://www.ietf.org/proceedings/89/wpkops.html All the best. Tim. ___ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops
Re: [wpkops] Soon to be external review - Proposed Charter for Public Notary Transparency
Joel - This project seems a great way to address one of the main criticisms of the Web PKI trust model; that all the CAs must act in a trustworthy manner, no matter how many there may be or how poorly resourced some of them may be. If I've understood correctly, the project will be incomplete until there exists an effective way for clients, acting in the auditor capacity, to compare their versions of logs. Without that, the need for blind trust is not eliminated entirely. Of all the attempts we have seen to address the trust model problem, this project seems to me to hold the most promise. All the best. Tim. On Jan 22, 2014, at 3:32 PM, joel jaeggli joe...@bogus.com wrote: I would draw your attention to this wg charter, which is likely to be in external review soon enough. I would very much like the feedback and expertise from some of the members of this community. https://datatracker.ietf.org/doc/charter-ietf-trans/ Thanks Joel ___ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops ___ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops
[wpkops] Bookmark this page
Colleagues - Here is the working group Wiki. http://trac.tools.ietf.org/wg/wpkops/trac/wiki The questionnaire is there. And, responses will be posted there once we have them. Remember, the deadline for responses is 2014-01-31. I know I don't have to tell you that the productivity of the meeting in London is dependent on a thorough set of responses by the deadline. Thanks a lot. All the best. Tim. ___ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops
Re: [wpkops] Early draft of vendor questionnaire
Rick - The CRL Timeout question had to do with behaviour in the event that no response to the CRL request is received. How long before the software decides it won't wait any longer and what does it do then? All the best. Tim. -Original Message- From: Rick Andrews [mailto:rick_andr...@symantec.com] Sent: Tuesday, December 03, 2013 8:06 PM To: t.petch Cc: wpkops@ietf.org; Tim Moses Subject: RE: [wpkops] Early draft of vendor questionnaire Tom, You sent two emails with comments; I'm going to combine them together and address both at once. I'm attaching the latest version of the document. -Rick -Original Message- From: t.petch [mailto:ie...@btconnect.com] Sent: Wednesday, November 27, 2013 10:24 AM Tom. These are good points. They relate more to the TLS stack than the PKI. But, they are relevant for all that. Can you provide specific questions? Tim Yes, my thoughts have a TLS bias but that is what I got from reading the document! That's fine; I think the WG has a TLS bias. And I find the document quite large already and am reluctant to add more to it without removing something. That worries me a bit. The state of Web PKI today is complex. We're trying to find our way through that complexity, and I don't think we'll learn very much if we keep the questions short and/or simple. On the other hand, I don't want this to get too big to be unwieldy. I think that Server Q1 is inappropriate for two reasons. 1) Different versions of eg Windows Server have very different capabilities and I would think it verging on the impossible to fill this in for the different versions. Rather, people should be invited to fill in a separate questionnaire for each version. And it is the vendor who knows what makes sense as a version, thus, as I recall, Windows Vista is the same as 2008R1, but 2008R2 is the same as 7 ie it is the underlying SChannel that matters, not the terms that might be used in marketing. 2) Many, if not most organisations, will not disclose market share and might stop and go no further - such data is often available but from other sources such as Universities and large web sites, not from vendors. I wrote some text in the introduction to encourage responders to make copies of the document for each version, if that's what they'd prefer, or just describe the different behavior of each version in each answer. Let me know if you think that's adequate. And a second substantial point is Server Q2 which I find misguided - yes you want to know what is supported but I think that this should be in terms of TLS ciphersuites - after all, Q8 does not ask what versions of SSH are in use! But this is the Web *PKI* Ops working group, and ciphersuites are not exclusively related to PKI. I'm inclined to avoid discussing ciphersuite support to keep the survey simpler. And my third substantial point is Server Q8 which I think fundamental, and which should come earlier, perhaps second (assuming that the emphasis on TLS is correct); and it is a complex question, it is really about the negotiation that takes place to find a version acceptable to client and server which in turn affects the available ciphersuites and so on. I am not sure how to rephrase this question and will think some more. I'll move it if you feel it's important. I didn't pay much attention to the order of questions, since I expect that responders will answer all questions. - -Original Message- From: t.petch [mailto:ie...@btconnect.com] Sent: Wednesday, November 27, 2013 2:31 AM To: Rick Andrews; wpkops@ietf.org Subject: Re: [wpkops] Early draft of vendor questionnaire Complicated:-( Perhaps there is a danger of losing the wood for the trees. Thus, I think of TLS in terms of cipher suites and think that software vendors would too; the mix and match approach of algorithms in 2) (where is RC4 or AEAD or AES-GCM?) seems likely to produce the wrong answers. See my answer above re: ciphersuites vs. PKI aspects. I also think of TLS in terms of versions, of which there are two values that appear separately in setting up a TLS connection, and many software vendors would appear not to understand what the specification says in that regard and so are in breach of it. Fallback attacks derived therefrom are a significant part of using TLS. Can you craft a question to capture this concern? And then there is Key Usage; some check, other do not. I added a question I got from Wayne: 18) Does the product enforce key usage constraints? __ Yes, via Key Usage __ Yes, via Extended Key Usage __ Yes, via metadata associated with the root Is that adequate, or do you have additional concerns? And the hot topic of three years ago was Renego and support for it; still significant today. Links into fallback attacks. I'm inclined to not include this a) because
Re: [wpkops] OCSP Responder Vendors
How about Tumbleweed (inheritor of the Valicert legacy)? All the best. Tim. On Nov 26, 2013, at 10:16 PM, Rick Andrews rick_andr...@symantec.commailto:rick_andr...@symantec.com wrote: Folks, I’m thinking we should also send the survey to vendors of OCSP Responder software. I know of CoreStreet, and I’ve heard tell of others, but I don’t know who they are. * Do you think we should include such companies? * If yes, should we create a separate section in the questionnaire for them? * If yes, do you know of other candidate companies, and maybe a contact point for each of them? Thanks, -Rick ___ wpkops mailing list wpkops@ietf.orgmailto:wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops ___ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops
[wpkops] Developments
Colleagues - The working group document authors met today by teleconference. The main point of discussion was the plan to survey vendors concerning the behaviour of their Web products as it relates to PKI. Rick Andrews of Symantec has graciously agreed to coordinate the compilation of survey questions and to interact with vendors. He will circulate an initial set of questions upon which to comment in the near future. We also discussed the timetable for completion of the project. While we have missed two interim deadlines, it is our intention to hold to the end-dates. We do not, however, intend to modify the charter to reflect the revised interim milestone dates at this point. So, look out for a message from Rick containing his proposal for survey questions and give him your thoughtful feedback Thanks a lot. All the best. Tim. ___ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops
Re: [wpkops] Meeting materials
Tom - It's heart-warming to know that someone read (or at least tried to read) the minutes. I have revised the file and tested it with your favourite reader. Let me know if you still have a problem. All the best. Tim. -Original Message- From: t.petch [mailto:ie...@btconnect.com] Sent: Tuesday, November 19, 2013 5:37 AM To: Tim Moses; wpkops@ietf.org Subject: Re: [wpkops] Meeting materials The minutes seem to have lost the concept of the new-line, which renders them so hard to read as to be almost unreadable. Other WG minutes from IETF88 do not suffer from this problem. My browser is Internet Explorer. Curiously, if I view the page's source with Notepad, they are understandable - usually, it is the other way round. Tom Petch - Original Message - From: Tim Moses tim.mo...@entrust.com To: wpkops@ietf.org Sent: Friday, November 15, 2013 1:42 PM Colleagues - The minutes and other materials related to last week's meeting in Vancouver are here. http://www.ietf.org/proceedings/88/wpkops.html All the best. Tim. ___ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops ___ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops
Re: [wpkops] Meeting materials
Tom - The four documents are: - The trust model; - The contents and processing of fields and extensions; - The processing of revocation schemes; - How the TLS stack deals with PKI. All the best. Tim. -Original Message- From: t.petch [mailto:ie...@btconnect.com] Sent: Tuesday, November 19, 2013 1:03 PM To: Tim Moses Cc: wpkops@ietf.org Subject: Re: [wpkops] Meeting materials Beautiful. One thought is - what are the four documents? The minutes do not say and I do not see that clearly in the charter unless it is - current server behaviour - current browser behaviour - historic server behaviour - historic browser behaviour (which is not where I think that I would start). Tom Petch - Original Message - From: Tim Moses tim.mo...@entrust.com To: t.petch ie...@btconnect.com Cc: wpkops@ietf.org Sent: Tuesday, November 19, 2013 2:02 PM Tom - It's heart-warming to know that someone read (or at least tried to read) the minutes. I have revised the file and tested it with your favourite reader. Let me know if you still have a problem. All the best. Tim. -Original Message- From: t.petch [mailto:ie...@btconnect.com] Sent: Tuesday, November 19, 2013 5:37 AM To: Tim Moses; wpkops@ietf.org Subject: Re: [wpkops] Meeting materials The minutes seem to have lost the concept of the new-line, which renders them so hard to read as to be almost unreadable. Other WG minutes from IETF88 do not suffer from this problem. My browser is Internet Explorer. Curiously, if I view the page's source with Notepad, they are understandable - usually, it is the other way round. Tom Petch - Original Message - From: Tim Moses tim.mo...@entrust.com To: wpkops@ietf.org Sent: Friday, November 15, 2013 1:42 PM Colleagues - The minutes and other materials related to last week's meeting in Vancouver are here. http://www.ietf.org/proceedings/88/wpkops.html All the best. Tim. ___ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops
[wpkops] Meeting materials
Colleagues - The minutes and other materials related to last week's meeting in Vancouver are here. http://www.ietf.org/proceedings/88/wpkops.html All the best. Tim. ___ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops
[wpkops] Vancouver agenda
Colleagues - The latest agenda for the Vancouver meeting is here ... https://datatracker.ietf.org/meeting/88/agenda/wpkops/ It contains links to the three documents that will be discussed and (where available) accompanying slides. The working group is asked to consider a fourth document ... http://www.ietf.org/proceedings/88/slides/slides-88-wpkops-1.txt But, it's principal author cannot be with us in Vancouver. So, no time-slot has been allocated. Please take the time to acquaint yourselves with the documents ahead of the meeting. Looking forward to a productive session. All the best. Tim. ___ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops
Re: [wpkops] FW: New Version Notification for draft-barreira-trustmodel-00.txt
Colleagues - I propose that this version be adopted as the first working group draft. If you have comments relating to this proposal, please provide them by end-of-day (Friday) 18 Oct. If accepted, the document can be restyled and submitted ahead of the deadline for submissions for the Vancouver meeting. Thanks a lot. All the best. Tim. -Original Message- From: wpkops-boun...@ietf.org [mailto:wpkops-boun...@ietf.org] On Behalf Of Bruce Morton Sent: Friday, October 11, 2013 8:03 AM To: wpkops WG (wpkops@ietf.org) (wpkops@ietf.org) Subject: [wpkops] FW: New Version Notification for draft-barreira-trustmodel-00.txt The Trust Model draft has been updated. Bruce. -Original Message- From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] Sent: Wednesday, October 09, 2013 8:47 AM To: Inigo Barreira; Bruce Morton Subject: New Version Notification for draft-barreira-trustmodel-00.txt A new version of I-D, draft-barreira-trustmodel-00.txt has been successfully submitted by Inigo Barreira and posted to the IETF repository. Filename:draft-barreira-trustmodel Revision:00 Title: Trust models of the Web PKI Creation date: 2013-10-09 Group: Individual Submission Number of pages: 9 URL: http://www.ietf.org/internet-drafts/draft-barreira-trustmodel-00.txt Status: http://datatracker.ietf.org/doc/draft-barreira-trustmodel Htmlized:http://tools.ietf.org/html/draft-barreira-trustmodel-00 Abstract: This is one of a set of documents to define the operation of the Web PKI. It describes the currently deployed Web PKI trust. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ___ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops ___ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops
Re: [wpkops] FW: New Version Notification for draft-barreira-trustmodel-00.txt
David - I think this is where we rely on judgment and bear in mind the purpose of this exercise. We want to spotlight those issues that the developers and operators of the Web PKI can reasonably fix. To your example, the operators can fix OCSP availability, but not fault-tolerant hardware. All the best. Tim. On Oct 15, 2013, at 1:26 PM, David Chadwick d.w.chadw...@kent.ac.uk wrote: In this case where do you draw the line of who to include and not to include. Supply chains are massively long and complex these days. So if the mainframe running the OCSP server crashes due to a fault of the manufacturer, so that no-one is able to check the revocation status of certs, is the computer manufacturer responsible rather than the CA? Should we mention this in the spec? Where do you draw the line? regards David On 15/10/2013 18:06, Ben Wilson wrote: Concerning 3.3.1. Subscriber uses agent, David Chadwick wrote, 5. What is the relevance of section 3.3.1? If a third party is subcontracted to a party to do work on its behalf, then the party is ultimately responsible for this and there is no need to mention it. David, I think it is helpful to mention or flag where certain relationships might exist that are not apparent by looking at just the technical/operational aspects to provide context to model. Since we are trying to explain how things operate, I think we need to go slightly beyond just the traditional three-party model. I don't think that the distinguishing feature here is legal. For instance, can we say with certainty that one party or another is ultimately responsible? That might involve legal wrangling and it might ultimately take a judge to make the determinations of who was responsible for what. The devil is in the details of the subcontract. I'm not saying we need to get into all of that legal stuff - quite the contrary. Ben -Original Message- From: wpkops-boun...@ietf.org [mailto:wpkops-boun...@ietf.org] On Behalf Of David Chadwick Sent: Monday, October 14, 2013 5:52 AM To: Bruce Morton; wpkops WG (wpkops@ietf.org) (wpkops@ietf.org) Subject: Re: [wpkops] FW: New Version Notification for draft-barreira-trustmodel-00.txt Hi Bruce here are my comments on this version 1. There is a potential problem with the scope/Introduction of the document, since it only covers trust between the browser and the subscriber, when what really matters is trust between the RP and the subscriber. How is this gap to be covered? 2. Section 2.1. 3rd para insert may - The root store provide may require the root CA Rationale. If the root store provider can verify a CA simply because it has been accepted by another root store provider, as per the second paragraph, then conversely, it may not require it to be annually audited but may remove it only when the other root store provider removes it. 3. Section 2.3 insert may - The subscriber may identify... Rationale. This more accurately reflects the current situation today, doesn't it? 4. Section 3.2.3. A third party RA is not identified in a CA certificate as anything, is it?. Remove as an issuing CA as this implies it is identified as something else. 5. What is the relevance of section 3.3.1? If a third party is subcontracted to a party to do work on its behalf, then the party is ultimately responsible for this and there is no need to mention it. 6. Section 5.2. Non-unique names. It is unclear whether non-unique names refers to Internet wide unique names, or only to CA wide unique names. Be explicit. regards David On 11/10/2013 13:02, Bruce Morton wrote: The Trust Model draft has been updated. Bruce. -Original Message- From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] Sent: Wednesday, October 09, 2013 8:47 AM To: Inigo Barreira; Bruce Morton Subject: New Version Notification for draft-barreira-trustmodel-00.txt A new version of I-D, draft-barreira-trustmodel-00.txt has been successfully submitted by Inigo Barreira and posted to the IETF repository. Filename: draft-barreira-trustmodel Revision: 00 Title: Trust models of the Web PKI Creation date: 2013-10-09 Group: Individual Submission Number of pages: 9 URL: http://www.ietf.org/internet-drafts/draft-barreira-trustmodel-00.txt Status: http://datatracker.ietf.org/doc/draft-barreira-trustmodel Htmlized:http://tools.ietf.org/html/draft-barreira-trustmodel-00 Abstract: This is one of a set of documents to define the operation of the Web PKI. It describes the currently deployed Web PKI trust. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ___ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops
[wpkops] Agenda: WPKOPS in Vancouver
Colleagues. The IETF has approved a meeting of the WPKOPS working group during its upcoming meeting in Vancouver. I am compiling an agenda, and the chairs welcome suggestions from the members. Below you'll find a preliminary draft. While our deliverables must be confined to the scope as defined in the charter, we are allowed (even encouraged) to discuss a broader range of topics; making the most of the opportunity afforded by the presence in one place of so many experts on the topic of the Web PKI. So, if there are related topics on which you would like to present, or topics on which you would like to see some discussion, please let us know. Thanks a lot. All the best. Tim. Agenda WPKOPS IETF 88 7 Nov, 15:20x-apple-data-detectors://0 (tentative) 1. Introductory remarks (appointment of note taker, Jabber scribe, IP statement, agenda bashing) - chairs - 10 mins 2. Project update - chairs - 10 mins 3. Status reports 3a. Trust models - author - 20 mins 3b. Cert/CRL/OCSP processing - author - 20 mins 3c. Revocation - author - 20 mins 4. Open mic. - 40 mins ___ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops
Re: [wpkops] Silence is deafening - Trust Model Paper
First of all, apologies for the delay in responding to this thread. Secondly, I think Michael makes some excellent points. Here's a suggestion ... Is not the Security Considerations section precisely the place where one would record the things that might go wrong in the event the model is not properly reflected in reality? There are too many failure modes to be exhaustive. But, one might capture the most serious ones; the ones that experts feel might have a solution within the IETF's ambit. In this way, the body of the document would describe how things should work (as the document does now), and the Security Considerations section would capture relevant failure modes. Thought? All the best. Tim. Michael Jenkins wrote ... To cut Bruce ein bißchen of slack :) he's writing about the trust model, not an observation of all the wonderful and glorious ways PKI has failed. Models don't necessarily reflect reality, so I don't think this paper needs to document how elements have failed to meet the model /as part of the model/. It just needs to extract from current operation where trust relationships exist. So I agree with Paul, mostly: the trust model paper should talk about browsers explicitly and solely, and how they store and use certificates for SSL specifically. It should describe the CA and its CP/CPS, how the auditor is supposed to use it, how the browser-vendor/trust-store-manager is supposed to use it. It should probably leave the browser-operator out of the trust model, because the indications presented to the browser-operator are disconnected from certificate processing. The paper should not go halves, trying to put what's out there in the context of traditional concepts of PKI. Anticipating a comment, I use is supposed to rather than should. Since we're describing a model, that's appropriate. If you're going to work to improve the consistency of web security behavior, then you've got to have a target. Substitute could effectively if you prefer. I also think the paper could describe the ways the model doesn't support security or inspire trust. Browser-vendors do vet CAs for entry into trust-stores, and do react to catastrophic failures, but don't have an on-going role in CA accountability. Auditors do inspect CA operations, but serve a guidance role, are in the employ of the CA itself, and the audit report is private. These things are inherent to the model, and are problems. The gaps created by PKI elements not supporting or actually subverting trust by violating the model don't really belong in the paper unless the paper increases in scope. I think those issues would still fit within the charter, but go beyond describing a model ___ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops
[wpkops] Document editors
Colleagues - Here is the current list of volunteers to edit WPKOPS drafts. Trust model - Iñigo Barreira, Bruce Morton Certificate, CRL, and OCSP field and extension processing - Ben Wilson, Robin Alden Revocation - Phillip Hallem-Baker TLS stack operation - Adam Langley ___ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops
[wpkops] WPKOPS BoF draft agenda
Colleagues - Here is an initial agenda. Please send your comments. If you would like to make a presentation, please let me know. Thanks a lot. All the best. Tim. 1. Introduction (Tim Moses) - 10 mins 2. The Web-app operator's perspective (Jeff Hodges/Brad Hill) - 20 mins 3. The CA's perspective (Ben Wilson) - 20 mins 4. Outstanding questions (chairs) - 10 mins 5. Comments and questions from the audience - 50 mins 6. Summation (chairs) - 10 mins T: +1 613 270 3183 ___ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops
Re: [wpkops] draft 4th draft charter
It means that schedule and accuracy take precedence over completeness. Faced with a tough deadline appeals to correct errors will be heard, appeals to add content won't. On 2012-10-19, at 3:28 PM, SM s...@resistor.net wrote: Hi Jeff, At 11:23 19-10-2012, =JeffH wrote: In an effort to help out, below is an updated draft 4th draft charter :) [snip] 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, though without sacrificing technical correctness. What does the above gem mean? Regards, -sm ___ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops ___ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops
[wpkops] Support for this activity from product developers?
Colleagues - One of the premises of this initiative (perhaps the main premise) was that product developers would be willing to be governed by the results of an industry consensus process when it comes to handling certificates and acting on the results of certificate validation. That is, that developers would see value in claiming conformance to any resulting standard. For instance, suppose consensus were to emerge that certain certificate validation failures should be fatal (i.e. the associated application should refuse to perform the requested operation), would application developers be willing to modify their products accordingly? Nothing in the discussions on the list to date confirms or refutes the premise. I think it would be useful to hear from developers of relevant products how they would view the outcome of this type of IETF initiative. Thanks a lot. All the best. Tim. T: +1 613 270 3183 ___ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops
Re: [wpkops] Third draft charter proposal
Hi Ron. I have written up a BoF proposal/application and it is with Steve Hanna for his consideration. I'll forward it to you as soon as I hear back from Steve. All the best. Tim. -Original Message- From: Ronald Bonica [mailto:rbon...@juniper.net] Sent: Monday, September 17, 2012 11:49 AM To: Stephen Farrell; Tim Moses Cc: wpkops@ietf.org Subject: RE: [wpkops] Third draft charter proposal Folks, On September 26, the IAB and IESG will review BoF proposals. Would it be OK if I included this version of the charter proposal in the BoF proposal? Ron -Original Message- From: wpkops-boun...@ietf.org [mailto:wpkops-boun...@ietf.org] On Behalf Of Stephen Farrell Sent: Saturday, September 15, 2012 1:35 PM To: Tim Moses Cc: wpkops@ietf.org Subject: Re: [wpkops] Third draft charter proposal Hi Tim, That looks pretty good to me. Some comments below. On 09/15/2012 05:00 PM, Tim Moses wrote: Colleagues - Here is a third draft of the WPKOPS charter proposal. It attempts to accommodate comments received on the second draft. The other major change is that I have deleted the proposal for a draft on communications between the certificate-holder and the certificate issuer. This was included originally to ensure that we didn't lose sight of the role of the Web server in the stapling process. But, I think this can be dealt with in the certificate revocation document. Equally to the point, I have received commitments from individuals to act as the primary editors for the remaining documents. Rick Andrews from Symantec with Scott Rea and Ben Wilson from DigiCert have offered to tackle certificate revocation, Ben Wilson and colleagues from DigiCert have offered to tackle the behavior of the certificate using product, and Adam Langley of Google has volunteered to edit the draft on TLS stack operation. I am looking for others to volunteer to assist in an editing role. Please let me know as soon as you possibly can and I'll put you in touch with the editors that have already been identified. 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 for end-users, certificate holders, 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. Certificate holders may have difficulty understanding whether some browser versions will reject their certificate if certain content specifications are not met, such as a subject public key that does not satisfy a minimum key size, or a certificate policies extension that does not contain a particular standard policy identifier. 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. But, such a project has to be bounded. Therefore, only server-authentication behavior encountered in more than 0.1 percent of connections made by desktop and mobile browsers should be considered. While it is not intended to apply the threshold with any precision, it may be used to justify the inclusion or exclusion of a technique. 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 (such as client authentication, document signing, code signing, and email) may use the same trust anchors and certificate-handling libraries as the ones used
[wpkops] 00 I-D on trust models
Colleagues - Here's a 00 I-D on trust models. http://tools.ietf.org/html/draft-moses-webpki-trustmodel-00 Please take a moment to look it over and comment. I need your help to correct and complete it. Thanks a lot. All the best. Tim. T: +1 613 270 3183 ___ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops
Re: [wpkops] Second draft charter proposal
Hi Jeff. I was thinking that both aspects of practices should be outside the scope of an IETF activity. The CA/Browser Forum is working on these with the co-operation of the root-program operators and the relevant audit experts (ETSI and WebTrust). I think that best value is obtained from the IETF community by focusing on technical protocols. No? All the best. Tim. -Original Message- From: wpkops-boun...@ietf.org [mailto:wpkops-boun...@ietf.org] On Behalf Of =JeffH Sent: Thursday, August 30, 2012 7:31 PM To: wpkops@ietf.org Subject: Re: [wpkops] Second draft charter proposal a detail-level comment: 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. practices of ... certificate issuers needs to be clearly defined in order to disambiguate between, e.g., verification of certificate issuance requester and CA infrastructure operational practices. My understanding is that this scope declaration is intended to exclude the former and not necessarily the latter, but this isn't clear. HTH, =JeffH ___ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops ___ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops
[wpkops] Second draft charter proposal
Colleagues - I have updated the proposed charter to reflect the discussion (see below). 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. But, such a project has to be bounded. Therefore, only behavior encountered in more than 0.1 percent of connections made by desktop and mobile browsers should be considered. While it is not intended to apply the threshold with any precision, it may be used to justify the inclusion or exclusion of a technique. 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 (such as document signing, code signing, and email) may use the same trust anchors and certificate-handling libraries as the ones used by the Web. Nevertheless, they may use the results in a way that is visibly different from the way in which the Web uses them. 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. Milestones 1.First WG draft of trust model document (4 months). 2.First WG draft of certificate, CRL, and OCSP field and extension processing document (12 months). 3.First WG draft of Web-server / CA communications document (4 months). 4.First WG draft of certificate revocation document (8 months). 5.First WG draft of TLS stack operation document (8 months). 6.IESG submission of trust model document (16 months). 7.IESG submission of certificate, CRL, and OCSP field and extension processing document (24 months). 8.IESG submission of Web-server / CA communications document (16 months). 9.IESG submission of certificate revocation document (20 months). 10. IESG submission of TLS stack operation document (16 months). T: +1 613 270 3183 ___ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops
Re: [wpkops] Scope
All - Here's what I had in mind. Tell me if you think it won't work. (What am I saying? Of course you're going to tell me.) I saw the purpose of this project as identifying issues with the way that the Web PKI works, based on a complete and common understanding. We may have different opinions on which of those issues needs to be addressed and with what priority. But, there will be less room for dispute over whether or not the issue exists, or the extent to which it exists. I didn't want to commit to writing requirements unless and until we have the enthusiastic participation of the browser and Web server suppliers. Without their involvement, there is no reason to believe that they would accept such requirements, or that significant considerations had been omitted or misunderstood when writing them. Documenting how things actually work (I hope) will foster a well-informed discussion about what works well and what could work better. The discussion may occasionally stray into potential solutions. And, while such discussions would be out-of-scope, and therefore have to be cut short, it should be easier to agree what further actions are required. So, in a sense, there are two types of deliverable: the BCP or info RFCs, and the mail-list discussion about what to do next. And, if we are successful, the latter will be the more valuable. All the best. Tim. -Original Message- From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie] Sent: Tuesday, August 28, 2012 5:04 PM To: Tim Moses Cc: 'Randy Turner'; wpkops@ietf.org Subject: Re: [wpkops] Scope So in addition, I was hoping this group would document use-cases and requirements for new protocols or changes to current protocols if the wg figure some are needed so that we could spin-up short-lived SEC or other WGs as needed. I'm not gonna stamp my feet if folks don't want to do that but I'd hope to get that kind of output so's we can concentrate on new protocol work in this space that'll be more likely to get adopted. (I would stamp my feet if folks wanted to specify new protocols in this group.) Cheers, S. On 08/28/2012 08:29 PM, Tim Moses wrote: Hi Randy. That's right. Hopefully, this will be a precursor to fixing some of the issues with the Web PKI. But, step one is to catalog what we have. So, we'll start by producing a set of BCPs that document major aspects of the Web PKI as it is generally practiced today. All the best. Tim. -Original Message- From: wpkops-boun...@ietf.org [mailto:wpkops-boun...@ietf.org] On Behalf Of Randy Turner Sent: Tuesday, August 28, 2012 3:26 PM To: wpkops@ietf.org Subject: Re: [wpkops] Scope Hi Tim, So, in a nutshell (because this is an OPS effort), we're doing to: 1. Document existing practice, given the most prevalent products, and 2. Given existing practice, analyze this existing practice for a set of BCPs Is this correct? Thanks! Randy On Aug 28, 2012, at 9:59 AM, Tim Moses wrote: Hi Rick. I completely agree. It's covered in the last paragraph of the draft charter. In the near future I'll distribute an updated charter proposal. All the best. Tim. -Original Message- From: wpkops-boun...@ietf.org [mailto:wpkops-boun...@ietf.org] On Behalf Of Rick Andrews Sent: Tuesday, August 28, 2012 12:56 PM To: Adam Langley; Tim Moses Cc: wpkops@ietf.org Subject: Re: [wpkops] Scope Tim, I think the 1% fuzzy threshold is fine. But I really hope that the sum total of connections that use Web PKI includes mobile browsers and apps. I've heard anecdotally that mobile represents a large and ever-growing share of web use, and I think it's essential to include it. -Rick -Original Message- From: wpkops-boun...@ietf.org [mailto:wpkops-boun...@ietf.org] On Behalf Of Adam Langley Sent: Tuesday, August 28, 2012 8:09 AM To: Tim Moses Cc: wpkops@ietf.org Subject: Re: [wpkops] Scope On Tue, Aug 28, 2012 at 10:58 AM, Tim Moses tim.mo...@entrust.com wrote: Colleagues - As discussed, the idea is to document the Web PKI as it is practiced today. Generally, that means considering product versions other than the most recent one from each significant supplier. But, in order to keep the workload at a manageable level, we will have to eliminate product versions that are seldom encountered today. Without making reference to specific products and versions, it's tough to come up with an objective criterion for identifying the versions that deserve to be documented. Therefore, I believe we have to rely on experts' judgments. As a guide, we might agree that, in order to warrant consideration, a technique must be involved in more than one percent of connections that use the Web PKI. While we would not attempt to apply this threshold with any precision, contributors may appeal to it in order to justify their exclusion of a particular technique. Then the disputant would be called upon
Re: [wpkops] Scope
Hi Rick. I completely agree. It's covered in the last paragraph of the draft charter. In the near future I'll distribute an updated charter proposal. All the best. Tim. -Original Message- From: wpkops-boun...@ietf.org [mailto:wpkops-boun...@ietf.org] On Behalf Of Rick Andrews Sent: Tuesday, August 28, 2012 12:56 PM To: Adam Langley; Tim Moses Cc: wpkops@ietf.org Subject: Re: [wpkops] Scope Tim, I think the 1% fuzzy threshold is fine. But I really hope that the sum total of connections that use Web PKI includes mobile browsers and apps. I've heard anecdotally that mobile represents a large and ever-growing share of web use, and I think it's essential to include it. -Rick -Original Message- From: wpkops-boun...@ietf.org [mailto:wpkops-boun...@ietf.org] On Behalf Of Adam Langley Sent: Tuesday, August 28, 2012 8:09 AM To: Tim Moses Cc: wpkops@ietf.org Subject: Re: [wpkops] Scope On Tue, Aug 28, 2012 at 10:58 AM, Tim Moses tim.mo...@entrust.com wrote: Colleagues - As discussed, the idea is to document the Web PKI as it is practiced today. Generally, that means considering product versions other than the most recent one from each significant supplier. But, in order to keep the workload at a manageable level, we will have to eliminate product versions that are seldom encountered today. Without making reference to specific products and versions, it's tough to come up with an objective criterion for identifying the versions that deserve to be documented. Therefore, I believe we have to rely on experts' judgments. As a guide, we might agree that, in order to warrant consideration, a technique must be involved in more than one percent of connections that use the Web PKI. While we would not attempt to apply this threshold with any precision, contributors may appeal to it in order to justify their exclusion of a particular technique. Then the disputant would be called upon to demonstrate that the technique was more prevalent. What do others think? 1% seems reasonable although, if anything, a little high. There are workarounds that apply to less than 1% but are, none the less, important. But any number 0.1%..1% seems sane. Cheers AGL ___ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops ___ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops ___ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops
