GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3641

Network Working Group S. Legg Request for Comments: 3641 Adacel Technologies Category: Standards Track October 2003

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

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 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.

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

Legg Standards Track [Page 1] RFC 3641 Generic String Encoding Rules October 2003

     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

 This document defines a set of ASN.1 [8] encoding rules, called the
 Generic String Encoding Rules or GSER, that produce a human readable
 UTF-8 [6] character string encoding of ASN.1 values of any given
 arbitrary ASN.1 type.
 Note that "ASN.1 value" does not mean a Basic Encoding Rules (BER)
 [12] encoded value.  The ASN.1 value is an abstract concept that is
 independent of any particular encoding.  BER is just one possible
 encoding of an ASN.1 value.
 GSER is based on ASN.1 value notation [8], with changes to
 accommodate the notation's use as a transfer syntax, and to support
 well established ad-hoc string encodings for Lightweight Directory
 Access Protocol (LDAP) [14] directory data types.
 Though primarily intended for defining the LDAP-specific encoding of
 new LDAP attribute syntaxes and assertion syntaxes, these encoding
 rules could also be used in other domains where human readable
 renderings of ASN.1 values would be useful.
 Referencing GSER is sufficient to define a human readable text
 encoding for values of a specific ASN.1 type, however other
 specifications may wish to provide a 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 for 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, that the GSER encoding
 takes precedence.

Legg Standards Track [Page 2] RFC 3641 Generic String Encoding Rules October 2003

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.

Legg Standards Track [Page 3] RFC 3641 Generic String Encoding Rules October 2003

 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.
 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

 The contents of a string value are encoded as a UTF-8 character
 string between double quotes, regardless of the ASN.1 string type.
 Depending on the ASN.1 string type and an application's internal
 representation of that string type, a translation to or from the
 UTF-8 character encoding may be required.  NumericString,
 PrintableString, IA5String, and VisibleString (ISO646String) are
 compatible with UTF-8 and do not require 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.

Legg Standards Track [Page 4] RFC 3641 Generic String Encoding Rules October 2003

    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

 It is not uncommon for ASN.1 specifications to define types that
 offer a CHOICE between two or more alternative ASN.1 string types,
 where the particular alternative chosen carries no semantic
 significance (DirectoryString [7] being a prime example).  Such types
 are defined to avoid having to use a complicated character encoding
 for all values when most values could use a simpler string type, or
 to deal with evolving requirements that compel the use of a broader
 character set while still maintaining backward compatibility.
 GSER encodes values of all the ASN.1 string types as UTF-8 character
 strings so the particular alternative that is chosen from a purely
 syntactic CHOICE of string types makes no material difference to the
 final encoding of the string value.
 While there are certain ASN.1 constructs that betray the semantic
 significance of the alternatives within a CHOICE type, the absence of
 those constructs does not necessarily mean that a CHOICE type is
 purely syntactic.  Therefore, it is necessary for specifications to
 declare the purely syntactic CHOICE types so that they may be more
 compactly encoded (see Section 3.12).  These declared CHOICE types
 are referred to as ChoiceOfStrings types.
 To be eligible to be declared a ChoiceOfStrings type, an ASN.1 type
 MUST satisfy the following conditions.
 a) The type is a CHOICE type.

Legg Standards Track [Page 5] RFC 3641 Generic String Encoding Rules October 2003

 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.
 Consider the ASN.1 parameterized type definition of DirectoryString.
    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 defines an ASN.1 type that satisfies the above conditions.
 Recognising that the alternative within a DirectoryString carries no
 semantic significance, this document declares (each and every use of)
 DirectoryString{} to be a ChoiceOfStrings type.
 Other specifications MAY declare other types satisfying the above
 conditions to be ChoiceOfStrings types.  The declaration SHOULD be
 made at the point where the ASN.1 type is defined, otherwise it
 SHOULD be made at the point where it is introduced as, or in, an LDAP
 attribute or assertion syntax.

3.4. Identifiers

 An <identifier> conforms to the definition of an identifier in ASN.1
 notation (Clause 11.3 of X.680 [8]).  It begins with a lowercase
 letter and is followed by zero or more letters, digits, and hyphens.
 A hyphen is not permitted to be the last character, nor is it to be
 followed by another hyphen.  The case of letters in an identifier is
 always significant.

Legg Standards Track [Page 6] RFC 3641 Generic String Encoding Rules October 2003

    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 value of the BIT STRING type is encoded according to the
 <BitStringValue> rule.  If the definition of the BIT STRING type
 includes a named bit list, the <bit-list> form of <BitStringValue>
 MAY be used.  If the number of bits in a BIT STRING value is a
 multiple of four, the <hstring> form of <BitStringValue> MAY be used.
 Otherwise, the <bstring> form of <BitStringValue> is used.
    BitStringValue = bstring / hstring / bit-list
 The <bit-list> rule encodes the one bits in the bit string value as a
 comma separated list of identifiers.  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>.  The <bstring> rule encodes each
 bit as the character "0" or "1" in order from the first bit to the
 last bit.  The <hstring> rule encodes 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.
    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 value of the BOOLEAN type is encoded according to the
 <BooleanValue> rule.
    BooleanValue = %x54.52.55.45 /   ; "TRUE"
                   %x46.41.4C.53.45  ; "FALSE"

