Here is another comment from Ned.
Carl-Uno Manros
10701 S Eastern Ave #1117
Henderson, NV 89052, USA
Tel +1-702-617-9414
Fax +1-702-617-9417
Mob +1-310-251-7103
Email carl at manros.com
-----Original Message-----
From: ned.freed at mrochek.com [mailto:ned.freed at mrochek.com]
Sent: Monday, April 01, 2002 11:34 AM
To: McDonald, Ira
Cc: 'Michael Sweet'; McDonald, Ira; 'Carl'; ipp at pwg.org
Subject: RE: IPP> RE: Mandatory Delivery Method for Notifications -
Commen ts by April 15
> The IETF could eliminate SMTP over TLS (RFC 3207), because it's
> hop-by-hop security (only works well _within_ an enterprise
> network, which is of course one of the best IPP environments).
You're comparing apples and oranges. SMTP over TLS is intended to provide a
completely different service that meets a completely different set of needs
than S/MIME or PGP.
Specifically, in many cases confidentiality or authentication of the first
hop
is exactly what you need.
The number of sites that use SMTP over TLS and SASL to authenticate before
being allowed to send mail, especially for users outside the organizxation,
is
large and gets larger all the time. Similarly, protecting the first hop may
be
all that's needed when a roving user connects to send mail.
Additionally, the practical difficulty of deploying S/MIME or PGP -- both of
which require client certificates or keys -- can be immense. SMTP over
TLS is much easier to deploy. As a result it gets used even when S/MIME or
PGP would in theory be more appropriate.
> But both S/MIME v3 and OpenPGP are recent and Proposed Std.
> Do you know if OpenPGP is any more common in infrastructure
> and clients than S/MIME?
S/MIME is far more common in my experience, but it is hard to compare
since usage of either one is pretty rare.
> Annecdotally, the IETF Registrar
> (for conferences), the RFC Editor and others regularly post
> their OpenPGP public keys on their Web pages, but I don't
> see S/MIME keys usually.
Yet the popular Microsoft and Netscape clients provide support for S/MIME
but
not PGP out of the box.
However, I must say that I believe this entire discussion is almost
completely
irrelevant to the task at hand. The task at hand isn't to decide on a brand
of
security pixie dust to sprinkle on IPP notifications. The task is to analyze
the actual security needs of IPP notifications in various contexts and then
do
what's appropriate. Trying to figure out what's most commonly used is
at most a marginal secondary concern.
And in the case of notifications via email I think this is fairly easy. My
understanding is that the WG has decided to focus on making these
notifications
human readable. Given that they aren't going to be processed automatically
anyway, I see little if any justification for signing them.
As for confidentiality, I suppose not having it encourages certain forms of
traffic analysis, but the risk seems small. And since TLS in base IPP is
only a
SHOULD there's no case to be made for a MUST. I think a MAY for S/MIME or
PGP
is the most you'd want here.
Authentication is another matter. Situations exist where printers are going
to have to authenticate before they will be able to send mail. Indeed,
I believe this is a sufficiently common case that you need to provide for
it. But this isn't a per-user sort of thing, it is instead part of the
basic printer configuration.
And authentication in email is done with SASL. S/MIME and PGP don't even
enter
into it, and TLS doesn't have to. I would therefore suggest making SASL
a MUST with DIGEST-MD5 the mandatory to implement mechanism. You'll need
to be able to configure the printer to support the necessary credentials.
Ned