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

Michael Richardson <> Mon, 17 June 2019 16:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D1687120136; Mon, 17 Jun 2019 09:58:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ak2LfH9lnilV; Mon, 17 Jun 2019 09:58:17 -0700 (PDT)
Received: from ( [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3FAE41200E3; Mon, 17 Jun 2019 09:58:16 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTPS id C6E941F450; Mon, 17 Jun 2019 16:58:14 +0000 (UTC)
Received: by (Postfix, from userid 179) id CB0EF3810; Mon, 17 Jun 2019 12:58:24 -0400 (EDT)
From: Michael Richardson <>
In-reply-to: <>
References: <> <>
Comments: In-reply-to Michael Richardson <> message dated "Mon, 17 Jun 2019 12:31:52 -0400."
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Mon, 17 Jun 2019 12:58:24 -0400
Message-ID: <>
Archived-At: <>
Subject: Re: [Anima] addressing Content-Type-Encoding errata on EST / RFC7030 --- relationship to BRSKI
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 17 Jun 2019 16:58:20 -0000

Resending a third time, with correct LAMPS ML name of "SPASM" (no trailing
S!).  My sincere appologies.

I have posted the draft

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:

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

Michael Richardson <>, Sandelman Software Works
 -= IPv6 IoT consulting =-

[[End of PGP Signed Part]]
Anima mailing list

Michael Richardson <>, Sandelman Software Works
 -= IPv6 IoT consulting =-