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