Blake,
I have now finished (almost) this year's work in the winery. Items of
agreement are gone.
jim
Comments are on the -05 version of the document.
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.
[JLS] - I agree that the best place is to put it into the CMSALG draft.
This falls into the - Yes, but we can't do it. Since SMimeCapabilities
is not defined in the CMS document, CMSALG can't reference it. CMSALG
must not reference the S/MIME documents. Unless you want Russ to add
SMIMECapabilities to CMS and this to CMSALG then it must go into this
document however icky.
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.
[JLS] I think the best thing to do with be an information reference to
"For what we use to do look at .... We no longer provide guidence on
this because things have changed so much.
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).
[JLS] I have definitely moved to the position that this information is
to tell what is inside the message rather than what security has been
added to the message.. This is also the position that is held in
several different documents (include ESS with receipts).
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
[JLS] I will look at doing this before next week.
26. Appendix B: Refernces need to be divided.
I'm not sure what you mean by "divided"...
Normative vs Informational as you have noted elsewhere.
Blake