Doug, Corey offered two distinct proposals, both of which would have resolved the issue - and one with more strengths in this regard. That was in https://cabforum.org/pipermail/servercert-wg/2018-August/000073.html . One approach was through better normative specification of the format, another was in aligning the format between CAA and TXT.
Tim rejected both suggestions to resolve the issue. I was pointing out that the logic behind that rejection is fundamentally unsound, and that if they're going to be rejected as such, then there's an onus on Tim to provide a better proposal that he sees as resolving the issues Corey highlighted. On Thu, Aug 9, 2018 at 6:55 AM Doug Beattie <[email protected]> wrote: > Ryan, > > > > Would it be possible for you to recommend an approach that addresses your > concerns with the format of email address, user and CA user unfriendless? > I hear your concerns (one after another), but it’s difficult to formulate a > proposal that resolves them without some more information from you on what > would be acceptable. > > > > Doug > > > > *From:* Servercert-wg <[email protected]> *On Behalf Of *Ryan > Sleevi via Servercert-wg > *Sent:* Wednesday, August 8, 2018 10:43 PM > *To:* Tim Hollebeek <[email protected]> > *Cc:* [email protected]; CABFPub <[email protected]> > *Subject:* Re: [Servercert-wg] Ballot SC4 - email and CAA CONTACT > > > > > > On Wed, Aug 8, 2018 at 10:30 PM Tim Hollebeek <[email protected]> > wrote: > > From: mailto://[email protected] <//[email protected]> > > To: mailto://[email protected] <//[email protected]> > > > > To make it clear, I don’t think turning things into URIs adds value for > customers. E-mail addresses usually AREN’T in the form of URIs, as noted > above. > > > > Except, again, this is dodging the point that Corey raised, and which you > haven't at all addressed, in which you're proposing a form that leaves it > entirely ambiguous to the CA, and subjective to their interpretation, as to > the form - and ambiguous for customers. > > > > If your view is that you're being customer focused, then that's not really > sustained by any of the positions being advocated here. The ambiguity > you're arguing is a strength is going to lead to misissued certificates and > confused customers. The fact that there's multiple ways to do it - URI > (CAA) vs non-URI (TXT) - is going to lead to confusion. The fact that > you're arguing the non-URI form is the preferred approach, while TXT is the > legacy approach, is entirely logically inconsistent. > > > > Your proposals don't make sense. And they don't stand serious scrutiny on > their merits. > > > > Lets say, however, that you decide to say that the CAA value should match > the contents of the TXT value, and that both need to be 'some' form of > email address. You need to define what that format is going to be, in a > clear, consistent, and unambiguous form. As you do so, it's going to be > inconsistent with how the iodef field is defined, adding more complexity - > and the very risk of error you're seemingly trying to avoid. > > > > My position is easy to square given that I originally didn’t want to have > URIs in the original proposal. It was only added in an attempt to gain > support for the ballot. Since that doesn’t seem to have worked, I think we > should seriously consider returning to the customer friendly form for all > use cases. > > > > You haven't demonstrated it's customer friendly. Nor have you demonstrated > how the form you're proposing can actually achieve those goals, because, as > it stands, what is written and what has been proposed is CA-hostile and > user-hostile. > > > > Especially if, as seems common recently, any attempt to address objections > to proposals just results in an endless series of more objections. > > > > You haven't put forward any attempt that meaningfully addresses the > objections though. What you see as an endless series of more objections is > the same objections being highlighted as unmet, and multiple attempts to > highlight why that's the case. > > > > Also, as usual, your tone is unhelpful. It’s best to be respectful of > other people’s positions and attempts to overcome objections, especially if > they’re working hard to address your concerns. I can certainly stop doing > that, and work with the rest of the WG instead, if you want. > > > > I haven't seen any attempt that actually addresses the concerns raised. > And I don't think these objections you're making to using URIs consistently > - between CAA properties and between CAA and TXT - are at all reasonable, > because they're not at all internally consistent. At best, it's "Tim > doesn't like them". And that's profoundly unhelpful. I don't think tone > policing <https://en.wikipedia.org/wiki/Tone_policing> is going to > overcome the structural deficiencies with your proposal either. >
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
