IPP Mail Archive: RE: IPP> RE: Mandatory Delivery Method for

IPP Mail Archive: RE: IPP> RE: Mandatory Delivery Method for

RE: IPP> RE: Mandatory Delivery Method for Notifications - Commen ts by April 15

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Mon Apr 01 2002 - 12:08:51 EST

  • Next message: don@lexmark.com: "Re: IPP> RE: Mandatory Delivery Method for Notifications - Comments by April 15"

    Hi Michael,

    Some more thoughts inline below.

    Cheers,
    - Ira McDonald

    -----Original Message-----
    From: Michael Sweet [mailto:mike@easysw.com]
    Sent: Monday, April 01, 2002 8:20 AM
    To: McDonald, Ira
    Cc: 'Carl'; ipp@pwg.org
    Subject: Re: IPP> RE: Mandatory Delivery Method for Notifications -
    Commen ts by April 15

    McDonald, Ira wrote:
    > ...
    > Security should be improved in both of the other optional IPP notification

    > delivery methods:
    >
    > 1) For SMTP notification, the use of S/MIME should be required
    > (S/MIME is only a MAY in the current draft).

    Except that most MUA's don't support S/MIME... :(

    <ira>
    Good point - could we say SHOULD support use of S/MIME (RFC 2633) and/or
    MIME with OpenPGP (RFC 3165) or SMTP over TLS (RFC 3207), all of which
    are IETF 'standards track'?
    </ira>

    > 2) For INDP notification, the use of TLS should be required
    > (TLS is only a MAY in the current draft).

    Again, I think that TLS, while a Good Thing (tm), introduces overhead
    that can make implementing IPP notifications impossible on the kind of
    devices it was originally targeted for...

    Making TLS a SHOULD is probably the strongest language we can use...

    <ira>
    Agreed - we should say SHOULD support use of (not SHOULD use - the choice
    of reliable security remains a client/notification receiver choice).
    </ira>

    > Neither of the optional methods is likely to pass IETF scrutiny with their
    > present security requirements and 'Security Considerations' sections.
    > Certainly not if chosen as the required IPP notification delivery method.
    > ...

    Encrypting a notification in an EMail won't make it any more secure.
    (I think SPAM/DoS issues are higher on the list than making sure that
    a notification is signed/validated; obviously the recipient can
    validate the notification themselves by looking at the printer,
    etc...)

    <ira>
    The problem of verifying the common identities of a user email address
    with certificate and a equivalent user network address (domain address)
    with certificate at time of notification subscription looks difficult.

    Since the names of mailing lists are not usually stored in directories
    with certificates, how can we address SPAM/DoS issues more than to
    refer the reader to RFC 2821 (SMTP)?
    </ira>

    For INDP, TLS may improve security, however the current spec doesn't
    require authentication at all for incoming IPP operations, so
    encrypting the channel doesn't make INDP more secure by itself.

    <ira>
    For INDP, we could say that the job submission (in IPP) SHOULD use
    TLS security and the INDP delivery SHOULD use TLS, right?
    </ira>

    -- 
    ______________________________________________________________________
    Michael Sweet, Easy Software Products                  mike@easysw.com
    Printing Software for UNIX                       http://www.easysw.com
    



    This archive was generated by hypermail 2b29 : Mon Apr 01 2002 - 12:09:34 EST