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

{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 :-)

2) Assuming the answer to (1) is no, what should we make of RFC7030
   that says to use it, and to base64 binary objects?

   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.

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.
    b) permit CTE, suggest it say, "binary"
    c) permit CTE, support "binary" or "base64"
    d) permit CTE, support "base64" only (like RFC7030).

Some implementors received pressure within to reduce the number of bytes on
the wire significantly.  The use of implicit Content-Type and CTE was
a result, rather than saving 25% by going base64->binary.

Constrained users are directed to draft-ietf-ace-est-coaps (replaces 7030),
and draft-ietf-anima-constrained-voucher (replaces 8366, and BRSKI),
which uses CBOR, COSE and COAP.

Note that the constrained-voucher version of BRSKI uses the standard
BRSKI-MASA protocol between registrar and MASA.  That path has no "legacy"
RFC7030 end points, and so should be modern HTTPS.  Because it transfers
both RFC8366 and the three formats of constrained voucher (all binary
artifacts), it relies on Content-Type: and Accept: in both directions to
signal the format present, and the desired format response.


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


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