RFC 3641

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

📅 published October 2003, from ietf

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

Okay bestie, this is RFC 3641, and it's giving Standards Track 📜. It was written by S. Legg at Adacel Technologies and dated October 2003. The whole thing is about GSER, a set of ASN.1 encoding rules that turn ASN.1 values into human-readable text 💖.

Status of this Memo 📌

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited ✨.

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

Abstract 🦋

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. Main character energy 👑.

Table of Contents 🌸

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
2.  Conventions. . . . . . . . . . . . . . . . . . . . . . . . . .  3
3.  Generic String Encoding Rules. . . . . . . . . . . . . . . . .  3
    3.1.  Type Referencing Notations . . . . . . . . . . . . . . .  3
    3.2.  Restricted Character String Types. . . . . . . . . . . .  4
    3.3.  ChoiceOfStrings Types. . . . . . . . . . . . . . . . . .  5
    3.4.  Identifiers. . . . . . . . . . . . . . . . . . . . . . .  6
    3.5.  BIT STRING . . . . . . . . . . . . . . . . . . . . . . .  7
    3.6.  BOOLEAN. . . . . . . . . . . . . . . . . . . . . . . . .  7
    3.7.  ENUMERATED . . . . . . . . . . . . . . . . . . . . . . .  8
    3.8.  INTEGER. . . . . . . . . . . . . . . . . . . . . . . . .  8
    3.9.  NULL . . . . . . . . . . . . . . . . . . . . . . . . . .  8
    3.10. OBJECT IDENTIFIER and RELATIVE-OID . . . . . . . . . . .  8
    3.11. OCTET STRING . . . . . . . . . . . . . . . . . . . . . .  9
    3.12. CHOICE . . . . . . . . . . . . . . . . . . . . . . . . .  9
    3.13. SEQUENCE and SET . . . . . . . . . . . . . . . . . . . . 10
    3.14. SEQUENCE OF and SET OF . . . . . . . . . . . . . . . . . 10
    3.15. CHARACTER STRING . . . . . . . . . . . . . . . . . . . . 11
    3.16. EMBEDDED PDV . . . . . . . . . . . . . . . . . . . . . . 11
    3.17. EXTERNAL . . . . . . . . . . . . . . . . . . . . . . . . 11
    3.18. INSTANCE OF. . . . . . . . . . . . . . . . . . . . . . . 11
    3.19. REAL . . . . . . . . . . . . . . . . . . . . . . . . . . 11
    3.20. Variant Encodings. . . . . . . . . . . . . . . . . . . . 12
4.  GSER Transfer Syntax . . . . . . . . . . . . . . . . . . . . . 13
5.  Security Considerations. . . . . . . . . . . . . . . . . . . . 13
6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
    6.1.  Normative References . . . . . . . . . . . . . . . . . . 13
    6.2.  Informative References . . . . . . . . . . . . . . . . . 14
7.  Intellectual Property Notice . . . . . . . . . . . . . . . . . 15
8.  Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15
9.  Full Copyright Statement . . . . . . . . . . . . . . . . . . . 16

1. Introduction ✨

Okay so this doc defines a set of ASN.1 [8] encoding rules called the Generic String Encoding Rules, or GSER 💅. They make a human readable UTF-8 [6] character string for ASN.1 values of any arbitrary ASN.1 type 🫶.

Quick but important: "ASN.1 value" does NOT mean a Basic Encoding Rules (BER) [12] encoded value 🙈. The ASN.1 value is an abstract idea that doesn't depend on any particular encoding. BER is just one possible encoding of an ASN.1 value, so no mixing them up, bestie 💀.

GSER is based on ASN.1 value notation [8], with some changes so it works as a transfer syntax. It also supports well established ad-hoc string encodings for Lightweight Directory Access Protocol (LDAP) [14] directory data types 🌈.

It's mainly meant for defining the LDAP-specific encoding of new LDAP attribute syntaxes and assertion syntaxes 🧚. But these rules could also be used in other domains where human readable renderings of ASN.1 values would be useful 🍓.

Referencing GSER is enough to define a human readable text encoding for values of a specific ASN.1 type 💖. Other specs may want to write their own customized Augmented Backus-Naur Form (ABNF) [3] description, independent of the ASN.1, as a convenience for the implementor. (Equivalent ABNF for the GSER encodings of ASN.1 types commonly occurring in LDAP syntaxes is provided in a separate document [15] 📚.) Such a specification SHOULD state that if there is a discrepancy between the customized ABNF and the GSER encoding defined by this document, the GSER encoding takes precedence 👑. No debate, GSER wins 🔥.

