Note, this is a repost of comments on the cert draft.
Some comments and questions:
S/MIME Certificate Handling
Status of this memo
2. PKCS #7 Options
The PKCS #7 message format allows for a wide variety of options in
content and algorithm support. This section puts forth a number of
support requirements and recommendations in order to achieve a base
level of interoperability among all S/MIME implementations.
Most of the PKCS #7 format for S/MIME messages is defined in
[SMIME-MSG].
General comment is to review structure and organization of the document in
light of the recent changes. I'm not clear how section 2 relates to rest of
doc and its purpose.
2.1 CertificateRevocationLists
Receiving agents MUST support for the Certificate Revocation List
(CRL) format defined in [KEYM]. If sending agents include CRLs in
outgoing messages, the CRL format defined in [KEYM] MUST be used.
All agents MUST validate CRLs and check certificates against CRLs, if
available, in accordance with [KEYM]. All agents SHOULD check the
nextUpdate field in the CRL against the current time. If the current
time is later than the revocation time, the action that the agent
should be "later than the nextUpdate time"
takes is a local decision. For instance, it could warn a human user,
it could retrieve a new CRL if able, and so on.
Receiving agents MUST recognize CRLs in received S/MIME messages. All
agents SHOULD have be able to retrieve CRLs directly from certificate
authorities using methods those authorities support.
I don't see how the second sentence on CRL retrieval is a testable
compliance requirement. Either we should delete it, mandate implementation
of at least n of m choices (email, LDAP, http), or pick 1. Also, remove the
"have" after SHOULD (this is a recurring problem in this edit).
Clients MUST handle multiple valid Certificate Authority (CA)
certificates containing the same subject name and the same public keys
but with overlapping validity intervals.
This paragraph should be a separate section (or part of later similar text).
2.3 ExtendedCertificateAndCertificates
Receiving agents MUST be able to handle an arbitrary number of
Do you want to make this handle at least nnn certificates?
certificates of arbitrary relationship to the message sender and to
each other in arbitrary order. In many cases, the certificates
included in a signed message may represent a chain of certification
from the sender to a particular root. There may be, however,
situations where the certificates in a signed message may be unrelated
and included for convenience.
Certificates MUST include an Internet mail address, as described in
section 3.1.
Sending agents SHOULD include any certificates for the user's public
key(s) and associated issuer certificates. This increases the
likelihood that the intended recipient can establish trust in the
originator's public key(s). This is especially important when sending
a message to recipients that may not have access to the sender's
public key through any other means or when sending a signed message to
a new recipient. The inclusion of certificates in outgoing messages
can be omitted if S/MIME objects are sent within a group of
correspondents that has established access to each other's
certificates by some other means such as a shared directory or manual
certificate distribution. Receiving S/MIME agents SHOULD be able
to handle messages without certificates using a database or directory
lookup scheme.
As with CRL retrieval, I don't think this last sentence is specific enough.
Certificate chains MUST be based on the Distinguished Name
of the certificates, not the subjectAltName field. [[Note: there
was some disagreement about this, and it is an open issue.]]
You can include me as one of the disagree-ers.
3. Distinguished Names in Certificates
3.1 Using Distinguished Names for Internet Mail
The format of an X.509 certificate includes fields for the subject
name and issuer name. The subject name identifies the owner of a
particular public key/private key pair while the issuer name is meant
to identify the entity that "certified" the subject (that is, who
signed the subject's certificate). The subject name and issuer name
are defined by X.509 as Distinguished Names.
Distinguished Names are defined by a CCITT standard X.501 [X.501]. A
Distinguished Name is broken into one or more Relative Distinguished
Names. Each Relative Distinguished Name is comprised of one or more
Attribute-Value Assertions. Each Attribute-Value Assertion consists of
a Attribute Identifier and its corresponding value information, such
as CountryName=US. Distinguished Names were intended to identify
entities in the X.500 directory tree [X.500]. Each Relative
Distinguished Name can be thought of as a node in the tree which is
described by some collection of Attribute-Value Assertions. The entire
Distinguished Name is some collection of nodes in the tree that
traverse a path from the root of the tree to some end node which
represents a particular entity.
The goal of the directory was to provide an infrastructure to uniquely
name every communications entity everywhere. However, adoption of a
global X.500 directory infrastructure has been slower than expected.
Consequently, there is no requirement for X.500 directory service
provision in the S/MIME environment, although such provision would
almost undoubtedly be of great value in facilitating key management
for S/MIME.
The use of Distinguished Names in accordance with the X.500 directory
is not very widespread. By contrast, Internet mail addresses, as
described in RFC 822 [RFC-822], are used almost exclusively in the
Internet environment to identify originators and recipients of
messages. However, Internet mail addresses bear no resemblance to
X.500 Distinguished Names (except, perhaps, that they are both
hierarchical in nature). Some method is needed to map Internet mail
addresses to entities that hold public keys. Some people have
suggested that the X.509 certificate format should be abandoned in
favor of other binding mechanisms. Instead, S/MIME keeps the X.509
certificate and Distinguished Name mechanisms while tailoring the
content of the naming information to suit the Internet mail
environment.
Why is the DN overview here?
Certificates MUST 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. [[Note: this only allows
"a(_at_)b(_dot_)com", not "First Last <a(_at_)b(_dot_)com>". Speak up if this
is not what
is intended.]]
Receiving agents MUST recognize email addresses in the subjectAltName
field. Receiving agents MUST recognize email addresses in the
Distinguished Name field.
Did you want to add compliance with recognizing email address as either RFC
xxxx or PKCS attributes? Are there any other restrictions on the DN
containing an email address?
Sending agents SHOULD have the address in the From 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 header of a
mail message matches an Internet mail address in the signer's
certificate. A receiving agent MUST provide some explicit alternate
processing of the message if this comparison fails, which may be to
reject the message.
3.2 Required Name Attributes
Receiving agents MUST support parsing of zero, one, or more instances
of each of the following set of name attributes within the
Distinguished Names in certificates.
Sending agents SHOULD include the Internet mail address during
Distinguished Name creation. Guidelines for the inclusion, omission,
and ordering of the remaining name attributes during the creation of a
distinguished name will most likely be dictated by the policies
associated with the certification service which will certify the
corresponding name and public key.
CountryName
StateOrProvinceName
Locality
CommonName
Title
Organization
OrganizationalUnit
StreetAddress
PostalCode
PhoneNumber
EmailAddress
What's the justification for the list? Also, does an agent need to do more
than equality comparisons with RDNs other than email addresses?
All attributes other than EmailAddress are described in X.520 [X.520].
EmailAddress is an IA5String that can have multiple attribute
values.
4. Certificate Processing
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. 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.
I'd remove the discussion of X.500 and DNS (probably the whole paragraph).
If anything, I think we're targetting LDAP, email, http as more likely
retrieval vehicles.
4.1 Certificate Revocation Lists
A receiving agent SHOULD have access to some certificate-revocation
list (CRL) retrieval mechanism in order to gain access to
certificate-revocation information when validating certificate chains.
A receiving or sending agent SHOULD also provide a mechanism to allow a
user to store incoming certificate-revocation information for
correspondents in such a way so as to guarantee its later retrieval.
However, it is always better to get the latest information from the CA
than to get information stored away from incoming messages.
Same comment as above on 2.1. Also, why not combine 2.1 and 4.1.
Receiving and sending agents SHOULD retrieve and utilize CRL information
every time a certificate is verified as part of a certificate chain
validation even if the certificate was already verified in the past.
However, in many instances (such as off-line verification) access to
the latest CRL information may be difficult or impossible. The use of
CRL information, therefore, should be dictated by the value of the
information that is protected. The value of the CRL information in a
particular context is beyond the scope of this draft but may be
governed by the policies associated with particular certificate
hierarchies.
I'd delete this - I think its covered elsewhere.
4.4 X.509 Version 3 Certificate Extensions
The X.509 v3 standard 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
purposes. This draft identifies the smallest set of certificate
"minimum required" rather than "smallest"
extensions which have the greatest value in the S/MIME environment.
The basicConstraints, keyUsage, and certificatePolicies extensions are
defined in [X.509].
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 CA certificates.
In the S/MIME environment, CAs which issue v3 certificates SHOULD
include only the extensions listed here.
For these extensions, the criticality flag SHOULD be set to False
unless the proper handling of the corresponding extension is deemed
critical to the correct interpretation of the associated certificate.
Also, in an S/MIME environment, when additional v3 extensions are
included in a certificate, the corresponding criticality flags SHOULD
be set to False.
Replace with:
Certificates issued for the S/MIME environment SHOULD not contain any
critical extensions other than those listed here. These extensions SHOULD
be marked as non-critical unless the proper handling of the extension is
deemed critical to the correct interpretation of the associated certificate.
When other extensions are included, those extensions MUST be marked as
non-critical.
And, on further review:
I think the general intent is to encourage limiting extensions to the ones
listed here and to strongly recommend that any other extensions be
non-critical. Having the extensions listed in this section be critical is
OK. Does replacing the last two sentences with "Other extensions MAY be
included by the issuer but SHOULD be marked non-critical." work?
4.4.1 Basic Constraints Certificate Extension
The basic constraints extension serves to delimit the role and
position of an issuing authority or end-user certificate plays in
a chain of certificates.
For example, certificates issued to CAs and subordinate CAs
contain a basic constraint extension that identifies them as
issuing authority certificates. End-user subscriber certificates
contain an extension that constrains the certificate from being
an issuing authority certificate.
Certificates SHOULD always contain a basicConstraints extension.
4.4.2 Key Usage Certificate Extension
The key usage extension serves to limit the technical purposes
for which a public key listed in a valid certificate may be used.
Issuing authority certificates may contain a key usage extension
that restricts the key to signing certificates, certificate
revocation lists and other data.
For example, a certification authority may create subordinate
issuer certificates which contain a keyUsage extension which specifies
that the corresponding public key can be used to sign end user
certs and sign CRLs.
Does this mean that as part of cert path validation, if the keyUsage field
is present for a CA, the certSign bit must be set?
5. Generating Keys and Certification Requests
5.1 Binding Names and Keys
There SHOULD NOT be multiple valid (that is, non-expired and
non-revoked) certificates for the same key pair bound to
different Distinguished Names. Otherwise, a security flaw exists
where an attacker can substitute one valid certificate for
another in such a way that can not be detected by a message
recipient. If a users wishes to change their name (or create an
alternate name), the user agent SHOULD generate a new key pair.
If the user wishes to reuse an existing key pair with a new or
alternate name, the user SHOULD first have any valid certificates
for the existing public key revoked.
What about adding a new email address to an existing list (without deleting
any of the present names)?
5.2 Using PKCS #10 for Certification Requests
Receiving agents MUST support the identification of an RSA key with the
rsa OID defined in X.509 and the rsaEncryption OID. Certification
Which OID?
authorities MUST also support the verification of signatures on
certificate requests made with sha-1WithRSAEncryption,
md5WithRSAEncryption, and MD2WithRSAEncryption signature algorithms
described in [SMIME-MSG].
Certification authorities MUST support parsing of zero or one instance
of each of the following set of certification-request attributes on
incoming messages. Inclusion of the following attributes during the
creation and submission of a certification-request will most likely be
dictated by the policies associated with the certification service
which will certify the corresponding name and public key.
I think the spec focuses on clients. Is the intent that client software
must support the inclusion of these attributes in a request?
postalAddress
challengePassword
unstructuredAddress
postalAddress is described in [X.520].
Do we want to say anything about PKCS-10 in PKCS-7?
5.2.1 Challenge Password
The challenge-password attribute type specifies a password by which an
entity may request certificate revocation. The interpretation of the
password is intended to be specified by the issuer of the certificate;
no particular interpretation is required. The challenge-password
attribute type is intended for PKCS #10 certification requests.
Is there a separate attribute used knowledge based authentication of the
requestor's identity?
6. Security Considerations
All of the security issues faced by any cryptographic application must
be faced by a S/MIME agent. Among these issues are protecting the user's
private key, preventing various attacks, and helping the user avoid
mistakes such as inadvertently encrypting a message for the wrong
recipient. The entire list of security considerations is beyond the
scope of this document, but some significant concerns are listed here.
When processing certificates, there are many situations
where the processing might fail. Because the processing may be done by
a user agent, a security gateway, or other program, there is no single
way to handle such failures. Just because the methods to handle the
failures has not been listed, however, the reader should not assume
that they are not important. The opposite is true: if a certificate is not
provably valid and associated with the message, the
processing software should take immediate and noticable steps to
inform the end user about it.
Some of the many places where signature and certificate checking might
fail include:
- no Internet mail addresses in a certificate match the sender of
a message
From: field
- no certificate chain leads to a trusted CA
- no ability to check the CRL for a certificate
- an invalid CRL was received
- the CRL being checked is expired
- the certificate is expired
- the certificate has been revoked
There are certainly other instances where a certificate may be
invalid, and it is the responsibility of the processing software to
check them all thoroughly, and to decide what to do if the check
fails.
Need to add discussion of root management. This should echo the warning
above on accepting new roots. Also, in general, do we want to say anything
about root certificate replacement?
Dave