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

[Doug Beattie]

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 <mailto:tim.hollebeek at digicert.com> > wrote:

From: mailto://tim.hollebeek@digicert.com

To: mailto://sleevi@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/5fa38f13/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5736 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20180809/5fa38f13/attachment-0003.p7s>