Subject: Re: Proposed charter for a S/MIME working group
From: Paul Hoffman / IMC <[email-masked]>
To: [email-masked]
Date: Tue, 30 Sep 1997 18:41:07 -0700

At 6:31 PM -0700 9/30/97, Kazu Yamamoto
(=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) wrote:
>Let me confirm. Why will S/MIME specs be submitted as Informational RFC?

At the Munich IETF meeting, the IESG announced that for security-related
standards, they have a strong preference for unencumbered technologies when
they exist. Since then, Jeff Schiller, the Area Director for security, has
said that he will not approve standards that rely on RSA encryption if
Diffie-Hellman key exchange could be used instead.

>PGP/MIME is on Standards track. I wonder why S/MIME cannot.

PGP/MIME became a proposed standard before this decision. It is likely that
it would not make it now. In fact, Jeff Schiller has said that he would not
support it moving to Draft Standard with its current requirement for RSA
encryption. However, that is not so much an issue now that there is (as of
today) an OpenPGP Working Group which will produce a protocol that does not
rely on RSA encryption.

One of the purposes of the S/MIME 3 work is so that we can produce a
protocol that does not require RSA encryption.

--Paul E. Hoffman, Director
--Internet Mail Consortium

To: [email-masked]
Subject: Re: Proposed charter for a S/MIME working group
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[email-masked]>
Date: Wed, 01 Oct 1997 10:31:57 +0900
Lines: 13
Sender: [email-masked]

From: Paul Hoffman / IMC <[email-masked]>
Subject: Proposed charter for a S/MIME working group
Date: Tue, 30 Sep 1997 12:36:30 -0700

> History:
>      PKCS #7 version 1.5 specification submitted as Informational RFC.
>      S/MIME v2 message specification submitted as Informational RFC.
>      S/MIME v2 certificate specification submitted as Informational RFC.

Let me confirm. Why will S/MIME specs be submitted as Informational RFC?
PGP/MIME is on Standards track. I wonder why S/MIME cannot.

--Kazu

Date: Tue, 30 Sep 1997 20:59:10 -0400
To: [email-masked]
From: David Solo <[email-masked]>
Subject: Re: Certs draft for review
Sender: [email-masked]

Repost of follow-up message
>
>At 03:54 PM 9/29/97 -0700, Anil R. Gangolli wrote:
>>David Solo wrote:
>>> 
>>... I agree with just about everything Dave said.  A few exceptions
>>below.
>>
>>> >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.
>>>
>>
>>Dave, do you have an alternative suggestion?
>>e.g.
>>- S/MIME implementations MUST support chain formation based on
>>subjectAltNames and issuerAltNames fields.
>>  People seemed opposed to this in this draft.
>>- S/MIME implementations SHOULD support chain formation ... as in
>>previous statement; and stregthen in
>>  a future draft.
>>- no statement at all
>
>Part of the question is to whom the requirement applies.  A statement that
clients MUST support chaining by DN and MAY/SHOULD support chaining by
altName is OK.  I'm not sure if the intent of the original language is to
also preclude a CA cert with a null DN.  While doing this may be necessary,
it does require enterprise CAs to have to choose a DN.  I can live with either.
>
>>
>>> >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.
>>> 
>>
>>I think the last two sentences needs to be clarified.  The way
>>I'm interpreting them right now, I would disagree.  
>>
>>If by "these" you mean those listed above, and by "other" you mean
>>anything else, you're not allowing for extensions that the
>>issuer wishes to require that implementations consider.
>
>I agree with you - the wording is still wrong.  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?
>
>>...
>>
>>> 
>>> 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?
>>
>>Yes, but why are we getting into this here?
>
>Actually, it doesn't belong here, but its missing from the cert path
processing description in PKIX.
>
>>-- 
>>Anil R. Gangolli
>>Structured Arts Consulting Group
>>mailto:[email-masked]
>>http://www.StructuredArts.com
>>
>
>Dave
>

Date: Tue, 30 Sep 1997 16:54:57 -0700
From: [email-masked] (John Myers)
To: [email-masked]
Subject: Re: Are we really finished?
Sender: [email-masked]

My previous message to the list must have gotten lost somewhere.  Here
it is again:

Paul Hoffman / IMC wrote:
> ** signedData vs. application/mime wording**
> 
> Section 3 talks a lot about what to do if the sender thinks that a signed
> message will go through a gateway that will separate or change the message.
> This has long been a contentious issue. Of the three implementations I know
> of, Microsoft and Netscape never use either of the two protection
> alternatives, and Deming will only send out signedData (I think).
> 
> My proposal, which wasn't all that well received, was that we move the
> whole discussion to a short appendix that covers just what the two options
> are, the brief advantages and disadvantages of each, says that as of today
> no one has tested application/mime, says that receiving agents SHOULD
> accept both, and you make your own decision. This does describe what the
> current practice is, so it's an honest approach. It also lets implementors
> figure out what works best for them. Let's remember that this a very
> transport-related issue for a protocol that is supposed to be
> transport-independent.
> 
> If you have a different idea of how to deal with the issue, please speak up!

I believe I've raised enough unresolved technical problems with
application/mime to warrant its removal from the document until such
time as the issues are resolved.

Date: Tue, 30 Sep 1997 17:04:35 -0400
To: [email-masked]
From: David Solo <[email-masked]>
Subject: comments on the smime-cert draft
Sender: [email-masked]

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
>>"[email-masked]", not "First Last <[email-masked]>". 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
>

Date: Tue, 30 Sep 1997 12:36:30 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Proposed charter for a S/MIME working group
Sender: [email-masked]

Greetings, all. As you saw last week, RSA has sent the ISOC material that
(hopefully) meets the IESG's requirements for what must happen before we
form an S/MIME working group. So, our next task is to agree on a charter
and submit it to Jeff Schiller, the area director for security. If Jeff
agrees, he'll take it to the IESG for their consideration.

Below is what I think a reasonable charter should look like. All comments
are welcome.

= = = = = = = = =

S/MIME Mail Security (smime)

Chair:
     Russ Housley <[email-masked]>

Security Area Director:
     Jeffrey Schiller <[email-masked]>

Mailing Lists:
     General Discussion: [email-masked]
     To Subscribe:       [email-masked]
     Archive:            http://www.imc.org/ietf-smime/

Description of Working Group:

The S/MIME Working Group will define MIME encapsulation of digitally
signed and encrypted objects whose format is based on PKCS #7. X.509
Certificates and CRLs as profiled by the existing PKIX Working Group
will be used to support authentication and key management. The Working
Group will base its work on the S/MIME version 2 specification, but
the Working Group will be free to change any part of that
specification. In particular, the Working Group will prepare a new
document that allows algorithm independence, based on PKCS #7 1.5.

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.

Goals and Milestones:

History:
     PKCS #7 version 1.5 specification submitted as Informational RFC.
     S/MIME v2 message specification submitted as Informational RFC.
     S/MIME v2 certificate specification submitted as Informational RFC.

October 97:
     First draft of message syntax specification.
     First draft of S/MIME v3 message specification.
     First draft of S/MIME v3 certificate specification.
     First draft of S/MIME optional security extensions.

December 97:
     Last call on message syntax specification.
     Last call on S/MIME v3 message specification.
     Last call on S/MIME v3 certificate specification.

January 98:
     Last call on S/MIME optional security extensions.
     Submit  message syntax specification as a Proposed Standard.
     Submit S/MIME v3 message specification as a Proposed Standard.
     Submit S/MIME v3 certificate specification as a Proposed Standard.

February 98:
     Submit S/MIME optional security extensions as a Proposed Standard.

--Paul E. Hoffman, Director
--Internet Mail Consortium

Date: Tue, 30 Sep 1997 15:23:04 -0400
To: "Roger Fajman" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re:  Signing time format
Cc: [email-masked]
Sender: [email-masked]

This is different because the the format to support dates beyond 2050 is
already defined.  The Y2K problem is a problem because a format to handle
the upcoming century was not agreed to by everyone well in advance.

Russ

At 07:44 PM 9/24/97 EDT, Roger Fajman wrote:
>> Don't you think that fifty years is enough time to upgrade all certificate
>> implenetations?
>
>Sure, but a lot of people thought that they didn't have to worry about
>the year 2000 because it was 25 years away.  Why set deadlines sooner than
>they really need to be?
>

From: Steve Dusse <[email-masked]>
To: "'Graham Klyne'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: RSA letter to ISOC
Date: Mon, 29 Sep 1997 11:41:15 -0700
Sender: [email-masked]

To answer the question that I think you're asking;

No, the MIT patent on the RSA public key cryptosystem has not been put
in the public domain.   On the other hand, there is no guarantee that
the protocol which results from IETF involvement in S/MIME will make any
use of RSA.

Hope this is helpful.

Cheers,
Steve Dusse
CTO
RSA

>----------
>From: 	Graham Klyne[SMTP:[email-masked]]
>Sent: 	Saturday, September 27, 1997 9:40 AM
>To: 	Steve Dusse; [email-masked]'
>Subject: 	Re: RSA letter to ISOC
>
>I'm not an IPR expert, so please excuse me if this is a dumb question:
>
>At 11:33 AM 9/26/97 -0700, Steve Dusse wrote:
>>>[...] to the extent
>>>RSA has any copyright interest or claim on the S/MIME specification [...]
>>>resulting from contributing authorship or otherwise, RSA hereby
>>>relinquishes
>>>and disclaims any such interest or claim thereto and contributes them to
>>>the
>>>public domain.
>
>My question:
>
>Does this mean that that RSADSI's patent control over the RSA *algorithm*
>is being relinquished?
>
>GK.
>---
>
>
>

From: Ray Langford <[email-masked]>
Date: Mon, 29 Sep 1997 08:50:57 -0500
Subject: Re: Looking for S/MIME API over Windows platform
To: "Ajay K. Sanghi" <[email-masked]>, "[email-masked]'" <[email-masked]>
Reply-To: [email-masked]
Sender: [email-masked]

>
>Hello:
>
>I am looking for S/MIME API (preferably MFC extension classes) over 
Windows 95 and NT platforms.

Ajay,

Frontier Technologies will soon release their e-Lock Secure Messaging
Toolkit. The e-Lock Secure Messaging Toolkit uses a modular design for
desktop and server application integration that supports a MIME engine and
multiple Secure Protocol Modules (SPM) for different secure messaging
protocols (S/MIME, MSP, PGP, etc.). The first SPM to ship with the e-Lock
Secure Messaging Toolkit will support S/MIME and use the Microsoft 
CryptoAPI. The e-Lock Secure Messaging Toolkit supports two interfaces, a 
standard 'C' based API and a COM interface (i.e callable from ASP pages, 
VB, etc.).

For more info, please review the e-Lock Secure Messaging Toolkit
documentation (press release, spec sheet, API docs, etc.) on our web site:
       www.FrontierTech.com

>Anybody having experience of having implemented S/MIME given MIME and 
CryptoAPI.
>
>Thanks,
>
>Regards,
>
>ajay
>

==========================================
Ray C. Langford
Director of Research and Development
Frontier Technologies Corp.
Email: [email-masked]
Voice: (414) 241-4555 x205
==========================================

From: "Ajay K. Sanghi" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Looking for S/MIME API over Windows platform
Date: Mon, 29 Sep 1997 08:41:23 +-5-30
Sender: [email-masked]

Hello:

I am looking for S/MIME API (preferably MFC extension classes) over Windows 95 and NT platforms.

Anybody having experience of having implemented S/MIME given MIME and CryptoAPI.

Thanks,

Regards,

ajay

Date: Sat, 27 Sep 1997 11:28:15 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Are we really finished?
Sender: [email-masked]

I hope everyone has had an opportunity to look at the new drafts that I
posted on Tuesday. So far, no one has commented at all on them. This could
be a good sign, that everything's done. If these really reflect what we
believe the spec for S/MIME 2 is, then I'll happily send the finals off to
the RFC editor to become informational RFCs of the spec.

If anyone has any objections or other comments, please post them by
Tuesday, September 30. It would be lovely to have these out on October 1,
and we can then start talking about S/MIME 3.

--Paul E. Hoffman, Director
--Internet Mail Consortium

Date: Sat, 27 Sep 1997 11:24:43 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: RSA letter to ISOC
Sender: [email-masked]

At 9:40 AM -0700 9/27/97, Graham Klyne wrote:
>Does this mean that that RSADSI's patent control over the RSA *algorithm*
>is being relinquished?

No. The word "patent" didn't appear anywhere in what they gave up.
Copyrights and trademarks are different than patents.

--Paul E. Hoffman, Director
--Internet Mail Consortium

Date: Sat, 27 Sep 1997 17:40:48 +0100
To: Steve Dusse <[email-masked]>, "[email-masked]'" <[email-masked]>
From: Graham Klyne <[email-masked]>
Subject: Re: RSA letter to ISOC
Sender: [email-masked]

I'm not an IPR expert, so please excuse me if this is a dumb question:

At 11:33 AM 9/26/97 -0700, Steve Dusse wrote:
>>[...] to the extent
>>RSA has any copyright interest or claim on the S/MIME specification [...]
>>resulting from contributing authorship or otherwise, RSA hereby relinquishes
>>and disclaims any such interest or claim thereto and contributes them to the
>>public domain.

My question:

Does this mean that that RSADSI's patent control over the RSA *algorithm*
is being relinquished?

GK.
---

From: "George Hatoun" <[email-masked]>
To: "Bruce Schneier" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: S/MIME Crack?  Beware press bearing incomplete stories
Date: Fri, 26 Sep 1997 13:25:29 -0700
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0090_01BCCA7F.A87DB800
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Actually, while there were some interoperability issues with the Beta 2 =
version of Outlook Express (the Internet Explorer mail client), these =
have been addressed for the final release (which will be on the Web on =
September 30); we do interop with Netscape Communicator.

-George Hatoun
Program Manager,
Microsoft Outlook Express
-----Original Message-----
    From: Bruce Schneier <[email-masked]>
    To: [email-masked] <[email-masked]>; [email-masked] =
<[email-masked]>
    Date: Friday, September 26, 1997 9:30 AM
    Subject: S/MIME Crack? Beware press bearing incomplete stories
   =20
    [...]
   =20
    I wrote this screen saver not to trash S/MIME (even though the =
announcement=20
    was used by another company), but to 1) illustrate that 40-bit RC2 =
really=20
    is insecure, and 2) try to force companies who implement S/MIME to =
get=20
    DES and triple-DES to interoperate.  I heard recently that RSADSI =
has said=20
    there is a triple-DES message on their website that can be =
understood by=20
    both Microsoft Internet Explorer and Netscape Communicator.  I don't =
know=20
    about the message, but when I tried to get DES and triple-DES to =
interoperate=20
    a few months ago I couldn't.=20
   =20
    Bruce=20
   =20
    =
**********************************************************************=20
    Bruce Schneier, President, Counterpane Systems     Phone: =
612-823-1098=20
    101 E Minnehaha Parkway, Minneapolis,MN  55419       Fax: =
612-823-1590=20
                                                =
http://www.counterpane.com=20
   =20

------=_NextPart_000_0090_01BCCA7F.A87DB800
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type><TITLE>S/MIME Crack? Beware press bearing =
incomplete stories</TITLE><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML =
3.2//EN">
<META content=3D'"MSHTML 4.71.1712.3"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>Actually, while there were some =
interoperability=20
issues with the Beta 2 version of Outlook Express (the I</FONT><FONT=20
color=3D#000000 size=3D2>nternet Explorer mail client), these have been =
addressed=20
for the final release (which will be on the Web on September 30); we do =
interop=20
with Netscape Communicator.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>-George Hatoun</FONT></DIV>
<DIV><FONT size=3D2>Program Manager,</FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Microsoft Outlook Express</FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 solid 2px; MARGIN-LEFT: 5px; PADDING-LEFT: =
5px">
    <DIV><FONT face=3DArial size=3D2><B>-----Original =
Message-----</B><BR><B>From:=20
    </B>Bruce Schneier &lt;<A=20
    =
href=3D"mailto:[email-masked]">[email-masked]</A>&gt;=
<BR><B>To:=20
    </B><A href=3D"mailto:[email-masked]">[email-masked]</A> =
&lt;<A=20
    href=3D"mailto:[email-masked]">[email-masked]</A>&gt;; <A=20
    href=3D"mailto:[email-masked]">[email-masked]</A> &lt;<A=20
    =
href=3D"mailto:[email-masked]">[email-masked]</A>&gt;<BR><B>Date:=
=20
    </B>Friday, September 26, 1997 9:30 AM<BR><B>Subject: </B>S/MIME =
Crack?=20
    Beware press bearing incomplete stories<BR></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2>[...]<BR></FONT>&nbsp;</DIV>
    <P><FONT size=3D2>I wrote this screen saver not to trash S/MIME =
(even though=20
    the announcement</FONT> <BR><FONT size=3D2>was used by another =
company), but=20
    to 1) illustrate that 40-bit RC2 really</FONT> <BR><FONT size=3D2>is =
