Greetings. After the S/MIME developers' meeting a few weeks ago, a group of
people concerned about the certs draft got together at Netscape, with a few
others chiming in over a telecon. At the bottom of this message is an
edited version of the minutes, ably taken by David Solo of BBN.
The result of the meeting, and some post-meeting discussion, is a revised
certs draft, which has now been submitted as a new Internet Draft. It is
available from <http://www.imc.org/ietf-smime/draft-dusse-smime-cert> now,
and should appear in the Internet Drafts directory within a few days. The
revision list is attached immediately below.
All S/MIME developers who handle certificates should read this draft
carefully, since it has many changes from earlier versions.
--Paul Hoffman, Director
--Internet Mail Consortium
==============================
The following changes were made between the -02 and -03 revisions of
this draft:
Made small changes to wording about "standards" because this is now
going to be an informational RFC, not a standard. Also added text
to 1.3 to make it clear how we are using the MUSTSHOULD RFC.
Updated the references to ASN.1, BER, and DER in 1.1.
Changed "handle and display" to "handle" in 3.2, 4.4, and 5.2 because
there is on UI defined so we can't say how to "display".
2.1 Changed the reference to PKIX part 1 and changed the sending
from SHOULD to MUST. Added more specifics about how to handle
CRLs.
2.2 Clarified what the format of the certificate is.
2.3 Added requirements for CA chains in last paragraph.
Note that the last paragraph that was added has some
controversy.
3.1 Replaced the last two paragraphs. Added allowance for email addresses
in subjectAltName field.
Also defined the format of the email addresses. Note that there
is a question on the format in this section.
4. Added a sentence about the PKIX mechanisms for getting certificates.
4.4 Removed Certificate Policy Certificate Extension and added
authorityKeyID, subjectKeyID, and the subjectAltNames.
5.1 Replaced the third and fourth paragraphs with four new ones.
5.2 Removed unstructuredName from the list, and removed 5.2.3 which
defined it, since these were only for PKCS #6.
6. Removed the unrelated material and added new stuff.
A. Removed the cert policies OID stuff and unstructuredName.
Removed old Appendix E (the S/MIME trademark) at the request of RSA.
RSA does not claim trademark rights to the name "S/MIME".
Changed Lisa Repka's name to Jeff Weinstein for this draft. Also
removed Laurence Lundblade, who primarily worked on the message
format draft.
***** Remaining open issues *****
In 2.3:
Certificate chains MUST be based on the Distinguished Name
of the certificates, not the subjectAltName field.
-----Do people agree with this?
In 3.1:
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>".
-----Do people agree on this?
==============================
Minutes of 9/12 S/MIME-cert meeting
Taken by David Solo <solo(_at_)bbn(_dot_)com>
In attendance:
David Solo, BBN <solo(_at_)bbn(_dot_)com>
Mike Myers, VeriSign <mmyers(_at_)verisign(_dot_)com>
Jeff Weinstein, Netscape <jsw(_at_)netscape(_dot_)com>
Anil Gangolli, Structured Arts <gangolli(_at_)structuredarts(_dot_)com
Peter Yee, SPYRUS <yee(_at_)spyrus(_dot_)com>
Buce Kelly, Microsoft <brucek(_at_)microsoft(_dot_)com>
George Hatoun, Microsoft <georgeh(_at_)microsoft(_dot_)com>
Blake Ramsdell, Worldtalk <blaker(_at_)deming(_dot_)com>
Paul Hoffman, IMC <phoffman(_at_)imc(_dot_)org>
1) Email addresses - the general conclusion is that in the interim, email
addresses may appear in either the subject DN (as a PKCS or RFC attribute)
or as a subject altName. There is a preference to move to altNames. It was
also viewed as important that clients perform checks between originator
information (as reflected in the From field) and the list of email addresses
in the cert; although the action to be taken on a failure is a local matter
(mapping, popups, rejection, etc.) - see below on security considerations.
There was also discussion on support for wildcarding of email addresses,
especially as needed to support intermediate system encryption/decryption.
This topic was deferred (Blake and Jeff will work on a separate draft).
Specific requirements in this area are:
Certificates MUST contain an email address
Clients MUST recognize email addresses in the subjectAltName field.
Clients MUST recognize email addresses in the DN field.
Sender SHOULD have the From field match an email address in the signer cert.
Recipient MUST check that the From field matches an email address in the
signer cert.
Recipient MAY reject messages that fail this test.
2) Cert policy - the decision was to delete the section on cert policy
(4.4.3) since there was no concrete processing associated with this. Mike
has an action to propose alternative text, if desired.
3) Key IDs - discussion of how clients should handle CAs with multiple valid
certs and a conclusion that the authorityKeyID and subjectKeyID are the best
way (trial and error also "works"). Dave and Anil to write new text for
section 5.1. Requirements are:
Clients MUST handle multiple valid CA certificates with different keys.
Clients SHOULD process the AuthorityKeyID and SubjectKeyID fields for this
purpose.
4) Revocation - general discussion that a mandatory revocation mechanism was
required, that online status checks weren't there yet, and the CRLs
represented the best current bet. Requirements are:
Clients MUST process (i.e. validate CRL and check certificates against the
list) v2 CRLs, if available, in accordance with PKIX part 1.
Clients MUST check the nextUpdate field in the CRL against the current time.
(action on failure is a local matter - could flag, retrieve new CRL if able,
etc.)
Clients MUST recognize CRLs in received S/MIME messages.
Clients MAY use PKIX part 2 protocols for accessing certificate information.
5) Time - there was a general discussion of how to handle time when
validating S/MIME messages (role of signing time, received time, etc.),
especially as regards certificate expiration or revocation. The conclusion
was to treat this as a local matter (reaction to detection of a cert
validation failure - see security considerations). A separate draft on
dealing with "old" signatures may also be generated.
6) Cert chains - general discussion of how a client decides which
certificates to include a message it sends. Issues include which
"personality" to assume, which target CA to form a path to (which root or
which peer), whether to send certs at all, whether to send a "root", how to
handle cross-certification, etc. The decision was to defer most of the
cross-cert, personality, multi-CA/path issues and default to always sending
a cert path up to, but not including, the root cert. Requirements are:
Clients SHOULD include at least one chain up to, but not including, a
"root". (need to define "root")
Clients MAY send "root" certificates.
7) Security considerations - this should be expanded to discuss further the
types of exceptions that may be encountered during cert and signature
processing (message sig failure, cert sig failure, no CA, no CRL, old CRL,
expired cert, revoked cert, etc.). For these exceptions, handling is a
local matter, however we may want to develop some guidance on communicating
information to user, automatic processing, and severity. There also needs
to be a discussion about the handling of root certificates, emphasizing the
severe security risks associated with letting users add roots to their local
store (if encountered in email messages, etc.)
8) PKIX profile - we decided that creating a PKIX usage profile (S/MIME use
of PKIX, part 1) is needed. This would also serve as a draft template for
other applications using PKIX and will cover extensions, cert path
validation, CRLs, etc. Dave has the action to create a first draft.
9) Capability fetch - observation that whatever mechanism supports cert
fetching should also allow retrieval of S/MIME Capability fields. This is
probably a comment on PKIX 2.
10) Misc corrections to ASN references and need to review list of OIDs (ITU,
PKCS, ....)
11) PKCS-10 profile - the section on cert requests needs to be refined to
create a cert request profile covering extensions, other attributes/algs,
etc. for complete profiling of PKCS-10. Mike and Dave to work on this.
12) editorial - several sections need rewrites to reflect above. (note, this
is my input, not direct minutes from the meeting)
- delete second par. of 2.2 (doesn't make sense, you can only send certs you
got from a CA). Add reference to PKIX, part 1 including cert path validation.
- rewrite 2.1 to match CRL conclusions
- rewrite 2.3 to match discussion on sending certs. Also should specify a
max number of "arbitrary" certs to be handled.
- rewrite section 3 to match discussion on naming and use of email addresses.
- rewrite section 4, 4.1, 4.2 to reflect PKIX references and above discussion
- edit section 4.4.n to reflect above extension changes.
- rewrite 5.1 to cover finding/choosing CA certs. remove CA requirements
- replace 5.2.n with reference to PKCS-10 profile
- expand section 6 to cover exception handling and root key management