Subject: This DUMB LITTLE AD will put $200 in your pocket every day!!! -aesugpng

From: Cookies@xkrlgjxn
Date: Sat, 30 Jan 1999 10:09:21 -0500

This in compliance with the laws set forth by the 105th congress
concerning commerical Emails and CAN NOT be called "spam"
To be removed simply reply with "remove "as the subject and you
will never hear from me again. This is a one time mailing. Thanks.

This little cookie cutter spits out $20 checks...

It's a 3-part automated system, consisting of a
KILLER classified ad...a powerful one page
sales letter, delivered by auto responder.
And a QUALITY product, delivered to
your customer by the company.

You can set up today...and actually be
getting checks mailed to you tomorrow.

For complete details, send a blank email to:
mailto: [email-masked]

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA16359 for ietf-smime-bks; Sat, 30 Jan 1999 07:05:25 -0800 (PST)
Received: from vhquify.World (11.middletown-04.va.dial-access.att.net [12.68.16.11]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA16355 for ; Sat, 30 Jan 1999 07:05:20 -0800 (PST)
Content-Type: text/html; charset="iso-8859-1"
To: [email-masked]
From: Cookies@xkrlgjxn
Reply-To: [email-masked]
Message-ID:
Subject: This DUMB LITTLE AD will put $200 in your pocket every day!!! -aesugpng
Date: Sat, 30 Jan 1999 10:09:21 -0500
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

This in compliance with the laws set forth by the 105th congress
concerning commerical Emails and CAN NOT be called "spam"
To be removed simply reply with "remove "as the subject and you
will never hear from me again. This is a one time mailing. Thanks.

This little cookie cutter spits out $20 checks...

It's a 3-part automated system, consisting of a
KILLER classified ad...a powerful one page
sales letter, delivered by auto responder.
And a QUALITY product, delivered to
your customer by the company.

You can set up today...and actually be
getting checks mailed to you tomorrow.

For complete details, send a blank email to:
mailto: [email-masked]

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA18231 for ietf-smime-bks; Fri, 29 Jan 1999 16:11:51 -0800 (PST)
Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by mail.proper.com (8.8.8/8.8.5) with SMTP id QAA18227 for ; Fri, 29 Jan 1999 16:11:49 -0800 (PST)
Received: from 208.236.41.137 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v3.2 SR1); Fri, 29 Jan 99 16:14:02 -0800
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by mail.deming.com with Internet Mail Service (5.5.2232.9) id ; Fri, 29 Jan 1999 16:14:02 -0800
Message-ID: <[email-masked]>
From: "Blake Ramsdell"
To: "'Jim Schaad (Exchange)'" , "[email-masked]'" , "Ietf-Smime (E-mail)"
Subject: RE: Last Call comments on the Message And Certificate Drafts
Date: Fri, 29 Jan 1999 16:14:01 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
X-WSS-ID: 1AAC914026235-01-01
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

> -----Original Message-----
> From: Jim Schaad (Exchange) [mailto:[email-masked]]
> Sent: Friday, January 29, 1999 4:03 PM
> To: [email-masked]'; Ietf-Smime (E-mail)
> Subject: RE: Last Call comments on the Message And Certificate Drafts
>
> After re-reading this, I think John is probably correct.

I'll buy it. Please let the
"absolutely-last-call-I'm-not-kidding-don't-mess-with-me" changes list
reflect this change.

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

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA17899 for ietf-smime-bks; Fri, 29 Jan 1999 16:00:29 -0800 (PST)
Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA17895 for ; Fri, 29 Jan 1999 16:00:28 -0800 (PST)
Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id ; Fri, 29 Jan 1999 16:02:51 -0800
Message-ID: <2FBF98FC7852CF11912A0000000000010ECB5C7B@DINO>
From: "Jim Schaad (Exchange)"
To: "[email-masked]'" , "Ietf-Smime (E-mail)"
Subject: RE: Last Call comments on the Message And Certificate Drafts
Date: Fri, 29 Jan 1999 16:02:41 -0800
X-Mailer: Internet Mail Service (5.5.2232.9)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

After re-reading this, I think John is probably correct.

jim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, January 29, 1999 3:06 PM
To: Ietf-Smime (E-mail)
Subject: RE: Last Call comments on the Message And Certificate Drafts

All,

I respectfully disagree with Jim and Blake regarding the attached message
exchange. The intent of the Cert I-D is to specify cert processing
requirements in addition to those defined in PKIX I. IMHO, the last
sentence in the first para in Section 1 should be changed to state: "S/MIME
agents MUST meet the certificate processing requirements documented in this
I-D in addition to those stated in [KEYM]."

- John Pawling

At 10:18 AM 1/14/99 -0800, Blake Ramsdell wrote:
>> -----Original Message-----
>> From: Jim Schaad (Exchange) [mailto:[email-masked]]
>> Sent: Saturday, January 09, 1999 3:48 PM
>> To: Ietf-Smime (E-mail); Blake Ramsdell
>> Cc: Russ Housley (E-mail)
>> Subject: Last Call comments on the Message And Certificate Drafts

