Re: [Acme] Consensus -- CAA draft to WGLC?

[Richard Barnes]

On Thu, Oct 19, 2017 at 2:21 PM, Hugo Landau  wrote:

> > > With regard to ACME-CAA PR#2: Is a "vendor" validation method, rather
> > > than a prefix, really that useful?
> > >
> >
> > It seems like something we're likely to need at some point, given that
> > there's still some diversity in validation methods.  But if you're
> > uncomfortable, I think we can drop it from the CAA PR and handle it later
> > if it's needed.
> Sounds good to me.
>
> > > RFC6648 deprecates prefixes like "x-", but thinks that vendor-specific
> > > prefixes like domain names are still OK. So we could amend the ACME
> > > specification allowing challenge method names of the form
> > > "f...@example.com", say (this is inspired by SSH capability names).
> This
> > > would have utility for vendors both in and outside of the context of
> > > ACME-CAA.
> > >
> >
> > I think you still run into the "x-" problem here.  What happens when "
> > f...@example.com" gets popular enough that "example.com" and "example.net
> "
> > also start using it?
> Then example.com is immortalised in history as a pioneer of that de
> facto standard - there's no issue here, is there? SSH uses
> f...@example.com-type identifiers for extensions, but there's no
> implication that only example.com will implement those extensions, on
> the contrary. Nor is the XML namespace "http://www.w3.org/1999/xhtml; is
> intended to only be used by the W3C.
>
> It would be very helpful if you could base comments on the current I-D:
>   https://tools.ietf.org/html/draft-ietf-acme-caa-03
> i.e., what diffs would you propose against this I-D?
>

Oh, sorry, I hadn't realized you had updated the draft in the meantime.  I
think for purposes of this discussion, what's in the draft now is fine.
I'll close my PR.

--Richard
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Consensus -- CAA draft to WGLC?

[Hugo Landau]

> > With regard to ACME-CAA PR#2: Is a "vendor" validation method, rather
> > than a prefix, really that useful?
> >
> 
> It seems like something we're likely to need at some point, given that
> there's still some diversity in validation methods.  But if you're
> uncomfortable, I think we can drop it from the CAA PR and handle it later
> if it's needed.
Sounds good to me.

> > RFC6648 deprecates prefixes like "x-", but thinks that vendor-specific
> > prefixes like domain names are still OK. So we could amend the ACME
> > specification allowing challenge method names of the form
> > "f...@example.com", say (this is inspired by SSH capability names). This
> > would have utility for vendors both in and outside of the context of
> > ACME-CAA.
> >
> 
> I think you still run into the "x-" problem here.  What happens when "
> f...@example.com" gets popular enough that "example.com" and "example.net"
> also start using it?
Then example.com is immortalised in history as a pioneer of that de
facto standard - there's no issue here, is there? SSH uses
f...@example.com-type identifiers for extensions, but there's no
implication that only example.com will implement those extensions, on
the contrary. Nor is the XML namespace "http://www.w3.org/1999/xhtml; is
intended to only be used by the W3C.

It would be very helpful if you could base comments on the current I-D:
  https://tools.ietf.org/html/draft-ietf-acme-caa-03
i.e., what diffs would you propose against this I-D?

Yours,
Hugo Landau

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Consensus -- CAA draft to WGLC?

[Richard Barnes]

Picking this up after a long gap...

On Sat, Jul 8, 2017 at 4:44 AM, Hugo Landau  wrote:

> > > https://github.com/ietf-wg-acme/acme/pull/332
> Alright, if the ACME spec wants to genericise its validation methods
> registry, I'm okay with the validation-methods change as-is.
>
> Questions:
>
> 1. Should we drop "non-acme", since any non-ACME method can have its own
>identifier listed? I think probably.
>

Yes, I agree.



> 2. An ACME validation method, such as http-01, can only be used in the
>context of using ACME. Conversely, should non-ACME validation methods
>only be usable in non-ACME contexts?
>

