Early Review of draft-housley-asn1-layman-guide-01
review-housley-asn1-layman-guide-01-opsdir-early-farrel-2026-08-13-00

Hi,

I have been selected as the Operational Directorate (opsdir) reviewer for this
Internet-Draft.

The Operational Directorate reviews all operational and management-related
Internet-Drafts to ensure alignment with operational best practices and that
adequate operational considerations are covered.

A complete set of _"Guidelines for Considering Operations and Management in
IETF Specifications"_ can be found at
https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5706bis/.

This review is in response to a review request by the Independent
Submissions Editor (ISE) and is provided as part of the OPS Dir review
of documents approaching potential publication. While the review looks
at the document from an operational perspective, it is up to the authors
and ISE how they respond to this review - the OPS ADs, who would
normally have an interest in this review, will only get to comment as
part of the RFC 5742 review and are unlikely to use this review as
anything other than an observational comment. This review makes no
recommendation to the ISE about whether or not to publish this
document as an RFC.

Document: draft-housley-asn1-layman-guide

Title: A Layman's Guide to a Subset of ASN.1, BER, and DER

Reviewer: Adrian Farrel

Review date: 2026-08-13

Intended Status: Informational on the Independent Submissions Stream

---

## Summary

Has Issues: I have some minor concerns about this document that I think should
be resolved before publication.

## General Operational Comments Alignment with RFC 5706bis

This document is a tutorial / cookbook on a common subset of ASN.1
(and the BER/DER encodings) that is necessary to work with many
IETF documents, especially those in the Security realm. It offers
a distillation of the information in the CCITT/ITU-T specifications,
and provides examples to better explain the data types.

The document is readable, although it certainly helped that I have
some (albeit ancient) familiarity with the subject matter. I think the
"average" reader would find the document a bit hard to get started with,
but once into the main text it gets a lot easier.

From an operational perspective, this is a useful document in that it
enables implementers and operators to have a clear understanding of
ASN.1 which should achieve more robust implementations and easier
debugging of operational systems.

However, while the inclusion of an Operational Considerations section
per draft-ietf-opsawg-rfc5706bis is not mandatory, I believe some
thought along those lines would be useful and would make the document
more complete. One might consider diagnostic tools that intercept and
decode BER/DER from the wire to display the data for operators, and
one might consider (in conjunction with the security considerations
section) the impact of very large or complex encodings on the message
sizes and network capabilities.

The document might also give advice on how failed decoding should be
handled (i.e., caused by misencoding) and whether there is any need
for version coordination between encoders and decoders.

It is is a long document covering relatively complicated material, so
it should be no surprise that I found a few things to comments on. These
are grouped below as:
- Issues
- Issues so trivial you can ignore them
- Nits

Cheers,
Adrian

===

==Issues==

The Document title and Abstract need to say what subset. I mean, "An
introduction/guide to *a* subset" is not very clear or helpful.

The Abstract and Introduction make a stab at explaining the purpose,
and so hint at what the subset is:

   The purpose of this note is to
   provide background material sufficient for understanding and
   implementing standards that make use of ASN.1.

...and...

   The purpose of this note is to describe a subset of ASN.1, BER and
   DER sufficient to understand and implement OSI-based applications,
   Public-Key Cryptography Standards (PKCS), and Internet protocols that
   make use of ASN.1.

...but that is still unclear. Is the description "sufficient to
understand" or is the subset "sufficient to implement"? And, indeed,
presumably the sufficiency of the material is predicated on the
standards restricting themselves to the subset.

I'd suggest breaking it out into two separate things:
- There is a subset. What subset? Why is a subset valuable?
- This is an introduction and description. For what purpose? Which
  readers?

The vaugeness about the "subset" persists throughout the document. For
example, in section 2 you have:
   Table 1 lists some ASN.1 types and their
   universal-class tags.
That is true, but feels a bit random.

All that said, the draft is missing an explanation of why it is even
necessary given that one can read [X680] and [X690] and the text even
says "if you want to know more, read the specs."

When you get to 2.2 there is a clue:
   ASN.1 defines
   four, all of which are relevant to the PKCS standards:
If this is all about PKCS (and why not?) then perhaps call this out from
the start as the purpose and definition of the subset.

---

Section 1.1 is a nice record of history. However, it claims that change
control has been transferred to the IETF. By publishing in the
Independent Submission Stream, you are not assigning change control to
the IETF: simply publishing in the RFC Series.

---

The Introduction says, "Advanced features of ASN.1, such as CLASS, are
not described in this note," yet 1.1 notes:
   The changes from the third version include:

   *  Discussion of CLASS was added as the replacement for ANY following
      the modern ASN.1 specification;
...and, indeed, 5.3 then discusses CLASS a little.

---

I think the BCP14 boilerplate should be stripped from section 1.2. In
fact, it brings conflict with the ASN.1 qualifier "OPTIONAL", and you
don't use any of the BCP14 language.

---

2.

You have...

   Universal:
      for types whose meaning is the same in all applications; these
      types are specified in [X680].

...and...

   The types with universal tags are defined in X.208, which also gives
   the types' universal tag numbers.

So...
- X.680 or X.208?
- Why is X.208 not a reference?

---

2.

   *  Comments begin with a pairs of hyphens ('--'), and comments end
      with another pair of hyphens or a line break.

