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
"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
