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

[Adam Roach via Datatracker <[e-mail]>]

Adam Roach has entered the following ballot position for
draft-ietf-anima-bootstrapping-keyinfra-22: 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:
----------------------------------------------------------------------

Thanks to everyone who invested time in developing this mechanism.
I have two blocking comments that should be quite easy to resolve.

---------------------------------------------------------------------------

§5:

>  MASA URI is "https://" iauthority "/.well-known/est".

This doesn't make sense: iauthority is a component of IRIs, not of URIs. In
URIs this is simply an "authority." It's not simply a terminology distinction:
converting from an iauthority to an authority requires idna encoding. Please
consult with an IRI expert (which I do not consider myself to be) to work out
the proper terminology and procedures here.  If you need help finding an
expert, please let me know and I'll track someone down for you.

---------------------------------------------------------------------------

§5.8:

>  Rather than returning the audit log as a response to the POST (with a
>  return code 200), the MASA MAY instead return a 201 ("Created")
>  RESTful response ([RFC7231] section 7.1) containing a URL to the
>  prepared (and easily cachable) audit response.

The DISCUSS portion of my comment on this text is that it is unclear about how
the URL is to be returned. It can just as easily be interpreted as returning
it in a "Location" header field as it could as returning it in the response
body -- or maybe somewhere else entirely (e.g., a link relation).  This
ambiguity will cause an interop issue. Please be explicit about precisely how
the value is conveyed.

While not part of the DISCUSS, I also have a fairly serious comment on the
phrasing and citation of  "return a 201 ("Created") RESTful response
([RFC7231] section 7.1)". Section 7.1 points to the top-level discussion of
Control Data header fields, rather than any general discussion of RESTful
responses.  It's worth noting that the term "RESTful" never appears in RFC
7231, so it's really unclear what section this was attempting to target.
Perhaps 6.3.2?


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

I share Warren's discomfort with the models described in this document,
especially in the context of device viability after companies disappear or
change focus.  It's not clear that this an unintended side effect of the
model: much of the text around "legal ownership" seems aimed at subverting the
doctrine of first sale/rule of exhaustion, and congruent laws around the world.

While I sincerely appreciate the treatment of this issue in section 10.3, I
think the document really needs *normative* behaviors defined that address the
two issues of resale and device utility in a world where the device
manufacturer (as that term is defined in section 1.2) is no longer available,
rather than the high-level non-normative sketches currently provided for
future study.

In short, beyond the user-hostile effects of these two issues, I have
ethical issues with the IETF publishing a protocol that promotes the
unnecessary creation of e-waste; and, unless handled properly, that will
be the inevitable result of the two factors I cite above.

While this isn't part of my DISCUSS, I can't in good conscience ballot "No
Objection" to a document that doesn't normatively address those issues.  I
urge the authors and working group to add text that does so.  I do, however,
recognize that the prospect of this happening at this stage of the process is
vanishingly small. In the absence of such admittedly unlikely action, I plan
to Abstain after my DISCUSS issue has been addressed.

---------------------------------------------------------------------------

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

---------------------------------------------------------------------------

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

---------------------------------------------------------------------------

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

---------------------------------------------------------------------------

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

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

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

---------------------------------------------------------------------------

§5.6

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

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

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

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

---------------------------------------------------------------------------

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

With a reasonably modern version of nodejs, validation can be as simple as
something like:

node -e 'console.log(JSON.stringify(JSON.parse(`
  {
    "ietf-voucher:voucher": {
      "nonce": "62a2e7693d82fcda2624de58fb6722e5",
      "assertion": "logging"
      "pinned-domain-cert": "base64encodedvalue=="
      "serial-number": "JADA123456789"
    }
  }
`)));'

If the JSON is valid, you'll get no errors.

---------------------------------------------------------------------------

§5.7:

>  {
>    "version":"1",
>    "Status":FALSE /* TRUE=Success, FALSE=Fail"
>    "Reason":"Informative human readable message"
>    "reason-context": { additional JSON }
>  }

Please see https://tools.ietf.org/html/rfc8259#section-3 --

   A JSON value MUST be an object, array, number, or string, or one of
   the following three literal names:

      false
      null
      true

   The literal names MUST be lowercase.  No other literal names are
   allowed.

There are also a number of other syntax errors in this JSON example, even
setting aside the "additional JSON" indication.

---------------------------------------------------------------------------

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

---------------------------------------------------------------------------

§5.8.1:

>  {
>    "version":"1",
>    "events":[
>      {
>       "date":"<date/time of the entry>",
>       "domainID":"<domainID extracted from voucher-request>",
>       "nonce":"<any nonce if supplied (or the exact string 'NULL')>"
>       "assertion":"<the value from the voucher assertion leaf>"
>       "truncated":"<the number of domainID entries truncated>"
>      },
>      {
>       "date":"<date/time of the entry>",
>       "domainID":"<anotherDomainID extracted from voucher-request>",
>       "nonce":"<any nonce if supplied (or the exact string 'NULL')>"
>       "assertion":"<the value from the voucher assertion leaf>"
>      }
>    ],
>    "truncation": {
>       "nonced duplicates": "<total number of entries truncated>",
>       "nonceless duplicates": "<total number of entries truncated>",
>       "arbitrary": "<number of domainID entries removed entirely>"
>       }
>  }

This JSON is syntactically invalid. Please validate.

---------------------------------------------------------------------------

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

---------------------------------------------------------------------------

§5.9.4:

>  {
>    "version":"1",
>    "Status":TRUE /* TRUE=Success, FALSE=Fail"
>    "Reason":"Informative human readable message"
>    "reason-context": "Additional information"
>  }

This JSON is syntactically invalid. Please validate.


---------------------------------------------------------------------------

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

---------------------------------------------------------------------------

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

---------------------------------------------------------------------------

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

---------------------------------------------------------------------------

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