ietf-smime
[Top] [All Lists]

RE: WG LAST CALL: draft-ietf-smime-rfc2633bis-04

2003-07-23 13:01:29

Comments are on the -05 version of the document.

1. Section 1.4 talks about version 3 not version 3.1 agents.

2. Section 2.1: Given your request for manditory inclusion of hash
algorithms in DigestAlgorithmIdentifier, is there a reason you don't
make population here atleast a SHOULD if not a MUST?

3. Section 2.2: There is no techincal reason that an S/MIME v2 client
cannot be augmented to verify an id-dsa-with-sha1 signature.  This
statement should be that S/MIME v2 clients are only REQUIRED to
implement rsaEncryption with either SHA-1 or MD5.

4. Section 2.2:  The required hash algorithms supported with
rsaEncryption needs to be noded as part of this section.

5. Section 2.3:  Agents should support ES Diffie-Hellman.  SS is not a
requirement.

6.  Section 2.4: CMS does not define the CompressedData content type
last time I checked.

7.  Section 2.4.4: Is there a reason why there is not any text
describing when one should and when one should not compress data?  (i.e.
don't compress after encryption).  Add reference to section 3.6?

8.  Section 2.5:  The text "Sending agents SHOULD generate one instance
of the signingCertificate
signed attribute in each S/MIME message." should state "signed attribute
in each SignerInfo structure".

9.  Section 2.5.2, para 4:  I would like to have the following text
added.  "
Because of the requirement for identical encoding, individuals
documenting algorithms to be used in the SMIMECapabilities attribute
should explicitly document the correct byte sequence for the common
cases."

10. Section 2.5.2, para 5:  I think we need to remove the "In the case
of symmetric algorithms,"  phrase from this paragraph.  The need for
dealing with parameters can occur for other algorithms such as OAEP, KEM
and PSS.  It may be necessary to distinguish more explicitly between
algorithm parameters such as rounds and block size as oppose to the IV.

11.  Section 2.5.2 - where do we document SMimeCapabilities for RC2?
Should be a 40-bit vs 128-bit difference between these which needs an
ASN.1 structure and encoding.  Based on reading of this document I could
not correctly encode these values.

12.  Section 2.5.3, last para:  what happended to the clock skew text
for SMIMECapabiltlies that clarifies what this sentence refers to? --
found it in section 2.7.1 - not immediately apparent should have some
type of reference in either 2.5.2 or 2.5.3 or both.

13.  Section 2.7.1, para 2:  Change reference to section 2.5.2

14. Section 2.7.1.2:  Should we remove this paragraph?  It does not
really follow from the fact that you recived a signed (by me) then
encrypted message that I was actually the party that enrypted the
message.  It could have been an DOS attacker, a gateway, an MLA and so
forth.

15. Section 2.7.1.3:  Need to be updated to comment on AES.

16.  Section 3.1, last para:  I would like to see some additional
comments provided to help people make the decision between a message
that is protecting the headers and a message which is an attachment.

17.  Section 3.1.2 para 3:  Change the "SHOULD NOT use 7-bit" to "SHOULD
use binary" to make a positive rather than a negative statement.

18.  Section 3.1, General:  Do you need to canonicalize before you
compress?

19.  Section 3.2.1:  Can we really justify limiting the file name to
eight characters any more?  All common windows platforms no longer have
this restriction.  Apple and Unix platforms have not had this
restriction for a long time (if ever).

20.  Section 3.2.2:  I would like to get some rewrites on this section
as to the purpose of S/MIME type.  I think it is JUST to provide
information about the information (misspelt in the document) about the
contained content.  It just happens that for display via UAs, the
distinction between signed and enveloped was consisted to be an
important part of the content.  Additionally, I think this is the
correct direction for us to tell people about how to define new
smime-types in the future.

The next question is weither a compressed only message would show up in
my mailbox.  I think that the correct smime-type for a compressed and
signed message is actually signed-data not compressed data.

21.  Section 3.4.1, last para:  Currently this reads

Messages signed using the signedData format cannot be viewed by a
recipient unless they have S/MIME facilities. However, if they have
S/MIME facilities, these messages can always be verified if they were
not changed in transit.

But duh for the last sentence.  The correct statement would be.
"However, the signedData format protects the message content from being
changed by benign intermediate agents.  Such agents might do line
wrapping or content-transfer encoding changes which would break the
signature."

22.  Section 3.4.3.2, algorithm table:  The last item in the table needs
to be removed.  The corect answer is that this value needs to be defined
by documents describing other hashing algorithms.

23.  Section 3.4.3.3:  Just for giggles, I think that adding a section
with the hex encoding of the acutal bytes hashed for this sample would
be a good idea.  This is one of the things people always have problems
with when doing multipart signed data.  Also it might be interesting to
make the body a multipart/alternative.  On the other hand this would
probably be better in an appendix.

24. Section 4:  Reference to [CERT3] needs updating.

25. Section 4.1:  Language and protocol statements needs to be updated
in this section to reflect the change in algorithms.

26. Appendix B:  Refernces need to be divided.


Jim


<Prev in Thread] Current Thread [Next in Thread>
  • RE: WG LAST CALL: draft-ietf-smime-rfc2633bis-04, Jim Schaad <=