Forwarded message from Ned Freed.
Carl-Uno
-----Original Message-----
From: ned.freed at mrochek.com [mailto:ned.freed at mrochek.com]
Sent: Thursday, April 18, 2002 11:01 AM
To: ned.freed at mrochek.com
Cc: ipp at pwg.org; carlmanros at hotmail.com; Carl; ned.freed at mrochek.com;
paf at 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