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

["Blake Ramsdell" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Jim Schaad
> Sent: Wednesday, July 23, 2003 1:02 PM
> To: 'Blake Ramsdell'; [e-mail]
> Subject: RE: WG LAST CALL: draft-ietf-smime-rfc2633bis-04
> 
> Comments are on the -05 version of the document.
> 
> 1. Section 1.4 talks about version 3 not version 3.1 agents.

Updated:

S/MIME version 3.1 agents should attempt to have the greatest
interoperability possible with agents for prior versions of S/MIME.
S/MIME version 2 is described in RFC 2311 through RFC 2315, inclusive
and S/MIME version 3 is described in RFC 2630 through RFC 2634
inclusive. RFC 2311 also has historical information about the
development of S/MIME.

> 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?

Well, if you're referring to my position on 5/5/03, I believe this field
to be valueless, so it doesn't matter to me.  Not changed unless there's
some new information that I am missing.

> 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.

Updated:

Also note that S/MIME v2
clients are only required to verify digital signatures using the
rsaEncryption algorithm with SHA-1 or MD5, and may not implement
id-dsa-with-sha1 at all.

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

Updated:

If using rsaEncryption, sending and receiving agents MUST support the
algorithms in section 2.1 as specified.

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

Updated:

Sending and receiving agents SHOULD support Diffie-Hellman defined in
[CMSALG], using the ephemeral-static mode.

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

Updated:

There are several CMS content types. Of these, only the Data,
SignedData, EnvelopedData and CompressedData content types are
currently used for S/MIME.

> 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?

Updated:

See section 3.6 for further guidance on the use of this type in
conjunction with other CMS types.

> 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".

Updated:

Sending agents SHOULD generate one instance of the signingCertificate
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."

Updated:

The structure of the SMIMECapabilities attribute is to facilitate
simple table lookups and binary comparisons in order to determine
matches. For instance, the DER-encoding for the SMIMECapability for
DES EDE3 CBC MUST be identically encoded regardless of the
implementation. 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.

Updated:

For any capability, the associated parameters for the OID MUST specify
all of the parameters necessary to differentiate between two instances
of the same algorithm. For instance, the number of rounds and block
size for RC5 must be specified in addition to the key length.

> 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.

I believe that this definition should be in the CMSALG document (but
it's not).  Should we bite the bullet and just stick it in this one?  I
agree that it needs to be specified somewhere, but I feel a bit icky
about sticking it in here.
 
> 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.

Updated 2.5.2:

Section 2.7.1 explains a strategy for caching capabilities.


Updated 2.5.3:

Section 2.7.1 explains a strategy for caching preference data.

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

Updated.

> 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.

Removed.  I agree -- there is no way to know if a message that comes in
that has encryption applied after the signature has any relationship to
the signer.

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

I see your point.  The intent is to fall back to something useful for
any version of S/MIME, and the older evil US-only RC2/40 clients.  It's
not clear what discussion you'd have about AES here.

It may be the case that this rule should be removed completely.
Comments?

Not changed, but needs discussion.

> 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.

Added:

When an S/MIME message is received, if the top-level protected MIME
entity has a Content-Type of message/rfc822, it can be assumed that
the intent was to provide header protection. This entity should be
presented as the top-level message, taking into account header merging
issues as previously discussed.

> 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.

This was discussed in private mail also, and I believe that the
following is reasonable text to put in.

Updated:

S/MIME implementations which "know" that all intended recipient(s) are
capable of handling inner (all but the outermost) binary MIME objects
SHOULD use binary encoding as opposed to a 7-bit-safe transfer
encoding for the inner entities. The use of a 7-bit-safe encoding
(such as base64) would unnecessarily expand the message size.
Implementations MAY "know" that recipient implementations are capable
of handling inner binary MIME entities either by interpreting the
id-cap-preferBinaryInside sMIMECapabilities attribute, by prior
agreement, or by other means.

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

I'm gonna say "yes".  Updated:

Each MIME entity MUST be converted to a canonical form that is
uniquely and unambiguously representable in the environment where the
signature is created and the environment where the signature will be
verified. MIME entities MUST be canonicalized for enveloping and
compressing as well as signing.

> 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).

It's a SHOULD, so if you really wanna have more, go for it.

> 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.

So I think your position is that the smime-type should have the "most
relevant interpretation of the protected data", instead of the "actual
type that is being protected".  I think the best example is an IMAP
client getting the headers and changing the icon next to the message to
indicate what kind of message you've got.

We can ask the audience, but I think that the conventional wisdom is
that the smime-type represents the type of the outermost layer, and
that's it -- just a further clarification of the overloaded
application/pkcs7-mime.

Fixed speling of information, but I want to hear more about how else we
should change this to clarify the semantic (and what the semantic is).

> 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."

Indeed, duh for the last sentence.  Updated:

Messages signed using the signedData format cannot be viewed by a
recipient unless they have S/MIME facilities. 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.

Updated:

Any other   (defined separately in algorithm profile or "unknown"
             if not defined)

> 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.

I think that getting too far with the examples should be left to the
Examples draft and any successors.  I do agree that adding the hex dump
would be a good idea.

My attempt at the hex dump is this, but I need at least one other person
to double check it.

Updated:

The content that is digested (the first part of the multipart/signed)
are the bytes:

43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 74 65 78 74 2f 70 6c 61 69
6e 0d 0a 0d 0a 54 68 69 73 20 69 73 20 61 20 63 6c 65 61 72 2d 73 69
67 6e 65 64 20 6d 65 73 73 61 67 65 2e 0d 0a

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

Updated to [CERT31].

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

Updated.  Complete section is now:

4.1 Key Pair Generation

All generated key pairs MUST be generated from a good source of non-
deterministic random input [RANDOM] and the private key MUST be
protected in a secure fashion.

If an S/MIME agent needs to generate an RSA key pair, then the S/MIME
agent or some related administrative utility or function SHOULD
generate RSA key pairs using the following guidelines. A user agent
SHOULD generate RSA key pairs at a minimum key size of 768 bits. A
user agent MUST NOT generate RSA key pairs less than 512 bits long.
Creating keys longer than 1024 bits may cause some older S/MIME
receiving agents to not be able to verify signatures, but gives better
security and is therefore valuable. A receiving agent SHOULD be able
to verify signatures with keys of any size over 512 bits. Some agents
created in the United States have chosen to create 512 bit keys in
order to get more advantageous export licenses. However, 512 bit keys
are considered by many to be cryptographically insecure. Implementors
should be aware that multiple (active) key pairs may be associated
with a single individual. For example, one key pair may be used to
support confidentiality, while a different key pair may be used for
authentication.

> 26. Appendix B:  Refernces need to be divided.

I'm not sure what you mean by "divided"...

Blake