The text of the RFC itself is not updated; you can consider verified
erratum to be authoritative. Verified erratum will be incorporated into
ACME-bis (a.k.a. ACME v2) if such a document is deemed necessary in the
future.
Aaron
On Mon, Nov 18, 2024 at 8:03 AM Jeremy Hahn <m...@jeremyhahn.com> wrote:
> Hello,
>
> Apologies for neglecting your inquiry. Yes, this seems to address the
> issue. Thank you very much.
>
> What is the process and expected timeline to get it published to the RFC?
>
> On Mon, Nov 18, 2024, 10:57 AM Rob Stradling <r...@sectigo.com> wrote:
>
>> > If the RFC does not strictly require an empty payload, that solves half
>> of my problem. It might be worth considering updating the language used in
>> the RFC to something like -
>> > "The client indicates to the server that it is ready for the challenge
>> validation by sending a JSON POST request to the challenge UIRL (not the
>> authorization URL). The client MUST send an empty JSON body ("{}") carried
>> in a POST or MAY optionally send an object supporting server-specific
>> challenges."
>>
>> Sending again...
>>
>> Does the following Verified erratum already address this concern?
>>
>> https://www.rfc-editor.org/errata/eid5729
>>
>> ------------------------------
>> *From:* Jeremy Hahn <m...@jeremyhahn.com>
>> *Sent:* 16 November 2024 18:57
>> *To:* Michael Richardson <mcr+i...@sandelman.ca>
>> *Cc:* Jacob Hoffman-Andrews <j...@letsencrypt.org>; acme@ietf.org <
>> acme@ietf.org>
>> *Subject:* [Acme] Re: RFC 8555 challenge response proposal
>>
>> This Message Is From an External Sender
>> This message came from outside your organization.
>> Report Suspicious
>> <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/J5K_pWsD!B8YZvmQUdQw35tzo9zc1jvOVHCeJLNuOmWnJtgeZpNuvSeBPn9_c_XcRcuJOC8sML0Fti22wkrlaefMsNGGX4mHDUCN17_-ZcgmgyJWX0u9PHlbarNu6Uvgd$>
>>
>> If the RFC does not strictly require an empty payload, that solves half
>> of my problem. It might be worth considering updating the language used in
>> the RFC to something like -
>>
>> "The client indicates to the server that it is ready for the challenge
>> validation by sending a JSON POST request to the challenge UIRL (not the
>> authorization URL). The client MUST send an empty JSON body ("{}") carried
>> in a POST or MAY optionally send an object supporting server-specific
>> challenges."
>>
>> I think the way it reads now comes across as the empty payload being part
>> of the protocol specification, leading to hard coded client implementations:
>> https://github.com/golang/crypto/blob/master/acme/acme.go#L517
>> <https://urldefense.com/v3/__https://github.com/golang/crypto/blob/master/acme/acme.go*L517__;Iw!!J5K_pWsD!0d6oW64ItwkFjd8gQODGe45yTxyadLKsOiE1tLiYPZn2ZR4ns5XQnVkC2A7UtgCnh6f3ZW_s9pI6$>
>>
>> "I really think it's a mistake to lump attestation responses in with
>> authorization challenges."
>>
>> I'm interested in hearing more about the concerns here and what you feel
>> is the right solution. In an effort to try to clarify the issue -
>>
>> I'm supporting device based attestations where the CA administrator
>> imports the root certs of the hardware manufacturer devices they want to
>> support as part of their initial setup or ongoing support (IE., a TPM or
>> HSM). After the CA has the root cert imported, the devices can be verified
>> by the CA to be genuine devices from a trusted manufacturer, and then used
>> to perform attestations regarding the security properties of the keys,
>> configurations, OS configs, etc on the systems they are installed.
>> Therefore, when the CA gets the "Accept" request as defined in RFC 8555,
>> section 7.5.1 from a client with the ability to produce a device
>> attestation, this client has the ability to include the challenge key
>> authorization in an attestation statement / payload at the same time it
>> notifies the CA that it's ready for validation. Since the CA has everything
>> it needs to both verify the request is from a trusted device, and that the
>> key authorization is correct, it does not necessitate any further activity
>> or round trips between the client and server.
>>
>> If you don't think submitting the payload at this time is appropriate,
>> what do you feel is the right implementation. Section 7.5.1 seems to
>> indicate that it's intention is to both prove control of the identifier (a
>> custom device id and public key defined by the TPM/HSM manufacturer in the
>> case of device attestations), to provision the "required" challenge
>> response based on the challenge type and indicate to the serve that it is
>> ready for validation.
>>
>> It seemed to me like this stage in the protocol would be the appropriate
>> time to submit the payload and perform the validation in a
>> synchronous manner, but if there is a better way, I would prefer that
>> approach, and have documentation based on RFC's to support the design
>> decision.
>>
>> What are your thoughts?
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Nov 15, 2024 at 12:09 PM Michael Richardson <
>> mcr+i...@sandelman.ca> wrote:
>>
>>
>> Jeremy Hahn <m...@jeremyhahn.com> wrote:
>> > An attestation authorization still needs to be verified with a
>> challenge,
>> > so setting it to valid in the new-order request does not seem like
>> it would
>> > work. I think what's best for device attestation is the ability to
>> send the
>> > attestation / challenge response at the same time the challenge is
>>
>> If I'm understanding this thread correctly...
>> I really think it's a mistake to lump attestation responses in with
>> authorization challenges. As I said in the WG session, I think that the
>> terminology is an attractive nuissance and we need a new term that
>> describes
>> the process by which a client proves they are "sane" enough to be issued a
>> certificate, and that this is very different from proving authorization
>> for a
>> name.
>>
>> OTH, I may mis-understand this discussion.
>>
>> --
>> Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting
>> )
>> Sandelman Software Works Inc, Ottawa and Worldwide
>>
>>
>>
>>
>> _______________________________________________
> Acme mailing list -- acme@ietf.org
> To unsubscribe send an email to acme-le...@ietf.org
>
_______________________________________________
Acme mailing list -- acme@ietf.org
To unsubscribe send an email to acme-le...@ietf.org
