blank.gif (43 bytes)

Church Of The
Swimming Elephant

Search:
4.5 Mail for Mailing Lists Connected: An Internet Encyclopedia
4.5 Mail for Mailing Lists

Up: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1421
Up: 4. Processing of Messages
Prev: 4.4 Encapsulation Mechanism
Next: 4.6 Summary of Encapsulated Header Fields

4.5 Mail for Mailing Lists

4.5 Mail for Mailing Lists

When mail is addressed to mailing lists, two different methods of processing can be applicable: the IK-per-list method and the IK-per- recipient method. Hybrid approaches are also possible, as in the case of IK-per-list protection of a message on its path from an originator to a PEM-equipped mailing list exploder, followed by IK- per-recipient protection from the exploder to individual list recipients.

If a message's originator is equipped to expand a destination mailing list into its individual constituents and elects to do so (IK-per- recipient), the message's DEK (and, in the symmetric key management case, MIC) will be encrypted under each per-recipient IK and all such encrypted representations will be incorporated into the transmitted message. Note that per-recipient encryption is required only for the relatively small DEK and MIC quantities carried in the "Key-Info:" field, not for the message text which is, in general, much larger. Although more IKs are involved in processing under the IK-per- recipient method, the pairwise IKs can be individually revoked and possession of one IK does not enable a successful masquerade of another user on the list.

If a message's originator addresses a message to a list name or alias, use of an IK associated with that name or alias as a entity (IK-per-list), rather than resolution of the name or alias to its constituent destinations, is implied. Such an IK must, therefore, be available to all list members. Unfortunately, it implies an undesirable level of exposure for the shared IK, and makes its revocation difficult. Moreover, use of the IK-per-list method allows any holder of the list's IK to masquerade as another originator to the list for authentication purposes.

Pure IK-per-list key management in the asymmetric case (with a common private key shared among multiple list members) is particularly disadvantageous in the asymmetric environment, as it fails to preserve the forwardable authentication and non-repudiation characteristics which are provided for other messages in this environment. Use of a hybrid approach with a PEM-capable exploder is therefore particularly recommended for protection of mailing list traffic when asymmetric key management is used; such an exploder would reduce (per discussion in Section 4.4 of this RFC) incoming ENCRYPTED messages to MIC-ONLY or MIC-CLEAR form before forwarding them (perhaps re-encrypted under individual, per-recipient keys) to list members.


Next: 4.6 Summary of Encapsulated Header Fields

Connected: An Internet Encyclopedia
4.5 Mail for Mailing Lists

Cotse.Net

Protect yourself from cyberstalkers, identity thieves, and those who would snoop on you.
Stop spam from invading your inbox without losing the mail you want. We give you more control over your e-mail than any other service.
Block popups, ads, and malicious scripts while you surf the net through our anonymous proxies.
Participate in Usenet, host your web files, easily send anonymous messages, and more, much more.
All private, all encrypted, all secure, all in an easy to use service, and all for only $5.95 a month!

Service Details

 
.
www.cotse.com
Have you gone to church today?
.
All pages ©1999, 2000, 2001, 2002, 2003 Church of the Swimming Elephant unless otherwise stated
Church of the Swimming Elephant©1999, 2000, 2001, 2002, 2003 Cotse.com.
Cotse.com is a wholly owned subsidiary of Packetderm, LLC.

Packetderm, LLC
210 Park Ave #308
Worcester, MA 01609