Re: [Acme] various issues with the spec

hallam@gmail.com Sat, 13 June 2015 23:04 UTC

Return-Path: <hallam@gmail.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 C594A1B2B8B for <acme@ietfa.amsl.com>; Sat, 13 Jun 2015 16:04:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] 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 qY8tUrlzNgeS for <acme@ietfa.amsl.com>; Sat, 13 Jun 2015 16:04:06 -0700 (PDT)
Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 4CFDE1A908B for <acme@ietf.org>; Sat, 13 Jun 2015 16:04:06 -0700 (PDT)
Received: by qkhg32 with SMTP id g32so34988575qkh.0 for <acme@ietf.org>; Sat, 13 Jun 2015 16:04:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JdBwV6BInXEPrVchux3rZmKFd56aBorBXG5XpT3KhjM=; b=pWzUk9NAgxOPap6OeKML7zJ1Dkgrfh3QSJpwodB0IcnWlgESaCUytP5zpHNVa/cc8B 7+eUsyrRP7J2kpJx+T+Uzo49H4lsC/TvII5nV5cmat2vFd184PAfcRwaF22DYFoFZQMx oODVcHUwwqp8heUPbgHxrfGA6ueFBNzeAN4QHnpX2H1T3g2z7uAY4luWRorW/h2Wt8aT Golf40or5+NnI5hP0tUZG2SHAhM1uiyJtclv5QOYjMBbm84EvmMLcIzF9jItvguSQLER T2IJ0cHsJlOo8BL7LGBOBT2mvG5rQv1iBuhpgOzE/w3B1pnU3yeoGwDsRmcFFIbhaygo JdFA==
X-Received: by 10.140.234.84 with SMTP id f81mr28921637qhc.49.1434236644621; Sat, 13 Jun 2015 16:04:04 -0700 (PDT)
Received: from [10.42.5.182] (mobile-107-107-61-101.mycingular.net. [107.107.61.101]) by mx.google.com with ESMTPSA id q105sm3880478qgq.11.2015.06.13.16.04.03 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 13 Jun 2015 16:04:03 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: hallam@gmail.com
X-Mailer: iPhone Mail (12F70)
In-Reply-To: <20150614002432.58be28e7@chromobil.localdomain>
Date: Sat, 13 Jun 2015 19:04:02 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <D000BE32-6C69-4F0D-A472-BF843555E341@gmail.com>
References: <20150609221325.63935a29@chromobil.localdomain> <20150613232121.51f292af@chromobil.localdomain> <7ed545b29d5149ebba5582dfec9777f5@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150614002432.58be28e7@chromobil.localdomain>
To: =?utf-8?Q?Stefan_B=C3=BChler?= <acme@stbuehler.de>
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/A2WJIH23kuZC2fsEe58xIBEMcSU>
Cc: "acme@ietf.org" <acme@ietf.org>
Subject: Re: [Acme] various issues with the spec
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: <http://www.ietf.org/mail-archive/web/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, 13 Jun 2015 23:04:07 -0000

Updates should be idempotent????

They are not by definition. 

In general, just use http features as little as possible. Caching is not at all helpful. Uri encoding is inferior to JSON structures.


Sent from my iPhone

> On Jun 13, 2015, at 6:24 PM, Stefan Bühler <acme@stbuehler.de>; wrote:
> 
> On Sat, 13 Jun 2015 21:24:41 +0000
> "Salz, Rich" <rsalz@akamai.com>; wrote:
>>> As it doesn't look like there is anyone interested in them on this
>>> mailing list I'll keep them to myself, or post them to github when
>>> I find the time.
>> 
>> No, please post here.
> 
> Ok, here we go:
> 
> * I don't see how a client would determine the /acme/revoke-cert URI,
>  it isn't part of any Link header as far as I could see. Perhaps it
>  should be part of the Link headers of the registration?
> 
> * Updates should use "PUT" instead of "POST", as they should be
>  idempotent
> 
> * When updating a registration sending empty "contact"/"agreement"
>  should actually reset them (if allowed) compared to not sending them,
>  which just retrieves the currently set values.
> 
>  I.e. posting {"contact":[]} should delete all contact information.
> 
> * All responses to successful updates should contain the same "Link"
>  headers as the creating request did.
> 
> * The "success" status code for updates should be documented. Right now
>  boulder always returns "202 Accepted".
> 
>  For challenges the spec says `The server provides a 200 response
>  including the updated challenge.`; boulder returns 202 anyway.
> 
> * simpleHttps: `The content type of the resource MUST be "text/plain"`
>  versus `4. Verify that the Content-Type header of the response is
>  either absent, or has the value "text/plain"`
> 
>  Is an absent Content-Type header ok or not?
> 
> * dvsni: Please don't require the domain name which is being validated
>  to be part of subjectAltName; configuring such certificate might
>  break a working setup in production, when it "wins" over an already
>  present and valid certificate for the domain.
> 
> * dvsni: Don't require it to be a self-signed certificate - what does it
>  matter who signed it?
> 
> * dvsni: `The public key is the public key for the key pair being
>  authorized`. I hope this was just an accident, this would be *really*
>  wrong to require.
> 
> I guess that the "dns" challenge type is probably not ready yet; but I
> suggest adding a "nodns" challenge which should be required in all
> combinations which don't include "dns": no any _acme-challenge TXT
> must be present.
> 
> Maybe another type "nodnssec" could also be added, to require DNSSEC in
> all combinations not including "dns" - so DNSSEC domains always have to
> be authorized by "dns" challenge.
> 
> Also I'd like to suggest making "dns" more powerful; for example making
> it possible to authorize accounts by public key and to authorize sub
> domains. Example:
> 
> _acme-challenge.example.com TXT "inherit:1 key-sha256:47DEQpj8HBSa-_TImW-5JCeuQeRkm5NMpJWZG3hSuFU="
> _acme-challenge.example.com TXT "token:17817c66b60ce2e4012dfad92657527a"
> 
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme