blank.gif (43 bytes)

Church Of The
Swimming Elephant

Search:
3.6.2 Display of Certificate Validation Data Connected: An Internet Encyclopedia
3.6.2 Display of Certificate Validation Data

Up: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1422
Up: 3. Architecture
Up: 3.6 Certificate Validation
Prev: 3.6.1 Validation Basics
Next: 3.6.3 Validation Procedure Details

3.6.2 Display of Certificate Validation Data

3.6.2 Display of Certificate Validation Data

PEM provides authenticated identities for message recipients and originators expressed in the form of distinguished names. Mail systems in which PEM is employed may employ identifiers other than DNs as the primary means of identifying recipients or originators. Thus, in order to benefit from these authentication facilities, each PEM implementation must employ some means of binding native mail system identifiers to distinguished names in a fashion which does not undermine this basic PEM functionality.

For example, if a human user interacts directly with PEM, then the full DN of the originator of any message received using PEM should be displayed for the user. Merely displaying the PEM-protected message content, containing an originator name from the native mail system, does not provide equivalent security functionality and could allow spoofing. If the recipient of a message is a forwarding agent such as a list exploder or mail relay, display of the originator's DN is not a relevant requirement. In all cases the essential requirement is that the ultimate recipient of a PEM message be able to ascertain the identity of the originator based on the PEM certification system, not on unauthenticated identification information, e.g., extracted from the native message system.

Conversely, for the originator of an ENCRYPTED message, it is important that recipient identities be linked to the DNs as expressed in PEM certificates. This can be effected in a variety of ways by the PEM implementation, e.g., by display of recipient DNs upon message submission or by a tightly controlled binding between local aliases and the DNs. Here too, if the originator is a forwarding process this linkage might be effected via various mechanisms not applicable to direct human interaction. Again, the essential requirement is to avoid procedures which might undermine the authentication services provided by PEM.

As described above, it is a local matter how and what certification information is displayed for a human user in the course of submission or delivery of a PEM message. Nonetheless all PEM implementations must provide a user with the ability to display a full certification path for any certificate employed in PEM upon demand. Implementors are urged to not overwhelm the user with certification path information which might confuse him or distract him from the critical information cited above.


Next: 3.6.3 Validation Procedure Details

Connected: An Internet Encyclopedia
3.6.2 Display of Certificate Validation Data

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