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

[Julian Reschke <[e-mail]>]

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.

> 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