2. Conventions 🎀

Throughout this document, "type" shall be taken to mean an ASN.1 type, and "value" shall be taken to mean an ASN.1 value 🦋.

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 BCP 14, RFC 2119 [1] 💅.

3. Generic String Encoding Rules 🌸

The GSER encoding of a value of any ASN.1 type is described by the following ABNF [3] 🧚:

   Value = BitStringValue /
           BooleanValue /
           CharacterStringValue /
           ChoiceValue /
           EmbeddedPDVValue /
           EnumeratedValue /
           ExternalValue /
           GeneralizedTimeValue /
           IntegerValue /
           InstanceOfValue /
           NullValue /
           ObjectDescriptorValue /
           ObjectIdentifierValue /
           OctetStringValue /
           RealValue /
           RelativeOIDValue /
           SequenceOfValue /
           SequenceValue /
           SetOfValue /
           SetValue /
           StringValue /
           UTCTimeValue /
           VariantEncoding

The ABNF for each of the above rules is given in the following sections 💖.

3.1 Type Referencing Notations 🔍

A value of a type with a defined type name is encoded according to the type definition on the right hand side of the type assignment for the type name 🎀.

A value of a type denoted by the use of a parameterized type with actual parameters is encoded according to the parameterized type, with the DummyReferences [11] substituted with the actual parameters ✨.

A value of a tagged or constrained type is encoded as a value of the type without the tag or constraint, respectively. Tags do not appear in the string encodings defined by this document. See X.680 [8] and X.682 [10] for the details of ASN.1 constraint notation 🙈. (Tags are hidden, no cap 🫣.)

A value of an open type denoted by an ObjectClassFieldType (Clause 14 of X.681 [9]) is encoded according to the specific type of the value 🌈.

A value of a fixed type denoted by an ObjectClassFieldType is encoded according to that fixed type 💅.

A value of a selection type is encoded according to the type referenced by the selection type 🦋.

A value of a type described by TypeFromObject notation (Clause 15 of X.681 [9]) is encoded according to the denoted type 🍓.

A value of a type described by ValueSetFromObjects notation (Clause 15 of X.681 [9]) is encoded according to the governing type 👑.

3.2. Restricted Character String Types 💜

Lowkey the big one here: the contents of a string value are encoded as a UTF-8 character string between double quotes, no matter the ASN.1 string type 🫶. Depending on the ASN.1 string type and an application's internal representation of that string, a translation to or from UTF-8 may be required 🔥. NumericString, PrintableString, IA5String, and VisibleString (ISO646String) are already compatible with UTF-8, so they don't need any translation 🧚. BMPString (UCS-2) and UniversalString (UCS-4) have a direct mapping to and from UTF-8 [6] 🌸. For the remaining string types, see X.680 [8] ✨. Any embedded double quotes in the resulting UTF-8 character string are escaped by repeating the double quote characters 💖.

A value of the NumericString, PrintableString, TeletexString (T61String), VideotexString, IA5String, GraphicString, VisibleString (ISO646String), GeneralString, BMPString, UniversalString or UTF8String type is encoded according to the <StringValue> rule 🎀.

   StringValue       = dquote *SafeUTF8Character dquote

   dquote            = %x22 ; " (double quote)

   SafeUTF8Character = %x00-21 / %x23-7F /   ; ASCII minus dquote
                       dquote dquote /       ; escaped double quote
                       %xC0-DF %x80-BF /     ; 2 byte UTF-8 character
                       %xE0-EF 2(%x80-BF) /  ; 3 byte UTF-8 character
                       %xF0-F7 3(%x80-BF)    ; 4 byte UTF-8 character

A value of the GeneralizedTime type, UTCTime type or ObjectDescriptor type is encoded as a string value 🦋. GeneralizedTime and UTCTime use the VisibleString character set, so the conversion to UTF-8 is trivial 🌈. ObjectDescriptor uses the GraphicString type 🍓.

   GeneralizedTimeValue  = StringValue
   UTCTimeValue          = StringValue
   ObjectDescriptorValue = StringValue

3.3. ChoiceOfStrings Types 🎀

okay so ASN.1 specs sometimes say "pick one of these string types," and it doesn't matter which one you pick, bestie 💅 The big example is DirectoryString [7]. People do this on purpose so most values can use a simpler string type, or so a spec can switch to a bigger character set later without breaking older stuff 🦋

