Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf-acme-star-delegation-07: (with DISCUSS and COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Fri, 11 June 2021 16:58 UTC

Return-Path: <kaduk@mit.edu>
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 4D0D33A10CD; Fri, 11 Jun 2021 09:58:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Level:
X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.398, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=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 9GHI977g9okh; Fri, 11 Jun 2021 09:58:50 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 7DCED3A10C5; Fri, 11 Jun 2021 09:58:50 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 15BGwYSQ013109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 11 Jun 2021 12:58:39 -0400
Date: Fri, 11 Jun 2021 09:58:34 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Thomas Fossati <Thomas.Fossati@arm.com>
Cc: Yaron Sheffer <yaronf.ietf@gmail.com>, The IESG <iesg@ietf.org>, "draft-ietf-acme-star-delegation@ietf.org" <draft-ietf-acme-star-delegation@ietf.org>, "acme-chairs@ietf.org" <acme-chairs@ietf.org>, "acme@ietf.org" <acme@ietf.org>, "ynir.ietf@gmail.com" <ynir.ietf@gmail.com>, "rsalz@akamai.com" <rsalz@akamai.com>
Message-ID: <20210611165834.GY32395@kduck.mit.edu>
References: <161785721553.2892.15997097506064189797@ietfa.amsl.com> <79202B74-A6EB-4B5C-89FF-AF6D59BE236A@arm.com> <20210609225906.GS32395@kduck.mit.edu> <4FF8AAB5-4718-4D91-A8BC-F1D8F5D2F8AC@arm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <4FF8AAB5-4718-4D91-A8BC-F1D8F5D2F8AC@arm.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/g-aO_BuxP7PkEIpLahM3wAn4j0s>
Subject: Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf-acme-star-delegation-07: (with DISCUSS and COMMENT)
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: Fri, 11 Jun 2021 16:58:54 -0000

Hi Thomas,

Trimming to just the one part that needs a response other than "thanks"...

On Fri, Jun 11, 2021 at 08:54:17AM +0000, Thomas Fossati wrote:
> Hi Ben,
> 
> Thank you again for your comments; Yaron has just pushed -09 which
> should address most of them -- see below for the detail.
> 
> On 10/06/2021, 08:00, "Benjamin Kaduk" <kaduk@mit.edu> wrote:
> > Section 3
> >
> >    Although most of this document, and in particular Section 2 is
> >    focused on the protocol between the NDC and to IdO, the protocol does
> >    affect the ACME server running in the CA.  A CA that wishes to
> >    support certificate delegation MUST also support unauthenticated
> >
> > Is it correct to say "non-STAR certificate delegation" here?  (The
> > corresponding change needed to support STAR delegation would have been
> > done already to support non-delegated STAR issuance, if I understand
> > correctly.)
> 
> I don't think the observation is correct: STAR issuance does not require
> the server to support unauthenticated GET.  It is a feature that the
> client needs to request explicitly, and the server could refuse if it
> does not implement it -- or for any other reason.  (See Section 3.4 of
> RFC8739.)
> 
> Or have I misinterpreted your thought?

My thinking was something along the lines of "the new protocol mechanisms
in this document don't affect the CA operation for the STAR issuance case,
since the CA protocol mechanisms for the STAR case are specified in RFC
8739".  But you are also correct to say that in order to use the mechanisms
in this document the CA has to do/implement something that 8739 did not
require of it.  Since this text is not clearly about "new protocol
mechanisms" vs "actually using the protocol", I think you are correct and
we should leave the text as-is.

Thanks again for all the updates and explanations!

-Ben