----- Forwarded message from Alfred Hönes -----
From A(_dot_)Hoenes(_at_)TR-Sys(_dot_)de Sun May 18 16:37:14 MES 2008
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3)
id AA250571434; Sun, 18 May 2008 16:37:14 +0200
Return-Path: <A(_dot_)Hoenes(_at_)TR-Sys(_dot_)de>
Received: (from ah(_at_)localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3)
id QAA11896; Sun, 18 May 2008 16:37:12 +0200 (MESZ)
From: Alfred Hönes <ah(_at_)TR-Sys(_dot_)de>
To: blake(_at_)sendmail(_dot_)com, turners(_at_)ieca(_dot_)com
Message-Id: <200805181437(_dot_)QAA11896(_at_)TR-Sys(_dot_)de>
Date: Sun, 18 May 2008 16:37:12 +0200 (MESZ)
Subject: draft-ietf-smime-3850bis-02
Hello,
I'd like to also submit a few comments on your I-D,
draft-ietf-smime-3850bis-02.
(1) Conventions used ...
a) I have not followed the progress of
draft-hoffman-additional-key-words,
but it looks like the evolution of that document might
be worth being monitored or coordinated with, in order
to avoid repeated re-specification of the new keywords.
b) last paragraph:
MUST- This term means the same as MUST. However, we expect at some
point that this algorithm will no longer be a MUST in a future
document. [...]
I'd give preference to the word-shuffled variant:
| MUST- This term means the same as MUST. However, we expect that at
| some point this algorithm will no longer be a MUST in a future
document. [...]
(2) Section 2.2
Without explanation, the draft says:
Receiving agents MUST support v1 X.509 and v3 X.509 identity
certificates as profiled in [KEYM]. [...]
This comes to surprise. Why are v2 certificates excluded?
The deliberations in RFC 5280 seem to make v1 much less preferable.
If there ideed are reasons for this particular requirement, a hint
on the rationale would be useful.
(3) Section 3
Below the ASN.1 fragment, please
s/an upper bounds/an upper bound/
^
(4) Section 4.3
The last paragraph says:
A receiving agent MUST be capable of verifying the signatures on
certificates and CRLs with key sizes from 512 bits to 2048 bits.
This requirement seems to be taylored to RSA/DSA key sizes,
but possibly not appropriate for the developing ECDSA context.
To not inappropriately exclude shorter ECDSA key sizes and request
support for unusually large ECDSA key sizes, the above statement
should perhaps be restricted in scope. Matching the algorithm
support requirements in the earlier parts of 4.3, but not precluding
future more previce specification of ECDSA use with PKIX, CMS, and
S/MIME, I propose to amend the above statement to say:
vvvvvvvvvvvvv
| A receiving agent MUST be capable of verifying RSA and DSA signatures
on certificates and CRLs with key sizes from 512 bits to 2048 bits.
(5) Sections 6
The lenghty deliberations on MD2 in this section seem to be aged,
or almost historical now. Shouldn't there be some words pointing
out more recent developments, in particular the perceived issues
with / reduced confidence in MD5 (and perhaps also SHA-1) as well?
(6) Appendix A
It is very unusual to label these sections "Appendix".
I suggest to renumber "Appendix A" to "Section 7".
"[RFC-2822]" is the only ref. tag used incorporating an RFC number.
I do not know the planned schedule, but it might happen that
2822-upd will be faster on the publication track, making a ref.
update necessary. To prepare for it, and to arrive at a more
homogenous ref. tag style, I suggest replacing "[RFC-2822]"
by "[IMF]".
For clerical completeness, I note the race condition that has
occurred by nearly concurrent publication events, making the
draft miss the ref. update: [KEYM] --> RFC 5280.
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
|
+------------------------+--------------------------------------------+
----- End of forwarded message from Alfred Hönes -----