GSER encodes every ASN.1 string type as a UTF-8 character string 🌈 So when the CHOICE is purely syntactic (no meaning hidden in which alternative you picked), the final encoding comes out the same no matter what, literally no difference 🙈

Here's the tricky part: some ASN.1 constructs give away that the alternatives do mean something, but just not having those constructs doesn't prove a CHOICE is purely syntactic 👀 So specs have to declare the purely syntactic CHOICE types on purpose, which lets them be encoded more compactly (see Section 3.12). Those declared types are called ChoiceOfStrings types ✨

To be eligible, an ASN.1 type MUST meet all of these:

  • a) The type is a CHOICE type.
  • b) The component type of each alternative is one of the following ASN.1 restricted string types: NumericString, PrintableString, TeletexString (T61String), VideotexString, IA5String, GraphicString, VisibleString (ISO646String), GeneralString, BMPString, UniversalString or UTF8String.
  • c) All the alternatives are of different restricted string types, i.e., no two alternatives have the same ASN.1 restricted string type.
  • d) Either none of the alternatives has a constraint, or all of the alternatives have exactly the same constraint.

Tagging on the alternative types is ignored 🫶

Let's look at the ASN.1 parameterized type definition of DirectoryString, which is the main character here 💖

   DirectoryString { INTEGER : maxSize } ::= CHOICE {
       teletexString     TeletexString (SIZE (1..maxSize)),
       printableString   PrintableString (SIZE (1..maxSize)),
       bmpString         BMPString (SIZE (1..maxSize)),
       universalString   UniversalString (SIZE (1..maxSize)),
       uTF8String        UTF8String (SIZE (1..maxSize)) }

Any use of the DirectoryString parameterized type with an actual parameter makes an ASN.1 type that meets the conditions above. Since the alternative inside a DirectoryString carries no semantic significance, this document declares (each and every use of) DirectoryString{} to be a ChoiceOfStrings type 🔥

Other specs MAY declare their own types as ChoiceOfStrings types, as long as those types meet the conditions above 🌸 The declaration SHOULD go where the ASN.1 type is defined. If that's not done, it SHOULD go where the type is introduced as, or in, an LDAP attribute or assertion syntax 🧚

3.4. Identifiers 🍓

An <identifier> follows the ASN.1 identifier definition (Clause 11.3 of X.680 [8]) 💅 It starts with a lowercase letter, followed by zero or more letters, digits, and hyphens. A hyphen can't be the last character, and it can't be followed by another hyphen (no double hyphens, bestie 🙅‍♀️). Letter case always matters in identifiers ✨

   identifier    = lowercase *alphanumeric *(hyphen 1*alphanumeric)
   alphanumeric  = uppercase / lowercase / decimal-digit
   uppercase     = %x41-5A  ; "A" to "Z"
   lowercase     = %x61-7A  ; "a" to "z"
   decimal-digit = %x30-39  ; "0" to "9"
   hyphen        = "-"

3.5. BIT STRING 🦋

A BIT STRING value is encoded according to the <BitStringValue> rule. If the BIT STRING type definition includes a named bit list, the <bit-list> form of <BitStringValue> MAY be used 👀 If the number of bits in the value is a multiple of four, the <hstring> form of <BitStringValue> MAY be used too. Otherwise, the <bstring> form of <BitStringValue> is used 💜

   BitStringValue = bstring / hstring / bit-list

The <bit-list> rule lists the one bits in the value as a comma separated list of identifiers. Each <identifier> MUST be one of the identifiers in the named bit list, and it MUST NOT appear more than once in the same <bit-list> 🙈 The <bstring> rule writes each bit as "0" or "1", in order from the first bit to the last. The <hstring> rule writes each group of four bits as a hexadecimal number, where the first bit is the most significant 🌈 An odd number of hexadecimal digits is permitted, which is kind of iconic of it 💅

   bit-list          = "{" [ sp identifier
                          *( "," sp identifier ) ] sp "}"

   hstring           = squote *hexadecimal-digit squote %x48 ; '...'H

   hexadecimal-digit = %x30-39 /  ; "0" to "9"
                       %x41-46    ; "A" to "F"

   bstring           = squote *binary-digit squote %x42  ; '...'B
   binary-digit      = "0" / "1"

   sp                = *%x20  ; zero, one or more space characters
   squote            =  %x27  ; ' (single quote)

3.6. BOOLEAN ✨

