[Servercert-wg] Ballot SC 13 version 2

[Tim Hollebeek]

Thanks, I missed your comment on the errata issue.  I agree that referencing the broken search algorithm in 6844 would be problematic.

 

Would changing it to be “RFC 6844 (as amended by errata 5065)” address your concerns?

 

-Tim

 

From: Ryan Sleevi <sleevi at google.com> 
Sent: Tuesday, November 20, 2018 2:48 PM
To: Tim Hollebeek <tim.hollebeek at digicert.com>
Cc: servercert-wg at cabforum.org
Subject: Re: [Servercert-wg] Ballot SC 13 version 2

 

Thanks for clarifying. I tried to explain why such language would not resolve the issue, but apologies if I was not clear enough. By specifying it as worded, this has the issues I mentioned regarding errata. This proposed change is inconsistent with the rest of the BRs regarding 6844, and thus seems like it will only add confusion. I do hope you'll reconsider for these reasons. As it stands, the proposed change - intending to remove ambiguity - only adds it.

 

On Tue, Nov 20, 2018 at 1:57 PM Tim Hollebeek <tim.hollebeek at digicert.com <mailto:tim.hollebeek at digicert.com> > wrote:

Thanks for proposing improved language.

 

(New) > The Random Value MUST be sent to an email address contained in a contactemail property tag, as defined in Appendix B, present in the CAA Resource Record Set.

(Newer) “… present in the relevant CAA Resource Record Set as described in RFC 6844 section 4” ?

 

I intentionally wanted to use “relevant” and “section 4” to make it unambiguously clear that the same search algorithm is intended.

 

-Tim

 

From: Ryan Sleevi <sleevi at google.com <mailto:sleevi at google.com> > 
Sent: Tuesday, November 20, 2018 1:29 PM
To: Tim Hollebeek <tim.hollebeek at digicert.com <mailto:tim.hollebeek at digicert.com> >; servercert-wg at cabforum.org <mailto:servercert-wg at cabforum.org> 
Subject: Re: [Servercert-wg] Ballot SC 13 version 2

 

Can you explain the motivation a bit more for the following addition:

 

> This email address is a valid contact address for all domains it is relevant for via the standard CAA search algorithm specified in RFC 6844 section 4.

 

As best I can tell, you're trying to suggest that the CAA processing rules apply. If that's the case, I don't think this language achieves what you want in a clear and unambiguous way. For example, does this section consider the Errata or not? One reading is that by saying "standard CAA search algorithm", you do not consider the Errata allowed in other areas.

 

Further, it also does not seem appropriate to place it in this section (the appendix definition of the tag), as opposed to the validation method itself, which is where the *processing* of the tag appropriately belongs.

 

I believe you want to place this within the validation sections (e.g. 3.2.2.4.13), by describing it as (in that section)

(Old) > The Random Value MUST be sent to an email address identified as a CAA contactemail property record as defined in Appendix B.

(New) > The Random Value MUST be sent to an email address contained in a contactemail property tag, as defined in Appendix B, present in the CAA Resource Record Set.

 

The point being that the algorithm that is applied (for determining the CAA Resource Record Set) is left to be consistent with all other CAA handling, and you're instead emphasizing that one _or more_ contactemail property tags be present in the resultant CAA Resource Record Set.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20181121/8da7e2d2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20181121/8da7e2d2/attachment-0001.p7s>