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

Rob Stradling <rob@sectigo.com> Tue, 17 November 2020 22:50 UTC

Return-Path: <rob@sectigo.com>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 524BB3A0E55 for <acme@ietfa.amsl.com>; Tue, 17 Nov 2020 14:50:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.09
X-Spam-Level:
X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sectigo.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CaR8VzUZDuwK for <acme@ietfa.amsl.com>; Tue, 17 Nov 2020 14:49:58 -0800 (PST)
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2048.outbound.protection.outlook.com [40.107.244.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 529FD3A0E46 for <acme@ietf.org>; Tue, 17 Nov 2020 14:49:47 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Kdtvhh5R3wfFV3aFsVf83VV4LpKeKElJUmj1KP9qn3eR0nBuqhuByecIvyGc0dE6+4eX5Anoc8uPmVtKXeC/VbEvx75gYmZj+rxYb5K+HQssP0bAN7V3JAe9HCP/cFFXt5QIqry4eOdaKPvJKX3Xs6RmAvInIJ3V+8ngug1EuM7AAtkEfL9ct6t2v0tZQnMoFVy2c3kZVUwoqqr+miOSOgGcAjGy+HKiszQCs0+hagUAqqLpw1xhI6BP48WZSBRhCRN3mPZktdFoZ98iv4cuzfrTMh3CsFYZelBiM6q40m2zwxZWCaeWTuh5gUc/WIVAWPWqeWS7LNgVVR7yE2Ikfg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iEetr4xghn1lEr0lGxyLHdangWtIx5zPf9Gss8VX2ws=; b=NIzITGtAR9bGMtnGOOV7qbv+NkyAx0FLxXXmhHs5Y8dCrSQbZsUjiCNrZKu96HnewBH4tFD7E5qhUa+q66D+q9yQU7TMRtLxLJYAXY2IaChYYwP1aTaTjowZpuCs32Odz/oVDUMOFSXs5oau180lWBTZ4sWK0tf3qNkGGWT+IR1zEzNqxbDGOehuTaf1X9i7Ul95CDcmL7Ryv+wswwHkOsVErb70N4gXD+qezCbUU9mUIQrvy7+qpGnaGOxr3KSKoToviW6gpPdLx5sWnl5KGXtNRreQcGam2MD835Wb0zQHaAxEaH5bFQrj8jApVWguPNqug2aq6Oyo0bcsjpYUsw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=sectigo.com; dmarc=pass action=none header.from=sectigo.com; dkim=pass header.d=sectigo.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sectigo.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iEetr4xghn1lEr0lGxyLHdangWtIx5zPf9Gss8VX2ws=; b=QMrC47sIB+80VTVypgqoEvVQgYLU0N/jgK7c36jOJRBh96L2kOIwMquAi3VoCE2w8utkmvDhxmTAL4af97uYz6k/38Wzn+0t+Li+ZBi9X9x8TB2Uz2K0F9R5noEga19LmOAotct4MR71wm6qNqSSlglCLycO2xcOUem4O79ijKU=
Received: from MW3PR17MB4122.namprd17.prod.outlook.com (2603:10b6:303:44::15) by MWHPR17MB1438.namprd17.prod.outlook.com (2603:10b6:300:ca::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3564.25; Tue, 17 Nov 2020 22:49:44 +0000
Received: from MW3PR17MB4122.namprd17.prod.outlook.com ([fe80::81c7:e190:21c3:9983]) by MW3PR17MB4122.namprd17.prod.outlook.com ([fe80::81c7:e190:21c3:9983%8]) with mapi id 15.20.3564.028; Tue, 17 Nov 2020 22:49:44 +0000
From: Rob Stradling <rob@sectigo.com>
To: Jacob Hoffman-Andrews <jsha@letsencrypt.org>
CC: "acme@ietf.org" <acme@ietf.org>
Thread-Topic: [Acme] Conflicting requirements for retrieving an ACME account that is already bound to an external account
Thread-Index: AQHWuDbZ3Ca9ixTj50S2TXCWhBHWtKnMznoAgAATFwM=
Date: Tue, 17 Nov 2020 22:49:44 +0000
Message-ID: <MW3PR17MB41228E410906AF35AE428421AAE20@MW3PR17MB4122.namprd17.prod.outlook.com>
References: <MW3PR17MB4122DD879FB24AEB6B856E28AAE80@MW3PR17MB4122.namprd17.prod.outlook.com>, <CAN3x4QngVMpuvUnxqj34XpDY3A0gUq7=G29o57nbVBxWz3+Y9A@mail.gmail.com>
In-Reply-To: <CAN3x4QngVMpuvUnxqj34XpDY3A0gUq7=G29o57nbVBxWz3+Y9A@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: letsencrypt.org; dkim=none (message not signed) header.d=none;letsencrypt.org; dmarc=none action=none header.from=sectigo.com;
x-originating-ip: [213.31.96.179]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 5b3b527a-1f31-4694-cf1b-08d88b4b13e2
x-ms-traffictypediagnostic: MWHPR17MB1438:
x-microsoft-antispam-prvs: <MWHPR17MB14385D571A64356931522FE8AAE20@MWHPR17MB1438.namprd17.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: URlZY2WyT1tkUpU8yBlMGb87kPUXOHYPRAC7V86HzZcrW5Awj2uCBE+s1DixwBgGOsVX94Gr12TVZYayvwDikOLaxBrwxvlSoyFlJQ2Y1NeGNkFPrQG1OcoRMq1tj6Tr6Vs3LZA8VZPIboBlVY6IQT85yepwcF7DFNP25f/CLWZ+W4EjlU7wGjzGpy28bCv4SW/3IbhBTfwSuiBr7l1tVZfwfSipC1jua+RG3U8xoV/gTA/3XOXjM/zJBFC3YjUMbnlHjkpysq99JaieyRKm7SVtd4XdNWHfw6Ai0+7hoBzWjxOM08q5eFipWlHsiGJ4Y5Rkut1F0g3AC0vtwC6/Bw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR17MB4122.namprd17.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(376002)(366004)(39860400002)(346002)(396003)(71200400001)(83380400001)(66446008)(19627405001)(6916009)(8676002)(8936002)(9686003)(55016002)(86362001)(52536014)(7696005)(5660300002)(26005)(53546011)(33656002)(186003)(6506007)(66476007)(64756008)(66946007)(76116006)(66556008)(15650500001)(316002)(478600001)(91956017)(2906002)(4326008); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: SBw/z9rEe6BR9tb85DF+ZP1OdZwNiU7HjmI+nVgrsjcEDwPrEu71YPdmHM6lyWNVwfLvmVh0hlo5PAKDiAA1ETzRfywiOrDUJaIBYN+SoYopOXRBYJ14+x5MVXVBhPrQzT+fxYfrtE00zbCa1GLzr7E104TbMdWGXKyKR/IeWtOKbOqvkys9dZsNvJHb3QXcQrKuHEecJnUi4au6OV3iJ7NWgRT9s8XA/AztgARWpO2ZDSHaTqLXwnf45XrVnQet7fFYzCmGTD8ga2LbUuKyKNY1+8dsPmFYLNSaHGYcpPW/VjMu7jSCSFYky4JmRyIini5K2IMlj/iOsTDMCYPc+vn8+MAlTXdqTUgsxDXicTJnPkuTtr8zN47Jboe9Ec62jf5CYJnCuirAdKB3PnREGl9q8ZuHy7FBcNDw4uMiiF5LoQg0MlTJGdZ0HoC+ciAzFTYFM6YE4+HEek42z+fB0iuZCZyPF56LKaXPchVIetSZ85lOwBdScKUNdTgijoV4tAkHlHjTH9TIEnrQ8x6x7wQl6yjqmGQw9KJhNetzkASe+C+0jsfNqt/U0Um8Kp33H8Ar5Dw33mtPF//5CEuSOtqGLf9frcsJox3nUVRGNJ47MgsAvlHm8xxYAqA3QU5OPLPoFOuPt71wPKCf07l84w==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MW3PR17MB41228E410906AF35AE428421AAE20MW3PR17MB4122namp_"
MIME-Version: 1.0
X-OriginatorOrg: sectigo.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MW3PR17MB4122.namprd17.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5b3b527a-1f31-4694-cf1b-08d88b4b13e2
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2020 22:49:44.4149 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0e9c4894-6caa-465d-9660-4b6968b49fb7
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: qdSjqe2FctS0lEtC1Mp2UghVd78dK2QomZQ9AeyxR0dj94bMgO1zqddkaKaK8UUuJzZj7M2upcV9kXLvavWExg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR17MB1438
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/Tk-lkOky-fZjykudqt_Fkl2DlIw>
Subject: Re: [Acme] Conflicting requirements for retrieving an ACME account that is already bound to an external account
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Nov 2020 22:50:00 -0000

> I understand "reflect" to mean "echo what the client sent."

Thanks Jacob!  I hadn't thought of interpreting it that way.

I've just done a quick review of other instances of the word "reflect" in the document.  I think some instances obviously mean "echo what the client sent" (e.g., [1]), whereas other instances seem to mean "send the server's current view" (e.g., [2]), and at least one instance combines both of these meanings (e.g., [3]).

The context of 'MUST NOT reflect the "externalAccountBinding" field in the resulting account object' is...

  'When a CA receives a newAccount request containing an
   "externalAccountBinding" field,'

...which does seem to suggest that "echo what the client sent" is the intended meaning of this particular instance of "reflect".

So I'm going to choose to interpret it that way so that I can make forward progress.  🙂


> > 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).
>
> ...if you want to do an errata for 1, I'd support it.

I suppose an erratum for 1 might break compatibility with some existing EAB-requiring servers, so it's probably best not to.


> > 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.
>
> I'm not enthusiastic about 2.

If a client tries to bind an ACME account that is already bound to external account EA1 to a different external account EA2, but the "externalAccountBinding" field in that client request is silently ignored, how does the client know that (despite the successful account retrieval) their ACME account has not been bound to EA2?  My thought was just that it might be better to throw an error so that the client is aware.


[1] Section 7.3 says:

  'The server MUST NOT reflect the
   "onlyReturnExisting" field or any unrecognized fields in the
   resulting account object.'

      I think the only place "any unrecognized fields" could have come from is the client's request, so this instance of "reflect" seems to mean "echo what the client sent".

[2] Section 7.4.1 says:

  'In some cases, a CA running an ACME server might have a completely
   external, non-ACME process for authorizing a client to issue
   certificates for an identifier.  In these cases, the CA should
   provision its ACME server with authorization objects corresponding to
   these authorizations and reflect them as already valid in any orders
   submitted by the client.'

      Since these authorization objects are determined by the ACME server without any involvement of an ACME client, this "reflect" seems to mean "send the server's current view".


[3] Section 7.4 says:

  'The body of this response is
   an order object reflecting the client's request and any
   authorizations the client must complete before the certificate will
   be issued.'


      The "reflecting the client's request" is obviously "what the client sent"; but "reflecting the...authorizations the client must complete" must mean "send the server's current view", because those authorizations are determined by the server.

________________________________
From: Jacob Hoffman-Andrews <jsha@letsencrypt.org>
Sent: 17 November 2020 20:23
To: Rob Stradling <rob@sectigo.com>
Cc: acme@ietf.org <acme@ietf.org>
Subject: Re: [Acme] Conflicting requirements for retrieving an ACME account that is already bound to an external account


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.


I think this is the key bit:

>   - Since the server has not verified the binding, its response 'MUST NOT reflect the "externalAccountBinding" field in the resulting account object'.

I understand "reflect" to mean "echo what the client sent." So I think it's acceptable for the server to ignore the externalAccountBind field / not re-verify it, and return an account object whose externalAccountBinding field is set based on the contents of the CA's database.

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

I think an errata is not needed to make forward progress, but if you want to do an errata for 1, I'd support it. I'm not enthusiastic about 2.

In general I think providing the option to look up an account by key was a mistake. Clients already have to store one piece of state (the account key), and asking them to store a second piece of state (the account URL) is not onerous. Particularly in the case where the client is storing both an account key and an external account binding, I think it's reasonable to ask that the client store the account URL rather than add additional complexity to the account-lookup part of the standard.