I mean, in principle, you could use the ACME methods with something else,
as long as you defined what public key / nonce to use.  But it would be
non-trivial.



>
>For example, suppose someone registered a "cabf-dv-http" validation
>method generically referring to CABF-compliant HTTP-based DV.
>If someone wants to use ACME, they can list http-01 specifically,
>so I think ACME CAs should ignore method specifiers like this.
>These method names would be applicable solely to non-ACME CAs.
>
>(This is sort of implied already by the subtext that an act of
>validation has exactly one validation method name applicable to it,
>but we could be clearer about this.)
>

This raises a good point with regard to the ACME PR.  These labels should
identify *specific* validation mechanisms, so that there's no overlap.  So
you wouldn't want a general label for any CABF-compliant validation
technique; you would want them for specific, interoperably-specified
techniques.  I've added some notes to the ACME PR to try to clarify this.



> With regard to ACME-CAA PR#2: Is a "vendor" validation method, rather
> than a prefix, really that useful?
>

It seems like something we're likely to need at some point, given that
there's still some diversity in validation methods.  But if you're
uncomfortable, I think we can drop it from the CAA PR and handle it later
if it's needed.



> RFC6648 deprecates prefixes like "x-", but thinks that vendor-specific
> prefixes like domain names are still OK. So we could amend the ACME
> specification allowing challenge method names of the form
> "f...@example.com", say (this is inspired by SSH capability names). This
> would have utility for vendors both in and outside of the context of
> ACME-CAA.
>

I think you still run into the "x-" problem here.  What happens when "
f...@example.com" gets popular enough that "example.com" and "example.net"
also start using it?

--Richard




>
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Consensus -- CAA draft to WGLC?

[Phillip Hallam-Baker]

On Thu, Jul 6, 2017 at 6:16 AM, Martin Thomson 
wrote:

> On 6 July 2017 at 20:07, Hugo Landau  wrote:
> > Vendor-assigned identifiers could be supported as such:
> >   vnd:example.com/custom-method
>
> RFC 6648 explains why vendor-prefixes can be a bad idea.  I think that
> you should do as Yaron suggested and establish a registry.  Set the
> bar low (specification required would be my choice) and then CABF can
> make a new entry as they see fit.  In particular, do away with
> attaching some sort of semantic to prefixes.
>
> > 2. Adding a reference to CABF is weird
>

​CAA already has a tag registry. The bar to entry is deliberately low. If
you really can't use the existing registry, use the existing one as a
template.

But the thing with DNS records is that you have a left hand side (domain
name, record type) and a right hand side (record data) and the DNS protocol
only allows you to select on the left hand side.

If you do a CAA query, you are always going to get back the full set of
records. ​So you are always going to have to look at them all.

CAA tags are text labels with a deliberately generous number of
possibilities. We are not going to run out. Rather than create a
subordinate registry, I would prefix within the label.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Consensus -- CAA draft to WGLC?

[Hugo Landau]

> > https://github.com/ietf-wg-acme/acme/pull/332
Alright, if the ACME spec wants to genericise its validation methods
registry, I'm okay with the validation-methods change as-is.

Questions:

1. Should we drop "non-acme", since any non-ACME method can have its own
   identifier listed? I think probably.

2. An ACME validation method, such as http-01, can only be used in the
   context of using ACME. Conversely, should non-ACME validation methods
   only be usable in non-ACME contexts?

   For example, suppose someone registered a "cabf-dv-http" validation
   method generically referring to CABF-compliant HTTP-based DV.
   If someone wants to use ACME, they can list http-01 specifically,
   so I think ACME CAs should ignore method specifiers like this.
   These method names would be applicable solely to non-ACME CAs.

   (This is sort of implied already by the subtext that an act of
   validation has exactly one validation method name applicable to it,
   but we could be clearer about this.)


With regard to ACME-CAA PR#2: Is a "vendor" validation method, rather
than a prefix, really that useful?

