All,
This message includes the minutes of the IETF S/MIME Working Group (WG)
meeting held on 30 March 1998 in Los Angeles, CA. These minutes have been
coordinated with the briefing presenters. All briefing slides are stored
at: ftp://ftp.ietf.org/ietf/smime/.
++++++++++++++++++++++++++++++++++++++++++++++++
Introductions - Russ Housley
Russ stated that the S/MIME version 2 documents are now available as
Informational RFCs. He reiterated that the IETF S/MIME WG charter is to
develop the S/MIME version 3 documents.
Russ reviewed the agenda. Nobody objected to the agenda.
++++++++++++++++++++++++++++++++++++++++++++++++
CMS Draft Discussion - Russ Housley
Russ presented several briefing slides regarding the CMS open issues. He
noted that Section 9, Authenticated-Data Content Type needs to be completed
including specifying the strategy for calculating a MAC or HMAC value. He
will coordinate the proposed text with the WG.
Russ proposed that the text regarding the contentHints attribute be moved
from the ESS I-D to the CMS I-D. Nobody objected.
Russ stated that Section 12, Supported Algorithms is incomplete, but that
the majority of the information will be straightforward to supply except for
the key management (KM) algorithm section. Russ stated that he has been
notified that one or more organization(s) have applied for patents that
cover some variants of the Diffie-Hellman (D-H) algorithm specified in the
X9.42 specification. The current CMS draft cites X9.42 as a reference for
the mandatory-to-implement D-H algorithm variant. It is still unclear if
the potential patents cover the X9.42 D-H variant intended for use with CMS.
Russ proposed to create an I-D specifying the proposed variant of the X9.42
D-H algorithm. He will then distribute that I-D with the request that all
organizations state if they have intellectual property that covers the I-D.
If any organizations make any such claims, then the I-D will be modified so
that it avoids the use of the intellectual property while still providing a
strong KM algorithm. Nobody objected to Russ' plan.
Russ stated that there is no standard method of encrypting a 3DES key with
another 3DES key. Russ proposed to develop an I-D that specifies a proposed
3DES wrapping algorithm. The I-D will then be widely distributed for
review. If required, the I-D will be revised to incorporate comments.
Nobody objected to Russ' plan.
++++++++++++++++++++++++++++++++++++++++++++++++
MSG Draft Discussion - Paul Hoffman
Paul led the discussion of the following open issues listed in the S/MIME v3
Message Specification I-D:
1) Should the MSG I-D list the documents needed to implement the algorithms
supporting S/MIME (X9.42, X9.57, etc). Paul recommended that the MSG I-D
should refer to the CMS I-D that includes references to the required
algorithm specifications. Nobody objected.
2) Regarding MSG I-D, Section 2.6.1, there is disagreement about the last
two steps in deciding which encryption algorithm to use when creating an
envelopedData. Paul recommended that the current sections 2.6.1.3 and
2.6.1.4 should be replaced with the following: "2.6.1.3 Rule 3: Unknown
Capabilities, Unknown Version of S/MIME: If the sending agent has no
knowledge of the encryption capabilities of the recipient and the sending
agent has no knowledge of the version of S/MIME of the recipient, then the
sending agent SHOULD use tripleDES because it is a stronger algorithm and is
required by S/MIME v3. If the sending agent chooses not to use tripleDES in
this step, it SHOULD use RC2/40." Nobody objected. Paul noted that if an
S/MIME v3 agent is sending an envelopedData to a legacy S/MIME v2 agent,
then RC2/40 SHOULD be used because the S/MIME v2 agent may not have
implemented tripleDES.
A WG member noted that the default encryption algorithm should result in
strong cryptography (i.e. use tripleDES whenever possible, rather than
RC2/40) and that if RC2/40 is used, then the user should be explicitly
notified of that fact.
3) Regarding Section 4.1, key lengths for non-RSA key pair generation
language are needed. A WG member asked if the WG was going to specify a D-H
"common group" of algorithm parameters. The WG agreed that this was a good
idea, but the use of the S/MIME WG-defined D-H "common group" would be
optional because some organizations may wish to use locally-defined D-H
"common groups". Paul recommended that the MSG I-D should refer to the CMS
I-D which covers this topic. Nobody objected.
4) smimeVersion capability: Paul proposed that the smimeVersion feature
should be added to the SMIMECapabilities list. This will have a content of
a single integer which will contain the version number of the highest S/MIME
specification understandable by the client. Nobody objected.
Jim Schaad addressed the following MSG I-D issues in later briefings:
"Add a section for selecting the encrypting X.509 certificate for a
particular recipient"
"SMIMEEncryptionKeyPreference - which key should a sender announce for this?
Also, unambiguous identification of X.509 certificates should be here, too."
++++++++++++++++++++++++++++++++++++++++++++++++
CERT Draft Discussion - Paul Hoffman
Paul noted that the S/MIME WG, as a general rule, should defer to the PKIX
WG regarding the rules for populating information in X.509 certificates and
CRLs. This will alleviate interoperability problems that could occur if
S/MIME levies special requirements regarding the contents of X.509
certificates that are above and beyond the generic PKIX requirements. Paul
led the discussion of the following open issues listed in the S/MIME v3
Certificate Handling I-D:
1) Names for chaining: Paul proposed that the S/MIME CERT I-D should refer
to the PKIX X.509 Certificate and CRL Profile I-D (PKIX I) for specifying
the rules for chaining. Nobody objected.
2) Use of keyUsage encipherOnly and decipherOnly bits in conjunction with
the use of KM X.509 certificates. John Pawling read the X.509 description
of the keyUsage encipherOnly and decipherOnly bits. He stated that he
believes that their use is not clearly defined when a public key is to be
used to form a pairwise key to encrypt or decrypt data. John proposed the
following: "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." This
issue will be further discussed on the S/MIME mail list.
3) Do we need to further qualify the syntax for rfc822Name (no wildcards or
comments)? Paul proposed that the S/MIME CERT I-D should refer to PKIX I
regarding this issue. Nobody objected.
4) Attribute Certificates: Paul noted that it is an action item for the
PKIX WG to define the use of ACs. David Solo proposed that all references
to ACs should be deleted from all of the S/MIME specifications until the
syntax and use of ACs are well defined. Russ and John Pawling made the
point that X.509 defines the AC syntax. However, Paul and Dave strongly
believed that ACs should be deleted from the S/MIME specs since their use is
not defined and the PKIX AC syntax may be changed. Nobody objected to this
proposal. The details of this change will be discussed further on the
S/MIME list.
A WG member stated that he is concerned about the S/MIME specs relying on
the PKIX specs which are still I-Ds. Jeff Schiller stated that the S/MIME
WG needs to clearly state their dependencies on the PKIX WG to put pressure
on them to finalize the PKIX I spec. Similarly, other IETF WGs are
dependent on the S/MIME WG finalizing the S/MIME v3 specs. Paul volunteered
to compile a list of S/MIME dependencies on the PKIX I spec.
++++++++++++++++++++++++++++++++++++++++++++++++
Authenticated Originator Certificate - John Pawling
John recommended adoption of Jim Schaad's original proposal to add a
signing-certificate authenticatedAttribute to the CMS I-D as follows:
"11.5 Signing Certificate Attribute. The signing-certificate attribute
type specifies the exact certificate used to sign the signed-data. This
provides for an authenticated method of linking the certificate used to
create the signed-data object and the signed-data object itself. If this
attribute is not used and two different certificates are used for the same
keys, it is possible to substitute the certificates without breaking the
signature. It is suggested that the signing-certificate attribute be present
if there are any authenticated attributes present. The signing-certificate
attribute MAY be critical. The signing-certificate attribute MUST be
authenticated. Only one instance of the signing-certificate attribute may
appear in an attribute set. The following object identifier identifies the
signing-certificate attribute: id-signingCert OBJECT IDENTIFIER ::= <TBD>.
Signing-certificate attribute value has the ASN.1 type IssuerAndSerialNumber."
John presented slides explaining the process by which the originator
composes a signedData object that includes a signing-certificate attribute
and the process by which the recipient validates the signer's certification
path and the signature of the signedData. The point of the briefing was
that the combination of the IssuerAndSerialNumber info, certification path
validation and verification of the signer's signature of the signedData
object provides sufficient information to reliably identify the signer's
X.509 certificate. John recommended that the IssuerAndSerialNumber syntax
is appropriate for use for the signing-certificate attribute. He
recommended that the subjectAltName and a hash of the X.509 certificate
should not be included in the signing-certificate syntax.
Denis Pinkas presented a briefing in which he proposed that issuerAltName
and certificateHash should be added as optional fields to the
signing-certificate syntax. Denis' briefing slides provide more details.
Dave Solo stated that he did not believe that the signing-certificate
attribute is needed to unambiguously identify the signer's identity. He
believes that the content of the signedData should include enough semantic
information to unambiguously identify the signer (if that is desired) rather
than relying solely on the information in the signer's X.509 certificate.
Russ asked for a show of hands regarding who believed that the
IssuerAndSerialNumber syntax should be sufficient to unambiguously identify
the signer. He also asked who believed that the signing-certificate
attribute should include information (such as the subjectAltName and
certificate hash value) in addition to IssuerAndSerialNumber. Twice as many
hands were raised for the second option as for the first.
In a later discussion, this issue was raised again and Russ explained the
issue. Russ asked who believed that the signing-certificate attribute
should be added to the S/MIME specs. The vote was 6 to 7 in a room filled
with several hundred people. It was apparent from this vote and from the
discussion of the WG members that there was not a consensus regarding the
purpose and syntax of the signing-certificate attribute, so the result of
the earlier straw poll was overturned. This issue will be further discussed
on the S/MIME mail list.
++++++++++++++++++++++++++++++++++++++++++++++++++
ESS Draft Discussion - Paul Hoffman
Paul led the discussion of the following open issues related to the ESS I-D:
1) Paul proposed that the text regarding the contentHints attribute be moved
from the ESS I-D to the CMS I-D. Nobody objected.
2) Paul explained the proposal for the signature-purpose attribute and that
it should be included in a separate document. Nobody objected.
3) Paul proposed that the group accept his recommended text for new wording
regarding what to do if a signedData has multiple signerInfos, some of which
don't have mlExpansionHistory attributes. Paul's e-mail message (Subject:
RE: ESS-04 Comments, 24 Mar 98) to the list describes this proposal. Paul
explained that his proposal allows gateways to add a signerInfo without an
mlExpansionHistory attribute. Nobody objected.
4) John Pawling proposed that the ESSSecurityLabel
security-policy-identifier should be changed from optional to mandatory.
Nobody objected to John's proposal.
++++++++++++++++++++++++++++++++++++++++++++++++
E-Mail Address in Certificates - J.L. Cote
J.L. stated that the Canadian government wants e-mail addresses to be
optional for inclusion in X.509 certificates. This was addressed in the
last version of the CERT I-D. J.L. also stated that X.400 addresses should
be documented in addition to RFC822 addresses. Nobody objected.
++++++++++++++++++++++++++++++++++++++++++++++++++
Signature and Key Management Certificates - Jim Schaad
Jim explained why separate signature and KM keys are required for a single
end entity. He explained the problems associated with separate keys as
keeping track of the different keys, making associations between the
different keys, publishing the different keys and making it known which of a
user's keys should be used for KM. He explained that there various methods
of associating the different keys including subject name matching, alternate
subject name matching and others. The MSG I-D, Section 2.5.3 documents the
SMIMEEncryptionKeyPreference authenticatedAttribute. Jim proposed that the
following process be documented in the MSG I-D:
- If an SMIMEEncryptionKeyPreference attribute is found in a signedData
object, this identifies the X.509 certificate that should be associated as
the KM X.509 certificate for the user.
- If an SMIMEEncryptionKeyPreference attribute is not found in a signedData
object, the set of X.509 certificates should be searched for a X.509
certificate with the same subject name as the signing X.509 certificate
which can be used for KM.
- Or use some other method of determining the user's KM key. If no KM X.509
certificate is found, then encryption cannot be done with the signer of the
message. If multiple X.509 certificates are found, the S/MIME agent can
make an arbitrary choice between them.
Jeff Schiller asked why the SMIMEEncryptionKeyPreference attributes is
needed. Jim answered that it is required to facilitate the bootstrapping of
an encryption exchange. A signer sends a signedData that includes the
signer's KM X.509 certificate which the recipient can then use to send an
envelopedData back to the signer.
A WG member asked if the user's KM X.509 certificate will be included in the
signedData object. Jim answered that it should be included, but may be
omitted if the sender knows that the recipient already has it.
Nobody objected to Jim's proposal.
++++++++++++++++++++++++++++++++++++++++++++++++++
Certificate Distribution - Jim Schaad
Jim outlined the current strategies for publishing X.509 certificates: LDAP
userCertificate; X.500 Directory entry; S/MIME signedData message; CMS
certificate-only attachment; and other methods such as vCard. Jim said that
the problems with these strategies is that they: do not carry a full
certification path; can only carry a single KM X.509 certificate; and does
not carry any S/MIME capabilities. Jim proposed that a new inner content
type should be defined as id-ct-publish. This would indicate that the
signedData: does not include a content; does include authenticatedAttributes
(could include SMIMEEncryptionKeyPreference attribute); and may include
multiple KM X.509 certificates. Jim proposed that the new content type
could be signed by either an end-entity or X.509 certificate issuer. He
also proposed the addition of a new LDAP userSMIMECertificate (binary)
schema property.
John Pawling asked how the message digest value would be calculated if the
content was absent. Jim answered that the digest would be calculated over
the initialization value for the hash algorithm that is being used.
The WG decided that they should pursue Jim's proposals within the S/MIME WG.
The WG also decided that Jim's proposal should be documented in a separate I-D.
++++++++++++++++++++++++++++++++++++++++++++++++++++
Other Discussion:
1) Paul Hoffman asked that people use meaningful names in their e-mail
message subject lines when making new proposals or creating a new thread on
the S/MIME mail list.
2) Russ stated that he believes that the ESS, CERT and MSG I-Ds will be
ready for Working Group last call in April 98. He also stated that his goal
is for the CMS I-D to be ready for Working Group last call in April 1998;
however, the D-H patent issue and 3DES wrapping issue may delay the
schedule. Since ESS, CERT, and MSG depend on CMS, they cannot go to IESG
last call until CMS is ready to go to IESG last call as well.
3) Darren Harter stated that there is a problem if a BER-encoded
authenticatedAttribute is received by an S/MIME agent that does not
recognize the OID for the attribute. In this case, the receiving agent
can't decode the attribute and re-encode it using DER because the agent does
not know the syntax of the attribute. This may result in a signature
verification error. Darren proposed the following options for solving this
problem: mandate DER encoding of the complete signedData object; or change
syntax of authenticatedAttribute to use OCTET STRING (similar to v3 X.509
certificate Extension format). Russ stated that his initial position is to
mandate DER-encoding of the authenticatedAttributes. This solves the problem
stated by Darren, because the receiving agent can simply hash over the
transmitted DER-encoded authenticatedAttributes without decoding and
re-encoding them. This issue will be resolved through messages on the S/MIME
mail list.
================================
John Pawling
jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
================================