[Acme] Conflicting requirements for retrieving an ACME account that is already bound to an external account

[Rob Stradling <[e-mail]>]

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