[cabfpub] CAA working group description

[Phillip]

I am interested in working on this (obviously).

My only concern is that we need to make sure that issues are being raised in the right forum which means that either we all raise them in the IETF LAMPS working group or we work out some formalized method for conveying issues from one into the other.

I sent off a fairly long message to the LAMPS group today which I think maps out the issues and where we need to go, in brief:

1) A new discovery mechanism.
2) An appendix, probably not normative that works through the implementation issues in excruciating detail. This includes the DNSSEC issues, failures, etc.

DNS is of course one of the worst infrastructures I could have picked for this. My only excuse being that there wasn't any alternative, let alone a better alternative. 



> -----Original Message-----
> From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Geoff
> Keating via Public
> Sent: Wednesday, October 4, 2017 4:33 AM
> To: CA/Browser Forum Public Discussion List <public at cabforum.org>
> Subject: [cabfpub] CAA working group description
> 
> Ballot XXX - Formalization of validation working group
> 
> ----
> Reason
> ----
> 
> As discussed at the CABforum meeting in Taipei, the Validation working
> group has proposed several ballots involving CAA.  It was thought that
> working group might now be somewhat busy with follow-ups from Ballot
> 190, that CAA is no longer obviously part of validation, and that perhaps a
> different group of people might be interested in CAA than in validation
> methods generally.
> 
> Geoffrey Keating of Apple Inc. made the following motion, which was
> endorsed by YYY and ZZZ
> 
> ----
> Motion begins
> ----
> 
> In accordance with Section 5.3 of the CA/B Forum Bylaws, the chartering of a
> new Working Group requires a ballot. This ballot charters the CAA Working
> Group.  The CAA Working Group’s charter will be as follows:
> 
> Scope
> 
> To consider and propose refinements and extensions to the Baseline
> Requirements related to checking for CAA records, RFC 6844, its errata, and
> its successors if any, taking into account implementation experience.
> 
> Deliverables
> 
> The Working Group shall produce:
> 
> - One or more ballots on the topics in its scope.
> - Documents, as it sees fit, providing information to the Forum on
> implementation experience of CAA record checking.
> 
> Expiry
> 
> The Working Group shall expire once it determines that the deliverables have
> been completed, or on 2019-10-01, whichever happens first.
> 
> Unless the working group has determined that its deliverables have been
> completed, the expiry date given above shall be automatically postponed by
> 1 year on 2019-09-01 ("postponement date") and each anniversary of the
> postponement date thereafter unless three or more members separately or
> jointly request on the Public Mail List, within one month prior to a particular
> postponement date, that expiry of this Working Group not be postponed in
> that instance.
> 
> ----
> Motion Ends
> ----
> 
> <ballot boilerplate goes here>