IETF Logo Mail Archive

Re: [Acme] ACME resources relations

Richard Barnes <rlb@ipv.sx> Fri, 03 February 2017 18:46 UTC

Return-Path: <rlb@ipv.sx>
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 6C5951294E5 for <acme@ietfa.amsl.com>; Fri, 3 Feb 2017 10:46:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.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 vox1kiCcf-H9 for <acme@ietfa.amsl.com>; Fri, 3 Feb 2017 10:46:44 -0800 (PST)
Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95456129409 for <acme@ietf.org>; Fri, 3 Feb 2017 10:46:44 -0800 (PST)
Received: by mail-ua0-x22c.google.com with SMTP id 96so20201115uaq.3 for <acme@ietf.org>; Fri, 03 Feb 2017 10:46:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sAIBaYEXpgBEvHoPNLUO6TEW81jBJ40fuBVRcFiISMM=; b=m1Ae9lgRBZ6CfUBHhdIz+985OGVHGLf1+e8SK0Iz1FrqSTZ1KGqZxhA8xtEFdGH2Hz 5tNGtaEughBb/Igv7qAqTcRZ5wgPpC4lMrQbMaYLLcY25zi7FxBAkctZMT46mVN9AUwV GGxKvVek4efMOFCmuxD5uhsWOqTng3PUm1JiukPW2gnSiKoP+/pQZ3Fj8v6nBmrqr9Kg Pi7kjJCXVBKrBc4y7TSgx/Vw0Cj6ZzxdyEnFUe0pH6i+NEweOm17UzP7oczGhmRMtJFs dLnkiaLvzN2zac/foSCkoQhqEHHCAkoYpK9jV84i7Nv6/DqpqSr+XoyZ8UQdP7x0fybV NuQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sAIBaYEXpgBEvHoPNLUO6TEW81jBJ40fuBVRcFiISMM=; b=F8gB78kdRYGFeFD9LMwWF2FIB0kEGlBM6P2RDO8ih6Cv2kbrQW0V/vQpKslNWTRmTC Q9uc0mizU5mSUDlgiX13Dn/AFGgHZdekGlMOzuEvhuZnnu8rKEH4cEKPkvxspMZaQj6X nzzXF3oymVppIGPk2orOrdsl/gaR4x4W2e4qdYGLbKLxDUWdptJlG5o6te/CyF4deOXI 5iM6BOssgWRffHj7MJxeneZ+vaoeYxhy62Ttygb8tD9ehZG1mdPnDQqDcNVjJKZSdcok bS5laCn3nEbMzug6vRGrIxR8xqfHZgUGxbQE5lcFcwc8GgZqQsVaJ/sT13oVyqGiJDMI WagQ==
X-Gm-Message-State: AIkVDXLV70pz9RqWUc7j5FINNJBcQXcOSiZkPZ7J7CyYpdGFQU9Zi1ookPn333V18smtmqKqd7sjjHlsL+D7Ww==
X-Received: by 10.159.36.73 with SMTP id 67mr7948403uaq.124.1486147603524; Fri, 03 Feb 2017 10:46:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.31.179.140 with HTTP; Fri, 3 Feb 2017 10:46:42 -0800 (PST)
In-Reply-To: <1bfcd722703f4236a32fc7458084ff06@Buyp-gvk-ex01.intra.buypass.no>
References: <1bfcd722703f4236a32fc7458084ff06@Buyp-gvk-ex01.intra.buypass.no>
From: Richard Barnes <rlb@ipv.sx>
Date: Fri, 03 Feb 2017 10:46:42 -0800
Message-ID: <CAL02cgQjbMvRVAVGLzrJde1OOdjH74gPgT-ctzeX42e7-5-w3A@mail.gmail.com>
To: Andriy Mahats <Andriy.Mahats@buypass.no>
Content-Type: multipart/alternative; boundary="001a113e1c9cfe7a820547a4b308"
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/qEDdqetANyDX25uZaGAL4dX8y70>
Cc: "acme@ietf.org" <acme@ietf.org>
Subject: Re: [Acme] ACME resources relations
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: Fri, 03 Feb 2017 18:46:46 -0000

This is a good question, and I'm not sure what the right answer is.  It
seems like there are basically three options:

1. Remove the "up" relation
2. Have the "up" relation point to the order that created the authz (if any)
3. Have multiple "up" relations pointing to all relevant orders

Of those options, I would probably prefer (1), just because I don't really
see much of a use case for it.

On Fri, Jan 20, 2017 at 8:08 AM, Andriy Mahats <Andriy.Mahats@buypass.no>
wrote:

> Hi all!
>
>
>
> At the resource diagram in *6.1 Resources* section,
>
> there is an authz resource related to order by “up” relation.
>
>
>
> My question is for following case:
>
>
>
> The client orders a certificate
>
> and at the time of ordering it satisfied some of authorizations (let’s say
> 2 of 3)
>
> in previous transactions (possibly using pre-authorization: new-authz).
>
>
>
> When client queries such previously satisfied authorization,
>
> what order resource shall pointed using “up” relation,
>
> since that authorization can be used for many orders?
>
>
>
> I’ve created issue in GitHub for this. You can find it here:
> https://github.com/ietf-wg-acme/acme/issues/236
>
>
>
>
>
> Sincerely,
>
> Andriy
>
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
>

v2.23.0 | Report a Bug | By Email