Re: [Acme] Authorizations and Certificates in Registrations

Niklas Keller <me@kelunik.com> Sat, 05 December 2015 20:10 UTC

Return-Path: <me@kelunik.com>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91CCD1A9059 for <acme@ietfa.amsl.com>; Sat, 5 Dec 2015 12:10:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.427
X-Spam-Level:
X-Spam-Status: No, score=-0.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6] autolearn=no
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 Z0hjxumEtkzB for <acme@ietfa.amsl.com>; Sat, 5 Dec 2015 12:10:03 -0800 (PST)
Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::8]) (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 9E5221A904E for <acme@ietf.org>; Sat, 5 Dec 2015 12:10:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1449346200; l=4079; s=domk; d=kelunik.com; h=Content-Type:Cc:To:From:Subject:Date:References:In-Reply-To: MIME-Version; bh=VEoMs6UKuOCoOW6zzhZQANxNEhykNERGq//s9dhDUrg=; b=tBSazQ7ItSPywgVn4bgOcXby7xxTT09cpLnG1IhksgORF3vD/gQ54MkQpI8vGXeOaQH yCI8N6McGdp6QRvIEFl34tDrj+7v1DE2yTDyei+qFboPJm+a4zpMAi0RD6C/0hrUnoQba 0+h8l7/C2pnXlTOO0sLgcbOnPqlnHoFI46M=
X-RZG-AUTH: :IWkkfkWkbvHsXQGmRYmUo9mls2vWuiu+7SLGvomb4bl9EfHtO3Q6
X-RZG-CLASS-ID: mo00
Received: from mail-wm0-f47.google.com ([74.125.82.47]) by smtp.strato.de (RZmta 37.14 AUTH) with ESMTPSA id N04073rB5KA0lAA (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (curve secp384r1 with 384 ECDH bits, eq. 7680 bits RSA)) (Client did not present a certificate) for <acme@ietf.org>; Sat, 5 Dec 2015 21:10:00 +0100 (CET)
Received: by wmww144 with SMTP id w144so104635585wmw.0 for <acme@ietf.org>; Sat, 05 Dec 2015 12:10:00 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.194.171.97 with SMTP id at1mr24238957wjc.39.1449346200021; Sat, 05 Dec 2015 12:10:00 -0800 (PST)
Received: by 10.194.22.5 with HTTP; Sat, 5 Dec 2015 12:09:59 -0800 (PST)
In-Reply-To: <56633D3D.5060203@eff.org>
References: <CANUQDCjv6oVAyFNm8pQfmEzEJ+s+HsAS7OkV5H3U1X8JWHaRNA@mail.gmail.com> <56633D3D.5060203@eff.org>
Date: Sat, 5 Dec 2015 21:09:59 +0100
X-Gmail-Original-Message-ID: <CANUQDCiotcLmYepyv2ce1xuJJ6_mn_O59YxeDFOpLF435_rQKA@mail.gmail.com>
Message-ID: <CANUQDCiotcLmYepyv2ce1xuJJ6_mn_O59YxeDFOpLF435_rQKA@mail.gmail.com>
From: Niklas Keller <me@kelunik.com>
To: Jacob Hoffman-Andrews <jsha@eff.org>
Content-Type: multipart/alternative; boundary=089e013c615068bb6605262c35e9
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/QqWoClvTwq5Vx8Z-YOhzb-beI3s>
Cc: IETF ACME <acme@ietf.org>
Subject: Re: [Acme] Authorizations and Certificates in Registrations
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.15
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: Sat, 05 Dec 2015 20:10:04 -0000

2015-12-05 20:38 GMT+01:00 Jacob Hoffman-Andrews <jsha@eff.org>rg>:

> > what's the reason why "authorizations" and "certificates" are optional
> in registration objects? They should both not be optional IMO, because
> they can be used nicely to lower the load on the CA, because clients can
> reuse prior authorizations and even download lost certificates easily.
> This makes also revocation easier, because you can simply list all valid
> certificates for a given account key.
>
> This is a good question. I would support making it mandatory in the
> protocol. We haven't yet implemented it in Let's Encrypt, but it's on
> the roadmap and it's an important feature.
>
> Speaking of which, I've been meaning to suggest a fix to this feature.
> Right now it specifies a list to be embedded in the new-reg object. It's
> likely that some registrations will have very large lists of
> authorizations and/certificates, making them prohibitive to embed
> directly in the registration.
>
> Instead, I propose that there be a URL for authorizations and a URL for
> certificates for each registration. These URLs would return a JSON list
> of URLs for the relevant objects, and possibly a Link header with
> rel=next for pagination if the number of results is above a
> (server-configured) threshold. Pagination is a very common approach to
> large data sets in web services.
>

https://github.com/ietf-wg-acme/acme/blob/master/draft-ietf-acme-acme.md#registration-objects

It's already an URL, but paging isn't mentioned yet.