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