Re: [cabfpub] CAA working group description

[Phillip via Public]

We had the Lamps meeting and discussed CAA. I think we now have a clear path on 
how to proceed and what is in scope of the document and what is not.

 

I won’t try to explain it now due to the teleconferencing lag kicking in.

 

 

 

From: Ben Wilson [mailto:ben.wil...@digicert.com] 
Sent: Thursday, November 16, 2017 11:26 AM
To: Geoff Keating <geo...@apple.com>; CA/Browser Forum Public Discussion List 
<public@cabforum.org>; Phillip <phill...@comodo.com>
Subject: RE: [cabfpub] CAA working group description

 

Let’s put this on the agenda for next CABF teleconference.

 

Ben Wilson, JD, CISA, CISSP

VP Compliance

+1 801 701 9678



 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Geoff Keating 
via Public
Sent: Monday, October 9, 2017 5:04 PM
To: Phillip <phill...@comodo.com <mailto:phill...@comodo.com> >; CA/Browser 
Forum Public Discussion List <public@cabforum.org <mailto:public@cabforum.org> >
Subject: Re: [cabfpub] CAA working group description

 

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@cabforum.org 
<mailto:public@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-boun...@cabforum.org] On Behalf Of Ryan Sleevi via 
Public
Sent: Thursday, October 5, 2017 1:52 PM
To: Jacob Hoffman-Andrews <j...@letsencrypt.org <mailto:j...@letsencrypt.org> 
>; CA/Browser Forum Public Discussion List <public@cabforum.org 
<mailto:public@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 < 
<mailto:public@cabforum.org> public@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

Re: [cabfpub] CAA working group description

[Ben Wilson via Public]

Let’s put this on the agenda for next CABF teleconference.

 

Ben Wilson, JD, CISA, CISSP

VP Compliance

+1 801 701 9678



 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Geoff Keating 
via Public
Sent: Monday, October 9, 2017 5:04 PM
To: Phillip <phill...@comodo.com>; CA/Browser Forum Public Discussion List 
<public@cabforum.org>
Subject: Re: [cabfpub] CAA working group description

 

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@cabforum.org 
<mailto:public@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-boun...@cabforum.org] On Behalf Of Ryan Sleevi via 
Public
Sent: Thursday, October 5, 2017 1:52 PM
To: Jacob Hoffman-Andrews <j...@letsencrypt.org <mailto:j...@letsencrypt.org> 
>; CA/Browser Forum Public Discussion List <public@cabforum.org 
<mailto:public@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 < 
<mailto:public@cabforum.org> public@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
 <mailto:Public@cabforum.org> Public@cabforum.org
 <https://cabforum.org/mailman/listinfo/public> 
https://cabforum.org/mailman/listinfo/public

 

Re: [cabfpub] CAA working group description

[Jacob Hoffman-Andrews via Public]

On Mon, Oct 9, 2017 at 4:04 PM, Geoff Keating  wrote:

> 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
>

Why not? If DNSSEC is not deployable in practice by CAs, that's something
the IETF needs to reckon with and include in its specs. We can't allow
DNSSEC deployment problems to become an elephant in the room that nobody
wants to bring to the IETF because there are hard-liners there.

 > I think the IETF RFC should specify fail-closed because that’s the only
fully secure approach

I agree, and I pushed for this when adopting the CAA ballot at CA/Browser
Forum. This is what Let's Encrypt currently implements. However, during
voting on the CAA ballot, some CAs expressed that they couldn't deploy
that, which is why we have an exception for retried failures. This is
exactly why we need those CAs to participate at LAMPS. If deploying
fail-closed CAA is impractical, IETF should acknowledge that and write it
into the next RFC. But that can't happen without LAMPS participation from
CAs that fail open.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] CAA working group description

[Geoff Keating via Public]

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@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-boun...@cabforum.org] On Behalf Of Ryan Sleevi 
> via Public
> Sent: Thursday, October 5, 2017 1:52 PM
> To: Jacob Hoffman-Andrews <j...@letsencrypt.org>; CA/Browser Forum Public 
> Discussion List <public@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@cabforum.org <mailto:public@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@cabforum.org <mailto:Public@cabforum.org>
>> https://cabforum.org/mailman/listinfo/public 
>> <https://cabforum.org/mailman/listinfo/public>
>  
> ___
> Public mailing list
> Public@cabforum.org <mailto:Public@cabforum.org>
> https://cabforum.org/mailman/listinfo/public 
> <https://cabforum.org/mailman/listinfo/public>


smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] CAA working group description

[Phillip via Public]

I am thinking the decision process needs to be three valued.

 

*   Success
*   Unknown
*   DNSSEC Fail

 

Without DNSSEC, it is not going to be possible to distinguish ordinary network 
failures from attacks. 

 

I don’t see a problem with an incentive to deploy DNSSEC so long as it is not 
mandatory.

 

 

 

From: Jacob Hoffman-Andrews [mailto:j...@letsencrypt.org] 
Sent: Friday, October 6, 2017 6:06 PM
To: Doug Beattie <doug.beat...@globalsign.com>
Cc: Phillip <phill...@comodo.com>; CA/Browser Forum Public Discussion List 
<public@cabforum.org>; Ryan Sleevi <sle...@google.com>
Subject: Re: [cabfpub] CAA working group description

 

