Jump to content

Privacy-Enhanced Mail: Difference between revisions

From Wikipedia, the free encyclopedia
Browse history interactively
← Previous editNext edit →
Content deleted Content added
VisualWikitext
Tags: Mobile edit Mobile web edit
m →‎Format: {{code}}
Line 6: Line 6:
Many cryptography standards use [[Abstract Syntax Notation One|ASN.1]] to define their data structures, and [[X.690#DER encoding|Distinguished Encoding Rules]] (DER) to serialize those structures.<ref>{{Cite IETF|rfc=7468|section=1|title=Textual Encodings of PKIX, PKCS, and CMS Structures|last=Sean|first=Leonard|last2=Simon|first2=Josefsson|date=April 2015||language=en|access-date=2017-03-06}}</ref> Because DER produces [[Binary file|binary]] output, it can be challenging to transmit the resulting files through systems, like electronic mail, that only support ASCII.
Many cryptography standards use [[Abstract Syntax Notation One|ASN.1]] to define their data structures, and [[X.690#DER encoding|Distinguished Encoding Rules]] (DER) to serialize those structures.<ref>{{Cite IETF|rfc=7468|section=1|title=Textual Encodings of PKIX, PKCS, and CMS Structures|last=Sean|first=Leonard|last2=Simon|first2=Josefsson|date=April 2015||language=en|access-date=2017-03-06}}</ref> Because DER produces [[Binary file|binary]] output, it can be challenging to transmit the resulting files through systems, like electronic mail, that only support ASCII.


The PEM format solves this problem by encoding the binary data using [[Base64encoded|base64]]. PEM also defines a one-line header, consisting of "-----BEGIN ", a label, and "-----", and a one-line footer, consisting of "-----END ", a label, and "-----". The label determines the type of message encoded. Common labels include "CERTIFICATE", "CERTIFICATE REQUEST", "PRIVATE KEY" and "X509 CRL".
The PEM format solves this problem by encoding the binary data using [[Base64encoded|base64]]. PEM also defines a one-line header, consisting of {{code|-----BEGIN }}, a label, and {{code|-----}}, and a one-line footer, consisting of {{code|-----END }}, a label, and {{code|-----}}. The label determines the type of message encoded. Common labels include {{code|CERTIFICATE}}, {{code|CERTIFICATE REQUEST}}, {{code|PRIVATE KEY}} and {{code|X509 CRL}}".


PEM data is commonly stored in files with a ".pem" suffix, a ".cer" or ".crt" suffix (for certificates), or a ".key" suffix (for public or private keys).<ref>{{Cite web|url=https://web.archive.org/web/20190804070022/http://www.gtopia.org/blog/2010/02/der-vs-crt-vs-cer-vs-pem-certificates/|title=DER vs. CRT vs. CER vs. PEM Certificates and How To Convert Them|website=www.gtopia.org|access-date=2020-02-04}}</ref> The label inside a PEM file represents the type of the data more accurately than the file suffix, since many different types of data can be saved in a ".pem" file.
PEM data is commonly stored in files with a ".pem" suffix, a ".cer" or ".crt" suffix (for certificates), or a ".key" suffix (for public or private keys).<ref>{{Cite web|url=https://web.archive.org/web/20190804070022/http://www.gtopia.org/blog/2010/02/der-vs-crt-vs-cer-vs-pem-certificates/|title=DER vs. CRT vs. CER vs. PEM Certificates and How To Convert Them|website=www.gtopia.org|access-date=2020-02-04}}</ref> The label inside a PEM file represents the type of the data more accurately than the file suffix, since many different types of data can be saved in a ".pem" file.
Line 12: Line 12:
A PEM file may contain multiple instances. For instance, an operating system might provide a file containing a list of trusted [[CA certificate]]s, or a web server might be configured with a "chain" file containing an end-entity certificate plus a list of intermediate certificates.
A PEM file may contain multiple instances. For instance, an operating system might provide a file containing a list of trusted [[CA certificate]]s, or a web server might be configured with a "chain" file containing an end-entity certificate plus a list of intermediate certificates.


<syntaxhighlight lang="text">
<syntaxhighlight lang="pem">
-----BEGIN PRIVATE KEY-----
-----BEGIN PRIVATE KEY-----


Revision as of 01:49, 31 August 2021

Internet security
protocols
Key management
Application layer
Domain Name System
Internet Layer

Privacy-Enhanced Mail (PEM) is a de facto file format for storing and sending cryptographic keys, certificates, and other data, based on a set of 1993 IETF standards defining "privacy-enhanced mail." While the original standards were never broadly adopted and were supplanted by PGP and S/MIME, the textual encoding they defined became very popular. The PEM format was eventually formalized by the IETF in RFC 7468.[1]

Format

Many cryptography standards use ASN.1 to define their data structures, and Distinguished Encoding Rules (DER) to serialize those structures.[2] Because DER produces binary output, it can be challenging to transmit the resulting files through systems, like electronic mail, that only support ASCII.

The PEM format solves this problem by encoding the binary data using base64. PEM also defines a one-line header, consisting of -----BEGIN, a label, and -----, and a one-line footer, consisting of -----END, a label, and -----. The label determines the type of message encoded. Common labels include CERTIFICATE, CERTIFICATE REQUEST, PRIVATE KEY and X509 CRL".

PEM data is commonly stored in files with a ".pem" suffix, a ".cer" or ".crt" suffix (for certificates), or a ".key" suffix (for public or private keys).[3] The label inside a PEM file represents the type of the data more accurately than the file suffix, since many different types of data can be saved in a ".pem" file.

A PEM file may contain multiple instances. For instance, an operating system might provide a file containing a list of trusted CA certificates, or a web server might be configured with a "chain" file containing an end-entity certificate plus a list of intermediate certificates. 

-----BEGIN PRIVATE KEY-----

-----END PRIVATE KEY-----

Privacy-enhanced mail

The PEM format was first developed in the privacy-enhanced mail series of RFCs: RFC 1421, RFC 1422, RFC 1423, and RFC 1424. These standards assumed prior deployment of a hierarchical public key infrastructure (PKI) with a single root. Such a PKI was never deployed, due to operational cost and legal liability concerns.[citation needed] These standards were eventually obsoleted by PGP and S/MIME, competing e-mail encryption standards.[citation needed]

History

The initiative to develop Privacy Enhanced Mail began in 1985 on behalf of the PSRG (Privacy and Security Research Group) [4] also known as the Internet Research Task Force.

References

  1. ^ Johnson, Mike (1995-10-01). "Cryptology in Cyberspace". Cryptologia. 19 (4): 392–396. doi:10.1080/0161-119591884042. ISSN 0161-1194.
  2. ^ Sean, Leonard; Simon, Josefsson (April 2015). Textual Encodings of PKIX, PKCS, and CMS Structures. sec. 1. doi:10.17487/RFC7468. RFC 7468. Retrieved 2017-03-06.
  3. ^ "DER vs. CRT vs. CER vs. PEM Certificates and How To Convert Them". www.gtopia.org. Retrieved 2020-02-04.
  4. ^ Kent, S. (1993). "Internet Privacy Enhanced Mail". Communications of the ACM. doi:10.1145/163381.163390.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Privacy-Enhanced_Mail&oldid=1041528895"