Subject: Incorporaion of PGP Certificates into X.509v3 Certificates.

From: Maxim Masiutin <[email-masked]>
Date: Mon, 3 Apr 2000 13:58:04 +0300

Hello!

   I tried to submit "Incorporaion of PGP Certificates into X.509v3
   Certificates" draft, but it was IETF meeting. I post my draft here
   until IETF will be ready to accept new drafts. You comments are very
   welcome.

Internet Draft                                      M. Masiutin
                                                    RITLABS
April 3, 2000
expires in six months

   Incorporaion of PGP Certificates into X.509v3 Certificates.

   Copyright 2000 by The Internet Society. All Rights Reserved.

Status of this memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026. 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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

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

Abstract

   There were currently no described provisions to convert from an
   X.509v3 certificate to a PGP Certificate and vice versa because of
   format of data being signed differ in these two standards. This
   document defines a new X.509v3 certificate extension called pgpKey
   that holds a verbatim PGP Certificate, making such conversion
   possible.

   This draft is being discussed on the "[email-masked]" mailing
   list. To join the list, send a message to <[email-masked]>
   with the single word "subscribe" in the body of the message. Also,
   there is a Web site for the mailing list at
   <http://www.imc.org/ietf-pkix>.

Definitions, Abbreviations, and Symbols

   UserID

     Data that is intended to represent the name and email address of
     the key holder.

   KeyMaterial
  
     Public key material, i.e. data used as a key in encryption and/or
     signature checking operation.

   PubKey

     KeyMaterial and one or more associated user UserIDs.

   PGPCert

     Also referred as Transferable PGP Certificate. Signed PubKey; after
     each UserID, zero or more signatures (certifications) follow.

   X509Cert

     X.509v3 certificate, as defined in [X509] secion 4.

   X509NativeCert

     X.509v3 certificate, without PGPKey extension.
   
   X509PGPCert

     X.509v3 certificate, with PGPKey extension.

   S/MIME

     Secure/Multipurpose Internet Mail Extensions
     
   PGP/MIME

     Pretty Good Privacy/Multipurpose Internet Mail Extensions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [MUSTSHOULD].

   The key words starting with X509- are defined in [X509] without X509-
   prefix.

Introduction

   There are currently two actively proposed methods for providing
   security services for e-mail: S/MIME and PGP/MIME. Both methods
   are based on RFC's that have IETF standards track status.

   PGP/MIME is based on [OpenPGP] message and certificate formats that
   were derived from [PGPOld] formats. These formats were created from
   scratch, and use simple binary encoding. [PGPOld] defines [RSA],
   [IDEA] and [MD5] algorithms as mandatory. OpenPGP makes these
   algorithms optional.

   S/MIME was originally developed by RSA Data Security, Inc. It is
   based on the [CMS] data format for the messages, and the [X509]
   format for certificates. [CMS] is a successor of [PKCS7]. [PKCS7] is
   based on the [ASN1] DER format for data.

   Of course, having two protocols that do the same thing is much worse
   than having one. Although they offer similar services to users, the
   two protocols have very different formats. Further, and more
   important to users, they have different formats for their
   certificates. This means that not only can users of one protocol not
   communicate with the users of the other, they also cannot share
   authentication certificates.

   This document defines a combined format of certificates. It also
   proposes a solution for applications that support both S/MIME and
   PGP/MIME.

   Applications that support both S/MIME and PGP/MIME get a possibility
   to have a single repository that keeps not only X509NativeCerts but
   also X509PGPCerts converted from PGPCerts. No separate
   [OpenPGP]-compatible public keyrings is needed in that case, thus
   such keyrings as well as single PGPCerts may be imported from and
   exported to that repository. There is no need of two different user
   interfaces for X509Cert repository and [OpenPGP]-keyring. Users of
   such applications may not even know the differences between S/MIME
   and PGP/MIME, X509Cert and PGPCert.

Implementing this specification
   
   Implementation of this specification must be done in such manner that
   it should not contradict with provisions of [OpenPGP], [X509] and
   [ESS].

Certificate Extension

   This document defines a new X509Cert extension called pgpKey that
   holds a verbatim PGPCert. Same KeyMaterial and keyholder's data is
   packed in X509Cert and PGPCert, but different packing methods are
   used, to conform both [OpenPGP] and [X509] standards.

   Defined extension is in full conformance with X509-Extension and MUST
   be non-critical. As each extension includes an associated object
   identifier (OID) and an [ASN1] structure, pgpKey extension has the
   following [ASN1] definition:

   id-ce-pgpKey OBJECT IDENTIFIER  ::= {??????????}

   pgpKey  ::= SEQUENCE {
     pgpKeyContents        pgpKeyContentsChoice
   }

   pgpKeyContentsChoice  ::= CHOICE
     pgpKeySingleVersion     [0] OCTET STRING
     pgpKeyAlternative       [1] pgpKeyAlternativeVersions }

   pgpKeyAlternativeVersions  ::= SEQUENCE
     pgpKeySignV3           OCTET STRING,
     pgpKeySignV4           OCTET STRING}

   If an OpenPGP certificate is available in two versions, [PGPOld]
   (for compatibility with old applications) and [OpenPGP] (allowing
   signature extensions), pgpKeyAlternative should be choosen. Otherwise,
   pgpKeySingleVersion should be choosen.

