All,
The following individuals met on 14 Jan 98 in San Francisco to discuss
S/MIME-related issues: Russ Housley, Spyrus; Paul Hoffman, IMC; Blake
Ramsdell, WorldTalk; Jim Schaad, Microsoft; Jon Callas, PGP; Dave Solo,
Citicorp; Pat Cain, GTE: Bob Dickinson, WorldTalk; Ron ?, WorldTalk; Clark
Wagner, DoD; John Pawling, VDA. As requested by Paul Hoffman, this message
includes notes from the meeting including proposals for changes to the
S/MIME v3 set of I-Ds. All are welcome to provide comments, if any.
++++++++++++++++++++++++++++++++++++++++++++++++++++++
1) PGP Commonality:
The IETF S/MIME WG Charter states: "The S/MIME Working Group will attempt to
coordinate its efforts with the OpenPGP Working Group in areas where the
work of the two groups overlap, particularly in specification of
cryptographic algorithms and MIME
structure." The group agreed that the S/MIME v3 and Open PGP I-Ds would
continue to differ in their use of certificates and security heading
formats. A goal is for the CMS and OpenPGP I-Ds to require a common set of
cryptographic algorithms. The following table documents the CMS mandatory
algorithm requirements and closest equivalent in the PGP environment:
| CMS PGP
====================|=====================================
Digest | SHA-1 SHA-1
Signature | DSS DSS
Content Encryption | 3DES (CBC) 3DES (Eccentric CFB)
Key Management (KM) | D-H (X9.42) D-H (ElGamal variant)
Note that the SHA-1 and DSS (a.k.a. DSA) algorithms are common between the
two environments, but the D-H and 3DES variants are not interoperable.
Note: CBC = Cipher Block Chaining mode and CFB = Cipher Feedback mode.
The MIME structure was discussed. Blake stated that it would be most
excellent if the MIME heading could include separate PGP and CMS signatures
in addition to the data that was signed. Another attendee stated that the
1847 spec should be enhanced to include a multipart format so that the PGP
and CMS signatures can be included in separate parts of the MIME heading.
Blake noted that the existing 1847 spec would work because the PGP and CMS
signatures can be included in a single multipart portion of a MIME header.
Proposal #1: Paul Hoffman proposes to create a separate mail list on which
S/MIME-PGP convergence issues will be discussed. He will announce the new
mail list on both the IETF OpenPGP and S/MIME WG mail lists.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++
2) SignedData Digesting Rules:
The Dec 97 CMS I-D, Section 5.3 includes rules for digesting the content of
a SignedData object as part of the signature generation and verification
processes. The rules are different for the Data content type (digest the
Data OCTET STRING value field which can be any random data) than for other
content types (digest the DER encoding of the content). After a long
debate, the group decided to make the following proposal:
Proposal #2: Change the CMS SignedData contentInfo field to be
signedContentInfo defined as follows:
SignedContentInfo ::= SEQUENCE {
sigContentType ContentType,
sigContent [0] EXPLICIT OCTET STRING OPTIONAL}
It is proposed that the CMS Section 5.3 will be changed so that the
digesting rules are consistent for all types of data that is signed (i.e.
the rules for digesting the Data content type will be extended to all types
of data).
Note that this change is backwards compatible with PKCS #7 v1.5. The
sigContent OCTET STRING is equivalent to the PKCS #7 v1.5 Data content OCTET
STRING. Also note that no changes are proposed to the ContentInfo SEQUENCE
encapsulating the outer CMS object.
++++++++++++++++++++++++++++++++++++++++++++++++++++
3) Two Key Systems
There was a discussion regarding some perceived problems with two key
systems (i.e. separate keys used for signing and for KM).
Proposal #3: One issue discussed was the process by which an agent
determines which of a remote user's certificates should be used for KM
purposes to support the encryption of a CMS EnvelopedData object. It is
proposed that a new authenticated attribute will be defined in CMS that will
identify which of a user's X.509 certificates (usually communicated in the
SignedData certificates field) is to be used for key management purposes.
For example, User 1 sends a SignedData object including his KM and DS
Certificates in the SignedData certificates field and the authenticated
attribute indicating which of the certs is his KM cert. The remote user
would then know which cert to use for KM purposes when sending an
envelopedData object to User 1. (Note that the EnvelopedData recipientInfo
originatorCert field is used to indicate which of the originator's certs (if
required by the KM algorithm (such as D-H)) is to be used for KM purposes to
support the decryption of an envelopedData object.)
Proposal #4: The following rule is also proposed for addition to CMS: "If
the new authenticated attribute is absent, then the signature and KM
certificates must include the same subject DN." If the new attribute is
absent, then the sending agent would examine the OID in the
subjectPublicKeyInfo field of each cert to determine if the OID indicates
the purpose (ex: id-dsa indicates that a DSS key is included in the cert).
The agent should also examine the keyUsage extension to determine the
intended usage of the public key included in the cert.
Proposal #5: The following rule is also proposed for addition to the S/MIME
v3 Certificate Handling I-D: "If a keyUsage extension is included in a v3
X.509 Certificate, then it MUST be marked as critical." This will ensure
that the S/MIME application uses the public key included in the X.509
Certificate as it was intended by the certificate issuer.
+++++++++++++++++++++++++++++++++++++++++++++++++++
4) DNs in Certs
There was much debate regarding the inclusion of subject and issuer names
(i.e. DNs) in X.509 Certificates. The PKIX X.509 Certificate and CRL
Profile states that issuer and subject DNs may be NULL.
Proposal #6: It is proposed that the S/MIME v3 Certificate Handling I-D will
be enhanced to include the following statement: "All subject and issuer
names must be non-NULL in S/MIME-compliant v3 X.509 Certificates, except
that the subject DN in a user's (i.e. end-entity) certificate may be NULL in
which case the subjectAltName extension will include the subject's
identifier and will be marked as critical."
This new rule allows the CMS IssuerAndSerialNumber syntax to be continued to
be used to identify X.509 Certificates.
+++++++++++++++++++++++++++++++++++++++++++++++++++
5) E-Mail Addresses in Certs
There was much debate regarding the inclusion of E-Mail addresses in X.509
Certificates. The current S/MIME v3 Certificate Handling I-D states that
all end-entity certs MUST contain an RFC-822 address.
The general consensus was that the e-mail address, if present, should be
included in the subjectAltName extension rather than in a component of the
subject DN. The vast majority of the group agreed that the inclusion of
RFC-822 addresses in X.509 Certificates should not be a mandatory
requirement in the S/MIME v3 Cert Handling I-D. Further message traffic
will include specific proposals regarding this issue.
++++++++++++++++++++++++++++++++++++++++++++++++++++
6) Certificate Request Message Format (CRMF)
Background: See "12/10/97 IETF S/MIME WG Minutes" Certificate Request
Syntax (CRS) discussion.
The PKIX CRS (based on PKCS-10) and PKIX Certificate Management Protocol
authors and other interested parties have developed a compromise solution
that will soon be documented in the PKIX Certificate Request Message Format
(CRMF) I-D. The CMP and CRS I-Ds will be changed to replace their redundant
certificate request protocols with pointers to the CRMF I-D. The CRS I-D
will define the use of CMS for protecting CRMF messages (and other related
certificate management messages to be determined). The S/MIME v3
Certificate Handling I-D will define how the CRS objects are communicated
using MIME. The CRMF will only include the harmonized certificate request
format. A separate I-D will include other harmonized certificate management
message formats such as the certificate response message format. Note that
the 10 Dec 97 IETF S/MIME WG agreed with this course of action. The only
new information is the name of the "harmonized" format (i.e. CRMF) and that
significant work has been accomplished toward the development of the CRMF I-D.
================================
John Pawling
jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
================================