insecure,=20
    and 2) try to force companies who implement S/MIME to get</FONT> =
<BR><FONT=20
    size=3D2>DES and triple-DES to interoperate.&nbsp; I heard recently =
that=20
    RSADSI has said</FONT> <BR><FONT size=3D2>there is a triple-DES =
message on=20
    their website that can be understood by</FONT> <BR><FONT =
size=3D2>both=20
    Microsoft Internet Explorer and Netscape Communicator.&nbsp; I don't =

    know</FONT> <BR><FONT size=3D2>about the message, but when I tried =
to get DES=20
    and triple-DES to interoperate</FONT> <BR><FONT size=3D2>a few =
months ago I=20
    couldn't.</FONT> </P>
    <P><FONT size=3D2>Bruce</FONT> </P>
    <P><FONT=20
    =
size=3D2>****************************************************************=
******</FONT>=20
    <BR><FONT size=3D2>Bruce Schneier, President, Counterpane=20
    Systems&nbsp;&nbsp;&nbsp;&nbsp; Phone: 612-823-1098</FONT> <BR><FONT =

    size=3D2>101 E Minnehaha Parkway, Minneapolis,MN&nbsp;=20
    55419&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Fax: 612-823-1590</FONT> =
<BR><FONT=20
    =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    <A href=3D"http://www.counterpane.com"=20
    target=3D_blank>http://www.counterpane.com</A></FONT>=20
</P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0090_01BCCA7F.A87DB800--

Date: Fri, 26 Sep 1997 14:40:17 +0100
From: Jeff Williams <[email-masked]>
Organization: IEG. INC.
To: Bruce Schneier <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: S/MIME Crack?  Beware press bearing incomplete stories
Sender: [email-masked]

Bruce,

  Is there a S/MIME implimentation or download avalibel for
16 bit systems like windows 3.11?  If so where might one find it?

Bruce Schneier wrote:
> 
> What I did:  write a Windows 95 screen saver that automatically brute
> forces 40-bit RC2 keys.  The screen saver is has an easy interface, and
> parallizes nicely.
> 
> What I didn't do:  break S/MIME.  I did not find any flaw in the S/MIME
> security specification.  I did not find any flaw in any of the cryptographic
> algorithms used.  I did not find any flaw in any software implementation
> of S/MIME.  There is nothing wrong with the S/MIME standard.
> 
> What I find, though, is that many S/MIME implementations don't interporate
> at anything stronger than 40-bit RC2.  I find that the default encryption
> is 40-bit RC2, and the user isn't given any indication that the encryption
> level should be changed.
> 
> 40-bit RC2 is weak.  This is nothing new to anyone who reads the S/MIME
> specifications. In fact, the S/MIME specification is very forthcoming in
> discussing security of 40-bit RC2.
> 
> > 2.6 ContentEncryptionAlgorithmIdentifier
> >
> > Receiving agents MUST support decryption and encryption using the RC2
> > algorithm [RC2] at a key size of 40 bits, hereinafter called "RC2/40".
> > Receiving agents SHOULD support decryption using DES EDE3 CBC,
> > hereinafter called "tripleDES".
> >
> > Sending agents SHOULD support encryption with RC2/40 and tripleDES.
> 
> Later in the spec, the following appears:
> 
> > Before sending a message, the sending agent MUST decide whether it is
> > willing to use weak encryption for the particular data in the message.
> > If the sending agent decides that weak encryption is unacceptable for
> > this data, then the sending agent MUST NOT use a weak algorithm such
> > as RC2/40. The decision to use or not use weak encryption overrides
> > any other decision in this section about which encryption algorithm to
> > use.
> 
> And even later:
> 
> > 2.6.2.3 Rule 3: Unknown Capabilities, Risk of Failed Decryption
> >
> > If:
> >  - the sending agent has no knowledge of the encryption capabilities
> >    of the recipient,
> >  - and the sending agent is willing to risk that the recipient may
> >    not be able to decrypt the message,
> > then the sending agent SHOULD use tripleDES.
> >
> > 2.6.2.4 Rule 4: Unknown Capabilities, No Risk of Failed Decryption
> >
> > If:
> >  - the sending agent has no knowledge of the encryption capabilities
> >    of the recipient,
> >  - and the sending agent is not willing to risk that the recipient
> >    may not be able to decrypt the message,
> > then the sending agent MUST use RC2/40.
> 
> And:
> 
> > 2.6.3 Choosing Weak Encryption
> >
> > Like all algorithms that use 40 bit keys, RC2/40 is considered by many
> > to be weak encryption. A sending agent that is controlled by a human
> > SHOULD allow a human sender to determine the risks of sending data
> > using RC2/40 or a similarly weak encryption algorithm before sending
> > the data, and possibly allow the human to use a stronger encryption
> > method such as tripleDES.
> 
> I wrote this screen saver not to trash S/MIME (even though the announcement
> was used by another company), but to 1) illustrate that 40-bit RC2 really
> is insecure, and 2) try to force companies who implement S/MIME to get
> DES and triple-DES to interoperate.  I heard recently that RSADSI has said
> there is a triple-DES message on their website that can be understood by
> both Microsoft Internet Explorer and Netscape Communicator.  I don't know
> about the message, but when I tried to get DES and triple-DES to interoperate
> a few months ago I couldn't.
> 
> Bruce
> 
> **********************************************************************
> Bruce Schneier, President, Counterpane Systems     Phone: 612-823-1098
> 101 E Minnehaha Parkway, Minneapolis,MN  55419       Fax: 612-823-1590
>                                             http://www.counterpane.com

-- 
Jeffrey A. Williams
DIR. Internet Network Eng/SR. Java Development Eng.
Information Eng. Group. IEG. INC. 
Phone :913-294-2375 (v-office)
E-Mail [email-masked]

From: Steve Dusse <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RSA letter to ISOC
Date: Fri, 26 Sep 1997 11:33:07 -0700
Sender: [email-masked]

Hi Y'all,

This letter was sent to the ISOC today.

Cheers,
Steve Dusse

>
>In furtherance of RSA Data Security, Inc.'s goal of promoting the
>standardization work on the S/MIME protocol within the IETF, to the extent
>RSA has any copyright interest or claim on the S/MIME specification Internet
>Drafts  (i.e., draft-dusse-smime-msg-xx and draft-dusse-smime-cert-xx)
>resulting from contributing authorship or otherwise, RSA hereby relinquishes
>and disclaims any such interest or claim thereto and contributes them to the
>public domain.
>
>As a point of clarification, it has not been the intent of RSA Data Security,
>Inc. to claim ownship of the mere acronym S/MIME as a trademark of RSA;
>rather, RSA intends to create one or more pictorial logos which may include
>the S/MIME name to connote RSA Data Security, Inc. as the source of products
>and/or services associated with the S/MIME protocol.  To the extent
>representations have been made inconsistent with the foregoing, and
>specifically that RSA Data Security has claimed as a trademark the
>stand-alone acronym S/MIME, RSA hereby disclaims any such ownership interest.
>
>
>
>
>
>
>

Posted-Date: Fri, 26 Sep 1997 11:25:42 -0500 (CDT)
Date: Fri, 26 Sep 1997 11:30:29 -0500
To: [email-masked], [email-masked]
From: Bruce Schneier <[email-masked]>
Subject: S/MIME Crack?  Beware press bearing incomplete stories
Sender: [email-masked]

What I did:  write a Windows 95 screen saver that automatically brute
forces 40-bit RC2 keys.  The screen saver is has an easy interface, and
parallizes nicely.

What I didn't do:  break S/MIME.  I did not find any flaw in the S/MIME
security specification.  I did not find any flaw in any of the cryptographic
algorithms used.  I did not find any flaw in any software implementation
of S/MIME.  There is nothing wrong with the S/MIME standard.

What I find, though, is that many S/MIME implementations don't interporate
at anything stronger than 40-bit RC2.  I find that the default encryption
is 40-bit RC2, and the user isn't given any indication that the encryption
level should be changed.

40-bit RC2 is weak.  This is nothing new to anyone who reads the S/MIME
specifications. In fact, the S/MIME specification is very forthcoming in
discussing security of 40-bit RC2.

> 2.6 ContentEncryptionAlgorithmIdentifier
>
> Receiving agents MUST support decryption and encryption using the RC2
> algorithm [RC2] at a key size of 40 bits, hereinafter called "RC2/40".
> Receiving agents SHOULD support decryption using DES EDE3 CBC,
> hereinafter called "tripleDES".
>
> Sending agents SHOULD support encryption with RC2/40 and tripleDES.

Later in the spec, the following appears:

> Before sending a message, the sending agent MUST decide whether it is
> willing to use weak encryption for the particular data in the message.
> If the sending agent decides that weak encryption is unacceptable for
> this data, then the sending agent MUST NOT use a weak algorithm such
> as RC2/40. The decision to use or not use weak encryption overrides
> any other decision in this section about which encryption algorithm to
> use.

And even later:

> 2.6.2.3 Rule 3: Unknown Capabilities, Risk of Failed Decryption
>
> If:
>  - the sending agent has no knowledge of the encryption capabilities
>    of the recipient,
>  - and the sending agent is willing to risk that the recipient may
>    not be able to decrypt the message,
> then the sending agent SHOULD use tripleDES.
>
> 2.6.2.4 Rule 4: Unknown Capabilities, No Risk of Failed Decryption
>
> If:
>  - the sending agent has no knowledge of the encryption capabilities
>    of the recipient,
>  - and the sending agent is not willing to risk that the recipient
>    may not be able to decrypt the message,
> then the sending agent MUST use RC2/40.

And:

> 2.6.3 Choosing Weak Encryption
>
> Like all algorithms that use 40 bit keys, RC2/40 is considered by many
> to be weak encryption. A sending agent that is controlled by a human
> SHOULD allow a human sender to determine the risks of sending data
> using RC2/40 or a similarly weak encryption algorithm before sending
> the data, and possibly allow the human to use a stronger encryption
> method such as tripleDES.

I wrote this screen saver not to trash S/MIME (even though the announcement
was used by another company), but to 1) illustrate that 40-bit RC2 really
is insecure, and 2) try to force companies who implement S/MIME to get
DES and triple-DES to interoperate.  I heard recently that RSADSI has said
there is a triple-DES message on their website that can be understood by
both Microsoft Internet Explorer and Netscape Communicator.  I don't know
about the message, but when I tried to get DES and triple-DES to interoperate
a few months ago I couldn't.

Bruce

**********************************************************************
Bruce Schneier, President, Counterpane Systems     Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis,MN  55419       Fax: 612-823-1590
                                            http://www.counterpane.com

Date: Wed, 24 Sep 1997 17:42:05 -0700
From: "Anil R. Gangolli" <[email-masked]>
Reply-To: [email-masked]
Organization: Structured Arts Consulting Group
To: Roger Fajman <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Signing time format
Sender: [email-masked]

Roger Fajman wrote:
> 
> > Don't you think that fifty years is enough time to upgrade all
> certificate
> > implenetations?
> 
> Sure, but a lot of people thought that they didn't have to worry about
> the year 2000 because it was 25 years away.  Why set deadlines sooner
> than
> they really need to be?

I don't think people care too much about the choice of 2050 vs 2070
vs 2090, for this rollover value but what is important is:

- implementations agree on what a given encoded date means and how
  to encode a given date.

- SMIME should follow what PKIX adopts rather than define things
  separately and differently.

If one really cares about the 2050 vs. 2090 issue,
one should argue it on PKIX lists:
ietf-pkix /ietf-pkix-request  @tandem.com

--a.

-- 
Anil R. Gangolli
Structured Arts Consulting Group
mailto:[email-masked]
http://www.StructuredArts.com

To: [email-masked]
cc: [email-masked]
From: "Roger Fajman" <[email-masked]>
Date:     Wed, 24 Sep 1997  19:44:47 EDT
Subject:  Re:  Signing time format
Sender: [email-masked]

> Don't you think that fifty years is enough time to upgrade all certificate
> implenetations?

Sure, but a lot of people thought that they didn't have to worry about
the year 2000 because it was 25 years away.  Why set deadlines sooner than
they really need to be?

Date: Wed, 24 Sep 1997 10:56:31 -0700
To: Paul Hoffman / IMC <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: MailConnect 3 interoperability event
Cc: (smime-dev), (ietf-smime), (ietf-pgp-mime)
Sender: [email-masked]

Greetings again. As some of you may know, the MailConnect 3 event that is
coming up in a little more than a month has two focuses: IMAP 4 and
end-to-end security. Some people have told me that they didn't realize that
MailConnect 3 would help companies test interoperability of S/MIME and
PGP/MIME agents, so I thought I would send this message to the relevant
mailing lists for those two communities.

The MailConnect series of interoperability events lets vendors come and
freely test implementations, both shipping and pre-release, of products
that conform to one of the tested protocols. This is not a conformance
test, nor is it a press event. The main idea is to get all the significant
players into a room for two days so that they can try out whatever
features, extensions, and modules of their clients. There are also pull-out
sessions to discuss protocol issues, particularly if problems arise during
testing. We expect between 10 and 20 companies to participate in
MailConnect 3.

For more information about MailConnect 3, please see
<http://www.imc.org/imc-mailconnect/mailconnect3-announce.html>.

--Paul E. Hoffman, Director
--Internet Mail Consortium

Date: Wed, 24 Sep 1997 10:24:40 -0400
To: "Roger Fajman" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re:  Signing time format
Cc: [email-masked]
Sender: [email-masked]

Don't you think that fifty years is enough time to upgrade all certificate
implenetations?

Russ

At 08:33 PM 9/17/97 EDT, Roger Fajman wrote:
>> PKIX says 2050.  I say we go with that.
>
>It makes sense to coordinate with PKIX, but why does PKIX say 2050?
>2090 would make a lot more sense, as no certificates existed before
>1990.  Or, perhaps the Year2000 WG will choose a common number for
>all Internet protocols.  In that case, something like 2060 might
>make sense.
>

Date: Tue, 23 Sep 1997 11:11:04 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Revised S/MIME message draft
Sender: [email-masked]

Greetings. This follows up on our previous discussion of open issues in the
S/MIME message draft. It appears we are pretty close to done. The new draft
has now been submitted as a new Internet Draft. It is available from
<http://www.imc.org/ietf-smime/draft-dusse-smime-msg> now, and should
appear in the Internet Drafts directory within a few days.

All S/MIME developers should read this draft carefully, since it might be
the last one before we ship it off as final.

The following changes were made between the -03 and -04 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.2 to make it clear how we are using the MUSTSHOULD RFC.

Updated the references to ASN.1, BER, and DER in 1.3.

In 2.5, changed "handle and display" to "handle"  because there is on
UI defined so we can't say how to "display".

In 2.5.1, changed how signing time is used in order to be Year 2000
friendly and to use the same method as PKIX.

Because this won't go on standards track, the registry listed 2.5.2
now only points to the IMC.

In 2.6, changed "RC2 algorithm[RC2]" to "RC2 [RC2] or a compatible
algorithm".

Added 2.6.4 about what to do if sending to multiple recipients whose
encryption capabilities do not overlap. Also emphasized this in
section 5.

Changed many parts of section 3 to remove the discussion of how to
choose between signedData and multipart/signed. Some of this material
was moved to Appendix F.

