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

Jim Schaad <> Wed, 19 June 2019 01:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E5BEB12034A; Tue, 18 Jun 2019 18:15:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id evIzwroXg_KC; Tue, 18 Jun 2019 18:15:08 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 771E31201F3; Tue, 18 Jun 2019 18:15:08 -0700 (PDT)
Received: from Jude ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 18 Jun 2019 18:15:02 -0700
From: Jim Schaad <>
To: 'Michael Richardson' <>,,
References: <> <> <>
In-Reply-To: <>
Date: Tue, 18 Jun 2019 18:15:00 -0700
Message-ID: <040a01d5263c$6c51efa0$44f5cee0$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJb28LO5lo2KeiH1QNaqQhKxPp0VgIQkln/AZkBSSGld1fWQA==
Content-Language: en-us
X-Originating-IP: []
Archived-At: <>
Subject: Re: [Anima] [lamps] 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: Wed, 19 Jun 2019 01:15:11 -0000

-----Original Message-----
From: Spasm <> On Behalf Of Michael Richardson
Sent: Monday, June 17, 2019 9:58 AM
Subject: Re: [lamps] [Anima] addressing Content-Type-Encoding errata on EST
/ RFC7030 --- relationship to BRSKI

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?
[JLS] I would say yes if only because that is the "new process" that is
being used.

2) is this appropriate for LAMPS?
[JLS] If I was running secdispatch this is where I would send it.

3) independant submission seems wrong.
[JLS] An Individual submission would be ok (direct to AD).  However an
Independent submission is a complete non-starter.  Cannot update a standards
track document via the ISE.


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
   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 =-