Re: [Anima] addressing Content-Type-Encoding errata on EST / RFC7030 --- relationship to BRSKI

[Michael Richardson <[e-mail]>]

Resending with correct LAMPS ML name of "SPASMS".

I have posted the draft
  https://datatracker.ietf.org/doc/draft-richardson-lamps-rfc7030est-clarify/

this morning.  It attempts to address the errata posted by Sean Turner in
2017 on RFC7030.  Specifically the use of Content-Type-Encoding (CTE) and
base64. You can see my other query to httpbis at:
  https://mailarchive.ietf.org/arch/msg/httpbisa/m4l4G_lHKfQVfSeAn7IxReUioD0

In doing BRSKI (draft-ietf-anima-bootstrapping-keyinfra) interop testing we
had a number of confusions about whether or things are base64 encoded, and if
they are always base64 encoded, why send the CTE header, and if BRSKI is
binary or base64 encoded!

Given that RFC7030 is somewhat well deployed, acting on the errata that Sean
Turner noted is a bit difficult!  (As a process thing, it's a problem that
his 2017 errata seems to have gone into /dev/null).

I am posting the core of the proposal at the bottom of this email.
It tries to leverage the Postel doctrine in a way.

Some questions/issues:

1) does this belong in secdispatch?

2) is this appropriate for LAMPS?

3) independant submission seems wrong.

4) ANIMA BRSKI needs to clarify things itself, and I will add a section on
   this, but I'm hesistant to add a normative reference here.
   I have an idea of appropriate text that I will post on Tuesday.
   Getting clarity here is really the most important thing for me.

5) I don't have a simple answer for the /csrattrs API. Maybe it needs to be solved
   by creating a new end point.  or it could be done with Accept: header.

ps: it's ironic to me, this is perhaps something that could also be solved
    by versioning the API in the URL.


   For the other three methods, when the client is aware that this is an
   amended server then it SHOULD send the POST request in binary form
   (DER-encoded), and omit the Content-Transfer-Encoding header.  How
   the client knows what kind of server it is dealing with is
   communicating with is detailed in the next section.

   An amended server, when it receives a request that has no Content-
   Transfer-Encoding header, or has a Content-Transfer-Encoding header
   with the "binary" attribute, MUST respond in the same binary format.

   When an amended server receives a request in CTE-base64 form, then it
   MAY respond in kind.  It is reasonable for a server to be configured
   to ignore or fail requests of this form, either via run-time
   configuration, or via a compile-time option.  A main reason to do
   this is to avoid a permutation that requires testing in the future
   when no legacy EST clients are expected to connect.




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

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