A BOOLEAN value is encoded according to the <BooleanValue> rule. Easy one, no cap 🫶

   BooleanValue = %x54.52.55.45 /   ; "TRUE"
                  %x46.41.4C.53.45  ; "FALSE"

3.7. ENUMERATED 🎀

An ENUMERATED value is encoded according to the <EnumeratedValue> rule. The <identifier> MUST be one of the ones in the list of enumerations in the ENUMERATED type definition, so no freestyling allowed 😤

   EnumeratedValue = identifier

3.8. INTEGER 🌸

An INTEGER value is encoded according to the <IntegerValue> rule. If the INTEGER type definition includes a named number list, the <identifier> form of <IntegerValue> MAY be used. When it is, the <identifier> MUST be one of the identifiers in that named number list 🧚

   IntegerValue    = "0" /
                     positive-number /
                     ("-" positive-number) /
                     identifier

   positive-number = non-zero-digit *decimal-digit
   non-zero-digit  = %x31-39  ; "1" to "9"

3.9. NULL 💖

A NULL value is encoded according to the <NullValue> rule. Just NULL, bestie, no extra drama 🙃

   NullValue = %x4E.55.4C.4C  ; "NULL"

3.10. OBJECT IDENTIFIER and RELATIVE-OID 🦋

An OBJECT IDENTIFIER value is encoded according to the <ObjectIdentifierValue> rule. That rule lets you use either a dotted decimal form of the value or an object descriptor name, which is the <descr> form. The <descr> rule is described in RFC 2252 [4] 🌈 An object descriptor name is potentially ambiguous and should be used with care 👀

   ObjectIdentifierValue = numeric-oid / descr
   numeric-oid           = oid-component 1*( "." oid-component )
   oid-component         = "0" / positive-number

A RELATIVE-OID value is encoded according to the <RelativeOIDValue> rule 💅

   RelativeOIDValue = oid-component *( "." oid-component )

3.11. OCTET STRING 🍓

An OCTET STRING value is encoded according to the <OctetStringValue> rule. The octets are encoded in order, from the first octet to the last. Each octet is written as a pair of hexadecimal digits, where the first digit is the four most significant bits of the octet 💜 If the hexadecimal string has an odd number of digits, the four least significant bits in the last octet are assumed to be zero ✨

   OctetStringValue = hstring

3.12. CHOICE 💅

A CHOICE value is encoded according to the <ChoiceValue> rule. The <ChoiceOfStringsValue> encoding MAY be used if the CHOICE type has been declared a ChoiceOfStrings type 🫶 This document declares DirectoryString to be a ChoiceOfStrings type (see Section 3.3). Otherwise, the <IdentifiedChoiceValue> form of <ChoiceValue> is used 🎀

   ChoiceValue           = IdentifiedChoiceValue /
                           ChoiceOfStringsValue
   IdentifiedChoiceValue = identifier ":" Value
   ChoiceOfStringsValue  = StringValue

For implementations that recognise the internal structure of the DirectoryString CHOICE type (e.g., X.500 directories [16]), here's the deal: if the character string between the quotes in a <StringValue> contains only characters allowed in a PrintableString, the DirectoryString is assumed to use the printableString alternative. Otherwise, it's assumed to use the uTF8String alternative 🧠 The <IdentifiedChoiceValue> rule MAY be used for a DirectoryString value to pick an alternative other than the one that would be assumed from the string contents 🔥 No matter which alternative is chosen, the <Value> is still a UTF-8 encoded character string. However, it is a syntax error if the characters in the UTF-8 string can't be represented in the string type of the chosen alternative 🚫

Implementations that don't care about the internal structure of a DirectoryString value MUST be able to parse the <IdentifiedChoiceValue> form for a DirectoryString value 💖 The identifier they find will be of no interest to them, though 🙈

3.13. SEQUENCE and SET 🌈

A SEQUENCE value is encoded according to the <SequenceValue> rule. The <ComponentList> rule encodes a comma separated list of the component values present in the SEQUENCE value, where each component value is preceded by its identifier from the SEQUENCE type definition. The components are encoded in the order they're defined in the SEQUENCE type ✨

   SequenceValue = ComponentList

   ComponentList = "{" [ sp NamedValue *( "," sp NamedValue) ] sp "}"
   NamedValue    = identifier msp Value
   msp           = 1*%x20  ; one or more space characters

A SET value is encoded according to the <SetValue> rule. The components are encoded in the order they're defined in the SET type (just like a SEQUENCE value). This is a deliberate departure from ASN.1 value notation, where the components of a SET can be written in any order 🙅‍♀️

   SetValue = ComponentList

