[cabfpub] [Servercert-wg] Ballot SC4 - email and CAA CONTACT

[Ryan Sleevi]

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 <doug.beattie at globalsign.com>
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 <servercert-wg-bounces at cabforum.org> *On Behalf Of *Ryan
> Sleevi via Servercert-wg
> *Sent:* Wednesday, August 8, 2018 10:43 PM
> *To:* Tim Hollebeek <tim.hollebeek at digicert.com>
> *Cc:* servercert-wg at cabforum.org; CABFPub <public at cabforum.org>
> *Subject:* Re: [Servercert-wg] Ballot SC4 - email and CAA CONTACT
>
>
>
>
>
> On Wed, Aug 8, 2018 at 10:30 PM Tim Hollebeek <tim.hollebeek at digicert.com>
> wrote:
>
> From: mailto://tim.hollebeek@digicert.com <//tim.hollebeek at digicert.com>
>
> To: mailto://sleevi@google.com <//sleevi at google.com>
>
>
>
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20180809/845c9cee/attachment-0003.html>