Hi Michael,
Some more thoughts inline below.
Cheers,
- Ira McDonald
-----Original Message-----
From: Michael Sweet [mailto:mike at easysw.com]
Sent: Monday, April 01, 2002 8:20 AM
To: McDonald, Ira
Cc: 'Carl'; ipp at 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 at easysw.com
Printing Software for UNIX http://www.easysw.com