[Servercert-wg] Ballot SC 13 version 2

[Doug Beattie]

I guess the question is, what is the right logic to be used to find approver email addresses in CAA records?  It’s not clear if we use the same logic as the issue tag.  

 

Once we find a non-empty contactemail record, are we required to stop and use that, or are we permitted to go down the ADN path looking for others?  I was assuming you’d look for approver email addresses in all locations and also following CNAMEs and then you’d end up with a list of approver emails you can use.  This is entirely different than looking to see if you are permitted to issue or not.

 

Doug

 

 

 

From: Tim Hollebeek <tim.hollebeek at digicert.com> 
Sent: Wednesday, November 21, 2018 12:20 PM
To: Doug Beattie <doug.beattie at globalsign.com>
Cc: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: RE: [Servercert-wg] Ballot SC 13 version 2

 

Ryan has a legitimate point that is worth addressing.  It shouldn’t take long; my proposed revised language now mirrors what we did in section 3.2.2.8.

 

-Tim

 

From: Doug Beattie <doug.beattie at globalsign.com> 
Sent: Wednesday, November 21, 2018 6:22 AM
To: Tim Hollebeek <tim.hollebeek at digicert.com>
Cc: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: RE: [Servercert-wg] Ballot SC 13 version 2

 

Tim,

 

If CAA rules are getting in the way of this ballot then I suggest we drop Method 13 and proceed with just Method 14 (DNS TXT).

 

Doug

 

From: Servercert-wg <servercert-wg-bounces at cabforum.org <mailto:servercert-wg-bounces at cabforum.org> > On Behalf Of Ryan Sleevi via Servercert-wg
Sent: Wednesday, November 21, 2018 12:14 AM
To: Geoff Keating <geoffk at apple.com <mailto:geoffk at apple.com> >
Cc: servercert-wg at cabforum.org <mailto:servercert-wg at cabforum.org> 
Subject: Re: [Servercert-wg] Ballot SC 13 version 2

 

They do - but this is not verified errata, and thus that discussion is not relevant.

 

It is marked as Hold for Document Update, which as the status suggests, means that it's something to be addressed as a normative change in a subsequent document (which may obsolete 6844). It's equally inconsistent with the remainder of the language in the BRs, and thus, as I mentioned, only adds to the confusion.

 

On Tue, Nov 20, 2018 at 7:27 PM Geoff Keating <geoffk at apple.com <mailto:geoffk at apple.com> > wrote:

My understanding is that verified errata change the RFC—the conceit is that the RFC always intended to say what the errata corrects it to—so referring to ‘RFC 6844 section 4’ includes any verified errata.

> On 20 Nov 2018, at 11:47 am, Ryan Sleevi via Servercert-wg <servercert-wg at cabforum.org <mailto:servercert-wg at cabforum.org> > wrote:
> 
> 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.

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