Re: [Anima] Alexey Melnikov's No Objection on draft-ietf-anima-bootstrapping-keyinfra-28: (with COMMENT)

[Michael Richardson <[e-mail]>]

Alexey Melnikov via Datatracker <[e-mail]> wrote:
    > Some comments below were still applicable to -27, but some might be out of date.

    > In 2.3.2:

(I've updated the text below from the -28 version, which does not use IRLs)

   doc> A complete URI MAY be in this extension, including the 'scheme',
   doc> 'authority', and 'path', The complete URI will typically be used in
   doc> diagnostic or experimental situations.  Typically, (and in
   doc> consideration to constrained systems), this SHOULD be reduced to only
   doc> the 'authority', in which case a scheme of "https://" ([RFC7230]
   doc> section 2.7.3) and 'path' of "/.well-known/est" is to be assumed, as
   doc> explained in Section 5.

    > This is not a problem per se, but mixing absolute URIs and iauthority in the
    > same field makes me rather uncomfortable. Maybe you can define ABNF for this
    > field to make it crystally clear what is allowed here. This would also avoid
    > the need to use SHOULD and MAY above.

The above reference to section 5 is vague, and I think it has gone lame, and
I've removed it.  There is a single sentence in 5.0 that probably used to say more.

The logic here (on the Registrar):
  if(strchr(text, '/')) {
    /* WHOLE URL is present */
    url = text;
  } else
    snprintf(somebuffer, sizeof(somebuffer),
                   "https://%s/.well-known/est", text);
    url = somebuffer;
  }

ruby:
  def self.canonicalize_masa_url(url)
    return nil unless url
    if !url.blank? and !url.include?("/")
      url = "https://" + url + "/.well-known/est/"
    end
    # always have a trailing /
    unless url[-1]=='/'
      url = url + '/'
    end
    url
  end

I'll have to think about how to explain this in ABNF.  I would need to
reference the RFC7230 ABNF and create some hybrid item.  It seems like a lot.

    > In 2.3.2: "https" URI scheme needs a Normative reference.

I think that the new text deals with this already.

    > 2.7.  Cloud Registrar

    doc> If the pledge uses a well known URI for contacting a cloud registrar
    doc> an Implicit Trust Anchor database (see [RFC7030]) MUST be used to
    doc> authenticate service as described in [RFC6125].

    > Just referencing RFC 6125 is not clear enough, as there are lots of parameters
    > that need to be specified:

    > a) which of CN-ID/DNS-ID/URI-ID/SRV-ID are allowed
    > b) are wildcards allowed in any of these?

I've added text:n
      The use of a DNS-ID for validation is
      appropriate, and it may include wildcard compnents on the
      left-mode side.

{i.e. what browsers and curl does.  I feel that surely this must be specified
somewhere more precisely?}

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-