[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Internet Draft                                 Blake Ramsdell,
draft-ramsdell-role-names-00.txt               Worldtalk
April 29, 1998
Expires in six months


              Role Names in X.509 Certificates

Status of this memo

This document is an Internet-Draft. Internet-Drafts are
working documents of the Internet Engineering Task Force
(IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by
other documents at any time. It is inappropriate to use
Internet-Drafts as reference material or to cite them other
than as "work in progress."

To view the entire list of current Internet-Drafts, please
check the "1id-abstracts.txt" listing contained in the
Internet-Drafts Shadow Directories on ftp.is.co.za (Africa),
ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern
Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East
Coast), or ftp.isi.edu (US West Coast).

1.   Introduction

The subjectAltName X.509 extension described in [KEYM]
provides a mechanism where information regarding the entity
that signed and/or encrypted some data can be identified.
However, there is a case where the subject may not be a
concrete entity, but may be a 'role' within an organization
or network. This document will specify a set of these roles
and their definitions.


1.1. Terminology

Throughout this draft, the terms MUST, MUST NOT, SHOULD, and
SHOULD NOT are used in capital letters. This  conforms to
the definitions in [MUSTSHOULD]. [MUSTSHOULD] defines the
use of these key words to help make the intent of standards
track documents as clear as possible. The same key words are
used in this document to help implementors achieve
interoperability.

2.   rfc822Name role names

Role names for the rfc822Name choice can only be the local-
part of the addr-spec. The currently defined roles handle
various cases such as:

The need to sign messages on behalf of people at a domain
that may or may not have signature services available at the
desktop. An outbound message from a domain may be sent that
is signed at the domain mail server.

The need to encrypt messages for people at a domain that may
not have encryption services available at the desktop. A
message may be encrypted for the domain mail server using a
domain encrypting certificate, and that message will be
decrypted before local delivery.

The need to encrypt messages between two mail transfer
agents (MTAs). This is different than a domain encrypting
certificate, in that the message is never encrypted or
decrypted at the mail user agent (MUA) level.

The need to encrypt messages for a keypair that is
controlled by the domain administrator for the purposes of
plaintext access. A message may be encrypted for the domain
mail server using a domain message recovery encryption
certificate for the purpose of selective plaintext recovery
by the domain administrator. This differs from a domain
encrypting certificate in that the message is not
necessarily decrypted before local delivery.


2.1. Domain signing

The domain signing role is used for signing email messages
(for instance, S/MIME signed messages) on behalf of a
domain. This can be used in the event that local users at
the domain do not have an email client that is capable of
digital signature generation.

The local-part that SHALL be used is:

domain-signing-authority


2.2. Domain encrypting

The domain encrypting role is used for encrypting email
messages for anyone at a particular domain. This can be used
in the event that local users at the domain do not have an
email client that is capable of email decryption, where the
mail server decrypts messages on behalf of the local users.

The local-part that SHALL be used is:

domain-encrypting-authority


2.3. Transfer agent to transfer agent encrypting

The transfer agent to transfer agent role is used for
encrypting email messages between two mail transfer agents
(MTAs).

The local part that SHALL be used is:

mta-encrypting-authority


2.4. Domain message recovery encrypting

The domain message recovery role is used for encrypting
email messages for the purpose of recovering the plaintext
at a later date.

The local-part that SHALL be used is:

domain-recovery-authority


2.5. Sending / receiving agent considerations

The primary purpose for these role name conventions is to
allow sending and receiving agents to make intelligent and
potentially unassisted decisions regarding certificate
selection.


2.5.1.    Outgoing encrypted messages

In order to select a certificate to encrypt for a particular
email address, the following logic is suggested. Given the
email address user@foo.com:

1.   Try to find a certificate for user@foo.com
2.   If that fails, try to find a certificate for domain-
  encrypting-authority@foo.com

In the event that the domain encrypting certificate is used
instead of a certificate for the actual recipient, the
sending agent MAY wish to display information regarding the
fact that the message will be encrypted for the domain
certificate and not for the actual recipient.

The use of a domain message recovery certificate is TBD. One
possibility is that if a domain encrypting certificate is
present, to use that certificate whenever encrypting mail to
that domain.


2.5.2.    Incoming signed messages

If matching is performed on inbound messages in order to
determine whether or not a message is signed by the sender
(that is, if the email address in the certificate matches
the email address from which the message was sent), role
names may need to be considered. Specifically, for
user@foo.com, the message could be signed with the
certificate for domain-signing-authority@foo.com. The
receiving agent MAY wish to display information regarding
the fact that the domain has signed the message and not the
originator.

A.   References

[KEYM] "Internet Public Key Infrastructure X.509 Certificate
and CRL Profile", Internet-Draft draft-ietf-pkix-ipki-part1

[MUSTSHOULD] "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119

B.   Author's address

Blake Ramsdell
Worldtalk
13122 NE 20th St., Suite C
Bellevue, WA 98005
(425) 882-8861
blaker@deming.com