It is worth noting that the need for an invitation only apples to Face to Face meetings. There is no restriction on who can be an Interested Party and participate in working groups and subcommittees, as long as you are able to sign the Intellectual Property Rights agreement. I’d encourage anyone interested in discussing this issue there to do so.
-Tim From: Acme <acme-boun...@ietf.org> On Behalf Of Ryan Sleevi Sent: Sunday, October 21, 2018 9:02 PM To: Ben Kaduk <ka...@mit.edu> Cc: Ryan Sleevi <ryan-i...@sleevi.com>; Salz, Rich <rs...@akamai.com>; ke...@iseclab.org; IETF ACME <acme@ietf.org>; Tobias Fiebig <t.fie...@tudelft.nl> Subject: Re: [Acme] ACME DV Security Considerations Draft On Sun, Oct 21, 2018 at 6:48 PM Benjamin Kaduk <ka...@mit.edu <mailto:ka...@mit.edu> > wrote: On Sun, Oct 21, 2018 at 05:25:40PM +0000, Salz, Rich wrote: > * It does not seem to be related to ACME - that is, what you’re > describing is more broadly a set of concerns with the methods that may be > used to validate a domain. > > Perhaps ACME isn’t the right place for this, perhaps it should be reviewed by > SecDispatch, or whatever the DNS equivalent is, or coordinated between the > two area AD’s. Since there are proposed solutions in here, secdispatch would seem like a fine place (and the latest agenda I saw for them had some slots free, still). There might also be a place for a more open-ended discussion of problems with DV in SAAG, if someone were to volunteer to prepare some slides and structure the discussion. Thanks. I agree secdispatch is probably a better place for this. The CA/Browser Forum's Validation WG attempted to perform a similar analysis during it's F2F in Herdon, VA, as captured ever so briefly in https://cabforum.org/2018/03/08/final-minutes-for-ca-browser-forum-f2f-meeting-herndon-va-7-8-march-2018/ . This was the first (and only) meeting in which the Forum Chair extended blanket invitations for experts to participate, and while well-attended, is nowhere near the open participation model that the IETF represents. Work on attempting to resolve some of the security concerns is captured in http://cabforum.org/pipermail/validation , although the limited participation (largely of CAs) prevents a lot of the thorough analysis this work represents, and having a broader participation such as through secdispatch is better for the ecosystem as a whole. One minor pedantic quibble, however, is that I think the discussion would be better served by not speaking of it as ACME or DV. The notion of "DV/OV/EV" is an arbitrary marketing distinction with no security value - all certificate types rely on the same procedures for validating an assertion of control (organizational or operational) over a domain name. Indeed, in many cases, forms of certificates such as OV/EV have been demonstrated to be significantly weaker in practice - for example, that the organization name in WHOIS (i.e. "Google, Inc") matches an incorporated institution somewhere named the same - without any further validation about which "Google, Inc" is being referred to, soft-matches such as "Google, LLC", or even relationships such as "There's a Google LLC as a subsidiary of Alphabet, and this company's name is Alphabets, so that's probably OK". By speaking more generally of the challenges of validating a domain, we allow speaking with precision without the distinction of marketing or branding, and addressing the underlying security issues more directly.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
