RFC 4792

Encoding Instructions for the Generic String Encoding Rules (GSER)

📅 published January 2007, from ietf

RFC 4792: Encoding Instructions for the Generic String Encoding Rules (GSER) 💖

  • Author: S. Legg, eB2Bcom 🎀
  • Stream: Network Working Group 🌸
  • Date: January 2007 🦋
  • Category: Standards Track 👑
  • Updates: RFC 3641 ✨
  • Obsoletes: nothing listed in the title block 💅

Status of This Memo ✨

This is an Internet standards track protocol for the Internet community, and it's asking everyone for discussion and suggestions for improvements 🫶. For the standardization state and status of this protocol, check the current edition of "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈.

Copyright (C) The IETF Trust (2007).

Abstract 🌸

ASN.1 (Abstract Syntax Notation One) gives you a general way to annotate types in an ASN.1 specification with encoding instructions 🦋. Those instructions change how values of those types get encoded under ASN.1 encoding rules 💅. This document defines the notation for encoding instructions that apply to the Generic String Encoding Rules (GSER) ✨. It specifically defines one encoding instruction that gives a machine-processable way to declare a GSER ChoiceOfStrings type 👑.

Table of Contents 🧚

1. Introduction ....................................................2
2. Conventions .....................................................2
3. Notation for GSER Encoding Instructions .........................2
4. The CHOICE-OF-STRINGS Encoding Instruction ......................3
   4.1. Effect on GSER Encodings ...................................5
   4.2. Replacement of Existing ChoiceOfStrings Declarations .......6
5. Security Considerations .........................................7
6. Normative References ............................................7

1. Introduction 🎀

ASN.1 [X.680] gives you a general framework for annotating types in an ASN.1 specification with encoding instructions [X.680-1] 🦋. Those instructions change how values of those types get encoded under ASN.1 encoding rules ✨. This document is where the supporting notation for encoding instructions for the Generic String Encoding Rules (GSER) [GSER] lives 💖. It also defines the CHOICE-OF-STRINGS encoding instruction, which gives a machine-processable way to declare a GSER ChoiceOfStrings type 👑.

The CHOICE-OF-STRINGS encoding instruction SHOULD be used instead of simply declaring a ChoiceOfStrings type 🫶. That's the move, bestie 💅.

2. Conventions 🌸

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 [BCP14] 🔥.

Throughout this document, "type" shall be taken to mean an ASN.1 type, and "value" shall be taken to mean an ASN.1 abstract value, unless qualified otherwise 🧚.

A reference to an ASN.1 production [X.680] (e.g., Type, NamedType) is a reference to text in an ASN.1 specification that matches that production 🦋.

3. Notation for GSER Encoding Instructions 🦋

The ASN.1 grammar lets you apply encoding instructions [X.680-1] through type prefixes and encoding control sections ✨. Those are what change how abstract values get encoded by the encoding rules you name 💖.

The generic notation for type prefixes and encoding control sections comes from the ASN.1 basic notation [X.680] [X.680-1] 👑. It includes an encoding reference that says which encoding rules the instruction affects 💅.

The encoding reference for the Generic String Encoding Rules is literally GSER 🎀.

The specific notation for an encoding instruction is left to the specification of each set of encoding rules 🌸. So this companion document to the GSER specification [GSER] is the one that defines the notation for GSER encoding instructions 🦋. Specifically, it fills in the EncodingInstruction and EncodingInstructionAssignmentList placeholder productions from the ASN.1 basic notation ✨.

In the context of the GSER encoding reference, the EncodingInstruction production is defined like this, using the ASN.1 basic notation conventions 💖:

EncodingInstruction ::=
    ChoiceOfStringsInstruction

In the context of the GSER encoding reference, the EncodingInstructionAssignmentList production (which only appears in an encoding control section) is empty 👑:

EncodingInstructionAssignmentList ::= empty

4. The CHOICE-OF-STRINGS Encoding Instruction 👑

The CHOICE-OF-STRINGS encoding instruction lets a GSER encoder encode the alternative of a CHOICE (of restricted string types) without the leading identifier 🫶. The optional PrecedenceList also lets a spec writer change the order a GSER decoder checks the alternatives of the CHOICE in when it figures out which alternative was encoded and the identifier is missing 💅.

The notation for a CHOICE-OF-STRINGS encoding instruction is defined like this 🧚:

