Re: [Acme] Do we need/want mandatory-to-implement signature algorithms?

[Stephen Farrell]

Hi Russ,

On 30/05/18 22:31, Russ Housley wrote:
> It seems to me that ACME is being used to support certificate
> enrollment for many different applications, so the same approach
> seems appropriate.
I agree with your description of the past:-)

I don't agree with not specifying MTI algs though.

My main reasons are that I think having MTI algorithms for
acme may lead to better interop and less proliferation of
algorithms/suites and less broken/non-tested code. (I
forget what I thought about this years ago, but I may have
changed opinion - it was reasonable for PKIX to not specify
MTI algs a decade or two ago, but that that is no longer a
good plan, as we now do really use all this stuff.)

That said, I don't feel too strongly about it - in practice
I reckon all acme clients will in any case want to implement
and be able to use whatever works with LE, at least for the
next while, and so this won't be a practical problem either
way.

Cheers,
S.



0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Do we need/want mandatory-to-implement signature algorithms?

[Russ Housley]

> On May 30, 2018, at 3:54 PM, Salz, Rich  
> wrote:
> 
> Yes, please ask. If I'm going to tell the IESG that no MTI is needed, I want 
> to tell them that the WG had consensus.
>  
> This came up in the “AD review” thread that many of you have probably just 
> seen and skimmed or ignored. :)
>  
> ACME does not define any mandatory-to-implement signature algorithms.  To the 
> best of my recollection, this has never come up, and Eric reasonably asks 
> that we not just say “silence gives consensus.”
>  
> SO, if anyone feels we should define a set of MTI signature algorithms for 
> ACME, please speak up now. If you do so, consider proposing what they should 
> be.  Please reply within a week.

I already spoke on the previous thread.  I will repeat it here...

PKIX chose not to specify mandatory-to-implement algorithms.  This was done 
because the application that made use of the certificate needed to be able to 
impose such requirements.

Here is one place from the PKIX WG archive in 2011 that states this approach:

   (https://mailarchive.ietf.org/arch/msg/pkix/blSByMc7SysNNvkFlsFdcrFLrIs 
)

   PKIX defines PKI specs for a very wide range of apps, which is why we
   do not mandate any alg suite.  Different apps may use different alg suites.
   TLS, S/MIME, IPsec, SeND, etc. each gets to choose MTE algs for itself.

It seems to me that ACME is being used to support certificate enrollment for 
many different applications, so the same approach seems appropriate.

Russ

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

Re: [Acme] I-D Action: draft-ietf-acme-tls-alpn-01.txt

[Roland Bracewell Shoemaker]

Various editorial changes and cleanups, mainly looking to clarify the Security 
Considerations/Design Rationale sections. The one technical change here is 
removing references to keyAuthorization in the challenge update step as this no 
longer happens in the ACME draft.

> On May 30, 2018, at 2:07 PM, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Automated Certificate Management Environment 
> WG of the IETF.
> 
>Title   : ACME TLS ALPN Challenge Extension
>Author  : Roland Bracewell Shoemaker
>   Filename: draft-ietf-acme-tls-alpn-01.txt
>   Pages   : 8
>   Date: 2018-05-30
> 
> Abstract:
>   This document specifies a new challenge for the Automated Certificate
>   Management Environment (ACME) protocol which allows for domain
>   control validation using TLS.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-acme-tls-alpn/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-acme-tls-alpn-01
> https://datatracker.ietf.org/doc/html/draft-ietf-acme-tls-alpn-01
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-tls-alpn-01
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> 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

[Acme] I-D Action: draft-ietf-acme-tls-alpn-01.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Automated Certificate Management Environment 
WG of the IETF.

Title   : ACME TLS ALPN Challenge Extension
Author  : Roland Bracewell Shoemaker
Filename: draft-ietf-acme-tls-alpn-01.txt
Pages   : 8
Date: 2018-05-30

Abstract:
   This document specifies a new challenge for the Automated Certificate
   Management Environment (ACME) protocol which allows for domain
   control validation using TLS.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-acme-tls-alpn/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-acme-tls-alpn-01
https://datatracker.ietf.org/doc/html/draft-ietf-acme-tls-alpn-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-tls-alpn-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

Re: [Acme] AD Review: draft-ietf-acme-acme-12

[Daniel McCarney]

>
> We have multiple CA’s that support it, and other implementations as well.