RFC6648 deprecates prefixes like "x-", but thinks that vendor-specific
prefixes like domain names are still OK. So we could amend the ACME
specification allowing challenge method names of the form
"f...@example.com", say (this is inspired by SSH capability names). This
would have utility for vendors both in and outside of the context of
ACME-CAA.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Consensus -- CAA draft to WGLC?

[Salz, Rich]

> https://github.com/ietf-wg-acme/acme/pull/332

I like this.  I proposed one minor wording clarification.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Consensus -- CAA draft to WGLC?

[Richard Barnes]

On Fri, Jul 7, 2017 at 9:33 AM, Hugo Landau  wrote:

> >On Thu, Jul 6, 2017 at 11:57 AM, Salz, Rich <[1]rs...@akamai.com>
> wrote:
> >
> >  So let's see.  Can we live with this?
> >
> >  Create a spec-required registry for validation method names.
> >
> >I share Hugo's concern about divergence here.  Should we maybe just
> put
> >these in the ACME challenge types registry?  It is already
> Spec-Required.
> >That would mean that not all of those values would be usable with
> ACME,
> >but that doesn't seems very likely to lead to interop problems, since
> a
> >sensible ACME server wouldn't offer the non-ACME ones.  Or you could
> just
> >add a column to indicate ACME / non-ACME.
> >In any case, if we go down this path, I would suggest we change
> "non-acme"
> >to "vendor", in order to signify "something that is not in the
> registry".
> In this case we may as well keep it called "acme-methods" and leave the
> extension of that namespace (ACME challenge method names) to non-ACME
> things to the future.
>

The future is now!  :)

https://github.com/ietf-wg-acme/acme/pull/332

Even if we don't make the ACME change, if we think that some day there
might be non-ACME identifiers in this CAA field, then I would propose that
we use "validation-methods" instead of "acme-methods", for future-proofing.

--Richard
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Consensus -- CAA draft to WGLC?

[Hugo Landau]

>On Thu, Jul 6, 2017 at 11:57 AM, Salz, Rich <[1]rs...@akamai.com> wrote:
> 
>  So let's see.  Can we live with this?
> 
>  Create a spec-required registry for validation method names.
> 
>I share Hugo's concern about divergence here.  Should we maybe just put
>these in the ACME challenge types registry?  It is already Spec-Required. 
>That would mean that not all of those values would be usable with ACME,
>but that doesn't seems very likely to lead to interop problems, since a
>sensible ACME server wouldn't offer the non-ACME ones.  Or you could just
>add a column to indicate ACME / non-ACME.
>In any case, if we go down this path, I would suggest we change "non-acme"
>to "vendor", in order to signify "something that is not in the registry".
In this case we may as well keep it called "acme-methods" and leave the
extension of that namespace (ACME challenge method names) to non-ACME
things to the future.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Consensus -- CAA draft to WGLC?

[Richard Barnes]

On Thu, Jul 6, 2017 at 11:57 AM, Salz, Rich  wrote:

> So let's see.  Can we live with this?
>
> Create a spec-required registry for validation method names.
>

I share Hugo's concern about divergence here.  Should we maybe just put
these in the ACME challenge types registry?  It is already Spec-Required.
That would mean that not all of those values would be usable with ACME, but
that doesn't seems very likely to lead to interop problems, since a
sensible ACME server wouldn't offer the non-ACME ones.  Or you could just
add a column to indicate ACME / non-ACME.

In any case, if we go down this path, I would suggest we change "non-acme"
to "vendor", in order to signify "something that is not in the registry".



> Do not reference CABF docs.
>

I don't understand the concern here.  IETF document reference non-IETF docs
all the time.  This seems like useful context.



> Change the CA sample names from A B to X Y or foo bar or this that or
> whatever.
>

This is already in my PR.  I updated the PR with the "vendor" stuff above:

https://github.com/ietf-wg-acme/acme-caa/pull/2/commits/e40c9cb7cfdf34b6fd2b4e0017ae626105287f58

--Richard
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Consensus -- CAA draft to WGLC?

[Salz, Rich]

So let's see.  Can we live with this?

Create a spec-required registry for validation method names.

