ASID Working Group Roland Hedberg INTERNET-DRAFT Umea University
<draft-ietf-asid-pgp-00.txt> 10 August<draft-ietf-asid-pgp-01.txt> 20 September 1995 Expires: 10 February 1996Definition of X.500 Attribute Types and a Object Class to Hold public PGP keys. 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 learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Distribution of this memo is unlimited. Editorial comments should be sent to the author (Roland.Hedberg@umdac.umu.se). Technical discussion will take place on the IETF ASID mailing list (firstname.lastname@example.org). Abstract Pretty Good Privacy (PGP) as definied by  is a high security cryptographic software application for MSDOS, Unix, VAX/VMS, MacOS and other operating systems. There is a need to store public PGPkeys in the X.500 [2,3] Directory as a means to ease the publication of public keys, and thereby the use of PGP as a cryptographic system. This document builds on the experimentation to date and defines four new attribute types and an auxiliary object class to allow PGP keys to be included in X.500 Directory entries in a standard way. It is intended that the schema elements defined in this document will be progressed according to the process defined by the Internet X.500 Schema Working Group . Schema Definition of PGPkey Attribute Types Name: pGPKey ShortName: Description: PrettyGoodPrivacy public encryptionkey OID: umuAttributeType.9 (1.2.7188.8.131.52) Syntax: IA5String SizeRestriction: None SingleValued: FalseTrue Name: pGPKeyRev ShortName: Description: PrettyGoodPrivacy public encryptionkey revocation OID: umuAttributeType.10 (1.2.7184.108.40.206) Syntax: IA5String SizeRestriction: None SingleValued: False Name: pGPKeyID ShortName: Description: PrettyGoodPrivacy encryptionkey key ID OID: umuAttributeType.12 (1.2.7220.127.116.11) Syntax: caseIgnoreString SizeRestriction: None SingleValued: FalseTrue Name: pGPUserID ShortName: Description: PrettyGoodPrivacy encryptionkey user ID OID: umuAttributeType.13 (1.2.718.104.22.168) Syntax: caseIgnoreString SizeRestriction: None SingleValued: FalseTrue Discussion of the pGPkeypGPKey Attribute Types The value for pGPkeypGPKey and pGPkeyRevpGPKeyRev that is to be stored in X.500 is the ASCII armored text format , as produced by the command pgp -kax, with possibly one small modification as described below. The attribute syntax used is the IA5String . IA5String ::= OCTET STRING The IA5String is a notational convenience to indicate that, although strings of IA5String type encode as OCTET STRING types, the legal character set in such a string is limited to the IA5 character set. The reasoning behind using the IA5StringSyntax is that, since ASCII-armored PGPkey as it is produced by PGP software today consists of serveral pieces separated by linebreaks, it can only be stored in X.500 without modifications if the attribute syntax choosen allows the complete ASCII characterset. The slight modification that might be necessary is due to the fact that linebreaks are defined differently in different Operating systems. The linebreaks stored in X.500 is therefore defined to consist of the pair CR (0x0d) plus LF (0x0a). Multiple pGPkey values for one object seems not to be the normal case, but should not be ruled out. pGPkeyIDpGPKeyID and pGPUserID is needed if one wants to use a X.500 directory service to emulate a PGP key server since the key servers normally allows you to search for keyIDs as well as matching on parts of the UserID. Since one of the designcriterias was to make it ease to deploy the ideas in this draft I have choosen standard attributetypes instead of inventing new ones, therefore I have to limit pGPKey, pGPKeyID and pGPUserID to be singlevalued to keep the connection between these values. Schema Definition of pGPkeyObjectpGPKeyObject Object Class Name: pGPSecurityObjectpGPKeyObject Description: Auxiliary object class that holds pGPkeypGPKey information OID: umuAttributeType.9umuObjectClass.4 (1.2.722.214.171.124) SubclassOf: top MustContain: MayContain: pGPkey, pGPkeyRevpGPKey, pGPKeyRev, pGPUserID, pGPKeyID Discussion of the pGPkeyObjectpGPKeyObject Object Class The pGPkeyObjectpGPKeyObject class is a subclass of top and may contain the pGPkeypGPKey, pGPKeyRev, pGPUserID and pGPkeyRevpGPKeyID attributes. The intent is that this object class can be added to existing objects to allow for inclusion of pGPkeypGPKey values. It is therefore viewed as a auxiliary objectclass. This approach does not preclude including the pGPkeypGPKey attribute type directly in other object classes as appropriate. Security Considerations The basis for the use of PGP public keys are that you may validate them in two different ways if you get the public key over the net. The first way depends on the fact that the public key as it is stored and received might contain a validation by someone that the receiver already has a validated public key for. If the receiver trusts the validator then the public key can be included in the receivers keyring without further ado. If on the other hand the received public key contains no validation or no validation by someone that the receiver already has a public key for then the receiver has to resort to out-of-bands methods to validate the key. This could be using the phone or a meeting in person. If you can not validate the public key by any of the above mentioned means you should never trust the public key. Therefore the use of X.500, for storage of PGP public keys, as it stands today with almost no security in place poses no problem. Like all other PGP key servers on the net today it does NOT attempt to guarantee that a key is a valid key. References  Philip Zimmermann, "The Official PGP User's Guide"; MIT Press ISBN 0-262-74017-6  The Directory: Overview of Concepts, Models and Service. CCITT Recommendation X.500, 1988.  Information Processing Systems -- Open Systems Interconnection -- The Directory: Overview of Concepts, Models and Service. ISO/IEC JTC 1/SC21; International Standard 9594-1, 1988.  Howes, T., Rossen, K., Sataluri, S., and Wright, R., "Procedures for Formalizing, Evolving, and Maintaining the Internet X.500 Directory Schema", Internet Draft (Work In Progress) of the Schema Working Group, <URL:ftp://ds.internic.net/internet-drafts/draft- howes-x500-schema-02.txt>  Atkins, D., Stallings, W. and Zimmerman, P., "PGP Message Exchange Formats", Internet Draft (Work in progress), <URL:ftp://ds.internic.net/internet-drafts/draft-pgp-pgpformat-00.txt> Author's Address Roland Hedberg Umdac Umea University S-901 87 Umea, Sweden Phone: +46 90 165165 Fax: +46 90 166766 EMail: Roland.Hedberg@umdac.umu.se This Internet Draft expires February 10th,March 20th, 1996.