Of the multiple CAs that support ACME, which support something resembling
the current draft? When I looked last the non-Let's Encrypt ACME server
implementations all seemed to be targeting Certbot and the "ACMEv1" era of
this draft (e.g. are not using the order based issuance flow at all). There
have been substantial backwards compatibility breaking changes in the draft
since this time.

I second EKR's sentiment that there has been little true ACME inter-op
testing of the protocol as described in draft-12 outside of that done with
Let's Encrypts ACMEv2 endpoint.

- Daniel / cpu

On Wed, May 30, 2018 at 3:56 PM, Salz, Rich <
rsalz=40akamai@dmarc.ietf.org> wrote:

>
>- Well, we have a fair bit of experience of a lot of people talking to
>Let's Encrypt. That's not really the same as a lot of servers and a lot of
>clients.
>
>
>
> We have multiple CA’s that support it, and other implementations as well.
> Certainly LE dominates, but it’s not the only usage.  And certainly not the
> only anticipated future usage.
>
>
>
>- I would match the TLS ones: MUST ECDSA with P-256, SHOULD EdDSA with
>X25519.
>
>
>
> That would make the MTI limited to a subset of the WebPKI supported by the
> latest browsers, which seems wrong.  But let’s not bikeshed too much and
> see what the WG consensus is.
>
>
>
> ___
> 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] AD Review: draft-ietf-acme-acme-12

[Salz, Rich]

  *   The reason I chose those values is because you're already tied to TLS for 
the communications and therefore you necessarily have the TLS MTI cipher 
suites, which means you already have those algorithms.

If your toolkit exposes it.  If your toolkit is a black box or scripted such as 
CURL, you might as well have the message signatures be what your ultimate 
certificates are gonna be.  That was the point I was trying to make.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] AD Review: draft-ietf-acme-acme-12

[Eric Rescorla]

On Wed, May 30, 2018 at 12:56 PM, Salz, Rich  wrote:

>
>- Well, we have a fair bit of experience of a lot of people talking to
>Let's Encrypt. That's not really the same as a lot of servers and a lot of
>clients.
>
>
>
> We have multiple CA’s that support it, and other implementations as well.
> Certainly LE dominates, but it’s not the only usage.  And certainly not the
> only anticipated future usage.
>

Right. And the purpose of the MTI is usually to make future interop work
better.

>
>
>- I would match the TLS ones: MUST ECDSA with P-256, SHOULD EdDSA with
>X25519.
>
>
>
> That would make the MTI limited to a subset of the WebPKI supported by the
> latest browsers, which seems wrong.  But let’s not bikeshed too much and
> see what the WG consensus is.
>

I'm not following your point here. Remember, I'm not talking about the MTI
for what the *certs* contain, but rather for what the protocol uses for its
in-protocol signatures. There's no reason you can't use an ECDSA key to
authorize issuance of an RSA cert (Which would presumably be in a
self-signed PKCS#10 blob with RSA), or for that matter, an XMSS cert.

The reason I chose those values is because you're already tied to TLS for
the communications and therefore you necessarily have the TLS MTI cipher
suites, which means you already have those algorithms.

-Ekr


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

Re: [Acme] AD Review: draft-ietf-acme-acme-12

[Salz, Rich]

  *   Well, we have a fair bit of experience of a lot of people talking to 
Let's Encrypt. That's not really the same as a lot of servers and a lot of 
clients.

We have multiple CA’s that support it, and other implementations as well.  
Certainly LE dominates, but it’s not the only usage.  And certainly not the 
only anticipated future usage.


  *   I would match the TLS ones: MUST ECDSA with P-256, SHOULD EdDSA with 
X25519.

That would make the MTI limited to a subset of the WebPKI supported by the 
latest browsers, which seems wrong.  But let’s not bikeshed too much and see 
what the WG consensus is.

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

[Acme] Do we need/want mandatory-to-implement signature algorithms?

[Salz, Rich]

  *   Yes, please ask. If I'm going to tell the IESG that no MTI is needed, I 
want to tell them that the WG had consensus.

This came up in the “AD review” thread that many of you have probably just seen 
and skimmed or ignored. :)

ACME does not define any mandatory-to-implement signature algorithms.  To the 
best of my recollection, this has never come up, and Eric reasonably asks that 
we not just say “silence gives consensus.”

SO, if anyone feels we should define a set of MTI signature algorithms for 
ACME, please speak up now. If you do so, consider proposing what they should 
be.  Please reply within a week.

Thanks.
/r$, co-chair

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

Re: [Acme] AD Review: draft-ietf-acme-acme-12