SEQUENCE and SET type definitions sometimes get extended by adding new component types, so an implementation SHOULD be capable of skipping over any <NamedValue> encoding with an identifier it doesn't recognise. It can assume the sender is using a newer definition of the SEQUENCE or SET type 🦋

3.14. SEQUENCE OF and SET OF 🍓

A SEQUENCE OF value is encoded according to the <SequenceOfValue> rule, as a comma separated list of the instances in the value. Each instance is encoded according to the component type of the SEQUENCE OF type 💜

   SequenceOfValue = "{" [ sp Value *( "," sp Value) ] sp "}"

A SET OF value is encoded according to the <SetOfValue> rule, as a list of the instances in the value. Each instance is encoded according to the component type of the SET OF type 🌸

   SetOfValue      = "{" [ sp Value *( "," sp Value) ] sp "}"

3.15. CHARACTER STRING 🧚

A value of the unrestricted CHARACTER STRING type is encoded according to the corresponding SEQUENCE type defined in Clause 40.5 of X.680 [8] (see [15] for equivalent ABNF) 💅

   CharacterStringValue = SequenceValue

3.16. EMBEDDED PDV 🫶

A value of the EMBEDDED PDV type is encoded according to the corresponding SEQUENCE type defined in Clause 33.5 of X.680 [8] (see [15] for equivalent ABNF) 🎀

   EmbeddedPDVValue = SequenceValue

3.17. EXTERNAL ✨

okay so an EXTERNAL value gets encoded like the matching SEQUENCE type from Clause 8.18.1 of X.690 [12] 💅 (see [15] for the equivalent ABNF 🦋)

ExternalValue = SequenceValue

3.18. INSTANCE OF 🌸

bestie, an INSTANCE OF value is encoded like the SEQUENCE type in Annex C of X.681 [9] 🧚

InstanceOfValue = SequenceValue

3.19. REAL 💖

okay this one is a whole vibe 😭 a REAL value MUST be encoded as "0" if it's zero. otherwise it's the special value <PLUS-INFINITY>, the special value <MINUS-INFINITY>, an optionally signed <realnumber>, or a value of the matching SEQUENCE type for REAL from Clause 20.5 of X.680 [8] (see [15] for the equivalent ABNF 🫶)

RealValue  = "0"               ; zero REAL value
             / PLUS-INFINITY   ; positive infinity
             / MINUS-INFINITY  ; negative infinity
             / realnumber      ; positive base 10 REAL value
             / "-" realnumber  ; negative base 10 REAL value
             / SequenceValue   ; non-zero REAL value, base 2 or 10

realnumber = mantissa exponent
mantissa   = (positive-number [ "." *decimal-digit ])
             / ( "0." *("0") positive-number )
exponent   = "E" ( "0" / ([ "-" ] positive-number))

PLUS-INFINITY  = %x50.4C.55.53.2D.49.4E.46.49.4E.49.54.59
                    ; "PLUS-INFINITY"
MINUS-INFINITY = %x4D.49.4E.55.53.2D.49.4E.46.49.4E.49.54.59
                    ; "MINUS-INFINITY"

3.20. Variant Encodings 🎀

the values of some named complex ASN.1 types get special string encodings 🌈 and these special ones are ALWAYS used instead of whatever the ASN.1 type definition would normally give you. no exceptions, babe 💅

VariantEncoding = RDNSequenceValue /
                  RelativeDistinguishedNameValue /
                  ORAddressValue

a value of the RDNSequence type (aka a distinguished name) gets encoded with the <RDNSequenceValue> rule as a quoted LDAPDN character string 🦋 first the string is derived using the <distinguishedName> rule in Section 3 of RFC 2253 [5], then it's encoded as if it were a UTF8String value. that means wrapped in double quotes, with any embedded double quotes escaped by being repeated.

RDNSequenceValue = StringValue

a RelativeDistinguishedName value that's NOT part of an RDNSequence value gets encoded with the <RelativeDistinguishedNameValue> rule as a quoted character string 🧚 the string is derived using the <name-component> rule in Section 3 of RFC 2253 [5], and then encoded as if it were a UTF8String value.

RelativeDistinguishedNameValue = StringValue

a value of the ORAddress type gets encoded with the <ORAddressValue> rule as a quoted character string ✨ the string is derived from the textual representation of MTS.ORAddress from RFC 2156 [2], and then encoded as if it were an IA5String value.

ORAddressValue = StringValue