In 3.1.1, added a sentence about specifying the charset so that the
receiver can figure out the canonicalization better.

In 3.1.2, changed the default transfer encoding to 7BIT if none is
specified.

In 3.1.4, changed the Content-Type of the example from
application/willy-waggle to image/jpeg.

In 3.2.1, added a reference to the Content-Disposition RFC.

In the example in 3.4.2.3, added a blank line after the message.

Added "name", "filename", and "smime-type" as optional parameters on
each of the registrations in Appendix E.

Removed old Appendix G (the S/MIME trademark) at the request of RSA.
RSA does not claim trademark rights to the name "S/MIME".

--Paul E. Hoffman, Director
--Internet Mail Consortium

Date: Tue, 23 Sep 1997 11:11:04 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Revised S/MIME certs draft
Sender: [email-masked]

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 "[email-masked]", not "First Last <[email-masked]>".
-----Do people agree on this?

==============================

Minutes of 9/12 S/MIME-cert meeting
Taken by David Solo <[email-masked]>

In attendance:
David Solo, BBN <[email-masked]>
Mike Myers, VeriSign <[email-masked]>
Jeff Weinstein, Netscape <[email-masked]>
Anil Gangolli, Structured Arts <[email-masked]
Peter Yee, SPYRUS <[email-masked]>
Buce Kelly, Microsoft <[email-masked]>
George Hatoun, Microsoft <[email-masked]>
Blake Ramsdell, Worldtalk <[email-masked]>
Paul Hoffman, IMC <[email-masked]>

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

To: [email-masked]
Path: news
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-smime
Subject: Re: Open issues in the message draft
Date: Fri, 19 Sep 1997 15:47:06 -0700
Organization: Netscape Communications Corporation
Lines: 24
NNTP-Posting-Host: 205.217.229.208
Sender: [email-masked]

Paul Hoffman / IMC wrote:
> ** signedData vs. application/mime wording**
> 
> Section 3 talks a lot about what to do if the sender thinks that a signed
> message will go through a gateway that will separate or change the message.
> This has long been a contentious issue. Of the three implementations I know
> of, Microsoft and Netscape never use either of the two protection
> alternatives, and Deming will only send out signedData (I think).
> 
> My proposal, which wasn't all that well received, was that we move the
> whole discussion to a short appendix that covers just what the two options
> are, the brief advantages and disadvantages of each, says that as of today
> no one has tested application/mime, says that receiving agents SHOULD
> accept both, and you make your own decision. This does describe what the
> current practice is, so it's an honest approach. It also lets implementors
> figure out what works best for them. Let's remember that this a very
> transport-related issue for a protocol that is supposed to be
> transport-independent.
> 
> If you have a different idea of how to deal with the issue, please speak up!

I believe I've raised enough unresolved technical problems with
application/mime to warrant its removal from the document until such
time as the issues are resolved.

Date: Fri, 19 Sep 1997 11:03:38 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re:  Signing time format
Sender: [email-masked]

> From: "Roger Fajman" <[email-masked]>
> 
> > PKIX says 2050.  I say we go with that.
> 
> It makes sense to coordinate with PKIX, but why does PKIX say 2050?
> 2090 would make a lot more sense, as no certificates existed before
> 1990.  Or, perhaps the Year2000 WG will choose a common number for
> all Internet protocols.  In that case, something like 2060 might
> make sense.

Then it's up to the Y2K WG to lobby both PKIX and ISO/ITU to change
their certificate specifications.  They both require that dates which
are encoded as UTCTime shall be interpreted with a cutover of 2050.

The current (6/97) draft of X.509 says that if UTCTime is used, then:

  "if the 2 digit value is 00 through 49 inclusive, the value shall
     have 2000 added to it.

   if the 2 digit value is 50 through 99 inclusive, the value shall
     have 1900 added to it."

Note that there is another cutover date to be considered - the date
by which implementations should support the use of GeneralizedTime
in certificates.  This support issue is left up to individual profiling
groups (such as PKIX); X.509 merely says:

  "In no case shall UTCTime be used for representing dates beyond 2049."

Date: Thu, 18 Sep 1997 20:17:06 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Open issues in the message draft
Sender: [email-masked]

Jamie Zawinski <[email-masked]> said:
>> If a sending agent is composing a signed message to a group of recipients
>> where the encrypting capabilities of some of the recipients are different,
>
>Might it be better to say "do not overlap" rather than "are different"?

Yes it might! Thanks for the suggestion.

At 7:58 PM -0700 9/18/97, Blake Ramsdell wrote:

>> If a sending agent is composing a signed message to a group of recipients
>>. . .
>
>I think this should be "If a sending agent is composing *an encrypted*
>message".

Er, yes, of course. <whoops!>

>I think also that this should be called out a little more clearly,
>because it is not an obvious problem and it really can affect the system
>security depending on the environment.  Along the lines of all caps,
>maybe?

Nope, we don't do that. We get thrown out of Tech Writers University if we
use all caps for anything except legal disclaimers and acronyms. Instead,
we use clear, concise, and exciting wording. When we cheat, we use
repetition.  :-) I'll add a paragraph that says almost the same thing to
the Security section to emphasize the point.

--Paul E. Hoffman, Director
--Internet Mail Consortium

From: "Blake Ramsdell" <[email-masked]>
To: "'Paul Hoffman / IMC'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Open issues in the message draft
Date: Thu, 18 Sep 1997 19:58:36 -0700
Sender: [email-masked]

On Thursday, September 18, 1997 5:44 PM, Paul Hoffman / IMC
[SMTP:[email-masked]] wrote:
> OK, this makes more sense now. Because a single message can only use one
> encryption algorithm, I believe that there is no protocol question.
> However, we can give implementors guidance. How does the following sound?

To clarify, a single envelopedData entity can only use one symmetric
encryption algorithm.

> If a sending agent is composing a signed message to a group of recipients
> where the encrypting capabilities of some of the recipients are different,
> the sending agent is forced to send more than one message. It should be
> noted that if the sending agent chooses to send a message encrypted with a
> strong algorithm, and then send the same message encrypted with a weak
> algorithm, someone watching the communications channel can decipher the
> contents of the strongly-encrypted message simply by decrypting the
> weakly-encrypted message.

I think this should be "If a sending agent is composing *an encrypted*
message".

I think also that this should be called out a little more clearly,
because it is not an obvious problem and it really can affect the system
security depending on the environment.  Along the lines of all caps,
maybe?

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

Date: Thu, 18 Sep 1997 17:44:05 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: Open issues in the message draft
Sender: [email-masked]

OK, this makes more sense now. Because a single message can only use one
encryption algorithm, I believe that there is no protocol question.
However, we can give implementors guidance. How does the following sound?

If a sending agent is composing a signed message to a group of recipients
where the encrypting capabilities of some of the recipients are different,
the sending agent is forced to send more than one message. It should be
noted that if the sending agent chooses to send a message encrypted with a
strong algorithm, and then send the same message encrypted with a weak
algorithm, someone watching the communications channel can decipher the
contents of the strongly-encrypted message simply by decrypting the
weakly-encrypted message.

--Paul E. Hoffman, Director
--Internet Mail Consortium

From: "Blake Ramsdell" <[email-masked]>
To: "'Paul Hoffman / IMC'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Open issues in the message draft
Date: Thu, 18 Sep 1997 16:27:29 -0700
Sender: [email-masked]

On Thursday, September 18, 1997 2:55 PM, Paul Hoffman / IMC
[SMTP:[email-masked]] wrote:
> I'm a tad confused about what you're asking. For encrypting, you have to
> create a different message for each recipient. The decision of what
> algorithm/strength to use is already being decided on a
> recipient-by-recipient basis. Am I missing something here?

Well, this is a little complicated for some senders that can't easily
spawn n messages when an algorithm conflict occurs (we are an add-in for
mail products, so spawning multiple messages and then tracking them is a
little bit difficult).  The options that we happen present right now
are: 1. Override the encryption algorithm (pick one), or 2. Remove the
offending recipients.  Granted that we aren't the mainstream case.

The concept of spawning multiple messages depending on the different
recipients encryption algorithms seems like a good idea at first, but
the problem is that the effective encryption strength for all of the
messages is the strength of the weakest algorithm sent.  This may not be
an issue for some environments, but it needs to be considered.

I can write up language for this, if there is interest.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

Date: Thu, 18 Sep 1997 14:55:04 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Open issues in the message draft
Sender: [email-masked]

At 11:37 AM -0700 9/18/97, David Solo wrote:
>>I don't think we need to address this in the document. Instead, we should
>>discuss this more on the mailing list, and add the desired profiles (if
>>any) to the OIDs list that is separate from the document. That way, if we
>>think of other profiles later, we can add them at will.
>
>I'm not sure it falls into this category, but part of the discussion dealt
>with the issue of "suites".  In some cases (especially where hardware tokens
>are involved) all possible combinations of digest, signature, encryption,
>and keymgmt algs may not work - consequently, capabilities need to express
>and handle combinations/suites.

Precisely. Such a "suite" (or "profile") could be defined to mean
"elliptical curve for key exchange, ElGamal for signature, and rot13 for
encryption". That would get a single OID that would define what it means.

>The other facet of this is what to do when encrypting a message for multiple
>recipients with different capabilities - in particular a case when some
>recipients handle only weak encryption.  Should an implementation take the
>"lowest common denominator", send multiple messages, exclude weak-only
>recipients, engage the sender?

I'm a tad confused about what you're asking. For encrypting, you have to
create a different message for each recipient. The decision of what
algorithm/strength to use is already being decided on a
recipient-by-recipient basis. Am I missing something here?

--Paul E. Hoffman, Director
--Internet Mail Consortium

Date: Thu, 18 Sep 1997 14:37:54 -0400
To: Paul Hoffman / IMC <[email-masked]>, [email-masked]
From: David Solo <[email-masked]>
Subject: Re: Open issues in the message draft
Sender: [email-masked]

Paul,

At 08:32 PM 9/16/97 -0700, Paul Hoffman / IMC wrote:
>Greetings, all. During the S/MIME developers' meeting last week, we
>discussed the open issues on the S/MIME message draft. We deferred
>discussion of the cert draft until a special session last Friday, and there
>will be a report about that in a few days.
>
>Below is what people brought up as open issues. I've commented on what I
>think the resolution for some of them should be, but all are open for
>discussion.
>
>** adding "no substitutions" profiles to SMIMECapabilities **
>
>Right now, there is no way to say "anything you send me must match the
>following capabilites"; instead, capabilities are suggestions, and are not
>necessarily complete lists. There was a desire to add definitive profiles
>that restricted clients could send out.
>
>I don't think we need to address this in the document. Instead, we should
>discuss this more on the mailing list, and add the desired profiles (if
>any) to the OIDs list that is separate from the document. That way, if we
>think of other profiles later, we can add them at will.

I'm not sure it falls into this category, but part of the discussion dealt
with the issue of "suites".  In some cases (especially where hardware tokens
are involved) all possible combinations of digest, signature, encryption,
and keymgmt algs may not work - consequently, capabilities need to express
and handle combinations/suites.

>** chosing an signing algorithm if there are multiple recipients **
>
>We never explicitly tell people what to do if a sender is trying to sign
>for multiple recipients. I propose we add:
>
>If a sending agent is composing a signed message to a group of recipients
>where the S/MIME capabilities of some of the recipients are not known, the
>agent MUST use SHA-1 for the DigestAlgorithmIdentifier, rsaEncryption for
>the DigestEncryptionAlgorithmIdentifier and
>KeyEncryptionAlgorithmIdentifier, and multipart/signed for the MIME
>encapsulation.
>
The other facet of this is what to do when encrypting a message for multiple
recipients with different capabilities - in particular a case when some
recipients handle only weak encryption.  Should an implementation take the
"lowest common denominator", send multiple messages, exclude weak-only
recipients, engage the sender?

Dave

To: [email-masked]
From: "Roger Fajman" <[email-masked]>
Date:     Wed, 17 Sep 1997  20:33:20 EDT
Subject:  Re:  Signing time format
Sender: [email-masked]

> PKIX says 2050.  I say we go with that.

It makes sense to coordinate with PKIX, but why does PKIX say 2050?
2090 would make a lot more sense, as no certificates existed before
1990.  Or, perhaps the Year2000 WG will choose a common number for
all Internet protocols.  In that case, something like 2060 might
make sense.

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "'Russ Housley'" <[email-masked]>, Paul Hoffman / IMC <[email-masked]>
Cc: [email-masked]
Subject: RE: Signing time format
Date: Wed, 17 Sep 1997 17:07:45 -0700
Sender: [email-masked]

If that is really what PKIX is doing, then I agree it makes sense.

> -----Original Message-----
> From:	Russ Housley [SMTP:[email-masked]]
> Sent:	Wednesday, September 17, 1997 2:53 PM
> To:	Paul Hoffman / IMC
> Cc:	[email-masked]
> Subject:	RE: Signing time format
> 
> PKIX is using 2050 as the cut-over year.  I think S/MIME should use
> the same.
> 
> Russ
> 
> At 02:15 PM 9/17/97 -0700, Paul Hoffman / IMC wrote:
> >At 2:14 PM -0700 9/17/97, Jim Schaad (Exchange) wrote:
> >>I would suggest that we want to use the same cut over time as is
> used by
> >>X509 certificates -- that is 2015 rather than the end of this time
> zone.
> >
> >Hmmm. I'd rather stick with whatever they're doing in PKIX, since
> we're
> >going to be putting our signatures in PKIX-style certs, not generic
> X.509
> >certs. What do others think?
> >
> >--Paul E. Hoffman, Director
> >--Internet Mail Consortium
> >
> >

Date: Wed, 17 Sep 1997 17:03:48 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: S/MIME trademark clarifications
Sender: [email-masked]

At 4:11 PM -0700 9/17/97, Steve Dusse wrote:
>>I have just been informed by our legal department that RSA Data Security,
>>Inc. does not own a trademark on the name "S/MIME".  Any representations to
>>that effect in the past were in error and will be updated.

I think I can update this in the next draft. It's called "removing the
text". :-)

This is very good (and a tad shocking) news, Steve. For those of you
following the discussion on us forming a Working Group, this should
defintely make it easier since the now-nonexistant trademark was a big
point of contention.

--Paul E. Hoffman, Director
--Internet Mail Consortium

Date: Wed, 17 Sep 1997 16:42:03 -0700
From: [email-masked] (Jeff Weinstein)
To: Paul Hoffman / IMC <[email-masked]>
CC: [email-masked]
Subject: Re: Signing time format
Sender: [email-masked]

PKIX says 2050.  I say we go with that.

	--Jeff

Paul Hoffman / IMC wrote:
> 
> At 2:14 PM -0700 9/17/97, Jim Schaad (Exchange) wrote:
> >I would suggest that we want to use the same cut over time as is used by
> >X509 certificates -- that is 2015 rather than the end of this time zone.
> 
> Hmmm. I'd rather stick with whatever they're doing in PKIX, since we're
> going to be putting our signatures in PKIX-style certs, not generic X.509
> certs. What do others think?
> 
> --Paul E. Hoffman, Director
> --Internet Mail Consortium

From: Steve Dusse <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: S/MIME trademark clarifications
Date: Wed, 17 Sep 1997 16:11:39 -0700
Sender: [email-masked]

>Howdy,
>
>I have just been informed by our legal department that RSA Data Security,
>Inc. does not own a trademark on the name "S/MIME".  Any representations to
>that effect in the past were in error and will be updated.  Rather, RSA does
>claim trademark rights to its logo using the S/MIME acronym which is used to
>connote interoperable use of the RSA technology and products according to the
>current specs.
>
>Cheers,
>Steve Dusse
>CTO
>RSA
>

Date: Wed, 17 Sep 1997 15:57:24 -0700
From: Jeff Thompson <[email-masked]>
To: Paul Hoffman / IMC <[email-masked]>
CC: [email-masked]
Subject: Re: Signing time format
Sender: [email-masked]