Do not reference CABF docs.

Change the CA sample names from A B to X Y or foo bar or this that or whatever.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Consensus -- CAA draft to WGLC?

[Martin Thomson]

On 6 July 2017 at 20:07, Hugo Landau  wrote:
> Vendor-assigned identifiers could be supported as such:
>   vnd:example.com/custom-method

RFC 6648 explains why vendor-prefixes can be a bad idea.  I think that
you should do as Yaron suggested and establish a registry.  Set the
bar low (specification required would be my choice) and then CABF can
make a new entry as they see fit.  In particular, do away with
attaching some sort of semantic to prefixes.

> 2. Adding a reference to CABF is weird

This I agree with.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Consensus -- CAA draft to WGLC?

[Yaron Sheffer]

The problem with saying "Tokens registered as ACME challenge types MUST 
NOT be used to identify non-ACME validation methods" is that ACME might 
want to come up with additional method names in the future, and those 
just might happen to conflict with methods that have been used by other 
organizations in the meantime. This is exactly the kind of mess that 
IANA is designed to prevent.


A simple way to go around this issue is if we changed the draft to use 
"acme-dns-01" instead of "dns-01" and similarly for all ACME methods. 
Then we COULD say that non-ACME CAs MUST not use "acme-*" methods.


To your second point, many enterprise users will want the extra security 
of "use this specific CA AND only with this method". There are probably 
other use cases though.


Thanks,

Yaron


On 06/07/17 00:17, Richard Barnes wrote:
Just for context here: I think the original operating model for CAA 
was that the CA would tell the customer what values to put in there in 
order to authorize issuance.  So it was safe to use arbitrary values 
because it was basically a closed loop CA -> Customer -> CAA -> CA.


Nonetheless, I sympathize with your point here.  With ACME, we're 
moving things in a more standardized / automated direction, so we can 
automate out some of the CA interaction around CAA if we standardize 
some values.


Note that the ACME challenge type values are already registered.  
Would it be sufficient to say something like "Tokens registered as 
ACME challenge types MUST NOT be used to identify non-ACME validation 
methods"?


---

This reminds me a related point that I forgot in my initial review.  
It would be nice if it were possible to specify a validation method 
policy independent of CA.  So I wouldn't have to authorize each CA I 
interact with individually, but I would be able to say "Only validate 
my domains using dns-01".


In fact, is there any reason to have different validation methods per 
CA?  It's a property of the domain owner / certificate applicant, not 
the CA. Is there a reason you would trust CA X to do "http-01" but not 
CA Y?  (I totally understand why "account-uri" is CA-specific, though.)


I would suggest pulling out "validation-methods" from being an 
attribute to being a "tag" / "property", parallel to "issue" and 
"issuewild".




On Wed, Jul 5, 2017 at 3:45 PM, Yaron Sheffer > wrote:


I support moving forward with the document.

However I think the treatment of the acme-methods (or
validation-methods) param is inconsistent, before and certainly
after Richard's PR. The original draft only allows ACME methods
and the special name "non-acme". This leaves the responsibility to
ensure names are well defined with the IETF.

If we allow mixing ACME methods with CA-defined methods per
Richard's proposal, we should make sure that there is no overlap.
And even if names are defined by individual CAs, the CA should
provide a precise definition of each validation method. IMO there
are two good options:

