This message includes the minutes of the IETF S/MIME Working Group
meeting held on 31 July 2000 in Pittsburgh, Pennsylvania, U.S.A.
Briefing slides are stored at: ftp://ftp.ietf.org/ietf/smime/.
These minutes include comments from the briefing presenters.
Reported by John Pawling.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Introductions - Russ Housley
Russ reviewed the agenda as follows. Nobody commented on the agenda.
Introductions Russ Housley
Working Group Status Russ Housley
Interoperability Matrix Jim Schaad
CERTDIST Draft Discussion Jim Schaad
Symmetric Key Distribution Sean Turner
Security Policies and Labels Weston Nicolls
Message Compression Ned Freed
DOMSEC Draft Discussion Bill Ottaway
CMS/ESS Examples Paul Hoffman
Crypto Algorithm Documents Russ Housley
RSA as a MUST Implement Blake Ramsdell
Electronic Signature Formats John Ross
Signature Policy Format Denis Pinkas
Wrap up Russ Housley
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
S/MIME Working Group Status - Russ Housley
Russ outlined the strategy for advancing the following RFCs from
Internet Proposed Standards to Internet Draft Standards:
RFC 2630 Cryptographic Message Syntax, R. Housley, June 1999
RFC 2631 Diffie-Hellman Key Agreement Method, E. Rescorla, June 1999
RFC 2632 S/MIME Version 3 Certificate Handling, B. Ramsdell, June 1999
RFC 2633 S/MIME Version 3 Message Specification, B. Ramsdell, June 1999
RFC 2634 Enhanced Security Services for S/MIME, P. Hoffman, June 1999
RFC 2785 Methods for Avoiding the "Small-Subgroup" Attacks on the
Diffie-Hellman Key Agreement Method for S/MIME,
R. Zuccherato, March 2000. [Informational]
RFC 2876 Use of the KEA and SKIPJACK Algorithms in CMS, J. Pawling,
July 2000. [Informational]
The aforementioned documents must meet the following requirements to
advance to Draft Standards:
1) Meet requirements documented in RFC 2026
2) Stable, mature, and useful specification
3) At least two independent and interoperable implementations
from different code bases
4) Draft Standards cannot reference Proposed Standard RFCs or
Experimental RFCs, so the aforementioned RFCs are blocked
until the PKIX Certificate and CRL Profile "Son-of-RFC 2459"
Internet-Draft (I-D) (draft-ietf-pkix-new-part1-02.txt)
progresses to Draft Standard (last call was estimated to begin by
7 August 2000).
Russ stated that Jim Schaad has developed an interoperability matrix
for RFCs 2630 through 2634. The interoperability matrix is posted at
<http://www.imc.org/ietf-smime/interop-matrix.html>. The matrix
indicates which features have and have not been implemented. So far,
Microsoft and Wang Government Services (WGS), A Getronics Company,
have provided input to the interoperability matrix. WGS has provided
input regarding the capabilities of the S/MIME Freeware Library (SFL)
including interoperability testing conducted with Microsoft.
Russ noted that Paul Hoffman (IMC) has offered to coordinate
interoperability testing and to enhance the "Examples of S/MIME
Messages" I-D. He also noted that no other organizations have
participated in the interoperability testing. He asked that other
organizations that have developed S/MIME v3 capabilities should
please participate.
There are some S/MIME v3 features for which interoperability testing
has not been performed between at least two independent
implementations. For example, Russ pointed out that the
EncryptedData, AuthenticatedData and DigestedData content types
have not been tested between two parties.
Russ proposed that RFC 2630 should be changed to state that:
- EnvelopedData and SignedData MUST be implemented; and
- EncryptedData, DigestedData, and AuthenticatedData MAY be
implemented.
Russ said that he would submit that proposal to the IETF S/MIME
working group (WG) mail list.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Interoperability Matrix - Jim Schaad
Jim discussed the interoperability matrix for RFCs 2630 through 2634.
He has documented the successful completion of two-way interoperability
testing for the following number of clauses in each RFC. He noted that
he has not completely updated the results based on all interoperability
testing performed:
RFC Clauses Tested
2630 45 of 96
2631 0 of 13
2632 16 of 21
2633 17 of 61
2634 0 of 81
Jim asked for others to submit input to him at
jimsch(_at_)exmsft(_dot_)com(_dot_)
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
CERTDIST Draft Discussion - Jim Schaad
Jim discussed the Certificate Distribution Specification I-D
<draft-ietf-smime-certdist-05.txt>, May 2000. Based on discussions
on the S/MIME WG mail list, Jim stated that there are three camps
of thought regarding publishing certificates with secondary support
information such as the SMIMECapabilities attribute:
1) Use attribute certificates (AC)
2) Put user's certificates in the signed object (see certdist-05)
3) Omit user's certificates from the signed object
Jim stated that the advantage of the AC strategy is that it matches
the X.500 schema. The disadvantage is that ACs are "new" and are
not necessarily a good use of ACs.
Jim stated that the advantage of the strategy to include user
certificates in the signed object is that there is a single location
from which to retrieve all of the required information. The
disadvantages of this strategy are that duplicate information is
stored in the directory and there are potential consistency problems.
Jim stated that the advantages of the strategy to omit user
certificates in the signed object are less data stored in the
directory and a single set of user certificates are used for all
purposes. The disadvantages of this strategy are that there are
potential consistency problems and multiple elements to be retrieved
from the directory.
Jim conducted a straw poll of the meeting attendees to obtain their
opinion regarding the following options:
1) Continue to try and get consensus
2) Adopt on standards track w/o consensus
3) Adopt on experimental track w/o consensus
The majority of the meeting attendees who voted chose option 1.
Blake Ramsdell asked if these issues should be discussed on the IETF
PKIX WG mail list in addition to the S/MIME WG mail list. Russ
stated his belief that the interested parties are subscribed to the
S/MIME mail list so it is not necessary to discuss the issues on the
PKIX mail list.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Symmetric Key Distribution - Jim Schaad for Sean Turner
Jim discussed the S/MIME Symmetric Key Distribution I-D,
<draft-ietf-smime-symkeydist-01.txt>, July 2000. Jim provided
significant comments to the symkeydist-00 I-D that Sean incorporated
into the symkeydist-01 I-D.
Jim stated that major architecture changes were made to the symmetric
key distribution strategy. The Key Management Agent (KMA) and Group
Management Agent (GMA) were combined into one component called the
Group Lists Agent (GLA). This change removes duplicative KMA checks.
The change was made based on the assumption that the KMA and GMA
will likely be implemented in the same box.
Jim briefed that major protocol changes were made to the symmetric
key distribution strategy. Instead of defining a new content type,
symkeydist-01 specifies that the exchange of data will use a protocol
based on RFC 2797, Certificate Management Messages over CMS (CMC).
There were many other changes made to the document as a result of
changing the architecture and protocols.
Jim briefed the following implementation requirements for the
control attributes:
Implementation
Requirement Control Attribute
==================================
MAY glUseKEK
MAY glDelete
MAY glAddMembers
MAY glDeleteMembers
MAY glRekey
MAY glAddOwners
MAY glRemoveOwners
MAY glkCompromise
SHOULD glkRefresh
MAY glSuccessInfo
MAY glFailInfo
MAY glAQueryRequest
MAY glAQueryResponse
MUST glKey
Jim noted that the protocol exchanges between the user and GLA will
be changed to "MUST implement" requirements. He also noted that
the protocol exchanges between the KMA and GLA will remain as
"MUST implement" requirements.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Mapping Company Classification Policy to the S/MIME Security Label -
Weston Nicolls
The "Implementing Company Classification Policy with the S/MIME
Security Label" I-D, <draft-ietf-smime-seclabel-01.txt>, July 2000,
was authored by Weston Nicolls. Weston planned to provide a briefing
at the meeting, but could not be present due to airline delays.
There was no information presented regarding this topic.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Message Compression - Ned Freed
Ned Freed is proposing a MIME encoding to handle compression. His
proposal is to compress the message using this MIME encoding before
it is signed or encrypted. Ned Freed could not be present at this
meeting, so there was no information presented regarding this topic.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
DOMSEC Draft Discussion - Bill Ottaway
Bill presented a briefing regarding the "Domain Security Services Using
S/MIME" I-D <draft-ietf-smime-domsec-06.txt>, July 2000. Bill stated
that there have been two releases of the DOMSEC I-D since the last
S/MIME WG meeting. DOMSEC-05 included clarifications based on input
from Luis Barriga and included the object identifier for the
signatureType attribute. DOMSEC-06 included corrections and
clarifications based on input from Jim Schaad, and included an ASN.1
module added.
Bill then discussed some issues with some technical proposals from
Jim Schaad. In an e-mail message, Jim Schaad stated: "Section 3.0
bullet 1: This concept bothers me. I think that there may be some
programs out there that assume at least one signature in a signed
data object except for cases such as degenerate certs only messages."
Blake Ramsdell reiterated that some applications interpret
a signedData with no signerInfos as being a certs-only message.
Bill's position is that CMS (section 5.1) states that there may be
zero signerInfos, so compliant implementations should be able to
process a signedData with zero signerInfos. He asked if any of the
other meeting attendees believed that DOMSEC should be changed to
omit the use of signedData objects without any signerInfos. None
of the meeting attendees responded.
In an e-mail message, Jim Schaad also stated: "Section 4 Paragraph
Last-2 - How can I possibly enforce this? For Key Transport the
sender is anonymous, for Key Agreement the senders certificate is
often not examined. Additionally the domain component could change
so that does match -- or it might be my domain component that did
the re-enecryption and would therefore match my domain name and not
the senders domain name." Bill's position is: "The only extra
specification to those specified in CMS is that the naming
convention and name mapping convention defined in DOMSEC is used.
This is specified to locate public keys. For example, if a domain
needs to locate the public key for the domain of the recipient
w(_dot_)ottaway(_at_)eris(_dot_)dera(_dot_)gov(_dot_)uk then the public key
belonging to
domain-confidentiality-authority(_at_)eris(_dot_)dera(_dot_)gov(_dot_)uk needs
to be
located, or if not present the public key of an ascendant of the
domain name needs to be located." Bill also stated that the
DOMSEC messages are encrypted between the originator's domain
and the recipient's domain, not the actual recipient user.
He stated that the text is intended to explain how an
originator domain agent can look up a recipient's name.
He will clarify the text.
Bill stated that the he believes that the outstanding issues
should be resolved and then the DOMSEC I-D should be submitted
for last call.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
RSA As a Must Implement - Blake Ramsdell
Blake Ramsdell proposed that RFC 2630 be changed to require the
RSA public key algorithm as the "MUST implement" key management
algorithm since the RSA patent will expire on 20 September 2000.
He also raised the question of changing RFC 2630 to require the
RSA public key algorithm as the "MUST implement" signature algorithm.
John Pawling asked if anybody had applied for any patents related
to the RSA public key algorithm. Russ Housley stated that was a
possibility, since patent filings are confidential until they are
published. He noted as an example that an organization applied
for a patent regarding the methods for avoiding the "small-
subgroup" attacks on the Diffie-Hellman (D-H) key agreement method.
He stated that nobody had made any statements to him regarding any
patents related to the RSA public key algorithm. John Linn stated
that RSA is not applying for any patents (that he knows of) related
to the RSA public key algorithm.
Pat Cain stated that he was concerned that this significant change
would slow down the process of advancing the S/MIME v3 RFCs from
Internet Proposed Standards to Internet Draft Standards. Jim Schaad
replied that this change would not slow down the process of
implementing the S/MIME v3 standards. Russ Housley stated that the
changes probably would reset the clock for advancing the S/MIME v3
RFCs from Internet Proposed Standards to Internet Draft Standards.
An attendee pointed out that PKCS #1 is not fully tested. Another
attendee stated that the group needs to consider the quality of the
cryptographic algorithms in addition to patent concerns.
Jim Schaad stated that he believes that DSA should remain a "MUST
implement" signature algorithm because the signature value requires
less bytes, and because it is widely implemented and required.
Russ Housley stated that the RFC 2630 Security Considerations
section recommends that the PKCS #1 v2.0 Optimal Asymmetric
Encryption Padding (RSA with OAEP) technique should be employed
instead of the PKCS#1 v1.5 RSA key management algorithm. Therefore,
if Ephemeral-Static Diffie-Hellman is no longer going to be the
mandatory-to-implement algorithm, then he recommends the use of
RSA with OAEP as its replacement.
Jim Schaad asked if separating the algorithms-related text from RFC
2630 would mandate a new six-month waiting period. Russ replied that
he did not believe that change alone mandated a new six-month
waiting period because it does not impact the RFC 2630 core
requirements.
Phillip Hallam-Baker stated his belief that the "S/MIME v3" mark
on a product means that it is interoperable with all S/MIME
implementations, so he supports RSA with OAEP rather than D-H.
An attendee asked if RSA with OAEP breaks backward compatibility
with S/MIME products that implement PKCS#1 v1.5 RSA. Russ
replied that it does break backward compatibility.
Blake Ramsdell pointed out that using RSA with OAEP was a better
option than using Ephemeral-Static (E-S) D-H because the same RSA
certificates can be used with both PKCS#1 v1.5 RSA and RSA with
OAEP.
Russ conducted a straw poll of the meeting attendees to obtain
their opinion regarding the following options for the "mandatory-
to-implement" key management algorithm:
1) PKCS#1 v1.5 RSA
2) RSA with OAEP
3) E-S D-H
The majority of the meeting attendees who voted chose option 1,
An attendee asked if anybody had submitted any patents regarding
RSA with OAEP. Russ replied that the OAEP authors told him that
they have not submitted any patents relating to OAEP.
Dave Solo asked if the group could discuss separate sign and
verify "mandatory-to-implement" signature algorithm requirements.
Russ conducted a straw poll of the meeting attendees to obtain
their opinion regarding Dave's request. The majority of the
meeting attendees who voted indicated that there should not be
separate sign and verify "mandatory-to-implement" signature
algorithm requirements.
Russ conducted a straw poll of the meeting attendees to obtain
their opinion regarding the following options for the "mandatory-
to-implement" signature algorithm:
1) PKCS#1 v1.5 RSA
2) DSA
3) Both
The majority of the meeting attendees who voted chose "Both".
Russ stated that he would submit these proposals to the S/MIME WG
mail list. He noted that the earliest that the changes could be
made would be September 2000.
An attendee asked how many organizations have implemented OAEP.
Russ replied that he did not know of any S/MIME implementations
that include OAEP.
An attendee stated that vendors are required to use NIST-approved
algorithms for federal procurement efforts. Russ stated that
both X9.42 D-H and X9.44 RSA are NIST-approved.
Russ noted that the NIST AES winner is supposed to be announced
in September 2000. He suggested that the group should discuss
whether AES should be the mandatory-to-implement symmetric
encryption algorithm instead of Triple-DES. Dave Solo noted
that AES is still theoretical.
Russ conducted a straw poll of the meeting attendees to obtain
their opinion regarding the following options for the "mandatory-
to-implement" symmetric encryption algorithm:
1) Triple-DES
2) AES
The vote was evenly split between the two options.
Pat Cain recommended that the S/MIME v3 standards should continue
to mandate Triple-DES for the immediate future, but that the group
could consider AES later.
Phillip Hallam-Baker suggested that the S/MIME v3 standards could
mandate both Triple-DES and AES.
Carlisle Adams stated his belief that AES must be the "mandatory-
to-implement" symmetric encryption algorithm. Pat Cain replied
that AES may not be implemented until the end of next year. Jim
Schaad noted that RSA with OAEP also delays implementation.
A meeting attendee stated that the AES has not been published yet,
but Carlisle Adams replied that the five AES candidates are
well-known. The implication being that people could begin
implementing the five AES candidates now.
Russ re-iterated that he would submit these proposals to the
S/MIME WG mail list.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Examples of S/MIME Messages - Paul Hoffman
Paul Hoffman planned to participate in the meeting, but could not
be present because he was required to attend another meeting at
the same time as the S/MIME WG meeting.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Electronic Signature Formats - John Ross
John briefed regarding the "Electronic Signature Formats for long term
electronic signatures" I-D, <draft-ietf-smime-esformats-01.txt>, July
2000. The esformats-01 I-D is based on the ETSI Electronic Signature
Infrastructure Standardisation.
John briefed that the esformats-00 I-D was split into two documents.
One covers Electronic Signature Formats and is proposed to be an
informational RFC. The other covers Signature Policy and is proposed
to be an experimental RFC.
John briefed that esformats-01 uses the following RFCs:
-RFC 2630 Cryptographic Message Syntax (CMS)
-RFC 2459 PKIX Certificate and CRL Profile
-RFC (to be published) PKIX Timestamping protocol
-RFC on "Attribute Certificates".
He summarized that the esformats-01 I-D defines a process to
provide proof of validity of a signature to be used if
repudiation is attempted.
John stated that the contents of the esformats-01 I-D is technically
equivalent to the ETSI ES 201 733 V.1.1 document. ETSI owns the
Copyright (C) on this document. John stated that individual copies
of the document can be downloaded from <http://www.etsi.org>. He
noted that these are two new ETSI work items: long term Electronic
Signature Formats that do not mandate timestamping and long term
Electronic Signature Formats based on XML signatures syntax.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Signature Policy Format - Denis Pinkas
Denis briefed regarding the "Electronic Signature Policies" I-D,
<draft-ietf-smime-espolicies-00.txt>. Denis briefed that the
contents of the I-D is based on the signature policy defined in the
ETSI ES 201 733 V.1.1.3(2000-05) document. ETSI owns the
Copyright (C) on this document. Denis stated that the
I-D defines signature policies for electronic signatures. He defined
signature policy as a set of rules for the creation and validation
of an electronic signature, under which the validity of signature can
be determined. He noted that a given legal/contractual context may
recognize a particular signature policy as meeting its requirements.
He stated that a signature policy has a globally unique reference,
which is bound to an electronic signature by the signer as part of
the signature calculation. He said that the signature policy needs
to be available in human readable form so that it can be assessed
to meet the requirements of the legal and contractual context in
which it is being applied. He briefed that to allow for the
automatic processing of an electronic signature another part of the
signature policy specifies the electronic rules for the creation
and validation of the electronic signature in a computer processable
form. He noted that the current document defines the format of the
signature policy using ASN.1 and briefed the proposed syntax.
Denis concluded with the statement that work on section 5 of the ID
continues
to define the Conformance Requirements including:
5.1 Signature Policy definition - Any signature policy issued by
a Signature Policy Issuer SHALL include ...
5.2 For signer systems - Signer systems MUST be able to process an
electronic signature defined in accordance with [ES-FORMATS]
against the signer rules of a signature policy defined in
accordance with ...
5.3 For verifier systems - Verifier systems MUST be able to process
an electronic signature defined in accordance with [ES-FORMATS]
against the verifier rules of a signature policy defined in
accordance with ...
An attendee asked if there was an issue regarding the occurrence of
one or more time stamps associated with the signature. Denis
responded that the signature policy may mandate a single or
multiple TSAs. For example, separate TSAs may be specified for the
sender and recipient.
Carlisle Adams asked about the timeframe for ETSI. Denis replied
that the ASN.1 for the signature format is stable, but the signature
policy ASN.1 syntax is still being actively discussed. He believes
that there will be a stable signature policy document by the end of
the year.
John Ross invited comments to both documents.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Wrap Up - Russ Housley
Russ asked if there were any other issues to discuss. The meeting
attendees were silent.
Meeting adjourned.