https://tools.ietf.org/html/rfc8555#section-7.1.2 says (emphasis mine):
'externalAccountBinding (optional, object): Including this field in a
newAccount request indicates approval by the holder of an existing
non-ACME account to bind that account to this ACME account. This
field is not updateable by the client (see Section
7.3.4<https://tools.ietf.org/html/rfc8555#section-7.3.4>).
https://tools.ietf.org/html/rfc8555#section-7.3.1 says (emphasis mine):
'If the server receives a newAccount request signed with a key for
which it already has an account registered with the provided account
key, then it MUST return a response with status code 200 (OK) and
provide the URL of that account in the Location header field. The
body of this response represents the account object as it existed on
the server before this request; any fields in the request object MUST
be ignored.'
https://tools.ietf.org/html/rfc8555#section-7.3.4 says:
'When a CA receives a newAccount request containing an
"externalAccountBinding" field, it decides whether or not to verify
the binding. If the CA does not verify the binding, then it MUST NOT
reflect the "externalAccountBinding" field in the resulting account
object (if any).'
ISTM that there's a conflict between these requirements when an ACME account
has previously been created and bound to an external non-ACME account (as per
section 7.3.4) and a user now wants to retrieve that ACME account by "Finding
an Account URL Given a Key" (as per section 7.3.1):
- The ACME server's directory object provides (quoting section 7.3.4)...
'the value "true"
in the "externalAccountRequired" subfield of the "meta" field in the
directory object.'
...and so the client is required to include the "externalAccountBinding" field
in the newAccount request.
- The server is required to ignore "any fields in the request object" (per
the part of section 7.3.1 quoted above).
- Whilst the server is normally at liberty to choose "whether or not to
verify the binding" (per the part of section 7.3.4 quoted above), the
requirement to ignore "any fields in the request object" forces the server to
not verify the binding provided by the client during this account retrieval
operation.
- Since the server has not verified the binding, its response 'MUST NOT
reflect the "externalAccountBinding" field in the resulting account object'.
So by attempting to retrieve a previously-externally-bound account, the ACME
client has caused the "externalAccountBinding" field in the account object to
be updated (from present to absent). Except that this can't have happened,
because "This field is not updateable by the client" (per the part of section
7.1.2 quoted above) and because "The body of this response represents the
account object as it existed on the server before this request" (per the part
of section 7.3.1 quoted above). The upshot is that retrieving a
previously-externally-bound account is currently impossible.
At Sectigo we currently have customers affected by this problem, and I think an
erratum to RFC8555 is needed to address it. I'm not proposing text just yet,
but I propose that the outcome of the erratum would be that:
1. A client should be permitted to omit "externalAccountBinding" from a
newAccount request when retrieving an existing account from a server that
requires external account binding. (External account binding is a one-time
operation; as soon as an ACME account and an external account are bound once,
they're bound forever).
2. When a client does provide "externalAccountBinding" in a newAccount
request to retrieve an existing account from a server that requires external
account binding, the server should be required to verify that binding and
ensure that it links to the exact same external account to which the ACME
account is already bound.
Do folks agree with my analysis and proposal?
--
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
