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