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 .
41-398: Many cryptography standards use ASN.1 to define their data structures, and Distinguished Encoding Rules (DER) to serialize those structures. 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
82-486: A ".key" suffix (for public or private keys). 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. In particular PEM refers to the header and base64 wrapper for a binary format contained within, but does not specify any type or format for the binary data, so that a PEM file may contain "almost anything base64 encoded and wrapped with BEGIN and END lines". The PEM format
123-477: A bit more complex to decode by software on usual processors because it will require additional contextual bit-shifting and masking and not direct byte addressing (but the same remark would be true with modern processors and memory/storage units whose minimum addressable unit is larger than 1 octet). However modern processors and signal processors include hardware support for fast internal decoding of bit streams with automatic handling of computing units that are crossing
164-475: A cross-platform way. It is broadly used in telecommunications and computer networking , and especially in cryptography . Protocol developers define data structures in ASN.1 modules, which are generally a section of a broader standards document written in the ASN.1 language. The advantage is that the ASN.1 description of the data encoding is independent of a particular computer or programming language. Because ASN.1
205-400: A graphical notation. The Specification and Description Language provides both a graphical Graphic Representation (SDL/GR) as well as a textual Phrase Representation (SDL/PR), which are both equivalent representations of the same underlying semantics. Models are usually shown in the graphical SDL/GR form, and SDL/PR is mainly used for exchanging models between tools. A system is specified as
246-459: A module can specify an integer field that must be in the range 0 to 100. The length of a sequence of values (an array) can also be specified, either as a fixed length or a range of permitted lengths. Constraints can also be specified as logical combinations of sets of basic constraints. Values used as constraints can either be literals used in the PDU specification, or ASN.1 values specified elsewhere in
287-549: A number of predefined encoding rules. If none of the existing encoding rules are suitable, the Encoding Control Notation (ECN) provides a way for a user to define his or her own customized encoding rules. Privacy-Enhanced Mail (PEM) encoding is entirely unrelated to ASN.1 and its codecs, but encoded ASN.1 data, which is often binary, is often PEM-encoded so that it can be transmitted as textual data, e.g. over SMTP relays, or through copy/paste buffers. This
328-405: 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
369-518: A schema, making them easy to use. They are also both cross-platform standards that are broadly popular for communications protocols, particularly when combined with a JSON schema or XML schema . Some ASN.1 tools are able to translate between ASN.1 and XML schema (XSD). The translation is standardised by the ITU. This makes it possible for a protocol to be defined in ASN.1, and also automatically in XSD. Thus it
410-402: A set of interconnected abstract machines which are extensions of finite-state machines (FSM). The language is formally complete , so it can be used for code generation for either simulation or final targets. The Specification and Description Language covers five main aspects: structure, communication, behavior, data, and inheritance. The behavior of components is explained by partitioning
451-536: A single and readily usable open-source implementation, and is published as a specification to be implemented by third-party vendors. However, ASN.1, defined in 1984, predates them by many years. It also includes a wider variety of basic data types, some of which are obsolete, and has more options for extensibility. A single ASN.1 message can include data from multiple modules defined in multiple standards, even standards defined years apart. ASN.1 also includes built-in support for constraints on values and sizes. For instance,
SECTION 10
#1732775833719492-528: Is a specification language targeted at the unambiguous specification and description of the behaviour of reactive and distributed systems . The ITU-T has defined SDL in Recommendations Z.100 to Z.106. SDL originally focused on telecommunication systems; As of 2016 its current areas of application include process control and real-time applications in general. Due to its nature it can be used to represent simulation systems without ambiguity and with
533-481: Is a type–length–value encoding, so the sequence above can be interpreted, with reference to the standard SEQUENCE, INTEGER, and IA5String types, as follows: Alternatively, it is possible to encode the same ASN.1 data structure with XML Encoding Rules (XER) to achieve greater human readability "over the wire". It would then appear as the following 108 octets, (space count includes the spaces used for indentation): Alternatively, if Packed Encoding Rules are employed,
574-471: Is a state machine that contributes to the action carried out by the system. A message stimulus coming from the environment or from another agent to an agent is called a signal. Signals received by a process agent are first placed in a queue (the input port). When the state machine is waiting in a state, if the first signal in the input port is enabled for that state it starts a transition leading to another state. Transitions can output signals to other agents or to
615-468: Is an example ASN.1 module defining the messages (data structures) of a fictitious Foo Protocol: This could be a specification published by creators of Foo Protocol. Conversation flows, transaction interchanges, and states are not defined in ASN.1, but are left to other notations and textual description of the protocol. Assuming a message that complies with the Foo Protocol and that will be sent to
656-918: Is both human-readable and machine-readable , an ASN.1 compiler can compile modules into libraries of code, codecs , that decode or encode the data structures. Some ASN.1 compilers can produce code to encode or decode several encodings, e.g. packed, BER or XML . ASN.1 is a joint standard of the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) in ITU-T Study Group 17 and International Organization for Standardization / International Electrotechnical Commission (ISO/IEC), originally defined in 1984 as part of CCITT X.409 :1984. In 1988, ASN.1 moved to its own standard, X.208 , due to wide applicability. The substantially revised 1995 version
697-511: Is covered by the X.680 series. The latest revision of the X.680 series of recommendations is the 6.0 Edition, published in 2021. ASN.1 is a data type declaration notation. It does not define how to manipulate a variable of such a type. Manipulation of variables is defined in other languages such as SDL (Specification and Description Language) for executable modeling or TTCN-3 (Testing and Test Control Notation) for conformance testing. Both these languages natively support ASN.1 declarations. It
738-399: Is made of functional blocks and each block can be further decomposed in sub-blocks. The lowest level block is composed of one process or several processes described as finite-state machines. [REDACTED] Blocks are connected through channels that carry the messages (or signals) exchanged between the blocks. A block agent consists of process agents. [REDACTED] Each process agent
779-428: Is not used to define type–length–value encodings. Many programming languages define language-specific serialization formats. For instance, Python's "pickle" module and Ruby's "Marshal" module. These formats are generally language specific. They also don't require a schema, which makes them easier to use in ad hoc storage scenarios, but inappropriate for communications protocols. JSON and XML similarly do not require
820-566: Is possible (though perhaps ill-advised) to have in a project an XSD schema being compiled by ASN.1 tools producing source code that serializes objects to/from JSON wireformat. A more practical use is to permit other sub-projects to consume an XSD schema instead of an ASN.1 schema, perhaps suiting tools availability for the sub-projects language of choice, with XER used as the protocol wireformat. For more detail, see Comparison of data serialization formats . Specification and Description Language Specification and Description Language ( SDL )
861-457: Is possible to import an ASN.1 module and declare a variable of any of the ASN.1 types declared in the module. ASN.1 is used to define a large number of protocols. Its most extensive uses continue to be telecommunications, cryptography, and biometrics. ASN.1 is closely associated with a set of encoding rules that specify how to represent a data structure as a series of bytes. The standard ASN.1 encoding rules include: ASN.1 recommendations provide
SECTION 20
#1732775833719902-441: Is the start transition that initializes the local variable. A connection request message conReq is sent, a 5 seconds timer conReqTimer is started, and the state machine goes to the connecting state. In the connecting state if the timer goes off -that is equivalent to a message receive- the connection request is sent again up to 10 times. If a connection confirmation is received the state machine goes to connected state. This
943-418: Is the latest version, an updated version of SDL-2000 that was completely based on object-orientation, rather than description by transformations. This version is accompanied by a UML -Profile: ITU-T Recommendation Z.109 (04/12), SDL-2010 combined with UML. SDL-2010 also introduced the support of C data types as initially introduced by SDL-RT. The hierarchy level of SDL is structured as follows. An SDL system
984-492: Is visually similar to Augmented Backus-Naur form (ABNF), which is used to define many Internet protocols like HTTP and SMTP . However, in practice they are quite different: ASN.1 defines a data structure, which can be encoded in various ways (e.g. JSON, XML, binary). ABNF, on the other hand, defines the encoding ("syntax") at the same time it defines the data structure ("semantics"). ABNF tends to be used more frequently for defining textual, human-readable protocols, and generally
1025-758: The PSRG (Privacy and Security Research Group) also known as the Internet Research Task Force. This task force is a subsidiary of the Internet Architecture Board (IAB) and their efforts have resulted in the Requests for Comment (RFCs) which are suggested Internet guidelines. Abstract Syntax Notation One Abstract Syntax Notation One ( ASN.1 ) is a standard interface description language (IDL) for defining data structures that can be serialized and deserialized in
1066-490: The answers array between 1 and 10 elements. The anArray field is a fixed length 100 element array of integers that must be in the range 0 to 1000. The '...' extensibility marker means that the FooHistory message specification may have additional fields in future versions of the specification; systems compliant with one version should be able to receive and transmit transactions from a later version, though able to process only
1107-410: The boundaries of addressable storage units (this is needed for efficient processing in data codecs for compression/decompression or with some encryption/decryption algorithms). If alignment on octet boundaries was required, an aligned PER encoder would produce: (in this case, each octet is padded individually with null bits on their unused most significant bits). Most of the tools supporting ASN.1 do
1148-408: The encoded PER are padded with null bits in the 6 least significant bits of the last byte c0 : these extra bits may not be transmitted or used for encoding something else if this sequence is inserted as a part of a longer unaligned PER sequence. This means that unaligned PER data is essentially an ordered stream of bits, and not an ordered stream of bytes like with aligned PER, and that it will be
1189-415: The encoder knows that encoding an IA5String byte value requires only 7 bits. However the length bytes are still encoded here, even for the first integer tag 01 (but a PER packer could also omit it if it knows that the allowed value range fits on 8 bits, and it could even compact the single value byte 05 with less than 8 bits, if it knows that allowed values can only fit in a smaller range). The last 6 bits in
1230-402: The environment. A process agent is allowed to contain procedure types so that the same actions can be invoked from different places. It is also allowed to call a remote procedure type to invoke a procedure in another agent (or even another system) and wait for a response. [REDACTED] In this example MyVariable is of type INTEGER and is the only variable in the process. The first transition
1271-488: The fields specified in the earlier version. Good ASN.1 compilers will generate (in C, C++, Java, etc.) source code that will automatically check that transactions fall within these constraints. Transactions that violate the constraints should not be accepted from, or presented to, the application. Constraint management in this layer significantly simplifies protocol specification because the applications will be protected from constraint violations, reducing risk and cost. To send
Privacy-Enhanced Mail - Misplaced Pages Continue
1312-472: The following 122 bits (16 octets amount to 128 bits, but here only 122 bits carry information and the last 6 bits are merely padding) will be produced: In this format, type tags for the required elements are not encoded, so it cannot be parsed without knowing the expected schemas used to encode. Additionally, the bytes for the value of the IA5String are packed using 7-bit units instead of 8-bit units, because
1353-492: The following: A list of tools supporting ASN.1 can be found on the ITU-T Tool web page . ASN.1 is similar in purpose and use to Google Protocol Buffers and Apache Thrift , which are also interface description languages for cross-platform data serialization. Like those languages, it has a schema (in ASN.1, called a "module"), and a set of encodings, typically type–length–value encodings. Unlike them, ASN.1 does not provide
1394-440: The generated serialization / deserialization routines, raising errors or exceptions if out-of-bounds data is encountered. It is complex to implement all aspects of ASN.1 constraints in an ASN.1 compiler. Not all tools support the full range of possible constraints expressions. XML schema and JSON schema both support similar constraints concepts. Tool support for constraints varies. Microsoft's xsd.exe compiler ignores them. ASN.1
1435-522: The myQuestion message through the network, the message is serialized (encoded) as a series of bytes using one of the encoding rules . The Foo protocol specification should explicitly name one set of encoding rules to use, so that users of the Foo protocol know which one they should use and expect. Below is the data structure shown above as myQuestion encoded in DER format (all numbers are in hexadecimal): DER
1476-537: The need for developers to hand code protocol constants in their implementation's source code. This significantly aids protocol development; the protocol's constants can be altered in the ASN.1 schema and all implementations are updated simply by recompiling, promoting a rapid and low risk development cycle. If the ASN.1 tools properly implement constraints checking in the generated source code, this acts to automatically validate protocol data during program operation. Generally ASN.1 tools will include constraints checking into
1517-410: The receiving party, this particular message ( protocol data unit (PDU)) is: ASN.1 supports constraints on values and sizes, and extensibility. The above specification can be changed to This change constrains trackingNumbers to have a value between 0 and 199 inclusive, and questionNumbers to have a value between 10 and 20 inclusive. The size of the questions array can be between 0 and 10 elements, with
1558-456: The schema file. Some ASN.1 tools will make these ASN.1 values available to programmers in the generated source code. Used as constants for the protocol being defined, developers can use these in the protocol's logic implementation. Thus all the PDUs and protocol constants can be defined in the schema, and all implementations of the protocol in any supported language draw upon those values. This avoids
1599-505: The system into a series of hierarchies. Communication between the components takes place through gates connected by channels. The channels are of delayed channel type, so communication is usually asynchronous, but when the delay is set to zero (that is, no delay) the communication becomes synchronous. The first version of the language was released in 1976 using graphical syntax (SDL-76). This was revised in 1980 with some rudimentary semantics (SDL-80). The semantics were refined in 1984 (SDL-84),
1640-453: The textual form was introduced for machine processing and data was introduced. In 1988, SDL-88 was released with a formal basis for the language: an abstract grammar as well as a concrete grammar and a full formal definition. The version released in 1992 (SDL-92) introduced object-oriented concepts such as inheritance, abstract generic types etc., with the object-oriented features described by transformations into non-object oriented ones. SDL-2010
1681-489: 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. These standards were eventually obsoleted by PGP and S/MIME , competing e-mail encryption standards. The initiative to develop Privacy Enhanced Mail began in 1985 on behalf of