Paul Hoffman / IMC wrote:
> 
> At 2:14 PM -0700 9/17/97, Jim Schaad (Exchange) wrote:
> >I would suggest that we want to use the same cut over time as is used by
> >X509 certificates -- that is 2015 rather than the end of this time zone.
> 
> Hmmm. I'd rather stick with whatever they're doing in PKIX, since we're
> going to be putting our signatures in PKIX-style certs, not generic X.509
> certs. What do others think?

Fine.  Does this include CRLs also?

Date: Wed, 17 Sep 1997 17:53:03 -0400
To: Paul Hoffman / IMC <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: Signing time format
Cc: [email-masked]
Sender: [email-masked]

PKIX is using 2050 as the cut-over year.  I think S/MIME should use the same.

Russ

At 02:15 PM 9/17/97 -0700, Paul Hoffman / IMC wrote:
>At 2:14 PM -0700 9/17/97, Jim Schaad (Exchange) wrote:
>>I would suggest that we want to use the same cut over time as is used by
>>X509 certificates -- that is 2015 rather than the end of this time zone.
>
>Hmmm. I'd rather stick with whatever they're doing in PKIX, since we're
>going to be putting our signatures in PKIX-style certs, not generic X.509
>certs. What do others think?
>
>--Paul E. Hoffman, Director
>--Internet Mail Consortium
>
>

From: Steve Dusse <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Signing time format
Date: Wed, 17 Sep 1997 14:53:18 -0700
Sender: [email-masked]

Ditto.

-steve

>----------
>From: 	Paul Hoffman / IMC[SMTP:[email-masked]]
>Sent: 	Wednesday, September 17, 1997 2:15 PM
>To: 	[email-masked]
>Subject: 	RE: Signing time format
>
>At 2:14 PM -0700 9/17/97, Jim Schaad (Exchange) wrote:
>>I would suggest that we want to use the same cut over time as is used by
>>X509 certificates -- that is 2015 rather than the end of this time zone.
>
>Hmmm. I'd rather stick with whatever they're doing in PKIX, since we're
>going to be putting our signatures in PKIX-style certs, not generic X.509
>certs. What do others think?
>
>--Paul E. Hoffman, Director
>--Internet Mail Consortium
>
>
>

Date: Wed, 17 Sep 1997 14:15:40 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: Signing time format
Sender: [email-masked]

At 2:14 PM -0700 9/17/97, Jim Schaad (Exchange) wrote:
>I would suggest that we want to use the same cut over time as is used by
>X509 certificates -- that is 2015 rather than the end of this time zone.

Hmmm. I'd rather stick with whatever they're doing in PKIX, since we're
going to be putting our signatures in PKIX-style certs, not generic X.509
certs. What do others think?

--Paul E. Hoffman, Director
--Internet Mail Consortium

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "'Blake Ramsdell'" <[email-masked]>, "'Paul Hoffman / IMC'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Signing time format
Date: Wed, 17 Sep 1997 14:14:23 -0700
Sender: [email-masked]

I would suggest that we want to use the same cut over time as is used by
X509 certificates -- that is 2015 rather than the end of this time zone.

> -----Original Message-----
> From:	Blake Ramsdell [SMTP:[email-masked]]
> Sent:	Wednesday, September 17, 1997 12:14 AM
> To:	'Paul Hoffman / IMC'; [email-masked]'
> Subject:	Signing time format
> 
> On Tuesday, September 16, 1997 8:33 PM, Paul Hoffman / IMC
> [SMTP:[email-masked]] wrote:
> > ** signing time**
> > 
> > Currently, signing time in 2.5.1 says it must be UTCTime, which is
> not Year
> > 2000 compliant. (Can we all say "duh"?) The proposed solution is to
> use the
> > same method that PKIX part 1 does for certificates. I propose that
> the
> > wording in our draft be:
> > 
> > Sending agenst shall always encode signing time through the year
> 2049 as
> > UTCTime; signing times in 2050 or later shall be encoded as
> GeneralizedTime.
> 
> We should also clarify when you should add 1900 to the year digits for
> UTCTime, and at when you should add 2000.
> 
> The wording from PKIX part 1 for UTCTime (from section 4.1.2.5.1) is:
> 
> Conforming systems shall interpret the year field (YY) as follows:
> 
> Where YY is greater than or equal to 50, the year shall be interpreted
> as 19YY; and
> 
> Where YY is less than 50, the year shall be interpreted as 20YY.
> 
> Blake
> --
> Blake C. Ramsdell
> Worldtalk Corporation
> For current info, check http://www.deming.com/users/blaker
> Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: "Bruce J Kelley" <[email-masked]>
To: "Paul Hoffman / IMC" <[email-masked]>, <[email-masked]>
Subject: RE: Open issues in the message draft
Date: Wed, 17 Sep 1997 11:39:45 -0700
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_014A_01BCC35E.652D9700
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

From:   Paul Hoffman / IMC [SMTP:[email-masked]]=20
   =20
    ** signedData vs. application/mime wording**=20
   =20
    Section 3 talks a lot about what to do if the sender thinks that a =
signed=20
    message will go through a gateway that will separate or change the =
message.=20
    This has long been a contentious issue. Of the three implementations =
I know=20
    of, Microsoft and Netscape never use either of the two protection=20
    alternatives, and Deming will only send out signedData (I think).=20
   =20
    Minor correction: Microsoft's Outlook Express allows the user to =
chose between multipart/signed and application/signedData through a =
configuration option.

- Bruce Kelley - Microsoft Outlook Express S/MIME developement=20

------=_NextPart_000_014A_01BCC35E.652D9700
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.71.1712.3"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><EM><FONT color=3D#000080 size=3D2>
<UL>
    <P><B><FONT face=3DArial size=3D1>From:&nbsp;&nbsp;</FONT></B> <FONT =
face=3DArial=20
    size=3D1>Paul Hoffman / IMC [SMTP:[email-masked]]</FONT> </P>
    <P><FONT color=3D#000000 face=3DArial size=3D2>** signedData vs. =
application/mime=20
    wording**</FONT> </P>
    <P><FONT color=3D#000000 face=3DArial size=3D2>Section 3 talks a lot =
about what to=20
    do if the sender thinks that a signed</FONT> <BR><FONT =
color=3D#000000=20
    face=3DArial size=3D2>message will go through a gateway that will =
separate or=20
    change the message.</FONT> <BR><FONT color=3D#000000 face=3DArial =
size=3D2>This=20
    has long been a contentious issue. Of the three implementations I=20
    know</FONT> <BR><FONT color=3D#000000 face=3DArial size=3D2>of, =
Microsoft and=20
    Netscape never use either of the two protection</FONT> <BR><FONT=20
    color=3D#000000 face=3DArial size=3D2>alternatives, and Deming will =
only send out=20
    signedData (I think).</FONT> </P></UL>
<P><I><FONT color=3D#0000ff face=3DArial size=3D2>Minor correction: =
Microsoft's=20
Outlook Express allows the user to chose between multipart/signed and=20
application/signedData through a configuration option.</FONT></I></P>
<P><I><B><FONT color=3D#0000ff face=3DArial size=3D2>- Bruce Kelley - =
Microsoft=20
Outlook Express S/MIME developement</FONT></B></I>=20
</P></FONT></EM></DIV></BODY></HTML>

------=_NextPart_000_014A_01BCC35E.652D9700--

Date: Wed, 17 Sep 1997 08:12:31 -0700
To: "Blake Ramsdell" <[email-masked]>, "[email-masked]'"  <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Signing time format
Sender: [email-masked]

At 12:14 AM -0700 9/17/97, Blake Ramsdell wrote:
>Conforming systems shall interpret the year field (YY) as follows:
>
>Where YY is greater than or equal to 50, the year shall be interpreted
>as 19YY; and
>
>Where YY is less than 50, the year shall be interpreted as 20YY.

Sounds like good additions to me.

--Paul E. Hoffman, Director
--Internet Mail Consortium

From: "Blake Ramsdell" <[email-masked]>
To: "'Paul Hoffman / IMC'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Signing time format
Date: Wed, 17 Sep 1997 00:14:27 -0700
Sender: [email-masked]

On Tuesday, September 16, 1997 8:33 PM, Paul Hoffman / IMC
[SMTP:[email-masked]] wrote:
> ** signing time**
> 
> Currently, signing time in 2.5.1 says it must be UTCTime, which is not Year
> 2000 compliant. (Can we all say "duh"?) The proposed solution is to use the
> same method that PKIX part 1 does for certificates. I propose that the
> wording in our draft be:
> 
> Sending agenst shall always encode signing time through the year 2049 as
> UTCTime; signing times in 2050 or later shall be encoded as GeneralizedTime.

We should also clarify when you should add 1900 to the year digits for
UTCTime, and at when you should add 2000.

The wording from PKIX part 1 for UTCTime (from section 4.1.2.5.1) is:

Conforming systems shall interpret the year field (YY) as follows:

Where YY is greater than or equal to 50, the year shall be interpreted
as 19YY; and

Where YY is less than 50, the year shall be interpreted as 20YY.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

Date: Tue, 16 Sep 1997 20:32:33 -0700
To: ietf-smime
From: Paul Hoffman / IMC <[email-masked]>
Subject: Open issues in the message draft
Sender: [email-masked]

Greetings, all. During the S/MIME developers' meeting last week, we
discussed the open issues on the S/MIME message draft. We deferred
discussion of the cert draft until a special session last Friday, and there
will be a report about that in a few days.

Below is what people brought up as open issues. I've commented on what I
think the resolution for some of them should be, but all are open for
discussion.

** signedData vs. application/mime wording**

Section 3 talks a lot about what to do if the sender thinks that a signed
message will go through a gateway that will separate or change the message.
This has long been a contentious issue. Of the three implementations I know
of, Microsoft and Netscape never use either of the two protection
alternatives, and Deming will only send out signedData (I think).

My proposal, which wasn't all that well received, was that we move the
whole discussion to a short appendix that covers just what the two options
are, the brief advantages and disadvantages of each, says that as of today
no one has tested application/mime, says that receiving agents SHOULD
accept both, and you make your own decision. This does describe what the
current practice is, so it's an honest approach. It also lets implementors
figure out what works best for them. Let's remember that this a very
transport-related issue for a protocol that is supposed to be
transport-independent.

If you have a different idea of how to deal with the issue, please speak up!

** signing time**

Currently, signing time in 2.5.1 says it must be UTCTime, which is not Year
2000 compliant. (Can we all say "duh"?) The proposed solution is to use the
same method that PKIX part 1 does for certificates. I propose that the
wording in our draft be:

Sending agenst shall always encode signing time through the year 2049 as
UTCTime; signing times in 2050 or later shall be encoded as GeneralizedTime.

** adding a "doesn't accept encryption" SMIMECapabilities **

Some not-quite-S/MIME agents can only send and receive signed messages, not
encrypted ones, due to legal and technical reasons. It was generally agreed
that we should add an attribute to SMIMECapabilities that indicates that
the recipient can't decrypt any kind of message.

I propose adding the following to the "Miscellaneous" parameters:

canNotDecryptAny OBJECT IDENTIFIER ::=
    {iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-9(9)
        SMIMECapabilities(15) 2}
        (No parameters. In the event that this OID is present, then every
        effort should be made not to send this recipient any encrypted
        message.)

** adding "no substitutions" profiles to SMIMECapabilities **

Right now, there is no way to say "anything you send me must match the
following capabilites"; instead, capabilities are suggestions, and are not
necessarily complete lists. There was a desire to add definitive profiles
that restricted clients could send out.

I don't think we need to address this in the document. Instead, we should
discuss this more on the mailing list, and add the desired profiles (if
any) to the OIDs list that is separate from the document. That way, if we
think of other profiles later, we can add them at will.

** change "handle and display" to "handle" **

It was pointed ouot that some places in the document, we tell agents to
"display" things. Of course, not all agents can display. I've changed all
instances of "handle and display" to "handle".

** chosing an signing algorithm if there are multiple recipients **

We never explicitly tell people what to do if a sender is trying to sign
for multiple recipients. I propose we add:

If a sending agent is composing a signed message to a group of recipients
where the S/MIME capabilities of some of the recipients are not known, the
agent MUST use SHA-1 for the DigestAlgorithmIdentifier, rsaEncryption for
the DigestEncryptionAlgorithmIdentifier and
KeyEncryptionAlgorithmIdentifier, and multipart/signed for the MIME
encapsulation.

** signed content inside of envelopedData **

There was a question about whether we should recommend that if a message is
going to be signed then encrypted, the signed message should use signedData
since it is known that the recipient must have S/MIME. However, many
recipient systems are multi-staged cryptography engines, and it is not
always the case that the same system that decrypted the message will be
checking the signature. I think 3.5 says enough about this, but am open to
suggestions on additional wording.

--Paul E. Hoffman, Director
--Internet Mail Consortium

Date: Sat, 13 Sep 1997 11:02:43 -0700 (PDT)
To: [email-masked], ietf-smime
From: [email-masked]
Subject: Welcome to ietf-smime
Reply-To: [email-masked]
Sender: [email-masked]

--

Welcome to the ietf-smime mailing list!

Please save this message for future reference.  Thank you.

If you ever want to remove yourself from this mailing list,
you can send mail to <[email-masked]> with the following
command in the body of your email message:

    unsubscribe ietf-smime [email-masked] ietf-smime

 Here's the general information for the list you've subscribed to,
 in case you don't already have it:

The ietf-smime mailing list discusses sending MIME messages in an
interoperable, secure fashion using S/MIME. The mailing list is currently an
IETF BOF, but the intention is to have the work become an IETF Working
Group.

To see what has gone on before you subscribed, please see the mailing
list archive at
  http://www.imc.org/ietf-smime/

To unsubscribe from the ietf-smime mailing list, send a message to:
  [email-masked]
with the message:
  unsubscribe

If you need to contact a human about this mailing list, please
send a message to:
  [email-masked]

From: "Blake Ramsdell" <[email-masked]>
To: "'Kazu Yamamoto'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Is 7bit restriction to signature practical?
Date: Fri, 12 Sep 1997 13:30:44 -0700
Sender: [email-masked]

On Thursday, September 11, 1997 7:49 PM, Kazu Yamamoto
[SMTP:[email-masked]] wrote:
> Do other UA implementors agree that this MIME requirement is
> reasonable and practical to you?

I personally think it's reasonable, just because of the reality of the
situation.  I don't think it's practical, but practicality is a
secondary goal to compatibility which would be sacrificed in this
particular case.

The fact is that a message will have to travel over an arbitrary path to
its destination.  When sending a signed message, all of the things along
that path need to be able to pass the signed part along completely
intact without modification (in order for the signature to be valid).
In a pure Internet environment, it seems that you might encounter 8bit
friendly and 8bit, uh, unfriendly hops.  If the original data is
multipart/signed with 8bit inside, an intermediate 7bit-only hop can do
a bunch of things:

1. Puke.  Forget to analyze the incoming content and it ends up broken
when it comes out (8bit data over 7bit transport)
2. Convert the offending 8bit stuff to QP or some other effectively 7bit
CTE (breaking the signature)
3. Understand that the message is multipart/signed, and bounce it
because it knows that it will be smashing the signature in the event
that it changes the CTE for any of the content.
4. Perform step 2 and remove the signature.

I think that 1 and 2 are the current mode of operation.  Ned has
consistently argued that we should put some language somewhere to
address this, since the lack of MTA / gateway language is what is
causing some of the current problems (including the one you are pointing
out, I believe) with multipart/signed.  I believe that discussing this
more is a good idea, despite any previous comments that may have
indicated the contrary.

So the bottom line on how to fix this is to come up with gateway / MTA
specific language about how to deal with multipart/signed.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

Date: Fri, 12 Sep 1997 12:20:25 -0700
From: "Anil R. Gangolli" <[email-masked]>
Reply-To: [email-masked]
Organization: Structured Arts Consulting Group
To: [email-masked]
Subject: comments on certs portion of draft
Sender: [email-masked]

Here are some terse comments on the Certs portion of the current
drafts after my first cursory reading.

I will be going to the meeting today, but I wanted to get this
off to the list.  

Here are some comments on draft-dusse-smime-cert-02.txt

I would be happy to assist in rewriting relevant sections.

Section 1.1

