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

[Michael Richardson <[e-mail]>]

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

Alexey Melnikov via Datatracker <[e-mail]> wrote:
    > ----------------------------------------------------------------------
    > 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.

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>


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

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.

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

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

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