IPP Mail Archive: IPP> IESG review of draft-ietf-ipp-install

IPP Mail Archive: IPP> IESG review of draft-ietf-ipp-install

IPP> IESG review of draft-ietf-ipp-install-04.txt

From: Carl (carl@manros.com)
Date: Thu Apr 18 2002 - 14:45:47 EDT

  • Next message: McDonald, Ira: "IPP> FW: Registration of new charsets: UTF-32, UTF-32BE, UTF-32LE"

    Forwarded message from Ned Freed.

    Carl-Uno

    -----Original Message-----
    From: ned.freed@mrochek.com [mailto:ned.freed@mrochek.com]
    Sent: Thursday, April 18, 2002 11:01 AM
    To: ned.freed@mrochek.com
    Cc: ipp@pwg.org; carlmanros@hotmail.com; Carl; ned.freed@mrochek.com;
    paf@cisco.com
    Subject: IESG review of draft-ietf-ipp-install-04.txt

    The security mechanisms described are wrong. Digital signatures support
    should be mandatory, with use (as always) optional. The definition of how
    to
    sign files is inadequate. Probably, what's needed is Secure Multipart,
    with
    any supported signature algorithm, but that needs to be spelled out much
    more
    clearly -- the IESG doesn't think that this document gives enough
    information
    to build interoperable implementations. Files that are digitally signed
    need
    not be protected during transmission by TLS. But the query function that
    returns the client-print-support-files-supported attribute value MUST be
    TLS-protected, or the client can't reliably retrieve the security
    indicator.
    That is, an attacker could spoof that response, and delete the attribute,
    thereby telling the client not to expect something secure. Going a step
    further, that whole security model is wrong. The client is the one being
    exposed to the risk of installing bad code; therefore, it's up to the
    *client*
    to demand security. The IESG would prefer a situation where the returned
    files were self-identifying as to security status (i.e., the same as
    email),
    and the client makes the decision about whether or not to install the
    fiels,
    depending on the security status, the signature, the certificate chain (if
    any), and the client's security policy. That in turn suggests new filter
    attributes, to define what signature formats and algorithms are acceptable
    to
    the client.

    Various acrynyms in the abstract need to be expanded in accordance
    with the new RFC Editor policies in this area.

    The first paragraph of the introduction talks about this being a
    notification extension, not a printer installation extension.

    "NEED NOT" is not defined in 2119.

    Section 2 talks about using terms from RFC 2911 twice, with two
    different lists of terms that it uses.

    The end of the first sentence in section 3 is "location\s" - it's
    not clear what the backslash is meant to mean.

    Section 3.1, talking about the encoding: what if you need a "<" or
    a "," in a field name or value? (Presumably only in a value, it's
    fair to say that the field names are easy enough to restrict).

    The last line of page 8 is duplicated as the first line of page 9,
    and the last line of page 10 is duplicated as the first line of
    page 11.

    The reason described for creating a new cpu-type registry in this
    document is that the bit size of a processor needs to be included;
    however, e.g. sparc is just represented by "sparc", not "sparc32"
    or "sparc64". Is x86 really the only architecture that needs the
    bit size?

    There's a missing close-quote on m-68000 in the cpu-type field values
    at the top of page 9.

    Neither "file-type" nor "digital-signature" registries are described
    in the IANA considerations, even though from the field name/value table
    it looks like this document is creating them (at the bottom of page
    9 and 10, respectively).

    The second sentence of section 3.1.2 is confusing; the words
    "an administrator" may be extraneous.

    The second example in section 3.1.3 contains whitespace in the value of
    the "client-file-name" field, even though section 3.1 talks a lot about
    no whitespace being allowed in this part of the string.

    Table 2 in section 3.2.1.1 says what to do if uri-scheme is omitted
    by a client, implying that it's optional. (There are some examples
    later which don't have a uri-scheme value). However, table 3,
    titled "REQUIRED ... fields", lists uri-scheme. Is it optional or
    required?

    The reference to [xmldsig] needs to be updated to refer to
    RFC 3075.

    Item 2 in 3.2.1.1.1 talks about case INsensitive matching, but
    nowhere else is this mentioned in the document. Is this
    item simply obsolete?

    That's it!

                                    Ned



    This archive was generated by hypermail 2b29 : Thu Apr 18 2002 - 14:46:28 EDT