ASID Working Group                                       Roland Hedberg
INTERNET-DRAFT                                          Umea University
<draft-ietf-asid-pgp-01.txt>                          20 September 1995
Expires: 20 March 1996





       Definition 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
   (ietf-asid@umich.edu).


Abstract

   Pretty Good Privacy (PGP) as definied by [1] 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 [4].








Hedberg                                                           [Page 1]


INTERNET-DRAFT        X.500 pGPKey Attribute Type            20 September 1995


Schema Definition of PGPkey Attribute Types

   Name:             pGPKey
   ShortName:
   Description:      PrettyGoodPrivacy public encryptionkey
   OID:              umuAttributeType.9 (1.2.752.17.1.9)
   Syntax:           IA5String
   SizeRestriction:  None
   SingleValued:     True

   Name:             pGPKeyRev
   ShortName:
   Description:      PrettyGoodPrivacy public encryptionkey
                     revocation
   OID:              umuAttributeType.10 (1.2.752.17.1.10)
   Syntax:           IA5String
   SizeRestriction:  None
   SingleValued:     False

   Name:             pGPKeyID
   ShortName:
   Description:      PrettyGoodPrivacy encryptionkey key ID
   OID:              umuAttributeType.12 (1.2.752.17.1.12)
   Syntax:           caseIgnoreString
   SizeRestriction:  None
   SingleValued:     True


   Name:             pGPUserID
   ShortName:
   Description:      PrettyGoodPrivacy encryptionkey user ID
   OID:              umuAttributeType.13 (1.2.752.17.1.13)
   Syntax:           caseIgnoreString
   SizeRestriction:  None
   SingleValued:     True


Discussion of the pGPKey Attribute Types

   The value for pGPKey and pGPKeyRev that is to be stored in
   X.500 is the ASCII armored text format [5], 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.

Hedberg                                                           [Page 2]


INTERNET-DRAFT        X.500 pGPKey Attribute Type            20 September 1995


   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).

   pGPKeyID 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 pGPKeyObject Object Class

   Name:              pGPKeyObject
   Description:       Auxiliary object class that holds pGPKey
                      information
   OID:               umuObjectClass.4 (1.2.752.17.3.4)
   SubclassOf:        top
   MustContain:
   MayContain:        pGPKey, pGPKeyRev, pGPUserID, pGPKeyID


Discussion of the pGPKeyObject Object Class

   The pGPKeyObject class is a subclass of top and may contain the
   pGPKey, pGPKeyRev, pGPUserID and pGPKeyID attributes.  The
   intent is that this object class can be added to existing objects
   to allow for inclusion of pGPKey values. It is therefore viewed
   as a auxiliary objectclass.
   This approach does not preclude including the pGPKey
   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.

Hedberg                                                           [Page 3]


INTERNET-DRAFT        X.500 pGPKey Attribute Type            20 September 1995


References

   [1] Philip Zimmermann,
   "The Official PGP User's Guide";
   MIT Press
   ISBN 0-262-74017-6

   [2] The Directory: Overview of Concepts, Models and Service. CCITT
   Recommendation X.500, 1988.

   [3] Information Processing Systems -- Open Systems Interconnection --
   The Directory: Overview of Concepts, Models and Service.
   ISO/IEC JTC 1/SC21; International Standard 9594-1, 1988.

   [4] 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>

   [5] 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 March 20th, 1996.






















Hedberg                                                           [Page 4]