idnits 2.17.1 draft-ietf-asid-pgp-01.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-24) 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 4 longer pages, the longest (page 3) being 67 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 4 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([4], [5], [2,3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (20 September 1995) is 10444 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 ASID Working Group Roland Hedberg 2 INTERNET-DRAFT Umea University 3 20 September 1995 4 Expires: 20 March 1996 6 Definition of X.500 Attribute Types and a 7 Object Class to Hold public PGP keys. 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its 13 areas, and its working groups. Note that other groups may also 14 distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet- 19 Drafts as reference material or to cite them other than as 20 ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check 23 the ``1id-abstracts.txt'' listing contained in the Internet- 24 Drafts Shadow Directories on ds.internic.net (US East Coast), 25 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or 26 munnari.oz.au (Pacific Rim). 28 Distribution of this memo is unlimited. Editorial comments should 29 be sent to the author (Roland.Hedberg@umdac.umu.se). Technical 30 discussion will take place on the IETF ASID mailing list 31 (ietf-asid@umich.edu). 33 Abstract 35 Pretty Good Privacy (PGP) as definied by [1] is a high security 36 cryptographic software application for MSDOS, Unix, VAX/VMS, MacOS 37 and other operating systems. 38 There is a need to store public PGPkeys in the X.500 [2,3] 39 Directory as a means to ease the publication of public keys, and 40 thereby the use of PGP as a cryptographic system. 42 This document builds on the experimentation to date and defines 43 four new attribute types and an auxiliary object class to allow PGP 44 keys to be included in X.500 Directory entries in a standard way. 46 It is intended that the schema elements defined in this document 47 will be progressed according to the process defined by the 48 Internet X.500 Schema Working Group [4]. 50 Schema Definition of PGPkey Attribute Types 52 Name: pGPKey 53 ShortName: 54 Description: PrettyGoodPrivacy public encryptionkey 55 OID: umuAttributeType.9 (1.2.752.17.1.9) 56 Syntax: IA5String 57 SizeRestriction: None 58 SingleValued: True 60 Name: pGPKeyRev 61 ShortName: 62 Description: PrettyGoodPrivacy public encryptionkey 63 revocation 64 OID: umuAttributeType.10 (1.2.752.17.1.10) 65 Syntax: IA5String 66 SizeRestriction: None 67 SingleValued: False 69 Name: pGPKeyID 70 ShortName: 71 Description: PrettyGoodPrivacy encryptionkey key ID 72 OID: umuAttributeType.12 (1.2.752.17.1.12) 73 Syntax: caseIgnoreString 74 SizeRestriction: None 75 SingleValued: True 77 Name: pGPUserID 78 ShortName: 79 Description: PrettyGoodPrivacy encryptionkey user ID 80 OID: umuAttributeType.13 (1.2.752.17.1.13) 81 Syntax: caseIgnoreString 82 SizeRestriction: None 83 SingleValued: True 85 Discussion of the pGPKey Attribute Types 87 The value for pGPKey and pGPKeyRev that is to be stored in 88 X.500 is the ASCII armored text format [5], as produced by 89 the command pgp -kax, with possibly one small modification 90 as described below. 92 The attribute syntax used is the IA5String . 94 IA5String ::= OCTET STRING 96 The IA5String is a notational convenience to indicate that, 97 although strings of IA5String type encode as OCTET STRING 98 types, the legal character set in such a string is limited 99 to the IA5 character set. 101 The reasoning behind using the IA5StringSyntax is that, since 102 ASCII-armored PGPkey as it is produced by PGP software today 103 consists of serveral pieces separated by linebreaks, it can 104 only be stored in X.500 without modifications if the attribute 105 syntax choosen allows the complete ASCII characterset. 107 The slight modification that might be necessary is due to the 108 fact that linebreaks are defined differently in different 109 Operating systems. The linebreaks stored in X.500 is therefore 110 defined to consist of the pair CR (0x0d) plus LF (0x0a). 112 pGPKeyID and pGPUserID is needed if one wants to use 113 a X.500 directory service to emulate a PGP key server since 114 the key servers normally allows you to search for keyIDs as well 115 as matching on parts of the UserID. Since one of the designcriterias 116 was to make it ease to deploy the ideas in this draft I have 117 choosen standard attributetypes instead of inventing new ones, 118 therefore I have to limit pGPKey, pGPKeyID and pGPUserID to be 119 singlevalued to keep the connection between these values. 121 Schema Definition of pGPKeyObject Object Class 123 Name: pGPKeyObject 124 Description: Auxiliary object class that holds pGPKey 125 information 126 OID: umuObjectClass.4 (1.2.752.17.3.4) 127 SubclassOf: top 128 MustContain: 129 MayContain: pGPKey, pGPKeyRev, pGPUserID, pGPKeyID 131 Discussion of the pGPKeyObject Object Class 133 The pGPKeyObject class is a subclass of top and may contain the 134 pGPKey, pGPKeyRev, pGPUserID and pGPKeyID attributes. The 135 intent is that this object class can be added to existing objects 136 to allow for inclusion of pGPKey values. It is therefore viewed 137 as a auxiliary objectclass. 138 This approach does not preclude including the pGPKey 139 attribute type directly in other object classes as appropriate. 141 Security Considerations 143 The basis for the use of PGP public keys are that you may validate 144 them in two different ways if you get the public key over the net. 145 The first way depends on the fact that the public key as it is 146 stored and received might contain a validation by someone that the 147 receiver already has a validated public key for. If the receiver 148 trusts the validator then the public key can be included in the 149 receivers keyring without further ado. 150 If on the other hand the received public key contains no validation 151 or no validation by someone that the receiver already has a public 152 key for then the receiver has to resort to out-of-bands methods to 153 validate the key. This could be using the phone or a meeting in 154 person. 156 If you can not validate the public key by any of the above mentioned 157 means you should never trust the public key. 159 Therefore the use of X.500, for storage of PGP public keys, as it 160 stands today with almost no security in place poses no problem. 161 Like all other PGP key servers on the net today it does NOT attempt 162 to guarantee that a key is a valid key. 164 References 166 [1] Philip Zimmermann, 167 "The Official PGP User's Guide"; 168 MIT Press 169 ISBN 0-262-74017-6 171 [2] The Directory: Overview of Concepts, Models and Service. CCITT 172 Recommendation X.500, 1988. 174 [3] Information Processing Systems -- Open Systems Interconnection -- 175 The Directory: Overview of Concepts, Models and Service. 176 ISO/IEC JTC 1/SC21; International Standard 9594-1, 1988. 178 [4] Howes, T., Rossen, K., Sataluri, S., and Wright, R., "Procedures 179 for Formalizing, Evolving, and Maintaining the Internet X.500 180 Directory Schema", Internet Draft (Work In Progress) of the Schema 181 Working Group, 184 [5] Atkins, D., Stallings, W. and Zimmerman, P., "PGP Message Exchange 185 Formats", Internet Draft (Work in progress), 186 188 Author's Address 190 Roland Hedberg 191 Umdac 192 Umea University 193 S-901 87 Umea, Sweden 195 Phone: +46 90 165165 196 Fax: +46 90 166766 197 EMail: Roland.Hedberg@umdac.umu.se 199 This Internet Draft expires March 20th, 1996.