Loading ...
Sorry, an error occurred while loading the content.
 

(INTEGOK) rough consensus

Expand Messages
  • Paul Leach
    What follows is text for the (currently TBS) section on Content-MD5 header. There are objections to it, but rough consensus is believed to exist. The most
    Message 1 of 6 , Mar 31, 1996
      What follows is text for the (currently TBS) section on Content-MD5
      header. There are objections to it, but rough consensus is believed to
      exist. The most likely outcome of the objections (IMHO) is that a new
      header for content integrity and authentication mechanisms will be
      proposed for HTTP/1.2.

      If there are any problems you have with this, please let me know, or
      I will believe enough consensus exists to make add this to the 1.1 draft
      to close this issue.

      --------------------
      10.13 Content-MD5

      The Content-MD5 entity-header field is an MD5 digest of the entity-body,
      as defined in [RFC 1864], for the purpose of providing an end-to-end
      integrity check of the entity-body.

      ContentMD5 = "Content-MD5" ":" digest
      digest = <base64 of 128 bit MD5 digest as per RFC 1864>

      The Content-MD5 header may optionally be generated by origin servers,
      and functions as an integrity check of the entity-body. Only
      origin-servers may generate the Content-MD5 headers: proxies and
      gateways MUST NOT generate it, as this would defeat its value and an
      end-to-end integrity check. Any recipient of the entity-body, including
      gateways and proxies, MAY check that the digest value in the header
      matches that of the entity-body as received.

      When being generated, the MD5 digest is computed based on the value of
      the entity-body after Content-Encoding (if any) but before
      Transfer-Encoding (if any) is applied; when being checked, after
      Transfer-Encoding has been removed, but before Content-Encoding has been
      removed.

      There are several ways in which the application of Content-MD5 to HTTP
      entity-bodies differs from its application to MIME entity-bodies. One is
      that HTTP, unlike MIME, does not use Content-Transfer-Encoding, and does
      use Transfer-Encoding and Content-Encoding. Another is that, unlike
      MIME, the digest is computed over the entire entity-body, even if it
      happens to be a MIME multi-part content-type. (Note that the multi-part
      bodies may themselves have Content-MD5 headers.) Another is that HTTP
      more frequently uses binary content types than MIME, so it is worth
      noting that in such cases, the byte order used to compute the digest is
      network byte order. Lastly, the canonical form of text types in HTTP
      includes several line break conventions, so conversion to CR-LF is not
      always required before computing or checking the digest: any acceptable
      convention should be left unaltered for inclusion in the digest.

      > Note: the net result of the above is that the digest is
      computed on the content that would be sent over-the-wire, in
      > network byte order, but prior to any transfer coding being
      > applied.



      ----------------------------------------------------
      Paul J. Leach Email: paulle@...
      Microsoft Phone: 1-206-882-8080
      1 Microsoft Way Fax: 1-206-936-7329
      Redmond, WA 98052
    • Roy T. Fielding
      I am having a hell of a time keeping connected to the discussions -- our network and workstations keep failing due to multiple power failures and server
      Message 2 of 6 , Apr 1, 1996
        I am having a hell of a time keeping connected to the discussions -- our
        network and workstations keep failing due to multiple power failures
        and server problems.

        Typos and rough wording changes:

        > 10.13 Content-MD5
        >
        > The Content-MD5 entity-header field is an MD5 digest of the entity-body,

        field provides an MD5 digest ...

        > as defined in [RFC 1864], for the purpose of providing an end-to-end

        RFC 1864 [xx],

        > integrity check of the entity-body.
        >
        > ContentMD5 = "Content-MD5" ":" digest
        > digest = <base64 of 128 bit MD5 digest as per RFC 1864>

        Content-MD5 = "Content-MD5" ":" md5-digest
        md5-digest = <base64 of 128 bit MD5 digest as per RFC 1864>

        > The Content-MD5 header may optionally be generated by origin servers,
        > and functions as an integrity check of the entity-body. Only

        The Content-MD5 header may be generated by an origin server to function
        as an integrity check of the entity-body. Only,

        > origin-servers may generate the Content-MD5 headers: proxies and

        header field; proxies and

        > gateways MUST NOT generate it, as this would defeat its value and an

        value as an

        > end-to-end integrity check. Any recipient of the entity-body, including
        > gateways and proxies, MAY check that the digest value in the header

        in this header field

        > matches that of the entity-body as received.
        >
        > When being generated, the MD5 digest is computed based on the value of
        > the entity-body after Content-Encoding (if any) but before
        > Transfer-Encoding (if any) is applied; when being checked, after
        > Transfer-Encoding has been removed, but before Content-Encoding has been
        > removed.

        The above is too terse.

        The MD5 digest is computed based on the content of the entity body,
        including any Content-Encoding that has been applied, but not including
        any Transfer-Encoding. If the entity is received with a
        Transfer-Encoding, that encoding must be removed prior to checking
        the Content-MD5 value against the received entity.

        > There are several ways in which the application of Content-MD5 to HTTP
        > entity-bodies differs from its application to MIME entity-bodies. One is
        > that HTTP, unlike MIME, does not use Content-Transfer-Encoding, and does
        > use Transfer-Encoding and Content-Encoding. Another is that, unlike
        > MIME, the digest is computed over the entire entity-body, even if it

        may be computed

        > happens to be a MIME multi-part content-type. (Note that the multi-part

        be a "multipart" type. ...

        > bodies may themselves have Content-MD5 headers.) Another is that HTTP
        > more frequently uses binary content types than MIME, so it is worth
        > noting that in such cases, the byte order used to compute the digest is
        > network byte order. Lastly, the canonical form of text types in HTTP
        > includes several line break conventions, so conversion to CR-LF is not

        so conversion of all line
        breaks to CRLF form is not

        > always required before computing or checking the digest: any acceptable
        > convention should be left unaltered for inclusion in the digest.
        >
        >> Note: the net result of the above is that the digest is
        > computed on the content that would be sent over-the-wire, in
        >> network byte order, but prior to any transfer coding being
        >> applied.

        Why not just say that and leave out the rest? I think the note is far
        more effective (and more likely to always be accurate) then the paragraph
        above it.


        ...Roy T. Fielding
        Department of Information & Computer Science (fielding@...)
        University of California, Irvine, CA 92717-3425 fax:+1(714)824-4056
        http://www.ics.uci.edu/~fielding/
      • Paul Leach
        ... ] I like all the suggested wording changes. ... How about switching: the note will be the definitive text, the paragraph above it the
        Message 3 of 6 , Apr 1, 1996
          >----------
          >From: Roy T. Fielding[SMTP:fielding@...]
          >Subject: Re: (INTEGOK) rough consensus
          >
          ] I like all the suggested wording changes.
          >
          >>> Note: the net result of the above is that the digest is
          >> computed on the content that would be sent over-the-wire, in
          >>> network byte order, but prior to any transfer coding being
          >>> applied.
          >
          >Why not just say that and leave out the rest? I think the note is far
          >more effective (and more likely to always be accurate) then the
          >paragraph
          >above it.

          How about switching: the note will be the definitive text, the paragraph
          above it the explanation/motivational note?

          I think the explanaority paragraph is useful to relate RFC 1864 to the
          HTTP context; if everyone else thinks its redundant, I can be persuaded
          to remove it.

          Send me private opinions on the utility -- no need to clutter the list:
          a one liner with "useful" or "not useful" will do.

          Paul
        • hallam@w3.org
          ... No, you really should remove the claim to be per RFC 1864 since the spec as given has no connection with RFC1864 except in using the same hash function.
          Message 4 of 6 , Apr 1, 1996
            > Content-MD5 = "Content-MD5" ":" md5-digest
            > md5-digest = <base64 of 128 bit MD5 digest as per RFC 1864>

            No, you really should remove the claim to be per RFC 1864 since the spec
            as given has no connection with RFC1864 except in using the same hash function.

            RFC 1864 in sofar as it says anything states that the entity is canonicalized
            before the digest is applied. I believe that we have (rightly) decided not to
            introduce the canonicalization step. Therefore we are not doing the base64 of
            the digest "per RFC1864)" we are doing the base64 of the digest.


            >> MIME, the digest is computed over the entire entity-body, even if it
            >
            > may be computed

            No, Roy this is wrong the disgest IS computed. If the digest is there the
            value is MD5(entity) there is no provision to allow MD5(cononical(entity)).


            As specified I think that we are being given a pig in a poke. If one gets a
            Content-MD5 header with this spec one will not know what the digest was
            calculated on. Are implementations to be required to perform both checks on
            the offchance that canonicalisation was used?

            If people want to reuse an existing tag then they should accept whatever
            baggage goes with it. If that involves irrelevant canonicalization steps
            then so be it. If the spec diverges one should specify a new tag.


            Phill
          • TROTH@ua1vm.ua.edu
            To compute an MD5 signature for textual material, I would like to see the following applied: o trailing white space stripped o remaining whitespace reduced
            Message 5 of 6 , Apr 2, 1996
              To compute an MD5 signature for textual material,
              I would like to see the following applied:

              o trailing white space stripped

              o remaining whitespace reduced to single blanks

              o CR/LF ignored

              The justification for this is that something cut-n-pasted
              should still pass. No, we're not going to splice the TCP stream
              and insert cut-n-pasted text, but the above will make digests work on
              the widest range of interoperable platforms. What I'm saying is that
              cut-n-paste-ability isn't the goal, it represents a sample of the
              kind of mangling that might happen when the text crosses some boundaries.
              Interoperability is the goal. Make MD5 verification work cross-platform.

              --
              Rick Troth <troth@...>, Houston, Texas, USA
              http://casita.houston.tx.us/~troth/
            • Ned Freed
              ... I basically agree with Roy about this section -- the simpler the prose is on this point, the better. However, there is still one problem remaining: The use
              Message 6 of 6 , Apr 2, 1996
                > Note: the net result of the above is that the digest is
                > computed on the content that would be sent over-the-wire, in
                > network byte order, but prior to any transfer coding being
                > applied.

                I basically agree with Roy about this section -- the simpler the prose is on
                this point, the better.

                However, there is still one problem remaining: The use of the term "network
                byte order". It is wrong to use this term in this context. Network byte
                order refers quite specifically to the ordering of bytes in network address
                information. It is not only nonsensical to talk about a generic sequence
                of octets being in network byte order, it is outright incorrect, as there
                may be media types defined with embedded network address information in them
                that isn't presented in network byte order.

                The bytes ungoing checksumming are in whatever order the media type puts them
                in for transfer of the content across the wire.

                Ned
              Your message has been successfully submitted and would be delivered to recipients shortly.