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

[Alexey Melnikov via Datatracker <[e-mail]>]

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?