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.