RE: WG LAST CALL: draft-ietf-smime-rfc2632bis-03

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

> -----Original Message-----
> From: Jim Schaad [mailto:[e-mail]] 
> Sent: Wednesday, July 23, 2003 1:02 PM
> To: 'Blake Ramsdell'; [e-mail]
> Subject: RE: WG LAST CALL: draft-ietf-smime-rfc2632bis-03
> 
> 1. Section 1.2:  Does this need to be updated to refer to version 3.1
> agents as well?

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. References need to be divided.

Still missing what this means.

> 3. Acknowlegements is [TBD]

Updated:

Many thanks go out to the other authors of the S/MIME v2 RFC: Steve
Dusse, Paul Hoffman and Jeff Weinstein. Without v2, there wouldn't be
a v3.

A number of the members of the S/MIME Working Group have also worked
very hard and contributed to this document. Any list of people is
doomed to omission and for that I apologize. In alphabetical order,
the following people stand out in my mind due to the fact that they
made direct contributions to this document.

Bill Flanigan
Trevor Freeman
Elliott Ginsburg
Paul Hoffman
Russ Housley
David P. Kemp
Michael Myers
John Pawling
Denis Pinkas
Jim Schaad

> 4. Section at beginning of document on changes since RFC2632 is
> required.

Added:

1.4 Changes Since S/MIME v3.0

Version 1 and Version 2 CRLs MUST be supported.

Multiple CA certificates with the same subject and public key, but
with overlapping validity periods MUST be supported.

Version 2 attribute certificates SHOULD be supported, and version 1
attributes certificates MUST NOT be used.

MD2 use for certificate signatures discouraged, and security language
added.

Clarified use of email address use in certificates.  Certificates that
do not contain an email address have no requirements for verifying the
email address associated with the certificate.

Receiving agents SHOULD display certificate information when
displaying the results of signature verification.

Receiving agents MUST NOT accept a signature made with a certificate
that does not have the digitalSignature or nonRepudiation bit set.

Clarifications for the interpretation of the key usage and extended
key usage extensions.

> 5. KEYMAC as a reference sent me to keyed macs, not to key management
> for ACs.

Are you saying that you were personally confused about the use of the
reference term KEYMAC?

Updated:

Reference name changed from KEYMAC to ACAUTH.

> 6.  Section 4.4.2 - Key Usage is not a required extension.  
> What happens
> in para #4 if the extension is not present.  Does this imply that the
> bits are set?

I have no idea, since no one's really been able to explain the
difference between these two bits anyway.

Updated:

If the key usage extension is not specified, receiving clients MUST
presume that the digitalSignature and nonRepudiation bits are set.

Blake