Re: [Anima] Content-Transfer-Encoding and HTTP 1.x in ANIMA BRSKI

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 17 June 2019 16:23 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73596120389 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 17 Jun 2019 09:23:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.9
X-Spam-Level:
X-Spam-Status: No, score=-2.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0dmo6g8hpPR for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 17 Jun 2019 09:23:53 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [IPv6:2603:400a:ffff:804:801e:34:0:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEDA01201DE for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 17 Jun 2019 09:23:35 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1hcuN4-0004ys-3k for ietf-http-wg-dist@listhub.w3.org; Mon, 17 Jun 2019 16:20:38 +0000
Resent-Date: Mon, 17 Jun 2019 16:20:38 +0000
Resent-Message-Id: <E1hcuN4-0004ys-3k@frink.w3.org>
Received: from mimas.w3.org ([2603:400a:ffff:804:801e:34:0:4f]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <mcr@sandelman.ca>) id 1hcuN0-0004xQ-Hl for ietf-http-wg@listhub.w3.org; Mon, 17 Jun 2019 16:20:34 +0000
Received: from relay.cooperix.net ([2a01:7e00::f03c:91ff:feae:de77] helo=relay.sandelman.ca) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <mcr@sandelman.ca>) id 1hcuMy-0001gY-Lj for ietf-http-wg@w3.org; Mon, 17 Jun 2019 16:20:33 +0000
Received: from dooku.sandelman.ca (unknown [75.98.19.133]) by relay.sandelman.ca (Postfix) with ESMTPS id A19C41F450; Mon, 17 Jun 2019 16:20:08 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 7DE563810; Mon, 17 Jun 2019 12:20:17 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Panos Kampanakis (pkampana)" <pkampana@cisco.com>
cc: Eliot Lear <lear@cisco.com>, Carsten Bormann <cabo@tzi.org>, Julian Reschke <julian.reschke@gmx.de>, "draft-ietf-pkix-est@ietf.org" <draft-ietf-pkix-est@ietf.org>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, Anima WG <anima@ietf.org>
In-reply-to: <BN7PR11MB25473A12F646FAC8C19C1118C9EF0@BN7PR11MB2547.namprd11.prod.outlook.com>
References: <32410.1560275231@localhost> <15839.1560351718@localhost> <8a538f76-787d-de13-97f1-16195daae8ce@gmx.de> <F896BCBC-6C32-4107-B4B5-C12617F81326@tzi.org> <AD4DC1AA-C332-4BC7-B095-0CDD30700B99@cisco.com> <909.1560436148@localhost> <BN7PR11MB25473A12F646FAC8C19C1118C9EF0@BN7PR11MB2547.namprd11.prod.outlook.com>
Comments: In-reply-to "Panos Kampanakis (pkampana)" <pkampana@cisco.com> message dated "Thu, 13 Jun 2019 17:18:30 -0000."
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:20:17 -0400
Message-ID: <8921.1560788417@dooku.sandelman.ca>
Received-SPF: pass client-ip=2a01:7e00::f03c:91ff:feae:de77; envelope-from=mcr@sandelman.ca; helo=relay.sandelman.ca
X-W3C-Hub-Spam-Status: No, score=-3.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1hcuMy-0001gY-Lj 3be9937d68c7af0ca50bb4778efa1df9
X-Original-To: ietf-http-wg@w3.org
Subject: Re: [Anima] Content-Transfer-Encoding and HTTP 1.x in ANIMA BRSKI
Archived-At: <https://www.w3.org/mid/8921.1560788417@dooku.sandelman.ca>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36724
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

> Now, I don’t know how other EST clients would act. There are many out
> there by now that we can’t safely tell if they would act up.
> The commercial and enterprise CAs I tested with interoped fine with
> the libest client and they were not all sending the CTE field. They
> payload was base64 though.

I didn't read this well enough before.

So effectively, the CTE header has effectively been dropped, but the payload
is now assumed to be base64, regardless.

This suggests that we can not use the CTE header as a signal.
One has to assume base64 encoded values for the RFC7030 end-points.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-