Here are some terse comments on the Certs portion of the current
drafts after my first cursory reading.
I will be going to the meeting today, but I wanted to get this
off to the list.
Here are some comments on draft-dusse-smime-cert-02.txt
I would be happy to assist in rewriting relevant sections.
Section 1.1
X.208 is basically the dead spec of ASN.1. Use the
living version X.680, 681, 682, 683.
Similarly for BER/DER/CER please refer to X.690.
Probably good to include the ISO/IEC standard numbers as well rather
than just the ITU-T X.nn recommendation numbers. Everyone knows them
by the ITU-T X.nn numbers of course.
Section 2.1
For CRL you should use the X.509 v1 and v2 CRL definitions.
The [KEYM] (PEM RFC 142<n>) definition is inconsistent in an important
aspect. The nextUpdate field is incorrectly specified as
mandatory. In the X.509 spec it is OPTIONAL.
I recommend the following approach to avoid
problems,
One MUST accept the syntax in the OPTIONAL form as specified
in X.509 v1.
One SHOULD generate it with the nextUpdate field present.
This affects other mentions of the CRL format throughout the
document.
Also, here is another place where UTCTime is used. The recent
X.509 work has been keeping step with PKIX to get similar
CHOICE/GeneralizedTime wording in. It is important to
incorporate this by reference as well.
In summary, please stop referring to the PEM RFCs for X.509
related stuff.
Section 2.3
You should probably allow for implementation-defined limits on
"arbitrary number of certificates" to be conformant.
In a number of instances in the document, the Section 4.2
requirement for a sender to verify a recipient's certificate
is not properly accounted for; that is, there are cases where
certificate verification is discussed only in the context of
"receiving agents." The doc needs to be re-scanned for this
issue and fixed.
Section 3.1
Description of distinguished names is inaccurate. RDNs are
conceptually labels on the edges of a tree, not on the nodes.
The entire DN is an ordered sequence and not a "collection."
Yes, it specifies a path to a directory object.
The type AVA in RDNs has been replaced with a type ATV
(Attribute Type and Value) that is of the same syntax but
has different semantics.
Most of the discussion of X.500 should either be replaced by or
accompanied by references to LDAP, and the LDAP RFCs.
Section 3.2
From the security perspective, I recommend that the certificate MUST
include the subject's RFC 822 address, and that this not be left to
some external mapping.
The working group needs to specify (and coordinate with PKIX --current
discussion is occurring) a set of possible places in the cert among
which
this MUST be and recommend where it SHOULD be specified.
Note that because there is an interest in using DNs in certs in
conjunction with LDAP and X.500, that there is a desire within
PKIX to put the RFC 822 address in an alternate names extension.
However there is a recognition that current secure e-mail
implementations are using PKCS-9 EMailAddress in the DN.
The document says "Sending agents SHOULD include the Internet
Mail Address during Distinguished Name creation." Note in general,
that CAs have final determination of DN content in certs, regardless of
what appears in any certificate request.
Section 4.
Certificate Processing should refer to the PKIX verification procedure
and interpretation of the extensions.
Section 4.1
First paragraph. Sending and Receiving agents. Sending agents
do verification too!
Suggest that we remove sentence on "it is always better to get the
latest
information from the CA". This is true from the security perspective,
not necessarily from the perspective of network load and scaleability.
Section 4.4
This is out of date. Important omissions are AuthorityKeyIdentifier
and SubjectKeyIdentifier. This affects some Section 5 discussions as
well.
Section 5.1
Paragraph 3. Inaccurate since implementations are required to
disambiguate based issuer+serial. Right?
Paragraph 4. Inaccurate. You must account for key change/rollover.
Disambiguation of issuer certs when chain-building is handled by use of
AuthorityKeyIdentifier/SubjectKeyIdentifier usage.
Section 5.2
UNIVERSAL STRING is already an ISO ASN.1 type. So is BMPString now.
Use of T61String is deprecated amongst implementers but still in
the syntax.
The CHOICE should be
PrintableString
T61String
BMPString
UNIVERSAL STRING
Occurrences of this CHOICE should probably be changed to refer to
the X.520 type DirectoryString, so that we "keep up" by reference
with cert and dir practices.
A paragraph may be desirable regarding encoding of untyped character
strings into these choices, following the current implementation
practice of "using the simplest choice that fits" strategy.
The phrase "this attribute may hae multiple attribute values"
is confusing in this context because it applies primarily to
directoy objects. Here is where the semantics of ATVs and
AVAs is separate.
--
Anil R. Gangolli
Structured Arts Consulting Group
mailto:gangolli(_at_)StructuredArts(_dot_)com
http://www.StructuredArts.com