[Eric Rescorla]

On Wed, May 30, 2018 at 11:45 AM, Salz, Rich  wrote:

> I believe the working group has decided that MTI algorithms are not
> necessary.  If you want that confirmed on the list, we can ask.
>

Yes, please ask. If I'm going to tell the IESG that no MTI is needed, I
want to tell them that the WG had consensus.


  ACME isn’t just WebPKI, as you know, it’s also becoming STIR and some
> have proposed home environments.
>
>
>
> We have many implementations to serve as proof points that MTI isn’t
> required in the Real World.
>

As I said to Richard, it seems like much of the interop is between clients
and LE. It's not hard to get interop when one side is fixed.

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

Re: [Acme] AD Review: draft-ietf-acme-acme-12

[Eric Rescorla]

On Wed, May 30, 2018 at 11:25 AM, Richard Barnes  wrote:

>
>
> On Tue, May 29, 2018 at 4:02 PM Eric Rescorla  wrote:
>
>>
>>
>> On Mon, May 28, 2018 at 9:57 PM, Russ Housley 
>> wrote:
>>
>>> Eric:
>>>
>>>
>>> > > Do you want to specify a set of acceptable signature algorithms here?
> >
> > I am inclined not to.  We have already forbidden "none" and MAC.  We
> > shouldn't specify "MUST"s here, because CABF sets their own list of
> > required algorithms, and we don't want to conflict.  I guess you
> > could specify some MUST NOTs pretty safely, but given that they're
> > already forbidden by CABF, it seems kind of duplicative.
>
> This is about the signatures that ACME accepts, not the signatures
> in certs. Does CABF have a position on what signature algorithms
> that ACME uses?
>

 Good point.  As Ryan pointed out, this is not something on which there
 is currently CABF guidance.

 Nonetheless, I'm still disinclined to have MUSTs here for other
 reasons.  If they're positive "MUST support" requirements, then we would
 need to come back and revise this document in the event of an algorithm
 break (though admittedly, that would be pretty far down on the TODO list).
 And looking at the current list of JWS algorithms, I don't see any I would
 MUST NOT, except possibly the ones based on SHA-1

>>>
>>> Hmm... Common practice in security protocols is to specify MTI
>>> algorithms. Why is this different?
>>>
>>>
>>> PKIX chose not to specify mandatory-to-implement algorithms.  This was
>>> done because the application that made use of the certificate needed to be
>>> able to impose such requirements.
>>>
>>> Here is one place from the PKIX WG archive in 2011 that states this
>>> approach:
>>>
>>>(https://mailarchive.ietf.org/arch/msg/pkix/
>>> blSByMc7SysNNvkFlsFdcrFLrIs)
>>>
>>>PKIX defines PKI specs for a very wide range of apps, which is why we
>>>do not mandate any alg suite.  Different apps may use different alg
>>> suites.
>>>TLS, S/MIME, IPsec, SeND, etc. each gets to choose MTE algs for
>>> itself.
>>>
>>> It seems to me that ACME is being used to support certificate enrollment
>>> for many different applications, so the same approach seems appropriate.
>>>
>>
>> Hmm... This seems like it would be more persuasive if there weren't a
>> dependency on TLS and its MTI algorithms
>>
>> From my perspective, this is sort of on the bubble. Historically, I've
>> seen the IESG insist on MTI algorithms, but it's not consistent. I would
>> like to understand if this is something that has strong consensus in the
>> WG, in which case I'll support that (though other IESG members may feel
>> differently) or if it just happened, in which case I'd ask the WG to
>> reconsider.
>>
>
> I think it's more in the latter category in the former, but TBH, I think
> that kind of argues in favor of the status quo -- we have a fair bit of
> implementation / deployment experience, and this has not been an interop
> problem.
>

Well, we have a fair bit of experience of a lot of people talking to Let's
Encrypt. That's not really the same as a lot of servers and a lot of
clients.


In a similar vein, where we have had discussion of versioning (a similar
> issue) there's been consensus *not* to go the traditional route of having
> version numbers -- you just have to know what version of ACME the endpoint
> you're talking to speaks.  It doesn't seem totally crazy to me for the same
> to be true of the signing algorithms you use.
>
> I guess I don't really know what value you're solving for here
>

I'm not sure what's confusing. The IETF has traditionally required MTI
algorithms to ensure that there is a baseline that allows two
implementations to talk to each other. We spent an enormous amount of time
on this in RTCWEB, so it's not exactly ancient history.

