Abstract Syntax Notation X (ASN.X) Representation of Encoding Instructions for the Generic String Encoding Rules (GSER)
draft-legg-xed-asd-gserei-03

  Comments are based on the SecDir Review by Steve Kent.

  draft-legg-xed-asd-07:

  Some of the introductory text for asd-07 abstract reads more like a
  marketing pitch than a technical abstract, touting the purported
  advantages of this syntax over ASN.1  I suggest that this text be
  modified to be more appropriate for an RFC.

  The Security Considerations section is short and to the point. In
  general, a syntax definition language like ASN.1 OR ASN.X is not
  intrinsically security relevant. Experience has shown that buggy
  implementations of encoders and decoders for such syntax can have
  adverse security implications, but this is not a property of the
  syntax per se. The author describes the need to "normalize" the
  syntax of an ASN.X module to ensure that decoding and re-encoding
  preserves the canonicalization. The normalization rules appear in
  another of these documents (draft-legg-xed-rxer-07.txt).

  Canonicalization is a security-relevant aspect of any syntax
  language, as one usually digitally signs canonical representations of
  data, to ensure that the signature can be verified despite possible
  encoding changes that may occur in transmission or storage of
  (digitally signed) data.

  draft-legg-xed-rxer-07:

  The Security Considerations section discusses the implications of the
  non-canonical representations under RXER, and thus the need to employ 
  CRXER whenever a canonical representation must be preserved, e.g., in 
  support of digital signatures. It also emphasizes the need to perform 
  comparisons on "underlying abstract values," vs. encodings, in 
  contexts such as comparisons used for access control determinations.

  draft-legg-xed-rxer-ei-04:

  The Security Considerations section in this document alerts the
  reader to a possible problem with regard to one specific encoding
  instruction (GROUP). Implementers of ASN.1 compliers are waned to be
  very careful re this encoding instruction, to avoid possible
  encode/decode errors that would break digital signatures and that
  might adversely affect access control decisions. My only concern with
  this warning is that is only says "don't get it wrong" without
  indicating what the author believes are common ways to "get it
  wrong," likely mis-interpretations of specs, etc.