X.208 is basically the dead spec of ASN.1.  Use the
living version X.680, 681, 682, 683.

Similarly for BER/DER/CER please refer to X.690.

Probably good to include the ISO/IEC standard numbers as well rather
than just the ITU-T X.nn recommendation numbers.  Everyone knows them
by the ITU-T X.nn numbers of course.

Section 2.1

For CRL you should use the X.509 v1 and v2 CRL definitions.
The [KEYM] (PEM RFC 142<n>) definition is inconsistent in an important
aspect.  The nextUpdate field is incorrectly specified as
mandatory.  In the X.509 spec it is OPTIONAL.  

I recommend the following approach to avoid
problems,

One MUST accept the syntax in the OPTIONAL form as specified
in X.509 v1.

One SHOULD generate it with the nextUpdate field present.

This affects other mentions of the CRL format throughout the
document.

Also, here is another place where UTCTime is used.  The recent
X.509 work has been keeping step with PKIX to get similar
CHOICE/GeneralizedTime wording in.  It is important to
incorporate this by reference as well.

In summary, please stop referring to the PEM RFCs for X.509
related stuff.

Section 2.3

You should probably allow for implementation-defined limits on
"arbitrary number of certificates" to be conformant.

In a number of instances in the document, the Section 4.2
requirement for a sender to verify a recipient's certificate 
is not properly accounted for;  that is,  there are cases where
certificate verification is discussed only in the context of
"receiving agents."  The doc needs to be re-scanned for this
issue and fixed.

Section 3.1

Description of distinguished names is inaccurate.  RDNs are
conceptually labels on the edges of a tree, not on the nodes.
The entire DN is an ordered sequence and not a "collection."
Yes, it specifies a path to a directory object.

The type AVA in RDNs has been replaced with a type ATV
(Attribute Type and Value) that is of the same syntax but
has different semantics.

Most of the discussion of X.500 should either be replaced by or
accompanied by references to LDAP, and the LDAP RFCs.

Section 3.2

>From the security perspective, I recommend that the certificate MUST
include the subject's RFC 822 address, and that this not be left to
some external mapping. 

The working group needs to specify (and coordinate with PKIX --current
discussion is occurring) a set of possible places in the cert among
which
this MUST be and recommend where it SHOULD be specified.

Note that because there is an interest in using DNs in certs in
conjunction with LDAP and X.500, that there is a desire within
PKIX to put the RFC 822 address in an alternate names extension.
However there is a recognition that current secure e-mail
implementations are using PKCS-9 EMailAddress in the DN.

The document says "Sending agents SHOULD include the Internet
Mail Address during Distinguished Name creation."  Note in general,
that CAs have final determination of DN content in certs, regardless of
what appears in any certificate request.

Section 4.

Certificate Processing should refer to the PKIX verification procedure
and interpretation of the extensions.

Section 4.1

First paragraph.  Sending and Receiving agents.  Sending agents
do verification too!

Suggest that we remove sentence on "it is always better to get the
latest
information from the CA".  This is true from the security perspective,
not necessarily from the perspective of network load and scaleability.

Section 4.4

This is out of date.  Important omissions are AuthorityKeyIdentifier
and SubjectKeyIdentifier.  This affects some Section 5 discussions as
well.

Section 5.1

Paragraph 3.  Inaccurate since implementations are required to
disambiguate based issuer+serial.  Right?

Paragraph 4.  Inaccurate.  You must account for key change/rollover.
Disambiguation of issuer certs when chain-building is handled by use of
AuthorityKeyIdentifier/SubjectKeyIdentifier usage.

Section 5.2

UNIVERSAL STRING is already an ISO ASN.1 type.  So is BMPString now.

Use of T61String is deprecated amongst implementers but still in
the syntax.

The CHOICE should be 
PrintableString
T61String
BMPString
UNIVERSAL STRING

Occurrences of this CHOICE should probably be changed to refer to
the X.520 type DirectoryString, so that we "keep up" by reference
with cert and dir practices.

A paragraph may be desirable regarding encoding of untyped character
strings into these choices, following the current implementation 
practice of "using the simplest choice that fits" strategy.

The phrase "this attribute may hae multiple attribute values"
is confusing in this context because it applies primarily to
directoy objects.  Here is where the semantics of ATVs and
AVAs is separate.

-- 
Anil R. Gangolli
Structured Arts Consulting Group
mailto:[email-masked]
http://www.StructuredArts.com

From: [email-masked]
X400-Received: by mta switchgate.switch.ch in /ADMD=SWITCHgate/C=ch/; Relayed; Fri, 12 Sep 1997 15:14:12 +0200
X400-Received: by mta UNIWORLD-SAT05 in /ADMD=SWITCHHOP/C=CH/; Relayed; Fri, 12 Sep 1997 15:15:23 +0200
X400-Received: by /ADMD=400NET/C=NL/; Relayed; Fri, 12 Sep 1997 15:13:57 +0200
X400-Received: by /ADMD=400NET/C=SE/; Relayed; Fri, 12 Sep 1997 15:13:56 +0200
Date: Fri, 12 Sep 1997 15:13:56 +0200
X400-Originator: [email-masked]
X400-Recipients: non-disclosure:;
X400-MTS-Identifier: [/ADMD=400NET/C=SE/;MHSP25MHBB R0021000874070035458]
Original-Encoded-Information-Types: teletex
X400-Content-Type: P2-1984 (2)
To: [email-masked] (Non Receipt Notification Requested)
Subject: Mixed comments on smime-cert-02
Sender: [email-masked]

=0D=0CSome comments on draft-dusse-smime-cert-02.txt

The spec. is defined as the solution in the first paragraph of clause =

1. I see it as a solution, current praxis. The last sentence should =

read: "This draft describes a mechanisms S/MIME uses can use to =

create and validate keys using certificates."

In clause 4.4 are we referencing the draft X.509 v3 and the =

corresponding ISO/IEC 9594-8 amendment. These are now approved as a =

1997 publication, which we should refer to in appendix B. The notion =

of the Amendment could be kept in appendix B for convenience to =

readers, if it is believed to be useful.

There are MUST statements on CAs in clause 5.2. I do not believe that =

this spec. can enforce any CA policy. Change it to a SHOULD.

The following type of statements are copied from PKCS?9 in clauses =

5.2.1, 5.2.2 and 5.2.3 :
"It is expected that if UCS becomes an ASN.1 type (e.g., UNIVERSAL =

STRING), UnstructuredAddress will become a CHOICE type: =

UnstructuredAddress ::=3D CHOICE ?
    PrintableString, T61String, UNIVERSAL STRING ?"

UCS (which obviously :) should be understood as ISO 10646) has been =

approved and I expect us to only keep the CHOICE including the =

UNIVERSAL STRING.

Clauses 5.2.2 and 5.2.3 speaks about "PKCS ?6 extended certificates". =

The use of them are excluded according to 2.2.1, remove the =

references.

I would like a different approach in the second paragraph of clause =

6. =

a) If the cert. verification fails, present data with warning.
b) If the signature verification fails, present data with BIG warning =

or at least make data available by out of band means.

In appendix D - Revision History, it is stated "Removed [PEM] =

reference" but we still have MUST requirements on RFC 1422. What was =

the intention?

/Bengt Ackzell

To: [email-masked]
Subject: Re: some typological errors
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[email-masked]>
Date: Fri, 12 Sep 1997 12:44:20 +0900
Lines: 36
Sender: [email-masked]

From: Ned Freed <[email-masked]>
Subject: Re: some typological errors
Date: Thu, 11 Sep 1997 19:18:46 -0700 (PDT)

> Well, all I can is that you're wrong. Both base64 and quoted-printable are
> designed to be 100% invertible and loss-free. If you have a problem with
> quoted-printable it is because of bugs in your MIME implementation.

I know QP is loss-free if it is implemented correctly. But I'm not a
discussing generic case but the example in 3.1.4 of the new S/MIME
draft and a paragraph of RFC 2015.

Quoted from RFC 2015.

   Though not required, it is generally a good idea to use Quoted-
   Printable encoding in the first step (writing out the data to be
   signed in MIME canonical format) if any of the lines in the data
   begin with "From ", and encode the "F".  This will avoid an MTA
   inserting a ">" in front of the line, thus invalidating the
   signature!

If this step is applied to ISO 2022 text carelessly(e.g ASCII part of
"From " is encoded but ISO 2022 part of "=" is not encoded), ISO 2022
text encoded with QP might not be decoded.

My point is that the example IS confusing. I think, to avoid
misunderstanding, some notes are necessary. 

All in all, QP is not efficient, in Ned's word, to ISO 2022.

> I've had this noted as something to fix in the
> next revision of RFC1847 for quite some time now.  

Thank you, Ned. I'm waiting for the revision.

--Kazu

To: [email-masked], [email-masked]
Subject: Re: Is 7bit restriction to signature practical?
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[email-masked]>
Date: Fri, 12 Sep 1997 11:48:42 +0900
Lines: 15
Sender: [email-masked]

From: Ned Freed <[email-masked]>
Subject: Re: Is 7bit restriction to signature practical?
Date: Wed, 10 Sep 1997 22:30:02 -0700 (PDT)

> > I guess many implementations just include messages when forwarded.
> 
> My various agents certainly do not. Again, this has nothing to do with
> multipart/signed per se; it is just a basic part of MIME functionality.

Do other UA implementors agree that this MIME requirement is
reasonable and practical to you?

I will implement if other implementors agree with it.

--Kazu

Date: Thu, 11 Sep 1997 19:18:46 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: some typological errors
To: Kazu Yamamoto <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> > That should not matter at all.  Transfer encoding is completely orthogonal
> > to character sets.

> I don't think so. Each charset has its own proper MIME encoding.

Well, all I can is that you're wrong. Both base64 and quoted-printable are
designed to be 100% invertible and loss-free. If you have a problem with
quoted-printable it is because of bugs in your MIME implementation.

Now, it is indeed true that one encoding can work better than another. For one
thing, quoted-printable can be a lot more efficient than base64 sometimes. And
in other cases it is far less efficient. There are also still cases, albeit
very rare ones now, where the transport infrastructure is weak and you'd be
well advised not to stress it with the character repetiore quoted-printable
employs. And there are instances of incomplete MIME support where one
decoder is available but not the other.

> > Before any 2022 interpretation is done all the QP
> > encoding will be removed. All it will see is "From ".

> The difference between Base64 and QP is whether or not *partial*
> encoding is possible. QP is possible and Base64 is not. If ISO 2022
> text is encoded with QP partially(e.g. only spaces in ASCII part),
> it is likely that encoded ISO 2022 cannot be decoded. This is real.
> Experience says that QP is not suitable for ISO 2022 family.

I'm sorry, but I also have a fair amount of experience with using ISO-2022-JP
and ISO-2022-KR and have encountered no problems with using quoted-printable on
them that did not arise from broken MIME software. (In fact I cannot recall a
case where an ISO-2022-* charset was damaged by bad MIME software, but I have
seen instances of bad MIME software would damage most anything, ISO-2022-* 
included. But if this is considered to be an issue, how about the one fairly
popular gateway that rejects 7bit as an "invalid encoding"?)

> To my understanding, RFC 2045 says that values of MIME parameters are
> case sensitive in general. And I cannot find any sentence to define
> that the protocol parameter is case-insensitive in RFC 1847. If there
> is one, please tell me what page in which RFC.

This, at least, is correct -- parameter values are to be considered to be case
sensitive unless noted otherwise. RFC1847 should have noted that the value of
the protocol parameter is case-insensitive. I've had this noted as something to
fix in the next revision of RFC1847 for quite some time now.

				Ned

To: [email-masked]
Subject: Re: some typological errors
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[email-masked]>
Date: Fri, 12 Sep 1997 09:40:26 +0900
Lines: 48
Sender: [email-masked]

From: Laurence Lundblade <[email-masked]>
Subject: Re: some typological errors
Date: Thu, 11 Sep 1997 10:39:58 -0700

> That should not matter at all.  Transfer encoding is completely orthogonal
> to character sets. 

I don't think so. Each charset has its own proper MIME encoding.

> Before any 2022 interpretation is done all the QP
> encoding will be removed. All it will see is "From ".

The difference between Base64 and QP is whether or not *partial*
encoding is possible. QP is possible and Base64 is not. If ISO 2022
text is encoded with QP partially(e.g. only spaces in ASCII part),
it is likely that encoded ISO 2022 cannot be decoded. This is real.
Experience says that QP is not suitable for ISO 2022 family.

What I suggested is to clarify that technic found in RFC 2015 is
suitable for charsets whose proper encoding is QP.

> I believe this is covered by content-disposition and other. The file name
> is not so important here anyway as the main purpose is using the three
> letter extension as poor man's type information.

I have no experience for RFC 2148, however, I'm afraid that confusion
will occur due to three major charsets in Japan. 

If suffix is important, how about restricting filename to US-ASCII?
Please note that I don't know that this solution is the best.

> >(3) 3.4.2.2
> >
> >> The protocol parameter MUST be "application/pkcs7-signature". Note
> >> that quotation marks are required around the protocol parameter
> >> because MIME requires that the "/" character in the parameter value
> >> MUST be quoted.
> >
> >It's nice if you clarify that the value is case-insensitive.
> 
> That's covered by the MIME standard.

To my understanding, RFC 2045 says that values of MIME parameters are
case sensitive in general. And I cannot find any sentence to define
that the protocol parameter is case-insensitive in RFC 1847. If there
is one, please tell me what page in which RFC.

--Kazu

Date: Thu, 11 Sep 1997 19:11:02 +0100
From: Jeff Williams <[email-masked]>
Organization: IEG. INC.
To: Karen Rosenthal <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], Pedro Chiang <[email-masked]>
Subject: Re: S/MIME Developers Meeting
Sender: [email-masked]

Karen,

Karen Rosenthal wrote:
> 
> After returning from attendance at the S/MIME Developers Workshop
> yesterday (I feel somehow like I've been spun up in a tornado, and
> dumped back in exactly the same place) ...

  Welcome home Dorthy!  >;)
> 
> Issues of concern:
> 
> 1.  Will the current PKCS standards, along with the current dusse drafts
> be submitted as Informational RFCs as is, or not; and if so, is this
> submission, in light of desire to proceed along the true RFC standards
> track at a later time, problematic or not?

  My guess is problematic at this point.
> 
> >From an ediint perspective, I have a vested interest in seeing the
> current work gaining some sort of RFC status in the immediate future, as
> the ediint drafts reference the dusse drafts.  If an Informational RFC
> is a short term answer, and progression down the standards track, with a
> revised, and more functional version of S/MIME / PKCS in the future, so
> be it.  Dave Crocker gave the impression that submitting the same
> material for both Informational RFC status, and standards track, would
> be asking for trouble.

  I usually discount most of what Dave Crocker say anyway.  His 
reputation has definatly proceded him in several other venues.

