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

["Jim Schaad" <[e-mail]>]

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
>