[Acme] Remove combinations array
Jacob Hoffman-Andrews <jsha@eff.org> Wed, 17 August 2016 18:22 UTC
Return-Path: <jsha@eff.org>
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 3067412D7E1 for <acme@ietfa.amsl.com>; Wed, 17 Aug 2016 11:22:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.249
X-Spam-Level:
X-Spam-Status: No, score=-8.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.247, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org
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 HqAUVj9I_m5l for <acme@ietfa.amsl.com>; Wed, 17 Aug 2016 11:22:49 -0700 (PDT)
Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2524312D51F for <acme@ietf.org>; Wed, 17 Aug 2016 11:22:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:Subject:From:To; bh=3atcSNbVCB1lzaZSJFe9Jkt+a9Ah9aWB8r3r0EA5DBk=; b=o98c1wmWiXdVuoIirSqY0HYcknA2J3BisOV/ruxtUes5jVhYFRkY9ob1ejiDk6GDkRtGOPl9NwRsxY2EynodNmrQ+VWXTsbwWgEdJBYbx3korNyfNC0bM4AZrB5i+A3bEP1E/Hf7dqBPmd9ag1TfoOxSIjepXCaeWsq0WFEKVdg=;
Received: ; Wed, 17 Aug 2016 11:22:48 -0700
To: "acme@ietf.org" <acme@ietf.org>
From: Jacob Hoffman-Andrews <jsha@eff.org>
Message-ID: <e5054e02-af84-e87e-1c73-aa48876866e4@eff.org>
Date: Wed, 17 Aug 2016 11:22:47 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/dZT-QEIG12EO9dCqNjK_uqKvNyQ>
Subject: [Acme] Remove combinations array
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 17 Aug 2016 18:22:51 -0000
https://github.com/ietf-wg-acme/acme/pull/171 This is a fairly complicated part of the protocol, and not used in practice. For instance, in Let's Encrypt's implementation, there are always three challenges, any one of which may be fulfilled by the client. After this change, all challenges are considered to be combined with an "OR." That is, any challenge within an authorization may be completed to make the authorization valid. Authorizations within the new-application object are considered to be combined with an "AND." That is, all of them must become valid before the certificate will be issued. The combination of the two means that we have similar expressiveness as before, even without the combinations array. Thoughts?
- Re: [Acme] Remove combinations array James Kasten
- Re: [Acme] Remove combinations array Richard Barnes
- [Acme] Remove combinations array Jacob Hoffman-Andrews