>  I didn't know if this was in the context of
> submitting the SAME material (current dusse drafts, and PKCS#7 v1.5) for
> Informational RFC, and down the standards RFC track, or also included
> the case of having an essentially rewritten form (i.e. S/MIME V3, PKCS#7
> v2) go down the standards track.  If the former, great, but if the
> latter, I'd say, drop the Informational RFC quest, and push the
> standards track.

  I believe tht pushing for the standards track is the better
alternitive.
> 
> 2.  Could the current drafts even pass as Informational RFCs right now.

  Possibly some could with some cleaning up.  But what's the point
really?
> 
> Opinion on this seems to be pretty well split.  I echo Keith Dennis'
> concern voiced in his earlier message, that RSA's hold on rsaEncryption
> is a big problem, regardless of whether or not precedence has been set
> on this before, in the IETF decision making process.  I hope, being one
> of the skeptics, that I'm wrong...

  I to am one of the skeptics.  Seems that this process is following
the same type of policy wonking that the TLS process has run into
lately.
Dam shame too!
> 
> 3.  Moving forward...
> 
> Cutting to the chase ... S/MIME and MSP merge, and a completely revamped
> PKCS#7.  Great.  How long are we talking about to get these completed,
> and through the IETF process (or does the IETF process get dropped?).

  At this point, who knows?  

> We've got S/MIME product in the market place right now.  And our
> customers want standards compliant, interoperable products (the word
> "standards" used loosely - truly for "most" clients, standards compliant
> really does mean interoperable!!!), that, with all the current press,
> provide for DSS and DH, as well as RSA.  In asking the question, can
> S/MIME and PKCS#7 v1.5 support DSS and/or DH, I've gotten no details,
> but answers ranging the gambit from:
> 
>     a. can't be done
>     b. can be done as a hack
>     c. can be done, in a standards* compliant manner
>     d. we've done it

  Our answer is D.
> 
> (Could someone please technically prove any of the above?)

  What would you require?  I can provide some basic documentation
for our "Interface Facility" or MLPI if you care to except this?
> 
> Bottom line - we need to provide DSS and DH soon.  We need to know what
> our options are, and timelines.  Will we have the ability to implement
> them though our current product (current versions of S/MIME, PKCS)?  If
> not, has anyone ever considered making algorithm independence a sole
> modification to the existing smime draft to get it on standards track,
> quickly?  Or is supporting PGP as well, our answer...

  All the above is your answer IMHO.  others will say, "Can't be done".
But we are not others.  >;)
> 
> --
> Karen Rosenthal               Email: [email-masked]
> Premenos                      Tel#:  1-510-688-2928
> 1000 Burnett Ave              Fax#:  1-510-602-2133
> Concord, CA  94520            Visit: http://www.premenos.com

Regards,
-- 
Jeffrey A. Williams
DIR. Internet Network Eng/SR. Java Development Eng.
Information Eng. Group. IEG. INC. 
Phone :913-294-2375 (v-office)
E-Mail [email-masked]

To: Karen Rosenthal <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], Pedro Chiang <[email-masked]>
Subject: Re: S/MIME Developers Meeting
From: EKR <[email-masked]>
Date: 11 Sep 1997 15:50:19 -0700
Lines: 96
Sender: [email-masked]

Karen Rosenthal <[email-masked]> writes:
> Cutting to the chase ... S/MIME and MSP merge, and a completely revamped
> PKCS#7.  Great.  How long are we talking about to get these completed,
> and through the IETF process (or does the IETF process get dropped?).
> We've got S/MIME product in the market place right now.  And our
> customers want standards compliant, interoperable products (the word
> "standards" used loosely - truly for "most" clients, standards compliant
> really does mean interoperable!!!), that, with all the current press,
> provide for DSS and DH, as well as RSA.  In asking the question, can
> S/MIME and PKCS#7 v1.5 support DSS and/or DH, I've gotten no details,
> but answers ranging the gambit from:
> 
>     a. can't be done
>     b. can be done as a hack
>     c. can be done, in a standards* compliant manner
>     d. we've done it
> 
> (Could someone please technically prove any of the above?)
DSS is no substantial problem. The text and the ASN.1 
both refer to encrypting the message digest, which isn't how
DSS works, but it's still perfectly straightforward to
put the DSS signature in the EncryptedDigest field
in the SignerInfo. [1]

SignerInfo ::= SEQUENCE {
  version Version,
  issuerAndSerialNumber IssuerAndSerialNumber,
  digestAlgorithm DigestAlgorithmIdentifier,
  authenticatedAttributes
    [0] IMPLICIT Attributes OPTIONAL,
  digestEncryptionAlgorithm
    DigestEncryptionAlgorithmIdentifier,
  encryptedDigest EncryptedDigest,
  unauthenticatedAttributes
    [1] IMPLICIT Attributes OPTIONAL }

EncryptedDigest ::= OCTET STRING

KEA/DH, however, can't really be done in a cool way.
In general, both KEA and DH require that the recipient
have the sender's public key (Y) available to them.
Y needs to be represented some way. Typically, in 
the FORTEZZA world, Y comes out of the sender's certificate.
Technically, this isn't necessary, and in the DH world,
one can typically choose between having a raw Y 
(in which case the sender is anonymous as with RSA) and
having a sender certificate which carries the Y. [2]

The problem is that the RecipientInfo structure in
PKCS7:
RecipientInfo ::= SEQUENCE {
  version Version,
  issuerAndSerialNumber IssuerAndSerialNumber,
  keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
  encryptedKey EncryptedKey }

doesn't have any room for ANY of this stuff, 
Ys, certificates, anything. Now, you could imagine putting
this stuff in a number of places:
1. In the parameters to the AlgorithmIdentifier
2. In the EncryptedKey itself. E.g. 
FortezzaWrappedKey::={
  senderIssuerAndSerialNumber IssuerAndSerialNumber,
  certificates [0] IMPLICIT Certificates OPTIONAL,
  rSender OCTET STRING,
  wrappedDEK  OCTET STRING  -- 12 octets

So, you see, it can be done without changing the 
EnvelopedData ASN.1, but it's pretty ugly. I'd call
this a hack.

The correct way to do this is to change the ASN.1 just 
a little bit. If you do it correctly, you can arrange
that the Bits on the Wire are identical if RSA is used,
but that things are different if KEA/DH is used. It's
fairly easy to write this using ASN.1 OPTIONALs.

-Ekr

[1] Note that one needs to decide precisely what OID one
is going to use and how to encode R and S (e.g. concatenate
them, represent them as a SEQUENCE OF INTEGER, etc.) but these
decisions have already been made for PKIX, so no problem.
 
[2] Incidentally, both KEA and DH (at least in the X9.42 variant)
are usually used with two random numbers Ra (generated by the
sender) and Rb (generated by the recipient). For store and
forward applications, Rb is usually fixed. This needs to
get carried as well.

-- 
[Eric Rescorla                             Terisa Systems, Inc.]
		"Put it in the top slot."

Date: Thu, 11 Sep 1997 15:06:15 -0700
From: Karen Rosenthal <[email-masked]>
Organization: Premenos
To: [email-masked], [email-masked]
CC: [email-masked], Pedro Chiang <[email-masked]>
Subject: S/MIME Developers Meeting
Sender: [email-masked]

After returning from attendance at the S/MIME Developers Workshop
yesterday (I feel somehow like I've been spun up in a tornado, and
dumped back in exactly the same place) ...

Issues of concern:

1.  Will the current PKCS standards, along with the current dusse drafts
be submitted as Informational RFCs as is, or not; and if so, is this
submission, in light of desire to proceed along the true RFC standards
track at a later time, problematic or not?

>From an ediint perspective, I have a vested interest in seeing the
current work gaining some sort of RFC status in the immediate future, as
the ediint drafts reference the dusse drafts.  If an Informational RFC
is a short term answer, and progression down the standards track, with a
revised, and more functional version of S/MIME / PKCS in the future, so
be it.  Dave Crocker gave the impression that submitting the same
material for both Informational RFC status, and standards track, would
be asking for trouble.  I didn't know if this was in the context of
submitting the SAME material (current dusse drafts, and PKCS#7 v1.5) for
Informational RFC, and down the standards RFC track, or also included
the case of having an essentially rewritten form (i.e. S/MIME V3, PKCS#7
v2) go down the standards track.  If the former, great, but if the
latter, I'd say, drop the Informational RFC quest, and push the
standards track.

2.  Could the current drafts even pass as Informational RFCs right now.

Opinion on this seems to be pretty well split.  I echo Keith Dennis'
concern voiced in his earlier message, that RSA's hold on rsaEncryption
is a big problem, regardless of whether or not precedence has been set
on this before, in the IETF decision making process.  I hope, being one
of the skeptics, that I'm wrong...

3.  Moving forward...

Cutting to the chase ... S/MIME and MSP merge, and a completely revamped
PKCS#7.  Great.  How long are we talking about to get these completed,
and through the IETF process (or does the IETF process get dropped?).
We've got S/MIME product in the market place right now.  And our
customers want standards compliant, interoperable products (the word
"standards" used loosely - truly for "most" clients, standards compliant
really does mean interoperable!!!), that, with all the current press,
provide for DSS and DH, as well as RSA.  In asking the question, can
S/MIME and PKCS#7 v1.5 support DSS and/or DH, I've gotten no details,
but answers ranging the gambit from:

    a. can't be done
    b. can be done as a hack
    c. can be done, in a standards* compliant manner
    d. we've done it

(Could someone please technically prove any of the above?)

Bottom line - we need to provide DSS and DH soon.  We need to know what
our options are, and timelines.  Will we have the ability to implement
them though our current product (current versions of S/MIME, PKCS)?  If
not, has anyone ever considered making algorithm independence a sole
modification to the existing smime draft to get it on standards track,
quickly?  Or is supporting PGP as well, our answer...

--
Karen Rosenthal               Email: [email-masked]
Premenos                      Tel#:  1-510-688-2928
1000 Burnett Ave              Fax#:  1-510-602-2133
Concord, CA  94520            Visit: http://www.premenos.com

Date: Thu, 11 Sep 1997 15:51:54 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: IETF S/MIME
Sender: [email-masked]

From: [email-masked]
>
> ... there is a bigger issue which is the RSA cryptosystem.
>

I don't think the RSA algorithm is particularly important for two reasons:

1) as Jeff Schiller pointed out in Memphis, there aren't that many years
left of patent protection on RSA.  Once it expires, no one needs a license
to do their own implementation.  My bet is that the patent will expire
before S/MIME makes it all the way to full IETF Standard :-).  RC2, on the
other hand, was claimed to be a trade secret, and that protection never
expires.

2) The trend in IETF working groups (TLS and PKIX, not to mention that
other email protocol :-) is to make DSA/DH algorithms mandatory, and
RSA optional.  If S/MIME progresses along the standards track, it would
probably do so as well.  Those implementors who wanted to provide
backwards compatibility with S/MIME v2 could buy an RSA license,
but implementors who did DSA/DH only (without licensing RSA) would be
assured of interoperability with all IETF-compliant implementations.

Date: Thu, 11 Sep 1997 10:39:58 -0700
To: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[email-masked]>
From: Laurence Lundblade <[email-masked]>
Subject: Re: some typological errors
Cc: [email-masked]
Sender: [email-masked]

At 12:35 PM +0900 9/11/97, Kazu Yamamoto
(=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) wrote:
>The followings are typological errors I found on 03 draft and some
>suggestions.
>
>
>Please note escaping "From " to "From=20" is not suitable to ISO 2022
>family becase the "=" keyword is used in character sets encoded by ISO
>2022.

That should not matter at all.  Transfer encoding is completely orthogonal
to character sets.  Before any 2022 interpretation is done all the QP
encoding will be removed. All it will see is "From ".

>
>(2) 3.2.1
>
>If extensions defined RFC2184 are used, the "name" or "filename"
>parameter may include a charset other than US-ASCII. Do you cover
>this case?

I believe this is covered by content-disposition and other. The file name
is not so important here anyway as the main purpose is using the three
letter extension as poor man's type information.

>(3) 3.4.2.2
>
>> The protocol parameter MUST be "application/pkcs7-signature". Note
>> that quotation marks are required around the protocol parameter
>> because MIME requires that the "/" character in the parameter value
>> MUST be quoted.
>
>It's nice if you clarify that the value is case-insensitive.

That's covered by the MIME standard.

LL

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Meeting to discuss current S/MIME certificate draft
Date: Thu, 11 Sep 1997 08:17:13 -0700
Sender: [email-masked]

Anyone who is interested in joining this via telephone please let me
know by private email ([email-masked]) by 3PM Pacific Time.  I will
see if I can coordinate a conference call so that others can participate
on such short notice.

Blake

>-----Original Message-----
>From:	[email-masked] [SMTP:[email-masked]]
>Sent:	Wednesday, September 10, 1997 10:06 PM
>To:	[email-masked]
>Subject:	Meeting to discuss current S/MIME certificate draft
>
>At the S/MIME workshop today we decided to have a face to face
>meeting on Friday to discuss feedback to the S/MIME certificate
>internet draft.  The separate meeting was suggested because there
>were only a few people interested in or prepared to comment on the
>draft, and we felt that we could make some serious progress by
>getting those people together face to face.  I'm annoucing the
>meeting to the list in case anyone else would like to participate.
>
>  The meeting will take place this Friday Sept 12, 1997 at
>1:30pm at Netscape in Mountain View, CA.  The address is:
>
>	Netscape Building #1
>	685-1 E. Middlefield Rd.
>	Mountain View, CA
>
>  This is a large building at the intersection of Middlefield Rd.
>and Highway 237.  The meeting will be held in the "Emerald City"
>conference room, which is right off of the building #1 lobby.
>Give the receptionist any of the following key words and she will
>point you in the right direction: "Jeff Weinstin", "Emerald City",
>or "S/MIME".
>
>	--Jeff

Date: Wed, 10 Sep 1997 22:30:02 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Is 7bit restriction to signature practical?
To: Kazu Yamamoto <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

> Some sons of multipart/signed(aka RFC1847) including PGP/MIME and
> S/MIME restricts an object to be signed to 7bit. From the UA
> programmer's point of view, I wonder if this restriction is practical.

> Let me give you an example.

> In Europa, we can find many 8bit messages as follows:

> 	Subject:
> 	From:
> 	To:
> 	MIME-Version: 1.0
> 	Content-Type: text/plain; charset=iso-8859-1
> 	Content-Transfer-Encoding: 8bit
	
> 	ISO-8859-1 text comes here.

> When I try to forward this message with my signature, how should I do?

Simple: You change the encoding from 8bit to quoted-printable.

> I mean that I want to create the following message.

> 	Subject:
> 	From:
> 	To:
> 	MIME-Version: 1.0
> 	Content-Type: Multipart/Mixed; boundary=foo

> 	--foo

> 	An explanation on the following forwarded message.

> 	--foo
> 	Content-Type: Multipart/Signed; boundary=bar;
> 		protocol="yyy"; micalg=zzz
> 	Content-Transfer-Encoding: xxx

> 	--bar
> 	Content-Type: Message/Rfc822
> 	Content-Transfer-Encoding: xxx

> 	Subject:
> 	From:
> 	To:
> 	MIME-Version: 1.0
> 	Content-Type: text/plain; charset=iso-8859-1
> 	Content-Transfer-Encoding: 8bit
	
> 	ISO-8859-1 text comes here.

> 	--bar
> 	Content-Type: yyy

> 	Signature comes here.

> 	--bar--
	
> 	--foo--

> Since 7bit restriction is required, I think the forwarded message must
> be first analyzed with MIME syntax then be converted to 7bit.

Correct.

> Is this practical? How about forwarding a more complex MIME message
> which is in 8bit?