>> 1. Section 1 - Reference to KEYM in the last sentence of
>> paragraph #1 is
>> almost certianly meant to be a reference to SMIME-MSG
>
>Hmm. I'll buy that. Agree.
>

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA17228 for ietf-smime-bks; Fri, 29 Jan 1999 15:00:45 -0800 (PST)
Received: from apollo.jgvandyke.com (apollo.jgvandyke.com [158.189.10.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA17224 for ; Fri, 29 Jan 1999 15:00:43 -0800 (PST)
Received: from ajsn101.jgvandyke.com (ajsn101.jgvandyke.com [158.189.2.101]) by apollo.jgvandyke.com (8.8.8/8.8.8) with SMTP id SAA15209 for ; Fri, 29 Jan 1999 18:08:46 -0500 (EST)
Received: from ajpc81 by ajsn101.jgvandyke.com (SMI-8.6/SMI-SVR4) id SAA10775; Fri, 29 Jan 1999 18:06:25 -0500
Date: Fri, 29 Jan 1999 18:06:25 -0500
Message-Id: <[email-masked]>
X-Sender: jsp@ajsn101
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: "Ietf-Smime (E-mail)"
From: [email-masked] (John Pawling)
Subject: RE: Last Call comments on the Message And Certificate Drafts
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

All,

I respectfully disagree with Jim and Blake regarding the attached message
exchange. The intent of the Cert I-D is to specify cert processing
requirements in addition to those defined in PKIX I. IMHO, the last
sentence in the first para in Section 1 should be changed to state: "S/MIME
agents MUST meet the certificate processing requirements documented in this
I-D in addition to those stated in [KEYM]."

- John Pawling

At 10:18 AM 1/14/99 -0800, Blake Ramsdell wrote:
>> -----Original Message-----
>> From: Jim Schaad (Exchange) [mailto:[email-masked]]
>> Sent: Saturday, January 09, 1999 3:48 PM
>> To: Ietf-Smime (E-mail); Blake Ramsdell
>> Cc: Russ Housley (E-mail)
>> Subject: Last Call comments on the Message And Certificate Drafts

>> 1. Section 1 - Reference to KEYM in the last sentence of
>> paragraph #1 is
>> almost certianly meant to be a reference to SMIME-MSG
>
>Hmm. I'll buy that. Agree.
>

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA16910 for ietf-smime-bks; Fri, 29 Jan 1999 14:26:21 -0800 (PST)
Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA16906; Fri, 29 Jan 1999 14:26:19 -0800 (PST)
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Fri, 29 Jan 1999 14:27:55 -0800
To: Russ Housley , [email-masked]
From: Paul Hoffman / IMC
Subject: Re: RFC 2026, Section 10
In-Reply-To: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

At 04:25 PM 1/29/99 -0500, Russ Housley wrote:
>Does anyone disagree?

I certainly don't. It's up to the author of a draft. And, if anyone creates
a draft that they don't put the permissive wording in, I'm not likely to
help them with it.

--Paul Hoffman, Director
--Internet Mail Consortium

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA16823 for ietf-smime-bks; Fri, 29 Jan 1999 14:16:33 -0800 (PST)
Received: from thehub.knight-hub.com ([email-masked] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA16819 for ; Fri, 29 Jan 1999 14:16:32 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id RAA09223; Fri, 29 Jan 1999 17:19:07 -0500
Message-Id: <[email-masked]>
X-Sender: [email-masked] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Fri, 29 Jan 1999 17:17:05 -0500
To: EKR
From: Russ Housley
Subject: Re: KEKRecpientInfo KEKIdentifier
Cc: [email-masked], [email-masked]
In-Reply-To:
References: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

What do others think?

I am unwilling to make it optional without a change to MSG that mandates it
for S/MIME.

Russ

At 08:58 AM 1/29/99 -0800, EKR wrote:
>[email-masked] (Peter Gutmann) writes:
>> almost never be used in the way you've described. PGP has worked just fine
>> for 8 years without a KEKIdentifier, so I don't see why CMS needs to
make it
>> mandatory. All you need to do is use "kekid [ 0 ] KEKIdentifier OPTIONAL"
>and
>> you can let the users decide whether it really is essential or not - I'm
not
>> asking that it be removed, simply that it be made optional so you can
>leave it
>> out where there's nothing to put in a KEKIdentifier.
>I've got to go with Peter here. While I think that for messaging,
>the index is more useful, I don't see any harm in making it optional.
>We can always make MSG require it.
>
>-Ekr
>
>
>--
>[Eric Rescorla [email-masked]]

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA16816 for ietf-smime-bks; Fri, 29 Jan 1999 14:16:29 -0800 (PST)
Received: from thehub.knight-hub.com ([email-masked] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA16812 for ; Fri, 29 Jan 1999 14:16:28 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id RAA09214; Fri, 29 Jan 1999 17:19:04 -0500
Message-Id: <[email-masked]>
X-Sender: [email-masked] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Fri, 29 Jan 1999 17:15:51 -0500
To: [email-masked]
From: Russ Housley
Subject: Re: KEKRecpientInfo KEKIdentifier
Cc: [email-masked]
In-Reply-To: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

Peter:

In file encryption, you might want to put something here to clue the user
about which key. For example, "The key Fred and Johnny picked on New
Year's Day".

In the file encryption application, I would hope that more than on KEK
would be used. If you agree, then the syntax needs a way to identify which
one.

Remember this used to be called mail list keys....

Russ

At 04:21 AM 1/30/99 +0000, Peter Gutmann wrote:
>>The idea is that the KEK is distributed out of band and cached by the
>>recipient(s). The KEKIdentifier is intended to be an index into the cache.
>
>OK, this is one possible hypothetical situation in which a KEKIdentifier
would
>be useful. However (as has been pointed out in other debates on this list),
>CMS is meant to be a Cryptographic Message Syntax, not (in this case) a
>CachedpreviouslyagreedonKEK Message Syntax. Of the many ways in which it's
>possible to use a KEK, the KEKIdentifier applies to only one very specific,
>very special-case use. Requiring that this field be present for every
>imaginable use and application of a KEK doesn't make any sense, because in
>many applications there's absolutely no use for it.
>
>As I mentioned in my previous message, the most common use for a KEK would be
>for file encryption. I'm basing this claim on several years of reading
>alt.security.pgp, in which almost the only use I've ever seen for PGP's -c
>conventional encryption option (equivalent to the CMS KEKRecpientInfo) is for
>file encryption. You've mentioned one theoretical possibility in which a
>KEKIdentifier would be useful, but that isn't a reason to force its use in
>every instance, especially when experience (it's use in PGP) shows that it'll
>almost never be used in the way you've described. PGP has worked just fine
>for 8 years without a KEKIdentifier, so I don't see why CMS needs to make it
>mandatory. All you need to do is use "kekid [ 0 ] KEKIdentifier OPTIONAL"
and
>you can let the users decide whether it really is essential or not - I'm not
>asking that it be removed, simply that it be made optional so you can
leave it
>out where there's nothing to put in a KEKIdentifier.
>
>(Minor nit: Since KEKRecipientInfo is still changing, could the version be
> reset to 0 or 1 to go with the other CMS RecipientInfo types? There's no
> real backwards compatibility problem because the format has changed in the
> last few versions anyway, and it'll avoid having this odd artificially-high
> version number for one particular RecipientInfo type).
>
>Peter.
>

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA16486 for ietf-smime-bks; Fri, 29 Jan 1999 13:32:48 -0800 (PST)
Received: from thehub.knight-hub.com ([email-masked] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA16482 for ; Fri, 29 Jan 1999 13:32:47 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id QAA07510 for ; Fri, 29 Jan 1999 16:35:26 -0500
Message-Id: <[email-masked]>
X-Sender: [email-masked] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Fri, 29 Jan 1999 16:25:18 -0500
To: [email-masked]
From: Russ Housley
Subject: RFC 2026, Section 10
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

All:

Here is Section 10 of RFC 2026.

It is my view that CMS should be labelled:

This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.

Does anyone disagree?

Russ

= = = = = = = = = = =

10. INTELLECTUAL PROPERTY RIGHTS

10.1. General Policy

In all matters of intellectual property rights and procedures, the
intention is to benefit the Internet community and the public at
large, while respecting the legitimate rights of others.

10.2 Confidentiality Obligations

No contribution that is subject to any requirement of confidentiality
or any restriction on its dissemination may be considered in any part
of the Internet Standards Process, and there must be no assumption of
any confidentiality obligation with respect to any such contribution.

10.3. Rights and Permissions

In the course of standards work, the IETF receives contributions in
various forms and from many persons. To best facilitate the
dissemination of these contributions, it is necessary to understand
any intellectual property rights (IPR) relating to the contributions.

10.3.1. All Contributions

By submission of a contribution, each person actually submitting the
contribution is deemed to agree to the following terms and conditions
on his own behalf, on behalf of the organization (if any) he
represents and on behalf of the owners of any propriety rights in the
contribution.. Where a submission identifies contributors in
addition to the contributor(s) who provide the actual submission, the
actual submitter(s) represent that each other named contributor was
made aware of and agreed to accept the same terms and conditions on
his own behalf, on behalf of any organization he may represent and
any known owner of any proprietary rights in the contribution.

l. Some works (e.g. works of the U.S. Government) are not subject to
copyright. However, to the extent that the submission is or may
be subject to copyright, the contributor, the organization he
represents (if any) and the owners of any proprietary rights in
the contribution, grant an unlimited perpetual, non-exclusive,
royalty-free, world-wide right and license to the ISOC and the
IETF under any copyrights in the contribution. This license
includes the right to copy, publish and distribute the
contribution in any way, and to prepare derivative works that are
based on or incorporate all or part of the contribution, the
license to such derivative works to be of the same scope as the
license of the original contribution.

2. The contributor acknowledges that the ISOC and IETF have no duty
to publish or otherwise use or disseminate any contribution.

3. The contributor grants permission to reference the name(s) and
address(es) of the contributor(s) and of the organization(s) he
represents (if any).

4. The contributor represents that contribution properly acknowledge
major contributors.

5. The contribuitor, the organization (if any) he represents and the
owners of any proprietary rights in the contribution, agree that
no information in the contribution is confidential and that the
ISOC and its affiliated organizations may freely disclose any
information in the contribution.

6. The contributor represents that he has disclosed the existence of
any proprietary or intellectual property rights in the
contribution that are reasonably and personally known to the
contributor. The contributor does not represent that he
personally knows of all potentially pertinent proprietary and
intellectual property rights owned or claimed by the organization
he represents (if any) or third parties.

7. The contributor represents that there are no limits to the
contributor's ability to make the grants acknowledgments and
agreements above that are reasonably and personally known to the
contributor.

By ratifying this description of the IETF process the Internet
Society warrants that it will not inhibit the traditional open and
free access to IETF documents for which license and right have
been assigned according to the procedures set forth in this
section, including Internet-Drafts and RFCs. This warrant is
perpetual and will not be revoked by the Internet Society or its
successors or assigns.

10.3.2. Standards Track Documents

(A) Where any patents, patent applications, or other proprietary
rights are known, or claimed, with respect to any specification on
the standards track, and brought to the attention of the IESG, the
IESG shall not advance the specification without including in the
document a note indicating the existence of such rights, or
claimed rights. Where implementations are required before
advancement of a specification, only implementations that have, by
statement of the implementors, taken adequate steps to comply with
any such rights, or claimed rights, shall be considered for the
purpose of showing the adequacy of the specification.
(B) The IESG disclaims any responsibility for identifying the
existence of or for evaluating the applicability of any claimed
copyrights, patents, patent applications, or other rights in the
fulfilling of the its obligations under (A), and will take no
position on the validity or scope of any such rights.

(C) Where the IESG knows of rights, or claimed rights under (A), the
IETF Executive Director shall attempt to obtain from the claimant
of such rights, a written assurance that upon approval by the IESG
of the relevant Internet standards track specification(s), any
party will be able to obtain the right to implement, use and
distribute the technology or works when implementing, using or
distributing technology based upon the specific specification(s)
under openly specified, reasonable, non-discriminatory terms.
The Working Group proposing the use of the technology with respect
to which the proprietary rights are claimed may assist the IETF
Executive Director in this effort. The results of this procedure
shall not affect advancement of a specification along the
standards track, except that the IESG may defer approval where a
delay may facilitate the obtaining of such assurances. The
results will, however, be recorded by the IETF Executive Director,
and made available. The IESG may also direct that a summary of
the results be included in any RFC published containing the
specification.

10.3.3 Determination of Reasonable and Non-discriminatory Terms

The IESG will not make any explicit determination that the assurance
of reasonable and non-discriminatory terms for the use of a
technology has been fulfilled in practice. It will instead use the
normal requirements for the advancement of Internet Standards to
verify that the terms for use are reasonable. If the two unrelated
implementations of the specification that are required to advance
from Proposed Standard to Draft Standard have been produced by
different organizations or individuals or if the "significant
implementation and successful operational experience" required to
advance from Draft Standard to Standard has been achieved the
assumption is that the terms must be reasonable and to some degree,
non-discriminatory. This assumption may be challenged during the
Last-Call period.

10.4. Notices

(A) Standards track documents shall include the following notice:

"The IETF takes no position regarding the validity or scope of
any intellectual property or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; neither does
it represent that it has made any effort to identify any such
rights. Information on the IETF's procedures with respect to
rights in standards-track and standards-related documentation
can be found in BCP-11. Copies of claims of rights made
available for publication and any assurances of licenses to
be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementors or users of this
specification can be obtained from the IETF Secretariat."

(B) The IETF encourages all interested parties to bring to its
attention, at the earliest possible time, the existence of any
intellectual property rights pertaining to Internet Standards.
For this purpose, each standards document shall include the
following invitation:

"The IETF invites any interested party to bring to its
attention any copyrights, patents or patent applications, or
other proprietary rights which may cover technology that may be
required to practice this standard. Please address the
information to the IETF Executive Director."

(C) The following copyright notice and disclaimer shall be included
in all ISOC standards-related documentation:

"Copyright (C) The Internet Society (date). All Rights
Reserved.

This document and translations of it may be copied and
furnished to others, and derivative works that comment on or
otherwise explain it or assist in its implmentation may be
prepared, copied, published and distributed, in whole or in
part, without restriction of any kind, provided that the above
copyright notice and this paragraph are included on all such
copies and derivative works. However, this document itself may
not be modified in any way, such as by removing the copyright
notice or references to the Internet Society or other Internet
organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or
as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will
not be revoked by the Internet Society or its successors or
assigns.

This document and the information contained herein is provided
on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE."

(D) Where the IESG is aware at the time of publication of
proprietary rights claimed with respect to a standards track
document, or the technology described or referenced therein, such
document shall contain the following notice:

"The IETF has been notified of intellectual property rights
claimed in regard to some or all of the specification contained
in this document. For more information consult the online list
of claimed rights."

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA15768 for ietf-smime-bks; Fri, 29 Jan 1999 11:54:04 -0800 (PST)
Received: from thehub.knight-hub.com ([email-masked] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA15764 for ; Fri, 29 Jan 1999 11:54:03 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id OAA03389 for ; Fri, 29 Jan 1999 14:56:46 -0500
Message-Id: <[email-masked]>
X-Sender: [email-masked] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Fri, 29 Jan 1999 14:57:35 -0500
To: [email-masked]
From: Russ Housley
Subject: Fwd: New I-D Boilerplate
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

All authors:

Please take not of this new requirement for Internet-Draft submission.

Russ

>Greetings,
>
>I recently posted a message to the announcement list informing folks that
>the I-D guidelines document has been updated, and that all I-D submissions
>need to incorporate what's in guidelines.
>
>The specific change pertains to the first line of the boilerplate text:
>
>=======================================================================
>All Internet-Drafts should begin with ONE of the following three
>statements:
>
> This document is an Internet-Draft and is in full conformance
> with all provisions of Section 10 of RFC2026.
>
> This document is an Internet-Draft and is in full conformance
> with all provisions of Section 10 of RFC2026 except for the
> right to produce derivative works.
>
> This document is an Internet-Draft and is NOT offered in
> accordance with Section 10 of RFC2026, and will only exist as
> an Internet-Draft.
>
>
>Any submission which does not include one (and only one) of the above
>three statements will be returned to the submitter. The IETF Secretariat
>will NOT add this text.
>
>
>=======================================================================
>
>I'm explicitly bringing this to your attention. You should be aware of the
>requirement, and I expect most of you will want to check out which line is
>used prior to accepting an document as a work ite of the WG.
>
>
>Steve
>
>

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA14945 for ietf-smime-bks; Fri, 29 Jan 1999 10:48:16 -0800 (PST)
Received: from 157.22.235.99 (mactivity.com [157.22.235.99]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA14938 for ; Fri, 29 Jan 1999 10:48:12 -0800 (PST)
Message-Id: <[email-masked]>
Received: from [157.22.235.107] by mactivity.com (AppleShare IP Mail Server 6.1) id 26905 via TCP with SMTP; Fri, 29 Jan 1999 10:51:58 -0800
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Fri, 29 Jan 1999 10:51:46 -0800
Subject: ANN: The Internet Security Conference
From: "Paul Kent"
To: [email-masked]
Mime-version: 1.0
X-Priority: 3
Content-type: multipart/alternative; boundary="MS_Mac_OE_3000451906_542846_MIME_Part"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

> 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.

--MS_Mac_OE_3000451906_542846_MIME_Part
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit

The Internet Security Conference
Making the Internet a Safer Place for Electronic Information Assets
April 19-23, 1999 * Fairmont Hotel * San Jose CA

The 2nd presentation of The Internet Security Conference (TISC,
http://tisc.corecom.com) will address the most pressing security
issues confronting Internet-enabled organizations today.

The most respected experts in nearly every field of security will gather in
the Fairmont Hotel, San Jose to present a technical conference and
exhibition, April
19-23, 1999.

The TISC faculty of over 50 experts, including:

* Fred Avolio, security, former product manager for TIS Gauntlet Internet
Firewall
* Dr. William Hancock, Chief Technology Officer, Network-1
* Charlie Kaufman, Security Architect for Lotus Notes, IBM
* Dr. Stephen Kent, Chief Scientist, Information Security, BBN Technologies
* Rik Farrow, Internet and UNIX Security consultant and author
* Bob Moskowitz, Sr. technical director at the ICSA
* Dr. Radia Perlman, Distinguished Engineer, Sun Microsystems
* Marcus Ranum, firewall expert, CEO & Founder, Network Flight Recorder,
* Dr. Ron Ross, Sr. computer scientist at the Information Technology
Laboratory, NIST

will join Network Computing Magazine's Technology Editors Dan Backman, Mike
Fratto and Dave Willis in presenting workshops, seminars, and a two-day, 30
session Security Symposium.

An Interoperability Lab and Vendor Exhibit will complement the education
offered at TISC. The Interoperability Lab
(http://tisc.corecom.com/lab99.html)
will provide attendees an opportunity to witness individual product
demonstrations,
conducted by vendor *technical* staff. Attendees will see and participate in
multi-vendor
demonstrations of:

* Network Attack, Penetration, and Intrusion Detection
* IPSec/IKE and CA Interoperability
* IPSec Configuration and Benchmarking
* Policy-Based Security Management
* Layered VPNs for Remote Access and Extranet Connectivity
* Desktop and Internet Application Security
* Authentication as an Enabler for Secure E-Commerce

coordinated by Aventail, Core Competence, Ernst & Young and Network
Computing Magazine.

Entrance to the TISC Interoperability Lab is free to all TISC '99 attendees.

TISC workshop students will receive a guided walking tour of security
technologies on display in the lab

A complete program guide is available at
http://tisc.corecom.com/programguide.pdf

Registration is now open, visit
https://secure.mactivity.com/tisc/register.html
or call 1-800-798-2928. Space is Limited.

The Internet Security Conference is presented by Core Competence, the
respected internetworking, fast packet and network management consulting
firm founded
by Dave Piscitello, and Network Computing, the premier technology
solutions
magazine.

Conference Sponsors include
* Compatible Systems * Checkpoint Software Technologies * Ernst & Young *
Microsoft
* Aventail * RadGuard * Internet Devices * NetScreen * 3Com * enCommerce *
RedCreek
* RSA Data Security * TimeStep * Xedia * Network Flight Recorder * Covad
Communications
* Axent Technologies * Kroll-O'Gara ISG* Exodus * Xcert * Network-1 *
Internet Week and NEC

(Visit http://tisc.corecom.com/sponsors.html for new additions to this
list.)
--MS_Mac_OE_3000451906_542846_MIME_Part
Content-type: text/html; charset="US-ASCII"
Content-transfer-encoding: quoted-printable

The Internet Security Conference

Making the Internet a Safer Place for Electronic Information Assets

April 19-23, 1999 * Fairmont Hotel * San Jose CA

The 2nd presentation of The Internet Security Conference (TISC,

http://tisc.corecom.com) will address t=
he most pressing security

issues confronting Internet-enabled organizations today.

The most respected experts in nearly every field of security will gather in=

the Fairmont Hotel, San Jose to present a technical conference and exhibiti=
on, April

19-23, 1999.

The TISC faculty of over 50 experts, including:

* Fred Avolio, security, former product manager for TIS Gauntlet Internet
Firewall

* Dr. William Hancock, Chief Technology Officer, Network-1

* Charlie Kaufman, Security Architect for Lotus Notes, IBM

* Dr. Stephen Kent, Chief Scientist, Information Security, BBN Technologies=

* Rik Farrow, Internet and UNIX Security consultant and author

* Bob Moskowitz, Sr. technical director at the ICSA

* Dr. Radia Perlman, Distinguished Engineer, Sun Microsystems

* Marcus Ranum, firewall expert, CEO & Founder, Network Flight Recorder=
,

* Dr. Ron Ross, Sr. computer scientist at the Information Technology

Laboratory, NIST

will join Network Computing Magazine's Technology Editors Dan Backman, Mike=

Fratto and Dave Willis in presenting workshops, seminars, and a two-day, 30=

session Security Symposium.

An Interoperability Lab and Vendor Exhibit will complement the education
offered at TISC. The Interoperability Lab (http://=
tisc.corecom.com/lab99.html)

will provide attendees  an opportunity to witness individual product d=
emonstrations,

conducted by vendor *technical* staff. Attendees will see and participate i=
n multi-vendor

demonstrations of:

* Network Attack, Penetration, and Intrusion Detection

* IPSec/IKE and CA Interoperability

* IPSec Configuration and Benchmarking

* Policy-Based Security Management

* Layered VPNs for Remote Access and Extranet Connectivity

* Desktop and Internet Application Security

* Authentication as an Enabler for Secure E-Commerce

coordinated by Aventail, Core Competence, Ernst & Young and Network

Computing Magazine.

Entrance to the TISC Interoperability Lab is free to all TISC '99 attendees=
.

TISC workshop students will receive a guided walking tour of security

technologies on display in the lab

A complete program guide is available at

http://tisc.corecom.com/programguide.pdf

Registration is now open, visit

https://secure.mactivity.com/tisc/register.html
or call 1-800-798-2928. Space is Limited.

The Internet Security Conference is presented by Core Competence, the

respected internetworking, fast packet and network management consulting fi=
rm founded

by Dave Piscitello, and  Network Computing,  the premier technolo=
gy solutions

magazine.

Conference Sponsors include

* Compatible Systems * Checkpoint Software Technologies * Ernst & Young=
* Microsoft

* Aventail * RadGuard * Internet Devices * NetScreen * 3Com * enCommerce * =
RedCreek

* RSA Data Security * TimeStep * Xedia * Network Flight Recorder * Covad Co=
mmunications

* Axent Technologies * Kroll-O'Gara ISG* Exodus * Xcert * Network-1 * Inter=
net Week and NEC

(Visit http://tisc.corecom.com/sponsors.html for new additions to this

list.)

--MS_Mac_OE_3000451906_542846_MIME_Part--

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA13504 for ietf-smime-bks; Fri, 29 Jan 1999 08:55:02 -0800 (PST)
Received: from speedy.rtfm.com ([208.217.207.133]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA13500 for ; Fri, 29 Jan 1999 08:55:02 -0800 (PST)
Received: (ekr@localhost) by speedy.rtfm.com (8.9.1/8.6.4) id IAA02838; Fri, 29 Jan 1999 08:58:25 -0800 (PST)
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: KEKRecpientInfo KEKIdentifier
References: <[email-masked]>
From: EKR
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Date: 29 Jan 1999 08:58:24 -0800
In-Reply-To: [email-masked]'s message of "Sat, 30 Jan 1999 04:21:54 (NZDT)"
Message-ID:
Lines: 16
X-Mailer: Gnus v5.6.43/XEmacs 20.4 - "Emerald"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

[email-masked] (Peter Gutmann) writes:
> almost never be used in the way you've described. PGP has worked just fine
> for 8 years without a KEKIdentifier, so I don't see why CMS needs to make it
> mandatory. All you need to do is use "kekid [ 0 ] KEKIdentifier OPTIONAL" and
> you can let the users decide whether it really is essential or not - I'm not
> asking that it be removed, simply that it be made optional so you can leave it
> out where there's nothing to put in a KEKIdentifier.
I've got to go with Peter here. While I think that for messaging,
the index is more useful, I don't see any harm in making it optional.
We can always make MSG require it.

-Ekr

--
[Eric Rescorla [email-masked]]

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA12310 for ietf-smime-bks; Fri, 29 Jan 1999 07:19:31 -0800 (PST)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA12306 for ; Fri, 29 Jan 1999 07:19:27 -0800 (PST)
Received: from cs26.cs.auckland.ac.nz ([email-masked] [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id EAA29912; Sat, 30 Jan 1999 04:21:55 +1300 (NZDT) (sender [email-masked])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <91762331427468>; Sat, 30 Jan 1999 04:21:54 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: KEKRecpientInfo KEKIdentifier
Reply-To: [email-masked]
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Sat, 30 Jan 1999 04:21:54 (NZDT)
Message-ID: <[email-masked]>
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

>The idea is that the KEK is distributed out of band and cached by the
>recipient(s). The KEKIdentifier is intended to be an index into the cache.

OK, this is one possible hypothetical situation in which a KEKIdentifier would
be useful. However (as has been pointed out in other debates on this list),
CMS is meant to be a Cryptographic Message Syntax, not (in this case) a
CachedpreviouslyagreedonKEK Message Syntax. Of the many ways in which it's
possible to use a KEK, the KEKIdentifier applies to only one very specific,
very special-case use. Requiring that this field be present for every
imaginable use and application of a KEK doesn't make any sense, because in
many applications there's absolutely no use for it.

As I mentioned in my previous message, the most common use for a KEK would be
for file encryption. I'm basing this claim on several years of reading
alt.security.pgp, in which almost the only use I've ever seen for PGP's -c
conventional encryption option (equivalent to the CMS KEKRecpientInfo) is for
file encryption. You've mentioned one theoretical possibility in which a
KEKIdentifier would be useful, but that isn't a reason to force its use in
every instance, especially when experience (it's use in PGP) shows that it'll
almost never be used in the way you've described. PGP has worked just fine
for 8 years without a KEKIdentifier, so I don't see why CMS needs to make it
mandatory. All you need to do is use "kekid [ 0 ] KEKIdentifier OPTIONAL" and
you can let the users decide whether it really is essential or not - I'm not
asking that it be removed, simply that it be made optional so you can leave it
out where there's nothing to put in a KEKIdentifier.

(Minor nit: Since KEKRecipientInfo is still changing, could the version be
reset to 0 or 1 to go with the other CMS RecipientInfo types? There's no
real backwards compatibility problem because the format has changed in the
last few versions anyway, and it'll avoid having this odd artificially-high
version number for one particular RecipientInfo type).

Peter.

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA05975 for ietf-smime-bks; Thu, 28 Jan 1999 16:25:31 -0800 (PST)
Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by mail.proper.com (8.8.8/8.8.5) with SMTP id QAA05970 for ; Thu, 28 Jan 1999 16:25:30 -0800 (PST)
Received: from 208.236.41.137 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v3.2 SR1); Thu, 28 Jan 99 16:27:36 -0800
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by mail.deming.com with Internet Mail Service (5.5.2232.9) id ; Thu, 28 Jan 1999 16:27:36 -0800
Message-ID: <[email-masked]>
From: "Blake Ramsdell"
To: "[email-masked]'"
Subject: RE: CERT changes in IETF last call -- please review
Date: Thu, 28 Jan 1999 16:27:31 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
X-WSS-ID: 1AAFDFF217465-01-01
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

> -----Original Message-----
> From: Blake Ramsdell
> Sent: Thursday, January 28, 1999 3:59 PM
> To: [email-masked]'
> Subject: CERT changes in IETF last call -- please review
>
> These are the changes that I am making in MSG-07 that were
> requested during
> IETF last call.

Uh, I mean CERT-07 if you didn't already figure that out.

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

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA05597 for ietf-smime-bks; Thu, 28 Jan 1999 15:56:47 -0800 (PST)
Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA05593 for ; Thu, 28 Jan 1999 15:56:46 -0800 (PST)
Received: from 208.236.41.137 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v3.2 SR1); Thu, 28 Jan 99 15:58:55 -0800
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by mail.deming.com with Internet Mail Service (5.5.2232.9) id ; Thu, 28 Jan 1999 15:58:55 -0800
Message-ID: <[email-masked]>
From: "Blake Ramsdell"
To: "[email-masked]'"
Subject: CERT changes in IETF last call -- please review
Date: Thu, 28 Jan 1999 15:58:45 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
X-WSS-ID: 1AAE263517253-01-01
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

These are the changes that I am making in MSG-07 that were requested during
IETF last call.

Let me know if I missed anything.

Changes from draft-ietf-smime-cert-06 to draft-ietf-smime-cert-07:

Changed "I-D" to "document" in section 1 (Russ Housley)
Added clarification to section 3.1 regarding emailAddress attribute from
PKCS #9 (Russ Housley)
Redid 4.4.2.1 regarding Diffie-Hellman to clarify "doneness" (Russ Housley)
Clarified 4.4 regarding certificate extensions and profiling efforts (Russ
Housley)
Clarified 2.3 regarding DSA parameters being scattered all over the
certificate chain, necessitating the transmission of the root certificate
(Jim Schaad)
Clarified 4.4.1 regarding basic constraints in end entity certificates (Jim
Schaad)
Changed an errant reference to [KEYM] to [SMIME-MSG] (Jim Schaad)
Removed certificate request language from section 1 (Jim Schaad)
Removed [CRMF] reference from section A (Jim Schaad)
Added reference to PKCS #1 v2 and DSS for signature algorithms in section
4.3 (Jim Schaad)
Fixed some language in 4.4 regarding syntax and semantics of extensions are
defined in [KEYM] (Jim Schaad)

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

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA04436 for ietf-smime-bks; Thu, 28 Jan 1999 14:02:02 -0800 (PST)
Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA04432 for ; Thu, 28 Jan 1999 14:02:01 -0800 (PST)
Received: from 208.236.41.137 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v3.2 SR1); Thu, 28 Jan 99 14:04:09 -0800
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by mail.deming.com with Internet Mail Service (5.5.2232.9) id ; Thu, 28 Jan 1999 14:04:09 -0800
Message-ID: <[email-masked]>
From: "Blake Ramsdell"
To: "'Francois Rousseau'" , "William Whyte"
cc:
Subject: RE: x9.42 and CMS
Date: Thu, 28 Jan 1999 14:04:08 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
X-WSS-ID: 1AAE015316031-01-01
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

> -----Original Message-----
> From: Francois Rousseau [mailto:[email-masked]]
> Sent: Thursday, January 28, 1999 1:25 PM
> To: William Whyte
> Cc: [email-masked]
> Subject: Re: x9.42 and CMS
>
> However, I still think that none of the S/MIME standards
> should be bound in
> any way to SHA-1, although SHA-1 can still be the recommended standard
> specified in [MSG] for interoperability at this time.

I think that the case that you illustrated (the use of SHA-1 for creation of
the cert ID) is different than this one. I agree with Jim that the OID can
be changed, which solves that problem.

I think we should be more concerned with William's case, however. The OID
that we tie to this whole process of Diffie Hellman "stuff" is
dhpublicnumber which is placed in certificates. If SHA-1 has a problem, we
can't go back and change the OID in the previously issued certificates.

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

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA04081 for ietf-smime-bks; Thu, 28 Jan 1999 13:22:47 -0800 (PST)
Received: from dylithium.adga.ca (dylithium.adga.ca [207.112.67.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA04077 for ; Thu, 28 Jan 1999 13:22:37 -0800 (PST)
Received: from xfile ([207.112.70.165]) by dylithium.adga.ca (980427.SGI.8.8.8/8.8.8-ajr) with SMTP id QAA13701; Thu, 28 Jan 1999 16:22:56 -0500 (EST)
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Thu, 28 Jan 1999 16:24:53 -0500
To: William Whyte
From: Francois Rousseau
Subject: Re: x9.42 and CMS
Cc: [email-masked]
In-Reply-To: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

Bill,

I had made similar comments before about "ESSCertID" in ESS-09 and
"SMimeEncryptionCert" in CERTDIST-02, since in both cases "certHash"
mandates the use of SHA-1 only. The reply I received from Jim Schaad for
ESS-09 at the time was:

"There are currently a large number of items which are assuming that SHA-1
will not ever be effectively broken. This is just another of those items.
If SHA-1 ever does get broken then the algorithm here can be updated by
creating a new OID to define a new version of ESSCertID. The problem with
making it flexible is that you then need to start stating which algorithms
can and cannot be used leading to the same problem of a new draft when SHA-1
is broken anyway."

However, I still think that none of the S/MIME standards should be bound in
any way to SHA-1, although SHA-1 can still be the recommended standard
specified in [MSG] for interoperability at this time.

Francois Rousseau
AEPOS Technologies

>Sorry only to be bringing this up at the Last Call stage, but I
>don't have any record of it being discussed before.
>
>I'm concerned that the draft-ietf-smime-x942-04 document does not
>provide for the use of any hash algorithm other than SHA-1 when deriving
>the key from the shared secret. X9.42 provides the KeyDerivationHash
>AlgorithmIdentifier. Would it be possible to change the
>KeyAgreeRecipientInfo ASN.1 to read (apologies for poor ASN.1 style):
>
>KeyAgreeRecipientInfo ::= SEQUENCE {
> version CMSVersion, -- always set to 3
> originator [0] EXPLICIT OriginatorIdentifierOrKey,
> ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
> keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
> keyDerivationHash KeyDerivationHashAlgorithmIdentifier
> DEFAULT sha1Identifier,
> recipientEncryptedKeys RecipientEncryptedKeys }
>
>We would then change section 2.1.2 of the draft-ietf-smime-x942-04
>document so that the line
> H is the message digest function SHA-1 [FIPS-180]
>becomes
> H is a message digest function. In [CMS], the message digest function
> is identified by the keyDerivationHash field of the KeyAgreeRecipientInfo
> if this is present, and is SHA-1 if this field is absent.
>
>Again, my apologies if it's too late to be bringing up this kind of point.
>
>Cheers,
>
>William
>
>

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA02993 for ietf-smime-bks; Thu, 28 Jan 1999 11:50:28 -0800 (PST)
Received: from thehub.knight-hub.com ([email-masked] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA02986 for ; Thu, 28 Jan 1999 11:50:24 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id OAA28521 for ; Thu, 28 Jan 1999 14:53:02 -0500
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Thu, 28 Jan 1999 14:46:48 -0500
To: [email-masked]
From: Russ Housley
Subject: Comments on CMS from Burt Kaliski
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

Significant issues are raised in Burt Kaliski's note.

Russ

>From: Burt Kaliski
>To: "[email-masked]'"
>Cc: "Linn, John"
>Subject: Comments on CMS
>Date: Mon, 25 Jan 1999 13:53:00 -0800
>X-Mailer: Internet Mail Service (5.5.2232.9)
>
>Dear Russ --
>
>Here are some comments on
>http://search.ietf.org/internet-drafts/draft-ietf-smime-cms-10.txt. Feel
>free to forward this to the S/MIME discussion list.
>
>> Some general points:
>>
>> * RFC 2437 can now be referenced rather than RFC 2313 for PKCS #1. As a
>> result Section 12.2.2 no longer needs to give the SHA-1 extension to PKCS
>> #1 RSA signatures, as it's supported by RFC 2437.
>>
>> * Section 12.3.2.1 should be more explicit about how RSA encryption is
>> employed for key wrapping (i.e., that the message to be encrypted with
>> RSAES-PKCS1-v1_5 is the key). It should also state whether parity changes
>> are required on DES keys, similar to Section 12.6.2.
>>
>> * It would be helpful to state in step 1 of Section 12.6.2 what parity
>> setting is assumed for DES. Is it necessary to set parity? This is not
>> required when wrapping a DES key with an RSA key.
>>
>> Regarding the key wrapping algorithm itself, one problem I see is that the
>> parts of the CEK are encrypted essentially independently of each other.
>> Although there is chaining through CBC mode, an opponent learns
>> plaintext-ciphertext pairs for the underlying encryption algorithm. The
>> opponent can thus detect collisions in the plaintext space.
>>
>> Specifically, consider what happens when wrapping a triple-DES CEK with
>> some symmetric algorithm. There will be five blocks to be encrypted under
>> a KEK with the symmetric algorithm. With chaining, this will be done as
>>
>> A = Encrypt (IV xor (salt || key<0..3>))
>> B = Encrypt (A xor key<4..11>)
>> C = Encrypt (B xor key<12..19>)
>> D = Encrypt (C xor (key<20..23> || keycheck<0..3>))
>> E = Encrypt (D xor (keycheck<4..7> || 04 04 04 04))
>>
>> where key<0..23> is the triple-DES CEK and ABCDE is the wrapped CEK. An
>> opponent will see ABCDE and knows IV.
>>
>Now suppose that many CEKs are wrapped with the same KEK. (The CEKs need not
>be different.) With high probability, there will be a collision between
>blocks of wrapped CEKs after about 2^32 encryptions. Let ABCDE and
>A*B*C*D*E* be the two wrapped CEKs, let key and key* be the two CEKs, and
>suppose A = E* (i.e., the first block of one wrapped CEK equals the last
>block of the other wrapped CEK). Since Encrypt is a permutation, the
>opponent knows that
>
>> IV xor (salt || key<0..3>) = D* xor (keycheck*<4..7> || 04 04 04 04)
>>
>> Although salt and keycheck* are unknown, the opponent can solve for
>> key<0..3>:
>>
>> key<0..3> = IV<4..7> xor D*<4..7> xor 04 04 04 04
>>
>> Through collisions in other blocks, the opponent can solve for other parts
>> of CEKs and for the difference between parts of CEKs. If the same CEK is
>> wrapped many times with the KEK, the opponent may gather enough
>> information to solve for the entire CEK. If different CEKs are wrapped
>> with the same KEK, an opponent may learn information about the
>> relationship between the CEKs. If the opponent has somehow obtained one
>> CEK encrypted with a KEK (perhaps by being a legitimate recipient of a
>> message encrypted with that CEK), the opponent may then be able to solve
>> for the other CEK.
>>
>The main problem is that all these attacks require only about 2^32 wrapped
>CEKs, which is probably not enough for many applications, particularly given
>the 2^112 security level intended by the use of triple-DES.
>
>> One way to avoid this problem is to limit the number of times a KEK can be
>> employed so that the probability of collision remains small. However, in
>> practice this can be burdensome. A partial solution is to make the padding
>> random rather than 04 04 04 04, but this only addresses the first attack
>> outlined above, not other attacks that find relationships between parts of
>> CEKs.
>>
>> A potential improvement is an OAEP-like construction, where the CEK is
>> formatted as in PKCS #1 EME-OAEP (section 9.1.1 of RFC 2437), then
>> encrypted with the KEK. I suppose the key expansion would be larger in
>> such an approach than in what is proposed in the Internet-Draft, but it
>> would also build on the same formatting for wrapping with RSA keys, and
>> avoid the attacks just described. The CEK parts would not be encrypted
>> separately of one another, but as a whole, having been mixed together
>> first with OAEP.
>>
>> -- Burt
>>
>> Burt Kaliski, Chief Scientist
>> RSA Laboratories - http://www.rsa.com
>> 20 Crosby Drive, Bedford, MA 01730 USA
>> +1 781 687 7057; fax: +1 781 687 7213; [email-masked]
>>

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA01071 for ietf-smime-bks; Thu, 28 Jan 1999 08:25:17 -0800 (PST)
Received: from puma.baltimore.ie ([email-masked] [194.125.215.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA01067 for ; Thu, 28 Jan 1999 08:25:15 -0800 (PST)
Received: from knuckle (knuckle.baltimore.ie [194.125.215.103]) by puma.baltimore.ie (8.8.5/8.8.5) with SMTP id QAA31163 for ; Thu, 28 Jan 1999 16:27:51 GMT
Received: by localhost with Microsoft MAPI; Thu, 28 Jan 1999 16:27:41 -0000
Message-ID: <[email-masked]>
From: William Whyte
To: "[email-masked]'"
Subject: x9.42 and CMS
Date: Thu, 28 Jan 1999 16:27:40 -0000
Organization: Baltimore Technologies
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

Sorry only to be bringing this up at the Last Call stage, but I
don't have any record of it being discussed before.

I'm concerned that the draft-ietf-smime-x942-04 document does not
provide for the use of any hash algorithm other than SHA-1 when deriving
the key from the shared secret. X9.42 provides the KeyDerivationHash
AlgorithmIdentifier. Would it be possible to change the
KeyAgreeRecipientInfo ASN.1 to read (apologies for poor ASN.1 style):

KeyAgreeRecipientInfo ::= SEQUENCE {
version CMSVersion, -- always set to 3
originator [0] EXPLICIT OriginatorIdentifierOrKey,
ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
keyDerivationHash KeyDerivationHashAlgorithmIdentifier
DEFAULT sha1Identifier,
recipientEncryptedKeys RecipientEncryptedKeys }

We would then change section 2.1.2 of the draft-ietf-smime-x942-04
document so that the line
H is the message digest function SHA-1 [FIPS-180]
becomes
H is a message digest function. In [CMS], the message digest function
is identified by the keyDerivationHash field of the KeyAgreeRecipientInfo
if this is present, and is SHA-1 if this field is absent.

Again, my apologies if it's too late to be bringing up this kind of point.

Cheers,

William

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA01064 for ietf-smime-bks; Thu, 28 Jan 1999 08:24:57 -0800 (PST)
Received: from thehub.knight-hub.com ([email-masked] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA01060 for ; Thu, 28 Jan 1999 08:24:55 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id LAA19436; Thu, 28 Jan 1999 11:27:20 -0500
Message-Id: <[email-masked]>
Message-Id: <[email-masked]>
X-Sender: [email-masked] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Wed, 27 Jan 1999 10:23:58 -0500
To: [email-masked]
From: Russ Housley
Subject: Re: KEKRecpientInfo KEKIdentifier
Cc: [email-masked]
In-Reply-To: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

Peter:

I do not agree.

The idea is that the KEK is distributed out of band and cached by the
recipient(s). The KEKIdentifier is intended to be an index into the cache.

Russ

At 03:13 AM 1/25/99 +0000, Peter Gutmann wrote:
>The KEKIdentifier in the KEKRecipientInfo currently contains a mandatory
OCTET
>STRING which is supposed to contain some magic key ID, however in what I
guess
>would be the most common uses for KEK data encryption (either straight
>file/data encryption or "Included below are last weeks sales figures
encrypted
>with the key we agreed on") there's no conceivable use for this value. Could
>this be made optional like the other fields, or better yet could the whole
>KEKIdentifier be made optional (since it'll be empty without the OCTET
>STRING)? Either:
>
> ...
> kekid [ 0 ] KEKIdentifier OPTIONAL,
> ...
>
>(the preferred option) or alternatively:
>
>KEKidentifier ::= SEQUENCE {
> keyIdentifier OCTET STRING OPTIONAL,
> date GeneralizedTime OPTIONAL,
> other [ 0 ] OtherKeyAttribute OPTIONAL
> }
>
>The former would be nicer since the latter will lead to odd-looking empty
>SEQUENCEs appearing in most KEKRecipientInfo's.
>
>A much uglier alternative is to use a zero-length OCTET STRING to denote "I
>don't know what to do with this field", but that kind of defeats the point of
>having it there in the first place since it's just a kludgy way of saying
OCTET
>STRING OPTIONAL. My preferred solution for this would be KEKIdentifier
>OPTIONAL since it reduces the amount of clutter.
>
>Peter.
>
>

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA01501 for ietf-smime-bks; Wed, 27 Jan 1999 20:25:22 -0800 (PST)
Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by mail.proper.com (8.8.8/8.8.5) with SMTP id UAA01489 for ; Wed, 27 Jan 1999 20:25:20 -0800 (PST)
Received: from 208.236.41.137 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v3.2 SR1); Wed, 27 Jan 99 20:27:25 -0800
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by mail.deming.com with Internet Mail Service (5.5.2232.9) id ; Wed, 27 Jan 1999 20:27:25 -0800
Message-ID: <[email-masked]>
From: "Blake Ramsdell"
To: "[email-masked]'"
Subject: MSG changes in IETF last call -- please review
Date: Wed, 27 Jan 1999 20:27:18 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
X-WSS-ID: 1AB138A710714-01-01
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

These are the changes that I am making in MSG-07 that were requested during
IETF last call.

Let me know if I missed anything.

Changes from draft-ietf-smime-msg-06 to draft-ietf-smime-msg-07:

Clarified section 2.4.1 in the case of multipart/signed (eContent is absent
in that case) (Jim Schaad)
Removed receipt request attribute from section 2.5 (Jim Schaad)
Capitalized MUST for use of the issuerAndSerialNumber CHOICE in section 2.6
(Jim Schaad)
Capitalized NOT in section 3.2.1 regarding reliance on file extensions (Jim
Schaad)
Changed [DH] reference to refer to draft-ietf-smime-x942-*.txt (Jim Schaad)
Replaced section A with ASN.1 module (Jim Schaad)
Rewording of 2.7.3 to explain that the content of the strongly-encrypted
message can be learned by decrypting the weaker message (Russ Housley)
Provided example OID. string for new smime-type values in section 3.2.2
(Russ Housley)
Rewording of section 5 regarding sending two messages with different levels
of encryption (Russ Housley)
Added [RANDOM] reference in section 4.1 and to section B (Russ Housley)
Explained in section 2.5.2 that section A contains all of the MUST and
SHOULD OIDs (Russ Housley)

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

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA12377 for ietf-smime-bks; Wed, 27 Jan 1999 01:32:21 -0800 (PST)
Received: from barbar.esat.kuleuven.ac.be ([email-masked] [134.58.56.153]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA12372 for ; Wed, 27 Jan 1999 01:32:18 -0800 (PST)
Received: from domus.esat.kuleuven.ac.be (domus.esat.kuleuven.ac.be [134.58.189.68]) by barbar (version 8.8.5) with ESMTP id KAA13259; Wed, 27 Jan 1999 10:34:45 +0100 (MET)
Organization: ESAT, K.U.Leuven, Belgium
Date: Wed, 27 Jan 1999 10:34:45 +0100 (MET)
From: "CMS'99"
To: [email-masked]
Subject: CFP: Communications and Multimedia Security '99
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by mail.proper.com id BAA12374
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

[Apologies if you receive this more than once.]

------------------------------------------------------------------------
International Federation for Information Processing

CMS '99
Communications and Multimedia Security

Joint working conference IFIP TC6 and TC11

September 20-21, 1999
Katholieke Universiteit Leuven, Belgium

------------------------------------------------------------------------
Call For Papers

------------------------------------------------------------------------

GOALS and TOPICS of INTEREST

CMS '99 is the fourth in a series of international conferences which aim
at reviewing state-of-the-art issues as well as practical experiences
and new trends in the areas of communications and multimedia systems
security.

It is the intention of the organisers to focus the attention of the
conference presentations and discussions on issues which combine
innovative research work with a highly promising application potential.

Topics of interest include, but are not limited to
* communications systems security
* mobile communications security
* Internet, intranet and extranet security
* security of mobile code
* multimedia systems security
* applied cryptography
* electronic commerce and digital signatures
* security in distributed systems
* secure teleworking, telecooperation, telemedicine
* legal, social and ethical aspects of communication systems security
* standards for communication and multimedia systems security

SUBMISSION DETAILS

Authors are strongly encouraged to submit their papers electronically.
Please email your submission in postscript (or pdf) format to:
[email-masked]
Electronic submissions must be received by March 15, 1999, 23:00 GMT in
order to be considered.

Authors unable to submit electronically are invited to send a cover
letter and 5 (five) copies of an anonymous paper (double-sided copies
preferred) to the Program Chair at the postal address below. Submissions
must be received by the Program Chair on or before March 15, 1999.

The cover letter should contain the paper's title and the names and
affiliations of the authors, and should identify the contact author
including e-mail and postal addresses.

Submissions must not substantially duplicate work that any of the
authors have published elsewhere or have submitted in parallel to any
other conference or workshop that has proceedings. The paper must be
anonymous, with no author names, affiliations, acknowledgments, or
obvious references. It should begin with a title, a short abstract, and
a list of key words, and its introduction should summarise the
contributions of the paper at a level appropriate for a non-specialist
reader. The paper should be at most 5000 words long. A full page figure
is 500 words. It is anticipated that the proceedings will be published by
Kluwer Academic Publishers. Therefore authors are encouraged to use for
their submissions the Kluwer IFIP templates for LaTeX or Word (see
http://www.wkap.com/IFIP).

All submitted papers will be refereed by at least three members of the
International Program Committee according to the standard blind
refereeing procedures. The Conference Proceedings will be published by
an international publisher; copies of the proceedings will be available
at the conference.

Notification of acceptance or rejection will be sent to authors by April
30, 1999. Authors of accepted papers must guarantee that their paper
will be presented at the conference.

Important dates:

* Submission Deadline: March 15, 1999
* Notification: April 30, 1999
* Final camera-ready version: May 21, 1999
* Conference: September 20-21, 1999

To submit a paper, or for further details, please contact:

Prof. Bart Preneel,
Program Committee Chair CMS'99
Katholieke Universiteit Leuven
Dept. Electrical Engineering-ESAT/COSIC
K. Mercierlaan 94, B-3001 Heverlee, BELGIUM

Email: [email-masked]
Tel +32 16 32 10 50 Fax: +32 16 32 19 86
For further details see http://www.esat.kuleuven.ac.be/cosic/cms99/

Program Committee Chair:
B. Preneel, Katholieke Universiteit Leuven, Belgium

Program Committee:
P. Ashley, Queensland University of Technology, Australia
A. Casaca, Inesc, Portugal
S. Fischer-Huebner, Hamburg University, Germany
W. Fumy, Siemens Research, Germany
D. Gollmann, Microsoft Research, UK
D. Gritzalis, Athens University of Economics and Business, Greece
P. Horster, University of Klagenfurt, Austria
S. Katsikas, University of the Aegean, Greece
L.R. Knudsen, University of Bergen, Norway
C. Mitchell, Royal Holloway, University of London, UK
D. Naccache, Gemplus, France
R. Oppliger, BFI, Switzerland
G. Pernul, University of Essen, Germany
R. Posch, TU Graz, Austria
G. Quirchmayr, University of Vienna, Austria
J.-J. Quisquater, Université Catholique de Louvain, Belgium
M. Reiter, Bell Labs, USA
D. Tygar, University of California at Berkeley, USA
P. van Oorschot, Entrust Technologies, Canada
S.H. von Solms, Rand Afrikaans University, South Africa
L. Yngstrom, Stockholm University and Royal Institute of Technology,
Sweden
L Strous, De Nederlandsche Bank NV, The Netherlands, advisory member

Organising Committee Chair:
J. Vandewalle, Katholieke Universiteit Leuven

Organising Committee:
Joris Claessens, Katholieke Universiteit Leuven
Jorge Nakahara, Katholieke Universiteit Leuven
Péla Noë, Katholieke Universiteit Leuven
Vincent Rijmen, Katholieke Universiteit Leuven
Mark Vandenwauver, Katholieke Universiteit Leuven

Main Organiser:
IFIP TC 11 and TC 6

------------------------------------------------------------------------

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA18218 for ietf-smime-bks; Tue, 26 Jan 1999 14:20:31 -0800 (PST)
Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA18211 for ; Tue, 26 Jan 1999 14:20:29 -0800 (PST)
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Tue, 26 Jan 1999 14:18:24 -0800
To: [email-masked]
From: Paul Hoffman / IMC
Subject: ESS changes in IETF last call -- please review
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

Greetings again. There were a bunch of requests for changes to the ESS-10
draft in IETF last call (which ended yesterday). The following is the list
of changes I intend to make in -11, which will then hopefully be sent by
Jeff Schiller to the IESG. Blake and Russ will be sending out similar lists
soon.

If there are any issues that were posted to the list that I missed (or got
wrong), please let me know in the next day or two. Please note that all of
these were already discussed on the list, so new requests at this very late
date might be frowned upon...

D. Changes from draft-ietf-smime-ess-10 to draft-ietf-smime-ess-11

1: Added wording about signing certificates (Section 5) to the introduction.

1.3.4: Added the sentence at the end of the first paragraph. "All of the
attributes defined in this document, other than ContentHints and
ContentIdentifier, MUST be carried in a CMS SignedAttributes type, and MUST
NOT be carried in an UnsignedAttributes or an UnprotectedAttributes type."

1.3.4: Removed the macValue description because it was removed from CMS.

1.4: Second paragraph, replaced second sentence to indicate that some
attributes might have to be omitted. "The main disadvantage is that the
gateway must check for the presence of certain attributes in the other
signerInfos and either omit or copy those attributes."

2.1: Added paragraph at the end of this section saying that you shouldn't
request that receipts be sent to people who don't have the original
message. "A receipt request can indicate that receipts be sent to many
places, not just to the sender (in fact, the receipt request might indicate
that the receipts should not even go to the sender). In order to verify a
receipt, the recipient of the receipt must be the originator or a recipient
of the original message. Thus, the sender SHOULD NOT request that receipts
be sent to anyone who does not have an exact copy of the message."

2.6: Added paragraph near beginning about accepting more than one signed
receipt. "Although receipients are not supposed to send more than one
signed receipt, receiving agents SHOULD be able to accept multiple signed
receipts from a recipient."

2.8: Changed Version to ESSVersion and defined it as:
ESSVersion ::= INTEGER { v1(1) }

3: Clarified the last paragraph to indicate ranked levels. "The labels
often describe ranked levels..."

4.2.3.2: Clarified step 2 to show that, if the mlExpansionHistory was not
found, you sign that whole message and stop.

4.4: Removed the comment "-- EntityIdentifier is imported from [CMS]"

5.1: Changed "changing" to "replacing".

5.4: The paragraph beginning "The first certificate..." was changed to
reflect the addition of the SKI to the SignerInfo. "The first certificate
identified in the sequence of certificate identifiers MUST be the
certificate used to verify the signature. The encoding of the ESSCertID for
this certificate SHOULD include the issuerSerial field. If other
constraints ensure that issuerAndSerialNumber will be present in the
SignerInfo, the issuerSerial field MAY be omitted. The certificate
identified is used during the signature verification process. If the hash
of the certificate does not match the certificate used to verify the
signature, the signature MUST be considered invalid."

5.4.1: Changed "CMS" to "[CERT]" for the reference.

6: Entire section is new:
==========
All security considerations from [CMS] and [SMIME3] apply to applications
that use procedures described in this document.

As stated in Section 2.3, a recipient of a receipt request must not send
back a reply if it cannot validate the signature. Similarly, if there
conflicting receipt requests in a message, the recipient must not send back
receipts, since an attacker may have inserted the conflicting request.
Sending a signed receipt to an unvalidated sender can expose information
about the recipient that it may not want to expose to unknown senders.

Senders of receipts should consider encrypting the receipts to prevent a
passive attacker from gleaning information in the receipts.

Senders must not rely on recipients' processing software to correctly
process security labels. That is, the sender cannot assume that adding a
security label to a message will prevent recipients from viewing messages
the sender doesn't want them to view. It is expected that there will be
many S/MIME clients that will not understand security labels but will still
display a labelled message to a recipient.

A receiving agent that processes security labels must handle the content of
the messages carefully. If the agent decides not to show the message to the
intended recipient after processing the security label, the agent must take
care that the recipient does not accidentally see the content at a later
time. For example, if an error response sent to the originator contains the
content that was hidden from the recipient, and that error response bounces
back to the sender due to addressing errors, the original recipient can
possibly see the content since it is unlikely that the bounce message will
have the proper security labels.

A man-in-the-middle attack can cause a recipient to send receipts to an
attacker if that attacker has a signature that can be validated by the
recipient. The attack consists of intercepting the original message and
adding a mLData attribute that says that a receipt should be sent to the
attacker in addition to whoever else was going to get the receipt.

Mailing lists that encrypt their content may be targets for
denial-of-service attacks if they do not use the mailing list management
described in Section 4. Using simple RFC822 header spoofing, it is quite
easy to subscribe one encrypted mailing list to another, thereby setting up
an infinite loop.

Mailing List Agents need to be aware that they can be used as oracles for
the the adaptive chosen ciphertext attack described in [CMS]. MLAs should
notify an administrator if a large number of undecryptable messages are
received.

When verifying a signature using certificates that come with a [CMS]
message, the recipient should only verify using certificates previously
known to be valid, or certificates that have come from a signed
SigningCertificate attribute. Otherwise, the attacks described in Section 5
can cause the receiver to possibly think a signature is valid when it is
not.
==========

--Paul Hoffman, Director
--Internet Mail Consortium

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA18303 for ietf-smime-bks; Sun, 24 Jan 1999 06:11:10 -0800 (PST)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA18299 for ; Sun, 24 Jan 1999 06:11:07 -0800 (PST)
Received: from cs26.cs.auckland.ac.nz ([email-masked] [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id DAA03311 for ; Mon, 25 Jan 1999 03:13:21 +1300 (NZDT) (sender [email-masked])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <91718720129757>; Mon, 25 Jan 1999 03:13:21 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: KEKRecpientInfo KEKIdentifier
Reply-To: [email-masked]
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Mon, 25 Jan 1999 03:13:21 (NZDT)
Message-ID: <[email-masked]>
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

The KEKIdentifier in the KEKRecipientInfo currently contains a mandatory OCTET
STRING which is supposed to contain some magic key ID, however in what I guess
would be the most common uses for KEK data encryption (either straight
file/data encryption or "Included below are last weeks sales figures encrypted
with the key we agreed on") there's no conceivable use for this value. Could
this be made optional like the other fields, or better yet could the whole
KEKIdentifier be made optional (since it'll be empty without the OCTET
STRING)? Either:

...
kekid [ 0 ] KEKIdentifier OPTIONAL,
...

(the preferred option) or alternatively:

KEKidentifier ::= SEQUENCE {
keyIdentifier OCTET STRING OPTIONAL,
date GeneralizedTime OPTIONAL,
other [ 0 ] OtherKeyAttribute OPTIONAL
}

The former would be nicer since the latter will lead to odd-looking empty
SEQUENCEs appearing in most KEKRecipientInfo's.

A much uglier alternative is to use a zero-length OCTET STRING to denote "I
don't know what to do with this field", but that kind of defeats the point of
having it there in the first place since it's just a kludgy way of saying OCTET
STRING OPTIONAL. My preferred solution for this would be KEKIdentifier
OPTIONAL since it reduces the amount of clutter.

Peter.

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA27676 for ietf-smime-bks; Sat, 23 Jan 1999 20:15:10 -0800 (PST)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA27672 for ; Sat, 23 Jan 1999 20:15:07 -0800 (PST)
Received: from cs26.cs.auckland.ac.nz ([email-masked] [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id RAA00407; Sun, 24 Jan 1999 17:16:39 +1300 (NZDT) (sender [email-masked])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <91715139926677>; Sun, 24 Jan 1999 17:16:39 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Avoiding Small Subgroup Attack in X9.42 Diffie-Hellman
Cc: [email-masked]
Reply-To: [email-masked]
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Sun, 24 Jan 1999 17:16:39 (NZDT)
Message-ID: <[email-masked]>
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

>In the x942 draft we presently specify that in some instances of
>ephemeral-static Diffie-Hellman, public key validation does not need to be
>performed; but for static-static Diffie-Hellman, public key validation is
>needed. I would like to call to the group's attention another option. If
>the prime p is chosen so that p-1=2*q*r where r is a product of large
>(greater than 160 bits) primes then the "small subgroup" attacks are not a
>concern here (except for the possible loss of 1 bit of the private key).
>Perhaps we could specify this as another option for those situations that
>require resistance to these attacks.
>
>If we did decide to allow this option, we would then have to specify how to
>choose the prime to be of this form. We could either change the prime
>generation algorithm, or we could specify that the prime generation algorithm
>should be run enough number of times until this condition is met.

This is just them Lim-Lee algorithm, which is already defined fairly clearly,
so it wouldn't be hard to include it. I'd be quite keen on this option since
it avoids using the (unnecessarily complex) FIPS 186 kosherizer, and has, as
you point out, some useful properties (it may also be faster, has anyone
compared it to the kosherizer for speed?). One possible downside is that it's
not so easy to generate a prime of exactly n bits, but I can't see why this
would be a drawback.

Peter.

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA19370 for ietf-smime-bks; Tue, 19 Jan 1999 08:47:26 -0800 (PST)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA19365 for ; Tue, 19 Jan 1999 08:47:23 -0800 (PST)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id RAA23410 for ; Tue, 19 Jan 1999 17:49:17 +0100
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id RAA16792 for ; Tue, 19 Jan 1999 17:51:50 +0100 (NFT)
Message-ID: <[email-masked]>
Date: Tue, 19 Jan 1999 17:49:35 +0100
From: Denis Pinkas
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: "Ietf-Smime (E-mail)"
Subject: Re: Last Call Comments on CMS-10
References: <2FBF98FC7852CF11912A0000000000010FF8A6D7@localhost>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

Russ,

As advertised at the last IETF meeting in Orlando, I have a comment on the
lastest version of the CMS draft published.

On page 12, in the section 5.6 Message Signature Validation Process the text
says “ The input to the signature validation process includes the result of the
message digest calculation process and the signer’s public key”.

The problem is how to get the right signer’s public key and how to know that is
valid or not. If no indication is given, then different results will be obtained
between different implementations. The process is thus much more complicated
than currently indicated as this is explained later on.

The knowledge of the certificate of the signer as well as the time of the
signature are both important. If there is an ambiguity on one or the other
component then the end-result may be quite the opposite.

The certificate is important because a user might use the same public key for
different certificates which include different attributes. In such a case it is
important to know which certificate has been selected by the signer.

The time of the signature is important because the certificate may have been
revoked since the document was signed and thus it is important to verify that
the certificate was valid when the document was signed.

In order to care for these cases, the following text is proposed for section
5.6:

“ When a signed CMS structure is received, it is important to know who the
signer is and whether the digital signature valid or not. The certificate allows
to identify the signer and possibly some other attributes. A signer may have
multiple certificates, e.g. with the same public key in it. In such a case,
these certificates will have different security attributes in it. It is thus
important to know which certificate has been selected by the signer.

The time of the signature is important because the certificate may have been
revoked since the document was signed and thus it is important to verify that
the certificate was valid when the document was signed.

This means that the certificate to be used for the verification process has to
be verified as valid, i.e. before verifying that the result of the message
digest, the digital signature and the signer’s public key match altogether.

Two cases may be considered:

1) the certificate of the signer is already securely known in advance from the
context and is checked to be valid according to a security policy (i.e. not
individually revoked and the trusted path not revoked as well). In that case it
may be used directly and the public key may be extracted out of it and used as
an input to the verification process.

2) Neither the certificate of the signer, nor the signature time are known in
advance from the context.. In such a case it is needed to obtain all the
information, i.e. both the certificate of the signer and the correct signing
time, from the data that has been received, in particular from the CMS
structure.

The SignerIdentifier may be used to obtain the right certificate. In some cases
that information may however be insufficient or/and insecure (see [ESS], section
5.4) and the ESSCertId signed attribute shall be used in addition.

If the signer’s certificate and all the cross-certificates from the
certification path are all valid (e.g. not on the appropriate certificate
revocation list (CRL) or authority revocation list (ARL) or a « not revoked »
status is given back by an OCSP server) and during their validity period at the
time the verification is made, then the public key may be used as an input to
the signature verification process. Otherwise the signature is said to be
invalid.

If the signer’s certificate has been revoked but all the cross-certificates from
the certification path are valid (e.g. at the time the verification is made,
then additional information is needed to know whether the certificate may be
used or not. It is then needed to verify that the signer’s certificate was valid
at the time the signature was made. The signing-time attribute, when present,
may only be used as an hint, since it only specify the time at which the signer
(purportedly) performed the signing process. The time contained in a time stamp
over the CMS structure from a TSA (Time Stamping Authority) will be needed to
know whether or not the certificate was revoked at the time the signature was
made. If the time from the time stamping authority is prior to the reviocation
of the signers’ certificate then the public key may be used as an input to the
signature verification process. Otherwise the signature is said to be invalid.

If one of the cross-certificates is revoked, a time stamp prior to the
revocation of that cross-certificate shall be obtained for that
cross-certificate (or alternatively on the whole certification path). This will
prove that the cross-certificate was valid before the revocation (or even the
key compromise) of that CA. If it is missing, the signature is said to be
invalid.

The input to the signature verification process includes the result of the
message digest calculation process and the signer's public key. The details of
the signature verification depend on the signature algorithm employed.

The recipient may not rely on any message digest values computed by the
originator. If the signedData signerInfo includes signedAttributes, then the
content message digest must be calculated as described in section 5.4. For the
signature to be valid, the message digest value calculated by the recipient must
be the same as the value of the messageDigest attribute included in
thesignedAttributes of the signedData signerInfo. »

Denis

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA07218 for ietf-smime-bks; Sun, 17 Jan 1999 17:12:25 -0800 (PST)
Received: from speedy.rtfm.com ([208.217.207.133]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA07213; Sun, 17 Jan 1999 17:12:24 -0800 (PST)
Received: (ekr@localhost) by speedy.rtfm.com (8.9.1/8.6.4) id RAA16233; Sun, 17 Jan 1999 17:15:09 -0800 (PST)
To: Russ Housley
Cc: Paul Hoffman / IMC , "Linn, John" , "'IETF SMIME list'"
Subject: Re: Crypto-oriented comments on x942-04
References: <"Linn, John"'s message of "Wed, 13 Jan 1999 13:30:42 -0500"> <[email-masked]> <[email-masked]> <[email-masked]>
From: EKR
Date: 17 Jan 1999 17:15:08 -0800
In-Reply-To: Russ Housley's message of "Sun, 17 Jan 1999 19:49:23 -0500"
Message-ID:
Lines: 21
X-Mailer: Gnus v5.6.43/XEmacs 20.4 - "Emerald"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

Russ Housley writes:
> You are correct. We did deal with this case. However, I think is is a good
> idea to use the algorithm in such a way that future users of CMS cannot
> make a simple mistake and be susceptable to the partion attack.
I agree.

> >>And, the fix is
> >> very simple. We need to simply include the key length in the hash input.
> >I'm prepared to do it, but I'm not sure that just shoving it in the
> >pubInfo is the right choice. I'll think about this and try to write
> >up a proposal by monday.
>
> If you are going to the RSA Confernce, I will gladly have a hallway chat
> regarding the best way forward.
Yes, I'll be there.

-Ekr

--
[Eric Rescorla [email-masked]]

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA06940 for ietf-smime-bks; Sun, 17 Jan 1999 16:57:06 -0800 (PST)
Received: from smtp4.erols.com (smtp4.erols.com [207.172.3.237]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA06934; Sun, 17 Jan 1999 16:57:04 -0800 (PST)
Received: from rhousley_laptop.spyrus.com (207-172-46-225.s225.tnt9.ann.erols.com [207.172.46.225]) by smtp4.erols.com (8.8.8/smtp-v1) with SMTP id TAA17077; Sun, 17 Jan 1999 19:58:39 -0500 (EST)
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Sun, 17 Jan 1999 19:49:23 -0500
To: EKR
From: Russ Housley
Subject: Re: Crypto-oriented comments on x942-04
Cc: Paul Hoffman / IMC , "Linn, John" , "'IETF SMIME list'"
In-Reply-To:
References: <"Linn, John"'s message of "Wed, 13 Jan 1999 13:30:42 -0500"> <[email-masked]> <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

Eric:

At 02:24 PM 1/16/99 -0800, EKR wrote:
>Russ Housley writes:
>> >I don't see how this makes any difference. Remember, all we're talking
>> >about is the data that's input to the key expansion function. The
>> >actual parameters that are to be used have to be conveyed separately
>> >in any case, because this data is subsequently hashed. The only real effect
>> >of including the algorithmId at all is to produce different keys for
>> >different algorithms using the same pubInfo. It could easily be omitted
>> >entirely.
>>
>> I think you are missing an important point. RC2 with a 40 bit key and RC2
>> with a 128 bit key result in the same inputs to the hash algorithm. If an
>> attacker is able to get a less sensitive message to be encrypted with the
>> 40 bit key, this message can be readily attacked by brute force. Should a
>> more sensitive message be encrypted with the 128 bit key, the attacker
>> already knows the first 40 bits of the key.
>This is incorrect. By fiat, when used for key encryption, RC2 ALWAYS
>uses a 128 bit key. The 40 bits refers only to the effective key length.
>It may be possible to go from the 40 bit key to having some information
>about the 128 bit key, but it's certainly not as simple as simply
>knowing the first 40 bits.

You are correct. We did deal with this case. However, I think is is a good
idea to use the algorithm in such a way that future users of CMS cannot
make a simple mistake and be susceptable to the partion attack.

>>And, the fix is
>> very simple. We need to simply include the key length in the hash input.
>I'm prepared to do it, but I'm not sure that just shoving it in the
>pubInfo is the right choice. I'll think about this and try to write
>up a proposal by monday.

If you are going to the RSA Confernce, I will gladly have a hallway chat
regarding the best way forward.

ANSI X9.42 is going to be changed based on this thread. It will say
something like:
If the algorithm identifier does not unambigiously specify
the output key length, then that key length must be inclused
in spuuPubInfo.

Russ

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA05145 for ietf-smime-bks; Sun, 17 Jan 1999 10:22:22 -0800 (PST)
Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA05141 for ; Sun, 17 Jan 1999 10:22:21 -0800 (PST)
Received: from 208.236.41.137 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v3.2 SR1); Sun, 17 Jan 99 10:23:33 -0800
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by mail.deming.com with Internet Mail Service (5.5.2232.9) id ; Sun, 17 Jan 1999 10:23:33 -0800
Message-ID: <[email-masked]>
From: "Blake Ramsdell"
To: "[email-masked]'"
Subject: MIME types for inbound / outbound
Date: Sun, 17 Jan 1999 10:23:33 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
X-WSS-ID: 1ABCF52F26499-01-01
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

The MIME type for application/pkcs7-mime was registered in RFC2311 (March of
1998). All applications should at the very least be prepared to parse this
as equivalent to application/x-pkcs7-mime, if not emitting it as well.

Our products don't emit it, but we can parse both. I'm fixing it. Everyone
else, please do the same (emit application/pkcs7-mime and recognize both
versions). Part of the reason that I emitted the x- variant was because
other applications couldn't read the non-x- variant. I suspect that this
should stop on the anniversary of the registration of the MIME type.

Applications may also wish to put in a way to force the outgoing MIME type
to be the x- variant as a configuration option, just in case.

Flames / comments welcome.

Blake

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA08421 for ietf-smime-bks; Sat, 16 Jan 1999 14:22:38 -0800 (PST)
Received: from speedy.rtfm.com ([208.217.207.133]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA08416; Sat, 16 Jan 1999 14:22:37 -0800 (PST)
Received: (ekr@localhost) by speedy.rtfm.com (8.9.1/8.6.4) id OAA06107; Sat, 16 Jan 1999 14:24:56 -0800 (PST)
To: Russ Housley
Cc: Paul Hoffman / IMC , "Linn, John" , "'IETF SMIME list'"
Subject: Re: Crypto-oriented comments on x942-04
References: <"Linn, John"'s message of "Wed, 13 Jan 1999 13:30:42 -0500"> <[email-masked]> <[email-masked]>
From: EKR
Date: 16 Jan 1999 14:24:55 -0800
In-Reply-To: Russ Housley's message of "Sat, 16 Jan 1999 13:56:24 -0500"
Message-ID:
Lines: 32
X-Mailer: Gnus v5.6.43/XEmacs 20.4 - "Emerald"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

Russ Housley writes:
> >I don't see how this makes any difference. Remember, all we're talking
> >about is the data that's input to the key expansion function. The
> >actual parameters that are to be used have to be conveyed separately
> >in any case, because this data is subsequently hashed. The only real effect
> >of including the algorithmId at all is to produce different keys for
> >different algorithms using the same pubInfo. It could easily be omitted
> >entirely.
>
> I think you are missing an important point. RC2 with a 40 bit key and RC2
> with a 128 bit key result in the same inputs to the hash algorithm. If an
> attacker is able to get a less sensitive message to be encrypted with the
> 40 bit key, this message can be readily attacked by brute force. Should a
> more sensitive message be encrypted with the 128 bit key, the attacker
> already knows the first 40 bits of the key.
This is incorrect. By fiat, when used for key encryption, RC2 ALWAYS
uses a 128 bit key. The 40 bits refers only to the effective key length.
It may be possible to go from the 40 bit key to having some information
about the 128 bit key, but it's certainly not as simple as simply
knowing the first 40 bits.

>And, the fix is
> very simple. We need to simply include the key length in the hash input.
I'm prepared to do it, but I'm not sure that just shoving it in the
pubInfo is the right choice. I'll think about this and try to write
up a proposal by monday.

-Ekr

--
[Eric Rescorla [email-masked]]

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA07845 for ietf-smime-bks; Sat, 16 Jan 1999 11:43:54 -0800 (PST)
Received: from smtp1.erols.com (smtp1.erols.com [207.172.3.234]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA07840; Sat, 16 Jan 1999 11:43:52 -0800 (PST)
Received: from rhousley_laptop.spyrus.com (207-172-39-2.s2.tnt10.ann.erols.com [207.172.39.2]) by smtp1.erols.com (8.8.8/8.8.5) with SMTP id OAA10332; Sat, 16 Jan 1999 14:45:23 -0500 (EST)
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Sat, 16 Jan 1999 13:56:24 -0500
To: EKR
From: Russ Housley
Subject: Re: Crypto-oriented comments on x942-04
Cc: Paul Hoffman / IMC , "Linn, John" , "'IETF SMIME list'"
In-Reply-To:
References: <"Linn, John"'s message of "Wed, 13 Jan 1999 13:30:42 -0500"> <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

Eric:

>> >> 7. Section 2.1.2: Identifying an algorithm by an OID rather than an
>> >> AlgorithmID risks losing some specifics about the algorithm. For
instance,
>> >> in a variable-key-size block cipher (e.g., RC5), the AlgorithmID
carries the
>> >> key size, so this information would be lost. As a result, it may be
possible
>> >> for an opponent to substitute a key of one size for a key of a different
>> >> size, which may lead to an attack that recovers the key one part at a
time.
>> >> Presumably, the reason for avoiding a full AlgorithmID is that some
of its
>> >> parameters are message-specific, such as IVs, but perhaps there is some
>> >> middle ground. Including the key size as an optional field of
OtherInfo is
>> >> one possibility. Other parameters that will be lost in the case of
RC5 are
>> >> the block size and the number of rounds.
>> >
>> >I think this is weird, but this is how X9.42 does it, so our
>> >choices are kind of limited.
>>
>> This worries me. If there is a substitution attack that can recover the
>> key, I think we need to look at it VERY CAREFULLY. Has this same topic been
>> discussed on the X9.42 list? If so, can someone summarize the result? If
>> not, why not?
>
>I don't see how this makes any difference. Remember, all we're talking
>about is the data that's input to the key expansion function. The
>actual parameters that are to be used have to be conveyed separately
>in any case, because this data is subsequently hashed. The only real effect
>of including the algorithmId at all is to produce different keys for
>different algorithms using the same pubInfo. It could easily be omitted
>entirely.

I think you are missing an important point. RC2 with a 40 bit key and RC2
with a 128 bit key result in the same inputs to the hash algorithm. If an
attacker is able to get a less sensitive message to be encrypted with the
40 bit key, this message can be readily attacked by brute force. Should a
more sensitive message be encrypted with the 128 bit key, the attacker
already knows the first 40 bits of the key.

Off the top of my head, I am not sure how the attacker can get this
situation to happen with S/MIME v3, but I am in favor of a robust security
standard. We know that people are looking at CMS for other purposes. One
of those future uses may permit an attack like this one. And, the fix is
very simple. We need to simply include the key length in the hash input.

Russ

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA23766 for ietf-smime-bks; Fri, 15 Jan 1999 08:44:20 -0800 (PST)
Received: (from phoffman@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA23757; Fri, 15 Jan 1999 08:44:17 -0800 (PST)
Date: Fri, 15 Jan 1999 08:44:17 -0800 (PST)
Message-Id: <[email-masked]>
From: List Manager of ietf-smime
To: [email-masked]
Subject: How to be removed from this list
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

Greetings again. Occasionally, people will sign up for a mailing list and
forget how to be removed. This message is a reminder for those folks.

First off, when you subscribe to a mailing list, you almost always get a
first message from the list owner telling you about the mailing list, and
explaining how to unsubscribe. It is always a good idea to keep those
messages, since you never know when you will need to unsubscribe. This is
particularly useful when you change email addresses, because it is difficult
to unsubscribe from a list after you have a different mailing address.

In the case of this list, the method to unsubscribe is to send a message
to:
[email-masked]
with the single word:
unsubscribe
in the body of the message. This is the same as it always has been.

To make this easier for you, I have crafted this message so that you should
be able to simply reply to this message, and the reply address should be
[email-masked] (although some mail clients screw this up...).
Remove everything from the body of the reply, and put in the single word:
unsubscribe

If you have tried this method, and the mailing list software won't let you
unsubscribe, it is probably because your address has changed. In that case,
please send a message to [email-masked] stating which list (or lists) you
want to unsubscribe from, and what you think your previous address was.
There is a human (that's me!) who will then try to take care of your
request, often within a few days.

--Paul Hoffman, Director
--Internet Mail Consortium

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA22894 for ietf-smime-bks; Fri, 15 Jan 1999 07:05:30 -0800 (PST)
Received: from smtp3.erols.com (smtp3.erols.com [207.172.3.236]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA22890 for ; Fri, 15 Jan 1999 07:05:29 -0800 (PST)
Received: from rhousley_laptop.spyrus.com (207-172-112-3.s3.tnt4.ann.erols.com [207.172.112.3]) by smtp3.erols.com (8.8.8/8.8.5) with SMTP id KAA00859; Fri, 15 Jan 1999 10:05:39 -0500 (EST)
Message-Id: <[email-masked]>
Message-Id: <[email-masked]>
Message-Id: <[email-masked]>
X-Sender: [email-masked] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Fri, 15 Jan 1999 00:42:31 -0500
To: EKR
From: Russ Housley
Subject: Re: Crypto-oriented comments on x942-04
Cc: [email-masked], [email-masked]
In-Reply-To:
References: <"Linn, John"'s message of "Wed, 13 Jan 1999 13:30:42 -0500">
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

Eric, John, et. al.:

>> 5. Section 2.1.2: In Section 2.1.1, ZZ is a field element or integer, so
>> some conversion to an octet string is required. The usual conversion,
>> following IEEE P1363 and ANSI X9.42, is a most significant byte first
>> representation. ANSI X9.42 specifies that the result has as few bytes as
>> possible (i.e., no leading zeros); IEEE P1363 says that the result has the
>> same length in octets as the longest field element (i.e., the length of the
>> prime p), with leading zeros. So, there's an apparent IEEE P1363 vs. ANSI
>> X9.42 discrepancy. Given that IEEE P1363 is currently in ballot and ANSI
>> X9.42 needs to be recirculated, we'd recommend that IEEE P1363 be followed.
>> In any case, some representation should be stated.
>Agreed. Myself I prefer fewest octets.

I disagree with Eric.

I believe that ZZ should be the same size as p. I think that this is much
easier to implement. An implementation must have a buffer the size of p
since the result of the exponentiation could have no leading zero octets.
So, the implementation can simply use the entire buffer as the first input
to the hash function.

I have asked a couple implementors what they do. So far, I have not found
anyone that is dropping leading zero octets.

It turns out that the ANSI X9F1 working group was meeting today. Good
timing. The ANSI X9F1 working group discussed this comment, and the ANSI
X9.42 draft will be changed to align with IEEE P1363.

To me, these three points are compelling. I strongly suggest that we adopt
Burt's and Lisa's recommendation.

>> 7. Section 2.1.2: Identifying an algorithm by an OID rather than an
>> AlgorithmID risks losing some specifics about the algorithm. For instance,
>> in a variable-key-size block cipher (e.g., RC5), the AlgorithmID carries the
>> key size, so this information would be lost. As a result, it may be possible
>> for an opponent to substitute a key of one size for a key of a different
>> size, which may lead to an attack that recovers the key one part at a time.
>> Presumably, the reason for avoiding a full AlgorithmID is that some of its
>> parameters are message-specific, such as IVs, but perhaps there is some
>> middle ground. Including the key size as an optional field of OtherInfo is
>> one possibility. Other parameters that will be lost in the case of RC5 are
>> the block size and the number of rounds.
>I think this is weird, but this is how X9.42 does it, so our
>choices are kind of limited.

I think it would be inappropriate to assign OIDs that did not contain
message-specific data, such as IVs. Assigning additional OIDs does not
seem to be the way forward.

This "partition attack" is a real concern. That input to the hash function
must unambiguously identify the output key length. However, I think that
there is a way forward. The key length is either implicit from the
algorithm identifier (e.g., DES) or it is carried as a parameter in the
algorithm identifier (e.g., RC2). So, the recipient can easily determine
the value to pass to the key derivation function. Perhaps we can always
put the key length in the pubInfo. If a UKM is present, the pubInfo can be
the concatenation of the key length and the UKM.

What do others think about this approach? If this approach is acceptable
to everyone, then we need work out the exact encodings.

>> 10. Section 2.1.2: Why can't counter be an INTEGER? That would avoid the
>> unnecessary definition of an encoding format for the counter, while
>> maintaining an unambiguous encoding.
>Again, this is how X9.42 does it.

This is done to aid implementors. By making the field fixed length, an
implentation can use a constant to initialize OtherInfo. Then, the counter
portion is incremented for each invocation of the Hash function.

>> 11. Section 2.1.2: Why must pubInfo, if present, contain a minimum of 512
>> bits? A minimum of 160 bits is sufficient to avoid collisions; the encoding
>> as an OCTET STRING is unambiguous and prevents length-extension attacks.
>Russ, you care to speak up on this?

Since the internal block size of SHA-1 is 512 bits, this seems to be the
maximum amount of entorpy that can be added with a public value.

This comment would indicate that sizes between 160 and 512 bits are useful.

Should we standarize on a single length? 512 bits?

>> 13. Section 2.1.3: KEK computation states that each algorithm requires a
>> specific size key. But some algorithms have variable-size keys, and it's
>> possible that future algorithms will require more than just a random string
>> (e.g., more structure). So, it would be preferable to say that the currently
>> proposed S/MIME algorithms assume a random string, perhaps with parity
>> changes.
>Well, the output of this process is necessarily a random string. Any
>algorithm which needs a key with more structure should have a pre-processor
>which produces one from a bit string.

I agree with Eric. I do not think that we can anticipate the needs of
these future algorithms. Rather, when a future algorithm is defined, a
mapping between the "random" X9.42 output and the structured input needed
by the algorithm can be defined.

>> 16. Section 2.2: Should a lower bound on the prime p also be given?
>Probably. 1024 and be done with it?

Eric, I assume that you mean p must be at least 1024 bits long. Not, p
must be greater than 1024.

>> 17. Sections 2.3 and 2.4: Key validation is not the only way to prevent a
>> small-subgroup attack. Another method is cofactor multiplication, as
>> described in IEEE P1363 and in [LAW98]. Cofactor multiplication performs an
>> additional operation on the shared secret value so that it is not in a small
>> subgroup. (There is a "compatibility mode" that keeps the shared secret
>> value the same as in ordinary Diffie-Hellman when the system is not under
>> attack; discussion is available in B.S. Kaliski Jr. Compatible cofactor
>> multiplication for Diffie-Hellman primitives. Electronics Letters,
>> 34(25):2396-2397, December 10, 1998.)
>>
>> Another method is to choose the primes p and q so that p = qj + 1 where j is
>> small and to check the received public key against a small set of excluded
>> values. In this case, the leakage due to a small subgroup attack will be
>> only a few bits.
>I have to admit that I'm not enough of a mathematician to have
>an informed opinion on this topic. I'd certainly far rather not
>change the shared-secret value, and I don't want to require
>an extra operation either (for perforamnce reasons).

Eric, your response here does not tell me what you plan to do. Do you
know yet?

Russ

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA22877 for ietf-smime-bks; Fri, 15 Jan 1999 07:04:18 -0800 (PST)
Received: from smtp3.erols.com (smtp3.erols.com [207.172.3.236]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA22871 for ; Fri, 15 Jan 1999 07:04:15 -0800 (PST)
Received: from rhousley_laptop.spyrus.com (207-172-112-3.s3.tnt4.ann.erols.com [207.172.112.3]) by smtp3.erols.com (8.8.8/8.8.5) with SMTP id KAA00842; Fri, 15 Jan 1999 10:05:37 -0500 (EST)
Message-Id: <[email-masked]>
Message-Id: <[email-masked]>
X-Sender: [email-masked] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Thu, 14 Jan 1999 16:52:12 -0500
To: [email-masked]
From: Russ Housley
Subject: Avoiding Small Subgroup Attack in X9.42 Diffie-Hellman
Cc: [email-masked]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

I am forwarding the following message from Robert Zuccherato.

Russ

= = = = = = = = = =

In the x942 draft we presently specify that in some instances of
ephemeral-static Diffie-Hellman, public key validation does not need to be
performed; but for static-static Diffie-Hellman, public key validation is
needed. I would like to call to the group's attention another option. If
the prime p is chosen so that p-1=2*q*r where r is a product of large
(greater than 160 bits) primes then the "small subgroup" attacks are not a
concern here (except for the possible loss of 1 bit of the private key).
Perhaps we could specify this as another option for those situations that
require resistance to these attacks.

I believe that the situations where resistance to these attacks is required
will remain the same. However, we could allow the option of choosing the
prime p to have this form. This may be a desirable option, as it appears
that performing public key validation may be encumbered. However, it is
not clear that this should be the only option because even with this, one
bit of the key could be leaked, which may not be acceptable in some
situations. Also, parameter generation will become more complicated.

If we did decide to allow this option, we would then have to specify how to
choose the prime to be of this form. We could either change the prime
generation algorithm, or we could specify that the prime generation
algorithm should be run enough number of times until this condition is met.

Thank you,

Robert Zuccherato

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA25256 for ietf-smime-bks; Thu, 14 Jan 1999 15:12:02 -0800 (PST)
Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA25252 for ; Thu, 14 Jan 1999 15:12:00 -0800 (PST)
Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id ; Thu, 14 Jan 1999 15:13:02 -0800
Message-ID: <2FBF98FC7852CF11912A0000000000010ECB5C13@localhost>
From: "Jim Schaad (Exchange)"
To: "Ietf-Smime (E-mail)" , "Blake Ramsdell (E-mail)"
Cc: "Russ Housley (E-mail)"
Subject: Last Call MSG-Draft: ASN Module for MSG draft
Date: Thu, 14 Jan 1999 15:12:59 -0800
X-Mailer: Internet Mail Service (5.5.2232.9)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

Here is a proposed module to replace appendix A in the Message draft. A
couple of comments about this:

We are putting in some duplicate information that I think should be lost
from the draft for various reasons (either duplication of data in other
modules or "obsolete" being the biggest). This information was required in
the V2 message draft as there was no other place to reference the
information, but should now be deleted in my opinion.

I suggest we
1) Delete the digest algorithms -- duplication of CMS
2) rsaEncryption from the Asymetric Encrption section and put a note in
about why we have rsa and id-dsa here
3) All but md2WithRSAEncryption from the signature algorithms section and
put in a comment about how it might be on certificates but should not be in
messages
4) Delete signing time from the bottom section -- duplication of CMS and
insufficent data to implement anyway.

jim

SecureMimeMessageV3
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) smime(4) }

DEFINITIONS IMPLICIT TAGS ::=
BEGIN

IMPORTS
-- Cryptographic Message Syntax
SubjectKeyIdentifier, IssuerAndSerialNumber, RecipientKeyIdentifier
FROM CryptographicMessageSyntax
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) };

-- id-aa is the arc with all new authenticated and unauthenticated
attributes
-- produced the by S/MIME Working Group

id-aa OBJECT IDENTIFIER ::= {iso(1) member-body(2) usa(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) attributes(2)}

-- S/MIME Capabilities provides a method of broadcasting the symetric
capabilities
-- understood. Algorithms should be ordered by preference and grouped
by type

smimeCapabilities OBJECT IDENTIFIER ::=
{iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 15}

SMIMECapability ::= SEQUENCE {
capabilityID OBJECT IDENTIFIER,
parameters ANY DEFINED BY capabilityID OPTIONAL }

SMIMECapabilities ::= SEQUENCE OF SMIMECapability

-- Encryption Key Preference provides a method of broadcasting the prefered
-- encryption certificate.

id-aa-encrypKeyPref OBJECT IDENTIFIER ::= {id-aa 11}

SMIMEEncryptionKeyPreference ::= CHOICE {
issuerAndSerialNumber [0] IssuerAndSerialNumber,
receipentKeyId [1] RecipientKeyIdentifier,
subjectAltKeyIdentifier [2] SubjectKeyIdentifier
}

-- The Content Encryption Algorithms defined for SMIME are:

-- Triple-DES is the manditory algorithm with CBCParameter being the
parameters

dES-EDE3-CBC OBJECT IDENTIFIER ::=
{iso(1) member-body(2) us(840) rsadsi(113549) encryptionAlgorithm(3) 7}

CBCParameter ::= IV

IV ::= OCTET STRING (SIZE (8..8))

-- RC2 (or compatable) is an optional algorithm w/ RC2-CBC-paramter as the
parameter

rC2-CBC OBJECT IDENTIFIER ::=
{iso(1) member-body(2) us(840) rsadsi(113549) encryptionAlgorithm(3) 2}

-- For the effective-key-bits (key size) greater than 32 and less than
-- 256, the RC2-CBC algorithm parameters are encoded as:

RC2-CBC-parameter ::= SEQUENCE {
rc2ParameterVersion INTEGER,
iv IV}

-- For the effective-key-bits of 40, 64, and 128, the rc2ParameterVersion
-- values are 160, 120, 58 respectively.

-- The following list the OIDs to be used with S/MIME V3

-- Digest Algorithms:

-- md5 OBJECT IDENTIFIER ::=
-- {iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 5}

-- sha-1 OBJECT IDENTIFIER ::=
--- {iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2)
-- 26}

-- Asymmetric Encryption Algorithms
--
-- rsaEncryption OBJECT IDENTIFIER ::=
-- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1}
--
-- rsa OBJECT IDENTIFIER ::=
-- {joint-iso-ccitt(2) ds(5) algorithm(8) encryptionAlgorithm(1) 1}
--
-- id-dsa OBJECT IDENTIFIER ::=
-- {iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 1 }

-- Signature Algorithms
--
-- md2WithRSAEncryption OBJECT IDENTIFIER ::=
-- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 2}
--
-- md5WithRSAEncryption OBJECT IDENTIFIER ::=
-- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4}
--
-- sha-1WithRSAEncryption OBJECT IDENTIFIER ::=
-- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5}
--
-- id-dsa-with-sha1 OBJECT IDENTIFIER ::=
-- {iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 3}

-- Other Signed Attributes
--
-- signingTime OBJECT IDENTIFIER ::=
-- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 5}
-- See [CMS] for a description of how to encode the attribute value.

END

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA23001 for ietf-smime-bks; Thu, 14 Jan 1999 11:07:19 -0800 (PST)
Received: from speedy.rtfm.com ([208.217.207.133]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA22996; Thu, 14 Jan 1999 11:07:17 -0800 (PST)
Received: (ekr@localhost) by speedy.rtfm.com (8.9.1/8.6.4) id LAA14200; Thu, 14 Jan 1999 11:09:46 -0800 (PST)
To: Paul Hoffman / IMC
Cc: "Linn, John" , "'IETF SMIME list'"
Subject: Re: Crypto-oriented comments on x942-04
References: <"Linn, John"'s message of "Wed, 13 Jan 1999 13:30:42 -0500"> <[email-masked]>
From: EKR
Date: 14 Jan 1999 11:09:45 -0800
In-Reply-To: Paul Hoffman / IMC's message of "Thu, 14 Jan 1999 09:32:24 -0800"
Message-ID:
Lines: 59
X-Mailer: Gnus v5.6.43/XEmacs 20.4 - "Emerald"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

Paul Hoffman / IMC writes:

> >> 7. Section 2.1.2: Identifying an algorithm by an OID rather than an
> >> AlgorithmID risks losing some specifics about the algorithm. For instance,
> >> in a variable-key-size block cipher (e.g., RC5), the AlgorithmID carries the
> >> key size, so this information would be lost. As a result, it may be possible
> >> for an opponent to substitute a key of one size for a key of a different
> >> size, which may lead to an attack that recovers the key one part at a time.
> >> Presumably, the reason for avoiding a full AlgorithmID is that some of its
> >> parameters are message-specific, such as IVs, but perhaps there is some
> >> middle ground. Including the key size as an optional field of OtherInfo is
> >> one possibility. Other parameters that will be lost in the case of RC5 are
> >> the block size and the number of rounds.
> >
> >I think this is weird, but this is how X9.42 does it, so our
> >choices are kind of limited.
>
> This worries me. If there is a substitution attack that can recover the
> key, I think we need to look at it VERY CAREFULLY. Has this same topic been
> discussed on the X9.42 list? If so, can someone summarize the result? If
> not, why not?
I don't see how this makes any difference. Remember, all we're talking
about is the data that's input to the key expansion function. The
actual parameters that are to be used have to be conveyed separately
in any case, because this data is subsequently hashed. The only real effect
of including the algorithmId at all is to produce different keys for
different algorithms using the same pubInfo. It could easily be omitted
entirely.

> >> Having noted this, the field selections and names seem inappropriate: the
> >> fact that keyInfo varies for a given key is contradictory. A preferable
> >> organization would be to have keyInfo include the algorithm and optional
> >> pubInfo, and put the counter in a field of its own, called keyPart, as in:
> >>
> >> OtherInfo ::= SEQUENCE {
> >> keyInfo KeySpecificInfo,
> >> keyPart INTEGER(1..2^32-1) }
> >>
> >> KeySpecificInfo ::= SEQUENCE {
> >> algorithm OBJECT IDENTIFIER,
> >> pubInfo OCTET STRING OPTIONAL,
> >> keySize INTEGER OPTIONAL }
> >
> >This structure is basically lifted from X9.42, so changing the
> >structure isn't really feasible for compatability reasons.
> >Changing the names while keeping the same ASN.1 doesn't seem
> >to add clarity.
>
> I disagree: implementors can often be led astray by field names.
As an implementor, one of the things I hate the most is when
I try to compare two protocols and have to spend a lot of time
trying to figure out if they're the same because someone has
gratiuitously changed a bunch of stuff and I can't tell if
the changes affect the bits on the wire.

-Ekr

--
[Eric Rescorla [email-masked]]

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA22540 for ietf-smime-bks; Thu, 14 Jan 1999 10:17:25 -0800 (PST)
Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA22536 for ; Thu, 14 Jan 1999 10:17:24 -0800 (PST)
Received: from 208.236.41.137 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v3.2 SR1); Thu, 14 Jan 99 10:18:22 -0800
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by mail.deming.com with Internet Mail Service (5.5.2232.9) id ; Thu, 14 Jan 1999 10:18:21 -0800
Message-ID: <[email-masked]>
From: "Blake Ramsdell"
To: "'Jim Schaad (Exchange)'" , "Ietf-Smime (E-mail)"
cc: "Russ Housley (E-mail)"
Subject: RE: Last Call comments on the Message And Certificate Drafts
Date: Thu, 14 Jan 1999 10:18:20 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
X-WSS-ID: 1A80EB648727-01-01
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

> -----Original Message-----
> From: Jim Schaad (Exchange) [mailto:[email-masked]]
> Sent: Saturday, January 09, 1999 3:48 PM
> To: Ietf-Smime (E-mail); Blake Ramsdell
> Cc: Russ Housley (E-mail)
> Subject: Last Call comments on the Message And Certificate Drafts
>
> 1. I would like to see some consistancy developed in the
> reference naming
> between the different documents produced from the S/MIME
> working group. I
> especially dislike the KEYM reference name for PKIX Part1 as
> this is really
> misleading. Part1 does not really say anything bout key management.

This makes sense.

> 2. Are we requesting obsoletion of the V2 drafts or not. If
> we are then why
> are we refering to them. If we are not then we need to make
> this clear to
> the RFC editors. Based on the current thinking, it would be
> my guess that
> we are not requesting the obsoletion of the S/MIME V2 drafts.

My understanding is that because an RFC is obsolete it does mean you can't
refer to it any more. We do this for PKCS #1 v1.5 and PKCS #1 v2.0, even
though the PKCS #1 v1.5 RFC is technically obsolete.

> 1. Section 2.4.1 - Example on signature appears to eleminate
> multipart/signed as it states content MUST be stored in eContent OCTET
> STRING. I would strongly recommend removing the MUST on this as it is
> example not statement of operation.

Hmm... I understand the concern. Thinking...

> 2. Section 2.5 - Why do we mention receipt requests but not
> security labels.
> I would think they are of equal importance and should either both be
> mentioned or omitted. This is especially true as security
> labels can easily
> be understood by V2 clients but not receipts (well at least
> not easily). I
> recommend we strike the reference to receipt requests.

Agree.

> 3. Section 2.6 -- This is not stated in the format of a MUST.
> Change to
> "S/MIME v3 agents MUST use the isserAndSerialNumber form of
> SignerInfo." or
> similar statement.

Can I just capitalize MUST in the current sentence?

> 5. Section 3.2.1 - The last sentence contains a "MUST not"
> this should be
> "MUST NOT"

Agree.

> 6. Section A - Changing to an ASN module would be considered
> niceness but
> not necessity. I an finding that I use ASN modules more and more for
> creation of ASN encode/decode functions. Given that we now
> have several
> different ASN structures in this appendix, I would like to
> see this combined
> into an ASN module. I can create this if desired.

I personally think that this would be cool (to have the ASN).

> 7. References -- The [DH] citation should be made to
> reference the internet
> draft/RFC

Agree.

> 1. Section 1 - Reference to KEYM in the last sentence of
> paragraph #1 is
> almost certianly meant to be a reference to SMIME-MSG

Hmm. I'll buy that. Agree.

> 2. Section 1 - PKCS#10 requirements are in the V2 Msg Draft
> and not the V3
> message draft. This text needs to be omitted or refer to
> MSG-V2 instead.
> (CERT-V2?)

I believe that this text should be omitted, since we came to agreement at
one point that we would not speak of it.

> 3. Section A - Remove reference to CRMF as we don't use it

Agree.

> 4. Section 2.3 - P#3 - Given inheritance of DSA parameters do
> we need to
> modify the statement on not sending the root CA cert.
> Messages are not even
> internally validatable with out the root in some cases.

Hmm. I'd rather make it so that DSA parameters MUST NOT be scattered all
the way up and down the certificate chain, which I understand will increase
the certificate size, but will greatly simplify implementation. Comments?

> 5. Section 4.3 - Why is there a reference to SMIME-MSG for
> RSA but not for
> DSA? Why is there no reference for DSA?

Not to mention that SMIME-MSG is a pretty stupid reference for RSA
signatures -- the PKCS #1 RFC would be better, wouldn't it?

Recommend that we fix the reference to point to PKCS #1 for the RSA
algorithms and to point to the DSA reference for the DSA algorithm.

> 6. Section 4.4 - P#1 - Lets replace the last sentence with
> "The syntax and
> semantics of all the identified extensions are defined in [KEYM]."

I think this sounds OK.

> 7. Section 4.4 - P#2 - Replace sentence #1 with "... the
> Basic Constraints,
> Key Usage, Authority Key Identifier, Subject Key Identifier
> and Subject
> Alternative Name Certificate Extensions when they ..."

Agree.

> 8. Section 4.4.1 - We have a big conflict with PKIX. We say
> basicConstraints should appear, they say it should not. My
> personal opinion
> on this one is that PKIX is wrong and we should not change
> it, but I raise
> this as an incompatiblity between the two drafts.

I believe that in the event that PKIX says one thing and -cert says
something else, -cert wins.

> 9. Section 4.4.1 - Should we add the same criticality
> statement as occurs in
> PKIX -- i.e. MUST be critical if it appears. I recommend
> that we strike the
> criticality statment in 4.4.2 as it duplicates information in
> PKIX part1.

Agree.

Blake

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA22121 for ietf-smime-bks; Thu, 14 Jan 1999 09:39:10 -0800 (PST)
Received: from aum (ip08.proper.com [165.227.249.8]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA22117; Thu, 14 Jan 1999 09:39:05 -0800 (PST)
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Thu, 14 Jan 1999 09:32:24 -0800
To: EKR , "Linn, John"
From: Paul Hoffman / IMC
Subject: Re: Crypto-oriented comments on x942-04
Cc: "'IETF SMIME list'"
In-Reply-To:
References: <"Linn, John"'s message of "Wed, 13 Jan 1999 13:30:42 -0500">
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

>> 7. Section 2.1.2: Identifying an algorithm by an OID rather than an
>> AlgorithmID risks losing some specifics about the algorithm. For instance,
>> in a variable-key-size block cipher (e.g., RC5), the AlgorithmID carries the
>> key size, so this information would be lost. As a result, it may be possible
>> for an opponent to substitute a key of one size for a key of a different
>> size, which may lead to an attack that recovers the key one part at a time.
>> Presumably, the reason for avoiding a full AlgorithmID is that some of its
>> parameters are message-specific, such as IVs, but perhaps there is some
>> middle ground. Including the key size as an optional field of OtherInfo is
>> one possibility. Other parameters that will be lost in the case of RC5 are
>> the block size and the number of rounds.
>
>I think this is weird, but this is how X9.42 does it, so our
>choices are kind of limited.

This worries me. If there is a substitution attack that can recover the
key, I think we need to look at it VERY CAREFULLY. Has this same topic been
discussed on the X9.42 list? If so, can someone summarize the result? If
not, why not?

>> Having noted this, the field selections and names seem inappropriate: the
>> fact that keyInfo varies for a given key is contradictory. A preferable
>> organization would be to have keyInfo include the algorithm and optional
>> pubInfo, and put the counter in a field of its own, called keyPart, as in:
>>
>> OtherInfo ::= SEQUENCE {
>> keyInfo KeySpecificInfo,
>> keyPart INTEGER(1..2^32-1) }
>>
>> KeySpecificInfo ::= SEQUENCE {
>> algorithm OBJECT IDENTIFIER,
>> pubInfo OCTET STRING OPTIONAL,
>> keySize INTEGER OPTIONAL }
>
>This structure is basically lifted from X9.42, so changing the
>structure isn't really feasible for compatability reasons.
>Changing the names while keeping the same ASN.1 doesn't seem
>to add clarity.

I disagree: implementors can often be led astray by field names.

--Paul Hoffman, Director
--Internet Mail Consortium

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA20971 for ietf-smime-bks; Thu, 14 Jan 1999 07:43:27 -0800 (PST)
Received: from spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA20954; Thu, 14 Jan 1999 07:43:25 -0800 (PST)
Received: from rhousley_laptop.spyrus.com (dial01.spyrus.com [207.212.34.121]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id HAA20919; Thu, 14 Jan 1999 07:44:19 -0800 (PST)
Message-Id: <[email-masked]>
Message-Id: <[email-masked]>
X-Sender: [email-masked] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Wed, 13 Jan 1999 11:29:49 -0500
To: [email-masked]
From: Russ Housley
Subject: Re: Comments on ESS-10
Cc: [email-masked]
In-Reply-To: <2FBF98FC7852CF11912A0000000000010ECB5BD7@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

Paul,

There is quite a bit of overlap with Jim's comments and mine. Thus, I
agree with almost everything he said.

>0. Section 1. We have not yet seen the new introduction paragraphs which
>include section 5. I would like to do so before the document goes to the
>RFC editor.
>
>1. Section 1.3 - the macValue attribute has been removed from CMS and needs
>to be removed from CMS
>
>2. Section 1.4 - Minor word changes in paragraph 2. "The main disadvantage
>is that the gateway must check for the presence of certain attributes in the
>other signerInfos and either omit or copy those attributes."
>
>3. Section 2.2 - bullet item 4: I have some \240 characters in the text
>here which I assume are suppose to be spaces. Many of these are found
>through out the entire document. I have had to edit them out to get the ASN
>module to compile.
>
>4. Section 2.8 - ASN for Receipt still references Version not CMSVersion

I suggest that you define ESSVersion instead of importing CMSVersion.

>5. Section 4.4 - The ASN for MLData has a comment on EntityIdentifier has a
>note about being imported from CMS, but its not. Please remove the comment
>in the text and in the ASN module

Russ

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA20970 for ietf-smime-bks; Thu, 14 Jan 1999 07:43:27 -0800 (PST)
Received: from spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA20955; Thu, 14 Jan 1999 07:43:25 -0800 (PST)
Received: from rhousley_laptop.spyrus.com (dial01.spyrus.com [207.212.34.121]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id HAA20907; Thu, 14 Jan 1999 07:44:12 -0800 (PST)
Message-Id: <[email-masked]>
Message-Id: <[email-masked]>
X-Sender: [email-masked] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Wed, 13 Jan 1999 10:39:03 -0500
To: [email-masked]
From: Russ Housley
Subject: Re: Comments on ESS-10
Cc: [email-masked]
In-Reply-To: <[email-masked]>
References: <2FBF98FC7852CF11912A0000000000010ECB5BD7@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

Paul:

>>4. Section 2.8 - ASN for Receipt still references Version not CMSVersion
>
>Many thanks to Russ for switching this out from under me. :-) I do *not*
>think we should import CMSVersion from CMS, because the version number we
>are using here has nothing to do with CMS, and the name will be confusing.
>Instead, I think I should define it as:
>
>Version ::= INTEGER { v1(1) }
>
>Comments?

This change to CMS was made to avoid conflicts with the PKIX Part 1
definition of Version.

I agree that you should not import CMSVersion. However, you should also
avoid the conflict with the PKIX Part 1 definition of Version.

I suggest that you use:

ESSVersion ::= INTEGER { v1(1) }

Russ

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA20972 for ietf-smime-bks; Thu, 14 Jan 1999 07:43:27 -0800 (PST)
Received: from spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA20966 for ; Thu, 14 Jan 1999 07:43:26 -0800 (PST)
Received: from rhousley_laptop.spyrus.com (dial01.spyrus.com [207.212.34.121]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id HAA20914; Thu, 14 Jan 1999 07:44:16 -0800 (PST)
Message-Id: <[email-masked]>
Message-Id: <[email-masked]>
X-Sender: [email-masked] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Wed, 13 Jan 1999 11:23:54 -0500
To: [email-masked]
From: Russ Housley
Subject: Re: Last Call comments on the Message And Certificate Drafts
Cc: [email-masked]
In-Reply-To: <2FBF98FC7852CF11912A0000000000010ECB5BD5@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

Blake:

> Message Draft comments
>
>6. Section A - Changing to an ASN module would be considered niceness but
>not necessity. I an finding that I use ASN modules more and more for
>creation of ASN encode/decode functions. Given that we now have several
>different ASN structures in this appendix, I would like to see this combined
>into an ASN module. I can create this if desired.

I strongly agree. So, I have assigned an OID for the module identifier.

id-mod-msg-v3 OBJECT IDENTIFIER ::= { id-mod 4 }

>Certificate Draft comments
>
>4. Section 2.3 - P#3 - Given inheritance of DSA parameters do we need to
>modify the statement on not sending the root CA cert. Messages are not even
>internally validatable with out the root in some cases.

I agree. We should not prohibit the inclusion of root certificates (or any
certificate).

>8. Section 4.4.1 - We have a big conflict with PKIX. We say
>basicConstraints should appear, they say it should not. My personal opinion
>on this one is that PKIX is wrong and we should not change it, but I raise
>this as an incompatiblity between the two drafts.

Very good catch.

MSG-06 says: "Certificates SHOULD contain a basicConstraints extension."

PKIX Part 1 requires the basicConstraints extension to be present in CA
certificates, and it says that the basicConstraints extension should not be
present in end-entity certificates.

I sugest that we adopt the PKIX Part 1 text.

>9. Section 4.4.1 - Should we add the same criticality statement as occurs in
>PKIX -- i.e. MUST be critical if it appears. I recommend that we strike the
>criticality statment in 4.4.2 as it duplicates information in PKIX part1.

I agree. When the the basicConstraints extension is present, it MUST be
critical.

Russ

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA20727 for ietf-smime-bks; Thu, 14 Jan 1999 07:09:31 -0800 (PST)
Received: from speedy.rtfm.com ([208.217.207.133]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA20723 for ; Thu, 14 Jan 1999 07:09:29 -0800 (PST)
Received: (ekr@localhost) by speedy.rtfm.com (8.9.1/8.6.4) id HAA12068; Thu, 14 Jan 1999 07:11:39 -0800 (PST)
To: "Linn, John"
Cc: "'IETF SMIME list'"
Subject: Re: Crypto-oriented comments on x942-04
References:
From: EKR
Date: 14 Jan 1999 07:11:38 -0800
In-Reply-To: "Linn, John"'s message of "Wed, 13 Jan 1999 13:30:42 -0500"
Message-ID:
Lines: 218
X-Mailer: Gnus v5.6.43/XEmacs 20.4 - "Emerald"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

"Linn, John" writes:

> Per Russ' solicitation for review of smime-x942-04 by cryptographers, I'm
> forwarding the attached comments provided to me by Burt Kaliski and Yiqun
> Lisa Yin of RSA Laboratories.
Thanks to John, Burt, and Lisa.

> 2. ANSI X9.42 is still an unapproved draft, and should be cited as such, not
> as a standard.
Ok.

> 3. The shared secret value ZZ is sometimes called a shared secret number.
> "Value" would be better throughout, since in more general settings, ZZ is a
> finite field element, not a number (integer).
Well, a lot of the point here is to concretize (there's a horrible
neologism for you) X9.42 for S/MIME use, and for the purposes of
S/MIME, it's an integer.

Anyone else want to comment on this?

> 4. Section 2.1.1: An operator is missing in the definitions of g and h,
> which should be
>
> g = h^{(p-1)/q} mod p ...
> h is any integer ... such that h^{(p-1)/q} ...
>
> In this definition, it could be clarifying to state that the parameters are
> (p,q,g) and to change the order of definitions to:
> p is a large prime
> q is a large prime such that p = qj+1 for some larger integer j
> g = h^{(p-1)/q} mod p where ...
>
> Further, it may be helpful to explain that "g has order q mod p" means that
> g^q mod p = 1, if g <> 1 and q is prime.
Right. I'm happy to change this.

> 5. Section 2.1.2: In Section 2.1.1, ZZ is a field element or integer, so
> some conversion to an octet string is required. The usual conversion,
> following IEEE P1363 and ANSI X9.42, is a most significant byte first
> representation. ANSI X9.42 specifies that the result has as few bytes as
> possible (i.e., no leading zeros); IEEE P1363 says that the result has the
> same length in octets as the longest field element (i.e., the length of the
> prime p), with leading zeros. So, there's an apparent IEEE P1363 vs. ANSI
> X9.42 discrepancy. Given that IEEE P1363 is currently in ballot and ANSI
> X9.42 needs to be recirculated, we'd recommend that IEEE P1363 be followed.
> In any case, some representation should be stated.
Agreed. Myself I prefer fewest octets.

> Also, the comment "the
> security of this data is limited to the size of ZZ" is not accurate. The
> security is related to the size of p and q. A large ZZ doesn't imply
> security by itself.
I agree that this is misleading. I'll fix it.

> 6. Section 2.1.2: Editorial: Change "shared key" to "shared secret value".
Agreed.

> 7. Section 2.1.2: Identifying an algorithm by an OID rather than an
> AlgorithmID risks losing some specifics about the algorithm. For instance,
> in a variable-key-size block cipher (e.g., RC5), the AlgorithmID carries the
> key size, so this information would be lost. As a result, it may be possible
> for an opponent to substitute a key of one size for a key of a different
> size, which may lead to an attack that recovers the key one part at a time.
> Presumably, the reason for avoiding a full AlgorithmID is that some of its
> parameters are message-specific, such as IVs, but perhaps there is some
> middle ground. Including the key size as an optional field of OtherInfo is
> one possibility. Other parameters that will be lost in the case of RC5 are
> the block size and the number of rounds.
I think this is weird, but this is how X9.42 does it, so our
choices are kind of limited.

> 8. Section 2.1.2: "Parameters" is misspelled in the definition of the
> algorithm field.
I'll fix this.

> 9. Section 2.1.2: Some additional explanation would be helpful about the
> relationship between KM and a KEK. In particular, the text might say that to
> generate a KEK, one generates one or more KMs from the same ZZ, where
> OtherInfo varies. The variable part of OtherInfo is keyInfo; pubInfo remains
> the same.
I'll try to add some text here.

> Having noted this, the field selections and names seem inappropriate: the
> fact that keyInfo varies for a given key is contradictory. A preferable
> organization would be to have keyInfo include the algorithm and optional
> pubInfo, and put the counter in a field of its own, called keyPart, as in:
>
> OtherInfo ::= SEQUENCE {
> keyInfo KeySpecificInfo,
> keyPart INTEGER(1..2^32-1) }
>
> KeySpecificInfo ::= SEQUENCE {
> algorithm OBJECT IDENTIFIER,
> pubInfo OCTET STRING OPTIONAL,
> keySize INTEGER OPTIONAL }
This structure is basically lifted from X9.42, so changing the
structure isn't really feasible for compatability reasons.
Changing the names while keeping the same ASN.1 doesn't seem
to add clarity.

> 10. Section 2.1.2: Why can't counter be an INTEGER? That would avoid the
> unnecessary definition of an encoding format for the counter, while
> maintaining an unambiguous encoding.
Again, this is how X9.42 does it.

> 11. Section 2.1.2: Why must pubInfo, if present, contain a minimum of 512
> bits? A minimum of 160 bits is sufficient to avoid collisions; the encoding
> as an OCTET STRING is unambiguous and prevents length-extension attacks.
Russ, you care to speak up on this?

> Also, random or nonce might be a better name, since all of otherInfo, not
> just pubInfo, is public.
Yet again, this name is from X9.42.

> 12. In general, the different terms for byte ordering should be harmonized
> or adopted from some other standard: "leftmost", "network byte order", etc.
I agree.

> 13. Section 2.1.3: KEK computation states that each algorithm requires a
> specific size key. But some algorithms have variable-size keys, and it's
> possible that future algorithms will require more than just a random string
> (e.g., more structure). So, it would be preferable to say that the currently
> proposed S/MIME algorithms assume a random string, perhaps with parity
> changes.
Well, the output of this process is necessarily a random string. Any
algorithm which needs a key with more structure should have a pre-processor
which produces one from a bit string.

> 14. Section 2.1.5: Editorial: Change "received public keys" to "a received
> public key y".
>
> Also, add a reference to IEEE P1363 security considerations for more
> discussion on public-key validation.

> 15. Section 2.1.6: This 16-byte example doesn't comply with the draft's
> 160-bit minimum (Section 2.2).
So it doesn't. I changed the minimum on the last draft and forgot
that it affected the examples.

> 16. Section 2.2: Should a lower bound on the prime p also be given?
Probably. 1024 and be done with it?

> Why is
> there a 160-bit minimum on q?
IIRC, Brian LaMacchia wanted this. I'll let him speak for it.

> (Note that the 128-bit minimum in the same
> paragraph is inconsistent.)
Yes, this is inconsistent search and replace.

> Also, a minimum size on the private key x is
> inconsistent with saying that x is in the interval [2,q-2].
Yes, I'll remove the reference to x here.

> Per Sec. 2.2.1.1, we believe that it would be appropriate for the document
> to state explicitly that alternate parameter generation algorithms MAY be
> used; P1363 can be cited for discussion.
Well, SHOULD means 'do it this way unless you've got a good reason'.

> Per Sec. 2.2.1.1, step 6, it would
> be useful to give a reference to what primality algorithm(s) can be used.
I can probably add something here.

> 17. Sections 2.3 and 2.4: Key validation is not the only way to prevent a
> small-subgroup attack. Another method is cofactor multiplication, as
> described in IEEE P1363 and in [LAW98]. Cofactor multiplication performs an
> additional operation on the shared secret value so that it is not in a small
> subgroup. (There is a "compatibility mode" that keeps the shared secret
> value the same as in ordinary Diffie-Hellman when the system is not under
> attack; discussion is available in B.S. Kaliski Jr. Compatible cofactor
> multiplication for Diffie-Hellman primitives. Electronics Letters,
> 34(25):2396-2397, December 10, 1998.)
>
> Another method is to choose the primes p and q so that p = qj + 1 where j is
> small and to check the received public key against a small set of excluded
> values. In this case, the leakage due to a small subgroup attack will be
> only a few bits.
I have to admit that I'm not enough of a mathematician to have
an informed opinion on this topic. I'd certainly far rather not
change the shared-secret value, and I don't want to require
an extra operation either (for perforamnce reasons).

> Editorial: Change "If the sender cannot" to "If an opponent cannot"; change
> "failure of decryption" to "failure of a decryption operation by the
> recipient".
No problemo.

> 19. Security considerations. The last two paragraphs could be merged into
> Sections 2.1.5 and 2.2, or at least should be made consistent, so there are
> not two sources for the same information.
>
> In the last paragraph, the effective length of 3DES keys is 112, not 168,
> due to a meet-in-the-middle attack.
Fair enough.

> In a general design, one looks for a minimum security level and selects
> algorithms to meet that level. So, for instance, if an 80-bit security level
> is desired, a designer may choose 3DES or RC2 and a 160-bit minimum
> subgroup. Selecting the subgroup size to be double the effective key
> strength, while effective, is more than what is necessary. The subgroup size
> should be double the desired security level rather than double the symmetric
> key size.
I see your point here, but I'm not sure I agree. It seems to me
that a good design principle is to have a balanced system, where
all the algorithms are of roughly comparable strength. This speaks
for having the effctive key length as the basis for private key
size.

> Moreover, there needs to be a prime size selection (1024 bits, 2048 bits,
> etc.) that matches the desired level.
Agreed. I'd be glad to have some guidance on this one.

-Ekr

--
[Eric Rescorla [email-masked]]

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA22109 for ietf-smime-bks; Wed, 13 Jan 1999 10:26:18 -0800 (PST)
Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA22103 for ; Wed, 13 Jan 1999 10:26:17 -0800 (PST)
Received: from mail.securitydynamics.com by tholian.securitydynamics.com via smtpd (for imc.org [206.184.129.134]) with SMTP; 13 Jan 1999 18:27:50 UT
Received: by securitydynamics.com (8.7.6/8.7.3) with ESMTP id NAA24497 for ; Wed, 13 Jan 1999 13:35:35 -0500 (EST)
Received: by exna01.securitydynamics.com with Internet Mail Service (5.5.2232.9) id ; Wed, 13 Jan 1999 13:27:31 -0500
Message-ID:
From: "Linn, John"
To: "'IETF SMIME list'"
Subject: Crypto-oriented comments on x942-04
Date: Wed, 13 Jan 1999 13:30:42 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

Per Russ' solicitation for review of smime-x942-04 by cryptographers, I'm
forwarding the attached comments provided to me by Burt Kaliski and Yiqun
Lisa Yin of RSA Laboratories.

--jl

1. In general, the draft is a nice condensation of the ANSI X9.42 draft into
IETF S/MIME terms.

2. ANSI X9.42 is still an unapproved draft, and should be cited as such, not
as a standard.

3. The shared secret value ZZ is sometimes called a shared secret number.
"Value" would be better throughout, since in more general settings, ZZ is a
finite field element, not a number (integer).

4. Section 2.1.1: An operator is missing in the definitions of g and h,
which should be

g = h^{(p-1)/q} mod p ...
h is any integer ... such that h^{(p-1)/q} ...

In this definition, it could be clarifying to state that the parameters are
(p,q,g) and to change the order of definitions to:
p is a large prime
q is a large prime such that p = qj+1 for some larger integer j
g = h^{(p-1)/q} mod p where ...

Further, it may be helpful to explain that "g has order q mod p" means that
g^q mod p = 1, if g <> 1 and q is prime.

5. Section 2.1.2: In Section 2.1.1, ZZ is a field element or integer, so
some conversion to an octet string is required. The usual conversion,
following IEEE P1363 and ANSI X9.42, is a most significant byte first
representation. ANSI X9.42 specifies that the result has as few bytes as
possible (i.e., no leading zeros); IEEE P1363 says that the result has the
same length in octets as the longest field element (i.e., the length of the
prime p), with leading zeros. So, there's an apparent IEEE P1363 vs. ANSI
X9.42 discrepancy. Given that IEEE P1363 is currently in ballot and ANSI
X9.42 needs to be recirculated, we'd recommend that IEEE P1363 be followed.
In any case, some representation should be stated. Also, the comment "the
security of this data is limited to the size of ZZ" is not accurate. The
security is related to the size of p and q. A large ZZ doesn't imply
security by itself.

6. Section 2.1.2: Editorial: Change "shared key" to "shared secret value".

7. Section 2.1.2: Identifying an algorithm by an OID rather than an
AlgorithmID risks losing some specifics about the algorithm. For instance,
in a variable-key-size block cipher (e.g., RC5), the AlgorithmID carries the
key size, so this information would be lost. As a result, it may be possible
for an opponent to substitute a key of one size for a key of a different
size, which may lead to an attack that recovers the key one part at a time.
Presumably, the reason for avoiding a full AlgorithmID is that some of its
parameters are message-specific, such as IVs, but perhaps there is some
middle ground. Including the key size as an optional field of OtherInfo is
one possibility. Other parameters that will be lost in the case of RC5 are
the block size and the number of rounds.

8. Section 2.1.2: "Parameters" is misspelled in the definition of the
algorithm field.

9. Section 2.1.2: Some additional explanation would be helpful about the
relationship between KM and a KEK. In particular, the text might say that to
generate a KEK, one generates one or more KMs from the same ZZ, where
OtherInfo varies. The variable part of OtherInfo is keyInfo; pubInfo remains
the same.

Having noted this, the field selections and names seem inappropriate: the
fact that keyInfo varies for a given key is contradictory. A preferable
organization would be to have keyInfo include the algorithm and optional
pubInfo, and put the counter in a field of its own, called keyPart, as in:

OtherInfo ::= SEQUENCE {
keyInfo KeySpecificInfo,
keyPart INTEGER(1..2^32-1) }

KeySpecificInfo ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
pubInfo OCTET STRING OPTIONAL,
keySize INTEGER OPTIONAL }

10. Section 2.1.2: Why can't counter be an INTEGER? That would avoid the
unnecessary definition of an encoding format for the counter, while
maintaining an unambiguous encoding.

11. Section 2.1.2: Why must pubInfo, if present, contain a minimum of 512
bits? A minimum of 160 bits is sufficient to avoid collisions; the encoding
as an OCTET STRING is unambiguous and prevents length-extension attacks.
Also, random or nonce might be a better name, since all of otherInfo, not
just pubInfo, is public.

12. In general, the different terms for byte ordering should be harmonized
or adopted from some other standard: "leftmost", "network byte order", etc.

13. Section 2.1.3: KEK computation states that each algorithm requires a
specific size key. But some algorithms have variable-size keys, and it's
possible that future algorithms will require more than just a random string
(e.g., more structure). So, it would be preferable to say that the currently
proposed S/MIME algorithms assume a random string, perhaps with parity
changes.

14. Section 2.1.5: Editorial: Change "received public keys" to "a received
public key y".

Also, add a reference to IEEE P1363 security considerations for more
discussion on public-key validation.

15. Section 2.1.6: This 16-byte example doesn't comply with the draft's
160-bit minimum (Section 2.2).

16. Section 2.2: Should a lower bound on the prime p also be given? Why is
there a 160-bit minimum on q? (Note that the 128-bit minimum in the same
paragraph is inconsistent.) Also, a minimum size on the private key x is
inconsistent with saying that x is in the interval [2,q-2].

The first paragraph of this section is missing a parenthesis.

Per Sec. 2.2.1.1, we believe that it would be appropriate for the document
to state explicitly that alternate parameter generation algorithms MAY be
used; P1363 can be cited for discussion. Per Sec. 2.2.1.1, step 6, it would
be useful to give a reference to what primality algorithm(s) can be used.

17. Sections 2.3 and 2.4: Key validation is not the only way to prevent a
small-subgroup attack. Another method is cofactor multiplication, as
described in IEEE P1363 and in [LAW98]. Cofactor multiplication performs an
additional operation on the shared secret value so that it is not in a small
subgroup. (There is a "compatibility mode" that keeps the shared secret
value the same as in ordinary Diffie-Hellman when the system is not under
attack; discussion is available in B.S. Kaliski Jr. Compatible cofactor
multiplication for Diffie-Hellman primitives. Electronics Letters,
34(25):2396-2397, December 10, 1998.)

Another method is to choose the primes p and q so that p = qj + 1 where j is
small and to check the received public key against a small set of excluded
values. In this case, the leakage due to a small subgroup attack will be
only a few bits.

Editorial: Change "If the sender cannot" to "If an opponent cannot"; change
"failure of decryption" to "failure of a decryption operation by the
recipient".

18. General: Replace "S" with "Section" for cross-referencing.

19. Security considerations. The last two paragraphs could be merged into
Sections 2.1.5 and 2.2, or at least should be made consistent, so there are
not two sources for the same information.

In the last paragraph, the effective length of 3DES keys is 112, not 168,
due to a meet-in-the-middle attack.

In a general design, one looks for a minimum security level and selects
algorithms to meet that level. So, for instance, if an 80-bit security level
is desired, a designer may choose 3DES or RC2 and a 160-bit minimum
subgroup. Selecting the subgroup size to be double the effective key
strength, while effective, is more than what is necessary. The subgroup size
should be double the desired security level rather than double the symmetric
key size.

Moreover, there needs to be a prime size selection (1024 bits, 2048 bits,
etc.) that matches the desired level.

Finally, the selection must take into account the number of users sharing
the primes, since it costs only slightly more to compute several discrete
logarithms than to compute the first one.

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA16868 for ietf-smime-bks; Wed, 13 Jan 1999 03:06:26 -0800 (PST)
Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA16864 for ; Wed, 13 Jan 1999 03:06:24 -0800 (PST)
Received: from secude.com ([141.12.207.12]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id MAA23620 for ; Wed, 13 Jan 1999 12:07:14 +0100 (MET)
Message-ID: <[email-masked]>
Date: Wed, 13 Jan 1999 12:08:04 +0100
From: Stephan =?iso-8859-1?Q?Andr=E9?=
Organization: SECUDE GmbH
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [email-masked]
Subject: NT SP4 and MIME types
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms4B361D56EE7FD97280E17422"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

This is a cryptographically signed message in MIME format.

--------------ms4B361D56EE7FD97280E17422
Content-Type: multipart/mixed;
boundary="------------C9D22D538CEA281FC843B28E"

This is a multi-part message in MIME format.
--------------C9D22D538CEA281FC843B28E
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hello,

this is a more 'product related' question:

Is it correct that Netscape Messenger does recognize application/x-pkcs7-mime
but not application/pkcs7-mime? Is it true for other implementations, too?

NT SP4 overwrites the respective HKEY_CLASSES_ROOT entry which causes
Outlook (add-ins) to send the new type recommended by RFC 2311 for
attachments like smime.p7m.

--
Gruß,
Stephan André
_____________________
http://www.secude.com
--------------C9D22D538CEA281FC843B28E
Content-Type: text/x-vcard; charset=us-ascii;
name="andre.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Stephan André
Content-Disposition: attachment;
filename="andre.vcf"

begin:vcard
n:André;Stephan
x-mozilla-html:FALSE
org:
SECUDE Sicherheitstechnologie
Informationssysteme GmbH
adr:;;Julius-Reiber-Str. 17;Darmstadt;;D-64293;Germany
version:2.1
email;internet:[email-masked]
tel;fax:(+49)6151/88 006 - 26
tel;work:(+49)6151/88 006 - 29
x-mozilla-cpt:;65535
fn:Stephan André
end:vcard

--------------C9D22D538CEA281FC843B28E--

--------------ms4B361D56EE7FD97280E17422
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIFawYJKoZIhvcNAQcCoIIFXDCCBVgCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
A4QwggOAMIICaKADAgECAgEQMA0GCSqGSIb3DQEBBQUAMFAxCzAJBgNVBAYTAkRFMRQwEgYD
VQQKEwtTRUNVREUgR21iSDErMCkGA1UECxMiU0VDVURFIFRydXN0RmFjdG9yeSBJbmRpdmlk
dWFscyBDQTAeFw05ODExMjMxMzE1MThaFw0wMjExMjQxMzE1MThaMDwxCzAJBgNVBA0TAkRF
MRQwEgYDVQQKEwtTRUNVREUgR21iSDEXMBUGA1UEAxQOU3RlcGhhbiBBbmRywmUwgZ8wDQYJ
KoZIhvcNAQEBBQADgY0AMIGJAoGBAP66MUwCB7rtfznL98KjZ/uj8VAr9GhZs57eBRZzk0NJ
zh5JvoW9KZXN7MTDqrK6+LVRcBkiEaFUXd523YGEs6F1oD/G9p8ccMsM95p2PZY3VT6H6epH
XX6PrFYOb5mI0yuVzLUCqQb4xx7Cvs4On/MhM/B0hB7yGhh9VRGq2wtXAgMBAAGjgfwwgfkw
DgYDVR0PAQH/BAQDAgTwMGwGA1UdEQRlMGOBEGFuZHJlQHNlY3VkZS5jb22BD2FuZHJlQHNl
Y3VkZS5kZYE+L289U0VDVURFIEdtYkgsIERhcm1zdGFkdC9vdT1TRUNVREUtQ09NL2NuPVJl
Y2lwaWVudHMvY249YW5kcmUwWAYDVR0SBFEwT4EXdHJ1c3RmYWN0b3J5QHNlY3VkZS5jb22G
NGh0dHA6Ly93d3cuc2VjdWRlLmNvbS90cnVzdGZhY3RvcnkvaW5kaXZpZHVhbHNjYS5jcnQw
DAYDVR0TAQH/BAIwADARBglghkgBhvhCAQEEBAMCALAwDQYJKoZIhvcNAQEFBQADggEBAE65
ho0yo2aSGBystmF3/FNZD2xVEoOJcpwPgzO1Dv7u9WDFetDfcMONg5Ar7a0Ts/BFd1So9hyd
gkTBt/Rsath2eM7U+yaOxGnprc1vvLZJVcc52tXlAAdCzUMh0qZZwu/bj43tw/cY+cgAnEyb
p8lsarW4hsy4wX4eMG3V+N54t/cRT9Yz5LuEO1J3ukodjeDUqOrlprWxsDX7bQrbH+sLxuPv
CLqZOCumL9U6tE8ALWSIJVwshq+ae3fTpowNAIPfI1cWrJOA5o7flg60zSyZkBcBnZw+ONUV
AEGuCHMc9Vhzxwgxzb2r4ZMXcWz8WKGA+4ivT59MhUvrhuJAXc4xggGvMIIBqwIBATBVMFAx
CzAJBgNVBAYTAkRFMRQwEgYDVQQKEwtTRUNVREUgR21iSDErMCkGA1UECxMiU0VDVURFIFRy
dXN0RmFjdG9yeSBJbmRpdmlkdWFscyBDQQIBEDAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJ
AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk5MDExMzExMDgwNVowIwYJKoZIhvcN
AQkEMRYEFIRE3g27nHZWk1PQOKOnCxjWIDdqMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMC
AgEoMA0GCSqGSIb3DQEBAQUABIGAFFEEXYPzCWF8ZYHJx/hK+BCfRBoH31sv76XVleGgad39
U8B0LotuHTxGjASRrxd3bD1fSmR3sNkz8KO6x44pYF6zGEaL3VjEDJZE2OLpfwyZuOxmK7uM
48+VXI3vYiw5aZ9vIKpFbnoyRdm3JkHMf5Ug+Zeu1X4IlsK7Hs85+RI=
--------------ms4B361D56EE7FD97280E17422--

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA21439 for ietf-smime-bks; Tue, 12 Jan 1999 16:42:54 -0800 (PST)
Received: from shell.tsoft.com ([email-masked] [207.201.34.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA21435 for ; Tue, 12 Jan 1999 16:42:54 -0800 (PST)
Received: from cs.stanford.edu ([209.133.59.212]) by shell.tsoft.com (8.8.7/8.8.7) with ESMTP id QAA14274; Tue, 12 Jan 1999 16:36:45 -0800 (PST)
Message-ID: <[email-masked]>
Date: Tue, 12 Jan 1999 16:45:31 -0800
From: Brian Korver
Reply-To: [email-masked]
X-Mailer: Mozilla 4.5 (Macintosh; I; PPC)
X-Accept-Language: en
MIME-Version: 1.0
To: Russ Housley
CC: "Ietf-Smime (E-mail)"
Subject: Re: Last Call Comments on CMS-10
References: <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

Russ Housley wrote:
> I prefer:
> ... However, signed attributes within the signed-data content type and
> authenticated attributes within the authenticated-data content type require DER
> encoding. Signed attributes and authenticated attributes must be transmitted
> in DER form to ensure that recipients can validate a content that contains an
> unrecognized attribute. Signed attributes and authenticated attributes are the
> only CMS data types that require DER encoding.

Agreed.

[snip]
> I know. This is a philosophy question. Since these identifiers will
> eventually be in the IANA registry, I did not know whether or not these values
> should be part of the module.
>
> I would be glad to add these values to the module if the working group thinks
> they belong there. Comments?

Either include the OIDs, or include a pointer to a document containing the
OIDs (that of course, uses the same names).

[snip]
> >7. Section 5.1: Text on version needs to be expanded to deal with SKI.
> >Must be 3 if any SignerInfo version is 3.
>
> Are you saying that a version 3 SignerInfo should cause parent SignedData
> version to be 3?
>
> Is there a reason to prohibit version 3 SignerInfo from being encapsulated in a
> version 1 SignedData?
[snip]

I can see arguments on each side:

If the SignedData version is bumped, that will possibly make some ASN.1
decoders happier.

If the SignedData version is left as is, then messages that contain
multiple SignerInfos, some of which are v1/v2, may be partially processed.

Neither of these are critical (both problems can be programmed around),
but I
think the later would be better for implementors (although the spec needs
to state
what to do when there are SignerInfos with "too high" version numbers).

On the other hand, my guess would be that bumping the SignedData version number
is ASN.1 Best Current Practice. Does anyone know?

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA20865 for ietf-smime-bks; Tue, 12 Jan 1999 15:27:30 -0800 (PST)
Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA20861 for ; Tue, 12 Jan 1999 15:27:29 -0800 (PST)
Received: by dfssl.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id ; Tue, 12 Jan 1999 15:28:21 -0800
Message-ID: <2FBF98FC7852CF11912A0000000000010ECB5BF1@localhost>
From: "Jim Schaad (Exchange)"
To: "'Russ Housley'"
Cc: "Ietf-Smime (E-mail)"
Subject: RE: Last Call Comments on CMS-10
Date: Tue, 12 Jan 1999 15:28:18 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

Russ --
Great.

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: Tuesday, January 12, 1999 2:32 PM
> To: Jim Schaad (Exchange)
> Cc: Ietf-Smime (E-mail)
> Subject: RE: Last Call Comments on CMS-10
>
>
> Jim:
>
> >> >4. Section 5, First pagagraph after the bullets. The text
> >> has not been
> >> >updated to reflect the SKI addition to the signer info object.
> >>
> >> Good catch. How about:
> >> ... The signer's public key is referenced by an issuer
> >> distinguished name along with an issuer-specific serial
> >> number or a subject key identifier that uniquely identify
> >> the certificate containing the public key.
> >>
> >
> >Wording is good, but I would like "is referenced either by".
>
> Here it is:
> ... The signer's public key is referenced either
> by an issuer distinguished name along with an
> issuer-specific serial number or by a subject key
> identifier that uniquely identifies the certificate
> containing the public key. The signer's certificate
> may be included in the SignedData certificates field.
>
> Russ
>

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA20290 for ietf-smime-bks; Tue, 12 Jan 1999 14:29:57 -0800 (PST)
Received: from thehub.knight-hub.com ([email-masked] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA20286 for ; Tue, 12 Jan 1999 14:29:56 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id RAA28131; Tue, 12 Jan 1999 17:31:14 -0500
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Tue, 12 Jan 1999 17:31:53 -0500
To: "Jim Schaad (Exchange)"
From: Russ Housley
Subject: RE: Last Call Comments on CMS-10
Cc: "Ietf-Smime (E-mail)"
In-Reply-To: <2FBF98FC7852CF11912A0000000000010ECB5BEF@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

Jim:

>> >4. Section 5, First pagagraph after the bullets. The text
>> has not been
>> >updated to reflect the SKI addition to the signer info object.
>>
>> Good catch. How about:
>> ... The signer's public key is referenced by an issuer
>> distinguished name along with an issuer-specific serial
>> number or a subject key identifier that uniquely identify
>> the certificate containing the public key.
>>
>
>Wording is good, but I would like "is referenced either by".

Here it is:
... The signer's public key is referenced either
by an issuer distinguished name along with an
issuer-specific serial number or by a subject key
identifier that uniquely identifies the certificate
containing the public key. The signer's certificate
may be included in the SignedData certificates field.

Russ

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA20267 for ietf-smime-bks; Tue, 12 Jan 1999 14:28:31 -0800 (PST)
Received: from aum (ip08.proper.com [165.227.249.8]) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA20263 for ; Tue, 12 Jan 1999 14:28:30 -0800 (PST)
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Tue, 12 Jan 1999 14:27:49 -0800
To:
From: Paul Hoffman / IMC
Subject: Re: Last Call Comments on CMS-10
In-Reply-To: <[email-masked]>
References: <2FBF98FC7852CF11912A0000000000010FF8A6D7@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

At 02:35 PM 1/12/99 -0500, Russ Housley wrote:
>>3. The algorithm OIDs defined and used in section 12 are not included in the
>>ASN module.
>
>I know. This is a philosophy question. Since these identifiers will
>eventually be in the IANA registry, I did not know whether or not these values
>should be part of the module.
>
>I would be glad to add these values to the module if the working group thinks
>they belong there. Comments?

Please do add them here. It could take a *long* time for them to get into
the IANA, and this document should stand on its own. It is common for the
IANA registries to start with a set of values that were defined in an RFC.

--Paul Hoffman, Director
--Internet Mail Consortium

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA20031 for ietf-smime-bks; Tue, 12 Jan 1999 14:12:08 -0800 (PST)
Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA20026 for ; Tue, 12 Jan 1999 14:12:07 -0800 (PST)
Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id ; Tue, 12 Jan 1999 14:12:57 -0800
Message-ID: <2FBF98FC7852CF11912A0000000000010ECB5BEF@localhost>
From: "Jim Schaad (Exchange)"
To: "'Russ Housley'"
Cc: "Ietf-Smime (E-mail)"
Subject: RE: Last Call Comments on CMS-10
Date: Tue, 12 Jan 1999 14:12:56 -0800
X-Mailer: Internet Mail Service (5.5.2232.9)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

Russ:

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: Tuesday, January 12, 1999 11:36 AM
> To: Jim Schaad (Exchange)
> Cc: Ietf-Smime (E-mail)
> Subject: Re: Last Call Comments on CMS-10
>
>
> Jim:
>
> >1. Section 2, Last paragraph, Sentence 4: I think that
> "However, signed
> >attributes within the signed-data content type and
> authenticated attributes
> >within the authenticated-data content type require DER
> encoding." should
> >read "However, signed attributes within the signed-data content type
> >andauthenicated a attributes within the authenticated-data
> content type are
> >the only places where DER encoding is required."
>
> I prefer:
> ... However, signed attributes within the signed-data
> content type and
> authenticated attributes within the authenticated-data
> content type require DER
> encoding. Signed attributes and authenticated attributes
> must be transmitted
> in DER form to ensure that recipients can validate a content
> that contains an
> unrecognized attribute. Signed attributes and authenticated
> attributes are the
> only CMS data types that require DER encoding.

This wording is great.

>
> >3. The algorithm OIDs defined and used in section 12 are not
> included in the
> >ASN module.
>
> I know. This is a philosophy question. Since these identifiers will
> eventually be in the IANA registry, I did not know whether or
> not these values
> should be part of the module.
>
> I would be glad to add these values to the module if the
> working group thinks
> they belong there. Comments?
>
> >4. Section 5, First pagagraph after the bullets. The text
> has not been
> >updated to reflect the SKI addition to the signer info object.
>
> Good catch. How about:
> ... The signer's public key is referenced by an issuer
> distinguished name along with an issuer-specific serial
> number or a subject key identifier that uniquely identify
> the certificate containing the public key.
>

Wording is good, but I would like "is referenced either by".

> >7. Section 5.1: Text on version needs to be expanded to
> deal with SKI.
> >Must be 3 if any SignerInfo version is 3.
>
> Are you saying that a version 3 SignerInfo should cause
> parent SignedData
> version to be 3?
>
> Is there a reason to prohibit version 3 SignerInfo from being
> encapsulated in a
> version 1 SignedData?

This is the backwards compatability thing. Everywhere else we have done --
you get a new version all the way up (See EnvelopedData) if you do something
new on an inner object. This prevents you from starting something you may
regret. If we don't do this here, then I don't see why we should be doing
it in EnvelopedData. I don't care which of the two we correct, but make
them consistant.

>
> >10. Section 12.3.1, paragraph 3. I would like to change the
> first sentence
> >to "A CMS Implementation should support mixed key-encryption and
> >content-encryption algorithms."
>
> Disgree. I am reluctant to change "may" to "should." What
> do other people
> think?
>
> >11. Section 12.3.3 - Please insert the following paragraph
> in this section
> >" A CMS implementation should support mixed key-encryption
> and content-
> > encryption algorithms. For example, a 128-bit RC2
> content-encryption
> > key may be wrapped with 168-bit Triple-DES key-encryption key.
> > Similarly, a 40-bit RC2 content-encryption key may be wrapped with
> > 128-bit RC2 key-encryption key."
>
> As with comment 10, I would like to hear what other people
> think before
> changing "may" to "should."

Can I at least get you to agree to put in the paragraph with the "may"
syntax even if I get no support for "should"?

>
> >12. Ditto 11 for section 12.6
>
> Ditto. As with comments 10 and 11, I would like to hear what
> other people
> think before changing "may" to "should."
>

> Russ

jim

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA19895 for ietf-smime-bks; Tue, 12 Jan 1999 13:59:06 -0800 (PST)
Received: from thehub.knight-hub.com ([email-masked] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA19890 for ; Tue, 12 Jan 1999 13:59:05 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id RAA26719; Tue, 12 Jan 1999 17:00:23 -0500
Message-Id: <[email-masked]>
Message-Id: <[email-masked]>
Message-Id: <[email-masked]>
X-Sender: [email-masked] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Tue, 12 Jan 1999 14:35:37 -0500
To: "Jim Schaad (Exchange)"
From: Russ Housley
Subject: Re: Last Call Comments on CMS-10
Cc: "Ietf-Smime (E-mail)"
In-Reply-To: <2FBF98FC7852CF11912A0000000000010FF8A6D7@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

Jim:

>1. Section 2, Last paragraph, Sentence 4: I think that "However, signed
>attributes within the signed-data content type and authenticated attributes
>within the authenticated-data content type require DER encoding." should
>read "However, signed attributes within the signed-data content type
>andauthenicated a attributes within the authenticated-data content type are
>the only places where DER encoding is required."

I prefer:
... However, signed attributes within the signed-data content type and
authenticated attributes within the authenticated-data content type require DER
encoding. Signed attributes and authenticated attributes must be transmitted
in DER form to ensure that recipients can validate a content that contains an
unrecognized attribute. Signed attributes and authenticated attributes are the
only CMS data types that require DER encoding.

>2. ASN Module Errors
>"cms.asn", line 176 (CryptographicMessageSyntax): A0256W: 'DigestAlgorithm'
>is referenced, but is not defined.
>Need to change DigestAlgorithm to DigestAlgorithmIdentifier in
>AuthenticatedData

Ooops. You are correct.

>3. The algorithm OIDs defined and used in section 12 are not included in the
>ASN module.

I know. This is a philosophy question. Since these identifiers will
eventually be in the IANA registry, I did not know whether or not these values
should be part of the module.

I would be glad to add these values to the module if the working group thinks
they belong there. Comments?

>4. Section 5, First pagagraph after the bullets. The text has not been
>updated to reflect the SKI addition to the signer info object.

Good catch. How about:
... The signer's public key is referenced by an issuer
distinguished name along with an issuer-specific serial
number or a subject key identifier that uniquely identify
the certificate containing the public key.

>5. Same as above: "that uniquely identify the certificate containing the
>public key" Should read "that uniquely identifies the certificate..."

I changed "identify" to "identifies."

>6. Section 5.1: The last two paragraphs really belong as part of section
>5.2 as they are discussing EncapsulatedContentInfo. This is especially true
>given that it is refered to from places like section 7.

Agreed. I moved them to the end of section 5.2.

>7. Section 5.1: Text on version needs to be expanded to deal with SKI.
>Must be 3 if any SignerInfo version is 3.

Are you saying that a version 3 SignerInfo should cause parent SignedData
version to be 3?

Is there a reason to prohibit version 3 SignerInfo from being encapsulated in a
version 1 SignedData?

>8. Section 9. nit-pik -- authenticatedAttributes is misspelt in the ASN for
>AuthenticatedData (but it is consistantly misspelt).

I did a global substitution of "authenctiatedAttributes" with
"authenticatedAttributes."

>9. Section 10.2.6 -- I don't like the first sentence. How about "The
>UserKeyingMaterial type gives a syntax for user keying material (UKM)."

Okay. I added "for" to the sentence.

>10. Section 12.3.1, paragraph 3. I would like to change the first sentence
>to "A CMS Implementation should support mixed key-encryption and
>content-encryption algorithms."

Disgree. I am reluctant to change "may" to "should." What do other people
think?

>11. Section 12.3.3 - Please insert the following paragraph in this section
>" A CMS implementation should support mixed key-encryption and content-
> encryption algorithms. For example, a 128-bit RC2 content-encryption
> key may be wrapped with 168-bit Triple-DES key-encryption key.
> Similarly, a 40-bit RC2 content-encryption key may be wrapped with
> 128-bit RC2 key-encryption key."

As with comment 10, I would like to hear what other people think before
changing "may" to "should."

>12. Ditto 11 for section 12.6

Ditto. As with comments 10 and 11, I would like to hear what other people
think before changing "may" to "should."

>13. Security Considerations, pargraph 7 - Typo with wises for wishes

I changed it to "wishes."

Russ

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA19881 for ietf-smime-bks; Tue, 12 Jan 1999 13:59:00 -0800 (PST)
Received: from thehub.knight-hub.com ([email-masked] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA19876 for ; Tue, 12 Jan 1999 13:58:59 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id RAA26678 for ; Tue, 12 Jan 1999 17:00:12 -0500
Message-Id: <[email-masked]>
Message-Id: <[email-masked]>
Message-Id: <[email-masked]>
X-Sender: [email-masked] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Tue, 12 Jan 1999 10:55:01 -0500
To: [email-masked]
From: Russ Housley
Subject: CERT-06
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

Blake & S/MIME WG Members:

Here are my comments.

1. In the "Overview," please change "I-D" to "document" to avoid changes
that the RFC Editor will have to make.

2. Section 2.1 says:
Agents MUST use revocation information included as a CRL in an S/MIME
message when verifying the signature and certificate path validity in
that message. Agents SHOULD store CRLs received in messages for use in
processing later messages.

What if a newer CRL is available in the Directory or cache? The recipient
should not be forced to use a stale CRL because the originator included it
in the message.

3. Section 2.3 says:
Receiving agents MUST support chaining based on the distinguished name
fields. Other methods of building certificate chains may be supported
but are not currently recommended.

I agree that DN chaining must be supported. However, I do not think that
we should discourage chain building based on key identifiers.

4. Section 3.1 says:
Receiving agents MUST recognize email addresses in the subjectAltName
field. Receiving agents MUST recognize email addresses in the
Distinguished Name field.

Should we say which attribute of the DN will be used to carry an e-mail
address?

5. Section 3.1 says:
Sending agents SHOULD make the address in the From or Sender 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
or Sender header of a mail message matches an Internet mail address in
the signer's certificate, if mail addresses are present in the
certificate. A receiving agent SHOULD provide some explicit alternate
processing of the message if this comparison fails, which may be to
display a message that shows the recipient the addresses in the
certificate or other certificate details.

Name matching is not required for encryption. Is this an omission? If
not, let's explicitly state that the check is not needed.

6. Section 4 says:
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 such as directory servers. 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.

The PKIX work in this area is ahead of us. We should probably give a
better reference. Also, the CRL should be discussed as well as the
certificate.

7. Section 4.4 says:
PKIX 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 extensions will be used. Further, there
are active efforts underway to issue PKIX certificates for business
purposes. This draft identifies the minumum required set of
certificate extensions which have the greatest value in the S/MIME
environment. The basicConstraints, and keyUsage extensions are defined
in [KEYM].

In my opinion, this needs to be reworded. The phrase "... there is still a
fair amount of profiling work to be done ..." says that we are not done! I
do not think there is any more work to be done. PKIX Part 1 is with the
RFC Editor.

8. Section 4.4.2.1 says:
For Diffie-Hellman key exchange certificates (certificates in which
the subject public key algorithm is dhpublicnumber), more
clarification is needed as to how to interpret the key usage
extension. If the keyUsage keyAgreement bit is set to 1 AND if the
public key is to be used to form a pairwise key to decrypt data, then
the S/MIME agent MUST only use the public key if the keyUsage
encipherOnly bit is set to 0. If the keyUsage keyAgreement bit is set
to 1 AND if the key is to be used to form a pairwise key to encrypt
data, then the S/MIME agent MUST only use the public key if the
keyUsage decipherOnly bit is set to 0.

In my opinion, this needs to be reworded. The phrase "... more
clarification is needed ..." leads the reader to think we are not finished
with our work. We are done!

Russ

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA19877 for ietf-smime-bks; Tue, 12 Jan 1999 13:58:59 -0800 (PST)
Received: from thehub.knight-hub.com ([email-masked] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA19866 for ; Tue, 12 Jan 1999 13:58:57 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id RAA26692 for ; Tue, 12 Jan 1999 17:00:16 -0500
Message-Id: <[email-masked]>
Message-Id: <[email-masked]>
X-Sender: [email-masked] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Tue, 12 Jan 1999 11:01:18 -0500
To: [email-masked]
From: Russ Housley
Subject: ESS-10
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

Paul & S/MIME WG Memeber:

1. Section 1, Introduction, says:
This document describes three optional security service extensions for
S/MIME. These services provide functionality that is similar to the Message
Security Protocol [MSP4], but are useful in many other environments,
particularly business and finance. The services are:
- signed receipts
- security labels
- secure mailing lists

I think that the signature attribute stuff should be included in the
introduction.

2. Section 1.3.4, Placement of Attributes, should be slightly expanded. It
should state that UnprotectedAttributes from EnvelopedData are not used to
carry
any of the attributes specifed in ESS.

3. Section 1.3.4, Placement of Attributes, still talks about the macValue
attribute. It has been deleted from [CMS], and it should be deleted here too.

4. Section 2.2.1 says, "Each recipient SHOULD return only one signed
receipt."
A related section should also state that recipients of receipts should be
prepaed to deal with duplicates.

5. Section 3, Security Labels, says:
... The labels are often priority based ("secret", "confidential",
"restricted", and so on) or role-based, describing which kind of people can
see the information ("patient's health-care team", "medical billing
agents", "unrestricted", and so on).

I think that "priority" is the wrong word. These labels state the amount of
harm that would result from the disclosure of the information.

6. Section 5, Signing Certificate Attribute, says:
Attribute certificates can be used as part of a signature verification
process. ...

I would prefer: Attribute certificates might support signature verification.

7. Section 5.1, Attack Descriptions, says:
At least three different attacks can be launched against a possible
signature verification process by changing the certificate or certficates
used in the signature verification process.

I would prefer "substituting" or "replacing" instead of "changing." The
certificate cannot be modified without invalidating the signature.

8. Section 5.4.1, Certificate Identification,
The best way to identify certificates is an often-discussed issue. CMS has
imposed a restriction for SignedData objects that the issuer DN must be
present in all signing certificates. ...

I think that the restriction is in CERT (not CMS). Please confirm.

Russ

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA19867 for ietf-smime-bks; Tue, 12 Jan 1999 13:58:58 -0800 (PST)
Received: from thehub.knight-hub.com ([email-masked] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA19860 for ; Tue, 12 Jan 1999 13:58:56 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id RAA26675 for ; Tue, 12 Jan 1999 17:00:11 -0500
Message-Id: <[email-masked]>
Message-Id: <[email-masked]>
Message-Id: <[email-masked]>
X-Sender: [email-masked] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Tue, 12 Jan 1999 10:55:24 -0500
To: [email-masked]
From: Russ Housley
Subject: MSG-06
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

Blake and S/MIME WG Members:

I do have a few comments.

1. Section 2.5.2 says:
There is a list of OIDs (OIDs Used with S/MIME) that is centrally
maintained and is separate from this draft. The list of OIDs is
maintained by the Internet Mail Consortium at .

This is true, and it is fine. However, I think that we should state that all
of the OIDs assosciated with the MUST and SHOULD implement algorithms are at
the end of this document. This is important for configuration control.

Further, the ESS document states that the registry will be transitioned to the
IANA (or ICANN). I think that the two documents should send the same message.

2. Section 2.7 says:
Sending and receiving agents MUST support encryption and decryption
with DES EDE3 CBC, hereinafter called "tripleDES" [3DES] [DES].
Receiving agents SHOULD support encryption and decryption using the
RC2 [RC2] or a compatible algorithm at a key size of 40 bits,
hereinafter called "RC2/40".

Since RC2 is described in an RFC, can we drop "or a compatible algorithm"?

3. Section 2.7.3 says:
If a sending agent is composing an encrypted message to a group of
recipients where the encryption capabilities of some of the recipients
do not overlap, 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 that we should provide rationale why this is not the circumstance to
use the mandatory to implment algorithm.

Also, I think that "can" is too strong. We should say "may be able to." You
are really saying that the message text can be recovered from the weakly
encrypted message in lieu of the stringly encrypted one. This is clearly
true. There are too many other variables to assert thet the weakly encrypted
message provides enough information to recover the key used for the strongly
encrypted one. A strong cipher algorithm should not be vulnerable to known
plaintext attacks.

4. Section 3.2.2 says:
If no common string is assigned. Then the common string of
"OID." is recommended.

I agree. However, an example is needed since people write OIDs in more than
one way. I assume that petiods between each number is the intended style.
Suggestion: DES40 would be "OID.1.3.6.1.5.5.7.6.1".

5. Section 5 says:
If a sending agent is sending the same message using different
strengths of cryptography, an attacker watching the communications
channel can determine the contents of the strongly-encrypted message
by decrypting the weakly-encrypted version. In other words, a sender
should not send a copy of a message using weaker cryptography than
they would use for the original of the message.

You are raising a good point here. However, I would like a small change. In
the 3rd line, I think that "can" should be changed to "may be able to." If
enough things are changed (subject line, etc), then the attacker may not be
able to tell that the two plaintexts are the same.

6. In section 4.1, you talk about random numbers. I suggest that you add a
reference to:

RANDOM Eastlake, D.; S. Crocker; J. Schiller. Randomness
Recommendations for Security. RFC 1750. December 1994.

Russ

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA19638 for ietf-smime-bks; Tue, 12 Jan 1999 13:22:42 -0800 (PST)
Received: from aum (ip08.proper.com [165.227.249.8]) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA19634 for ; Tue, 12 Jan 1999 13:22:41 -0800 (PST)
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Tue, 12 Jan 1999 13:22:04 -0800
To:
From: Paul Hoffman / IMC
Subject: Re: Comments on ESS-10
In-Reply-To: <2FBF98FC7852CF11912A0000000000010ECB5BD7@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

At 07:39 PM 1/9/99 -0800, Jim Schaad (Exchange) wrote:
>4. Section 2.8 - ASN for Receipt still references Version not CMSVersion

Many thanks to Russ for switching this out from under me. :-) I do *not*
think we should import CMSVersion from CMS, because the version number we
are using here has nothing to do with CMS, and the name will be confusing.
Instead, I think I should define it as:

Version ::= INTEGER { v1(1) }

Comments?

--Paul Hoffman, Director
--Internet Mail Consortium

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA10081 for ietf-smime-bks; Mon, 11 Jan 1999 12:30:06 -0800 (PST)
Received: from exchng-fairfax.p-e-c.com (exchng-fairfax.pec.com [204.254.216.13]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA10077 for ; Mon, 11 Jan 1999 12:30:05 -0800 (PST)
Received: by exchang-fairfax.pec.com with Internet Mail Service (5.0.1460.8) id ; Mon, 11 Jan 1999 15:32:39 -0500
Message-ID: <[email-masked]>
From: WHenry
To: "[email-masked]'"
Subject: Document-centric Digital Signatures
Date: Mon, 11 Jan 1999 15:32:38 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: multipart/alternative; boundary="---- =_NextPart_001_01BE3DA1.87C2F9F0"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

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_001_01BE3DA1.87C2F9F0
Content-Type: text/plain

All:

Several months ago I started a discussion thread on ietf-pkix about the
viability of embedding digital signatures within electronic documents (e.g.
Word, Excel, etc).

Some of the responses I received ranged from "use CMS!" to "it would be
difficult to get application vendors on-board." There seemed to be some
interest in establishing a BOF at the next IETF mtg to discuss this.

In the absence of a BOF, I've set up a listserv for discussing this issue
at http://www.onelist.com. You can subscribe to Disig-arch under Computers -
Security or use the following URL
http://www.onelist.com/viewarchive.cgi?listname=digsig-arch

Subscribers post to the list using the following address:
[email-masked]

"Digsig-arch" is an unmoderated list intended to provide a forum for the
discussion of issues related to the archiving of digitally signed electronic
documents. The list focuses on public key infrastructure (PKI) associated
digital signature issues vice biometric or electronic signature issues.

Apologies for not providing an email subscribe/unsubscribe capability.
However, the service is free and very easy to maintain (which we like!).
Onelist will maintain a discussion archive at the site for those interested
in reviewing previous postings.

I've taken the liberty of posting my (and others) previous ietf-pkix
postings regarding this issue in the archive (from May '98 timeframe).

Regards,
Bill Henry
Performance Engineering Corporation
Fairfax, VA

------ =_NextPart_001_01BE3DA1.87C2F9F0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

Document-centric Digital Signatures

All:

Several months ago I started a =
discussion thread on ietf-pkix about the viability of embedding digital =
signatures within electronic documents (e.g. Word, Excel, =
etc).

Some of the responses I received =
ranged from "use CMS!" to "it would be difficult to get =
application vendors on-board." There seemed to be some interest in =
establishing a BOF at the next IETF mtg to discuss this.

In the absence of a BOF, I've =
set up a listserv for discussing this issue at http://www.onelist.com. You can subscribe to =
Disig-arch under =
Computers - Security or use the following URL http://www.onelist.com/viewarchive.cgi?listname=3Ddigs=
ig-arch

Subscribers =
post to the list using the following address:

[email-masked]

"Digsig-arch" is an unmoderated list =
intended to provide a forum for the discussion of issues related to the =
archiving of digitally signed electronic documents. The list focuses on =
public key infrastructure (PKI) associated digital signature issues =
vice biometric or electronic signature issues.

Apologies for =
not providing an email subscribe/unsubscribe capability.  However, =
the service is free and very easy to maintain (which we like!). Onelist =
will maintain a discussion archive at the site for those interested in =
reviewing previous postings.

I've taken the =
liberty of posting my (and others) previous ietf-pkix postings =
regarding this issue in the archive (from May '98 =
timeframe).

Regards,

Bill =
Henry

Performance =
Engineering Corporation

Fairfax, =
VA

------ =_NextPart_001_01BE3DA1.87C2F9F0--

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA07107 for ietf-smime-bks; Mon, 11 Jan 1999 07:27:42 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA07103 for ; Mon, 11 Jan 1999 07:27:41 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA18158; Mon, 11 Jan 1999 10:28:20 -0500 (EST)
Message-Id: <[email-masked]>
To: IETF-Announce: ;
Cc: [email-masked]
From: The IESG
SUBJECT: Last Call: Cryptographic Message Syntax to Proposed Standard
Reply-to: [email-masked]
Date: Mon, 11 Jan 1999 10:28:20 -0500
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

The IESG has received a request from the Secure MIME BOF Working Group
to consider the following Internet-Drafts as Proposed Standards:

o Cryptographic Message Syntax
o Diffie-Hellman Key Agreement Method
o S/MIME Version 3 Certificate Handling
o S/MIME Version 3 Message Specification
o Enhanced Security Services for S/MIME

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
[email-masked] or [email-masked] mailing lists by January 25, 1999.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-10.txt
http://www.ietf.org/internet-drafts/draft-ietf-smime-x942-04.txt
http://www.ietf.org/internet-drafts/draft-ietf-smime-cert-06.txt
http://www.ietf.org/internet-drafts/draft-ietf-smime-msg-06.txt
http://www.ietf.org/internet-drafts/draft-ietf-smime-ess-10.txt

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA02752 for ietf-smime-bks; Mon, 11 Jan 1999 00:47:37 -0800 (PST)
Received: from tlcpi.finsiel.it (zero.tlcpi.finsiel.it [195.103.245.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA02748 for ; Mon, 11 Jan 1999 00:47:19 -0800 (PST)
Received: (from root@localhost) by tlcpi.finsiel.it (8.8.7/8.8.7) id JAA14053 for ; Mon, 11 Jan 1999 09:44:03 +0100
Received: from tecpi.tlcpi.finsiel.it(193.43.104.9) by zero via smap (V2.0beta) id xma014049; Mon, 11 Jan 99 09:43:51 +0100
Received: from Campanari.tecsiel.it ([193.43.104.174]) by tecpi with SMTP (1.37.109.16/16.2) id AA200364400; Mon, 11 Jan 1999 09:46:41 +0100
Message-Id: <[email-masked]>
From: "Ilaria Campanari"
To:
Subject: MIME++
Date: Mon, 11 Jan 1999 09:46:08 +0100
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-Mimeole: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

Does anybody uses the MIME++ C++ Library of Douglas W. Sauder to build and
parse MIME objects? Does anybody knows similar freeware products?

Ilaria

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA11211 for ietf-smime-bks; Sat, 9 Jan 1999 19:43:33 -0800 (PST)
Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA11206; Sat, 9 Jan 1999 19:43:32 -0800 (PST)
Received: by dfssl.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id ; Sat, 9 Jan 1999 19:39:46 -0800
Message-ID: <2FBF98FC7852CF11912A0000000000010ECB5BD7@localhost>
From: "Jim Schaad (Exchange)"
To: "Paul Hoffman (E-mail)" , "Ietf-Smime (E-mail)"
Cc: "Russ Housley (E-mail)"
Subject: Comments on ESS-10
Date: Sat, 9 Jan 1999 19:39:32 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

Paul,

These comments are in addition to the changes to ESS Section 5 for the
addition of the SKI as a certificate identifier on CMS I previously sent
you.

0. Section 1. We have not yet seen the new introduction paragraphs which
include section 5. I would like to do so before the document goes to the
RFC editor.

1. Section 1.3 - the macValue attribute has been removed from CMS and needs
to be removed from CMS

2. Section 1.4 - Minor word changes in paragraph 2. "The main disadvantage
is that the gateway must check for the presence of certain attributes in the
other signerInfos and either omit or copy those attributes."

3. Section 2.2 - bullet item 4: I have some \240 characters in the text
here which I assume are suppose to be spaces. Many of these are found
through out the entire document. I have had to edit them out to get the ASN
module to compile.

4. Section 2.8 - ASN for Receipt still references Version not CMSVersion

5. Section 4.4 - The ASN for MLData has a comment on EntityIdentifier has a
note about being imported from CMS, but its not. Please remove the comment
in the text and in the ASN module

Jim

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA10169 for ietf-smime-bks; Sat, 9 Jan 1999 15:52:15 -0800 (PST)
Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA10165 for ; Sat, 9 Jan 1999 15:52:14 -0800 (PST)
Received: by dfssl.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id ; Sat, 9 Jan 1999 15:48:12 -0800
Message-ID: <2FBF98FC7852CF11912A0000000000010ECB5BD5@localhost>
From: "Jim Schaad (Exchange)"
To: "Ietf-Smime (E-mail)" , "Blake Ramsdell (E-mail)"
Cc: "Russ Housley (E-mail)"
Subject: Last Call comments on the Message And Certificate Drafts
Date: Sat, 9 Jan 1999 15:47:58 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

Blake & Russ,

Here are my last call comments on the message and certificates draft. There
is one comment in here that, if you decide to do it, would also affect the
CMS and ESS drafts.

Jim

General Comments

1. I would like to see some consistancy developed in the reference naming
between the different documents produced from the S/MIME working group. I
especially dislike the KEYM reference name for PKIX Part1 as this is really
misleading. Part1 does not really say anything bout key management.

2. Are we requesting obsoletion of the V2 drafts or not. If we are then why
are we refering to them. If we are not then we need to make this clear to
the RFC editors. Based on the current thinking, it would be my guess that
we are not requesting the obsoletion of the S/MIME V2 drafts.

Message -06 draft Comments

1. Section 2.4.1 - Example on signature appears to eleminate
multipart/signed as it states content MUST be stored in eContent OCTET
STRING. I would strongly recommend removing the MUST on this as it is
example not statement of operation.

2. Section 2.5 - Why do we mention receipt requests but not security labels.
I would think they are of equal importance and should either both be
mentioned or omitted. This is especially true as security labels can easily
be understood by V2 clients but not receipts (well at least not easily). I
recommend we strike the reference to receipt requests.

3. Section 2.6 -- This is not stated in the format of a MUST. Change to
"S/MIME v3 agents MUST use the isserAndSerialNumber form of SignerInfo." or
similar statement.

4. Section 2.7.1.3 - Given that rule #4 appears to have vanished, there is
no reason not to remove all references to "Unknown version of S/MIME" in
this section. I recomment that we strike all such references.

5. Section 3.2.1 - The last sentence contains a "MUST not" this should be
"MUST NOT"

6. Section A - Changing to an ASN module would be considered niceness but
not necessity. I an finding that I use ASN modules more and more for
creation of ASN encode/decode functions. Given that we now have several
different ASN structures in this appendix, I would like to see this combined
into an ASN module. I can create this if desired.

7. References -- The [DH] citation should be made to reference the internet
draft/RFC

Certificate Draft comments

1. Section 1 - Reference to KEYM in the last sentence of paragraph #1 is
almost certianly meant to be a reference to SMIME-MSG

2. Section 1 - PKCS#10 requirements are in the V2 Msg Draft and not the V3
message draft. This text needs to be omitted or refer to MSG-V2 instead.
(CERT-V2?)

3. Section A - Remove reference to CRMF as we don't use it

4. Section 2.3 - P#3 - Given inheritance of DSA parameters do we need to
modify the statement on not sending the root CA cert. Messages are not even
internally validatable with out the root in some cases.

5. Section 4.3 - Why is there a reference to SMIME-MSG for RSA but not for
DSA? Why is there no reference for DSA?

6. Section 4.4 - P#1 - Lets replace the last sentence with "The syntax and
semantics of all the identified extensions are defined in [KEYM]."

7. Section 4.4 - P#2 - Replace sentence #1 with "... the Basic Constraints,
Key Usage, Authority Key Identifier, Subject Key Identifier and Subject
Alternative Name Certificate Extensions when they ..."

8. Section 4.4.1 - We have a big conflict with PKIX. We say
basicConstraints should appear, they say it should not. My personal opinion
on this one is that PKIX is wrong and we should not change it, but I raise
this as an incompatiblity between the two drafts.

9. Section 4.4.1 - Should we add the same criticality statement as occurs in
PKIX -- i.e. MUST be critical if it appears. I recommend that we strike the
criticality statment in 4.4.2 as it duplicates information in PKIX part1.

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA08131 for ietf-smime-bks; Sat, 9 Jan 1999 10:45:35 -0800 (PST)
Received: from jis.ne.mediaone.net (jis.ne.mediaone.net [24.128.10.141]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA08127 for ; Sat, 9 Jan 1999 10:45:31 -0800 (PST)
Received: from mit.edu (localhost [127.0.0.1]) by jis.ne.mediaone.net (8.8.7/8.8.4) with ESMTP id NAA00333; Sat, 9 Jan 1999 13:46:24 -0500
Message-ID: <[email-masked]>
Disposition-Notification-To: "Jeffrey I. Schiller"
Date: Sat, 09 Jan 1999 13:46:24 -0500
From: "Jeffrey I. Schiller"
Organization: Massachusetts Institute of Technology
X-Mailer: Mozilla 4.5 [en] (X11; U; Linux 2.0.30 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Russ Housley
CC: [email-masked]
Subject: Re: Ready For Last Call: draft-ietf-smime-ess-10.txt
References: <[email-masked]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms4501F2D05FBFC3AF6A7C2337"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

This is a cryptographically signed message in MIME format.

--------------ms4501F2D05FBFC3AF6A7C2337
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

All of your Last Call requests have been processed (i.e., I have asked
the Secretariat to issue the Last Calls). The next IESG Telechat where
they can be voted on is on January 28th. However I will not be able to
personally be present on that call (I'll be on an airplane at the time)
so there is a chance that they may not be approved at that meeting. The
following IESG telechat is on February 11th, for which I plan to be
present. Hopefully all outstanding documents will be approved on or
before that date.

-Jeff

--------------ms4501F2D05FBFC3AF6A7C2337
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIEiAYJKoZIhvcNAQcCoIIEeTCCBHUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
AoMwggJ/MIIB6AIDATe5MA0GCSqGSIb3DQEBBAUAMGwxCzAJBgNVBAYTAlVTMRYwFAYDVQQI
Ew1NYXNzYWNodXNldHRzMS4wLAYDVQQKEyVNYXNzYWNodXNldHRzIEluc3RpdHV0ZSBvZiBU
ZWNobm9sb2d5MRUwEwYDVQQLEwxDbGllbnQgQ0EgdjEwGhcLOTgxMjIzMDIwMFoXCzk5MTIy
MzAyMDBaMIGlMQswCQYDVQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEuMCwGA1UE
ChMlTWFzc2FjaHVzZXR0cyBJbnN0aXR1dGUgb2YgVGVjaG5vbG9neTEVMBMGA1UECxMMQ2xp
ZW50IENBIHYxMRswGQYDVQQDExJKZWZmcmV5IEkgU2NoaWxsZXIxGjAYBgkqhkiG9w0BCQET
C2ppc0BNSVQuRURVMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC6LFHhYYpFuotoKI7N
tMXX2oRUglnD43MiA+zxNU9mW82tWFiX5hrtrx7gbXv8HIqhKcS7uZHmc84P4FuJAlNtM3I2
LVDc0Rr85IFq3SQFG7+/mo6riIWL3uEkPS3LnZaKH9peopybibbFLabZgC/IJrOY3RHzmkpk
UFU1wwNwmQIDAQABMA0GCSqGSIb3DQEBBAUAA4GBACYQ6u2qshATnUEvbGgRcID1ZqckS6rm
0q2g2yhf3S4VlCyAtAHR5Zg/SXmKSzDcXIwXsDeTUHfczmdIbvdcYncLiEZzWB9JHVrIrp6f
R9QoZBJIQ+QxIKouayCx8hM6pTSbDeNqpjxy2VWKOlVUVAgPekLhYE/Cd7yMlRR5cMloMYIB
zTCCAckCAQEwczBsMQswCQYDVQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEuMCwG
A1UEChMlTWFzc2FjaHVzZXR0cyBJbnN0aXR1dGUgb2YgVGVjaG5vbG9neTEVMBMGA1UECxMM
Q2xpZW50IENBIHYxAgMBN7kwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN
AQcBMBwGCSqGSIb3DQEJBTEPFw05OTAxMDkxODQ2MjRaMCMGCSqGSIb3DQEJBDEWBBRodl2L
tYEDTBholPW05d1/FaPpYTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3
DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG
9w0BAQEFAASBgBq3jwmEg6Qs1mv4xMkbF8ZhskX6pWFqGOJmO8yfqTQER69GBCXmchXe6QD3
jODHwKPpneH0Ifkx9E8Wnwhw7dcuakCnePqak8ZjHsAXs2yqX8AKjTeoTWpJ3QkTJmK5lKVn
NOt2co9gBrm3/NgV3aC0CTE7WHf909wK2XcxHXKY
--------------ms4501F2D05FBFC3AF6A7C2337--

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA10119 for ietf-smime-bks; Fri, 8 Jan 1999 14:23:47 -0800 (PST)
Received: from thehub.knight-hub.com ([email-masked] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA10115 for ; Fri, 8 Jan 1999 14:23:46 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id RAA12727 for ; Fri, 8 Jan 1999 17:24:43 -0500
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Fri, 08 Jan 1999 17:25:50 -0500
To: [email-masked]
From: Russ Housley
Subject: S/MIME at 44th IETF-MINNEAPOLIS, MN
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

This is to confirm one session for the S/MIME WG at 44th IETF-MINNEAPOLIS, MN.
We will meet on Wednesday, March 17 at 0900-1130.

Send me any agenda items.

Russ

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA09223 for ietf-smime-bks; Fri, 8 Jan 1999 14:09:28 -0800 (PST)
Received: from thehub.knight-hub.com ([email-masked] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA09219 for ; Fri, 8 Jan 1999 14:09:27 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id RAA12080; Fri, 8 Jan 1999 17:10:19 -0500
Message-Id: <[email-masked]>
X-Sender: [email-masked] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
X-Priority: 1 (Highest)
Date: Fri, 08 Jan 1999 17:11:25 -0500
To: [email-masked]
From: Russ Housley
Subject: Ready For Last Call: draft-ietf-smime-ess-10.txt
Cc: [email-masked]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

Jeff:

This draft-ietf-smime-ess-10.txt is ready for IETF-wide Last Call.

I recommend a two week last call. It should complete the process at about
the same time as the CMS and X9.42 documents that were sent to you before
Christmas.

This is the final S/MIME document in this batch.

Russ

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA08932 for ietf-smime-bks; Fri, 8 Jan 1999 14:05:47 -0800 (PST)
Received: from thehub.knight-hub.com ([email-masked] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA08927 for ; Fri, 8 Jan 1999 14:05:46 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id RAA11843; Fri, 8 Jan 1999 17:06:40 -0500
Message-Id: <[email-masked]>
X-Sender: [email-masked] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
X-Priority: 1 (Highest)
Date: Fri, 08 Jan 1999 15:33:59 -0500
To: [email-masked]
From: Russ Housley
Subject: Ready For Last Call: draft-ietf-smime-msg-06.txt
Cc: [email-masked]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

Jeff:

This draft-ietf-smime-msg-06.txt is ready for IETF-wide Last Call.

I recommend a two week last call. It should complete the process at about
the same time as the CMS and X9.42 documents that were sent to you before
Christmas.

Russ

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA03602 for ietf-smime-bks; Fri, 8 Jan 1999 12:05:01 -0800 (PST)
Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA03597 for ; Fri, 8 Jan 1999 12:05:00 -0800 (PST)
Received: by dfssl.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id ; Fri, 8 Jan 1999 12:01:58 -0800
Message-ID: <2FBF98FC7852CF11912A0000000000010FF8A6D7@localhost>
From: "Jim Schaad (Exchange)"
To: "Russ Housley (E-mail)" , "Ietf-Smime (E-mail)"
Subject: Last Call Comments on CMS-10
Date: Fri, 8 Jan 1999 12:01:51 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

Russ,

I have a few comments on the lastest version of the CMS draft published

1. Section 2, Last paragraph, Sentence 4: I think that "However, signed
attributes within the signed-data content type and authenticated attributes
within the authenticated-data content type require DER encoding." should
read "However, signed attributes within the signed-data content type
andauthenicated a attributes within the authenticated-data content type are
the only places where DER encoding is required."

2. ASN Module Errors
"cms.asn", line 176 (CryptographicMessageSyntax): A0256W: 'DigestAlgorithm'
is referenced, but is not defined.
Need to change DigestAlgorithm to DigestAlgorithmIdentifier in
AuthenticatedData

3. The algorithm OIDs defined and used in section 12 are not included in the
ASN module.

4. Section 5, First pagagraph after the bullets. The text has not been
updated to reflect the SKI addition to the signer info object.

5. Same as above: "that uniquely identify the certificate containing the
public key" Should read "that uniquely identifies the certificate..."

6. Section 5.1: The last two paragraphs really belong as part of section
5.2 as they are discussing EncapsulatedContentInfo. This is especially true
given that it is refered to from places like section 7.

7. Section 5.1: Text on version needs to be expanded to deal with SKI.
Must be 3 if any SignerInfo version is 3.

8. Section 9. nit-pik -- authenticatedAttributes is misspelt in the ASN for
AuthenticatedData (but it is consistantly misspelt).

9. Section 10.2.6 -- I don't like the first sentence. How about "The
UserKeyingMaterial type gives a syntax for user keying material (UKM)."

10. Section 12.3.1, paragraph 3. I would like to change the first sentence
to "A CMS Implementation should support mixed key-encryption and
content-encryption algorithms."

11. Section 12.3.3 - Please insert the following paragraph in this section
" A CMS implementation should support mixed key-encryption and content-
encryption algorithms. For example, a 128-bit RC2 content-encryption
key may be wrapped with 168-bit Triple-DES key-encryption key.
Similarly, a 40-bit RC2 content-encryption key may be wrapped with
128-bit RC2 key-encryption key.
"
12. Ditto 11 for section 12.6

13. Security Considerations, pargraph 7 - Typo with wises for wishes

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA29951 for ietf-smime-bks; Fri, 8 Jan 1999 08:28:35 -0800 (PST)
Received: from thehub.knight-hub.com ([email-masked] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA29945 for ; Fri, 8 Jan 1999 08:28:33 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id LAA30357; Fri, 8 Jan 1999 11:29:26 -0500
Message-Id: <[email-masked]>
X-Sender: [email-masked] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
X-Priority: 1 (Highest)
Date: Fri, 08 Jan 1999 11:30:34 -0500
To: [email-masked]
From: Russ Housley
Subject: Ready For Last Call: draft-ietf-smime-cert-06.txt
Cc: [email-masked]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

Jeff:

This draft-ietf-smime-cert-06.txt is ready for IETF-wide Last Call.

I recommend a two week last call. It shouls complete the process at about
the same time as the CMS and X9.42 documents that were sent to you before
Christmas..

Russ

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA24562 for ietf-smime-bks; Fri, 8 Jan 1999 00:27:16 -0800 (PST)
Received: from krdl.org.sg (rodin.krdl.org.sg [137.132.252.27]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA24378; Fri, 8 Jan 1999 00:16:28 -0800 (PST)
Received: from mailhost.krdl.org.sg (mailbox.krdl.org.sg [137.132.247.30]) by krdl.org.sg (8.9.0/8.9.0) with ESMTP id QAA19629; Fri, 8 Jan 1999 16:20:41 +0800 (SGT)
Received: from colorado (colorado [137.132.249.218]) by mailhost.krdl.org.sg (8.9.0/8.9.0) with SMTP id QAA10492; Fri, 8 Jan 1999 16:14:52 +0800 (SGT)
Date: Fri, 8 Jan 1999 16:14:09 +0800 (SGT)
From: Jianying Zhou
X-Sender: jyzhou@colorado
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: ACM CCS'99 CFP
In-Reply-To:
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

I apology for sending a large attachment in an early message.

Sorry.

Jianying Zhou

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA16927 for ietf-smime-bks; Mon, 4 Jan 1999 12:43:40 -0800 (PST)
Received: from relay.hq.tis.com ([email-masked] [192.94.214.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA16923 for ; Mon, 4 Jan 1999 12:43:38 -0800 (PST)
Received: by relay.hq.tis.com; id PAA22906; Mon, 4 Jan 1999 15:51:40 -0500 (EST)
Received: from clipper.hq.tis.com(10.33.1.2) by relay.hq.tis.com via smap (4.1) id xma022878; Mon, 4 Jan 99 15:50:52 -0500
Received: from balenson.hq.tis.com (balenson.hq.tis.com [10.33.80.11]) by clipper.hq.tis.com (8.9.1/8.9.1) with SMTP id PAA14316; Mon, 4 Jan 1999 15:39:12 -0500 (EST)
Message-Id:
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Mon, 04 Jan 1999 15:40:19 -0500
To: [email-masked]
From: "David M. Balenson"
Subject: REMINDER: Jan 6th Early Bird Deadline for NDSS '99
Cc: [email-masked]
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=====================_915500419==_"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

--=====================_915500419==_
Content-Type: text/plain; charset="us-ascii"

--=====================_915500419==_
Content-Type: text/plain; charset="us-ascii"

S A V E $ 7 0 O F F R E G I S T R A T I O N F E E ! !
R E G I S T E R B Y J A N U A R Y 6 , 1 9 9 9

THE INTERNET SOCIETY'S
1999 NETWORK AND DISTRIBUTED SYSTEM SECURITY (NDSS) SYMPOSIUM
February 3-5, 1999
Catamaran Resort Hotel
San Diego, California
General Chair: Steve Welke, Trusted Computer Solutions
Program Chairs: Steve Kent, BBN Technologies
Gene Tsudik, USC/Information Sciences Institute

ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss99

KEYNOTE SPEAKER: Whitfield Diffie, Sun Microsystems. Co-author of
"Privacy on the Line: The Politics of Wiretapping and Encryption."

THIS YEAR'S TOPICS INCLUDE:
- Secure Password-Based Protocol for Downloading a Private Key
- A Real-World Analysis of Kerberos Password Security
- Secure Remote Access to an Internal Web Server
- Security and the User
- Experimenting with Shared Generation of RSA Keys
- Addressing the Problem of Undetected Signature Key Compromise
- Practical Approach to Anonymity in Large Scale Electronic Voting Schemes
- Securing the Internet's Exterior Routing Infrastructure
- Distributed Policy Management for Java 1.2
- Distributed Execution with Remote Audit
- An Algebra for Assessing Trust in Certification Chains
- A Network Security Research Agenda
- PGRIP: PNNI Global Routing Infrastructure Protection
- A Cryptographic Countermeasure Against Connection Depletion Attacks
- IPSec: Friend or Foe?

EXPANDED PRE-CONFERENCE TECHNICAL TUTORIALS:
- Principles of Network Security (Dr. Stephen T. Kent, BBN Technologies)
- Optical Network Security (Jeff Ingle and Dr. Eric Harder, NSA)
- Electronic Payment Systems (Dr. B. Clifford Neuman, USC/ISI)
- Windows NT Security (Dominique Brezinski, Secure Computing Corp.)
- Web Security and Beyond (Dr. B. Clifford Neuman, USC/ISI)
- JAVA Security (Dr. Gary McGraw, Reliable Software Technologies)
Full details and biographies at http://www.isoc.org/ndss99/technical.shtml

--=====================_915500419==_
Content-Type: text/plain; charset="us-ascii"

----------------------------------------------------------------------
David M. Balenson, Cryptographic Technologies Group
TIS Labs at Network Associates, Inc.
3060 Washington Road, Suite 100, Glenwood, MD 21738 USA
[email-masked]; 443-259-2358; fax 301-854-4731

--=====================_915500419==_--

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA08234 for ietf-smime-bks; Sun, 3 Jan 1999 20:42:56 -0800 (PST)
Received: from aum (ip08.proper.com [165.227.249.8]) by mail.proper.com (8.8.8/8.8.5) with SMTP id UAA07939; Sun, 3 Jan 1999 20:39:39 -0800 (PST)
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Sun, 03 Jan 1999 20:34:22 -0800
To: [email-masked], [email-masked]
From: Paul Hoffman / IMC
Subject: Re: Wassenaar Agreement
In-Reply-To:
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

>Have anybody/organization has ever evaluate the
>impact of the Wassenaar Arrangement in Dec 1998
>about the dual use regulation on the global PKI
>market and whether this will cause a new barrier
>to the export of strong cryptographic technology
>from other non-us countries.

I believe that neither the ietf-smime mailing list nor the ietf-pkix
mailing lists is an appropriate place to discuss this. There are plenty of
other discussion lists on which the Wassenaar Arrangement and its effects
are being debated.

--Paul Hoffman, Director
--Internet Mail Consortium

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA01659 for ietf-smime-bks; Sun, 3 Jan 1999 19:32:19 -0800 (PST)
Received: from zeus.planetworld.com (smtp.planetworld.com [38.234.12.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA01212; Sun, 3 Jan 1999 19:29:07 -0800 (PST)
Received: by smtp.planetworld.com with Internet Mail Service (5.5.2232.9) id ; Sun, 3 Jan 1999 21:31:27 -0600
Message-ID: <[email-masked]>
From: Bill Brice
To: [email-masked], "[email-masked]'"
Subject: RE: Impact of US Export Regulation changes on WG documents
Date: Sun, 3 Jan 1999 21:31:26 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

Not at all. There may be no impact. My posting is
simply in response to many debates I've seen fly by
on algorithm support. I'm merely suggesting that the
technologists see if this has any impact.
If there is none, then great.

-----Original Message-----
From: Paul Hoffman / IMC [mailto:[email-masked]]
Sent: Sunday, January 03, 1999 7:57 PM
To: [email-masked]; [email-masked]
Subject: Re: Impact of US Export Regulation changes on WG documents

At 07:46 PM 1/3/99 -0600, Bill Brice wrote:
>My purpose in bringing this to the attention of these
>lists it that many of the Work Group documents are in
>last call or near completion. The appropriate authors
>should consider whether the changes made by the BXA
>might impact these documents.

Could you be a bit more explicit? What do you mean by "impact"? I hope you
are not suggesting that we break backwards compatibility with S/MIME v2 by
substituting one weak algorithm for another.

--Paul Hoffman, Director
--Internet Mail Consortium

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA27191 for ietf-smime-bks; Sun, 3 Jan 1999 18:55:02 -0800 (PST)
Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA27162; Sun, 3 Jan 1999 18:51:37 -0800 (PST)
From: [email-masked]
Received: from hkmail.hkg.hp.com ([email-masked] [15.19.68.29]) by palrel3.hp.com (8.8.6 (PHNE_14041)/8.8.5tis) with ESMTP id SAA23205; Sun, 3 Jan 1999 18:52:14 -0800 (PST)
Received: from localhost (root@localhost) by hkmail.hkg.hp.com with SMTP (8.8.6 (PHNE_14041)/8.7.3 TIS 5.0 Openmail) id KAA13015; Mon, 4 Jan 1999 10:51:57 +0800 (HKG)
X-OpenMail-Hops: 1
Date: Mon, 4 Jan 1999 10:51:49 +0800
Message-Id:
Subject: Wassenaar Agreement
MIME-Version: 1.0
TO: [email-masked], [email-masked], [email-masked]
Content-Type: text/plain; charset=US-ASCII; name="Wassenaar"
Content-Disposition: inline; filename="Wassenaar"
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

Hello all,

Have anybody/organization has ever evaluate the
impact of the Wassenaar Arrangement in Dec 1998
about the dual use regulation on the global PKI
market and whether this will cause a new barrier
to the export of strong cryptographic technology
from other non-us countries.

In the past, non-US countries company like Ireland
Balimore can export strong crypto. Will it be
changed after the signing of the Wassenaar
Arrangement.

Best REegards,
Esmond TONG

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA26805 for ietf-smime-bks; Sun, 3 Jan 1999 18:06:40 -0800 (PST)
Received: from aum (ip08.proper.com [165.227.249.8]) by mail.proper.com (8.8.8/8.8.5) with SMTP id SAA26760; Sun, 3 Jan 1999 18:02:08 -0800 (PST)
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Sun, 03 Jan 1999 17:57:09 -0800
To: [email-masked], [email-masked]
From: Paul Hoffman / IMC
Subject: Re: Impact of US Export Regulation changes on WG documents
In-Reply-To: <[email-masked] m>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

At 07:46 PM 1/3/99 -0600, Bill Brice wrote:
>My purpose in bringing this to the attention of these
>lists it that many of the Work Group documents are in
>last call or near completion. The appropriate authors
>should consider whether the changes made by the BXA
>might impact these documents.

Could you be a bit more explicit? What do you mean by "impact"? I hope you
are not suggesting that we break backwards compatibility with S/MIME v2 by
substituting one weak algorithm for another.

--Paul Hoffman, Director
--Internet Mail Consortium

Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA26625 for ietf-smime-bks; Sun, 3 Jan 1999 17:49:24 -0800 (PST)
Received: from zeus.planetworld.com (smtp.planetworld.com [38.234.12.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA26566; Sun, 3 Jan 1999 17:44:20 -0800 (PST)
Received: by smtp.planetworld.com with Internet Mail Service (5.5.2232.9) id ; Sun, 3 Jan 1999 19:46:38 -0600
Message-ID: <[email-masked]>
From: Bill Brice
To: [email-masked], "[email-masked]'"
Subject: Impact of US Export Regulation changes on WG documents
Date: Sun, 3 Jan 1999 19:46:30 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:

PKIX and S/MIME lists:

On Thursday, December 31 the US Department of Commerce,
Bureau of Export Administration published it's awaited
revised regulations on the export of Encryption Items.

My purpose in bringing this to the attention of these
lists it that many of the Work Group documents are in
last call or near completion. The appropriate authors
should consider whether the changes made by the BXA
might impact these documents.

The most significant change is that the allowable key
lengths have been increased for export grade software.
Previously, symmetric confidentiality ciphers were limited
to 40-bits and asymmetric ciphers (such as RSA) used for
key exchange were limited to 512 bits.

The new regulations permit the following key lengths for
export:
Symmetric confidentiality algorithms RC2, RC4, RC5, DES
and CAST: 56-bits
Symmetric key exchange ciphers: 112 bits
Asymmetric key exchange ciphers: 1024 bits

This has the effect of permitting the export versions of
such products as Microsoft Internet Explorer (CryptoAPI)
and Netscape Communicator (PKCS#11) to, by default, use
56-bit DES and 1024-bit RSA.

For certificate authorities, this has the impact of permitting
browser based enrollment controls (Xenroll or KeyGen) to
default to 1024-bit RSA worldwide (except the 7 bad countries).

Between now and March 31, 1999 any manufacturer of encryption
software may upgrade their export versions to the new bit
levels by merely sending notice to the BXA. I'd like for
Microsoft and Netscape to comment as to how quickly they
expect to have crypto upgrades available for release.

The relevant BXA link for the complete text is:
http://www.bxa.doc.gov/Encryption/1231ERC.htm or
http://www.bxa.doc.gov/PDF/1231ERC.pdf

The relevant text covering mass-market software is quoted in
the postscript.

-Bill Brice, CEO
AlphaTrust Corp.

Postscript:
(iv) Mass-market encryption software that has already been
classified after a technical review and that has been released from EI
controls under the provisions of this paragraph (b)(1) will be
permitted for export and reexport under license exception TSU with
increases of 56-bits for the confidentiality algorithm, the same or
double the key length authorized for the confidentiality algorithm for
symmetric
algorithms for key exchange mechanisms and with key spaces of 512, 768
or up to and including 1024 bits for asymmetric algorithms for key
exchange without an additional technical review, provided that there is
no other change in the cryptographic functionality. Exporters must
notify BXA in writing of the increase in the key length for the
confidentiality algorithm, the asymmetric or symmetric key exchange
algorithms, and include the original authorization number issued by BXA
and the information identified in paragraphs (a)(2)(iii) through (v) of
Supplement No. 6 to part 742 of the EAR (if this information was
submitted previously, then only identify the modifications). BXA must
receive such notification by March 31, 1999.
(A) The notification should be sent to:
Office of Strategic Trade and Foreign Policy Controls, Bureau of
Export Administration, Department of Commerce, 14th Street and
Pennsylvania Ave., N.W., Room 2705, Washington, D.C. 20230, Attn:
Encryption Upgrade (B) A copy of the certification should be sent to:
Attn: ENC Encryption Request Coordinator, P.O. Box 246, Annapolis
Junction, MD 20701-0246

End Postscript.