Re: [cabfpub] [EXTERNAL]Re: Draft SMIME Working Group Charter
I support Tim's comment. I think the scope of this charter is much too restrictive. For example, consider Baseline Requirements section 4.1.2 (“the CA SHALL obtain… an executed Subscriber Agreement”). I don’t think the working group charter would allow discussion of such a section; it doesn’t fall under any of the items specifically mentioned as part of the Scope, unless you’re going to try to call it a ‘CA operational practice’. That raises another concern I have with the scope, which is that it is vague, and so likely to lead to unresolvable disputes. For example, suppose someone proposes something like section 6.1.5. I would say this is out of scope, but someone else might say this is part of the certificate profile. Or someone might propose something like section 6.1.7 saying it’s an operational practice of the CA; is it? > On Feb 6, 2019, at 12:19 PM, Tim Hollebeek via Public > wrote: > > My experience is the reverse. IETF and groups with tight charters get bogged > down in constant discussions about charter revisions. CABF has recently > fallen into the same trap and I don’t think it is a change for the better. > There are other SDOs I participate in where groups have operated for 10+ > years with the same charter, with no downsides other than the fact that they > spend their time discussing and working on the relevant issues instead of > re-chartering every time a new topic comes up. smime.p7s Description: S/MIME cryptographic signature ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
Re: [cabfpub] [EXTERNAL]Re: Draft SMIME Working Group Charter
On Wed, Feb 6, 2019 at 3:20 PM Tim Hollebeek wrote: > My experience is the reverse. IETF and groups with tight charters get > bogged down in constant discussions about charter revisions. > Interesting example. While I do disagree with your conclusions, it's useful to understand the perspective and the context - IETF WGs that would regularly go off into the weeds and produce something unusuable, unimplemented, and not aligned with actual needs. Recall that this is why, especially in the PKI space, multiple WGs were shut down - because they constantly were getting distracted, lacking consensus, and yet still trudging on. While I can't speak with absolute certainty, the debate about adoptions - including in LAMPS - has I think helpfully demonstrated a very clear lack of consensus to take on the work, and that while sometimes the work is very important to some members, it's not seen as broadly valuable or with consensus. With something as broad as S/MIME, we absolutely need that level of restraint. > CABF has recently fallen into the same trap and I don’t think it is a > change for the better. There are other SDOs I participate in where groups > have operated for 10+ years with the same charter, with no downsides other > than the fact that they spend their time discussing and working on the > relevant issues instead of re-chartering every time a new topic comes up. > And do they scope their IP protections the same? And consensus measures? My choice of IETF and W3C wasn't accidental; they have also served as models for our workmode and IP protections. With something as broad as S/MIME, we absolutely need those level of protections. ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
Re: [cabfpub] [EXTERNAL]Re: Draft SMIME Working Group Charter
My experience is the reverse. IETF and groups with tight charters get bogged down in constant discussions about charter revisions. CABF has recently fallen into the same trap and I don’t think it is a change for the better. There are other SDOs I participate in where groups have operated for 10+ years with the same charter, with no downsides other than the fact that they spend their time discussing and working on the relevant issues instead of re-chartering every time a new topic comes up. -Tim From: Ryan Sleevi Sent: Wednesday, February 6, 2019 12:57 PM To: Tim Hollebeek Cc: CA/Browser Forum Public Discussion List ; Dean Coclin Subject: Re: [cabfpub] [EXTERNAL]Re: Draft SMIME Working Group Charter On Wed, Feb 6, 2019 at 12:41 PM Tim Hollebeek mailto:tim.holleb...@digicert.com> > wrote: There are many SDOs that I participate in that are able to manage their priorities effectively without hardcoding them into a charter. In fact, it’s more common than not. In my experience, SDOs that require a re-charter every time they want to discuss a new topic is indeed very disruptive and high overhead. I've tried to provide very detailed answers to support the position I'm advocating. Could you discuss more what parts you believe are disruptive and high overhead? Is it because there's disagreement on embracing the topic and/or disagreement on the appropriateness of the timing? While there are many SDOs, I will highlight that the SDOs that have been most successful for our line of work - that is, groups such as IETF and W3C - have fairly consistency and explicitly required 'tight' charters with explicit deliverables, as a way of measuring and ensuring progress. Groups that have tended to have very broad charters - which include ETSI and OASIS - tend to get extremely mired down in debates, much like the one we're having now, rather than focusing on the concrete deliverables. smime.p7s Description: S/MIME cryptographic signature ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
Re: [cabfpub] [EXTERNAL]Re: Draft SMIME Working Group Charter
On Wed, Feb 6, 2019 at 12:41 PM Tim Hollebeek wrote: > There are many SDOs that I participate in that are able to manage their > priorities effectively without hardcoding them into a charter. In fact, > it’s more common than not. In my experience, SDOs that require a > re-charter every time they want to discuss a new topic is indeed very > disruptive and high overhead. > I've tried to provide very detailed answers to support the position I'm advocating. Could you discuss more what parts you believe are disruptive and high overhead? Is it because there's disagreement on embracing the topic and/or disagreement on the appropriateness of the timing? While there are many SDOs, I will highlight that the SDOs that have been most successful for our line of work - that is, groups such as IETF and W3C - have fairly consistency and explicitly required 'tight' charters with explicit deliverables, as a way of measuring and ensuring progress. Groups that have tended to have very broad charters - which include ETSI and OASIS - tend to get extremely mired down in debates, much like the one we're having now, rather than focusing on the concrete deliverables. ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
Re: [cabfpub] [EXTERNAL]Re: Draft SMIME Working Group Charter
There are many SDOs that I participate in that are able to manage their priorities effectively without hardcoding them into a charter. In fact, it’s more common than not. In my experience, SDOs that require a re-charter every time they want to discuss a new topic is indeed very disruptive and high overhead. -Tim From: Public On Behalf Of Ryan Sleevi via Public Sent: Tuesday, February 5, 2019 4:02 PM To: Dean Coclin ; CA/Browser Forum Public Discussion List Subject: Re: [cabfpub] [EXTERNAL]Re: Draft SMIME Working Group Charter While I've yet to see an SDO successfully manage that approach, as you suggest, one of the benefits of dealing with it at the charter level is that it helps make sure there is consensus that the core is done, and that it's an appropriate time to move forward with identity. With an approach as you've described, there's a risk - one which I've personally seen happen in a number of WGs - that some members will feel it's time to start working on the update, while others feel that there's still work to be done to get the core out. The problem is that this debate - "is it time for Y" - ends up taking energy and focus away. You often see this in specs that have heavy involvement in the first 95%, but then drag on for the last 5% as everyone starts working on the 'new thing'. A ballot to update the charter addresses that, ensures that folks views are heard and represented, and quantifiably measures consensus, versus "who's loudest". It also helps discourage splinter-groups from forming that decided they want to tackle topic Y, even though it's "not time yet", because that's what they're interested in; if it's clear their work will have no place to go, it's much easier to discourage that and focus on the tough problems at hand with issuance. On Tue, Feb 5, 2019 at 3:43 PM Dean Coclin via Public mailto:public@cabforum.org> > wrote: There’s no reason why guidelines couldn’t be produced and then other sections added in a subsequent release. But why exclude that from the scope? That would mean having to go back later and adding it, potentially disrupting the work of the group. The group should just agree up front (and you can put it in the charter) that the initial release will include X and topic Y will be covered in an update. From: Public mailto:public-boun...@cabforum.org> > On Behalf Of Wayne Thayer via Public Sent: Tuesday, January 29, 2019 4:54 PM To: CA/Browser Forum Public Discussion List mailto:public@cabforum.org> > Subject: Re: [cabfpub] [EXTERNAL]Re: Draft SMIME Working Group Charter My intention is not to prevent CAs from issuing S/MIME certificates containing identity information. It's really what Ryan said and Rufus reiterated. There is a tremendous amount of work to do and the core of all of it is cert profiles and email validation practices. I expect that it will take a few years to get the core work published, and the complexity of identity validation could easily extend that by a year or more. I am particularly concerned (could just be my ignorance) about all the government-issued identity certificates that are valid for S/MIME. Our identity validation rules will need to support those use cases. Given how long S/MIME standards have already waited behind governance reform, I prefer a narrower initial scope that produces guidelines faster. On Tue, Jan 29, 2019 at 2:18 PM Buschart, Rufus mailto:rufus.busch...@siemens.com> > wrote: Hello! I would support the approach of Ryan (if I understood his approach correctly): Let’s start with the absolute minimal core and this is the validation of the email address and the definition of acceptable practices regarding key generation, key distribution and key escrow. I remember some discussions from last fall with Wayne about this issue when the new Mozilla Root Store Policies were drafted and it turned out that SMIME seems to be significantly different to TLS since the business needs are very much different. So there will be a lot to do with this issues. With best regards, Rufus Buschart Siemens AG Information Technology Human Resources PKI / Trustcenter GS IT HR 7 4 Hugo-Junkers-Str. 9 90411 Nuernberg, Germany Tel.: +49 1522 2894134 <mailto:rufus.busch...@siemens.com> mailto:rufus.busch...@siemens.com <http://www.twitter.com/siemens> www.twitter.com/siemens <https://siemens.com/ingenuityforlife> www.siemens.com/ingenuityforlife Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322 Von: Public mailto:public-boun...@cabfor
Re: [cabfpub] [EXTERNAL]Re: Draft SMIME Working Group Charter
On 6/2/2019 12:38 π.μ., Dean Coclin via Public wrote: Well I agree with your first comment “I suspect we'll disagree on this” This is a good topic for the F2F meeting as it will likely be more productive to have this discussion there and try to come to some conclusion. Dimitris-is this already on the agenda? If not, can we add? It certainly is. It might need more time though, we can update. We will discuss the F2F agenda on our scheduled teleconference call on February 21st. Of course, if members want to propose additional topics, they can check the draft agenda on the wiki and send me any updates they would like to see. For what it's worth, I agree with Dean that we should allow Identity in the scope and prioritize our focus. It was one of my earlier comments when the document was drafted and it's included as a comment in the online draft. The risk Ryan describes seems acceptable to me and something we can handle by adding the appropriate language in the Charter. Thanks, Dimitris. *From:* Ryan Sleevi *Sent:* Tuesday, February 5, 2019 4:39 PM *To:* Dean Coclin *Cc:* CA/Browser Forum Public Discussion List ; Wayne Thayer *Subject:* Re: [cabfpub] [EXTERNAL]Re: Draft SMIME Working Group Charter On Tue, Feb 5, 2019 at 4:29 PM Dean Coclin <mailto:dean.coc...@digicert.com>> wrote: While that’s true, there’s also the risk to that approach in that the community feels that topic X is not included in the charter and therefore will not be addressed or feel that it’s not important a topic to be addressed. By including it in the initial charter and by specifying the order of events, that insures it will be covered at some point. The charter can say simply (with better wording): “Topics A, B, C and X, Y, Z will be covered in the charter. Topics A, B, C will be the first ones addressed in the initial release of the guidelines. Topics X, Y, Z will be addressed in a subsequent release. The initial guidelines will have to be voted on and approved prior to moving to topics X, Y, Z.” This avoids the risk you describe about starting to work on the secondary topics before the first ones are approved. This insures the relevant topics expressed by the community are in scope but that an ordering is preferred and necessary. It also avoids a problem later on by anyone who doesn’t want to cover topics X, Y, Z and forces the working group to disband before they are addressed. I suspect we'll disagree on this, but what you describe as a bug is actually a feature. It defers the debate about topics X, Y, and Z, and how to address them, and when to address them, to a time later suited, in order to ensure that focus is executed on A, B, C. I'm supportive of language that helps assuage folks concerns by clarifying that it's excluded from scope without a statement about fitness for purpose, if that is the only reason to include X, Y, Z in the charter, but I believe there is substantial harm in including it as you've presented, for the reasons I explained previously. And while I realize that many members would prefer not to think about IP issues, including X, Y, and Z in scope mean that, at any time, participation may touch on IP on those topics, even if they're not 'yet' being tackled. Explicitly excluding from scope, and rechartering, helps provide meaningful check points for progress. Just as we talk about how "good" ballots are one that are focused and narrow to a problem at hand - which the Validation WG has done a fairly great job at demonstrating - the same applies to charters. Keeping focus is extremely valuable, and we shouldn't compromise that. ) ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
Re: [cabfpub] [EXTERNAL]Re: Draft SMIME Working Group Charter
Well I agree with your first comment “I suspect we'll disagree on this” This is a good topic for the F2F meeting as it will likely be more productive to have this discussion there and try to come to some conclusion. Dimitris-is this already on the agenda? If not, can we add? From: Ryan Sleevi Sent: Tuesday, February 5, 2019 4:39 PM To: Dean Coclin Cc: CA/Browser Forum Public Discussion List ; Wayne Thayer Subject: Re: [cabfpub] [EXTERNAL]Re: Draft SMIME Working Group Charter On Tue, Feb 5, 2019 at 4:29 PM Dean Coclin mailto:dean.coc...@digicert.com> > wrote: While that’s true, there’s also the risk to that approach in that the community feels that topic X is not included in the charter and therefore will not be addressed or feel that it’s not important a topic to be addressed. By including it in the initial charter and by specifying the order of events, that insures it will be covered at some point. The charter can say simply (with better wording): “Topics A, B, C and X, Y, Z will be covered in the charter. Topics A, B, C will be the first ones addressed in the initial release of the guidelines. Topics X, Y, Z will be addressed in a subsequent release. The initial guidelines will have to be voted on and approved prior to moving to topics X, Y, Z.” This avoids the risk you describe about starting to work on the secondary topics before the first ones are approved. This insures the relevant topics expressed by the community are in scope but that an ordering is preferred and necessary. It also avoids a problem later on by anyone who doesn’t want to cover topics X, Y, Z and forces the working group to disband before they are addressed. I suspect we'll disagree on this, but what you describe as a bug is actually a feature. It defers the debate about topics X, Y, and Z, and how to address them, and when to address them, to a time later suited, in order to ensure that focus is executed on A, B, C. I'm supportive of language that helps assuage folks concerns by clarifying that it's excluded from scope without a statement about fitness for purpose, if that is the only reason to include X, Y, Z in the charter, but I believe there is substantial harm in including it as you've presented, for the reasons I explained previously. And while I realize that many members would prefer not to think about IP issues, including X, Y, and Z in scope mean that, at any time, participation may touch on IP on those topics, even if they're not 'yet' being tackled. Explicitly excluding from scope, and rechartering, helps provide meaningful check points for progress. Just as we talk about how "good" ballots are one that are focused and narrow to a problem at hand - which the Validation WG has done a fairly great job at demonstrating - the same applies to charters. Keeping focus is extremely valuable, and we shouldn't compromise that. smime.p7s Description: S/MIME cryptographic signature ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
Re: [cabfpub] [EXTERNAL]Re: Draft SMIME Working Group Charter
On Tue, Feb 5, 2019 at 4:29 PM Dean Coclin wrote: > While that’s true, there’s also the risk to that approach in that the > community feels that topic X is not included in the charter and therefore > will not be addressed or feel that it’s not important a topic to be > addressed. > > > > By including it in the initial charter and by specifying the order of > events, that insures it will be covered at some point. The charter can say > simply (with better wording): > > > > “Topics A, B, C and X, Y, Z will be covered in the charter. Topics A, B, C > will be the first ones addressed in the initial release of the guidelines. > Topics X, Y, Z will be addressed in a subsequent release. The initial > guidelines will have to be voted on and approved prior to moving to topics > X, Y, Z.” This avoids the risk you describe about starting to work on the > secondary topics before the first ones are approved. > > > > This insures the relevant topics expressed by the community are in scope > but that an ordering is preferred and necessary. It also avoids a problem > later on by anyone who doesn’t want to cover topics X, Y, Z and forces the > working group to disband before they are addressed. > I suspect we'll disagree on this, but what you describe as a bug is actually a feature. It defers the debate about topics X, Y, and Z, and how to address them, and when to address them, to a time later suited, in order to ensure that focus is executed on A, B, C. I'm supportive of language that helps assuage folks concerns by clarifying that it's excluded from scope without a statement about fitness for purpose, if that is the only reason to include X, Y, Z in the charter, but I believe there is substantial harm in including it as you've presented, for the reasons I explained previously. And while I realize that many members would prefer not to think about IP issues, including X, Y, and Z in scope mean that, at any time, participation may touch on IP on those topics, even if they're not 'yet' being tackled. Explicitly excluding from scope, and rechartering, helps provide meaningful check points for progress. Just as we talk about how "good" ballots are one that are focused and narrow to a problem at hand - which the Validation WG has done a fairly great job at demonstrating - the same applies to charters. Keeping focus is extremely valuable, and we shouldn't compromise that. ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
Re: [cabfpub] [EXTERNAL]Re: Draft SMIME Working Group Charter
While that’s true, there’s also the risk to that approach in that the community feels that topic X is not included in the charter and therefore will not be addressed or feel that it’s not important a topic to be addressed. By including it in the initial charter and by specifying the order of events, that insures it will be covered at some point. The charter can say simply (with better wording): “Topics A, B, C and X, Y, Z will be covered in the charter. Topics A, B, C will be the first ones addressed in the initial release of the guidelines. Topics X, Y, Z will be addressed in a subsequent release. The initial guidelines will have to be voted on and approved prior to moving to topics X, Y, Z.” This avoids the risk you describe about starting to work on the secondary topics before the first ones are approved. This insures the relevant topics expressed by the community are in scope but that an ordering is preferred and necessary. It also avoids a problem later on by anyone who doesn’t want to cover topics X, Y, Z and forces the working group to disband before they are addressed. From: Ryan Sleevi Sent: Tuesday, February 5, 2019 4:02 PM To: Dean Coclin ; CA/Browser Forum Public Discussion List Cc: Wayne Thayer Subject: Re: [cabfpub] [EXTERNAL]Re: Draft SMIME Working Group Charter While I've yet to see an SDO successfully manage that approach, as you suggest, one of the benefits of dealing with it at the charter level is that it helps make sure there is consensus that the core is done, and that it's an appropriate time to move forward with identity. With an approach as you've described, there's a risk - one which I've personally seen happen in a number of WGs - that some members will feel it's time to start working on the update, while others feel that there's still work to be done to get the core out. The problem is that this debate - "is it time for Y" - ends up taking energy and focus away. You often see this in specs that have heavy involvement in the first 95%, but then drag on for the last 5% as everyone starts working on the 'new thing'. A ballot to update the charter addresses that, ensures that folks views are heard and represented, and quantifiably measures consensus, versus "who's loudest". It also helps discourage splinter-groups from forming that decided they want to tackle topic Y, even though it's "not time yet", because that's what they're interested in; if it's clear their work will have no place to go, it's much easier to discourage that and focus on the tough problems at hand with issuance. On Tue, Feb 5, 2019 at 3:43 PM Dean Coclin via Public mailto:public@cabforum.org> > wrote: There’s no reason why guidelines couldn’t be produced and then other sections added in a subsequent release. But why exclude that from the scope? That would mean having to go back later and adding it, potentially disrupting the work of the group. The group should just agree up front (and you can put it in the charter) that the initial release will include X and topic Y will be covered in an update. From: Public mailto:public-boun...@cabforum.org> > On Behalf Of Wayne Thayer via Public Sent: Tuesday, January 29, 2019 4:54 PM To: CA/Browser Forum Public Discussion List mailto:public@cabforum.org> > Subject: Re: [cabfpub] [EXTERNAL]Re: Draft SMIME Working Group Charter My intention is not to prevent CAs from issuing S/MIME certificates containing identity information. It's really what Ryan said and Rufus reiterated. There is a tremendous amount of work to do and the core of all of it is cert profiles and email validation practices. I expect that it will take a few years to get the core work published, and the complexity of identity validation could easily extend that by a year or more. I am particularly concerned (could just be my ignorance) about all the government-issued identity certificates that are valid for S/MIME. Our identity validation rules will need to support those use cases. Given how long S/MIME standards have already waited behind governance reform, I prefer a narrower initial scope that produces guidelines faster. On Tue, Jan 29, 2019 at 2:18 PM Buschart, Rufus mailto:rufus.busch...@siemens.com> > wrote: Hello! I would support the approach of Ryan (if I understood his approach correctly): Let’s start with the absolute minimal core and this is the validation of the email address and the definition of acceptable practices regarding key generation, key distribution and key escrow. I remember some discussions from last fall with Wayne about this issue when the new Mozilla Root Store Policies were drafted and it turned out that SMIME seems to be significantly different to TLS since the business needs are very much different. So there will be a lot to do with this issues. With best regards, Rufus Buschart Siemens AG Information Technology Human
Re: [cabfpub] [EXTERNAL]Re: Draft SMIME Working Group Charter
While I've yet to see an SDO successfully manage that approach, as you suggest, one of the benefits of dealing with it at the charter level is that it helps make sure there is consensus that the core is done, and that it's an appropriate time to move forward with identity. With an approach as you've described, there's a risk - one which I've personally seen happen in a number of WGs - that some members will feel it's time to start working on the update, while others feel that there's still work to be done to get the core out. The problem is that this debate - "is it time for Y" - ends up taking energy and focus away. You often see this in specs that have heavy involvement in the first 95%, but then drag on for the last 5% as everyone starts working on the 'new thing'. A ballot to update the charter addresses that, ensures that folks views are heard and represented, and quantifiably measures consensus, versus "who's loudest". It also helps discourage splinter-groups from forming that decided they want to tackle topic Y, even though it's "not time yet", because that's what they're interested in; if it's clear their work will have no place to go, it's much easier to discourage that and focus on the tough problems at hand with issuance. On Tue, Feb 5, 2019 at 3:43 PM Dean Coclin via Public wrote: > There’s no reason why guidelines couldn’t be produced and then other > sections added in a subsequent release. But why exclude that from the > scope? That would mean having to go back later and adding it, potentially > disrupting the work of the group. The group should just agree up front (and > you can put it in the charter) that the initial release will include X and > topic Y will be covered in an update. > > > > *From:* Public *On Behalf Of *Wayne Thayer > via Public > *Sent:* Tuesday, January 29, 2019 4:54 PM > *To:* CA/Browser Forum Public Discussion List > *Subject:* Re: [cabfpub] [EXTERNAL]Re: Draft SMIME Working Group Charter > > > > My intention is not to prevent CAs from issuing S/MIME certificates > containing identity information. It's really what Ryan said and Rufus > reiterated. > > > > There is a tremendous amount of work to do and the core of all of it is > cert profiles and email validation practices. I expect that it will take a > few years to get the core work published, and the complexity of identity > validation could easily extend that by a year or more. I am particularly > concerned (could just be my ignorance) about all the government-issued > identity certificates that are valid for S/MIME. Our identity validation > rules will need to support those use cases. Given how long S/MIME standards > have already waited behind governance reform, I prefer a narrower initial > scope that produces guidelines faster. > > > > On Tue, Jan 29, 2019 at 2:18 PM Buschart, Rufus < > rufus.busch...@siemens.com> wrote: > > Hello! > > > > I would support the approach of Ryan (if I understood his approach > correctly): Let’s start with the absolute minimal core and this is the > validation of the email address and the definition of acceptable practices > regarding key generation, key distribution and key escrow. I remember some > discussions from last fall with Wayne about this issue when the new Mozilla > Root Store Policies were drafted and it turned out that SMIME seems to be > significantly different to TLS since the business needs are very much > different. So there will be a lot to do with this issues. > > > > With best regards, > Rufus Buschart > > Siemens AG > Information Technology > Human Resources > PKI / Trustcenter > GS IT HR 7 4 > Hugo-Junkers-Str. 9 > 90411 Nuernberg, Germany > Tel.: +49 1522 2894134 > mailto:rufus.busch...@siemens.com > www.twitter.com/siemens > www.siemens.com/ingenuityforlife <https://siemens.com/ingenuityforlife> > [image: www.siemens.com/ingenuityforlife] > Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim > Hagemann Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief > Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, > Cedrik Neike, Michael Sen, Ralf P. Thomas; Registered offices: Berlin and > Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, > Munich, HRB 6684; WEEE-Reg.-No. DE 23691322 > > *Von:* Public *Im Auftrag von *Bruce Morton > via Public > *Gesendet:* Dienstag, 29. Januar 2019 21:50 > *An:* Wayne Thayer ; CA/Browser Forum Public > Discussion List > *Betreff:* Re: [cabfpub] [EXTERNAL]Re: Draft SMIME Working Group Charter > > > > Hi Wayne, > > > > Can you elaborate on why we should exclude identity validation from the > initial scope? > > > > My thinking is tha
Re: [cabfpub] [EXTERNAL]Re: Draft SMIME Working Group Charter
There’s no reason why guidelines couldn’t be produced and then other sections added in a subsequent release. But why exclude that from the scope? That would mean having to go back later and adding it, potentially disrupting the work of the group. The group should just agree up front (and you can put it in the charter) that the initial release will include X and topic Y will be covered in an update. From: Public On Behalf Of Wayne Thayer via Public Sent: Tuesday, January 29, 2019 4:54 PM To: CA/Browser Forum Public Discussion List Subject: Re: [cabfpub] [EXTERNAL]Re: Draft SMIME Working Group Charter My intention is not to prevent CAs from issuing S/MIME certificates containing identity information. It's really what Ryan said and Rufus reiterated. There is a tremendous amount of work to do and the core of all of it is cert profiles and email validation practices. I expect that it will take a few years to get the core work published, and the complexity of identity validation could easily extend that by a year or more. I am particularly concerned (could just be my ignorance) about all the government-issued identity certificates that are valid for S/MIME. Our identity validation rules will need to support those use cases. Given how long S/MIME standards have already waited behind governance reform, I prefer a narrower initial scope that produces guidelines faster. On Tue, Jan 29, 2019 at 2:18 PM Buschart, Rufus mailto:rufus.busch...@siemens.com> > wrote: Hello! I would support the approach of Ryan (if I understood his approach correctly): Let’s start with the absolute minimal core and this is the validation of the email address and the definition of acceptable practices regarding key generation, key distribution and key escrow. I remember some discussions from last fall with Wayne about this issue when the new Mozilla Root Store Policies were drafted and it turned out that SMIME seems to be significantly different to TLS since the business needs are very much different. So there will be a lot to do with this issues. With best regards, Rufus Buschart Siemens AG Information Technology Human Resources PKI / Trustcenter GS IT HR 7 4 Hugo-Junkers-Str. 9 90411 Nuernberg, Germany Tel.: +49 1522 2894134 <mailto:rufus.busch...@siemens.com> mailto:rufus.busch...@siemens.com <http://www.twitter.com/siemens> www.twitter.com/siemens <https://siemens.com/ingenuityforlife> www.siemens.com/ingenuityforlife Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322 Von: Public mailto:public-boun...@cabforum.org> > Im Auftrag von Bruce Morton via Public Gesendet: Dienstag, 29. Januar 2019 21:50 An: Wayne Thayer mailto:wtha...@mozilla.com> >; CA/Browser Forum Public Discussion List mailto:public@cabforum.org> > Betreff: Re: [cabfpub] [EXTERNAL]Re: Draft SMIME Working Group Charter Hi Wayne, Can you elaborate on why we should exclude identity validation from the initial scope? My thinking is that many CAs which are currently issuing S/MIME certificates are also including identity. I assume that most use similar methods that are defined in the BRs to validate identity. It would seem that it should be included in the scope to cover current practice. Thanks, Bruce. From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Wayne Thayer via Public Sent: January 25, 2019 1:37 PM To: Ryan Sleevi mailto:sle...@google.com> >; CA/Browser Forum Public Discussion List mailto:public@cabforum.org> > Subject: [EXTERNAL]Re: [cabfpub] Draft SMIME Working Group Charter WARNING: This email originated outside of Entrust Datacard. DO NOT CLICK links or attachments unless you trust the sender and know the content is safe. _ I agree that we should exclude identity validation from the initial scope of this working group. On Fri, Jan 25, 2019 at 10:04 AM Ryan Sleevi via Public mailto:public@cabforum.org> > wrote: Finally, regarding membership criteria, I'm curious whether it's necessary to consider WebTrust for CAs / ETSI at all. For work like this, would it make sense to merely specify the requirements for a CA as one that is trusted for and actively issues S/MIME certificates that are accepted by a Certificate Consumer. This seems to be widely inclusive and can be iterated upon if/when improved criteria are developed, if appropriate. This would allow a CA that is not eligible for full Forum membership to join this WG as a full member. How would that work? Would we require such an organization to join the Forum as an
Re: [cabfpub] [EXTERNAL]Re: Draft SMIME Working Group Charter
My intention is not to prevent CAs from issuing S/MIME certificates containing identity information. It's really what Ryan said and Rufus reiterated. There is a tremendous amount of work to do and the core of all of it is cert profiles and email validation practices. I expect that it will take a few years to get the core work published, and the complexity of identity validation could easily extend that by a year or more. I am particularly concerned (could just be my ignorance) about all the government-issued identity certificates that are valid for S/MIME. Our identity validation rules will need to support those use cases. Given how long S/MIME standards have already waited behind governance reform, I prefer a narrower initial scope that produces guidelines faster. On Tue, Jan 29, 2019 at 2:18 PM Buschart, Rufus wrote: > Hello! > > > > I would support the approach of Ryan (if I understood his approach > correctly): Let’s start with the absolute minimal core and this is the > validation of the email address and the definition of acceptable practices > regarding key generation, key distribution and key escrow. I remember some > discussions from last fall with Wayne about this issue when the new Mozilla > Root Store Policies were drafted and it turned out that SMIME seems to be > significantly different to TLS since the business needs are very much > different. So there will be a lot to do with this issues. > > > > With best regards, > Rufus Buschart > > Siemens AG > Information Technology > Human Resources > PKI / Trustcenter > GS IT HR 7 4 > Hugo-Junkers-Str. 9 > 90411 Nuernberg, Germany > Tel.: +49 1522 2894134 > mailto:rufus.busch...@siemens.com > www.twitter.com/siemens > www.siemens.com/ingenuityforlife <https://siemens.com/ingenuityforlife> > [image: www.siemens.com/ingenuityforlife] > Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim > Hagemann Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief > Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, > Cedrik Neike, Michael Sen, Ralf P. Thomas; Registered offices: Berlin and > Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, > Munich, HRB 6684; WEEE-Reg.-No. DE 23691322 > > *Von:* Public *Im Auftrag von *Bruce Morton > via Public > *Gesendet:* Dienstag, 29. Januar 2019 21:50 > *An:* Wayne Thayer ; CA/Browser Forum Public > Discussion List > *Betreff:* Re: [cabfpub] [EXTERNAL]Re: Draft SMIME Working Group Charter > > > > Hi Wayne, > > > > Can you elaborate on why we should exclude identity validation from the > initial scope? > > > > My thinking is that many CAs which are currently issuing S/MIME > certificates are also including identity. I assume that most use similar > methods that are defined in the BRs to validate identity. It would seem > that it should be included in the scope to cover current practice. > > > > Thanks, Bruce. > > > > *From:* Public [mailto:public-boun...@cabforum.org > ] *On Behalf Of *Wayne Thayer via Public > *Sent:* January 25, 2019 1:37 PM > *To:* Ryan Sleevi ; CA/Browser Forum Public Discussion > List > *Subject:* [EXTERNAL]Re: [cabfpub] Draft SMIME Working Group Charter > > > > *WARNING:* This email originated outside of Entrust Datacard. > *DO NOT CLICK* links or attachments unless you trust the sender and know > the content is safe. > -- > > I agree that we should exclude identity validation from the initial scope > of this working group. > > > > On Fri, Jan 25, 2019 at 10:04 AM Ryan Sleevi via Public < > public@cabforum.org> wrote: > > > > Finally, regarding membership criteria, I'm curious whether it's necessary > to consider WebTrust for CAs / ETSI at all. For work like this, would it > make sense to merely specify the requirements for a CA as one that is > trusted for and actively issues S/MIME certificates that are accepted by a > Certificate Consumer. This seems to be widely inclusive and can be iterated > upon if/when improved criteria are developed, if appropriate. > > > > This would allow a CA that is not eligible for full Forum membership to > join this WG as a full member. How would that work? Would we require such > an organization to join the Forum as an Interested Party? If the idea is > that such an organization wouldn't be required to join the Forum, then I > don't believe that was anticipated or intended in the design of the current > structure. It's not clear to me that we should permit membership in a CWG > without Forum membership. For instance, allowing this may create loopholes > in the IPR obligatio
Re: [cabfpub] [EXTERNAL]Re: Draft SMIME Working Group Charter
Hi Wayne, Can you elaborate on why we should exclude identity validation from the initial scope? My thinking is that many CAs which are currently issuing S/MIME certificates are also including identity. I assume that most use similar methods that are defined in the BRs to validate identity. It would seem that it should be included in the scope to cover current practice. Thanks, Bruce. From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Wayne Thayer via Public Sent: January 25, 2019 1:37 PM To: Ryan Sleevi ; CA/Browser Forum Public Discussion List Subject: [EXTERNAL]Re: [cabfpub] Draft SMIME Working Group Charter WARNING: This email originated outside of Entrust Datacard. DO NOT CLICK links or attachments unless you trust the sender and know the content is safe. I agree that we should exclude identity validation from the initial scope of this working group. On Fri, Jan 25, 2019 at 10:04 AM Ryan Sleevi via Public mailto:public@cabforum.org>> wrote: Finally, regarding membership criteria, I'm curious whether it's necessary to consider WebTrust for CAs / ETSI at all. For work like this, would it make sense to merely specify the requirements for a CA as one that is trusted for and actively issues S/MIME certificates that are accepted by a Certificate Consumer. This seems to be widely inclusive and can be iterated upon if/when improved criteria are developed, if appropriate. This would allow a CA that is not eligible for full Forum membership to join this WG as a full member. How would that work? Would we require such an organization to join the Forum as an Interested Party? If the idea is that such an organization wouldn't be required to join the Forum, then I don't believe that was anticipated or intended in the design of the current structure. It's not clear to me that we should permit membership in a CWG without Forum membership. For instance, allowing this may create loopholes in the IPR obligations that are defined and administered at the Forum level. There's also a bootstrapping issue for membership, in that until we know who the accepted Certificate Consumers are, no CA can join as a Certificate Issuer. I'm curious whether it makes sense to explicitly bootstrap this in the charter or how we'd like to tackle this. ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