UnionInstruction ::= "CHOICE-OF-STRINGS" AlternativesPrecedence ?

AlternativesPrecedence ::= "PRECEDENCE" PrecedenceList

PrecedenceList ::= identifier PrecedenceList ?

The Type in the EncodingPrefixedType for a CHOICE-OF-STRINGS encoding instruction SHALL be one of the following 🔥:

  • (a) a BuiltinType that is a ChoiceType, or
  • (b) a ConstrainedType that is not a TypeWithConstraint where the Type in the ConstrainedType is one of (a) to (d), or
  • (c) a BuiltinType that is a PrefixedType that is a TaggedType where the Type in the TaggedType is one of (a) to (d), or
  • (d) a BuiltinType that is a PrefixedType that is an EncodingPrefixedType where the Type in the EncodingPrefixedType is one of (a) to (d).

The point of this condition is to force the CHOICE-OF-STRINGS encoding instruction to sit right next to the CHOICE type definition it applies to 🎀. That makes it obvious to a reader that the instruction covers every use of the CHOICE type, no matter how it gets referenced 🌸.

The ChoiceType in case (a) is said to be "subject to" the CHOICE-OF-STRINGS encoding instruction 🦋.

The Type of each NamedType of the ChoiceType in case (a) MUST be one of the following 💖:

  • (1) the NumericString, PrintableString, TeletexString (T61String), VideotexString, IA5String, GraphicString, VisibleString (ISO646String), GeneralString, BMPString, UniversalString, or UTF8String type, or
  • (2) a type notation that references a type that is one of (1) to (4), or
  • (3) a constrained type where the type that is constrained is one of (1) to (4), or
  • (4) a prefixed type where the type that is prefixed is one of (1) to (4).
ASIDE: A tagged type is a special case of a prefixed type. An effect of case (4) is that tagging is not significant.

The ASN.1 restricted string type in case (1) MUST be different for each NamedType in the ChoiceType, i.e., no two alternatives have the same restricted string type 🔥.

If case (3) applies to any NamedType, then the constraint in case (3) MUST be the same for each NamedType, i.e., either none of the alternatives has a constraint, or all of the alternatives have exactly the same constraint 👑.

Each identifier in the PrecedenceList MUST be the identifier of a NamedType of the ChoiceType 🫶.

A particular identifier SHALL NOT appear more than once in the same PrecedenceList 🙈.

4.1. Effect on GSER Encodings 💅

A value of a CHOICE type is encoded according to the <ChoiceValue> [GSER] Augmented Backus-Naur Form [ABNF] rule 🧚. The ABNF for <ChoiceValue> is reproduced here for convenience ✨:

ChoiceValue           = IdentifiedChoiceValue /
                        ChoiceOfStringsValue

IdentifiedChoiceValue = identifier ":" Value
ChoiceOfStringsValue  = StringValue

The <IdentifiedChoiceValue> rule MUST be used to encode values of a CHOICE type where the ChoiceType is not subject to a CHOICE-OF-STRINGS encoding instruction 🔥.

The chosen alternative of a value of a CHOICE type corresponds to some NamedType in the definition of the type 🌸. The <identifier> in the <IdentifiedChoiceValue> is the identifier of this NamedType 🦋.

Either the <IdentifiedChoiceValue> rule or the <ChoiceOfStringsValue> rule is used to encode values of a CHOICE type where the ChoiceType is subject to a CHOICE-OF-STRINGS encoding instruction 💖.

If <ChoiceOfStringsValue> has been used, then a GSER decoder MUST determine the chosen alternative by considering the alternatives of the CHOICE in the order prescribed below, and accepting the first alternative that allows all of the characters in the <StringValue> 👑.

If the CHOICE-OF-STRINGS encoding instruction has a PrecedenceList, then the alternatives of the ChoiceType referenced by the PrecedenceList are considered in the order that PrecedenceList identifies, and then the remaining alternatives are considered in the order of their definition in the ChoiceType 🫶. If the CHOICE-OF-STRINGS encoding instruction does not have a PrecedenceList, then all the alternatives of the ChoiceType are considered in the order of their definition in the ChoiceType 💅.

A GSER encoder MUST use <IdentifiedChoiceValue> if a GSER decoder would determine the chosen alternative to be something other than the chosen alternative of the CHOICE value being encoded 🙈. Otherwise, <ChoiceOfStringsValue> MAY be used 🌈.

