Abstract Syntax Notation X (ASN.X)
draft-legg-xed-asd-07

[Ballot comment]
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.

Community discussion has strongly indicated that it is too early for this work to be confirmed as a Proposed Standard by the IETF community.  Putting it forward as Experimental makes the specifications available, and increases the chance the interested user communities will be able to define their need for this work.  It can be reconsidered as a proposed standard (or an updated document set, incorporating any changes can be) when the constinuency is more visible and the use cases more clear.

Last call comment from Tom Yu

The potential upcoming approval of these documents on the Standards
Track makes me uneasy, for reasons I can't yet articulate well.  I can
try to produce an improved analysis before these drafts come up on
next week's telechat.  I was not aware of the existence of these
drafts until recently.

These five documents appear to be a set of individual submissions
intended for the Standards Track.  I have concerns that such a large
(they collectively number about 375 pages) and ambitious body of work
may not have received adequate IETF review.  Steve Kent's review for
SecDir was useful to me in getting oriented within this massive
quantity of text.  A few questions came to my mind concerning these
drafts:

* Should a working group have reviewed this effort?  (It's possible
  that this has happened and I was not aware of it.)

* Is any of this work better addressed within the OSI standards
  process?

* Are these documents intended to have wider applicability than XED?

* For that matter, has XED itself actually had wide IETF review?

These drafts need to be checked by multiple ASN.1 experts to ensure
that they are consistent with the relevant ASN.1 standards.  The sheer
size of the drafts, combined with the size of the corresponding ASN.1
standards, makes this a massive undertaking.

draft-legg-xed-asd-07 describes a method of translating the entire
ASN.1 language; it necessarily has to be complete and consistent with
respect to the relevant ASN.1 standards.  Likewise,
draft-legg-xed-rxer-07 describes a set of ASN.1 encoding rules; it
necessarily has to have a complete specification for how to encode all
ASN.1 types.  The other drafts probably have related issues.

A somewhat fragmentary overview of my thoughts on these documents
follows.

These documents appear to support the XML-Enabled Directory (XED)
effort, which appears to be outlined in draft-legg-xed-roadmap-05.  It
took me significant effort to determine the motivations for these
documents, as I did not know that I needed to read xed-roadmap.  I'm
not sure that xed-roadmap is referenced in any of these documents,
either.

It is unclear whether these documents are intended for use by other
IETF protocols.  If that is the intent, they could use wider IETF
review.  The absence of obvious mentions of XED within these documents
suggests to me that they are intended for more general usage outside
of XED, in which case perhaps a great many different groups of people
need to look at these documents.

These drafts present two major concepts: Robust XML Encoding Rules
(RXER), which is a new set of encoding rules for ASN.1, and ASN.X,
which is effectively an XML representation of the semantic content of
the ASN.1 language.

draft-legg-xed-rxer-07 describes Robust XML Encoding Rules (RXER), an
alternative set of XML encoding rules for ASN.1.  X.693 is an OSI
standard for XML Encoding Rules for ASN.1 (XER), but xed-rxer argues
that RXER overcomes some flaws present in XER.

draft-legg-xed-asd-07 describes how to take an ASN.1 module and
translate it into an XML representation called ASN.X.  The semantic
content of a ASN.1 module and its ASN.X representation are meant to be
identical, thus defining identical data types and values.  While the
document does not describe the translation process in terms of
producing an RXER encoding, ASN.X modules are themselves valid RXER
encodings.

Appendix A is a tour de force which specifies ASN.X using
ASN.1... effectively an ASN.1 module which can represent other ASN.1
modules.  It should in principle be possible to encode ASN.X using an
encoding more compact than RXER, but the document does not mention
this possibility.

The motivation for ASN.X appears to be that the grammar of the ASN.1
language is difficult parse by machine, and having a readily
machine-parseable (XML, in this case) representation of the abstract
syntax of a protocol is useful.  It seems that XED uses ASN.X as a
means of communicating things such as user-defined syntaxes for
directory attributes.

draft-legg-xed-gserei-03, -asd-xerei-03, and -rxer-ei-04 concern the
notation called Encoding Instructions, defined in X.680 Amendment 1.
The drafts describe how to represent X.680amd1 Encoding Instructions
using ASN.X, thus allowing ASN.1 modules which make use of this
notation to be represented in ASN.X.  (Encoding Instructions are
somewhat poorly named: they are not encoding rules, but are ASN.1
language elements introduced in X.680amd1 which can alter how a given
set of encoding rules encodes the value of a type.)