Below are comments to the cert handling draft. Most of them
are editorial in nature. I really haven't been following
this draft so I may have made some improper assumptions. Use
them for what they're worth.
- clause 3.1 seemed to be placing quite a bit under the
heading of DN for Internet mail. I've made the following
assumptions: the section is really Using Internet Mail for
DN; the section was addressing using an e-mail address in
place of the Extension.subject DN; the section was
addressing how receiving agents handle using e-mail as a DN.
Below is recommended text. In it the Issuer and Subject
names were moved out of section 3.1 to the more generic
section 3.0, and added a clause that when using the email as
DN the Extension.subject field should be empty,
3. Distinguished Names in Certificates
Issuer names MUST be populated (i.e. not an empty SEQUENCE)
in S/MIME-compliant v3 X.509 Certificates.
Subject names MUST be populated in S/MIME-compliant v3 X.509
Certificates, unless identity information is present only in
the subjectAltName extension (see 4.4.3) in which case the
subject may contain an empty SEQUENCE. In the latter case
the subjectAltName extension MUST be marked as critical.
3.1 Using Internet Mail for Distinguished Names
End-entity certificates MAY contain an Internet mail address
as described in [RFC-822]. The address MUST be an
"addr-spec" as defined in Section 6.1 of that specification.
The email address SHOULD be in the subjectAltName
When used as a subject identifier, email addresses SHOULD
NOT be in the subject distinguished name. The subject
distinguished name SHOULD instead contain an empty SEQUENCE.
Receiving agents MUST recognize email addresses in the
certificate subjectAltName extension. While using email
addresses in the certificate subject field is not
recommended by this document, receiving agents MUST be able
to recognize email addresses in the subject Distinguished
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
- I thought that section 4.4 was a little wordy and
redundant. Below is recommended text which express the
following: changed "X.509 v3 standard" (never saw it
expressed like that); and the draft called out a " minimum
required set" of extensions but doesn't say what it is (I
made the assumption that it was the 5 extensions that the
agents were required to handle) and that although "minimum
required" would suggest a MUST the later definition of the
extensions suggested that it was a SHOULD.
4.4 X.509 Version 3 Certificate Extensions
The X.509 standard [X.509] 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 v3
extensions will be used. Further, there are active efforts
underway to issue X.509 v3 certificates for business
At a minimum, the basicConstraints, keyUsage,
authorityKeyID, subjectKeyID, and the subjectAltNames X.509
v3 certificate extensions, defined in [X.509], SHOULD be
supported. Other X.509 v3 certificate extensions MAY also be
supported. Unless the extension is deemed critical for
correct interpretation of the associated certificate or
otherwise noted in this document, all extensions SHOULD be
marked as non-critical.
Sending and receiving agents MUST correctly handle the v3
Basic Constraints Certificate Extension, the Key Usage
Certificate Extension, authorityKeyID, subjectKeyID, and the
subjectAltNames when they appear in end-user certificates.
Some mechanism SHOULD exist to handle the defined v3
certificate extensions when they appear in intermediate or
Unless otherwise specified in this document, interpretation
and syntax for all extensions MUST follow [KEYM].
- clause 4.4.1 - 4.4.3: address 3 of the 5 recommended
extensions in more detail (i.e. basicConstraints, keyUsage,
and subjectAltNames) were the other two (authorityKeyID and
subjectKeyID) omitted for a reason? Recommend giving the
criticality of all of the extensions defined in these
sections in the same manner as 4.4.2.
- clause 4.4.1: doesn't indicate whether the extension is
critical and one would assume based on earlier guidance in
the document that is should be non-critical (by default).
Recommendations from both X.509 (1997) and the PKIX profile
would seem to suggest that this should be a critical
-clause 4.4.3: suggest restating guidance on criticality of
subjectAltName expressed in section 3.1 here.