Data Being Certified

   There are some restrictions on X509-subject structure for
   X509PGPCert. X509-subject MUST contain a single DistinguishedName in
   an X509-RDNSequence. X509-RelativeDistinguishedName MUST contain a
   single occurrence of type X509-emailAddress, X509-id-at-name, and
   X509-id-at-commonName, which are defines in [X509]. Value of
   X509-emailAddress MUST match X509-subjectAltName extension. No UTF-8
   strings are allowed. No characters that require quoting in [RFC822]
   e-mail address are allowed by this specification, although there are
   no restrictions on format of other data containded in
   X509-RelativeDistinguishedName. Value of X509-emailAddress MUST match
   X509-id-at-commonName. Incorporated OpenPGP certificate MUST have at
   least one UserID packet bound to the same public key which is packed
   into X509-SubjectPublicKeyInfo. Although OpenPGP format makes no
   restriction on contents of UserID packet (chapter 5.11 of [OpenPGP]),
   this specification does define, in a form of [ABNF]-like notation

   User-ID = X509-id-at-name " <" X509-emailAddress ">"

   Contents of UserID of incorporated PGPCert MUST be formed by a rule
   described above. This UserID must be associated with the same
   KeyMaterial as in X509-SubjectPublicKeyInfo, and signed by the same
   issuer's key. Issuer's key is identified by AuthorityKeyIdentifier
   extension. Other UserIDs may also exist in an incorporated PGPcert.

Choosing between pgpKeySingleVersion and pgpKeyAlternativeVersions

   When pgpKey extension is assembled for a new X509Cert certificate
   that is created along with a new PGPCert, and it is possible to
   produce a PGPCert readable by [PGPOld]-applications,
   pgpKeyAlternativeVersions should be choosen. PubKey should be signed
   using Version 3 and Version 4 OpenPGP Signature Packets, resulting
   two PGPCerts. This can be done, for example, by a certification
   authority using data presented in a certification request, or by an
   end-user application that generates a self-signed certificate.

   When pgpKey certificate extension is created from an existing
   PGPCert, or when it is unable to produce a PGPCert readable by
   [PGPOld]-applications (e.g. [RSA] algorithm is unavailable or
   undesirable), pgpKeySingleVersion should be choosen. Such PgpCert
   should be put inside OCTET STRING of pgpKeySingleVersion, regardless
   versions of signature packets used. Unnecessary or untrusted UserIDs
   and/or signatures may be stripped. This can be done, for example, by
   an applications that support both S/MIME, PGP/MIME, when a user
   imports a PGPCert taken from a PGP keyserver into a X509Cert
   repository of his/her e-mail client.

pgpKeyAlternative

   pgpKeyAlternative holds two versions of OpenPGP certificate, one of
   which MUST be in full conformance with [PGPOld], other SHOULD contain
   OpenPGP Signature Packets Version 4 with possible subpackets.

   As [RSA] algorithm is mandatory by [PGPOld], pgpKeyAlternative may
   only occur in X509Certs that use [RSA] public keys, i.e.
   signatureAlgorithm must be [RSA]-based. Examples are [RSA]-based
   signature algorithm identifiers ([ASN1] OIDS) are
   md2WithRSAEncryption, md5WithRSAEncryption and sha1WithRSAEncryption
   (see Security Issues chapter).

   KeyMaterial, associated UserIDs, signing keys, and all other data,
   such as number of UserIDs and signatures, as well as order of packets
   above mentioned, used to produce a PGPCert for pgpKeySignV3 MUST also
   be used without a change or addition to produce a PGPCert for
   pgpKeySignV4. OpenPGP certificate of pgpKeySignV4 may contain
   signature subpacket(s) that are not allowed by version 3 of OpenPGP
   Signature Packet Format.

   To produce a valid pgpKeyAlternative, [RSA] KeyMaterial and
   associated User IDs should be:

   1) signed using PGP Signature Packet Version 3 as defined in Section
   5.2.2 of [OpenPGP] by means of algorithms required by [PGPOld] ([RSA]
   and [MD5]) making it readable by [PGPOld]-applications. Resulting
   PGPCert should be put inside OCTET STRING of pgpKeySignV3.

   2) signed using OpenPGP Signature Packet Version 4 with all possible
   subpackets as defined in Section 5.2.3 of [OpenPGP], making it
   readable by [OpenPGP]-applications. The same [RSA] KeyMaterial as for
   previous step should be used to produce a signature, but a different
   hashing method is allowed. Resulting OpenPGP certificate should put
   be inside OCTET STRING of pgpKeySignV4.