..  Just to try to make this concrete, if you were going to propose some
> algorithms to be MTI / MTnotI, what would you list?
>

I would match the TLS ones: MUST ECDSA with P-256, SHOULD EdDSA with X25519.

-Ekr


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

Re: [Acme] Let's Encrypt ACME-CAA validation-methods support

[Jacob Hoffman-Andrews]

Apologies for the delay on publishing the latest draft. I'll work on 
getting that out today. Thanks for the reminder!


On 05/30/2018 12:17 PM, Corey Bonnell wrote:


Hello,

This development is exciting work in regard to allowing domain owners 
to limit which validation methods they want to allow to be used for 
their domains.


Unfortunately, the validation-methods extension is not compliant with 
RFC 6844 (the CAA RFC), as parameter tags cannot contain hyphens. 
 This was originally pointed out on this mailing list in January 
(https://www.ietf.org/mail-archive/web/acme/current/msg02506.html). I 
proposed a fix to this issue (as well as fixing an ambiguity in the 
ABNF grammar in regard to parameter delimiters) on the LAMPS WG 
mailing list a few months ago 
(https://www.ietf.org/mail-archive/web/spasm/current/msg01144.html), 
but this change has not yet been incorporated into a draft of RFC 
6844-bis.


Since RFC 6844 dictates that parameters have meaning specific to the 
issuer (from section 5.1: “The semantics of issuer-parameters are 
determined by the issuer alone”), I don’t believe that issuing 
certificates for domains whose CAA record sets contain non-conformant 
parameter syntax would constitute mis-issuance. However, it may 
present difficulties in regard to tooling/automation that expect all 
parameter tags to follow RFC 6844.


Thanks,

*Corey Bonnell*

Senior Software Engineer

*Trustwave***| SMART SECURITY ON DEMAND
www.trustwave.com 

*From: *Acme  on behalf of Daniel McCarney 


*Reply-To: *"c...@letsencrypt.org" 
*Date: *Wednesday, May 30, 2018 at 1:57 PM
*To: *Hugo Landau , IETF ACME 
*Subject: *[Acme] Let's Encrypt ACME-CAA validation-methods support

Hi folks,

I'm happy to share that Let's Encrypt has deployed support for Hugo 
Landau's ACME-CAA "validation-methods" CAA record extension in the 
staging environment[0]. Community feedback/review would be most 
appreciated.


You can find more information in the associated API announcement[1].

Thanks,


- Daniel / cpu

[0] - https://letsencrypt.org/docs/staging-environment/ 



[1] - 
https://community.letsencrypt.org/t/acme-caa-validation-methods-support/63125 





___
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] Let's Encrypt ACME-CAA validation-methods support

[Corey Bonnell]

Hello,
This development is exciting work in regard to allowing domain owners to limit 
which validation methods they want to allow to be used for their domains.

Unfortunately, the validation-methods extension is not compliant with RFC 6844 
(the CAA RFC), as parameter tags cannot contain hyphens.  This was originally 
pointed out on this mailing list in January 
(https://www.ietf.org/mail-archive/web/acme/current/msg02506.html). I proposed 
a fix to this issue (as well as fixing an ambiguity in the ABNF grammar in 
regard to parameter delimiters) on the LAMPS WG mailing list a few months ago 
(https://www.ietf.org/mail-archive/web/spasm/current/msg01144.html), but this 
change has not yet been incorporated into a draft of RFC 6844-bis.

Since RFC 6844 dictates that parameters have meaning specific to the issuer 
(from section 5.1: “The semantics of issuer-parameters are determined by the 
issuer alone”), I don’t believe that issuing certificates for domains whose CAA 
record sets contain non-conformant parameter syntax would constitute 
mis-issuance. However, it may present difficulties in regard to 
tooling/automation that expect all parameter tags to follow RFC 6844.

Thanks,

Corey Bonnell
Senior Software Engineer

Trustwave | SMART SECURITY ON DEMAND
www.trustwave.com

From: Acme  on behalf of Daniel McCarney 

Reply-To: "c...@letsencrypt.org" 
Date: Wednesday, May 30, 2018 at 1:57 PM
To: Hugo Landau , IETF ACME 
Subject: [Acme] Let's Encrypt ACME-CAA validation-methods support

Hi folks,

I'm happy to share that Let's Encrypt has deployed support for Hugo Landau's 
ACME-CAA "validation-methods" CAA record extension in the staging 
environment[0]. Community feedback/review would be most appreciated.

You can find more information in the associated API announcement[1].

Thanks,

- Daniel / cpu
[0] - 
https://letsencrypt.org/docs/staging-environment/
[1] - 
https://community.letsencrypt.org/t/acme-caa-validation-methods-support/63125
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] AD Review: draft-ietf-acme-acme-12

[Salz, Rich]

I believe the working group has decided that MTI algorithms are not necessary.  
If you want that confirmed on the list, we can ask.  ACME isn’t just WebPKI, as 
you know, it’s also becoming STIR and some have proposed home environments.

We have many implementations to serve as proof points that MTI isn’t required 
in the Real World.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] AD Review: draft-ietf-acme-acme-12

[Richard Barnes]

On Tue, May 29, 2018 at 4:02 PM Eric Rescorla  wrote:

>
>
> On Mon, May 28, 2018 at 9:57 PM, Russ Housley 
> wrote:
>
>> Eric:
>>
>>
>> > > Do you want to specify a set of acceptable signature algorithms here?
 >
 > I am inclined not to.  We have already forbidden "none" and MAC.  We
 > shouldn't specify "MUST"s here, because CABF sets their own list of
 > required algorithms, and we don't want to conflict.  I guess you
 > could specify some MUST NOTs pretty safely, but given that they're
 > already forbidden by CABF, it seems kind of duplicative.

 This is about the signatures that ACME accepts, not the signatures
 in certs. Does CABF have a position on what signature algorithms
 that ACME uses?

>>>
>>> Good point.  As Ryan pointed out, this is not something on which there
>>> is currently CABF guidance.
>>>
>>> Nonetheless, I'm still disinclined to have MUSTs here for other
>>> reasons.  If they're positive "MUST support" requirements, then we would
>>> need to come back and revise this document in the event of an algorithm
>>> break (though admittedly, that would be pretty far down on the TODO list).
>>> And looking at the current list of JWS algorithms, I don't see any I would
>>> MUST NOT, except possibly the ones based on SHA-1
>>>
>>
>> Hmm... Common practice in security protocols is to specify MTI
>> algorithms. Why is this different?
>>
>>
>> PKIX chose not to specify mandatory-to-implement algorithms.  This was
>> done because the application that made use of the certificate needed to be
>> able to impose such requirements.
>>
>> Here is one place from the PKIX WG archive in 2011 that states this
>> approach:
>>
>>(
>> https://mailarchive.ietf.org/arch/msg/pkix/blSByMc7SysNNvkFlsFdcrFLrIs)
>>
>>PKIX defines PKI specs for a very wide range of apps, which is why we
>>do not mandate any alg suite.  Different apps may use different alg
>> suites.
>>TLS, S/MIME, IPsec, SeND, etc. each gets to choose MTE algs for itself.
>>
>> It seems to me that ACME is being used to support certificate enrollment
>> for many different applications, so the same approach seems appropriate.
>>
>
> Hmm... This seems like it would be more persuasive if there weren't a
> dependency on TLS and its MTI algorithms
>
> From my perspective, this is sort of on the bubble. Historically, I've
> seen the IESG insist on MTI algorithms, but it's not consistent. I would
> like to understand if this is something that has strong consensus in the
> WG, in which case I'll support that (though other IESG members may feel
> differently) or if it just happened, in which case I'd ask the WG to
> reconsider.
>

I think it's more in the latter category in the former, but TBH, I think
that kind of argues in favor of the status quo -- we have a fair bit of
implementation / deployment experience, and this has not been an interop
problem.

In a similar vein, where we have had discussion of versioning (a similar
issue) there's been consensus *not* to go the traditional route of having
version numbers -- you just have to know what version of ACME the endpoint
you're talking to speaks.  It doesn't seem totally crazy to me for the same
to be true of the signing algorithms you use.

I guess I don't really know what value you're solving for here.  Just to
try to make this concrete, if you were going to propose some algorithms to
be MTI / MTnotI, what would you list?

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

[Acme] Let's Encrypt ACME-CAA validation-methods support

[Daniel McCarney]

Hi folks,

I'm happy to share that Let's Encrypt has deployed support for Hugo
Landau's ACME-CAA "validation-methods" CAA record extension in the staging
environment[0]. Community feedback/review would be most appreciated.

You can find more information in the associated API announcement[1].

Thanks,

- Daniel / cpu

[0] - https://letsencrypt.org/docs/staging-environment/
[1] -
https://community.letsencrypt.org/t/acme-caa-validation-methods-support/63125
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme