[Servercert-wg] Ballot SC 13 version 2

[Tim Hollebeek]

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/e285a2da/attachment.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/e285a2da/attachment.p7s>