IETF Logo Mail Archive

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 11 July 2019 20:02 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 8A5C212013B; Thu, 11 Jul 2019 13:02:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 Gtuy72QDoaSI; Thu, 11 Jul 2019 13:02:03 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B25F120155; Thu, 11 Jul 2019 13:02:02 -0700 (PDT)
Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 282493818F; Thu, 11 Jul 2019 15:59:56 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 709994E9; Thu, 11 Jul 2019 16:02:01 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Adam Roach <adam@nostrum.com>
cc: The IESG <iesg@ietf.org>, draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert <tte+ietf@cs.fau.de>, anima-chairs@ietf.org, anima@ietf.org
In-Reply-To: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com>
References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com>
X-Mailer: MH-E 8.6; nmh 1.7+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-sha256"; protocol="application/pgp-signature"
Date: Thu, 11 Jul 2019 16:02:01 -0400
Message-ID: <19180.1562875321@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/vo-lF0cQ6eGtC5dGf2c90-rV3aQ>
Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
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: Thu, 11 Jul 2019 20:02:06 -0000

Adam Roach via Datatracker <noreply@ietf.org> wrote:
    > §5:

    >> MASA URI is "https://" iauthority "/.well-known/est".

    > This doesn't make sense: iauthority is a component of IRIs, not of URIs. In
    > URIs this is simply an "authority." It's not simply a terminology distinction:
    > converting from an iauthority to an authority requires idna encoding. Please
    > consult with an IRI expert (which I do not consider myself to be) to work out
    > the proper terminology and procedures here.  If you need help finding an
    > expert, please let me know and I'll track someone down for you.

okay, this one is my fault.
I agree, we should have consulted an expert.  I thought I was being clever.
Please, can you find us an expert, if you think we should go this direction.

I thought IRIs were supersets of URIs, and that all URIs were IRIs, and the
only reason to RFC3987 instead of RFC3986 is because one might have legacy
systems that couldn't handle idna.  Since I thought we had a greenfield here,
I figured we could specify the superset.

I can easily make this "authority" and RFC3986.
Please advise.

Some background: this text is slightly new, and is the result of interop
failures.   I had placed "https://example.com/" in the certificate, while
another implementer placed "example.com:9443/.well-known/est" in, assuming that
"https:" was naturally implied.

So, we disagreed what the base was, and we then agreed that there were
sometimes reasons to include the the entire URL, but that less is better.
We then looked for what the term for the "hostname:port" part was, and
found 3986 and 3987.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [





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

v2.23.0 | Report a Bug | By Email