- Define an IANA registry for the validation-methods values. (This
is simple enough, and would be my preference).
- Define an IANA registry for prefixes (such as "cabf" mentioned
in Richard's text) and specify that everything else must be
defined by ACME.

Thanks,
Yaron



https://github.com/ietf-wg-acme/acme-caa/pull/2


On Wed, Jul 5, 2017 at 11:47 AM, Salz, Rich > wrote:

There's no listing going on here, since there's no
registry for the

values.  CABF could put tokens in their documents if they
like.

Okay, please propose wording (or did you?  Sorry if so) to
change for the
CAA draft.




___
Acme mailing list
Acme@ietf.org 
https://www.ietf.org/mailman/listinfo/acme





___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Consensus -- CAA draft to WGLC?

[Richard Barnes]

Just for context here: I think the original operating model for CAA was
that the CA would tell the customer what values to put in there in order to
authorize issuance.  So it was safe to use arbitrary values because it was
basically a closed loop CA -> Customer -> CAA -> CA.

Nonetheless, I sympathize with your point here.  With ACME, we're moving
things in a more standardized / automated direction, so we can automate out
some of the CA interaction around CAA if we standardize some values.

Note that the ACME challenge type values are already registered.  Would it
be sufficient to say something like "Tokens registered as ACME challenge
types MUST NOT be used to identify non-ACME validation methods"?

---

This reminds me a related point that I forgot in my initial review.  It
would be nice if it were possible to specify a validation method policy
independent of CA.  So I wouldn't have to authorize each CA I interact with
individually, but I would be able to say "Only validate my domains using
dns-01".

In fact, is there any reason to have different validation methods per CA?
It's a property of the domain owner / certificate applicant, not the CA. Is
there a reason you would trust CA X to do "http-01" but not CA Y?  (I
totally understand why "account-uri" is CA-specific, though.)

I would suggest pulling out "validation-methods" from being an attribute to
being a "tag" / "property", parallel to "issue" and "issuewild".



On Wed, Jul 5, 2017 at 3:45 PM, Yaron Sheffer  wrote:

> I support moving forward with the document.
>
> However I think the treatment of the acme-methods (or validation-methods)
> param is inconsistent, before and certainly after Richard's PR. The
> original draft only allows ACME methods and the special name "non-acme".
> This leaves the responsibility to ensure names are well defined with the
> IETF.
>
> If we allow mixing ACME methods with CA-defined methods per Richard's
> proposal, we should make sure that there is no overlap. And even if names
> are defined by individual CAs, the CA should provide a precise definition
> of each validation method. IMO there are two good options:
>
> - Define an IANA registry for the validation-methods values. (This is
> simple enough, and would be my preference).
> - Define an IANA registry for prefixes (such as "cabf" mentioned in
> Richard's text) and specify that everything else must be defined by ACME.
>
> Thanks,
> Yaron
>
>
>
> https://github.com/ietf-wg-acme/acme-caa/pull/2
>>
>> On Wed, Jul 5, 2017 at 11:47 AM, Salz, Rich  wrote:
>>
>> There's no listing going on here, since there's no registry for the

>>> values.  CABF could put tokens in their documents if they like.
>>>
>>> Okay, please propose wording (or did you?  Sorry if so) to change for the
>>> CAA draft.
>>>
>>>
>>>
>>
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Consensus -- CAA draft to WGLC?

[Yaron Sheffer]

I support moving forward with the document.

However I think the treatment of the acme-methods (or 
validation-methods) param is inconsistent, before and certainly after 
Richard's PR. The original draft only allows ACME methods and the 
special name "non-acme". This leaves the responsibility to ensure names 
are well defined with the IETF.


If we allow mixing ACME methods with CA-defined methods per Richard's 
proposal, we should make sure that there is no overlap. And even if 
names are defined by individual CAs, the CA should provide a precise 
definition of each validation method. IMO there are two good options:


- Define an IANA registry for the validation-methods values. (This is 
simple enough, and would be my preference).
- Define an IANA registry for prefixes (such as "cabf" mentioned in 
Richard's text) and specify that everything else must be defined by ACME.


Thanks,
Yaron



https://github.com/ietf-wg-acme/acme-caa/pull/2

On Wed, Jul 5, 2017 at 11:47 AM, Salz, Rich  wrote:


There's no listing going on here, since there's no registry for the

values.  CABF could put tokens in their documents if they like.

Okay, please propose wording (or did you?  Sorry if so) to change for the
CAA draft.






___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Consensus -- CAA draft to WGLC?

[Richard Barnes]

https://github.com/ietf-wg-acme/acme-caa/pull/2

On Wed, Jul 5, 2017 at 11:47 AM, Salz, Rich  wrote:

> > There's no listing going on here, since there's no registry for the
> values.  CABF could put tokens in their documents if they like.
>
> Okay, please propose wording (or did you?  Sorry if so) to change for the
> CAA draft.
>
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Consensus -- CAA draft to WGLC?

[Salz, Rich]

> There's no listing going on here, since there's no registry for the values.  
> CABF could put tokens in their documents if they like.

Okay, please propose wording (or did you?  Sorry if so) to change for the CAA 
draft.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Consensus -- CAA draft to WGLC?

[Richard Barnes]

There's no listing going on here, since there's no registry for the
values.  CABF could put tokens in their documents if they like.

On Tue, Jun 13, 2017 at 1:33 PM, Salz, Rich  wrote:

> > The two last ones are editorial, but the first about enumerating all BR
> > methods isn't (since it needs new validation method identifiers).
>
> Thinking about it a bit more, I don't think it is appropriate for ACME to
> list CABF things.  That's a strong view as an individual, and a moderate
> view as a WG chair.
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Consensus -- CAA draft to WGLC?

[Russ Housley]

I do not see how the comments from Richard Barnes were handled.

Russ


> On Jun 30, 2017, at 10:30 AM, Salz, Rich  wrote:
> 
> Based on feedback here, Hugo just posted an updated draft, 
> https://tools.ietf.org/html/draft-ietf-acme-caa-02
> 
> I would like to advance this to the IESG in a week.  Please speak up if you 
> disagree.
> 
> Also, still looking for a  document shepherd (see 
> https://www.ietf.org/iesg/template/doc-writeup.html; an essay style writeup 
> is fine).
> 
> --  
> Senior Architect, Akamai Technologies
> Member, OpenSSL Dev Team
> IM: richs...@jabber.at Twitter: RichSalz

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Consensus -- CAA draft to WGLC?

[Salz, Rich]

Based on feedback here, Hugo just posted an updated draft, 
https://tools.ietf.org/html/draft-ietf-acme-caa-02

I would like to advance this to the IESG in a week.  Please speak up if you 
disagree.

 Also, still looking for a  document shepherd (see 
https://www.ietf.org/iesg/template/doc-writeup.html; an essay style writeup is 
fine).

--  
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richs...@jabber.at Twitter: RichSalz

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Consensus -- CAA draft to WGLC?

[Ilari Liusvaara]

On Tue, Jun 13, 2017 at 05:33:48PM +, Salz, Rich wrote:
> > The two last ones are editorial, but the first about enumerating all BR
> > methods isn't (since it needs new validation method identifiers).
> 
> Thinking about it a bit more, I don't think it is appropriate for
> ACME to list CABF things.  That's a strong view as an individual,
> and a moderate view as a WG chair.

Yeah, the major problem includes keeping the list up to date if a new
method comes about. Or if some method is modified in major way.


-Ilari

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Consensus -- CAA draft to WGLC?

[Salz, Rich]

> The two last ones are editorial, but the first about enumerating all BR
> methods isn't (since it needs new validation method identifiers).

Thinking about it a bit more, I don't think it is appropriate for ACME to list 
CABF things.  That's a strong view as an individual, and a moderate view as a 
WG chair.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Consensus -- CAA draft to WGLC?

[Salz, Rich]

> Couple of minor comments:

These seem like all strictly editorial to me.  Anyone disagree?

--  
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richs...@jabber.at Twitter: RichSalz
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] Consensus -- CAA draft to WGLC?

[Salz, Rich]

>>Hugo's CAA draft (already adopted, short, might be

>> ready for WGLC) -- https://tools.ietf.org/html/draft-ietf-acme-caa-01

This has moved to WGLC.  If you know of any reason why it should not advance to 
the IESG, please post by end of next week.

If you are willing to be the document shepherd for this document (see 
https://www.ietf.org/iesg/template/doc-writeup.html; an essay style writeup is 
fine), please let the chairs know soon.

--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richs...@jabber.at Twitter: RichSalz

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme