Re: [Anima] Content-Transfer-Encoding and HTTP 1.x in ANIMA BRSKI
Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 20 June 2019 16:04 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 A3F39120124 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 20 Jun 2019 09:04:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.898
X-Spam-Level:
X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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 7j956WBy9-yp for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 20 Jun 2019 09:04:56 -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 232A2120123 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 20 Jun 2019 09:04:54 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1hdzWG-0008Hw-OI for ietf-http-wg-dist@listhub.w3.org; Thu, 20 Jun 2019 16:02:36 +0000
Resent-Message-Id: <E1hdzWG-0008Hw-OI@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 <ylafon@w3.org>) id 1hdzWD-0008H4-QT for ietf-http-wg@listhub.w3.org; Thu, 20 Jun 2019 16:02:33 +0000
Received: from raoul.w3.org ([128.30.52.128]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <ylafon@w3.org>) id 1hdzWC-0002VB-11 for ietf-http-wg@w3.org; Thu, 20 Jun 2019 16:02:33 +0000
Received: from platy.fdn.fr ([80.67.176.7] helo=[192.168.1.129]) by raoul.w3.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <ylafon@w3.org>) id 1hdzWB-0002eK-IF for ietf-http-wg@w3.org; Thu, 20 Jun 2019 16:02:31 +0000
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Content-Type: multipart/alternative; boundary="Apple-Mail=_31E69A16-9827-4894-A49A-38A0C2BC0B04"
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Resent-From: Yves Lafon <ylafon@w3.org>
In-Reply-To: <8a538f76-787d-de13-97f1-16195daae8ce@gmx.de>
Date: Wed, 12 Jun 2019 20:50:28 +0000
Resent-Date: Thu, 20 Jun 2019 18:02:30 +0200
Message-Id: <9fcce3cd-c3cb-bd60-a55c-af21da621b88@gmail.com>
Resent-To: HTTP Working Group <ietf-http-wg@w3.org>
References: <32410.1560275231@localhost> <15839.1560351718@localhost> <8a538f76-787d-de13-97f1-16195daae8ce@gmx.de>
X-Name-Md5: efe3dad792d606410c9cc49cedaffc94
To: Julian Reschke <julian.reschke@gmx.de>, Michael Richardson <mcr+ietf@sandelman.ca>, anima@ietf.org, ietf-http-wg@w3.org, draft-ietf-pkix-est@ietf.org, Carsten Bormann <cabo@tzi.org>
X-Mailer: Apple Mail (2.3445.104.11)
X-W3C-Hub-Spam-Status: No, score=-1.8
X-W3C-Hub-Spam-Report: ALL_TRUSTED=-1, AWL=-1.530, BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, W3C_NW=0.5
X-W3C-Scan-Sig: mimas.w3.org 1hdzWC-0002VB-11 cca53dc8927edde19de99edc64f5a613
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/9fcce3cd-c3cb-bd60-a55c-af21da621b88@gmail.com>
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36728
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>
Hi Julian, On 13-Jun-19 05:26, Julian Reschke wrote: > On 12.06.2019 17:01, Michael Richardson wrote: >> >> {resending, now that I'm subscribed to ietf-http-wg. If you aren't >> on that list, the IETF global white list won't help you} >> >> RFC7030 (Enrollment over Secure Transport) includes language like (section >> 4.1.3): https://tools.ietf.org/html/rfc7030#section-4.1.3 >> >> A successful response MUST be a certs-only CMC Simple PKI Response, >> as defined in [RFC5272], containing the certificates described in the >> following paragraph. The HTTP content-type of >> "application/pkcs7-mime" is used. The Simple PKI Response is sent >> with a Content-Transfer-Encoding of "base64" [RFC2045]. >> >> draft-ietf-anima-bootstrap-keyinfra (now in IETF Last Call), extends EST. >> It creates a few more end points, and transfers RFC8366 format artifacts >> over those end points. RFC8366 defines them to be CMS signed objects, >> in DER (not PEM) format. Another document in ANIMA models the artifacts >> as COSE signed CBOR (also CMS signed CBOR). All binary objects. >> >> In doing interop testing we had some surprises about whether we should see >> base64 encoding of objects "on-the-wire". >> >> Some implementations have what I consider to be typical HTTP client and >> server code. The application sticks binary in, an appropriate >> Content-Transfer-Encoding is added, and the binary is adapted. On the >> client, if there is an encoding, it is removed, and the client sees binary >> plus a Content-Type. >> >> Other implementations were doing something more optimal: observing the >> base64, but noticing that there is only one possible Content-Type, and >> the Content-Transfer-Encoding is implicit, and so emitting base64 with an >> implicit text/plain content type. >> >> In addition, people make mistakes, and the desire to write test cases with >> curl --data (vs --data-binary) easily has led some of us astray at times. >> >> While we think that constrained devices should speak the constrained protocol >> (see below), in some cases code-constrained devices speak HTTPS, and >> wish to do away with any base64 layer of encoding, as a naive use of it >> can come with unknown memory requirements. >> >> Some questions: >> >> 1) Is Content-Transfer-Encoding even valid in HTTP1.x? >> RFC2616 and RFC7230 >> speak about Transfer-Encoding, and this relates to Chunked or not. >> https://tools.ietf.org/html/rfc2616#section-14.41 >> >> https://tools.ietf.org/html/rfc2616#section-19.4.5 says: >> HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC >> 2045. Proxies and gateways from MIME-compliant protocols to HTTP MUST >> remove any non-identity CTE ("quoted-printable" or "base64") encoding >> prior to delivering the response message to an HTTP client. >> >> RFC7230 does not include the above text making CTE unwanted. >> This made it rather hard to track down the truth :-) > > There is no Content-Transfer-Encoding header field in HTTP. It is simply > not needed. Just as a matter of curiosity, what happened in HTTP1.1 to the fragment in RFC2616 that says (under Content-MD5): "The entity-body for composite types MAY contain many body-parts, each with its own MIME and HTTP headers (including Content-MD5, Content-Transfer-Encoding, and Content-Encoding headers)." This seems to be a source of confusion, e.g. https://stackoverflow.com/questions/5169434/content-transfer-encoding-in-file-uploading-request <https://stackoverflow.com/questions/5169434/content-transfer-encoding-in-file-uploading-request> . RFC7030 uses a content type of application/pkcs7-mime. So is it allowed to specify a MIME header? Brian > >> 2) Assuming the answer to (1) is no, what should we make of RFC7030 >> that says to use it, and to base64 binary objects? > > Raise an erratum :-). > >> Would it be reasonable to assume that this is an error, to >> permit an absent (or CTE: Binary) to mean binary for RFC7030? >> There is clearly an interoperability issue here if existing >> implementations do not understand this. >> >> Did we miss a cross-area review, or did we do this on purpose? >> RFC7030 is terribly repetitive about CTE suggesting it needed >> to hit people over the head with a hammer. > > I'm sure I haven't looked at that spec. Anybody from this WG should have > spotted this. > >> 3) What should draft-ietf-anima-bootstrapping-keyinfra do going forward? >> We make use of RFC7030 functionality, and after bootstrap, we can't >> be sure that the EST server we use for certificate renewal is the >> same (brand of) EST server as before, so just because we did BRSKI, >> doesn't mean we can assume a binary version of 7030. >> >> Should BRSKI end-points: >> a) omit CTE, and assume binary. > > Yes. > >> ... > > Best regards, Julian > > _______________________________________________ > Anima mailing list > Anima@ietf.org <mailto:Anima@ietf.org> > https://www.ietf.org/mailman/listinfo/anima <https://www.ietf.org/mailman/listinfo/anima>
- Re: [Anima] Content-Transfer-Encoding and HTTP 1.… Michael Richardson
- Re: [Anima] Content-Transfer-Encoding and HTTP 1.… Julian Reschke
- Re: [Anima] Content-Transfer-Encoding and HTTP 1.… Michael Richardson
- Re: [Anima] Content-Transfer-Encoding and HTTP 1.… Julian Reschke
- Re: [Anima] Content-Transfer-Encoding and HTTP 1.… Carsten Bormann
- Re: [Anima] Content-Transfer-Encoding and HTTP 1.… Amos Jeffries
- Re: [Anima] Content-Transfer-Encoding and HTTP 1.… Eliot Lear
- Re: [Anima] Content-Transfer-Encoding and HTTP 1.… Michael Richardson
- Re: [Anima] Content-Transfer-Encoding and HTTP 1.… Michael Richardson
- Re: [Anima] Content-Transfer-Encoding and HTTP 1.… Julian Reschke
- Re: [Anima] Content-Transfer-Encoding and HTTP 1.… Brian E Carpenter
- Re: [Anima] Content-Transfer-Encoding and HTTP 1.… Brian E Carpenter