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

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 . 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
> https://www.ietf.org/mailman/listinfo/anima
> 