Subject: CERT-06

From: Russ Housley <[email-masked]>
Date: Tue, 12 Jan 1999 10:55:01 -0500

Blake & S/MIME WG Members:

Here are my comments.

1.  In the "Overview," please change "I-D" to "document" to avoid changes
that the RFC Editor will have to make.

2.  Section 2.1 says: 
   Agents MUST use revocation information included as a CRL in an S/MIME
   message when verifying the signature and certificate path validity in
   that message. Agents SHOULD store CRLs received in messages for use in
   processing later messages.

What if a newer CRL is available in the Directory or cache?  The recipient
should not be forced to use a stale CRL because the originator included it
in the message.

3.  Section 2.3 says:
   Receiving agents MUST support chaining based on the distinguished name
   fields. Other methods of building certificate chains may be supported
   but are not currently recommended.

I agree that DN chaining must be supported.  However, I do not think that
we should discourage chain building based on key identifiers.

4.  Section 3.1 says:
   Receiving agents MUST recognize email addresses in the subjectAltName
   field. Receiving agents MUST recognize email addresses in the
   Distinguished Name field.

Should we say which attribute of the DN will be used to carry an e-mail
address?

5.  Section 3.1 says:
   Sending agents SHOULD make the address in the From or Sender header in
   a mail message match an Internet mail address in the signer's
   certificate. Receiving agents MUST check that the address in the From
   or Sender header of a mail message matches an Internet mail address in
   the signer's certificate, if mail addresses are present in the
   certificate. A receiving agent SHOULD provide some explicit alternate
   processing of the message if this comparison fails, which may be to
   display a message that shows the recipient the addresses in the
   certificate or other certificate details.

Name matching is not required for encryption.  Is this an omission?  If
not, let's explicitly state that the check is not needed.

6.  Section 4 says:
   A receiving agent needs to provide some certificate retrieval
   mechanism in order to gain access to certificates for recipients of
   digital envelopes. There are many ways to implement certificate
   retrieval mechanisms. X.500 directory service is an excellent example
   of a certificate retrieval-only mechanism that is compatible with
   classic X.500 Distinguished Names. The PKIX Working Group is
   investigating other mechanisms such as directory servers. Another
   method under consideration by the IETF is to provide certificate
   retrieval services as part of the existing Domain Name System (DNS).
   Until such mechanisms are widely used, their utility may be limited by
   the small number of correspondent's certificates that can be
   retrieved. At a minimum, for initial S/MIME deployment, a user agent
   could automatically generate a message to an intended recipient
   requesting that recipient's certificate in a signed return message.

The PKIX work in this area is ahead of us.  We should probably give a
better reference.  Also, the CRL should be discussed as well as the
certificate.

7.  Section 4.4 says:
   PKIX describes an extensible framework in which the basic certificate
   information can be extended and how such extensions can be used to
   control the process of issuing and validating certificates. The PKIX
   Working Group has ongoing efforts to identify and create extensions
   which have value in particular certification environments. As such,
   there is
   still a fair amount of profiling work to be done before there is
   widespread agreement on which extensions will be used. Further, there
   are active efforts underway to issue PKIX certificates for business
   purposes. This draft identifies the minumum required set of
   certificate extensions which have the greatest value in the S/MIME
   environment. The basicConstraints, and keyUsage extensions are defined
   in [KEYM].

In my opinion, this needs to be reworded.  The phrase "... there is still a
fair amount of profiling work to be done ..." says that we are not done!  I
do not think there is any more work to be done.  PKIX Part 1 is with the
RFC Editor.

8.  Section 4.4.2.1 says:
   For Diffie-Hellman key exchange certificates (certificates in which
   the subject public key algorithm is dhpublicnumber), more
   clarification is needed as to how to interpret the key usage
   extension. If the keyUsage keyAgreement bit is set to 1 AND if the
   public key is to be used to form a pairwise key to decrypt data, then
   the S/MIME agent MUST only use the public key if the keyUsage
   encipherOnly bit is set to 0. If the keyUsage keyAgreement bit is set
   to 1 AND if the key is to be used to form a pairwise key to encrypt
   data, then the S/MIME agent MUST only use the public key if the
   keyUsage decipherOnly bit is set to 0.

In my opinion, this needs to be reworded.  The phrase "... more
clarification is needed ..." leads the reader to think we are not finished
with our work.  We are done!

Russ