Re: [Acme] [Technical Errata Reported] RFC8555 (5979)

"Salz, Rich" <rsalz@akamai.com> Wed, 12 February 2020 15:14 UTC

Return-Path: <rsalz@akamai.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 DA4201200E7 for <acme@ietfa.amsl.com>; Wed, 12 Feb 2020 07:14:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 b9v-VNHYJdz4 for <acme@ietfa.amsl.com>; Wed, 12 Feb 2020 07:14:30 -0800 (PST)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 7D9ED1200A3 for <acme@ietf.org>; Wed, 12 Feb 2020 07:14:30 -0800 (PST)
Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 01CFD5Z3005396; Wed, 12 Feb 2020 15:14:26 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=be3d+WsVeYRygBWbt2zhPw+A4pkxDtnTfJ/J3VFNsDE=; b=aV4moqZTBtzQojDAOMCBtIWvnV0fxyBl0XfykLaxTw0fQwJxvvmIX8vRJ/aYYu7tg9Z7 nCLQdV0servSoWp7qjPxVly0+FtxDaVswEOZ0AJHHYdFiSklt+Pgn7W+NFQhV3ZacQh4 QQuGvz9/1ZjNW/vYfeqoenBUzyq9EaByz4zj0PQOf34vHbiKkImXT0I3L9uB9AxDKDSL lZ5p4hm8YxIy1kvDcmTdjUH547VKdTJEUT+JaKYZ2T/4oSQ9nmACnEIXei7CYJcxYPxn zfFXZ2Psp0WD9fqcZJDPA/UaJS22K9nAL8/i+d1ySxkC6E/nk+uj9uWv10y0ypg8/jIo CQ==
Received: from prod-mail-ppoint3 (prod-mail-ppoint3.akamai.com [96.6.114.86] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2y457tat5e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 12 Feb 2020 15:14:25 +0000
Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 01CF2PQB024081; Wed, 12 Feb 2020 10:14:24 -0500
Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint3.akamai.com with ESMTP id 2y1s72tuh6-9 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 12 Feb 2020 10:14:06 -0500
Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 12 Feb 2020 10:12:08 -0500
Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Wed, 12 Feb 2020 10:12:08 -0500
From: "Salz, Rich" <rsalz@akamai.com>
To: Richard Barnes <rlb@ipv.sx>, RFC Errata System <rfc-editor@rfc-editor.org>
CC: Jacob Hoffman-Andrews <jsha@eff.org>, Daniel McCarney <cpu@letsencrypt.org>, James Kasten <jdkasten@umich.edu>, Roman Danyliw <rdd@cert.org>, Benjamin Kaduk <kaduk@mit.edu>, Yoav Nir <ynir.ietf@gmail.com>, "jonathan@findmeon.com" <jonathan@findmeon.com>, IETF ACME <acme@ietf.org>
Thread-Topic: [Technical Errata Reported] RFC8555 (5979)
Thread-Index: AQHV4SVPuDUy37EKE025UefMBMIlG6gXLzyAgAB8DYA=
Date: Wed, 12 Feb 2020 15:12:07 +0000
Message-ID: <ED53B334-3E71-4501-A1F8-F40C43A6E884@akamai.com>
References: <20200211214847.E0E30F40709@rfc-editor.org> <CAL02cgSaD8y87Sb=FubN14P=5=sXCqNeNSLP9qGgL7dSyYWsZg@mail.gmail.com>
In-Reply-To: <CAL02cgSaD8y87Sb=FubN14P=5=sXCqNeNSLP9qGgL7dSyYWsZg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.22.0.200209
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.117.63]
Content-Type: multipart/alternative; boundary="_000_ED53B3343E714501A1F8F40C43A6E884akamaicom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-12_08:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2002120117
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-12_08:2020-02-11, 2020-02-12 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 spamscore=0 clxscore=1011 priorityscore=1501 impostorscore=0 malwarescore=0 bulkscore=0 mlxscore=0 phishscore=0 adultscore=0 mlxlogscore=999 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2002120118
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/Esz-nKU384hpSiNNbBkGlzisE3A>
X-Mailman-Approved-At: Wed, 12 Feb 2020 07:51:12 -0800
Subject: Re: [Acme] [Technical Errata Reported] RFC8555 (5979)
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: Wed, 12 Feb 2020 15:14:33 -0000

I agree.

From: Richard Barnes <rlb@ipv.sx>
Date: Tuesday, February 11, 2020 at 9:49 PM
To: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: Jacob Hoffman-Andrews <jsha@eff.org>, "cpu@letsencrypt.org" <cpu@letsencrypt.org>, James Kasten <jdkasten@umich.edu>, Roman Danyliw <rdd@cert.org>, Benjamin Kaduk <kaduk@mit.edu>, Rich Salz <rsalz@akamai.com>, Yoav Nir <ynir.ietf@gmail.com>, "jonathan@findmeon.com" <jonathan@findmeon.com>, "acme@ietf.org" <acme@ietf.org>
Subject: Re: [Technical Errata Reported] RFC8555 (5979)

ADs: This seems like a nice clarification, but not really an error.  Suggest HFDU.

On Tue, Feb 11, 2020 at 4:49 PM RFC Errata System <rfc-editor@rfc-editor.org<mailto:rfc-editor@rfc-editor.org>> wrote:
The following errata report has been submitted for RFC8555,
"Automatic Certificate Management Environment (ACME)".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5979<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_errata_eid5979&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=MMQj9_sfha5evr4GH273LeuhOmY6tvtBrC1WMtBe5IQ&s=xy31cbf-zGvz2x7X2PVMRXH5DbioSjZwYbPYLlytw3U&e=>

--------------------------------------
Type: Technical
Reported by: jonathan vanasco <jonathan@findmeon.com<mailto:jonathan@findmeon.com>>

Section: 7.4

Original Text
-------------
 If the server is willing to issue the requested certificate, it
   responds with a 201 (Created) response.  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.



Corrected Text
--------------
 If the server is willing to issue the requested certificate, it
   responds with a 201 (Created) response.  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 server returns an order URL in a Location header field.


Notes
-----
The RFC does not specify/require where the "order URL" is presented.  The RFC is very explicit about where other URLs are obtained, and the common understanding is that the URL appears in a Location header after a new-order.

For example:

In 7.3; 7.3.1; 7.3.5, the RFC explicitly declares the account URL is in the Location header field.

In 7.4.1 the RFC is explicit that authorization URLs in pre-authorization appear in the Location header field.

But the order URL is only mentioned by example:

In 7.4, the RFC illustrates the order URL appearing in the Location header field (All clients seem to implement this).  In 7.1, the RFC shows a table with "a typical sequence of requests" that note the "account" and "order" URLs appear in the location header field.

The specification should state something to the effect of "The server returns an order URL in a Location header field." making this functionality explicit.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC8555 (draft-ietf-acme-acme-18)
--------------------------------------
Title               : Automatic Certificate Management Environment (ACME)
Publication Date    : March 2019
Author(s)           : R. Barnes, J. Hoffman-Andrews, D. McCarney, J. Kasten
Category            : PROPOSED STANDARD
Source              : Automated Certificate Management Environment
Area                : Security
Stream              : IETF
Verifying Party     : IESG