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

[Ted Hardie <[e-mail]>]

Howdy,

On Thu, Jul 11, 2019 at 1:02 PM Michael Richardson <[e-mail]>
wrote:

>
> Adam Roach via Datatracker <[e-mail]> 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.
>
> It is correct that all IRIs are URIs, but the core purpose of the IRI was
to be a presentation format.  The presumption was that you turn it into
wire-format (that is a URI) whenever you passed it to the protocol
machinery that were going to retrieve a resource or take some other action
over the network.  For something that is already a URI, this is a null
transform.  For everything else, there's a set of steps in 3987, which
includes ToASCII for ireg-name components which are domain names.

I would personally not suggest using IRIs here, given that the scheme
(https) is expected to retrieve a resource at a well-known location and
thus will always have to be mapped to a URI to do the retrieval (rather
than used in a string comparison or something similar) .   RFC 5280, which
this cites, actually goes through the steps pretty well, and I think the
complexity there demonstrates the advantage for constrained devices of
always using the URI form.

Just a personal opinion, obviously, and I also would not class myself as an
expert here.

Ted


> 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   [
> ]     [e-mail]  http://www.sandelman.ca/        |   ruby on
> rails    [
>
>
>
>
>
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
>