Subject: [Anima] Alexey Melnikov's Discuss on draft-ietf-anima-bootstrapping-keyinfra-26: (with DISCUSS and COMMENT)

From: Alexey Melnikov via Datatracker <[email-masked]>
Date: Mon, 16 Sep 2019 09:22:26 -0700

Alexey Melnikov has entered the following ballot position for
draft-ietf-anima-bootstrapping-keyinfra-26: Discuss

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/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thank you for this document. Despite comments/DISCUSSes raised, this was a good
read.

I agree with DISCUSS points from Alissa, Adam and Roman.

1) Resolved

2) Resolved

3) Resolved

4) In 5.8.1:

Format of different fields is not defined in enough details, so this is not
interoperable. Please specify what format is used for dates and nonces.

5) Resolved

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

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

The first mention of HTTP 1.1 needs a Normative reference.

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: Mon, 16 Sep 2019 15:11:16 -0400

https://tinyurl.com/y2kmjqmm for diff.

    > interoperable. Please specify what format is used for dates and nonces.

Date now references rfc3339. (Why doesn't rfc8259 reference 3339?)

          <t>
            The date is in <xref target="RFC3339" /> format, which is
            consistent with typical JavaScript usage of JSON.
          </t>

          <t>
            The nonce is a string, as provided in the voucher-request, and
            used in the voucher.   If no nonce was placed in the resulting
            voucher, then a value of null SHOULD be used in preference to
            omitting the entry.
            While the nonce is often created as a base64 encoded random
            series of bytes, this should not be assumed.
          </t>

    > The first mention of HTTP 1.1 needs a Normative reference.

We now refer to HTTP persistent connections, and reference RFC7230 section 6.3.

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

    > the need to use SHOULD and MAY above.

The field contains either:
    authority
OR
    scheme //: authority / path

As "/" is not legal in authority, which can be deduced, as explained:

   The registrar can assume that only the 'authority' is present in the
   extension, if there are no slash ("/") characters in the extension.

I'm not sure that ABNF would make it clearer to implementers.

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

Now references rfc7230 section 2.7.3

    > b) are wildcards allowed in any of these?

I don't know, as we haven't defined how the cloud register would work, and
did not intend to define that in this document.
A very drafty draft, draft-friel-anima-brski-cloud-00 has recently been posted.

The only reason we talk about this at all, is that we can it clear how this
option would fit into the pledge state machine.  We also say this because we
want to make sure that a built-in trust anchor is used, and not some trust
anchor that might have been received provisionally, or via the /cacerts
EST method.

The pledge would contain the logic to connect, and would know what name to
use, and would know how to validate it.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-