[Anima-bootstrap] section 5.1 -- redirection

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 17 October 2016 13:47 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: anima-bootstrap@ietfa.amsl.com
Delivered-To: anima-bootstrap@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 72CFB129677 for <anima-bootstrap@ietfa.amsl.com>; Mon, 17 Oct 2016 06:47:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.332
X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id mBfoPw2Vxmor for <anima-bootstrap@ietfa.amsl.com>; Mon, 17 Oct 2016 06:47:06 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0E831294FB for <anima-bootstrap@ietf.org>; Mon, 17 Oct 2016 06:47:05 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4BC852009E for <anima-bootstrap@ietf.org>; Mon, 17 Oct 2016 10:01:36 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 714E963AFE for <anima-bootstrap@ietf.org>; Mon, 17 Oct 2016 09:47:04 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: anima-bootstrap <anima-bootstrap@ietf.org>
X-Attribution: mcr
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Mon, 17 Oct 2016 09:47:04 -0400
Message-ID: <7868.1476712024@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima-bootstrap/qXZ6hnjweGQ62tZHYHNoL0aa_Lo>
Subject: [Anima-bootstrap] section 5.1 -- redirection
X-BeenThere: anima-bootstrap@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list for the bootstrap design team of the ANIMA WG <anima-bootstrap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima-bootstrap>, <mailto:anima-bootstrap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima-bootstrap/>
List-Post: <mailto:anima-bootstrap@ietf.org>
List-Help: <mailto:anima-bootstrap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima-bootstrap>, <mailto:anima-bootstrap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Oct 2016 13:47:07 -0000

Max, I'm doing the minutes, and I'm trying to explain the confusion we had
over the various objects by connecting to the real text, and I came across this.

Section 5.1 includes the text:

   As indicated in EST [RFC7030] the bootstrapping server can redirect
   the client to an alternate server.  If the New Entity authenticated
   the Registrar using the well known URI method then the New Entity
   MUST follow the redirect automatically and authenticate the new
   Registrar against the redirect URI provided.  If the New Entity had
   not yet authenticated the Registrar because it was discovered and
   was not a known-to-be-valid URI then the new Registrar must be
   authenticated using one of the two autonomic methods described in
   this document.  Similarly the Registar MAY respond with an HTTP 202
   ("the request has been accepted for processing, but the processing
   has not been completed") as described in EST [RFC7030] section 4.2.3.

I'm trying to understand how/when the New Entity would authenticate the
registrar using the well known URI.  Is this for some form of mitigation,
where the new entity does not (can not) do all of the proxy steps and a human
helps via craft console?  Or is this part of the rekey state machine?

Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-