On Thu, Oct 5, 2017 at 12:40 PM, Doug Beattie <doug.beat...@globalsign.com 
<mailto:doug.beat...@globalsign.com> > wrote:

Yes, I agree that it seems IETF has left portions of the spec under defined, 
for example how to look up and validate CAA records given all of the types of 
errors that could be encountered.  Do we expect the IETF WG to focus more 
heavily on those, or should this be done in CABForum?

 

I think error handling would be a great topic to bring up at the IETF LAMPS WG. 
In particular the question of how to distinguish DNSSEC-based SERVFAIL vs other 
types of SERVFAIL is a very tricky technical one, and would benefit from the 
expertise present at IETF.

___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] CAA working group description

[Jacob Hoffman-Andrews via Public]

> I know there’s a CAA document going through ACME. Is this also going
LAMPS?  The ACME WG is already working on account UIR and validation-methods
parameters. Given that this represents two of the four parameters suggested
during the F2F, should we add the other two there?

There are two CAA documents currently being discussed at IETF:

Hugo Landau's draft to add a validation-method parameter to
CAA: https://datatracker.ietf.org/doc/draft-ietf-acme-caa/. Currently in
last call. This was started in the ACME WG because LAMPS was not chartered
to discuss CAA at the time. LAMPS is now in the process of being
rechartered to discuss CAA, so we can additionally discuss over there.

My CAA Simplification draft, currently an individual draft, but hopefully
soon to be a WG
draft: 
https://datatracker.ietf.org/doc/draft-hoffman-andrews-caa-simplification/.
This is being discussed at the LAMPS WG.

I'd encourage folks to join both ACME and LAMPS, but if you only have time
for one, join LAMPS. https://datatracker.ietf.org/wg/lamps/charter/.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] CAA working group description

[Jeremy Rowley via Public]

I know there’s a CAA document going through ACME. Is this also going LAMPS?  
The ACME WG is already working on account UIR and validation-methods 
parameters. Given that this represents two of the four parameters suggested 
during the F2F, should we add the other two there? 

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Jacob 
Hoffman-Andrews via Public
Sent: Thursday, October 5, 2017 12:52 PM
To: Phillip <phill...@comodo.com>
Cc: CA/Browser Forum Public Discussion List <public@cabforum.org>
Subject: Re: [cabfpub] CAA working group description

 

On Thu, Oct 5, 2017 at 11:09 AM, Phillip <phill...@comodo.com 
<mailto:phill...@comodo.com> > wrote:

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.

 

I agree that this would be a bad outcome, and it's part of why we need to 
encourage interested CA/Browser Forum members to participate directly in IETF, 
so they can be heard as part of the consensus.



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] CAA working group description

[Doug Beattie via Public]

Yes, I agree that it seems IETF has left portions of the spec under defined, 
for example how to look up and validate CAA records given all of the types of 
errors that could be encountered.  Do we expect the IETF WG to focus more 
heavily on those, or should this be done in CABForum?  I think a CABForum WG to 
discuss and recommend changes to IETF might be the most expedient and effective 
approach near term.  If we find out that IETF is addressing this and we have 
conflicting work products, then we can disband the WG and participate in IETF.

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Phillip via 
Public
Sent: Thursday, October 5, 2017 2:09 PM
To: 'Ryan Sleevi' <sle...@google.com>; 'CA/Browser Forum Public Discussion 
List' <public@cabforum.org>; 'Jacob Hoffman-Andrews' <j...@letsencrypt.org>
Subject: Re: [cabfpub] CAA working group description

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-boun...@cabforum.org] On Behalf Of Ryan Sleevi via 
Public
Sent: Thursday, October 5, 2017 1:52 PM
To: Jacob Hoffman-Andrews <j...@letsencrypt.org>; CA/Browser Forum Public 
Discussion List <public@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@cabforum.org<mailto:public@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/. 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 (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@cabforum.org<mailto:Public@cabforum.org>
https://cabforum.org/mailman/listinfo/public

___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] CAA working group description

[Jacob Hoffman-Andrews via Public]

On Thu, Oct 5, 2017 at 11:09 AM, Phillip  wrote:

> 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.
>

I agree that this would be a bad outcome, and it's part of why we need to
encourage interested CA/Browser Forum members to participate directly in
IETF, so they can be heard as part of the consensus.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] CAA working group description

[Phillip via Public]

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-boun...@cabforum.org] On Behalf Of Ryan Sleevi via 
Public
Sent: Thursday, October 5, 2017 1:52 PM
To: Jacob Hoffman-Andrews <j...@letsencrypt.org>; CA/Browser Forum Public 
Discussion List <public@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@cabforum.org <mailto:public@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/. 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 (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@cabforum.org <mailto:Public@cabforum.org> 
https://cabforum.org/mailman/listinfo/public

 

___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] CAA working group description

[Ryan Sleevi via Public]

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@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/. 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 (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@cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] CAA working group description

[Jacob Hoffman-Andrews via Public]

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/. 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 (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@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] CAA working group description

[Phillip via Public]

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-boun...@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@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
> 
> 
> 

___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

[cabfpub] CAA working group description

[Geoff Keating via Public]

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




smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public