Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Michael Richardson <[e-mail]>]

Max and Toerless, please search for your name.

Adam Roach via Datatracker <[e-mail]> wrote:
    > §2.1

    >> |            +------v-------+
    >> |            | (5) Enroll   |<---+ (non-error HTTP codes  )
    >> ^------------+              |\___/ (e.g. 201 'Retry-After')
    >> | Enroll     +------+-------+
    >> | Failure           |

    > I can't work out what a "Retry-After" would mean in a "201 Created" response.
    > As noted above, section 5.6 of this document does indicate the use of a
    > "Retry-After" header field with a 202 response, so I presume this diagram
    > should say 202?

Thank you. It should say 202.

    > ---------------------------------------------------------------------------

    > §5:

    >> BRSKI uses existing CMS message formats for existing EST operations.
    >> BRSKI uses JSON [RFC7159] for all new operations defined here, and
    >> voucher formats.

    > RFC 7159 has been obsoleted by RFC 8259.

updated.

    > ---------------------------------------------------------------------------

    > §5.2

    >> The pledge SHOULD include an [RFC7231] section 5.3.2 "Accept" header
    >> indicating the acceptable media type for the voucher response.  The

    > Nit: ..."Accept" header field indicating...

fixed.

    > ---------------------------------------------------------------------------

    > §5.5

    >> The Registrar SHOULD include an [RFC7231] section 5.3.2 "Accept"
    >> header indicating the response media types that are acceptable.  This

    > Nit: ..."Accept" header field indicating...

fixed.

    >> field and appropriate 'Accept header' field values from the physical

    > Nit: ...'Accept header field' values...

fixed.

    > ---------------------------------------------------------------------------

    > §5.6

    >> pledge would keep track of the appropriate Retry-After header values

    > Nit: "...Retry-After header field values..."

fixed.

    >> desired type or using the desired algorithms (as indicated by the
    >> Accept: headers, and algorithms used in the signature) cannot be

    > Nit: "...Accept: header fields, ..."

fixed.

    >> The voucher response format is as indicated in the submitted accept
    >> header or based on the MASA's prior understanding of proper format

    > Nit: "...Accept header field..."

fixed.

    > ---------------------------------------------------------------------------

    > §5.6

    >> {
    >> "ietf-voucher:voucher": {
    >> "nonce": "62a2e7693d82fcda2624de58fb6722e5",
    >> "assertion": "logging"
    >> "pinned-domain-cert": "base64encodedvalue=="
    >> "serial-number": "JADA123456789"
    >> }
    >> }

    > This JSON is syntactically invalid. Please run this example and all other
    > instances of JSON in this document through a validation tool.

I have moved all of our examples json into separate files in our directory so
that we can validate them better, and added the validation to the Makefile.
I see that "FALSE" is not valid, but "false" is.
Please note that we know we have to renumber the figures.

In the appendix, we have examples of the JSON that is inside the CMS.
These are from real examples, and we have the private keys so that implementors
can make sure they can produce the same outputs.

The pinned-domain-cert has base64 in it, and it's more than 60 characters
wide.  I noticed it wasn't wrapped at all in -22, and just fixed that to be
wrapped at 60 characters, but then, it isn't valid JSON, because it has
LF in the "".  I shall leave a note, but maybe you have a better suggestion here.

    > ---------------------------------------------------------------------------

    > §5.8:

    >> A MASA that returns a code 200 MAY also include a Location: header
    >> for future reference by the registrar.

    > Nit: "Location: header field"

    > Also, it's not 100% clear what the registrar would use this URI for. Please
    > explain in the document.

okay.

    > §5.8.1:

    >> Distribution of a large log is less than ideal.  This structure can
    >> be optimized as follows: Nonced or Nonceless entries for the same
    >> domainID MAY be truncated from the log leaving only the single most

    > Nit: "truncate" means to shorten something by removing only the beginning or
    > only the end. I believe that you mean "omitted" (here and elsewhere in this
    > section).

How about *abridged*? I also used omitted where it referred to a single entry.

    > ---------------------------------------------------------------------------

    > §6:

    >> In the BRSKI context, the EST "Content-Transfer-Encoding" header if
    >> present, SHOULD be ignored.  This header does not need to included.

    > Nit: "...header field, if present..."

    > Nit: "This header field does not..."

done.

    > ---------------------------------------------------------------------------

    > §8.1:

    >> This document extends the definitions of "est" (so far defined via
    >> RFC7030) in the "https://www.iana.org/assignments/well-known-uris/
    >> well-known-uris.xhtml" registry as follows:
    >>
    >> o  add /.well-known/est/requestvoucher (see Section 5.5 )
    >>
    >> o  add /.well-known/est/requestauditlog (see Section 5.7)

    > The .well-known registry does not contain sub-paths under the path
    > element that appears after ".well-known". I note that "est" has already
    > been registered by RFC 7030. There are a bunch of ways this can be
    > handled, the easiest of which would be a request for the IANA to add
    > this RFC alongside RFC 7030 to the entry for "est."

    > More complex solutions would be selecting a different path than
    > "est", or establishing a separate sub-registry for paths under
    > the "est" well-known path.

The response we got from Mark Nottingham was that this document would
have to Updates: RFC7030.
I'd rather not change the "est", but we could do that at this point.
Max?



    > ---------------------------------------------------------------------------

    > §8.4:

    >> Service Name: _brski-proxy
    > ...
    >> Service Name: _brski-registrar

    > You almost certainly don't want the service name to contain a leading
    > underscore. That is added as part of the DNS-SD resolution process, but
    > not part of the service name itself.

fixed.

    > ---------------------------------------------------------------------------

    > Appendix B:

    >> For example, if the first
    >> Multicast DNS _bootstrapks._tcp.local response doesn't work then the
    >> second and third responses are tried.

    > I got a little lost here. Where is the "bootstrapks" service defined?
    > I don't see it defined in this document or registered at
    > https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=bootstrapks

Toerless, can you help here?
I think that we renamed this.



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