This is true for single line comments. X.680 allows for multi-line
comments using /* and */. It's OK to rule that out here, but if you do,
I think you have to say that multi-line comments are achieved using
multiple single line comments.

---

2.

   *  Identifiers (names of values and fields) and type references
      (names of types) consist of upper- and lower-case letters, digits,
      hyphens, and spaces; identifiers begin with lower-case letters;
      type references begin with upper-case letters.

This diverges from X.680 and could cause some chaos with run on to the
next elements. X.680 has...

   An "identifier" shall consist of an arbitrary number (one or more) of
   letters, digits, and hyphens. The initial character shall be a lower-
   case letter. A hyphen shall not be the last character. A hyphen shall
   not be immediately followed by another hyphen.

---

2.1

I always found it helpful to clarify whether arbitrary strings of foo
can be zero length.

---

2.1

Could you include references for UTF-8, T.61, and UTC?

---

Should section 3 have a reference to X.690?

---

3.1 has:

   It requires that the length of the value
   be known in advance

I know what you mean, but I think your words are unclear. "In advance"
could mean "in advance of encoding", but actually you mean "in advance
of encoding and decoding". So it may be better to write:

   It requires that the length of the value
   be known a priori

Similar shows up in 3.2.

---

3.1

      Low-tag-number form.  One octet.  Bits 8 and 7 specify the class
      (see Table 2), bit 6 has value "0", indicating that the encoding
      is primitive, and bits 5-1 give the tag number.

      High-tag-number form.  Two or more octets.  First octet is as in
      low-tag-number form, except that bits 5-1 all have value "1".

The ltn form definition is slightly unclear because (of course) bits
5-1 do not always give the tag number (as you go on to say). So, I think
you need to add to the ltn definition, "...except that the value 31 with
all 5 bits set has special meaning as below."

---

3.1.1

ML-DAS-44 is introduced here for the first time (and appears later,
along with ML-DSA) as though the reader is supposed to know what it
means. I know we are all post-quantum these days, but this all seems a
bit presumptuous about the poor reader.

---

3.2

I suggest that you add clarification to your example (as voiced in 3.3)
to say that the 8 byte OCTET STRING is in constructed form with 4 byte
elements.

---

The two main types that are in X.580 but you left out of section 5 are
enumerated and real. It's OK if you really don't feel they are an
important part of the base subset you want to describe. Just checking.

---

Not sure all of the key words are defined clearly before they are used.
For example, "OPTIONAL" and "DEFAULT" are used quite a bit, but the
clear explanation doesn't appear until 5.13. For example, "DEFINED BY"
never really gets explained. Probably some more.

Of course, the meaning is pretty clear, but still...

---

5.5 seems to be the only subsection in section 5 that doesn't have
preamble to say what the type actually is and describe the ASN.1
notation.

---

5.7

   16 11 74 65 73 74 31 40 65 78 61 6d 70 6c 65 2e 63 6f 6d DER encoding

Do you mean "BER"?

---

5.8

   where identifier1, ..., identifierN are optional distinct identifiers
   and value1, ..., valueN are optional integer values.  The
   identifiers, when present, are associated with values of the type.
   INTEGER is always signed.

I'd prefer if the language made it clear that the pair identifieri valuei
were mutually dependent. Current text makes it sound like they are
independently optional.

---

5.11 shouldn't you also give an example of indefinite length encoding?

Also for 5.12, 5.17, and 5.20?

---

5.17

   Note: The use of T61String is generally discouraged, and the use of
   UTF8String is preferred.

That feels a bit passive-voice to me. Who does this discouraging and
preferring?

== Issues so trivial you can ignore them ==

While finding nothing to degree with, I found the Introduction rather
frothy. Given that the document title and Abstract presume that people
are coming at all this with an understanding of what ASN.1, BER, and DER
are, maybe the text could be reduced to just some references.  The text
at the very start of Section 2 seems like a perfect introduction.

---

5.9

It is unimportant, but I seem to recall a fun wrinkle where NULL could
take any length. This was useful for overwriting other types without
shuffling data.

== Nits ==

Section 1, para 2
s/involve/involves/

---

Section 1, para 3
s/in terms of others/in terms of other types/
s/(Distinguished Encoding Rules/(Distinguished Encoding Rules)/

---

s/1.2.  Terminology and notation/1.2.  Terminology and Notation/

Check other section headings for capitalisation.

---

1.2
s/delimits alternatives with a/delimits alternatives within a/

---

2.
OLD
   *  Comments begin with a pairs of hyphens ('--'), and comments end
      with another pair of hyphens or a line break.
NEW
   *  Comments begin with a pair of hyphens ('--'), and end
      with another pair of hyphens or a line break.
END

---

2.1

s/non- string/non-string/
s/indefinite- length/indefinite-length/

---

3.1

s/(for tag numbers between 0 and 30)/(for tag numbers from 0 to 30)/

---

3.1

Paragraph starting "82 0c 80 the first octet" needs to be double
indented.

---

5.1

s/implied.  (See Section 2.3.)/implied (see Section 2.3.)./

---

5.2

s/context- specific/context-specific/

---

5.11

   Example: The BER encoding of the OCTET STRING value 01 23 45 67 89 ab
   cd ef is

Isn't that DER?

---

5.15

The formatting of the pseudocode examples is snafu'd in the TXT version.

---

It would be nice if you could use URL references so that the line
lengths are conformant for TXT files.