Well, let's see. In order to conform to the requirements of SMTP an agent must
be prepared to do this whenever it encounters an SMTP server that doesn't
support the 8bitMIME extension. (In fact we're starting to see SMTP server that
refuse to accept unlabelled 8bit, because so many problems attach to 8bit that
doesn't have proper charset labelling.) So what you're asking isn't whether or
not user agents can support multipart/signed, you're asking whether or not user
agents can support MIME. And the evidence is pretty darned strong that they
can.

Now, if you want examples of actual implementations, you'll find that the
code necessaary to do this is part of modern versions of sendmail. I think
the fact that this functionality is part of one of the most, if not the
most, popular email packages around pretty much demonstrates that not
supporting it is inexcusable.

> I guess many implementations just include messages when forwarded.

My various agents certainly do not. Again, this has nothing to do with
multipart/signed per se; it is just a basic part of MIME functionality.

				Ned

To: [email-masked], [email-masked]
Subject: Is 7bit restriction to signature practical?
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[email-masked]>
Date: Thu, 11 Sep 1997 12:57:36 +0900
Lines: 66
Sender: [email-masked]

Some sons of multipart/signed(aka RFC1847) including PGP/MIME and
S/MIME restricts an object to be signed to 7bit. From the UA
programmer's point of view, I wonder if this restriction is practical.

Let me give you an example.

In Europa, we can find many 8bit messages as follows:

	Subject:
	From:
	To:
	MIME-Version: 1.0
	Content-Type: text/plain; charset=iso-8859-1
	Content-Transfer-Encoding: 8bit
	
	ISO-8859-1 text comes here.

When I try to forward this message with my signature, how should I do?
I mean that I want to create the following message.

	Subject:
	From:
	To:
	MIME-Version: 1.0
	Content-Type: Multipart/Mixed; boundary=foo

	--foo

	An explanation on the following forwarded message.

	--foo
	Content-Type: Multipart/Signed; boundary=bar; 
		protocol="yyy"; micalg=zzz
	Content-Transfer-Encoding: xxx

	--bar
	Content-Type: Message/Rfc822
	Content-Transfer-Encoding: xxx	

	Subject:
	From:
	To:
	MIME-Version: 1.0
	Content-Type: text/plain; charset=iso-8859-1
	Content-Transfer-Encoding: 8bit
	
	ISO-8859-1 text comes here.

	--bar
	Content-Type: yyy

	Signature comes here.

	--bar--
	
	--foo--

Since 7bit restriction is required, I think the forwarded message must
be first analyzed with MIME syntax then be converted to 7bit.

Is this practical? How about forwarding a more complex MIME message
which is in 8bit?

I guess many implementations just include messages when forwarded.

--Kazu

To: [email-masked]
Subject: some typological errors
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[email-masked]>
Date: Thu, 11 Sep 1997 12:35:36 +0900
Lines: 54
Sender: [email-masked]

The followings are typological errors I found on 03 draft and some
suggestions.

(1) The first part of the example in 3.1.4

"A1Hola" should be "=A1Hola".

Please note escaping "From " to "From=20" is not suitable to ISO 2022
family becase the "=" keyword is used in character sets encoded by ISO 
2022.

(2) 3.2.1

If extensions defined RFC2184 are used, the "name" or "filename"
parameter may include a charset other than US-ASCII. Do you cover
this case?

(3) 3.4.2.2

> The protocol parameter MUST be "application/pkcs7-signature". Note
> that quotation marks are required around the protocol parameter
> because MIME requires that the "/" character in the parameter value
> MUST be quoted.

It's nice if you clarify that the value is case-insensitive.

(4) boundary issue

MIME's boundary includes a preceding <CR><LF>. I think examples of
3.1.4, 3.4.2.3, and 3.4.2.4 need one more null line before the last
boundaries.

For instance, 

    ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
    4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
    n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
    7GhIGfHfYT64VQbnj756
    --boundary42--

SHOULD be

    ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
    4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
    n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
    7GhIGfHfYT64VQbnj756

    --boundary42--

(5) References

The [RC2] line contains one 8bit character.

--Kazu

To: [email-masked]
Subject: Re: New versions of the drafts: please read
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[email-masked]>
Date: Thu, 11 Sep 1997 11:15:49 +0900
Lines: 43
Sender: [email-masked]

From: Laurence Lundblade <[email-masked]>
Subject: Re: New versions of the drafts: please read
Date: Wed, 10 Sep 1997 16:57:52 -0700

> >Does "registered character set" mean one of character sets found in
> >"ftp://ftp.isi.edu/in-notes/iana/assignment/character-sets/"?
> >
> >If so, you should change this sentence. "ISO-2022-JP" and "EUC-JP" is
> >registered by IANA. But to canonicalize Japanese text, "ISO-2022-JP"
> >MUST be used if it is transfered by SMTP.
> 
> Kazu, can you write some language here?  

Do you mean to post ISO-2022-JP messages to ietf-smime? If so, I'm
afraid that most of members cannot read it.

# It seems that many people cannot decode even my From: field.

> Or someone else that knows the
> char set stuff better.

I think I know charset well. 

Let me clarify my point. There are three major charset in Japan,
ISO-2022-JP(aka JIS), EUC/Japan, Shift-JIS. In SMTP world, only
ISO-2022-JP text is allowed to transfer. However, in HTTP world, all
three charsets are actually transferred. Seeing this situation, it
seems to me that "registered character set" is confusing.

NOTE: in S/MIME draft, the word "charset" SHOULD be used. Its
definition can be found in draft-freed-charset-reg-02.txt. Please
understand that ISO 2022 is an encoding scheme for character sets.

> Sounds right, perhaps combined with the above text, and alluding to the
> fact that 2022 is Japanese so other implementors that don't know about
> Japanese don't get confused.

2022 includes Kerean and Chinese as well as Japanese. People says that
EUC/Korea is the transfer charset in Korea but international gateways
convert EUC/Korea to ISO-2022-KR. Are there any Korean guys on this
list?

--Kazu

Date: Wed, 10 Sep 1997 19:06:05 -0700
From: [email-masked] (Jeff Weinstein)
To: [email-masked]
Subject: Meeting to discuss current S/MIME certificate draft
Sender: [email-masked]

At the S/MIME workshop today we decided to have a face to face
meeting on Friday to discuss feedback to the S/MIME certificate
internet draft.  The separate meeting was suggested because there
were only a few people interested in or prepared to comment on the
draft, and we felt that we could make some serious progress by
getting those people together face to face.  I'm annoucing the
meeting to the list in case anyone else would like to participate.

  The meeting will take place this Friday Sept 12, 1997 at
1:30pm at Netscape in Mountain View, CA.  The address is:

	Netscape Building #1
	685-1 E. Middlefield Rd.
	Mountain View, CA

  This is a large building at the intersection of Middlefield Rd.
and Highway 237.  The meeting will be held in the "Emerald City"
conference room, which is right off of the building #1 lobby.
Give the receptionist any of the following key words and she will
point you in the right direction: "Jeff Weinstin", "Emerald City",
or "S/MIME".

	--Jeff

Date: Wed, 10 Sep 1997 16:57:52 -0700
To: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[email-masked]>
From: Laurence Lundblade <[email-masked]>
Subject: Re: New versions of the drafts: please read
Cc: [email-masked]
Sender: [email-masked]

Reply details intertwined... (Paul, I assume you'll make some of these
changes?)  LL

At 1:31 PM +0900 9/8/97, Kazu Yamamoto
(=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) wrote:
>Hello S/MIME guys,
>
>I have some comments on draft-dusse-smime-msg-03.txt.
>
>(1) 3.1.1
>
>> The most common and important canonicalization is for text, which is
>> often represented differently in different environments. MIME entities
>> of major type "text" must have both their line endings and character
>> set canonicalized. The line ending must be the pair of characters
>> <CR><LF>, and the character set should be a registered character set.
>
>Does "registered character set" mean one of character sets found in
>"ftp://ftp.isi.edu/in-notes/iana/assignment/character-sets/"?
>
>If so, you should change this sentence. "ISO-2022-JP" and "EUC-JP" is
>registered by IANA. But to canonicalize Japanese text, "ISO-2022-JP"
>MUST be used if it is transfered by SMTP.

Kazu, can you write some language here?  Or someone else that knows the
char set stuff better.

>
>(2) 3.1.1
>
>> Note that some character sets such as ISO-2022 have multiple
>> representations for the same characters. When preparing such text for
>> signing, the canonical representation specified for the character set
>> MUST be used.
>
>Great. It is nice if the following sentence is appended to this
>paragraph.
>
>	"For instance, redundant escape sequences in ISO-2022 text
>	SHOULD be removed."

Sounds right, perhaps combined with the above text, and alluding to the
fact that 2022 is Japanese so other implementors that don't know about
Japanese don't get confused.

>
>(3) 3.1.2
>
>> When generating any of the secured MIME entities below, except the
>> signing using the multipart/signed format, no transfer encoding at all
>> is required.  S/MIME implementations MUST be able to deal with binary
>> MIME objects. If no Content-Transfer-Encoding header is present, the
>> transfer encoding should be considered binary.
>
>Is this default rule intentional?
>
>RFC2045 defines that "7BIT" is assumed if the
>Content-Transfer-Encoding header field is not present.

I agree, the default should be 7BIT.  This likely what all S/MIME
implementations are doing now too.  I would go so far as to exclude binary
CTE all together.  Many S/MIME implementations can't handle binary now
anyway.

>(4) 3.1.4
>
>For readability, I like to have more popular Content-Type: of the
>second part of the multipart/mixed example than
>"application/willy-waggle". How about image/jpeg?
>
>I don't know what application/willy-waggle is, however,
>Content-Transfer-Encoding: base64 is necessary if it is replaced with
>other CT: value.

Yes, switch to image/jpeg is probably a good idea.  wally-waggle isn't
registered (yet).

>(5) 3.2.1
>
>RFC 2183 should be referred for Content-Dispostion:.
>
>(6) 3.4.2.3
>
>Do you intend that the first part of the example in Sec 3.4.2.3 ends
>without line delimiter?
>
>If so, the following is more readable.
>
>    --boundary42
>    Content-Type: text/plain
>
>    This is a clear-signed message. No line delimiter here.
>    --boundary42
>
>If no, you should fix it as follows:
>
>    --boundary42
>    Content-Type: text/plain
>
>    This is a clear-signed message.
>
>    --boundary42
>

Yes, the latter is probably better.

>--Kazu, WIDE project

From: Keith Moore <[email-masked]>
To: "Paul Rarey" <[email-masked]>
cc: Keith Moore <[email-masked]>, Steve Russell <[email-masked]>, "[email-masked] @ WORLDTALK" <[email-masked]>, "[email-masked] @ WORLDTALK" <[email-masked]>, "[email-masked] @ WORLDTALK" <[email-masked]>, "David P. Kemp" <[email-masked]>, Anthony Daniel <[email-masked]>
Subject: Re: IETF S/MIME 
Date: Wed, 10 Sep 1997 18:23:43 -0400
Sender: [email-masked]

> Is RSASDI currently negotiation terms of an agreement with ISOC?

people are talking.  I'm not going to be more specific at this time.

Keith

Date: Wed, 10 Sep 1997 14:44:35 -0700
From: "Paul Rarey" <[email-masked]>
Organization: The Clorox Services Company
To: Keith Moore <[email-masked]>
CC: Steve Russell <[email-masked]>, "[email-masked] @ WORLDTALK" <[email-masked]>, "[email-masked] @ WORLDTALK" <[email-masked]>, "[email-masked] @ WORLDTALK" <[email-masked]>, "David P. Kemp" <[email-masked]>, Anthony Daniel <[email-masked]>
Subject: Re: IETF S/MIME
Sender: [email-masked]

Keith,

Keith Moore wrote:

> Negotiations are continuing.  These things take time. [*]

Is RSASDI currently negotiation terms of an agreement with ISOC?Or is that
wind also?

[ psr ]

From: Keith Moore <[email-masked]>
To: "Steve Russell" <[email-masked]>
cc: "[email-masked] @ WORLDTALK" <[email-masked]>, "[email-masked] @ WORLDTALK" <[email-masked]>, "[email-masked] @ WORLDTALK" <[email-masked]>, "David P. Kemp" <[email-masked]>, "Anthony Daniel" <[email-masked]>, [email-masked]
Subject: Re: IETF S/MIME 
Date: Wed, 10 Sep 1997 16:57:22 -0400
Sender: [email-masked]

> You can't believe everything that you read.  

Indeed.

> I've enclosed an article that   
> is both more current (as far as when it was written), and more
> accurate.

Perhaps the article was more current, but it was still so inaccurate
as to be useless.  In particular,

S/MIME was not "removed from the docket", because it was never on the
docket.  Since no S/MIME working group was ever formed, there was no
working group to meet in Munich.  There had already been two S/MIME
BOFs, and IETF rules prevent a BOF from meeting more than two times.

Neither has there ever been any agreement to delegate change control
of S/MIME, or use of the S/MIME trademark, to IETF or ISOC.  IETF will
not form a working group to standardize proprietary technology until
it has change control over the specification.  See RFC 2026, section
7.1.3.

So while there are still problems with IETF adopting S/MIME, this is
not a "stunning rebuke".  The truth is simply that RSADSI and IETF
have not yet agreed on mutually acceptable terms for delegating change
control and the use of the S/MIME trademark to IETF.  And IESG won't
take action on an S/MIME working group until the ink is dry on the
agreement.

Negotiations are continuing.  These things take time. [*]

Meanwhile, don't believe ANYTHING that you read in the trade press.
*All* of the news I've seen in the trade press on IETF and S/MIME is
substantially wrong.

Keith

[*] Unfortunately, press posturing is also continuing, which will
probably cause things to take even longer.

Date: Wed, 10 Sep 1997 20:18:00 -0700
From: "Steve Russell" <[email-masked]>
Subject: RE: IETF S/MIME
To: "[email-masked] @ WORLDTALK" <[email-masked]>, "[email-masked] @ WORLDTALK" <[email-masked]>, "[email-masked] @ WORLDTALK" <[email-masked]>, "David P. Kemp" <[email-masked]>, "Anthony Daniel" <[email-masked]>
Sender: [email-masked]

You can't believe everything that you read.  No OpenPGP is not the best   
course, nor is S/MIME prohibiting you from using whatever encryption   
technology you find exciting.  Nor, as PGP is often claiming, is S/MIME   
'less secure' than PGP open or otherwise. I've enclosed an article that   
is both more current (as far as when it was written), and more accurate.   
 It was published in this week's Internet Week (formerly Communication   
Week) and can also be referenced at the CMP web site:

Internet Week (formerly Communication Week)
<!-- begin article -->September 08, 1997, <!-- Document ID   
INW19970908S0035 -->Issue: 680
Section: News & Analysis

S/MIME Protocol Gets Back On Standards Track
By John Fontana
Just when it seemed there was little hope of RSA's S/MIME protocol   
becoming an Internet standard, it appears to be back on track.
The Secure Multipurpose Internet Mail Extension (S/MIME) protocol, which   
is a trademark of RSA Data Security (www.rsa.com), Redwood City, Calif.,   
will be submitted as an informational request for comment (RFC) to the   
Internet Engineering Task Force in the next few weeks, said Tim Matthews,   
product manager for RSA's S/Mail, an S/MIME developer's kit.
S/MIME has been regarded as a de facto standard for secure messaging for   
the past two years. It was all but assured of moving closer to an   
Internet Engineering Task Force standard at last month's quarterly   
meeting, held in Munich.
But, in a stunning rebuke, it was removed from the docket.
Initially an informational RFC that is based on S/MIMEv2, S/MIME will be   
filed with the IETF. That will be followed shortly by the submission of a   
plan to establish a working group for S/MIMEv3 within the IETF, according   
to Matthews. The formation of a working group is the first step to   
creating a standard. S/MIME is a protocol for end-to-end authentication   
and privacy for E-mail. S/MIMEv3 is more robust because it allows for the   
exchange of encryption keys other than those designed and supported by   
RSA.
Doing The Right Thing
Before the plan is submitted, RSA must come to an agreement with the   
Internet Society (ISOC), which oversees the IETF, to turn over copyrights   
and the trademarked S/MIME name to the ISOC, according to Paul Hoffman,   
co-director of the Internet Mail Consortium (www.imc.org) and author of   
the S/MIME charter. Once an agreement is reached, the charter can be   
submitted and a working group can be formed.
"We are taking advice from the IETF and its security area director so we   
can do the right things with the charter," said Matthews. RSA plans to   
work on the charter this week at its Developer's Day in San Francisco.
"The working group should be in place by December," said Hoffman. Its   
first face-to-face meeting would then be at the next IETF meeting Dec.   
8-12 in Washington, D.C.
Questions over S/MIME and RSA's trademark became an issue at the IETF   
meeting in Munich. The removal of S/MIME from consideration by the IETF   
came as a surprise to vendors who are heavily pushing the protocol in   
their messaging products. Momentum behind the specification is being   
driven by Lotus Development, Microsoft, Netscape and Novell, among   
others.
Netscape has already released S/MIME support, Novell will release support   
in two weeks in GroupWise, and the other two plan to implement it this   
fall. The four vendors combined account for nearly 25 million seats of   
electronic mail.
Major corporations are anxiously awaiting a standard and secure way to   
exchange E-mail, which is becoming a transport for many sensitive   
documents. S/MIME is seen as a good technical solution even though some   
interoperability problems recently surfaced.
Copyright (c) 1997 CMP Media Inc

 -----Original Message-----
From: Anthony Daniel
Sent: Wednesday, September 10, 1997 11:45 AM
To: David P. Kemp; [email-masked] @ WORLDTALK; [email-masked] @   
WORLDTALK; [email-masked] @ WORLDTALK
Cc: [email-masked] @ WORLDTALK
Subject: Re: IETF S/MIME

