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

[Russ Housley <[e-mail]>]

Blake:

> > 1.  Should Section 1.4 reference RFC 3369?
>
>This section just describes where "prior practice of S/MIME" is located.
>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.
>
>Deleted.

Thanks.

> > 3.  Section 2.4 probably should point out that ContentInfo is
> > needed to
> > 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.

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

> > 4.  What compression algorithm MUST be implemented if
> > CompressedData is
> > supported?
>
>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
> > should/SMIMECapabilities
> > attribute SHOULD/
>
>Fixed.

Thanks.

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

Works for me.

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

Thanks.

Russ