rfc-3641

Generic String Encoding Rules (GSER) for ASN.1 Types

S. Legg
date2003-10 streamIETF wgnon working group statusPROPOSED STANDARD pages16 canonicalhttps://www.rfc-editor.org/rfc/rfc3641 doi10.17487/RFC3641
This document defines a set of Abstract Syntax Notation One (ASN.1) encoding rules, called the Generic String Encoding Rules (GSER), that produce a human readable text encoding for values of any given ASN.1 data type.

updated by

Extracted elements (25)

design-rationale §1

GSER is based on ASN.1 value notation with changes to accommodate its use as a transfer syntax and to support well-established ad-hoc string encodings for LDAP directory data types. Though primarily intended for LDAP attribute and assertion syntaxes, it can be used wherever human-readable renderings of ASN.1 values are useful.

ldap, json

design-rationale §3.13

SET values are encoded in definition order rather than in any order (as permitted by ASN.1 value notation). This is a deliberate departure from ASN.1 value notation to simplify encoding and parsing.

design-rationale §3.1

Tags and constraints are stripped from the encoding: a value of a tagged or constrained type is encoded as if the tag or constraint were absent. This simplifies the human-readable output by removing metadata that is only meaningful in binary encodings.

design-rationale §3.3

This document declares DirectoryString{} to be a ChoiceOfStrings type because the chosen alternative within a DirectoryString carries no semantic significance. This enables more compact encoding since all string alternatives ultimately produce a UTF-8 string.

ldap

interoperability-note §3.12

For DirectoryString, if the quoted string contains only PrintableString-permitted characters, the printableString alternative is assumed; otherwise the uTF8String alternative is assumed. IdentifiedChoiceValue MAY be used to explicitly indicate a different alternative, but it is a syntax error if the UTF-8 content cannot be represented in the chosen string type.

ldap

normative-requirement §1 SHOULD

If there is a discrepancy between a customized ABNF description provided by another specification and the GSER encoding defined by this document, the GSER encoding takes precedence. Specifications providing customized ABNF SHOULD state this explicitly.

normative-requirement §3.13 SHOULD

Implementations SHOULD be capable of skipping over any NamedValue encoding with an unrecognized identifier when parsing SEQUENCE or SET values, on the assumption that the sender is using a more recent definition of the type.

normative-requirement §3.12 MUST

Implementations that do not care about the internal structure of a DirectoryString MUST be able to parse the IdentifiedChoiceValue form for a DirectoryString value, even though the particular identifier found will be of no interest.

ldap

normative-requirement §3.5 MUST NOT

In a bit-list encoding of BIT STRING, each identifier MUST be one of the identifiers in the named bit list, and MUST NOT appear more than once in the same bit-list.

normative-requirement §3.3 MUST

To be eligible to be declared a ChoiceOfStrings type, an ASN.1 type MUST be a CHOICE type whose every alternative is one of the restricted string types, with all alternatives being different types, and either none or all having exactly the same constraint.

ldap

normative-requirement §5 MUST

When interpreting security-sensitive fields, especially fields used to grant or deny access, implementations MUST ensure that comparisons are done on the underlying abstract ASN.1 value, regardless of the particular encoding used.

security, ldap

protocol-element §3.3

ChoiceOfStrings types are ASN.1 CHOICE types declared to be purely syntactic (no semantic significance to the chosen alternative), where every alternative is a restricted string type and all alternatives use different string types with identical or absent constraints. Declaring a type ChoiceOfStrings allows more compact encoding.

ldap

protocol-element §4

The GSER transfer syntax is identified by OBJECT IDENTIFIER { 1 2 36 79672281 0 0 }, assigned by Adacel Technologies under an arc assigned by Standards Australia. This OID is used to describe the transfer syntax for GSER-encoded data values, e.g., in an EMBEDDED PDV value.

registry

security-consideration §5 MUST NOT

GSER does not define a canonical encoding: a round-trip through another encoding (e.g., BER) and back to GSER will not necessarily reproduce the original GSER octet sequence. Therefore, GSER MUST NOT be used where a canonical encoding is needed.

security, ldap

security-consideration §5 MUST NOT

GSER does not necessarily preserve the exact octet encoding of TeletexString, VideotexString, GraphicString, or GeneralString values, so DER-to-GSER-to-DER round-trips may not reproduce the original DER encoding. Therefore, GSER MUST NOT be used to re-encode (for storage or transmission) ASN.1 values whose original binary encoding must be recoverable, such as for verifying digital signatures.

security, crypto

wire-format §3.5

BIT STRING values are encoded as one of three forms: a named bit list (bit-list) using identifiers from the named bit list enclosed in braces, a hex string (hstring) of the form '...'H when bits are a multiple of four, or a binary string (bstring) of the form '...'B otherwise.

wire-format §3.6

BOOLEAN values are encoded as the literal strings "TRUE" or "FALSE" (ASCII uppercase). ENUMERATED values are encoded as the identifier from the enumeration list. NULL is encoded as the literal string "NULL".

wire-format §3.12

CHOICE values are encoded as IdentifiedChoiceValue (identifier ":" Value) unless the CHOICE type has been declared a ChoiceOfStrings type, in which case ChoiceOfStringsValue (a plain StringValue) MAY be used. DirectoryString is declared a ChoiceOfStrings type by this document.

ldap

wire-format §3.8

INTEGER values are encoded as "0", a positive decimal number, a negative decimal number (with leading "-"), or an identifier from the named number list if one exists. OBJECT IDENTIFIER values are encoded as dotted decimal (numeric-oid) or as an object descriptor name (descr); the descriptor form is potentially ambiguous and should be used with care.

wire-format §3.11

OCTET STRING values are encoded as a hex string (hstring) where octets appear in order, each as two hexadecimal digits with the high nibble first. An odd number of hex digits is permitted; missing low nibble is assumed zero.

wire-format §3.19 MUST

REAL values MUST be encoded as "0" for zero, "PLUS-INFINITY", "MINUS-INFINITY", an optionally signed base-10 realnumber (mantissa of the form digits[.digits] and exponent "E" digits), or as a SequenceValue for non-zero base-2 or base-10 REAL values.

wire-format §3.2

Restricted character string values (NumericString, PrintableString, TeletexString, IA5String, BMPString, UniversalString, UTF8String, etc.) are encoded as a UTF-8 string between double quotes. Embedded double quotes are escaped by repeating them. The ABNF rule is: StringValue = dquote *SafeUTF8Character dquote.

ldap

wire-format §3.13

SEQUENCE values are encoded as a ComponentList: a brace-enclosed, comma-separated list of NamedValue pairs (identifier followed by Value), with components in the order of their definition in the SEQUENCE type. SET values use the same ComponentList encoding and also encode components in definition order.

wire-format §3

The GSER encoding of any ASN.1 value is described by an ABNF <Value> rule that is a union of type-specific alternatives: BitStringValue, BooleanValue, CharacterStringValue, ChoiceValue, EnumeratedValue, IntegerValue, NullValue, ObjectIdentifierValue, OctetStringValue, RealValue, SequenceValue, SetValue, and others including VariantEncoding.

ldap

wire-format §3.20

Variant encodings override normal structural encodings for specific named types: RDNSequence (distinguished name) is encoded as a quoted LDAPDN string per RFC 2253, RelativeDistinguishedName (standalone) is encoded as a quoted name-component string per RFC 2253, and ORAddress is encoded as a quoted IA5String per RFC 2156.

ldap