Continuing my 'sliced' review of the New ASN.1 drafts,
below are some more remarks on the AlgorithmInformation Module
and general elements of concern for both drafts.
The various RFC specific ASN.1 modules will be dealt with in
subsequent messages sent to the 'responsible' list (PKIX/SMIME) only.
(4) AlgorithmInformation Module
I had already raised the question of where this module should go to
-- in the PKIX draft only or in both drafts.
For more precise reference, I hereby renumber that issue to # (4a)
and continue the previous enumeration.
In the meantime, I have reported a bunch of comments for this
module off-list, mostly editorial in nature.
However, the following 3 items included in my message to the authors
might deserve feedback from the lists and are rephrased here:
(4b)
Some 'simple type' definitions from the RFC 5280 (PKIX1) modules
are needed in many modules.
It might make sense to move such definitions into the basic
PKIX-CommonTypes module, to simplify the module dependency graph.
Opinions?
(4d) DIGEST-ALGORITHM
DISCUSS:
Should the module new AlgorithmInformation module prepare for RHASH
(Krawczyk et al. Randomized Hashing) addition in a future document ?
Would need a bucket for the Nonce -- unless implemented as a parameter.
[ cf. draft-irtf-cfrg-rhash-01 (expired) and NIST Draft SP 800-106. ]
Opinions?
(4n) COMBINED ALGORITHMS
DISCUSS: Should a specific CLASS for combined (authenticated-
encryption) algorithms be added ?
Opinions?
(5) General topics for RFC specific ASN.1 modules
(5a) additional information?
To enhance the readability and utility of the drafts, I suggest to
add the following type of information to all respective sections
of both drafts:
(5a.1) Keyword in Section title
Ex. (PKIX draft) :
|4. ASN.1 Module for RFC 2560
---
|4. ASN.1 Module for RFC 2560 (OCSP)
(5a.2) Short intro to the purpose and scope of the module
At the very beginning of each section, I would appreciate a short
(one-sentence) paragraph that describes the scope and content of the
subsequent module. This can also be used to expand acronym[s] used
in the section headline (introduced by the above suggestion),
as required by RFC style policy.
Notable specifics should also be mentioned there.
Ex. (PKIX draft, section 4) :
| The subsequent ASN.1 module formally specifies the syntax of
| the 'basic' OCSP (Online Certificate Status Protocol) request
| and response messages as defined in [RFC2560] and includes the
| related OIDs.
| It also corrects an oversight in the original (1988 ASN.1) module
| in [RFC2560], supplying the missing definition for CRLReason.
(5a.3) IMPORTS pointers
I would appreciate to see the FROM clauses in all IMPORTS statements
amended by comments precisely pointing to the definition of the
referenced ASN.1 module.
Ex. (PKIX draft):
IMPORTS
.......
FROM PKIX1Implicit88 -- Section <x>
{ ... }
.....
FROM <rfc-module> -- Section <y> of RFC <zzz>
{ ... }
etc.
(5b) order of modules
Currently, the RFC specific modules are presented (in both drafts)
in ascending RFC number order, but the 'elementary' new module(s)
are presented first.
In the PKIX draft, it strikes that so many dependencies exist to
the PKIX1 modules from RFC 5280 which appears in tha last module
section of the PKIX draft.
Thus, the placement of the 'elementary' modules could be seen as
an indication of a reader-friendly bottom-up staggering of the
modules, but this principle is not followed subsequently.
If a general reordering following a topological sort of the
IMPORTS module dependency graph shall not be undertaken,
two relatively simple measures should be considered:
* moving more 'elementary type' definitions into the
PKIX-CommonTypes module, to simplify the module
dependency graph;
* moving the frequently uesd PKIX1 modules immediately after
the new 'basic' module(s), and leaving the remaining modules
in ascending RFC number order.
Opinions?
(5c) names of PKIX1 modules
Notwithstanding the remarks in Section 1.2 on module OIDs,
IMHO the _names_ of the new PKIX1 modules should be changed;
having "1988" in these names simply is very confusing.
s/1988/1992/ ?
[[ to be continued with per-RFC-module comments ]]
Kind regards,
Alfred Hönes.
--
+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. |
| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 |
| D-71254 Ditzingen | E-Mail: ah(_at_)TR-Sys(_dot_)de
|
+------------------------+--------------------------------------------+