Subject: Re: WG LAST CALL: draft-ietf-smime-rfc2633bis-07.txt

From: Russ Housley <[email-masked]>
Date: Mon, 01 Mar 2004 00:16:27 -0500

Hare are seven comments.  I think number 6 is the most significant one, but 
none of them are show stoppers.

1.  Should Section 1.4 reference RFC 3369?

2.  Delete section 1.6 before the document is sent to the IESG.

3.  Section 2.4 probably should point out that ContentInfo is needed to 
encapsulate each of the protection content types.

4.  What compression algorithm MUST be implemented if CompressedData is 
supported?

5.  Section 2.5.2: s/SMIMECapabilities attribute should/SMIMECapabilities 
attribute SHOULD/

6.  Section 2.6:  the first two paragraphs are not clear.  S/MIME v3.1 MUST 
support both issuerAndSerialNumber and subjectKeyIdentifier for sending and 
receiving.

7.  Section 3.4.3.2: s/not currently supported in S/MIME/not currently 
recommended in S/MIME/

Russ

---

From: "Sean P. Turner" <[email-masked]>
Date: Tue, 02 Mar 2004 09:32:11 -0500

Russ,

For #4 ZLIB compression algorithm from RFC1950/1951 is a MUST in the 
RFC3274 do we need to say it again here?

spt

Russ Housley wrote:

>
> Hare are seven comments.  I think number 6 is the most significant 
> one, but none of them are show stoppers.
>
> 3.  Section 2.4 probably should point out that ContentInfo is needed 
> to encapsulate each of the protection content types.
>
> 4.  What compression algorithm MUST be implemented if CompressedData 
> is supported?
>
> 5.  Section 2.5.2: s/SMIMECapabilities attribute 
> should/SMIMECapabilities attribute SHOULD/
>
> 6.  Section 2.6:  the first two paragraphs are not clear.  S/MIME v3.1 
> MUST support both issuerAndSerialNumber and subjectKeyIdentifier for 
> sending and receiving.
>

---

From: Russ Housley <[email-masked]>
Date: Mon, 01 Mar 2004 19:56:05 -0500

>RFC3274 do we need to say it again here?

Yes.  The decision of the S/MIME WG more than a year ago was to put all of 
the mandatory to implement algorithms in this document.  In this case, we 
need to say:

      If an implementation chooses to support compression, then
      the implementation MUST support the ZLIB compression
      algorithm.

Russ

---

From: "Blake Ramsdell" <[email-masked]>
Date: Thu, 25 Mar 2004 20:44:00 -0800

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]] 
> Sent: Sunday, February 29, 2004 9:16 PM
> To: Blake Ramsdell; [email-masked]
> Subject: Re: WG LAST CALL: draft-ietf-smime-rfc2633bis-07.txt
> 

This section just describes where "prior practice of S/MIME" is located.
I think that RFC 3369 is "current practice of S/MIME".

> 2.  Delete section 1.6 before the document is sent to the IESG.

Deleted.

> encapsulate each of the protection content types.

Hmm. I don't agree. This is meant to describe the subset of types that
are supported by S/MIME, independent of their encoding.

> 4.  What compression algorithm MUST be implemented if 

Has this train finished wrecking or is it still in progress?

> 5.  Section 2.5.2: s/SMIMECapabilities attribute 

Fixed.

> support both issuerAndSerialNumber and subjectKeyIdentifier 

S/MIME v3.1 implementations MUST support both issuerAndSerialNumber as
well as subjectKeyIdentifier. Messages that use the
subjectKeyIdentifier choice cannot be read by S/MIME v2 clients.

> 7.  Section 3.4.3.2: s/not currently supported in S/MIME/not 

Fixed.

Blake

---

From: Russ Housley <[email-masked]>
Date: Fri, 26 Mar 2004 09:31:58 -0500

>I think that RFC 3369 is "current practice of S/MIME".

Okay.

> > 2.  Delete section 1.6 before the document is sent to the IESG.

Thanks.

>are supported by S/MIME, independent of their encoding.

Okay.  I accept that ContentInfo is not a content type.

>Has this train finished wrecking or is it still in progress?

I think we know where all the pieces landed.

> > 5.  Section 2.5.2: s/SMIMECapabilities attribute

Thanks.

>subjectKeyIdentifier choice cannot be read by S/MIME v2 clients.

Works for me.

> > 7.  Section 3.4.3.2: s/not currently supported in S/MIME/not

Thanks.

Russ