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

From: Alexey Melnikov via Datatracker <[email-masked]>
Date: Wed, 16 Oct 2019 03:51:21 -0700

Alexey Melnikov has entered the following ballot position for
draft-ietf-anima-bootstrapping-keyinfra-28: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for addressing my DISCUSS points.

Some comments below were still applicable to -27, but some might be out of date.

In 2.3.2:

   As explained in [RFC5280] section 7.4, a complete IRI SHOULD be in
   this extension, including the scheme, iauthority, and ipath.  As a
   consideration to constrained systems, this MAY be reduced to only the
   iauthority, in which case a scheme of "https://" and ipath of
   "/.well-known/est" is to be assumed, as explained in section
   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.

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

2.7.  Cloud Registrar

   If the pledge uses a well known URI for contacting a cloud registrar
   an Implicit Trust Anchor database (see [RFC7030]) MUST be used to
   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?

---

From: Michael Richardson <[email-masked]>
Date: Wed, 16 Oct 2019 20:23:53 +0200

> 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.

    > 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].

    > 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 <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-