Re: [Acme] question regarding -subdomains-00 section 5
Thanks for the review Daniel.
I created a github issue to track:
https://github.com/upros/acme-subdomains/issues/2
From: Acme On Behalf Of Daniel Migault
Sent: 09 December 2021 06:26
To: acme@ietf.org
Subject: [Acme] question regarding -subdomains-00 section 5
Briefly looking at the flows of section 5 I do have the following
questions/comments.
| POST /challenge| |
|--->| |
|| Verify|
||-->|
| 200 status=valid | |
|<---| |
I believe the 200 response is the response to the POST / Challenge
extrapolating the POST-as-GET to the order resource.
[ofriel] Correct.
My understanding is that the purpose of the POST is to indicate the challenge
can be checked by the ACME server. It has a challenge url as well as an empty
JSON payload {}.
The POST-as-GET purpose would be to check the status of the authorization
resource. It has an new-order url and a void payload.
If the 200 status=valid is a response to a POST /challenge, I am wondering if
that is a common practice for ACME server to delay the response of a POST
/challenge and to have the client inferring the 200 status=valid will be
reflected in the authorization and later in the order with a status=ready or
valid.- assuming the the order requires a single authorization. When multiple
authorizations are involved, the ACME client would need to keep track of those.
I might also have missed this in 8555.
[ofriel] https://datatracker.ietf.org/doc/html/rfc8555#section-7.5.1 states:
“Usually, the validation process will take some time, so the client
will need to poll the authorization resource to see when it is
finalized”
So you are correct, the usual flow is an immediate response to the client with
a status=processing, and then the client polls until it gets a response with
status=valid. I guess the operative word in the acme-subdomains doc is
*Illustrative* call flow, but I could add a processing response and a client to
server poll to the call flow to make it clearer and align with the ‘usual’ flow
if there is consensus that that will make things clearer.
The ACME spec is pretty flexible and not proscriptive here. And yes, if the
client has multiple pending authorizations, then yes it will have to track
these different pending objects.
I do have a similar question regarding the finalize order exchange.
Beginning of page 12, given the text on page 11, and the introduction to step
2, it seems maybe clearer to set the status of the authorization object to
"valid".
[ofriel] Maybe it becomes clearer if I split the paragraph. I can put the
second sentence “Once the client completes the challenge, the server will
transition the authorization object and associated challenge object status to
"valid". “ after the example STEP 1 JSON.
STEP 2:
"""
As an authorization object already exists for the parent ADN of the
Domain Namespace, the server replies with an order object with a
status of "valid" that includes a link to the existing "valid"
authorization object.
"""
I have the impression an order has its status set to valid once the certificate
has been issued. In STEP 2, my understanding is that authorization has been
validated and the order has not been finalized, so I would have expected a
status set to ready.
I have the same issue in STEP 3.
[ofriel] Correct for both steps, will update to “ready”.
Yours,
Daniel
--
Daniel Migault
Ericsson
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
[Acme] acme-subdomains RFC8499 vs. CA/B terminology
I mentioned it at IETF 112 that we needed to decide on use of RFC8499 vs. CA/B forum terminology in the document. As this document is not specific to Web PKI use cases, I prefer RFC8499 terminology. Martin expressed that preference too: https://mailarchive.ietf.org/arch/msg/acme/Yh1YbtqZy9rwOmInU1KyJdADTE4/ For acme-integrations, Deb also preferred RFC8499: https://mailarchive.ietf.org/arch/msg/acme/Hj1PwYuO0zWdXG4HOPGOs8cVNw4/ So unless I hear otherwise, I will publish a draft-01 with updated RFC8499 terminology, that also addresses Daniels comments https://mailarchive.ietf.org/arch/msg/acme/Px0d5MG5_fC490PmEUSRAcsCAF0/ , before the holiday break. Cheers, Owen ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] question regarding -subdomains-00 section 5
Thanks. I agree with you that mentioning this is an illustrative flow is
good. The flows are also pretty clear, so my personal recommendation
would be to keep the flows as they are, but clarifying this also works in a
poll model with a few lines just to clarify it works with any acme client.
Of course that is my personal opinion.
Yours,
Daniel
On Fri, Dec 10, 2021 at 4:09 AM Owen Friel (ofriel)
wrote:
> Thanks for the review Daniel.
>
>
>
> I created a github issue to track:
> https://github.com/upros/acme-subdomains/issues/2
>
>
>
>
>
>
>
>
>
> *From:* Acme *On Behalf Of *Daniel Migault
> *Sent:* 09 December 2021 06:26
> *To:* acme@ietf.org
> *Subject:* [Acme] question regarding -subdomains-00 section 5
>
>
>
> Briefly looking at the flows of section 5 I do have the following
> questions/comments.
>
>
>
>| POST /challenge| |
>|--->| |
>|| Verify|
>||-->|
>| 200 status=valid | |
>|<---| |
>
>
> I believe the 200 response is the response to the POST / Challenge
> extrapolating the POST-as-GET to the order resource.
>
> [ofriel] Correct.
>
>
> My understanding is that the purpose of the POST is to indicate the
> challenge can be checked by the ACME server. It has a challenge url as well
> as an empty JSON payload {}.
> The POST-as-GET purpose would be to check the status of the authorization
> resource. It has an new-order url and a void payload.
>
> If the 200 status=valid is a response to a POST /challenge, I am
> wondering if that is a common practice for ACME server to delay the
> response of a POST /challenge and to have the client inferring the 200
> status=valid will be reflected in the authorization and later in the
> order with a status=ready or valid.- assuming the the order requires a
> single authorization. When multiple authorizations are involved, the ACME
> client would need to keep track of those. I might also have missed this in
> 8555.
>
>
>
> [ofriel] https://datatracker.ietf.org/doc/html/rfc8555#section-7.5.1
> states:
>
>
>
> “Usually, the validation process will take some time, so the client
>
>will need to poll the authorization resource to see when it is
>
>finalized”
>
>
>
> So you are correct, the usual flow is an immediate response to the client
> with a status=processing, and then the client polls until it gets a
> response with status=valid. I guess the operative word in the
> acme-subdomains doc is **Illustrative** call flow, but I could add a
> processing response and a client to server poll to the call flow to make it
> clearer and align with the ‘usual’ flow if there is consensus that that
> will make things clearer.
>
>
>
> The ACME spec is pretty flexible and not proscriptive here. And yes, if
> the client has multiple pending authorizations, then yes it will have to
> track these different pending objects.
>
>
>
> I do have a similar question regarding the finalize order exchange.
>
>
> Beginning of page 12, given the text on page 11, and the introduction to
> step 2, it seems maybe clearer to set the status of the authorization
> object to "valid".
>
> [ofriel] Maybe it becomes clearer if I split the paragraph. I can put the
> second sentence “Once the client completes the challenge, the server will
> transition the authorization object and associated challenge object status
> to "valid". “ after the example STEP 1 JSON.
>
>
>
> STEP 2:
>
> """
> As an authorization object already exists for the parent ADN of the
>Domain Namespace, the server replies with an order object with a
>status of "valid" that includes a link to the existing "valid"
>authorization object.
> """
>
> I have the impression an order has its status set to valid once the
> certificate has been issued. In STEP 2, my understanding is that
> authorization has been validated and the order has not been finalized, so I
> would have expected a status set to ready.
>
> I have the same issue in STEP 3.
>
> [ofriel] Correct for both steps, will update to “ready”.
>
> Yours,
> Daniel
>
>
>
> --
>
> Daniel Migault
>
> Ericsson
>
--
Daniel Migault
Ericsson
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] acme-subdomains RFC8499 vs. CA/B terminology
I also prefer 8499 terminology. Yours, Daniel On Fri, Dec 10, 2021 at 4:40 AM Owen Friel (ofriel) wrote: > I mentioned it at IETF 112 that we needed to decide on use of RFC8499 vs. > CA/B forum terminology in the document. > > > > As this document is not specific to Web PKI use cases, I prefer RFC8499 > terminology. > > > > Martin expressed that preference too: > https://mailarchive.ietf.org/arch/msg/acme/Yh1YbtqZy9rwOmInU1KyJdADTE4/ > > > > For acme-integrations, Deb also preferred RFC8499: > https://mailarchive.ietf.org/arch/msg/acme/Hj1PwYuO0zWdXG4HOPGOs8cVNw4/ > > > > So unless I hear otherwise, I will publish a draft-01 with updated RFC8499 > terminology, that also addresses Daniels comments > https://mailarchive.ietf.org/arch/msg/acme/Px0d5MG5_fC490PmEUSRAcsCAF0/ , > before the holiday break. > > > > Cheers, > > Owen > ___ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > -- Daniel Migault Ericsson ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
