Re: [wpkops] Preliminary Next Version of Browser Behavior Draft
I guess the cut-off time for I-D submissions was 2014-07-05 and use of the I-D submission tool is suspended until 2014-07-21 so I can't submit v. 02. In any event, I've made Rick's suggested changes and have a new draft ready to submit. Changes are in line below. Cheers, Ben From: wpkops [mailto:wpkops-boun...@ietf.org] On Behalf Of Rick Andrews Sent: Tuesday, June 10, 2014 6:04 PM To: b...@digicert.com; wpkops@ietf.org Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft Ben, I reviewed what I think is the latest draft at https://tools.ietf.org/html/draft-wilson-wpkops-browser-processing-01, not the Word doc attached to the previous message. Section 2.1: Is it worth pointing out that root stores are not fixed? Not only can they be extended via automatic download (as you pointed out), but enterprises can add and remove roots (as often happens in Windows environments) and browser users can manually add or remove roots or modify trust bits. Document readers may not be aware of those other possibilities. Added: Root stores are not fixed. Not only can they be extended via automatic download, but enterprises can add and remove roots through group policies, and most end users can manually add or remove root certificates. and Most systems also allow users to further adjust trust anchors with other configuration changes, such as allowing users to enable or disable potential key usages by checking or unchecking them for each certificate found in the root store. For instance, Firefox provides three options (identify websites, identify mail users, and identify software makers), while the Apple key chain provides ten key usages to select from, and Microsoft offers nearly fifty. and Assuming that the browser has obtained a set of certificates that can be used to form a certificate chain, section 4.2.1 of RFC 5280 sets forth how the authorityKeyIdentifier and the subjectKeyIdentifier standard extensions can also be used to select appropriate certificate when multiple choices exist. Most browsers process these extensions as part of certification path construction. Similarly, most browsers also match the issuer name with the subject name of the issuer's certificate as the chain is constructed up to the trust anchor. Section 2.2: It might be helpful to readers to explain here why Firefox does not do AIA chasing. In other words, they don't see it as a missing feature; they choose to fail on incomplete chains, and a case can be made as to why this behavior is preferable to the behavior of other browsers. Or do we just want to point out differences among browsers without trying to explain why those differences exist (where we understand why)? Added: It is the authors' understanding that the Mozilla community intentionally chose this behavior instead of processing the caIssuers AIA because Firefox will alert server administrators about defective chains and they can install missing CA certificates absent from certificate chains. Section 3.1 The introduction says This document reviews the current processing behaviors..., but this Section is full of shoulds. I suggest it needs to be rewritten to factually describe current behavior. First few paragraphs of section 3.1 have been edited to read: Browsers use one or more trust anchors from their root stores for certification path validation. The primary mechanism used to perform certification path validation in accordance with Section 6 of RFC 5280 is verifying the signature on the certificate. Much has been written on the process of signature verification, which requires processing the tbsCertificate and signatureValue fields using the signature algorithm and issuer public key to verify that the certificate was properly signed. DSA, RSA, and ECDSA are common digital signature algorithms used to sign certificates in conjunction with hashing algorithms such as MD5, RIPEMD-160, SHA-1, SHA-256, SHA-384, SHA-512, and Whirlpool. Thus, a browser might need to be able to perform the signature verification process using a variety of signature and hashing algorithms. The following extensions described in RFC 5280 are also relevant to certification path validation: Section 3.4 seems speculative and not descriptive of current browser behavior. Replaced with: Potential threats to communications security to be considered include whether allowing weak cryptography increases the risk that intercepted communications will be decrypted, and whether an inability to handle unexpected certificate data might cause a browser to fail in an insecure way, for example, software failure that allows a connection to proceed without encryption or enables other system
Re: [wpkops] Preliminary Next Version of Browser Behavior Draft
+1 As some other have already said, the charter of the WG calls for documenting current Web PKI practices, not describing what one might wish were true. Steve Ben, I reviewed what I think is the latest draft at https://tools.ietf.org/html/draft-wilson-wpkops-browser-processing-01, not the Word doc attached to the previous message. Section 2.1: Is it worth pointing out that root stores are not fixed? Not only can they be extended via automatic download (as you pointed out), but enterprises can add and remove roots (as often happens in Windows environments) and browser users can manually add or remove roots or modify trust bits. Document readers may not be aware of those other possibilities. Section 2.2: It might be helpful to readers to explain here why Firefox does not do AIA chasing. In other words, they don't see it as a missing feature; they choose to fail on incomplete chains, and a case can be made as to why this behavior is preferable to the behavior of other browsers. Or do we just want to point out differences among browsers without trying to explain why those differences exist (where we understand why)? Section 3.1 The introduction says This document reviews the current processing behaviors..., but this Section is full of shoulds. I suggest it needs to be rewritten to factually describe current behavior. Section 3.4 seems speculative and not descriptive of current browser behavior. Section 3.5 Header is not in bold. Section 4.3 Shouldn't say browsers should ;^) -Rick *From:*wpkops [mailto:wpkops-boun...@ietf.org] *On Behalf Of *Ben Wilson *Sent:* Tuesday, May 27, 2014 2:13 PM *To:* wpkops@ietf.org *Subject:* Re: [wpkops] Preliminary Next Version of Browser Behavior Draft 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 . *From:*wpkops [mailto:wpkops-boun...@ietf.org] *On Behalf Of *Ben Wilson *Sent:* Tuesday, May 13, 2014 9:44 AM *To:* wpkops@ietf.org mailto:wpkops@ietf.org *Subject:* [wpkops] Preliminary Next Version of Browser Behavior Draft Here is a first pass through the browser behavior document that I sent to Robin and Santosh yesterday. ___ 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
It's now posted here - https://tools.ietf.org/html/draft-wilson-wpkops-browser-processing-01 -Original Message- From: wpkops [mailto:wpkops-boun...@ietf.org] On Behalf Of i-barre...@izenpe.net Sent: Tuesday, June 10, 2014 2:23 AM To: b...@digicert.com; bruce.mor...@entrust.com Cc: wpkops@ietf.org; g...@mozilla.org; tim.mo...@entrust.com Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft Hi Ben, I´ll wait for your proposal but still don´t see it as a part of the trust model. The cryptolibraries are something the browsers use to perform their activities regarding the web PKI but IMHO are not related on how the browsers (or the OS) accept a CA in their root stores or how a CA adopt different options. In any case, if this is important for the browser behavior document, as said, will wait for the proposal and see where this can be added to the trust model doc. Iñigo Barreira Responsable del Área técnica i-barre...@izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. -Mensaje original- De: Ben Wilson [mailto:b...@digicert.com] Enviado el: lunes, 09 de junio de 2014 18:24 Para: Barreira Iglesias, Iñigo; bruce.mor...@entrust.com CC: wpkops@ietf.org; g...@mozilla.org; tim.mo...@entrust.com Asunto: RE: [wpkops] Preliminary Next Version of Browser Behavior Draft Iñigo, Yes, the cryptolibraries are functional subcomponents of browsers, so they ought to be mentioned. Providing the functional introduction will lay the groundwork for technical background. I'll send you (or post to the IETF site) the next version of the working document on non-revocation behavior. Cheers, Ben -Original Message- From: wpkops [mailto:wpkops-boun...@ietf.org] On Behalf Of i-barre...@izenpe.net Sent: Monday, June 9, 2014 2:29 AM To: b...@digicert.com; bruce.mor...@entrust.com Cc: wpkops@ietf.org; g...@mozilla.org; tim.mo...@entrust.com Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft Hi Ben, The current text of the trust models document already identifies the way a browser and a root store provider work together but not the relation with the crypto libraries. I don´t understand your question exactly because I don´t see why these libraries are of interest for a trust model. Do you mean that a trust model can differ depending on which library is used? The trust model document is more on a functional view than a technical one. I need more clarification on what you think to be added Regards Iñigo Barreira Responsable del Área técnica i-barre...@izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. -Mensaje original- De: Ben Wilson [mailto:b...@digicert.com] Enviado el: viernes, 06 de junio de 2014 20:48 Para: Barreira Iglesias, Iñigo; bruce.mor...@entrust.com CC: wpkops@ietf.org; 'Gervase Markham'; 'Tim Moses' Asunto: RE: [wpkops] Preliminary Next Version of Browser Behavior Draft 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
Re: [wpkops] Preliminary Next Version of Browser Behavior Draft
Hi Ben, The current text of the trust models document already identifies the way a browser and a root store provider work together but not the relation with the crypto libraries. I don´t understand your question exactly because I don´t see why these libraries are of interest for a trust model. Do you mean that a trust model can differ depending on which library is used? The trust model document is more on a functional view than a technical one. I need more clarification on what you think to be added Regards Iñigo Barreira Responsable del Área técnica i-barre...@izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. -Mensaje original- De: Ben Wilson [mailto:b...@digicert.com] Enviado el: viernes, 06 de junio de 2014 20:48 Para: Barreira Iglesias, Iñigo; bruce.mor...@entrust.com CC: wpkops@ietf.org; 'Gervase Markham'; 'Tim Moses' Asunto: RE: [wpkops] Preliminary Next Version of Browser Behavior Draft 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 Tim, Well, I have my doubts. The trust model document is about the webPKI working as today and CT is not deployed at all. Google plans to incorporate by the beginning of 2015 officially and make it mandatory for Chrome (of course, CAs can use it today on a voluntary basis). OTOH, CT is about issuing a certificate from a CA and how to let the others know that a certificate has not been issued properly but I think this is on the CA operations rather than on a trust model document but it also has implications on the trust you can have. Google uses in Chrome, when running on windows, the MS root store so it relies on what MS has stated in his root store program independently of the CT. But, in section 3.4 of the trust model document, it´s described how a browser can support public key pinning, so CT can be a new section 3.4.5, but again, it´s not yet deployed. The same can happen with CAA, there´s a RFC but none is using it at the moment and there´s a minimum of % to be considered. Initially was also considered the EU Trusted List and were removed because not widely used and maintained by the browser, so the % was very low. So, IMHO, right now, the CT is not part of the trust model document. We´ll see next year. Iñigo Barreira Responsable del Área técnica i-barre...@izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. -Mensaje original- De: Tim Moses [mailto:tim.mo...@entrust.com] Enviado el: viernes, 06 de junio de 2014 22:02 Para: Ben Wilson CC: Barreira Iglesias, Iñigo; Bruce Morton; wpkops@ietf.org; Gervase Markham Asunto: 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
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 smime.p7s Description: S/MIME cryptographic signature ___ 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
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
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
Re: [wpkops] Preliminary Next Version of Browser Behavior Draft
Thanks. I'll take a look and create another draft. -Original Message- From: wpkops [mailto:wpkops-boun...@ietf.org] On Behalf Of Tim Moses Sent: Thursday, June 5, 2014 8:19 AM To: Gervase Markham Cc: wpkops@ietf.org; b...@digicert.com Subject: 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 smime.p7s Description: S/MIME cryptographic signature ___ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops
