[Anima] BRSKI redirect Q (was: Re: chain of redirections for Cloud Registrar)

Toerless Eckert <tte@cs.fau.de> Mon, 14 June 2021 16:02 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCDCB3A2916 for <anima@ietfa.amsl.com>; Mon, 14 Jun 2021 09:02:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.347
X-Spam-Level:
X-Spam-Status: No, score=0.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_TRY_3LD=1.997] 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 8usz1-oxugIb for <anima@ietfa.amsl.com>; Mon, 14 Jun 2021 09:02:18 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99D8A3A2910 for <anima@ietf.org>; Mon, 14 Jun 2021 09:02:18 -0700 (PDT)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [131.188.34.51]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 4D37854806A; Mon, 14 Jun 2021 18:02:12 +0200 (CEST)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 452404E776E; Mon, 14 Jun 2021 18:02:12 +0200 (CEST)
Date: Mon, 14 Jun 2021 18:02:12 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Carsten Bormann <cabo@tzi.org>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, max pritikin <pritikin@cisco.com>, anima@ietf.org
Message-ID: <20210614160212.GA28552@faui48e.informatik.uni-erlangen.de>
References: <6572.1623550948@localhost> <B2AB9C25-FA39-43F2-A768-3B7544518B9D@tzi.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <B2AB9C25-FA39-43F2-A768-3B7544518B9D@tzi.org>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/-XfkKy-C5vKsqTutE4XmRKrafic>
Subject: [Anima] BRSKI redirect Q (was: Re: chain of redirections for Cloud Registrar)
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Jun 2021 16:02:23 -0000

Let me fork off a question:

AFAIK, a 307 redirect can redirect to any other location and not only
a different origin, e.g.:

GET https://mycloudreg.example.com/.well-known/brski/requestvoucher
  -> 307, Location: https://mycloudreg.example2.com/whatthecke/strangeurl

AFAIK, there is no text prohibiting this in rfc8995 (or for that
matter rfc7030).

I don't think such a redirect would work, because the pledge wouldn't know
what the URL for followup commands such as requestvoucher (or any EST
command) would be.

I can see how redirect to other URL prefies than .well-known might
be useful though, even without changing web origin, because some
more complex web server may be built that way, but effectively i
think EST and BRSKI can only work if the redirect location is
cnsistent in its last wo elements:

  GET https://mycloudreg.example.com/.well-known/brski/requestvoucher
  -> 307, Location: /<whatever>/brski/requestvoucher

In this case, the pledge would then extrapolate also
  GET https://mycloudreg.example.com/<whatever>/est/cacerts

Aka: assume both brski and es live under <whatever>

Yes/No/Maybe ?

Cheers
    toerless

On Sun, Jun 13, 2021 at 07:41:18AM +0200, Carsten Bormann wrote:
> On 13. Jun 2021, at 04:22, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> > 
> >  "another web origin" --- I guess I don't know what this means.
> 
> See RFC 6454 "The Web Origin Concept???.
> 
> In short, scheme + authority.
> 
> >   Does it mean redirecting from https://one.example/foo to https://two.example/bar,
> 
> Different origins https://one.example vs. https://two.example
> 
> >   or does it refer to https://one.example/foo to https://one.example/bar    etc.
> 
> Same origin https://one.example
> 
> I don???t like the term that much, but it is in wide use in the combination ???Same origin principle???.
> In RFC 7252, we use ???Origin server??? to identify the serving endpoint.
> (Of course, ???endpoint" has been hijacked as a needless synonym of ???resource??? in OAuth.)
> 
> Somebody should write a Web terminology glossary :-)
> 
> Grüße, Carsten
> 
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima

-- 
---
tte@cs.fau.de