Converting from existing PgpCert
   
   Primary KeyMaterial and primary UserID of a given PgpCert are used to
   form the X509-subject and X509-subjectPublicKeyInfo members of
   X509-TBSCertificate. An application may display a dialog of choices,
   allowing user to select which UserID is primary. An application
   should also validate signatures of UserIDs. Selected UserId is
   parsed, according to [RFC822], to extract a user name and an e-mail
   address. If it was unable to extract a valid e-mail address, an
   application shouldn't convert given PgpCerts. Extracted data should
   be used to produce a valid X509-subject structure, as defined in
   "Data Being Certified" chapter.

   If it was unable to extract a valid user name, but an e-mail was
   extracted, an application should copy this e-mail string to all
   fields containing user name that are mandatory by this document or
   may be mandatory by other documents.

Security Considerations

   All security considerations from [OpenPGP], [X509] and [ESS] apply to
   applications that use procedures described in this document. Security
   rules for X509PGPCert are the same as for a pair of a separate
   PGPCert and a separate X509NativeCert.

   As md2WithRSAEncryption is referred in this document, it SHOULD not
   be used. As about md5WithRSAEncryption and sha1WithRSAEncryption, the
   [MD5] hash algorithm has been found to have weaknesses
   (pseudo-collisions in the compress function) that make some people
   deprecate its use. They consider the [SHA1] algorithm better.

References

   [ASN1]

      CCITT Recommendation X.208: Specification of Abstract Syntax
      Notation One (ASN.1), 1988.

   [SHA1]

     NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.

   [IDEA]

     Lai, X, "On the design and security of block ciphers", ETH Series
     in Information Processing, J.L. Massey (editor), Vol. 1,
     Hartung-Gorre Verlag Knostanz, Technische Hochschule (Zurich), 1992

   [MD5]

     The MD5 Message-Digest Algorithm. R. Rivest. April 1992. RFC1321.

   [RSA]

     PKCS #1: RSA Cryptography Specifications Version 2.0. B. Kaliski,
     J. Staddon. October 1998. RFC2437.

   [RFC2234]

     Augmented BNF for Syntax Specifications: ABNF. D. Crocker, Ed., P.
     Overell. November 1997. RFC2234.

   [RFC822]

     Standard for the format of ARPA Internet text messages. D. Crocker.
     13 August 1982. STD0011, RFC882.

   [PGPOld]

     PGP Message Exchange Formats. D. Atkins, W. Stallings & P.
     Zimmermann. August 1996. RFC1991.

   [OpenPGP]

     OpenPGP Message Format. J. Callas, L. Donnerhacke, H. Finney, R.
     Thayer. November 1998. RFC2440.

   [X509]

     Internet X.509 Public Key Infrastructure Certificate and CRL
     Profile. R. Housley, W. Ford, W. Polk, D. Solo. January 1999.
     RFC2459.

   [CMS]
   
     Cryptographic Message Syntax. R. Housley. June 1999. RFC2630.

   [MUSTSHOULD]
   
     Key words for use in RFCs to Indicate Requirement Levels. S.
     Bradner. March 1997. BCP0014, RFC2119.
     
   [ESS]

     Enhanced Security Services for S/MIME. P. Hoffman, Ed.. June
     1999. RFC2634.

   [PKCS7]

     PKCS 7: Cryptographic Message Syntax Version 1.5. B. Kaliski.
     March 1998. RFC2315.

Author's Address

   Maxim Masiutin
   RITLABS S.R.L.
   180 Stefan cel Mare
   Chisinau MD2004
   Republic of Moldova
   [email-masked]
   fax: +373-2-246530

Full Copyright Statement

Copyright (C) The Internet Society 2000.  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.   

-- 
Max Masyutin,
Software Engineer
RIT Research Labs  http://www.ritlabs.com/

---

From: Borselius N <[email-masked]>
Date: Thu, 6 Apr 2000 23:24:41 +0100

Maxim,

If I understand it correctly you are storing signed PGP keys within an X.509
extension. I suppose it makes sense for compatibility reasons but does look
a bit awkward at a first look, to store signed information along with the
signature itself (that's how PGP certs are constructed) within a X.509
field.

I am not fully clued up with PGP, (so please excuse my possibly silly
questions). I know PGP does encoding differently from other apps such as
S/MIME but does PGP use any of the same algorithms that are specified RFC
2459? And would it be possible to separate the information stored in a PGP
certificate (such as public key, owner identity, signature, algorithm ...)?

Cheers,
Niklas

-----Original Message-----
From: Maxim Masiutin [mailto:[email-masked]]
Sent: 03 April 2000 11:58
To: [email-masked]
Subject: Incorporaion of PGP Certificates into X.509v3 Certificates.

Hello!

--- snip