idnits 2.17.1 draft-ramsdell-role-names-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 190 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 41: '...draft, the terms MUST, MUST NOT, SHOUL...' RFC 2119 keyword, line 88: '...The local-part that SHALL be used is:...' RFC 2119 keyword, line 100: '...The local-part that SHALL be used is:...' RFC 2119 keyword, line 110: '...The local part that SHALL be used is:...' RFC 2119 keyword, line 120: '...The local-part that SHALL be used is:...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 42 has weird spacing: '...s. This confo...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 29, 1998) is 9487 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'KEYM' on line 167 looks like a reference -- Missing reference section? 'MUSTSHOULD' on line 170 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Blake Ramsdell, 2 draft-ramsdell-role-names-00.txt Worldtalk 3 April 29, 1998 4 Expires in six months 6 Role Names in X.509 Certificates 8 Status of this memo 10 This document is an Internet-Draft. Internet-Drafts are 11 working documents of the Internet Engineering Task Force 12 (IETF), its areas, and its working groups. Note that other 13 groups may also distribute working documents as Internet- 14 Drafts. 16 Internet-Drafts are draft documents valid for a maximum of 17 six months and may be updated, replaced, or obsoleted by 18 other documents at any time. It is inappropriate to use 19 Internet-Drafts as reference material or to cite them other 20 than as "work in progress." 22 To view the entire list of current Internet-Drafts, please 23 check the "1id-abstracts.txt" listing contained in the 24 Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), 25 ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern 26 Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East 27 Coast), or ftp.isi.edu (US West Coast). 29 1. Introduction 31 The subjectAltName X.509 extension described in [KEYM] 32 provides a mechanism where information regarding the entity 33 that signed and/or encrypted some data can be identified. 34 However, there is a case where the subject may not be a 35 concrete entity, but may be a 'role' within an organization 36 or network. This document will specify a set of these roles 37 and their definitions. 39 1.1. Terminology 41 Throughout this draft, the terms MUST, MUST NOT, SHOULD, and 42 SHOULD NOT are used in capital letters. This conforms to 43 the definitions in [MUSTSHOULD]. [MUSTSHOULD] defines the 44 use of these key words to help make the intent of standards 45 track documents as clear as possible. The same key words are 46 used in this document to help implementors achieve 47 interoperability. 49 2. rfc822Name role names 51 Role names for the rfc822Name choice can only be the local- 52 part of the addr-spec. The currently defined roles handle 53 various cases such as: 55 The need to sign messages on behalf of people at a domain 56 that may or may not have signature services available at the 57 desktop. An outbound message from a domain may be sent that 58 is signed at the domain mail server. 60 The need to encrypt messages for people at a domain that may 61 not have encryption services available at the desktop. A 62 message may be encrypted for the domain mail server using a 63 domain encrypting certificate, and that message will be 64 decrypted before local delivery. 66 The need to encrypt messages between two mail transfer 67 agents (MTAs). This is different than a domain encrypting 68 certificate, in that the message is never encrypted or 69 decrypted at the mail user agent (MUA) level. 71 The need to encrypt messages for a keypair that is 72 controlled by the domain administrator for the purposes of 73 plaintext access. A message may be encrypted for the domain 74 mail server using a domain message recovery encryption 75 certificate for the purpose of selective plaintext recovery 76 by the domain administrator. This differs from a domain 77 encrypting certificate in that the message is not 78 necessarily decrypted before local delivery. 80 2.1. Domain signing 82 The domain signing role is used for signing email messages 83 (for instance, S/MIME signed messages) on behalf of a 84 domain. This can be used in the event that local users at 85 the domain do not have an email client that is capable of 86 digital signature generation. 88 The local-part that SHALL be used is: 90 domain-signing-authority 92 2.2. Domain encrypting 94 The domain encrypting role is used for encrypting email 95 messages for anyone at a particular domain. This can be used 96 in the event that local users at the domain do not have an 97 email client that is capable of email decryption, where the 98 mail server decrypts messages on behalf of the local users. 100 The local-part that SHALL be used is: 102 domain-encrypting-authority 104 2.3. Transfer agent to transfer agent encrypting 106 The transfer agent to transfer agent role is used for 107 encrypting email messages between two mail transfer agents 108 (MTAs). 110 The local part that SHALL be used is: 112 mta-encrypting-authority 114 2.4. Domain message recovery encrypting 116 The domain message recovery role is used for encrypting 117 email messages for the purpose of recovering the plaintext 118 at a later date. 120 The local-part that SHALL be used is: 122 domain-recovery-authority 124 2.5. Sending / receiving agent considerations 126 The primary purpose for these role name conventions is to 127 allow sending and receiving agents to make intelligent and 128 potentially unassisted decisions regarding certificate 129 selection. 131 2.5.1. Outgoing encrypted messages 133 In order to select a certificate to encrypt for a particular 134 email address, the following logic is suggested. Given the 135 email address user@foo.com: 137 1. Try to find a certificate for user@foo.com 138 2. If that fails, try to find a certificate for domain- 139 encrypting-authority@foo.com 141 In the event that the domain encrypting certificate is used 142 instead of a certificate for the actual recipient, the 143 sending agent MAY wish to display information regarding the 144 fact that the message will be encrypted for the domain 145 certificate and not for the actual recipient. 147 The use of a domain message recovery certificate is TBD. One 148 possibility is that if a domain encrypting certificate is 149 present, to use that certificate whenever encrypting mail to 150 that domain. 152 2.5.2. Incoming signed messages 154 If matching is performed on inbound messages in order to 155 determine whether or not a message is signed by the sender 156 (that is, if the email address in the certificate matches 157 the email address from which the message was sent), role 158 names may need to be considered. Specifically, for 159 user@foo.com, the message could be signed with the 160 certificate for domain-signing-authority@foo.com. The 161 receiving agent MAY wish to display information regarding 162 the fact that the domain has signed the message and not the 163 originator. 165 A. References 167 [KEYM] "Internet Public Key Infrastructure X.509 Certificate 168 and CRL Profile", Internet-Draft draft-ietf-pkix-ipki-part1 170 [MUSTSHOULD] "Key words for use in RFCs to Indicate 171 Requirement Levels", RFC 2119 173 B. Author's address 175 Blake Ramsdell 176 Worldtalk 177 13122 NE 20th St., Suite C 178 Bellevue, WA 98005 179 (425) 882-8861 180 blaker@deming.com