> 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<mailto:mcr%2bi...@sandelman.ca>> wrote:
Jeremy Hahn <m...@jeremyhahn.com<mailto: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<mailto:mcr%2bi...@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
