From: Aaron Gable
Sent: 14 September 2021 00:02
To: Owen Friel (ofriel)
Cc: Michael Richardson ; Ryan Sleevi
; Deb Cooley ; acme@ietf.org
Subject: Re: [Acme] working group call for adoption
On Sun, Sep 12, 2021 at 11:24 PM Owen Friel (ofriel)
mailto:ofr...@cisco.com>> wrote:
Consider
On Sun, Sep 12, 2021 at 11:24 PM Owen Friel (ofriel)
wrote:
>
>
> Consider an RA that wants to get device certs for thousands of devices
> e.g. foo.type-a-sensors.example.org and bar.type-b-sensors.example.org,
> The RA would likely do a preAuthz for the domains it owns (e.g.
> example.org)
From: Acme On Behalf Of Aaron Gable
Sent: 02 September 2021 08:31
To: Michael Richardson
Cc: Ryan Sleevi ; Deb Cooley ;
acme@ietf.org
Subject: Re: [Acme] working group call for adoption
On Wed, Sep 1, 2021 at 5:28 PM Michael Richardson
mailto:mcr%2bi...@sandelman.ca>> wrot
On Wed, Sep 1, 2021 at 8:28 PM Michael Richardson
wrote:
>
> Ryan Sleevi wrote:
> >> This seems to make the ACME server keep a bunch of state itself
> (across
> >> multiple HTTPS/TLS connections), while I suspect that most of us
> would like
> >> the client to be responsible for
On Wed, Sep 1, 2021 at 5:28 PM Michael Richardson
wrote:
> Yes, but not necessarily across TLS connections.
>
> One connects, gets a challenge, sets it up (DNS or HTTP/S), waits for the
> authorization check to complete, and sends an order.
>
> I don't know what letsencrypt does, but my
Ryan Sleevi wrote:
>> This seems to make the ACME server keep a bunch of state itself (across
>> multiple HTTPS/TLS connections), while I suspect that most of us would
like
>> the client to be responsible for keeping that authorization around.
>>
>> Would you agree with
On Wed, Sep 1, 2021 at 7:45 PM Michael Richardson
wrote:
> This seems to make the ACME server keep a bunch of state itself (across
> multiple HTTPS/TLS connections), while I suspect that most of us would like
> the client to be responsible for keeping that authorization around.
>
> Would you
Aaron Gable wrote:
> That said, it is not clear to me that this draft enables truly novel
> behavior. I believe that the desired result -- authorization for a single
> parent domain, but issuance only for specific subdomains -- is possible
> using current mechanisms:
> 1)
Substantive comments:
Reading through the history of this document, I see that it started out as
simply specifying server behavior to allow particular kinds of
authorization re-use, and has now grown to an API extension that adds new
fields to various request and response objects. My comments
I have read this document, and I think the ACME WG should adopt it.
Russ
> On Aug 31, 2021, at 11:37 AM, Cooley, Dorothy E
> wrote:
>
> This is a working group call for adoption of:
> draft-friel-acme-subdomains-05. We have had presentations of this work at
> the past couple of IETF meetings
This is a working group call for adoption of:
draft-friel-acme-subdomains-05. We have had presentations of this work at
the past couple of IETF meetings (back to when we still met in person -
sigh).
Please review the draft and post your comments to the list by Wednesday, 15
September 2021.
11 matches
Mail list logo