4. GSER Transfer Syntax 🦋

Adacel Technologies got this OBJECT IDENTIFIER assigned to identify the Generic String Encoding Rules 💜 it lives under an arc that Standards Australia gave to Adacel:

{ 1 2 36 79672281 0 0 }

this OID is what you'd use, for example, to describe the transfer syntax for a GSER encoded data-value inside an EMBEDDED PDV value 🫶

5. Security Considerations 🔥

⚠️ bestie, read this part slowly. security is not a vibe to skip 💀

the Generic String Encoding Rules do NOT define a canonical encoding 😭 so if you go from a GSER encoding to some other encoding (like BER) and then back to GSER, you won't necessarily get the exact same GSER octets you started with. which means GSER MUST NOT be used where a canonical encoding is needed 🙅‍♀️

also, GSER doesn't always let you rebuild the exact octet encoding of TeletexString, VideotexString, GraphicString, or GeneralString values. so going from a Distinguished Encoding Rules (DER) [12] encoding to GSER and back to DER might not reproduce the original DER encoding. so GSER MUST NOT be used to re-encode, whether for storage or transmission, ASN.1 abstract values whose original binary encoding has to be recoverable 🌸 that recovery is needed for verifying digital signatures, so in those cases protocols ought to use DER or a DER-reversible encoding 💖

and when you're interpreting security-sensitive fields, especially ones used to grant or deny access, implementations MUST make sure any comparisons happen on the underlying abstract value, no matter which encoding was used 👑 this one is non-negotiable, periodt 💅

6. References 📚

6.1. Normative References

  • [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [2] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, January 1998.
  • [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
  • [4] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997.
  • [5] Wahl, M., Kille S. and T. Howes. "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997.
  • [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
  • [7] ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994, Information Technology - Open Systems Interconnection - The Directory: Selected attribute types
  • [8] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1:2002 Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation
  • [9] ITU-T Recommendation X.681 (07/02) | ISO/IEC 8824-2:2002 Information technology - Abstract Syntax Notation One (ASN.1): Information object specification
  • [10] ITU-T Recommendation X.682 (07/02) | ISO/IEC 8824-3:2002 Information technology - Abstract Syntax Notation One (ASN.1): Constraint specification
  • [11] ITU-T Recommendation X.683 (07/02) | ISO/IEC 8824-4:2002 Information technology - Abstract Syntax Notation One (ASN.1): Parameterization of ASN.1 specifications
  • [12] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1:2002 Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)

6.2. Informative References

  • [13] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996.
  • [14] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002.
  • [15] Legg, S., "Common Elements of Generic String Encoding Rules (GSER) Encodings", RFC 3642, October 2003.
  • [16] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994, Information Technology - Open Systems Interconnection - The Directory: Overview of concepts, models and services

7. Intellectual Property Notice 👑

the IETF doesn't take a position on whether any intellectual property or other rights claimed for the technology in this document are valid or in scope 🙈 it also doesn't say whether any license under those rights might be available, and it hasn't claimed to have looked for any such rights. info about the IETF's procedures for rights in standards-track and standards-related documents is in BCP-11 📖 copies of claims of rights made available for publication, plus any assurances of licenses, or the result of an attempt to get a general license or permission for implementers or users of this specification, can be obtained from the IETF Secretariat 💌

the IETF invites anyone interested to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology required to practice this standard 🦋 send that info to the IETF Executive Director.

8. Author's Address 💌

Steven Legg
Adacel Technologies Ltd.
250 Bay Street
Brighton, Victoria 3186
AUSTRALIA

Phone: +61 3 8530 7710
Fax:   +61 3 8530 7888
EMail: steven.legg@adacel.com.au

Copyright (C) The Internet Society (2003). All Rights Reserved. 🎀

this document and translations of it can be copied and furnished to others, and derivative works that comment on or explain it, or help with its implementation, can be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind. the one condition is that the above copyright notice and this paragraph are included on all such copies and derivative works 🫶 but this document itself may not be modified in any way (like removing the copyright notice or references to the Internet Society or other Internet organizations). the exceptions are if it's needed for developing Internet standards, in which case the Internet Standards process copyright procedures must be followed, or if it's needed to translate it into languages other than English 🌸

the limited permissions above are perpetual and won't be revoked by the Internet Society or its successors or assignees ✨

this document and the information in it 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. 💀

Acknowledgement 🫶

funding for the RFC Editor function is currently provided by the Internet Society 💖

📦 where this page comes from