Paul & Jim,
as promised quite some time ago, I have started a review of the
New ASN.1 Modules drafts, now that they have arrived at WGLC.
Firstly, I want to thank you for this huge effort and the
'orthogonalization' of the naming style performed, which in part
might not have been possible before this synoptical re-working
of many less coordinated previous efforts.
In order to speed things up and keep message lengths bounded,
I'll report my detailed findings in successive pieces, as soon
as time avails.
(0)
I have derived from the PKIX list discussion that both drafts
need additional language in their 'executive level text' to better
motivate the long-term switch to the new ASN.1, and hence the aim
for Standards Track, which I strongly support.
There would indeed be no reason for Standards Track if the single
benefit of the whole effort only would be "simply a change to the
syntax". It already has been pointed out that the major benefit
is the formatization of a significant amount of syntactical
information that in the 1988 ASN.1 could only be represented
*informally* as ASN.1 comments, or in explanations in the prose
-- most notably the mess with unspecified sets of allowed OIDs and
dependent objects with 'ANY' syntax (e.g. algorithm parameters).
We all need to get acquainted with the 'new ASN.1', but I expect
that the long-term benefits in precision will far outweigh the
necessary one-time effort.
As some kind of 'draft marketing', the benefits of migrating to the
new syntax should be emphasized at first place, in the Abstract and
in the leading paragraph(s) of Section 1, in both drafts.
Below are a few nits and comments for the (almost) common parts of
both drafts. More TBD.
For brevity, I'll denote the two drafts,
draft-ietf-pkix-new-asn1-02 and draft-ietf-smime-new-asn1-02,
by "PKIX draft" and "CMS draft", respectively.
(1) Section 1, paragraphs below the bullets -- typo (both drafts)
The following typo occurs 3x :
- in the two last paragraphs in the PKIX draft, and
- in the penultimate para in the CMS draft.
s/defintions/definitions/
^^ ^^^
(2) Section 1.2.1 (both drafts)
Let's take the authoritarian way.
The figures in the OIDs are not worth of lenghty discussions.
Russ Housley, the maintainer of
http://www.imc.org/ietf-pkix/pkix-oid.asn
seems to be the canonical trusted 3rd party to do this. :-)
(3) PKIX-CommonTypes module ( PKIX draft, Section 2 )
(Linear walk-through)
(3a) typo
-- ATTRIBUTE
--
| -- Describe the set of data assoicate with an attribute of some type.
--- ^^^^^^
-- ATTRIBUTE
--
| -- Describe the set of data associated with an attribute of some type.
^^^^^^^
(3b) punctuation
Better use a semicolon -- full sentence follows:
v
| -- &Type is the ASN.1 type structure for the attribute, not all
-- attributes have a data struture, so this field is optional
--- v
| -- &Type is the ASN.1 type structure for the attribute; not all
-- attributes have a data struture, so this field is optional
(3c) typo
v
| -- &minCount contains the mininum number of time the attribute can
-- occur in an AttributeSet
--- v
| -- &minCount contains the minimum number of time the attribute can
-- occur in an AttributeSet
(3d) typo
vv
| -- Currently we are using two differen prefixes for attributes.
--- vvv
| -- Currently we are using two different prefixes for attributes.
(3e) ref.?
-- MATCHING-RULE is imported from InformationFramework.asn
For completeness: Can you give a reference?
[ Sorry, shame on me: I did not arrive yet at studying
the complete X.68* document set. :-) ]
(3f) word shuffling?
| -- MATCHING-RULE information object class specification
Too many nouns in sequence; semantics depend on how you set the
imaginary brackets.
Is this a better, less ambiguous alternative? :
| -- specification of MATCHING-RULE information object class
(3g) AttributeSet vs. SingleAttribute
The formal parameter is a placeholder, isn't it?
Because it plays the same role in both cases, wouldn't it be
reasonable to reuse 'Attrs' for SingleAttribute (in favor of
'AttributeSet') ?
Alternatively, in both cases 'AttributeSet' might be used, in a
similar manner as the draft does for Extensions (subsequently).
IMO, using the long version specifically for SingleAttribute might
be confusing for human readers (mixing up the different meta levels).
(3h) EXTENSION -- word omission
v
-- This class definition is used describe the association of
-- object identifier and ASN.1 type structure for extensions
--- vvvv
-- This class definition is used to describe the association of
-- object identifier and ASN.1 type structure for extensions
(3i) EXTENSION ff. -- need more info
The intent of the commented-out &Critical needs to be explained.
Is this a proposal to be judged/evaluated by the WG?
(3j) Security Category -- use of case
I suggest to always use uppercase "RFC" in favor of mixing it with
lowercase "rfc". Hence, please change:
-- Security categories are used both for specifing clearances and for
| -- labeling objects. We move this here from rfc 3281 so that they
-- will use a common single object class to express this information.
---
-- Security categories are used both for specifing clearances and for
| -- labeling objects. We move this here from RFC 3281 so that they
-- will use a common single object class to express this information.
(4) AlgorithmInformation Module(s)
It turns out that Section 3 of the PKIX draft and Section 2 of the
CMS draft are identical.
I did not find a statement clearly announcing this important fact.
This is a poor service level for potential readers.
Concern: Duplicated specification incurs danger of divergence
and duplicated maintenance efforts in the future;
Benefit: Better readability / self-containment of both drafts.
However: PKIX-CommonTypes module is only in the PKIX draft!
Possible ways to deal with:
a) Leave module in both drafts;
add statement to first paragraph (intro) of the
abovementioned sections clearly stating the duplication.
b) Leave module in both drafts, but declare the copy in the
PKIX draft as normative and the copy in the CMS draft as
non-normative; adjust wording in to first paragraph (intro)
of the abovementioned sections of both drafts to clearly
indicate the duplication and the role of the sections;
also update the final part of Setcion 1 accordingly,
in both drafts.
c) Only keep this module in the PKIX draft;
change language in CMS draft, end of Section 1, accordingly.
d) Move both 'fundamental' modules to a third draft.
Opinions?
My personal preference is for c).
[[ to be continued ]]
Kind regards,
Alfred.
--
+------------------------+--------------------------------------------+
| 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
|
+------------------------+--------------------------------------------+