Legg Standards Track [Page 7] RFC 3641 Generic String Encoding Rules October 2003

3.7. ENUMERATED

 A value of the ENUMERATED type is encoded according to the
 <EnumeratedValue> rule.  The <identifier> MUST be one of those in the
 list of enumerations in the definition of the ENUMERATED type.
    EnumeratedValue = identifier

3.8. INTEGER

 A value of the INTEGER type is encoded according to the
 <IntegerValue> rule.  If the definition of the INTEGER type includes
 a named number list, the <identifier> form of <IntegerValue> MAY be
 used, in which case the <identifier> MUST be one of the identifiers
 in the 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 value of the NULL type is encoded according to the <NullValue>
 rule.
    NullValue = %x4E.55.4C.4C  ; "NULL"

3.10. OBJECT IDENTIFIER and RELATIVE-OID

 A value of the OBJECT IDENTIFIER type is encoded according to the
 <ObjectIdentifierValue> rule.  The <ObjectIdentifierValue> rule
 allows either a dotted decimal representation of the OBJECT
 IDENTIFIER value or an object descriptor name, i.e., <descr>.  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 value of the RELATIVE-OID type is encoded according to the
 <RelativeOIDValue> rule.
    RelativeOIDValue = oid-component *( "." oid-component )

Legg Standards Track [Page 8] RFC 3641 Generic String Encoding Rules October 2003

3.11. OCTET STRING

 A value of the OCTET STRING type is encoded according to the
 <OctetStringValue> rule.  The octets are encoded in order from the
 first octet to the last octet.  Each octet is encoded as a pair of
 hexadecimal digits where the first digit corresponds to the four most
 significant bits of the octet.  If the hexadecimal string does not
 have an even number of digits, the four least significant bits in the
 last octet are assumed to be zero.
    OctetStringValue = hstring

3.12. CHOICE

 A value of a CHOICE type is encoded according to the <ChoiceValue>
 rule.  The <ChoiceOfStringsValue> encoding MAY be used if the
 corresponding 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]), if the
 character string between the quotes in a <StringValue> contains only
 characters that are permitted in a PrintableString, the
 DirectoryString is assumed to use the printableString alternative,
 otherwise it is assumed to use the uTF8String alternative.  The
 <IdentifiedChoiceValue> rule MAY be used for a value of type
 DirectoryString to indicate an alternative other than the one that
 would be assumed from the string contents.  No matter what
 alternative is chosen, the <Value> will still be a UTF-8 encoded
 character string.  However, it is a syntax error if the characters in
 the UTF-8 string cannot be represented in the string type of the
 chosen alternative.
 Implementations that do not care about the internal structure of a
 DirectoryString value MUST be able to parse the
 <IdentifiedChoiceValue> form for a DirectoryString value, though the
 particular identifier found will be of no interest.

Legg Standards Track [Page 9] RFC 3641 Generic String Encoding Rules October 2003