Imagine what would have happened to the Internet (and to software
developers), if a company like RSA Inc, had copyright and trade secrets   
on
the TCP protocol?

Is it not better to leave RSA with their copyrights and secrets (they can
keep them) and move on to a free package that has wide use within the
internet community and has always had published code - with no future
problems on licensing: that is developers/end-user additional costs.

A package tested and open to use whatever algorithms we want to use?

Isn't OPEN PGP the best solution?

Anthony

At 12:03 PM 10/09/97 -0400, David P. Kemp wrote:
>
>It will be interesting to see the minutes from today's S/MIME workshop,
>particularly regarding agenda item 3: "progressing S/MIME within the   
IETF".
>Until now, I held out some hope that that might actually happen.
>
>But an article in Computer Reseller News entitled "RSA's Bidzos takes   
issue
>with the IETF" (http://techweb.cmp.com/crn, search on bidzos) says that
>RSA has no intention of being "bullied" by the IETF, implying that there
>is little chance of resolving the licensing issues.
>Assuming that the article accurately reflects RSA's position, I fully
>support the IETF's decision not to form an S/MIME working group.
>
>At the Memhis BOF, Jeff Schiller stated that the two primary obstacles
>were the trade secret status claimed for the RC2 algorithm, and
>licensing of the S/MIME trademark.  The first issue was addressed by
>publication of draft-rivest-rc2desc-00.txt on June 23, so it is   
apparently
>the second issue which is gumming up the works.
>
>
>As a way out of this impasse, I propose the formation of an IETF working
>group to standardize the Message Security Protocol (MSP) version 5.
>The working drafts for MSP v5 would be identical in content to
>draft-dusse-smime-msg and draft-dusse-smime-cert except that all
>references to the trademarked term "S/MIME" would be replaced with
>the term "MSP".  The development of MSP v5 (including the message
>encoding format and the choice of mandatory algorithms) would be in
>accordance with standard IETF procedures, only faster :-).
>
>
>Any S/MIME(tm) developers interested in pursuing this course, as a way
>to move forward?
>
>Any interest in an MSP BOF this December in DC?
>

From: "Gaon, David" <[email-masked]>
To: "[email-masked] " <[email-masked]>, "[email-masked] " <[email-masked]>, "[email-masked] " <[email-masked]>, "[email-masked] " <[email-masked]>, Anthony Daniel  <[email-masked]>
Cc: "[email-masked] " <[email-masked]>
Subject: RE: IETF S/MIME
Date: Wed, 10 Sep 1997 14:56:00 -0400
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------ =_NextPart_000_01BCBDFA.021FE690
Content-Type: text/plain

     Anthony Daniel wrote:
     >>Isn't OPEN PGP the best solution?
     
     This seems to me a much more reasonable alternative.
     It will at least eliminate one competing standard from an already 
     crowded platform and leave us with one standard that is just as 
     effective (in my opinion).
     Is PGP-MIME in any way weaker than S-MIME ??
     
     David Gaon

------ =_NextPart_000_01BCBDFA.021FE690
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64

------ =_NextPart_000_01BCBDFA.021FE690--

Date: Wed, 10 Sep 1997 19:43:12 -0400
To: [email-masked] (David P. Kemp), [email-masked], [email-masked], [email-masked]
From: Anthony Daniel <[email-masked]>
Subject: Re: IETF S/MIME
Cc: [email-masked]
Sender: [email-masked]

Imagine what would have happened to the Internet (and to software
developers), if a company like RSA Inc, had copyright and trade secrets on
the TCP protocol?

Is it not better to leave RSA with their copyrights and secrets (they can
keep them) and move on to a free package that has wide use within the
internet community and has always had published code - with no future
problems on licensing: that is developers/end-user additional costs.

A package tested and open to use whatever algorithms we want to use?

Isn't OPEN PGP the best solution?

Anthony 

At 12:03 PM 10/09/97 -0400, David P. Kemp wrote:
>
>It will be interesting to see the minutes from today's S/MIME workshop,
>particularly regarding agenda item 3: "progressing S/MIME within the IETF".
>Until now, I held out some hope that that might actually happen.
>
>But an article in Computer Reseller News entitled "RSA's Bidzos takes issue
>with the IETF" (http://techweb.cmp.com/crn, search on bidzos) says that
>RSA has no intention of being "bullied" by the IETF, implying that there
>is little chance of resolving the licensing issues.
>Assuming that the article accurately reflects RSA's position, I fully
>support the IETF's decision not to form an S/MIME working group.
>
>At the Memhis BOF, Jeff Schiller stated that the two primary obstacles
>were the trade secret status claimed for the RC2 algorithm, and
>licensing of the S/MIME trademark.  The first issue was addressed by
>publication of draft-rivest-rc2desc-00.txt on June 23, so it is apparently
>the second issue which is gumming up the works.
>
>
>As a way out of this impasse, I propose the formation of an IETF working
>group to standardize the Message Security Protocol (MSP) version 5.
>The working drafts for MSP v5 would be identical in content to
>draft-dusse-smime-msg and draft-dusse-smime-cert except that all
>references to the trademarked term "S/MIME" would be replaced with
>the term "MSP".  The development of MSP v5 (including the message
>encoding format and the choice of mandatory algorithms) would be in
>accordance with standard IETF procedures, only faster :-).
>
>
>Any S/MIME(tm) developers interested in pursuing this course, as a way
>to move forward?
>
>Any interest in an MSP BOF this December in DC?
>

Date: Wed, 10 Sep 1997 13:33:52 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: IETF S/MIME
Sender: [email-masked]

> From: Jeff Williams <[email-masked]>
> > 
> > Any interest in an MSP BOF this December in DC?
> 
>   How about somewhere else rather than DC?

Take it up with the IETF Secretariat.  Conferences are usually planned
at least a year in advance, so I doubt you'll be able to change the location
of this one at this late date.

Date: Wed, 10 Sep 1997 12:37:53 +0100
From: Jeff Williams <[email-masked]>
Organization: IEG. INC.
To: "David P. Kemp" <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: IETF S/MIME
Sender: [email-masked]

David,

David P. Kemp wrote:
> 
> It will be interesting to see the minutes from today's S/MIME workshop,
> particularly regarding agenda item 3: "progressing S/MIME within the IETF".
> Until now, I held out some hope that that might actually happen.
> 
> But an article in Computer Reseller News entitled "RSA's Bidzos takes issue
> with the IETF" (http://techweb.cmp.com/crn, search on bidzos) says that
> RSA has no intention of being "bullied" by the IETF, implying that there
> is little chance of resolving the licensing issues.
> Assuming that the article accurately reflects RSA's position, I fully
> support the IETF's decision not to form an S/MIME working group.
> 
> At the Memhis BOF, Jeff Schiller stated that the two primary obstacles
> were the trade secret status claimed for the RC2 algorithm, and
> licensing of the S/MIME trademark.  The first issue was addressed by
> publication of draft-rivest-rc2desc-00.txt on June 23, so it is apparently
> the second issue which is gumming up the works.
> 
> As a way out of this impasse, I propose the formation of an IETF working
> group to standardize the Message Security Protocol (MSP) version 5.
> The working drafts for MSP v5 would be identical in content to
> draft-dusse-smime-msg and draft-dusse-smime-cert except that all
> references to the trademarked term "S/MIME" would be replaced with
> the term "MSP".  The development of MSP v5 (including the message
> encoding format and the choice of mandatory algorithms) would be in
> accordance with standard IETF procedures, only faster :-).
> 
> Any S/MIME(tm) developers interested in pursuing this course, as a way
> to move forward?

  Count me in.  I think that in light of the situation with RSA,
this is an execelent suggestion.
> 
> Any interest in an MSP BOF this December in DC?

  How about somewhere else rather than DC?

Regards,

-- 
Jeffrey A. Williams
DIR. Internet Network Eng/SR. Java Development Eng.
Information Eng. Group. IEG. INC. 
Phone :913-294-2375 (v-office)
E-Mail [email-masked]

Date: Wed, 10 Sep 1997 12:03:00 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked], [email-masked], [email-masked]
Subject: IETF S/MIME
Cc: [email-masked]
Sender: [email-masked]

It will be interesting to see the minutes from today's S/MIME workshop,
particularly regarding agenda item 3: "progressing S/MIME within the IETF".
Until now, I held out some hope that that might actually happen.

But an article in Computer Reseller News entitled "RSA's Bidzos takes issue
with the IETF" (http://techweb.cmp.com/crn, search on bidzos) says that
RSA has no intention of being "bullied" by the IETF, implying that there
is little chance of resolving the licensing issues.
Assuming that the article accurately reflects RSA's position, I fully
support the IETF's decision not to form an S/MIME working group.

At the Memhis BOF, Jeff Schiller stated that the two primary obstacles
were the trade secret status claimed for the RC2 algorithm, and
licensing of the S/MIME trademark.  The first issue was addressed by
publication of draft-rivest-rc2desc-00.txt on June 23, so it is apparently
the second issue which is gumming up the works.

As a way out of this impasse, I propose the formation of an IETF working
group to standardize the Message Security Protocol (MSP) version 5.
The working drafts for MSP v5 would be identical in content to
draft-dusse-smime-msg and draft-dusse-smime-cert except that all
references to the trademarked term "S/MIME" would be replaced with
the term "MSP".  The development of MSP v5 (including the message
encoding format and the choice of mandatory algorithms) would be in
accordance with standard IETF procedures, only faster :-).

Any S/MIME(tm) developers interested in pursuing this course, as a way
to move forward?

Any interest in an MSP BOF this December in DC?

To: [email-masked]
Subject: Re: New versions of the drafts: please read
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[email-masked]>
Date: Mon, 08 Sep 1997 13:31:03 +0900
Lines: 90
Sender: [email-masked]

Hello S/MIME guys,

I have some comments on draft-dusse-smime-msg-03.txt.

(1) 3.1.1

> The most common and important canonicalization is for text, which is
> often represented differently in different environments. MIME entities
> of major type "text" must have both their line endings and character
> set canonicalized. The line ending must be the pair of characters
> <CR><LF>, and the character set should be a registered character set.

Does "registered character set" mean one of character sets found in
"ftp://ftp.isi.edu/in-notes/iana/assignment/character-sets/"?

If so, you should change this sentence. "ISO-2022-JP" and "EUC-JP" is
registered by IANA. But to canonicalize Japanese text, "ISO-2022-JP"
MUST be used if it is transfered by SMTP.

(2) 3.1.1

> Note that some character sets such as ISO-2022 have multiple
> representations for the same characters. When preparing such text for
> signing, the canonical representation specified for the character set
> MUST be used.

Great. It is nice if the following sentence is appended to this
paragraph.

	"For instance, redundant escape sequences in ISO-2022 text 
	SHOULD be removed."

(3) 3.1.2

> When generating any of the secured MIME entities below, except the
> signing using the multipart/signed format, no transfer encoding at all
> is required.  S/MIME implementations MUST be able to deal with binary
> MIME objects. If no Content-Transfer-Encoding header is present, the
> transfer encoding should be considered binary.

Is this default rule intentional? 

RFC2045 defines that "7BIT" is assumed if the
Content-Transfer-Encoding header field is not present.

(4) 3.1.4

For readability, I like to have more popular Content-Type: of the
second part of the multipart/mixed example than
"application/willy-waggle". How about image/jpeg?

I don't know what application/willy-waggle is, however,
Content-Transfer-Encoding: base64 is necessary if it is replaced with
other CT: value.

(5) 3.2.1

RFC 2183 should be referred for Content-Dispostion:.

(6) 3.4.2.3

Do you intend that the first part of the example in Sec 3.4.2.3 ends
without line delimiter?

If so, the following is more readable.

    --boundary42
    Content-Type: text/plain

    This is a clear-signed message. No line delimiter here.
    --boundary42

If no, you should fix it as follows:

    --boundary42
    Content-Type: text/plain

    This is a clear-signed message.

    --boundary42

--Kazu, WIDE project

Date: Fri, 5 Sep 1997 09:22:18 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: New versions of the drafts: please read
Sender: [email-masked]

We're getting very near the end of the revision cycle for both drafts. I've
submitted new versions to the Internet Drafts directory, and they should
show up there in a few days. In the meantime, please read them at
<http://www.imc.org/draft-dusse-smime-msg> and
<http://www.imc.org/draft-dusse-smime-cert>.

I would very much like to finish the discussion of these by the end of next
week. If you're planning on attending the S/MIME developer's conference,
there will certainly be a discussion of them there. Because there are two
open issues in the draft-dusse-smime-msg draft, we still need to do a bit
of work on it, but other than that, we should be finished soon.

For those of you tracking the changes, here are the change summaries for
the two drafts.

*****draft-dusse-smime-msg*****

The following changes were made between the -02 and -03 revisions of
this draft:

Fixed many typos throughout the document found by Lisa Repka.

Fixed typos in the mailing list address and Section 3.

Added references to the cryptographic algorithms.

Clarified that the degnerate case is in Section 2.4.2.

Removed Section 2.4.4 and the reference to PEM since SignedAndEncrypted
was only mentioned as a SHOULD NOT.

Removed "and/or encrypted" from Section 2.5. Added paragraph about
handling new attributes and values. Added similar wording to the end
of Section 2.5.2.

Removed "and encryption" from the first sentence of Section 2.6 since
the sentence is about receiving agents.

Added paragraph at the end of Section 3.1.1 about canonicalization
in character sets.

Changed the last sentence of 3.2.1 to say implementations must not
rely on the extension.

Made micalg required in Section 3.4.2.2 and defined its values.

Added paragraph in Section 3.4.2.4 prohibiting binary in app/mime.

Added "application/pkcs10" to Section 3.9.

Added text at the end of Section 4.1 discussing multiple key pairs.
Also change the "SHOULD NOT" to "MUST NOT" generate keys under 512
bits.

In Appendix A, lowercased the "us" to conform to ASN.1.

In Appendix E, added "name" as an optional parameter in each
registration.

Fixed Appendix G with RSA-approved wording.

*****draft-dusse-smime-cert*****

The following changes were made between the -01 and -02 revisions of
this draft:

Fixed typos in the mailing list address and Section 3.

Changed 2.2 to say MUST for v1 and v3 certs, and dropped v2 certs.
Also clarified what kind of cert should be sent.

Added sentence to the end of 2.3 indicating that receiving agents
should be able to handle no-certs messages.

Removed reference to PKCS #9 from 3.2 and fixed X.520 refs.

Restructured 5.2 to remove references to PKCS #9 by incorporating the
text from PKCS #9 here.

Restructured the tables in 3.2 and 5.2.

Removed [PEM] reference.

Removed Appendix E (open issues), and renumbered other appendixes.

Fixed Appendix E (was F) with RSA-approved wording.

--Paul E. Hoffman, Director
--Internet Mail Consortium

From: Tim Matthews <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: Kim Apathy <[email-masked]>
Subject: Workshop Details
Date: Tue, 2 Sep 1997 14:22:54 -0700
Sender: [email-masked]

All,

A few details for next week's S/MIME Workshop.

DATE: Wednesday, September 10th

AGENDA:

Start: 9AM
- technical feedback on the current Internet Drafts
- getting gateways to DO THE RIGHT THING !!!
- progressing S/MIME within the IETF
- S/MIME compliance and interoperability test plans
- introduction of new features for next version of S/MIME
End: 4PM

COST:              $0.00
     
WHERE:           San Francisco Airport Marriott
                        1800 Old Bayshore Highway
                        Burlingame, California 94010
                        (415) 692-9100
     
SHUTTLE:         A complimentary Marriot shuttle runs  
                        every 10 minutes to and from the San Francisco 
		Airport. 
     
HOTEL 
RESERVATIONS:      Call the Marriot in advance for reservations.  We DO
		        NOT have any special rates set up.  

FOOD:              We will provide a traditional continental   
                        breakfast in the morning and snacks in the
afternoon.   
                        There are restaurants in the hotel for lunch on
your 
                        own.

Tim Matthews
Product Manager
RSA Data Security, Inc.
p. 415/595-8782
f.  415/595-1873
e. [email-masked]