[cabfpub] CAA working group description

[Geoff Keating]

I tried to write the CABForum WG charter so that it did not include changes to the CAA specification itself; these should indeed be handled at the IETF level.  This WG is about adoption of CAA in the Baseline Requirements.  Some topics we might cover are:

- Requirement for DNSSEC checking—for example, we might extend the current requirements so that CAs obtain and retain a record of the NSEC/NSEC3 record proving a subdomain does not use DNSSEC, even if they don’t actually check the crypto
- Error handling—for example, perhaps repeated failure to find a record should be treated as if the record is missing, rather than the current interpretation where we treat it as if the record exists and allows issuance, or we might just go to fail-closed
- Adoption of any new IETF RFCs, which may need to be phased in
- Adoption of any new IETF Errata

I don’t think any of these apply at the IETF level; I’m sure the IETF is not going to specify a ‘what if you only wanted a little bit of DNSSEC’ configuration, I think the IETF RFC should specify fail-closed because that’s the only fully secure approach, and the IETF can’t specify adoption of their standards in the Baseline Requirements.

> On 5 Oct 2017, at 11:09 am, Phillip via Public <public at cabforum.org> wrote:
> 
> I can well imagine a possibility where the IETF WG might leave some parts of the specification specified in less detail than would be desirable for compliance purposes and thus make work in CABForum desirable. But lets cross that bridge if we come to it.
>  
> What somewhat worries me is a situation in which I have ten CABForum members tell me that they really want X in a CABForum group and then I report that into the IETF WG and three people say they have other ideas and there being 3 of them and one of me, they represent the consensus. IETF process does allow for liasons and there might be an argument for a CABForum/IETF liason. But that does not seem like the right approach here.
>  
>  
>  
> From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi via Public
> Sent: Thursday, October 5, 2017 1:52 PM
> To: Jacob Hoffman-Andrews <jsha at letsencrypt.org>; CA/Browser Forum Public Discussion List <public at cabforum.org>
> Subject: Re: [cabfpub] CAA working group description
>  
> I agree with both Phillip and Jacob here. I think LAMPS is a great venue for working out the technical issues of discussion - and identifying where policy flexibility is needed or the challenges - and then bringing that as maybe one or two more ballots into the Forum. I think the technical clarifications and edge cases that we've seen discussed are totally within the realm of IETF's goals of interoperability, so we should try to use that as much as possible :)
>  
> The extent of Forum ballots seems like it may be adopting one or two more technical erratum (if interoperability issues arise and raised in IETF), and then potentially exploring adopting the newer version being proposed in LAMPS once completed.
>  
> On Thu, Oct 5, 2017 at 10:40 AM, Jacob Hoffman-Andrews via Public <public at cabforum.org <mailto:public at cabforum.org>> wrote:
>> With respect, I would suggest that there is already a CAA working group: the IETF LAMPS WG at https://datatracker.ietf.org/wg/lamps/charter/ <https://datatracker.ietf.org/wg/lamps/charter/>. It has the advantage of being open for anyone to join and post, so CAs can more easily have conversations with Subscribers and Relying Parties. If half of the CAA conversation happens in LAMPS and half happens here, it will be harder for Subscribers and Relying Parties to fully participate.
>>  
>> I'd definitely encourage anyone in the CA/Browser Forum who is interested in CAA issues to join the LAMPS mailing list at https://www.ietf.org/mailman/listinfo/spasm <https://www.ietf.org/mailman/listinfo/spasm> (confusingly, the mailing list is named SPASM, a holdover from an earlier name).
>>  
>> I think it's likely there will be another ballot or two in the CA/Browser Forum clarifying some of the language we use to incorporate CAA, but I think the amount of work is not enough to justify splitting out a second working group.
>> 
>> _______________________________________________
>> Public mailing list
>> Public at cabforum.org <mailto:Public at cabforum.org>
>> https://cabforum.org/mailman/listinfo/public <https://cabforum.org/mailman/listinfo/public>
>  
> _______________________________________________
> Public mailing list
> Public at cabforum.org <mailto:Public at cabforum.org>
> https://cabforum.org/mailman/listinfo/public <https://cabforum.org/mailman/listinfo/public>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20171009/e3d3b1ae/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3321 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20171009/e3d3b1ae/attachment-0003.p7s>