3.13. SEQUENCE and SET

 A value of a SEQUENCE type is encoded according to the
 <SequenceValue> rule.  The <ComponentList> rule encodes a comma
 separated list of the particular component values present in the
 SEQUENCE value, where each component value is preceded by the
 corresponding identifier from the SEQUENCE type definition.  The
 components are encoded in the order of their definition 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 value of a SET type is encoded according to the <SetValue> rule.
 The components are encoded in the order of their definition in the
 SET type (i.e., 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 are sometimes extended by the
 inclusion of additional component types, so an implementation SHOULD
 be capable of skipping over any <NamedValue> encoding with an
 identifier that is not recognised, on the assumption that the sender
 is using a more recent definition of the SEQUENCE or SET type.

3.14. SEQUENCE OF and SET OF

 A value of a SEQUENCE OF type 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 value of a SET OF type 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 "}"

Legg Standards Track [Page 10] RFC 3641 Generic String Encoding Rules October 2003

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

 A value of the EXTERNAL type is encoded according to the
 corresponding SEQUENCE type defined in Clause 8.18.1 of X.690 [12]
 (see [15] for equivalent ABNF).
    ExternalValue = SequenceValue

3.18. INSTANCE OF

 A value of the INSTANCE OF type is encoded according to the
 corresponding SEQUENCE type defined in Annex C of X.681 [9].
    InstanceOfValue = SequenceValue

3.19. REAL

 A value of the REAL type MUST be encoded as "0" if it is zero,
 otherwise it is encoded as the special value <PLUS-INFINITY>, the
 special value <MINUS-INFINITY>, an optionally signed <realnumber>, or
 as a value of the corresponding SEQUENCE type for REAL defined in
 Clause 20.5 of X.680 [8] (see [15] for 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

Legg Standards Track [Page 11] RFC 3641 Generic String Encoding Rules October 2003

    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 have special string
 encodings.  These special encodings are always used instead of the
 encoding that would otherwise apply based on the ASN.1 type
 definition.
    VariantEncoding = RDNSequenceValue /
                      RelativeDistinguishedNameValue /
                      ORAddressValue
 A value of the RDNSequence type, i.e., a distinguished name, is
 encoded according to the <RDNSequenceValue> rule, as a quoted LDAPDN
 character string.  The character string is first derived according to
 the <distinguishedName> rule in Section 3 of RFC 2253 [5], and then
 encoded as if it were a UTF8String value, i.e., between double quotes
 with any embedded double quotes escaped by being repeated.
    RDNSequenceValue = StringValue
 A RelativeDistinguishedName value that is not part of an RDNSequence
 value is encoded according to the <RelativeDistinguishedNameValue>
 rule as a quoted character string.  The character string is first
 derived according to 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 is encoded according to the
 <ORAddressValue> rule as a quoted character string.  The character
 string is first derived according to the textual representation of
 MTS.ORAddress from RFC 2156 [2], and then encoded as if it were an
 IA5String value.
    ORAddressValue = StringValue

Legg Standards Track [Page 12] RFC 3641 Generic String Encoding Rules October 2003

4. GSER Transfer Syntax

 The following OBJECT IDENTIFIER has been assigned by Adacel
 Technologies, under an arc assigned to Adacel by Standards Australia,
 to identify the Generic String Encoding Rules:
    { 1 2 36 79672281 0 0 }
 This OBJECT IDENTIFIER would be used, for example, to describe the
 transfer syntax for a GSER encoded data-value in an EMBEDDED PDV
 value.

5. Security Considerations

 The Generic String Encoding Rules do not define a canonical encoding.
 That is, a transformation from a GSER encoding into some other
 encoding (e.g., BER) and back into GSER will not necessarily
 reproduce the original GSER octet encoding.  Therefore, GSER MUST NOT
 be used where a canonical encoding is needed.
 Furthermore, GSER does not necessarily enable the exact octet
 encoding of values of the TeletexString, VideotexString,
 GraphicString or GeneralString types to be reconstructed, so a
 transformation from a Distinguished Encoding Rules (DER) [12]
 encoding to GSER and back to DER may not reproduce the original DER
 encoding.  Therefore, GSER MUST NOT be used to re-encode, whether for
 storage or transmission, ASN.1 abstract values whose original binary
 encoding must be recoverable.  Such recovery is needed for the
 verification of digital signatures.  In such cases, protocols ought
 to use DER or a DER-reversible encoding.
 When interpreting security-sensitive fields, and in particular fields
 used to grant or deny access, implementations MUST ensure that any
 comparisons are done on the underlying abstract value, regardless of
 the particular encoding used.

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.

Legg Standards Track [Page 13] RFC 3641 Generic String Encoding Rules October 2003

 [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.

Legg Standards Track [Page 14] RFC 3641 Generic String Encoding Rules 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 takes no position regarding the validity or scope of any
 intellectual property 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; neither does it represent that it
 has made any effort to identify any such rights.  Information on the
 IETF's procedures with respect to rights in standards-track and
 standards-related documentation can be found in BCP-11.  Copies of
 claims of rights made available for publication 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 implementors or users of this specification can
 be obtained from the IETF Secretariat.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights which may cover technology that may be required to practice
 this standard.  Please address the information 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

Legg Standards Track [Page 15] RFC 3641 Generic String Encoding Rules October 2003

9. Full Copyright Statement

 Copyright (C) The Internet Society (2003).  All Rights Reserved.
 This document and translations of it may be copied and furnished to
 others, and derivative works that comment on or otherwise explain it
 or assist in its implementation may be prepared, copied, published
 and distributed, in whole or in part, without restriction of any
 kind, provided that the above copyright notice and this paragraph are
 included on all such copies and derivative works.  However, this
 document itself may not be modified in any way, such as by removing
 the copyright notice or references to the Internet Society or other
 Internet organizations, except as needed for the purpose of
 developing Internet standards in which case the procedures for
 copyrights defined in the Internet Standards process must be
 followed, or as required to translate it into languages other than
 English.
 The limited permissions granted above are perpetual and will not be
 revoked by the Internet Society or its successors or assignees.
 This document and the information contained herein 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.

Legg Standards Track [Page 16]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3641.txt · Last modified: 2003/10/20 16:44 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki