Internet Draft M. Masiutin RITLABS April 8, 2000 expires in six months Incorporaion of PGP Certificates into X.509v3 Certificates. draft-masiutin-x509pgp-00.txt 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 "x509pgp@egroups.com" mailing list. To join the list, send a message to Also, there is a Web site for the mailing list at 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 ::= {iso(1) org(3) dod(6) internet(1) private(4) enterprise(1) ritlabs(5898) 1 1} PGPKey ::= SEQUENCE { pgpKeyContents PGPKeyContents } PGPKeyContents ::= CHOICE { pgpKeySingleVersion [0] OCTET STRING pgpKeyAlternative [1] PGPKeyAlternative } PGPKeyAlternative ::= 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 pgpKeyAlternative 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, pgpKeyAlternative 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 max@ritlabs.com 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.