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

[Ryan Sleevi]

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://cabforum.org/pipermail/servercert-wg/attachments/20180808/5271afc4/attachment-0001.html>