Re: [Ace] Embedded Content Types

"Panos Kampanakis (pkampana)" <> Wed, 20 February 2019 21:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AFCC112D4EA; Wed, 20 Feb 2019 13:33:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yHnDa4FVV1-3; Wed, 20 Feb 2019 13:33:44 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7197412D4E7; Wed, 20 Feb 2019 13:33:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3725; q=dns/txt; s=iport; t=1550698424; x=1551908024; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=mmJEpI+KE1zKqo1QW1R3vEL5qrPznD3gh+LkeMcdyyc=; b=UkEqdhLlKjqLWCraANJx/gAzmS5gjiByJfwVGD9PZcDt27yd+3oPnn7q GLXRaRKwwKILijZuXppnsriS8RcXDrqBaQDWT6//55HXXDE/QVUOYmQIC 1/AByydhy+/axqQ+1tOpwltucQHdFauQwR7oojdMMaBErWEwyQSoF4k/J A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAACWxm1c/4cNJK1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgVQFKmeBAycKjBeNdpgcgXsLAQEYC4R?= =?us-ascii?q?JAoN0IjQJDQEDAQECAQECbRwMhUoBAQEEAQE4NAsMBAIBCA4DBAEBDRIQJws?= =?us-ascii?q?dCAEBBAENBQgTgwaBcg+saRqCVYQzAgELQ4UoBYwnHReBQD+BEYIUfoMeAQG?= =?us-ascii?q?HQQKKOJkUCQKHOosWIZMGikeFTYw3AhEUgSgfOIFWcBU7gmyDPwECh1yFP0E?= =?us-ascii?q?xAY5rgR8BAQ?=
X-IronPort-AV: E=Sophos;i="5.58,392,1544486400"; d="scan'208";a="525099470"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Feb 2019 21:33:43 +0000
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id x1KLXhHk017287 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Feb 2019 21:33:43 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 20 Feb 2019 15:33:42 -0600
Received: from ([]) by ([]) with mapi id 15.00.1395.000; Wed, 20 Feb 2019 15:33:42 -0600
From: "Panos Kampanakis (pkampana)" <>
To: Jim Schaad <>, "" <>, "Klaus Hartke" <>
CC: "" <>
Thread-Topic: [Ace] Embedded Content Types
Thread-Index: AdTJQwabXPaUkoDzRkqcz/D5vJfkVwAH1C+A
Date: Wed, 20 Feb 2019 21:33:42 +0000
Message-ID: <>
References: <02a201d4c945$eb10a510$c131ef30$>
In-Reply-To: <02a201d4c945$eb10a510$c131ef30$>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Ace] Embedded Content Types
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 20 Feb 2019 21:33:47 -0000

Hi Jim,

Thank you. Sorry I couldn't make it to the CORE interim meeting. 

I see the challenge with content-format ID explosion in option c. So I agree that in the long run, there needs to be a long-term solution and option b seems the best for the general case.

There are challenges with option b and EST-coaps though. If we broke the requests to different URIs, it means that a client needs to keep track of his transactions and on top of it he needs to correlate the key and the cert he receives at a later time. So, after pulling the two URIs he has to cryptographically confirm the key is tied to the certificate. Additionally, this deviates from the logic of the EST protocol which we are trying to profile on. We are adding new APIs to the protocol. 

Because of these challenges, I would like to use option c in the ETS-coaps draft. It is not violating RFC7252 and it does not affect the long term plan (option b) either. There are only to content types we are talking about in EST-coaps, a key and a cert. A key can be encrypted or not. A cert can be in PKCS#7 or plain pkix-cert. That makes four combinations. The number cannot explode further, so we could live with it in this context.

Any strong objections?


-----Original Message-----
From: Ace <> On Behalf Of Jim Schaad
Sent: Wednesday, February 20, 2019 12:59 PM
Subject: [Ace] Embedded Content Types

The CoRE working had an interesting virtual meeting this morning (my time) where the main topic of discussion was how to deal with embedded content types.  This is a current problem that needs to be addressed with the EST document which is currently trying to deal with last call comments.  The log from the meeting can be found at

The takeaway from this that I got was:
1.  There is a real problem and we need to figure out the best ways to try
and deal with this in a generic manner.   This is a problem not only here,
but it the Publish/Subscribe CoRE document and in many other cases that we can see.

2.  We are not going to get a general solution immediately so EST needs to look at  doing something now.

3.  A couple of different possibilities where discussed that could be used:
a)  Return a list of links rather than a multipart content and let the client sort through that list and download the things that they want.  This is a purely reactive solution.
b) Use a different URI to ask for the different options.  This could be done either by the use of a different URI path or by the use of a query parameter.
c) Register a different content type for each of the possible return values.

There was a general preference for the use of a different URI as being the solution that should be used today.  The idea of registering multiple content types was generally disliked as it does not really extend well.
There was no specific preference on whether the use of a different URI path or a query parameter would be preferred.  The use of a different URI would allow for better discovery of capabilities.  

The idea of listing nested content types in the 'ct' link type was also universally disliked.

The CoRE, T2TRG and other forums are expected to continue discussions on this topic in different contexts such as Pub-Sub and CoRAL. To come up with both proactive and reactive solutions to the more general problem.


Ace mailing list