Example 🧚

Consider this type definition ✨:

[GSER:CHOICE-OF-STRINGS PRECEDENCE basicName] CHOICE {
    extendedName  UTF8String,
    basicName     PrintableString
}

If a <ChoiceOfStringsValue> has been used, then a GSER decoder would first check whether the <StringValue> is a valid basicName (a PrintableString) before checking whether it's a valid extendedName (a UTF8String) 💖😭.

4.2. Replacement of Existing ChoiceOfStrings Declarations ✨

okay so bestie, this part is all about updating the old DirectoryString declarations 💅 In line with the older declaration [GSER] of DirectoryString as a ChoiceOfStrings type, applications using GSER MUST add this encoding instruction:

[GSER:CHOICE-OF-STRINGS PRECEDENCE printableString uTF8String]

Slide that in immediately before the "CHOICE" keyword in the definition of the DirectoryString type, in the third and every subsequent edition of the SelectedAttributeTypes ASN.1 module of X.520 [X.520-3] [X.520-4] [X.520-5]. 🦋

Here's what that looks like for the third, fourth and fifth editions 👑:

DirectoryString{INTEGER:maxSize} ::=
[GSER:CHOICE-OF-STRINGS PRECEDENCE printableString uTF8String]
CHOICE {
    teletexString     TeletexString(SIZE (1..maxSize)),
    printableString   PrintableString(SIZE (1..maxSize)),
    universalString   UniversalString(SIZE (1..maxSize)),
    bmpString         BMPString(SIZE (1..maxSize)),
    uTF8String        UTF8String(SIZE (1..maxSize))
}

Now, the uTF8String alternative did not show up in the second edition of the SelectedAttributeTypes ASN.1 module of X.520 [X.520-2] 🙈 So for compatibility, applications using GSER with the second edition of X.520 MUST add this encoding instruction:

[GSER:CHOICE-OF-STRINGS PRECEDENCE printableString]

Same deal: put it immediately before the "CHOICE" keyword in the definition of the DirectoryString type. 🌸

And for the second edition, it looks like this 🧚:

DirectoryString{INTEGER:maxSize} ::=
[GSER:CHOICE-OF-STRINGS PRECEDENCE printableString]
CHOICE {
    teletexString     TeletexString(SIZE (1..maxSize)),
    printableString   PrintableString(SIZE (1..maxSize)),
    universalString   UniversalString(SIZE (1..maxSize))
}

5. Security Considerations 💀

okay this one is short but it's giving reassurance 🫶 This specification changes the way ChoiceOfStrings types are declared, but it does not alter the existing behaviour of GSER implementations. The security considerations for GSER are unchanged (see [GSER]). So no new security drama here, periodt ✨

6. Normative References 📚

  • [BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [GSER] Legg, S., "Generic String Encoding Rules (GSER) for ASN.1 Types", RFC 3641, October 2003.
  • [ABNF] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
  • [X.520-2] ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994, Information Technology - Open Systems Interconnection - The Directory: Selected attribute types
  • [X.520-3] ITU-T Recommendation X.520 (08/97) | ISO/IEC 9594-6:1998, Information Technology - Open Systems Interconnection - The Directory: Selected attribute types
  • [X.520-4] ITU-T Recommendation X.520 (02/01) | ISO/IEC 9594-6:2001, Information technology - Open Systems Interconnection - The Directory: Selected attribute types
  • [X.520-5] ITU-T Recommendation X.520 (08/05) | ISO/IEC 9594-6:2005, Information technology - Open Systems Interconnection - The Directory: Selected attribute types
  • [X.680] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1, Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation.
  • [X.680-1] ITU-T Recommendation X.680 (2002) Amendment 1 (10/03) | ISO/IEC 8824-1:2002/Amd 1:2004, Support for EXTENDED-XER.

Author's Address 🖋️

Dr. Steven Legg eB2Bcom Suite 3, Woodhouse Corporate Centre 935 Station Street Box Hill North, Victoria 3129 AUSTRALIA

Phone: +61 3 9896 7830 Fax: +61 3 9896 7801 EMail: steven.legg@eb2bcom.com

Copyright (C) The IETF Trust (2007).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property 🔥

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Acknowledgement 💜

Funding for the RFC Editor function is currently provided by the Internet Society.

📦 where this page comes from