Movatterモバイル変換

Network Working Group                                            S. LeggRequest for Comments: 4792                                       eB2BcomUpdates:3641                                               January 2007Category: Standards TrackEncoding Instructions for theGeneric String Encoding Rules (GSER)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 Notice   Copyright (C) The IETF Trust (2007).Abstract   Abstract Syntax Notation One (ASN.1) defines a general framework for   annotating types in an ASN.1 specification with encoding instructions   that alter how values of those types are encoded according to ASN.1   encoding rules.  This document defines the supporting notation for   encoding instructions that apply to the Generic String Encoding Rules   (GSER) and, in particular, defines an encoding instruction to provide   a machine-processable representation for the declaration of a GSER   ChoiceOfStrings type.Table of Contents1. Introduction ....................................................22. Conventions .....................................................23. Notation for GSER Encoding Instructions .........................24. The CHOICE-OF-STRINGS Encoding Instruction ......................34.1. Effect on GSER Encodings ...................................54.2. Replacement of Existing ChoiceOfStrings Declarations .......65. Security Considerations .........................................76. Normative References ............................................7Legg                        Standards Track                     [Page 1]

RFC 4792             Encoding Instructions for GSER         January 20071.  Introduction   Abstract Syntax Notation One (ASN.1) [X.680] defines a general   framework for annotating types in an ASN.1 specification with   encoding instructions [X.680-1] that alter how values of those types   are encoded according to ASN.1 encoding rules.  This document defines   the supporting notation for encoding instructions that apply to the   Generic String Encoding Rules (GSER) [GSER], and in particular   defines an encoding instruction, the CHOICE-OF-STRINGS encoding   instruction, to provide a machine-processable representation for the   declaration of a GSER ChoiceOfStrings type.   The CHOICE-OF-STRINGS encoding instruction SHOULD be used instead of   simply declaring a ChoiceOfStrings type.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 inBCP 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 corresponding to that   production.3.  Notation for GSER Encoding Instructions   The grammar of ASN.1 permits the application of encoding instructions   [X.680-1], through type prefixes and encoding control sections, that   modify how abstract values are encoded by nominated encoding rules.   The generic notation for type prefixes and encoding control sections   is defined by the ASN.1 basic notation [X.680] [X.680-1], and   includes an encoding reference to identify the specific encoding   rules that are affected by the encoding instruction.   The encoding reference that identifies the Generic String Encoding   Rules is literally GSER.   The specific notation for an encoding instruction for a particular   set of encoding rules is left to the specification of those encoding   rules.  Consequently, this companion document to the GSER   specification [GSER] defines the notation for GSER encodingLegg                        Standards Track                     [Page 2]

RFC 4792             Encoding Instructions for GSER         January 2007   instructions.  Specifically, it elaborates the EncodingInstruction   and EncodingInstructionAssignmentList placeholder productions of the   ASN.1 basic notation.   In the context of the GSER encoding reference the EncodingInstruction   production is defined as follows, using the conventions of the ASN.1   basic notation:      EncodingInstruction ::=          ChoiceOfStringsInstruction   In the context of the GSER encoding reference the   EncodingInstructionAssignmentList production (which only appears in   an encoding control section) is empty:      EncodingInstructionAssignmentList ::= empty4.  The CHOICE-OF-STRINGS Encoding Instruction   The CHOICE-OF-STRINGS encoding instruction allows a GSER encoder to   encode the alternative of a CHOICE (of restricted string types)   without the leading identifier.  The optional PrecedenceList also   allows a specification writer to alter the order in which a GSER   decoder will consider the alternatives of the CHOICE as it determines   which alternative has been encoded when the identifier is absent.   The notation for a CHOICE-OF-STRINGS encoding instruction is defined   as follows:      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:   (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), orLegg                        Standards Track                     [Page 3]

RFC 4792             Encoding Instructions for GSER         January 2007   (d) a BuiltinType that is a PrefixedType that is an       EncodingPrefixedType where the Type in the EncodingPrefixedType       is one of (a) to (d).   The effect of this condition is to force the CHOICE-OF-STRINGS   encoding instruction to be textually co-located with the CHOICE type   definition to which it applies.  This makes it clear to a reader that   the encoding instruction applies to every use of the CHOICE type no   matter how it might be 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:   (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.Legg                        Standards Track                     [Page 4]

RFC 4792             Encoding Instructions for GSER         January 20074.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 identified by that   PrecedenceList, 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.Legg                        Standards Track                     [Page 5]

RFC 4792             Encoding Instructions for GSER         January 2007   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 consider whether the <StringValue> was a valid      basicName (a PrintableString) before considering whether it was a      valid extendedName (a UTF8String).4.2.  Replacement of Existing ChoiceOfStrings Declarations   In line with the previous declaration [GSER] of the DirectoryString   type as a ChoiceOfStrings type, applications using GSER MUST add this   encoding instruction:      [GSER:CHOICE-OF-STRINGS PRECEDENCE printableString uTF8String]   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].   For example, this is how the DirectoryString definition would appear   in 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))      }   The uTF8String alternative did not appear in the second edition of   the SelectedAttributeTypes ASN.1 module of X.520 [X.520-2].  For   compatibility, applications using GSER with the second edition of   X.520 MUST add this encoding instruction:      [GSER:CHOICE-OF-STRINGS PRECEDENCE printableString]Legg                        Standards Track                     [Page 6]

RFC 4792             Encoding Instructions for GSER         January 2007   immediately before the "CHOICE" keyword in the definition of the   DirectoryString type.   For example, this is how the DirectoryString definition would appear   in the second edition:      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   This specification changes the manner in which ChoiceOfStrings types   are declared but does not alter the existing behaviour of GSER   implementations.  The security considerations for GSER are unchanged   (see [GSER]).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 typesLegg                        Standards Track                     [Page 7]

RFC 4792             Encoding Instructions for GSER         January 2007   [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.comLegg                        Standards Track                     [Page 8]

RFC 4792             Encoding Instructions for GSER         January 2007Full Copyright Statement   Copyright (C) The IETF Trust (2007).   This document is subject to the rights, licenses and restrictions   contained inBCP 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 inBCP 78 andBCP 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 athttp://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.Legg                        Standards Track                     [Page 9]