IETF Logo Mail Archive

Re: [lamps] [Anima] /.well-known/brski reference to brski-registry

Benjamin Kaduk <kaduk@mit.edu> Tue, 05 April 2022 17:32 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5613F3A0DCD; Tue, 5 Apr 2022 10:32:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham 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 FI2-YqOxWrMk; Tue, 5 Apr 2022 10:32:09 -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 EC29E3A0DA2; Tue, 5 Apr 2022 10:32:08 -0700 (PDT)
Received: from mit.edu (c-73-169-244-254.hsd1.wa.comcast.net [73.169.244.254]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 235HVotx002052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 5 Apr 2022 13:31:56 -0400
Date: Tue, 5 Apr 2022 10:31:50 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Sean Turner <sean@sn3rd.com>
Cc: "Brockhaus, Hendrik" <hendrik.brockhaus@siemens.com>, Roman Danyliw <rdd@cert.org>, Robert Wilton <rwilton@cisco.com>, "david.von.oheimb@siemens.com" <david.von.oheimb@siemens.com>, John Gray <John.Gray@entrust.com>, Russ Housley <housley@vigilsec.com>, "spasm@ietf.org" <spasm@ietf.org>, Mark Nottingham <mnot@mnot.net>, "Fries, Steffen" <steffen.fries@siemens.com>, Michael Richardson <mcr+ietf@sandelman.ca>, "anima@ietf.org" <anima@ietf.org>
Message-ID: <20220405173150.GX13021@mit.edu>
References: <30686.1648741661@localhost> <DB6PR1001MB12691C71E28CF3AEB4603368FEE19@DB6PR1001MB1269.EURPRD10.PROD.OUTLOOK.COM> <4ACC1227-F79D-42B8-B050-07FB0C2BC86A@vigilsec.com> <DB6PR1001MB1269630A63DBF8DF02BCCB6DFEE09@DB6PR1001MB1269.EURPRD10.PROD.OUTLOOK.COM> <E2286164-E5F8-4563-BC69-C34B6D18B687@sn3rd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <E2286164-E5F8-4563-BC69-C34B6D18B687@sn3rd.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/BXwATtatndjfIFxorHY7nHuL6mk>
X-Mailman-Approved-At: Tue, 05 Apr 2022 11:33:54 -0700
Subject: Re: [lamps] [Anima] /.well-known/brski reference to brski-registry
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2022 17:32:14 -0000

On Sun, Apr 03, 2022 at 10:36:01PM -0400, Sean Turner wrote:
> 
> 
> > On Apr 1, 2022, at 02:25, Brockhaus, Hendrik <hendrik.brockhaus@siemens.com> wrote:
> > 
> > 
> >> Von: Russ Housley <housley@vigilsec.com>
> >> Gesendet: Donnerstag, 31. März 2022 19:53
> >> 
> >>> On Mar 31, 2022, at 12:20 PM, Brockhaus, Hendrik
> >> <hendrik.brockhaus@siemens.com> wrote:
> >>> 
> >>> Thank you Michael for rising the questions.
> >>> 
> >>>> Von: Anima <anima-bounces@ietf.org> Im Auftrag von Michael Richardson
> >>>> Gesendet: Donnerstag, 31. März 2022 17:48
> >>>> 
> >>>> 
> >>>> We were discussing the /.well-known/cmp that is in being proposed in
> >>>> draft-ietf- lamps-cmp-updates, We were comparing it to
> >>>> /.well-known/brski and /.well- known/est.
> >>>> 
> >>>> Question 2)
> >>>>  Should the CMP document be establishing a registry or not?
> >>>> 
> >>> As discussed during IETF 113 I plan to do these things in CMP Updates
> >>> - register 'cmp' in the "Well-Known URIs" registry
> >>> - define a protocol registry group "Certificate Management Protocol (CMP)"
> >>> - define a registry for "CMP Well-Known Arbitrary Label URI Segments"
> >> defining 'p' to be followed by a <profileLabel>.
> >>> In addition I would define a registry for "CMP Well-Known Operation Label URI
> >> Segments" in Lightweight CMP Profile containing the path segments defined
> >> three for http and coap use.
> >>> 
> >>> Does this makes sense?
> >> 
> >> Hendrik:
> >> 
> >> That is consistent with the discussion lat week.
> >> 
> >> Russ
> > 
> > Would it also be sufficient to have only one additional registry "CMP Well-Known URI Path Segments" containing the arbitrary label 'p' and the operation labels?
> > 
> > Hendrik
> 
> When the /.well-known/est/ was registered we only did the top level, i.e., /est/. There are no registries for the /.well-known/est/*this part*.  It’s not clear to me that you need to do anything more than get /.well-known/cmp.
> 
> What will be the registration policy [0] for the ‘p’ values? I assume FCFS (first come first served)?

I had assumed that we were just registering the value 'p' in a single
combined registry of CMP operations and path labels, but that the stuff
after 'p' was site-local and did not need to be registered.  (Though a FCFS
registry for them is not wrong.)

-Ben

v2.8.7 | Report a Bug | By Email