Subject: ASN.1-SIZE floating
From: [email-masked]
To: [email-masked]
Date: Mon, 31 Aug 1998 08:59:33 +0100

--SAA21471.904553068/kryptonite.sge.net--

From: "Enzo Michelangeli" <[email-masked]>
To: <[email-masked]>
Subject: OPTION 2: RC2 Key Length Fixed
Date: Tue, 1 Sep 1998 08:13:19 +0800
Sender: [email-masked]

Date: Tue, 01 Sep 1998 01:37:18 +0100
From: Dr Stephen Henson <[email-masked]>
Organization: Dr S N Henson
To: "[email-masked]" <[email-masked]>
Subject: OPTION 1: RC2 Key Length X/8
Sender: [email-masked]

I propose this option not because its the best but because its what the
two versions I've tested use: viz Netscape Messenger and Microsoft
Outlook.

If you permit a larger key length then it may break an existing
implementation that assumes that the the keylength is X/8. It would
break mine for example but I can fix that. 

I can't comment on whether the above implementations assume X/8, can
anyone else? If no one knows then I can do some tests and post the
results back here.

As for this being more complicated to code and test I'd say that depends
on the implementation. Currently, for example, SSLeay would need some
modification to support option 2 with its envelope routines whereas
option 1 is already supported.

There is a standard that that sort of defines it. The standard I'm
referring to is PKCS#12 password based encryption. In this case the
keylength is specifically implied by the algorithm as X/8.

Steve.
-- 
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
PGP key: via homepage.

Date: Mon, 31 Aug 1998 16:28:20 -0700 (PDT)
From: Gene Tsudik <[email-masked]>
To: [email-masked]
Subject: ACM Comp. and Comm. Security: Reg-n Form and Call for Participation
Sender: [email-masked]

This is the Call for Participation for the  5th ACM Conference on 
Computer and Communications Security that will take place in San 
Francisco Nov 2-5.

Below please find the REGISTRATION form.
The official conference homepage is at: 

            http://www.bell-labs.com/user/reiter/ccs5/

It includes, among other things, the conference program, information
about invited talks, speakers and tutorials. 

------------------------- cut here ----------------------------------

Fifth ACM Conference on Computer and Communications Security

                   REGISTRATION FORM

          Name:_____________________________________________

   Affiliation:_____________________________________________

Postal Address:_____________________________________________

               _____________________________________________

               _____________________________________________

         Phone:_____________________________________________

           Fax:_____________________________________________

         Email:_____________________________________________

Note: Notification of receipt of registration form will be sent via email.
      Address information will be distributed to all attendees.

Please mark the appropriate registration categories.  Payment must be
included and must be either by check in U.S. dollars, drawn on a U.S.
bank and made payable to "ACM Conference on Computer and
Communications Security", or by credit card.  Dates are strictly
enforced by postmark.

Attendees who register for tutorials can attend any of the four
half-day tutorials.  However, to assist in planning, please indicate
which tutorials you are likely to attend.

 Morning sessions (choose one):
  ___  Cryptography: Theory and Applications (Dan Boneh)
  ___  Programming Languages and Security (Martin Abadi, George Necula)

 Afternoon sessions (choose one):
  ___  Authentication protocol verification and analysis (Jon Millen)
  ___  Emerging models in electronic commerce (Doug Tygar)

The following tutorial registration fees include admission to all
tutorials, and must be paid in full if any tutorial is attended.

 Advance tutorial registration (on or before October 1, 1998)
  ___  ................................................................$300.00
  ___  Full-time Student...............................................$100.00
 Late tutorial registration (after October 1, 1998)
  ___  ................................................................$395.00
  ___  Full-time Student...............................................$100.00

Conference registration includes admission to the regular conference
programs (but not the tutorials), conference proceedings, continental
breakfast, lunch, and reception/dinner.

 Advance conference registration (on or before October 1, 1998)
  ___  Member, ACM or ACM SIGACT (Member #__________, required)........$315.00
  ___  Non-Member......................................................$390.00
  ___  Full-time Student...............................................$100.00
 Late conference registration (after October 1, 1998)
  ___  Member, ACM or ACM SIGACT (Member #__________, required)........$375.00
  ___  Non-Member......................................................$465.00
  ___  Full-time Student...............................................$100.00

Do you have any special requirements?_________________________________________

Please indicate your method of payment by checking the appropriate box:

  [ ] Check in U.S. funds drawn on a U.S. bank (PLEASE ENCLOSE WITH THIS FORM)

  Credit card authorization:
  (Charges will appear on your statement as made by ACM.
   Note: your credit card number will be processed by the ACM.)

         Visa        MasterCard      American Express     Diners Club
         [ ]            [ ]                [ ]                [ ]

  Credit Card Number:_________________________________________________________

  Card Holder Name:______________________________Expiration Date:_____________

Mail registration to:                     Or Email this form (CREDIT CARD
        Li Gong                           REGISTRATIONS ONLY) to:
        Sun Microsystems                  [email-masked] with the subject
        MS UCUP02-102                     ACM CCS registration
        901 San Antonio Road
        Palo Alto, CA 94303-4900, USA

>>>>SORRY, NO REFUNDS.<<<<

Hotel Reservations - The Fairmont Hotel, San Francisco
======================================================
The legendary Fairmont Hotel in San Francisco is situated atop the
exclusive Nob Hill area, with a panoramic view of the City and San
Francisco Bay.  Nearby, cable cars stop to carry guests to Union
Square and the Financial District as well as nearby Chinatown,
Ghirardelli Square and Fisherman's Wharf.

Hotel reservations must be made under the group name "Association of
Computing Machinery/ACM CCS".  The special group rate is

Main Building:  $155 single and $175 double occupancy
Tower/Bay View: $185 single and $205 double occupancy

There is an additional 14% tax.  These rates are guaranteed for the
period of the conference only.  The cut-off date for reservations is
Thursday, October 8, 1998.  Reservations made after this date will be
accepted on a space available basis, but due to the busy season,
reservations should be made as early as possible.  Reservations must
be guaranteed by a credit card or it must be accompanied by an advance
deposit for the first night.  You may cancel your individual
reservations up to 24 hours prior to arrival, after which your deposit
becomes non-refundable.  Please be advised the check-in time is after
3:00 p.m.; check-out is 1:00 p.m.

For reservations and information, contact:

The Fairmont Hotel
950 Mason Street
San Francisco, CA 94108
Tel: +1 415-772-5000
     +1 800-527-4727

Transportation from the San Francisco International Airport to the
hotel can be via taxi, which takes about 30 minutes and costs about
$30, or via shuttle at a cost of around $12.  Shuttle information can
be found at the airport.
=============================================================================

To: [email-masked]
Subject: RC2 Keylength Strawpoll -- Correction
Date: Mon, 31 Aug 1998 15:38:39 -0700
From: Rescorla <[email-masked]>
Sender: [email-masked]

I forgot to fully explicate one of the options. Here's the revised
message. Sorry about the duplicate, folks.

-Ekr

We continue to have an RC2 keylength issue. Russ has
asked me to do a straw poll to resolve it.

To review, RC2 is a cipher which accepts a key of variable
length and which incorporates a keyspace reduction function
to control the effective keylength of the cipher. These
sizes don't have to be related, except of course that the
key length must be of greater size than the effective
number of bits. There has never been a written standard
clearly stating how long the key should be for a given
number of effective bits, although the RC2 RFC states
that a fixed length 64 bits (8 bytes) is common. 

This is clearly inappropriate in the S/MIME case, however,
since one of our choices is 128 effective bits. 

Why wasn't this an issue before?
All that is required is that the sender and receiver agree
on the length of the key. When using RSA (the only key exchange
algorithm in S/MIME v2) the PKCS-1 padding explicitly provides
the length of the wrapped key, so there is agreement.

Why is this an issue now?
The Key Agreement mechanism specified in draft-ietf-smime-x94-00
specifies two uses for RC2 keys. In neither case is the keylength
explicitly provided in the message. The first case is as a 
Key Encryption Key which is generated as the output of a SHA-1
digest. The second case is the familiar Message Encryption Key,
which is wrapped according to section 12. As a consequence, we
need to have a standard for how long the key will be so that
the sender and receiver can agree.

What's standard practice?
It seems that there isn't any. Due to the aforementioned
feature of RSA, implementors were free to choose any keylength
they wanted while remaining interoperable, and according to
Blake Ramsdell at the Chicago IETF, they have done pretty much
that.

What are our choices?
"OPTION 1: RC2 Key Length X/8"

We choose the actual keylength to be equal to the effective
keylength. I.e. 40 bit RC2 has a 5 byte key. 

Pros
(1) Slightly faster when wrapping an MEK for 40 bit RC2
since you don't need to wrap as many blocks worth of key.
(2) May be slightly more common.
Cons
(1) Less obviously secure.
(2) More complicated to code and test.

"OPTION 2: RC2 Key Length Fixed"
We choose the key length to be some fixed (sufficiently large)
size. Probably 16 bytes or 20 bytes. Both of these can be
produced with one SHA-1 operation, so they're small enough to
be equally fast with DH fixed.

Pros
(1) Simpler to code and test.
Cons
(1) Slightly slower key wrapping for 40 bit RC2

To vote, send an email to [email-masked] with one of
the following subject lines:

"OPTION 1: RC2 Key Length X/8"

"OPTION 2: RC2 Key Length Fixed"

Don't bother with a message body, I am just going to count the 
messages.  Discussion of the content of this message should reply to 
this message. 

-Ekr

[Eric Rescorla                                   [email-masked]]

To: [email-masked]
Subject: RC2 keylength strawpoll
Date: Mon, 31 Aug 1998 15:36:01 -0700
From: Rescorla <[email-masked]>
Sender: [email-masked]

We continue to have an RC2 keylength issue. Russ has
asked me to do a straw poll to resolve it.

To review, RC2 is a cipher which accepts a key of variable
length and which incorporates a keyspace reduction function
to control the effective keylength of the cipher. These
sizes don't have to be related, except of course that the
key length must be of greater size than the effective
number of bits. There has never been a written standard
clearly stating how long the key should be for a given
number of effective bits, although the RC2 RFC states
that a fixed length 64 bits (8 bytes) is common. 

This is clearly inappropriate in the S/MIME case, however,
since one of our choices is 128 effective bits. 

Why wasn't this an issue before?
All that is required is that the sender and receiver agree
on the length of the key. When using RSA (the only key exchange
algorithm in S/MIME v2) the PKCS-1 padding explicitly provides
the length of the wrapped key, so there is agreement.

Why is this an issue now?
The Key Agreement mechanism specified in draft-ietf-smime-x94-00
specifies two uses for RC2 keys. In neither case is the keylength
explicitly provided in the message. The first case is as a 
Key Encryption Key which is generated as the output of a SHA-1
digest. The second case is the familiar Message Encryption Key,
which is wrapped according to section 12. As a consequence, we
need to have a standard for how long the key will be so that
the sender and receiver can agree.

What's standard practice?
It seems that there isn't any. Due to the aforementioned
feature of RSA, implementors were free to choose any keylength
they wanted while remaining interoperable, and according to
Blake Ramsdell at the Chicago IETF, they have done pretty much
that.

What are our choices?
"OPTION 1: RC2 Key Length X/8"

We choose the actual keylength to be equal to the effective
keylength. I.e. 40 bit RC2 has a 5 byte key. 

Pros
(1) Slightly faster when wrapping an MEK for 40 bit RC2
since you don't need to wrap as many blocks worth of key.
(2) May be slightly more common.
Cons
(1) Less obviously secure.
(2) More complicated to code and test.

"OPTION 2: RC2 Key Length Fixed"

Pros
(1) Simpler to code and test.
Cons
(1) Slightly slower key wrapping for 40 bit RC2

To vote, send an email to [email-masked] with one of
the following subject lines:

"OPTION 1: RC2 Key Length X/8"

"OPTION 2: RC2 Key Length Fixed"

Don't bother with a message body, I am just going to count the 
messages.  Discussion of the content of this message should reply to 
this message. 

-Ekr

[Eric Rescorla                                   [email-masked]]

Date: Mon, 31 Aug 1998 10:09:44 -0400
To: Koujirou Wakabayashi <[email-masked]>, [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: 42nd meeting
Sender: [email-masked]

K.W.

I am writing the minutes for the meeting.  As soon as I have finished them
and the presenters have approved what I have written, then I will send them
to the list.  This should be accomplished this week.

================================
John Pawling, [email-masked]                             
J.G. Van Dyke & Associates, Inc.   
www.jgvandyke.com         
================================

At 05:29 PM 8/31/98 +0900, Koujirou Wakabayashi wrote:
>Hi All!
>
>Unfortunately, I could not take part in the meeting at CHICAGo.So, Could
you anybody tell me the summary of the meeting?
>
>K.W.
>
>Keio Univ  
>

To: [email-masked]
Subject: 42nd meeting
Date: Mon, 31 Aug 1998 17:29:48 +0900
From: Koujirou Wakabayashi <[email-masked]>
Sender: [email-masked]

Hi All!

Unfortunately, I could not take part in the meeting at CHICAGo.So, Could you anybody tell me the summary of the meeting?

K.W.

Keio Univ  

Date: Mon, 31 Aug 1998 17:12:19 +0900 (JST)
From: "=?ISO-2022-JP?B?GyRCPGNOUxsoQg==?= =?ISO-2022-JP?B?GyRCOSc8IU86GyhC?=" <[email-masked]>
To: [email-masked]
Subject: 42nd meeting
Sender: [email-masked]

Hi all.

Unfortunately, I could not take part in the meeting at CHICAGO. So Could you anybady tell me the summary of SMIME WG at CHICAGO?

fly

From: [email-masked]
X400-Received: by mta BMX03 in /PRMD=MIL/ADMD=400NET/C=SE; relayed; 31 Aug 1998 09:59:42 +0200
X400-Received: by mta TFX01 in /PRMD=MIL/ADMD=400NET/C=SE; relayed; 31 Aug 1998 10:01:06 +0200
X400-Received: by mta FMX01N in /PRMD=MIL/ADMD=400NET/C=SE; relayed; 31 Aug 1998 09:59:33 +0200
To: [email-masked]
Subject: ASN.1-SIZE floating
X400-MTS-Identifier: [/PRMD=MIL/ADMD=400NET/C=SE;ISOCOR-3575cc50-fmx01]
Date: Mon, 31 Aug 1998 08:59:33 +0100
Importance: normal
Autoforwarded: false
Sender: [email-masked]

Comments on draft-ietf-smime-ess-07.txt

Clause 2.9
Using the SIZE constraints (1..MAX), where the implementor can chose MAX will course interoperability problems. Nor only due to possible loss of attributes, but to the fact that an implementation design with a lower MAX than received, should reject the message as a protocol violation. 
We shall assign a fixed number to MAX. 
4 is a reasonable value, since I by this has to propose a figure.

Appendix B (used in 3.2 )
The reference to [MTSABS]/X.411 ought to be changed. In those days it was not ITU, it was CCITT (International Telegraph and Telephone Consultative Committee). Secondly all references to the 1988 publication are deprecated due to the amount of corrigenda issued to that publication. Even if there are no corrigendum relevant to the security label ASN.1, it's better to refer to the 1992 publication (still CCITT) which has the same technical content but has the corrigenda incorporated.

Date: Mon, 31 Aug 1998 00:36:08 +0100
From: Dr Stephen Henson <[email-masked]>
Organization: Dr S N Henson
To: "[email-masked]" <[email-masked]>
Subject: Re: Comments on CMS-06
Sender: [email-masked]

I think there are several issues here. Perhaps some are sufficiently
obvious that they don't need mentioning.

A signature can be cryptographically valid but not of much value because
the signing certificate has been revoked or there is some other path
validation error as has been pointed out.

The whole area become muddied when the message being verified is not
recent: it has either been delayed or has been previously stored. It is
possible that a message was valid when it was sent but is no longer
valid due to certificate revocation or expiry.

An example of this would be a certificate that has been revoked due to
private key compromise. A bogus signed message could be built containing
a signingTime before the certificate was revoked.

Unless some additional timestamp corroboration is available (e.g.
countersignature from a timestamping authority) it may be necessary to
regard every message ever signed by such a revoked certificate as
invalid. Messages signed in the past may well not be invalid but they
cannot be demonstrated as such.

Even with a trusted timestamp, a CA may allow a user to specify a time
when they believe the private key was compromised that is in the past:
how far in the past may vary from one CA to another. The upshot of this
is that a signed message may only be deemed to be of value when a
"reasonable time" has passed after its initial issue. What constitutes a
"reasonable time" is anyones guess...

There are of course other revocation reasons (such as loss of private
key) that do not affect previously signed messages.

Steve.
-- 
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
PGP key: via homepage.

From: "Darren Harter" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Comments on CMS-06
Date: Sun, 30 Aug 1998 13:08:41 PDT
Sender: [email-masked]

I agree with Paul - partly.  If you follow Paul's logic, he is correct 
to say that if certs are ignored the later signature validation test 
could be ambiguous.  However, SignerInfo includes an indication of the 
cert that should be used for the validation process using its issuer and 
serial number.  So Denis is correct to say that the message signature 
should only be valid until the certificate is revoked.

I believe that if CMS doesn't contain wording for path validation, then 
it should.

Darren

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

Date: Sat, 29 Aug 1998 17:13:33 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Comments on CMS-06
Sender: [email-masked]

Denis brought this up in the IETF meeting last week, and said no one had
commented on it. So I've re-read his message and my comment is that this is
a non-issue.

At 03:43 PM 7/15/98 -0700, Denis Pinkas wrote:
>On page 10, 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”. This is not sufficient in order to give
>the same and relaible result between two different implementations. 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 can be different.

You appear to be confusing signature validation with certificate
validation. A signature can be perfectly valid even if a certificate that
contains the public key used in that signature is revoked. Signature
validation as described in CMS doesn't involve following cert chains or
checking revocation, nor should it.

For a concrete example of this, imagine that I get a cert on my public key
from CA(x) with an expiration date of two years. After a year, CA(x) asks
for more money, and I refuse. In retribution, they revoke my certificate. I
take the same public key to CA(y), who signs it. A message that was signed
with my private key before the revocation is checked after the revocation
time. No certs are included in the message, but the recipient has cached
previous certs of mine, as specified in S/MIME. Depending on the
certificates the recipient uses, this will come back as "valid signature
and non-revoked cert", "valid signature but revoked cert" or possibly
"valid signature and mixed signals on cert status due to multiple certs
with different revocation status". But, in each case, the signature is
still valid.

Thus, I see no reason to change CMS in the ways you describe.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Sat, 29 Aug 1998 14:31:37 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Proposed new attribute for CMS: AdditionalRevInfo
Sender: [email-masked]

Greetings. Those of you at the IETF meeting this week may remember my
two-minute blurt near the end of the meeting about a new attribute I am
proposing to the CMS draft. In discussions after the meeting, I've gotten
some clarity, and the following is my proposal.

Note that we're waiting for the next rev of the draft for the next few
weeks anyway while Russ works on the Diffie-Hellman patent hell. If we
agree on this proposal before then, the section can go in before the WG
last call on CMS.

11.6 Additional Revocation Information

The AdditionalRevInfo attribute carries revocation status information from
the message creator to the recipient. This attribute augments the crls
field of the SignedData type. The purpose of this attribute is to let the
message creator include non-CRL revocation status information in a message
in case the recipient of the message cannot (or does not want to) get the
status information when validating the signature, such as if the recipient
is not online and no usable CRLs were included in the SignedData.

The following object identifier identifies the AdditionalRevInfo attribute:

   id-addlrevinfo OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) aa(2) 12 }

AdditionalRevInfo attributes have ASN.1 type AdditionalRevInfo:

   AdditionalRevInfo ::= SET OF AdditionalRevInfos

   AdditionalRevInfos ::= SEQUENCE {
      AddlRevType    OBJECT IDENTIFIER,
      AddlRevValue   OCTET STRING }

Currently, the only type of additional revocation information defined is an
OCSP response message [OCSP]. Its object identifier is:

   id-ocsp-resp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
      dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-ad(48)
      id-ad-ocsp(1) }

As other revocation information systems are designed, they may be used
in the AdditionalRevInfo attribute.

[OCSP] Housley, R. et. al., Internet X.509 Public Key Infrastructure
Certificate and CRL Profile, draft-ietf-pkix-ipki-part1.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Mon, 24 Aug 1998 19:02:19 -0400
To: "Robert E. Booker" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: EntityIdentifier Definition
Cc: <[email-masked]>
Sender: [email-masked]

You are correct.  EntityIdentifier is no longer defined in CMS...

Russ

At 05:31 PM 8/21/98 -0400, Robert E. Booker wrote:
>Enhanced Security Services for S/MIME I-D rev. 7 identifies an attribute
>type of EntityIdentifier which is "imported from [CMS]" and defines the
>syntax of MLData mailListIdentifier.  I cannot locate the definition within
>[CMS] rev. 6.  Perhaps I've missed it but I've been through both drafts
>several times.  Any help will be appreciated.
>
>Warmest Regards...
>
>...Robert
>
>============================================================================
>===
>
>Robert E. Booker                      Voice:	+1 612 415-3123
>Managing Security Consultant            Fax:	+1 612 415-3830
>Control Data Systems, Inc.
>4201 Lexington Ave. North            E-mail:	mailto:[email-masked]
>Arden Hills, MN  55126
>UNITED STATES OF AMERICA
> 

Date: Mon, 24 Aug 1998 08:23:18 -0400
To: "Robert E. Booker" <[email-masked]>, <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: EntityIdentifier Definition
Sender: [email-masked]

Robert,

You are correct.  EntityIdentifier used to be defined in CMS but was deleted
when the RecipientInfo syntax was changed.  I believe that the ESS ASN.1
module should directly include EntityIdentifier as follows:

EntityIdentifier ::= CHOICE {
  issuerAndSerialNumber IssuerAndSerialNumber,
  subjectKeyIdentifier SubjectKeyIdentifier }   
        
The ESS ASN.1 module should also be changed so that it no longer imports
EntityIdentifier from CMS.  Instead, it should import IssuerAndSerialNumber
from CMS.

================================
John Pawling, [email-masked]                             
J.G. Van Dyke & Associates, Inc.   
www.jgvandyke.com         
================================

At 05:31 PM 8/21/98 -0400, Robert E. Booker wrote:
>Enhanced Security Services for S/MIME I-D rev. 7 identifies an attribute
>type of EntityIdentifier which is "imported from [CMS]" and defines the
>syntax of MLData mailListIdentifier.  I cannot locate the definition within
>[CMS] rev. 6.  Perhaps I've missed it but I've been through both drafts
>several times.  Any help will be appreciated.
>
>Warmest Regards...
>
>...Robert
>
>============================================================================
>===
>
>Robert E. Booker                      Voice:	+1 612 415-3123
>Managing Security Consultant            Fax:	+1 612 415-3830
>Control Data Systems, Inc.
>4201 Lexington Ave. North            E-mail:	mailto:[email-masked]
>Arden Hills, MN  55126
>UNITED STATES OF AMERICA
>
>

From: "Robert E. Booker" <[email-masked]>
To: <[email-masked]>
Subject: EntityIdentifier Definition
Date: Fri, 21 Aug 1998 17:31:40 -0400
Importance: Normal
Sender: [email-masked]

Enhanced Security Services for S/MIME I-D rev. 7 identifies an attribute
type of EntityIdentifier which is "imported from [CMS]" and defines the
syntax of MLData mailListIdentifier.  I cannot locate the definition within
[CMS] rev. 6.  Perhaps I've missed it but I've been through both drafts
several times.  Any help will be appreciated.

Warmest Regards...

...Robert

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

Robert E. Booker                      Voice:	+1 612 415-3123
Managing Security Consultant            Fax:	+1 612 415-3830
Control Data Systems, Inc.
4201 Lexington Ave. North            E-mail:	mailto:[email-masked]
Arden Hills, MN  55126
UNITED STATES OF AMERICA

Date: Wed, 19 Aug 1998 18:32:25 +0100
From: Dr Stephen Henson <[email-masked]>
Organization: Dr S N Henson
To: "[email-masked]" <[email-masked]>
Subject: Certificate distribution specification suggestions.
Sender: [email-masked]

My appologies if this has been mentioned already. I lost rather a lot of
mail from this list recently.

While looking through the certificate distribution specification
recently it occurred to me that it could, with minor extensions, be used
as a standard to allow email clients import or export their S/MIME
certificates and symmetric capabilities. Some clients use a
"certificates only" PKCS#7 signed data structure for this purpose
already but this does not include symmetric capabilities.

The changes required are:

1. More than one SignerInfo structure permitted: one for each user
represented.
2. The messageDigest signed attribute is ignored. This is only given a
default value anyway and by allowing any value it is possible to just
cut the PKCS#7 structure from an S/MIME signed message. The value is
irrelevant: its the digital signature on the signed attributes that is
important.

To use this format for export, a client would gather together the
valid SignerInfo structures for each user, package them in a PKCS#7
structure and add the necessary certificates (removing duplicates).

For import, a client would check the signature on the signed attributes
of each SignerInfo structure then add the valid capabilities to its
lists along with the necessary certificates.

Steve.
-- 
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
PGP key: via homepage.

Date: Wed, 19 Aug 1998 18:20:20 +0100
From: Dr Stephen Henson <[email-masked]>
Organization: Dr S N Henson
To: "[email-masked]" <[email-masked]>
Subject: 40 bit RC2, X9.42 issue resolved?
Sender: [email-masked]

My appologies if this has been cleared up. I lost rather a lot of mail
from this list recently.

There was an issue involving the precise parameters used by RC2-XX in
S/MIME in particular wrt DH. I said at the time that an X bit RC2
algorithm used in S/MIME used a keylength of X/8 and an X for the
effective number of bits and that DH should follow this for
compatability with the key exchange methods.

Did anyone ever confirm this? Speaking personally I couldn't find any
documentation confirming it *but* it just happens to be "what works"
with current implementations.

Steve.
-- 
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
PGP key: via homepage.

Date: Wed, 19 Aug 1998 10:18:52 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: S/MIME WG Meeting Agenda
Cc: [email-masked], [email-masked]
Sender: [email-masked]

The S/MIME WG will meet on Wednesday at 9:00 AM.  Attached is our agenda.

Russ

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

S/MIME Mail Security WG Agenda

0900	Introductions			Russ Housley
0905	CMS Draft Discussion		Russ Housley
0925	X9.42 Draft Discussion		Russ Housley
0935	MSG Draft Discussion		Blake Ramsdell
0955	CERT Draft Discussion		Blake Ramsdell
1015	ESS Draft Discussion		Paul Hoffman
1025	CERTDIST Draft Discussion 	Jim Schaad
1045	SIGATTR Draft Discussion 	Jim Schaad
1105	DOMSEC Draft Discussion 	Bill Ottaway
1125	Wrap up			Russ Housley
1130	Adjourn

Date: Fri, 14 Aug 1998 15:18:56 -0400
To: "Darren Harter" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Ambiguity of DER encoding of UTCTime
Cc: <[email-masked]>
Sender: [email-masked]

Darren:

You are correct that DER is no completely specified for UTCTime.  PKIX Part
1 completes the specification to ensure that all UTCTime encodings are
"distinguished."

I will add the text from PKIX Part 1 to CMS where UTCTime is used.

Russ

At 06:56 PM 8/13/98 +0000, Darren Harter wrote:
>Appologies in advance for being slightly off topic for this list, but I
>believe this topic is of interest to all involved with digital signatures,
>if not explicitly for S/MIME.
>
>X.208 and X.680 specify that UTC time may carry precision to either minutes
>or seconds.  This means that mid-day on the 1 September this year (ignoring
>locales) would be encoded as either 9809011200Z with minute precision or
>980901120000Z with second precision.
>
>One second after being encoded as either 9809011200Z or 980901120001Z.
>
>X.209 and X.690 do not alter the definition of UTCTime in specifiying DER,
>and DER is therefore not distinguished!  This is a reasonably well known
>problem and has resulted in a specific clauses in many specs (including
>PKIX-1) stating whether second or minute precision should be used.
>
>I have two questions:
>
>1)    Within S/MIME we inherit the rules of PKIX-1 for Certificates, CRLs
>etc. which clearly states that second precision is required.  Do/Should we
>have a statement in the S/MIME specs that reiterate this position?
>
>2)    Has this issue been resolved in the latest ASN.1 specs, or in a
>technical corrigenda that I may have missed? If so does anybody have a
>reference for it?
>
>Regards,
>
>Darren Harter
>CASM Programme Office
>CESG
>[email-masked]
>[email-masked],uk
>[email-masked]
>
> 

Date: Fri, 14 Aug 1998 13:58:03 -0400
To: Francois Rousseau <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: New version of CMS available
Cc: [email-masked]
Sender: [email-masked]

These all look fine to me.

Russ

At 04:07 PM 8/12/98 -0400, Francois Rousseau wrote:
>Russ:
>
>>>Sec 6, Sec 6.2 and Sec 6.4 should indicate if the different key management
>>>techniques can be used in combination for the various recipients and/or a
>>>single recipient of an encrypted content. Reading Sec 6, it does not seem
>>>to preclude either approach.
>>
>>It is possible for there to be three recipients, each with a different key
>>managament technique.  What needs to change to make this clear?
>
>I would suggest the following changes to clarify this:
>
>The last sentence of the first paragraph of Sec 6 should read:
>
>"Any type of content can be enveloped for an arbitrary number of recipients
>using any of the three key management techniques for each recipient"
>
>Add the following sentence after the second sentence in Sec 6.2:
>
>"Any of the three key management techniques can be used for each recipient
>of the same encrypted content"
>
>Add the following sentence at the end of Sec 6.4:
>
>"Any of the three key management techniques can be used for each recipient
>of the same encrypted content"
>
>
>Francois Rousseau
> 

Reply-To: "Darren Harter" <[email-masked]>
From: "Darren Harter" <[email-masked]>
To: "Bancroft Scott" <[email-masked]>, "Darren Harter" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Ambiguity of DER encoding of UTCTime
Date: Thu, 13 Aug 1998 22:22:28 -0000
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0017_01BDC708.DB5098C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

-----Original Message-----
From: Bancroft Scott <[email-masked]>
To: Darren Harter <[email-masked]>
Cc: [email-masked] <[email-masked]>
Date: Thursday, August 13, 1998 07:04
Subject: Re: Ambiguity of DER encoding of UTCTime

>A technical corrigendum to X.690 that addresses this matter was issued two
>or three years ago.  The 1997 version of X.690 incorporates it:
>
>11.8    UTCTime
>
>11.8.1  The encoding shall terminate with "Z", as described in the ITU-T
X.680 |
>        ISO/IEC 8824-1 clause on UTCTime.
>
>11.8.2  The seconds element shall always be present.
>
>11.8.3  Midnight (GMT) shall be represented in the form:
>
>            "YYMMDD000000Z"
>
>        where "YYMMDD" represents the day following the midnight in
question.
>
>11.8.4  Examples of valid representations
>
>            "920521000000Z"
>
>            "920622123421Z"
>
>            "920722132100Z"
>
>11.8.5  Examples of invalid representations
>
>            "920520240000Z"         (midnight represented incorrectly)
>
>            "9207221321Z"           (seconds of 00 omitted)
>
>--------------------------------------------------------------------------
>Bancroft Scott                                Toll Free    :1-888-OSS-ASN1
>Open Systems Solutions, Inc.                  International:1-609-987-9073
>[email-masked]                                  Tech Support :1-732-249-5107
>http://www.oss.com                            Fax          :1-732-249-4636
>
>

Bancroft,

I presumed the matter would have been addressed by the standards community -
thanks for the confirmation.

Darren

------=_NextPart_000_0017_01BDC708.DB5098C0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0017_01BDC708.DB5098C0--

Date: Thu, 13 Aug 1998 14:48:52 -0400 (EDT)
From: Bancroft Scott <[email-masked]>
Reply-To: Bancroft Scott <[email-masked]>
To: Darren Harter <[email-masked]>
Cc: [email-masked]
Subject: Re: Ambiguity of DER encoding of UTCTime
Sender: [email-masked]

On Thu, 13 Aug 1998, Darren Harter wrote:

> Appologies in advance for being slightly off topic for this list, but I
> believe this topic is of interest to all involved with digital signatures,
> if not explicitly for S/MIME.
> 
> X.208 and X.680 specify that UTC time may carry precision to either minutes
> or seconds.  This means that mid-day on the 1 September this year (ignoring
> locales) would be encoded as either 9809011200Z with minute precision or
> 980901120000Z with second precision.
> 
> One second after being encoded as either 9809011200Z or 980901120001Z.
> 
> X.209 and X.690 do not alter the definition of UTCTime in specifiying DER,
> and DER is therefore not distinguished!  This is a reasonably well known
> problem and has resulted in a specific clauses in many specs (including
> PKIX-1) stating whether second or minute precision should be used.
> 
> I have two questions:
> 
> 1)    Within S/MIME we inherit the rules of PKIX-1 for Certificates, CRLs
> etc. which clearly states that second precision is required.  Do/Should we
> have a statement in the S/MIME specs that reiterate this position?
> 
> 2)    Has this issue been resolved in the latest ASN.1 specs, or in a
> technical corrigenda that I may have missed? If so does anybody have a
> reference for it?

A technical corrigendum to X.690 that addresses this matter was issued two
or three years ago.  The 1997 version of X.690 incorporates it:

11.8    UTCTime

11.8.1  The encoding shall terminate with "Z", as described in the ITU-T X.680 | 
        ISO/IEC 8824-1 clause on UTCTime.

11.8.2  The seconds element shall always be present.

11.8.3  Midnight (GMT) shall be represented in the form:

            "YYMMDD000000Z"

        where "YYMMDD" represents the day following the midnight in question.

11.8.4  Examples of valid representations

            "920521000000Z"

            "920622123421Z"

            "920722132100Z"

11.8.5  Examples of invalid representations

            "920520240000Z"         (midnight represented incorrectly)

            "9207221321Z"           (seconds of 00 omitted)

--------------------------------------------------------------------------
Bancroft Scott                                Toll Free    :1-888-OSS-ASN1
Open Systems Solutions, Inc.                  International:1-609-987-9073
[email-masked]                                  Tech Support :1-732-249-5107
http://www.oss.com                            Fax          :1-732-249-4636

Reply-To: "Darren Harter" <[email-masked]>
From: "Darren Harter" <[email-masked]>
To: <[email-masked]>
Subject: Ambiguity of DER encoding of UTCTime
Date: Thu, 13 Aug 1998 18:56:50 -0000
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0014_01BDC6EC.21514E40
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Appologies in advance for being slightly off topic for this list, but I
believe this topic is of interest to all involved with digital signatures,
if not explicitly for S/MIME.

X.208 and X.680 specify that UTC time may carry precision to either minutes
or seconds.  This means that mid-day on the 1 September this year (ignoring
locales) would be encoded as either 9809011200Z with minute precision or
980901120000Z with second precision.

One second after being encoded as either 9809011200Z or 980901120001Z.

X.209 and X.690 do not alter the definition of UTCTime in specifiying DER,
and DER is therefore not distinguished!  This is a reasonably well known
problem and has resulted in a specific clauses in many specs (including
PKIX-1) stating whether second or minute precision should be used.

I have two questions:

1)    Within S/MIME we inherit the rules of PKIX-1 for Certificates, CRLs
etc. which clearly states that second precision is required.  Do/Should we
have a statement in the S/MIME specs that reiterate this position?

2)    Has this issue been resolved in the latest ASN.1 specs, or in a
technical corrigenda that I may have missed? If so does anybody have a
reference for it?

Regards,

Darren Harter
CASM Programme Office
CESG
[email-masked]
[email-masked],uk
[email-masked]

------=_NextPart_000_0014_01BDC6EC.21514E40
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0014_01BDC6EC.21514E40--

From: [email-masked]
To: [email-masked]
Date: Thu, 13 Aug 98 05:10:01 -0400
Subject: Aggressive Inline and your Teenage Market!
Sender: [email-masked]

Hi!  -  Incase you haven't already found us - I wanted to invite you to check out

http://www.XtremeCentral.com

a new Internet "Neighborhood Hangout" for hip young people.

We got  http://www.hotrails.com  for you bladers,   http://www.ripping.com  for you boarders, 

And a whole bunch of other stuff to check out - like  http://www.sk8chat.com   the coolest!

So If you're a kid - lookin' to chill - Awesome!

Or if you're a  RETAILER - trying to find the kids . . . .

Either way - Xtreme Central just might be the right place!

Catch ya there  . . . Slider

Date: Wed, 12 Aug 1998 16:07:05 -0400
To: Russ Housley <[email-masked]>
From: Francois Rousseau <[email-masked]>
Subject: Re: New version of CMS available
Cc: [email-masked]
Sender: [email-masked]

Russ:

>>Sec 6, Sec 6.2 and Sec 6.4 should indicate if the different key management
>>techniques can be used in combination for the various recipients and/or a
>>single recipient of an encrypted content. Reading Sec 6, it does not seem
>>to preclude either approach.
>
>It is possible for there to be three recipients, each with a different key
>managament technique.  What needs to change to make this clear?

I would suggest the following changes to clarify this:

The last sentence of the first paragraph of Sec 6 should read:

"Any type of content can be enveloped for an arbitrary number of recipients
using any of the three key management techniques for each recipient"

Add the following sentence after the second sentence in Sec 6.2:

"Any of the three key management techniques can be used for each recipient
of the same encrypted content"

Add the following sentence at the end of Sec 6.4:

"Any of the three key management techniques can be used for each recipient
of the same encrypted content"

Francois Rousseau

To: [email-masked]
Cc: [email-masked]
Subject: Re: SignatureAlgorithmIdentifiers
From: EKR <[email-masked]>
Date: 12 Aug 1998 12:00:51 -0700
Lines: 46
Sender: [email-masked]

"Anil R. Gangolli" <[email-masked]> writes:

> Sorry to drag this out again, I've had my head down coding.
> Was there a resolution on the signature algorithm identifier
> issue for dsa-with-sha1?
> 
> I think we should stick with a compatible oid representation
> for the RSA-based signatures, but don't care either
> way on the dsa-with-sha1 representation.
> 
> I wanted to make one comment:
> 
> EKR had posted a note regarding a digest subsitution 
> attack based on the fact that DSA signatures do not include 
> the digest OID in them, whereas PKCS-1 format
> RSA signatures do, and are not susceptible.
> 
> Using the combined OID dsa-with-sha1 does not
> address this problem for DSA,
> since the combined oid is still not under the 
> "stronger" portion of the signature (raw DSA).
> [That is, if there is any digest that is
> permissible to be used with DSA that is at
> some point compromised to the extent Eric mentions, 
> then the message, digest value, and the combined oid can
> still be substituted. This is another minor botch in the
> DSS design: it is DSA applied to the pure digest value.]
> 
> Putting the oids in the authenticated attributes field
> wouldn't help either since it is only digested.
Yes, that is correct. The CMS spec must say that
DSS must be used with SHA-1 only. This can only
be enforced by specsmanship, not by OIDs.

However, once we've made that decision, as a matter of 
form, one shouldd use dsa-with-sha-1 as the oid since
to do otherwise suggests that digests are subsitutible
with DSA when in fact they are not. That was the 
point I was trying to make.

-Ekr

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

Date: Wed, 12 Aug 1998 11:19:34 -0700
From: "Anil R. Gangolli" <[email-masked]>
Reply-To: [email-masked]
Organization: Structured Arts Computing Corporation
To: [email-masked]
Subject: Re: SignatureAlgorithmIdentifiers
Sender: [email-masked]

Sorry to drag this out again, I've had my head down coding.
Was there a resolution on the signature algorithm identifier
issue for dsa-with-sha1?

I think we should stick with a compatible oid representation
for the RSA-based signatures, but don't care either
way on the dsa-with-sha1 representation.

I wanted to make one comment:

EKR had posted a note regarding a digest subsitution 
attack based on the fact that DSA signatures do not include 
the digest OID in them, whereas PKCS-1 format
RSA signatures do, and are not susceptible.

Using the combined OID dsa-with-sha1 does not
address this problem for DSA,
since the combined oid is still not under the 
"stronger" portion of the signature (raw DSA).
[That is, if there is any digest that is
permissible to be used with DSA that is at
some point compromised to the extent Eric mentions, 
then the message, digest value, and the combined oid can
still be substituted. This is another minor botch in the
DSS design: it is DSA applied to the pure digest value.]

Putting the oids in the authenticated attributes field
wouldn't help either since it is only digested.

--a.

-- 
Anil R. Gangolli
Structured Arts Computing Corporation
mailto:[email-masked]
http://www.structuredarts.com

Date: Tue, 11 Aug 1998 21:31:41 -0400
To: Francois Rousseau <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: New version of CMS available
Cc: [email-masked]
Sender: [email-masked]

Francois:

Please excuse the deplay in responding to your comments.

>Sec 6, Sec 6.2 and Sec 6.4 should indicate if the different key management
>techniques can be used in combination for the various recipients and/or a
>single recipient of an encrypted content. Reading Sec 6, it does not seem
>to preclude either approach.

It is possible for there to be three recipients, each with a different key
managament technique.  What needs to change to make this clear?

>Sec 6.1, both the OriginatorInfo "certs" field and the SignedData
>"certificates" field from Sec 5.1 are defined as a "CertificateSet" type,
>which is defined at Sec 10.2.3 as a set of "CertificateChoices" type
>allowing PKCS #6 extended certificates, X.509 certificates and X.509
>attribute certificates. Although attribute certificates can be present in
>the "certificates" field if the value of the SignedData "version" field is
>set to 3, attribute certificates are not mentioned in the definition of the
>OriginatorInfo "certs" field at Sec 6.1. Does this mean that the
>"EnvelopedData" and the "AuthenticatedData" content types can NOT contain
>attribute certificates in their OriginatorInfo "certs" field?

No.  In the OriginatorInfo discussion, I will add: "certs may also contain
attribute certificates associated with the originator. "

>Sec 6.1, under the definition of the "contentEncryptionAlgorithm" field, I
>suggest that the last sentence should read "The same algorithm and
>content-encryption key are used for all recipients".

Agree.

>Sec 10.2.1 defines the "CertificateRevocationLists" type that appears under
>the "crls" field of the "SignedData", the "EnvelopedData" and the
>"AuthenticatedData" content types, as a set of "CertificateList", which the
>definition is imported from X.509. In addition to the Certificate
>Revocation List (CRL) attribute type, which is mentioned throughout the CMS
>document, three other attribute types using the syntax of CertificateList
>are also defined in X.509 (i.e. Authority Revocation List (ARL), Delta
>Revocation List and Attribute Certificate Revocation List), however they
>are not mentioned in CMS. Are these other attribute types not also allowed
>in the "crls" field of CMS? Note that PKIX Part 1 currently only mentions
>the CRL and Delta CRL attribute types. I suggest that an enlarged
>definition of CRL be added at Sec 10.2.1 to cover all types.

I will add: "The CertificateList may contain a CRL, an Authority Revocation
List
(ARL), a Delta Revocation List, or an Attribute Certificate Revocation List. 
All of these lists share a common syntax." 

Date: Tue, 11 Aug 1998 21:15:03 -0400
To: Tom Kung <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: New version of CMS available
Cc: [email-masked]
Sender: [email-masked]

Tom:

You are correct.  I renamed the second one to KeyAgreeRecipientIdentifier.

Russ

At 02:06 PM 7/3/98 -0400, Tom Kung wrote:
>Goodays,
>
>There appears to be two definitions for RecipientIdentifier in CMS06:
>
> RecipientIdentifier ::= CHOICE {
>     issuerAndSerialNumber IssuerAndSerialNumber,
>     subjectKeyIdentifier [0] SubjectKeyIdentifier }
>
>AND
>
> RecipientIdentifier ::= CHOICE {
>     issuerAndSerialNumber IssuerAndSerialNumber,
>     rKeyId [0] IMPLICIT RecipientKeyIdentifier }
>
>Tom.
>> ----------
>> From: 	Paul Hoffman / IMC[SMTP:[email-masked]]
>> Sent: 	Friday, July 03, 1998 11:37 AM
>> To: 	[email-masked]
>> Subject: 	New version of CMS available
>> 
>> Draft -06 of CMS is now in the official drafts archives and can also be
>> found at <http://www.imc.org/draft-ietf-smime-cms>.
>> 
>> --Paul Hoffman, Director
>> --Internet Mail Consortium
>> 
> 

To: "Bob Jueneman" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: Replay of CMS SignedData
From: EKR <[email-masked]>
Date: 11 Aug 1998 09:28:24 -0700
Lines: 34
Sender: [email-masked]

"Bob Jueneman" <[email-masked]> writes:

> I'm afraid that I disagree with the apparent concensus, and 
> agree with Russ.
> 
> "Applications which desire replay prevention should carefully
> consider what it is they are trying to accomplish and 
> design accordingly. "
> 
> Excellent advice, but unfortunately very rarely followed.
Applications which DON'T follow it will likely get unexpected
results even if they use Signing Time.

The issue here is not generating Signing Time but rather
checking it. To produce predictable results, protocols which
desire replay protection have to specify how the replay
checking is performed, which is the tricky bit. We
shouldn't do that here since it's application specific.
Consequently, since we can't do the Right Thing we shouldn't
do anything.

> I would be perfectly happy with suggesting that signing time always
> be used, but I suppose you could have a CHOICE of signing time or some 
> nonce.  Creating a good nonrepeating nonce may be even harder, 
> however.
Huh? Creating a nonrepeating nonce is trivial. Use a counter.
In the worst case, you can use the time, in which case
this reduces to the Signing Time problem.

-Ekr

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

Date: Tue, 11 Aug 1998 09:46:51 -0600
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Replay of CMS SignedData
Sender: [email-masked]

I'm afraid that I disagree with the apparent concensus, and 
agree with Russ.

"Applications which desire replay prevention should carefully
consider what it is they are trying to accomplish and 
design accordingly. "

Excellent advice, but unfortunately very rarely followed.

In my experience, standards are very often misapplied and misused
by people who were not involved in the original discussions and don't 
appreciate the subtleties. This seems like a case where this is all too
likely.

(BTW, as someone who has only casually been follwing these 
discussions, and hasn't even read the text yet, I admit to falling into 
that category of people who may not appreciate the subtleties. 
My apologies if I am misreading something.)

Signing time in this context would presumably not be viewed as a 
secure timestamp -- in particular I assume that no representatations are
made about its correctness (accuracy relative to UTC).  

But on the other hand, except in the possible case of a stuck clock
(which is still fail safe), it is extremely unlikely to repeat, even if the 
system clock is adjusted backwards. And if it does repeat, that 
simply means that a message would be rejected as a replay
attack.

I would be perfectly happy with suggesting that signing time always
be used, but I suppose you could have a CHOICE of signing time or some 
nonce.  Creating a good nonrepeating nonce may be even harder, 
however.

Bob

>Russ Housley <[email-masked]> writes:
>> Unless an application making use of SignedData includes a specifically
>> formatted field that includes replay prevention, any application protocol
>> using SignedData will be open to replay.
>> 
>> The CMS specification can reamin silent on this issue, or we can recommend
>> a simple patch.  Why not recommend that the signing time attribute always
>> be used?
>>
>> When no authenticated atributes are included, this solution will not help.
>> In this case, the best we can do is a paragraph in the security
>> considerations section.
>> 
>> Thoughts?
>
>I'd rather the spec remain silent on this issue.
>
>Timestamps aren't a very good fix for replay prevention.
>Applications which desire replay prevention should carefully
>consider what it is they are trying to accomplish and 
>design accordingly. 
>
>-Ekr
>
>-- 
>[Eric Rescorla                             Terisa Systems, Inc.]
>		"Put it in the top slot."

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Products Group
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

"Architects, like prophets and saints, are 
usually years ahead of their time. For this
reason they are often difficult to live with
at home."

To: [email-masked]
Cc: "Jim Schaad (Exchange)" <[email-masked]>
Subject: Re: Replay of CMS SignedData 
Date: Tue, 11 Aug 1998 16:12:05 +0100
From: Andrew Farrell <[email-masked]>
Sender: [email-masked]

In message <2FBF98FC7852CF11912A000000000001091266B7@DINO>you write:
>I very much agree with Eric on this issue.  This type of thing must be done
>in a way which makes sense to the application.  This is especially true
>since one can't rely on signing time as a correct value, it does not even
>have the quality of a timestamp yet.

Even if timestamping works, we don't get a message which we can look at
and say "this is a replay attack". If our ISP loops a piece of mail for
a week, then all our mail will have a receiving date much later than the
timestamped one. Signifies nothing.

However, it does serve a function as one thing which, all other things
being valid, must be different from one instance to another. If you
recieve two identical signed pieces of mail which say "Send me the
money", both with signingTime, then something somewhere is wrong, which
isn't necessarily the case without signingTime. Again, this is a matter
of storing and comparing email messages, and so is outside our
jurisdiction, but it would be no harm to include a note saying we
facilitate this, much as the ESS MailingListHistory facilitates stopping
loopbacks.

While I'm on the subject: We are (by volume) most of the S/MIME
implementors. Doesn't here not send signingTime?

Andrew Farrell,
Baltimore Technologies.

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "'EKR'" <[email-masked]>, Russ Housley <[email-masked]>
Cc: [email-masked]
Subject: RE: Replay of CMS SignedData
Date: Tue, 11 Aug 1998 00:57:55 -0700
Sender: [email-masked]

I very much agree with Eric on this issue.  This type of thing must be done
in a way which makes sense to the application.  This is especially true
since one can't rely on signing time as a correct value, it does not even
have the quality of a timestamp yet.

jim

-----Original Message-----
From: EKR [mailto:[email-masked]]
Sent: Monday, August 10, 1998 10:09 PM
To: Russ Housley
Cc: [email-masked]
Subject: Re: Replay of CMS SignedData

Russ Housley <[email-masked]> writes:
> Unless an application making use of SignedData includes a specifically
> formatted field that includes replay prevention, any application protocol
> using SignedData will be open to replay.
> 
> The CMS specification can reamin silent on this issue, or we can recommend
> a simple patch.  Why not recommend that the signing time attribute always
> be used?
>
> When no authenticated atributes are included, this solution will not help.
> In this case, the best we can do is a paragraph in the security
> considerations section.
> 
> Thoughts?

I'd rather the spec remain silent on this issue.

Timestamps aren't a very good fix for replay prevention.
Applications which desire replay prevention should carefully
consider what it is they are trying to accomplish and 
design accordingly. 

-Ekr

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

To: Russ Housley <[email-masked]>
Cc: [email-masked]
Subject: Re: Replay of CMS SignedData
From: EKR <[email-masked]>
Date: 10 Aug 1998 22:09:05 -0700
Lines: 27
Sender: [email-masked]

Russ Housley <[email-masked]> writes:
> Unless an application making use of SignedData includes a specifically
> formatted field that includes replay prevention, any application protocol
> using SignedData will be open to replay.
> 
> The CMS specification can reamin silent on this issue, or we can recommend
> a simple patch.  Why not recommend that the signing time attribute always
> be used?
>
> When no authenticated atributes are included, this solution will not help.
> In this case, the best we can do is a paragraph in the security
> considerations section.
> 
> Thoughts?

I'd rather the spec remain silent on this issue.

Timestamps aren't a very good fix for replay prevention.
Applications which desire replay prevention should carefully
consider what it is they are trying to accomplish and 
design accordingly. 

-Ekr

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

Date: Mon, 10 Aug 1998 13:18:06 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: CMS Countersignatures
Sender: [email-masked]

It is generally inadvisable to sign arbitrary message digest values.  These
values potentially have associated meaning which may be damaging to the
signing entity in various contexts and for which the signing entity should
be able to repudiate.  For example, message digest may correspond to an
unseen digital contract.

Because a CMS countersigning process might not check the message digest
value presented for serial signature against the corresponding message
content, it can be duped into signing an undesirable message digest value.
  
I would like to require the validation of the signature value prior to
counter signing it.  However, this is not a PKCS#7 v1.5 requirement.  Does
anyone have an objection to requiring a counter-signer from validating the
signature value prior to signing it?

If requiring the validation of the presented value is unacceptable, then
some counter-signer-generated data (such as a random nonce or time stamp
attribute) should be included in the counter-signed data.  Note that the
input to this process should be different than for a regular signature with
authenticated attributes or the problem will remain.

Russ

Date: Mon, 10 Aug 1998 12:51:48 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Replay of CMS SignedData
Sender: [email-masked]

Unless an application making use of SignedData includes a specifically
formatted field that includes replay prevention, any application protocol
using SignedData will be open to replay.

The CMS specification can reamin silent on this issue, or we can recommend
a simple patch.  Why not recommend that the signing time attribute always
be used?

When no authenticated atributes are included, this solution will not help.
In this case, the best we can do is a paragraph in the security
considerations section.

Thoughts?

Russ

Date: Mon, 10 Aug 1998 08:51:48 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Replay of CMS SignedData
Sender: [email-masked]

Unless an application making use of SignedData includes a specifically
formatted field that includes replay prevention, any application protocol
using SignedData will be open to replay.

The CMS specification can reamin silent on this issue, or we can recommend
a simple patch.  Why not recommend that the signing time attribute always
be used?

When no authenticated atributes are included, this solution will not help.
In this case, the best we can do is a paragraph in the security
considerations section.

Thoughts?

Russ

Date: Mon, 10 Aug 1998 09:18:06 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: CMS Countersignatures
Sender: [email-masked]

It is generally inadvisable to sign arbitrary message digest values.  These
values potentially have associated meaning which may be damaging to the
signing entity in various contexts and for which the signing entity should
be able to repudiate.  For example, message digest may correspond to an
unseen digital contract.

Because a CMS countersigning process might not check the message digest
value presented for serial signature against the corresponding message
content, it can be duped into signing an undesirable message digest value.
  
I would like to require the validation of the signature value prior to
counter signing it.  However, this is not a PKCS#7 v1.5 requirement.  Does
anyone have an objection to requiring a counter-signer from validating the
signature value prior to signing it?

If requiring the validation of the presented value is unacceptable, then
some counter-signer-generated data (such as a random nonce or time stamp
attribute) should be included in the counter-signed data.  Note that the
input to this process should be different than for a regular signature with
authenticated attributes or the problem will remain.

Russ

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-msg-05.txt
Date: Mon, 10 Aug 1998 11:21:49 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: S/MIME Version 3 Message Specification
	Author(s)	: B. Ramsdell
	Filename	: draft-ietf-smime-msg-05.txt
	Pages		: 20
	Date		: 07-Aug-98
	
S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a
consistent way to send and receive secure MIME data. Based on the
popular Internet MIME standard, S/MIME provides the following
cryptographic security services for electronic messaging applications:
authentication, message integrity and non-repudiation of origin (using
digital signatures) and privacy and data security (using encryption).
 
S/MIME can be used by traditional mail user agents (MUAs) to add
cryptographic security services to mail that is sent, and to interpret
cryptographic security services in mail that is received. However,
S/MIME is not restricted to mail; it can be used with any transport
mechanism that transports MIME data, such as HTTP. As such, S/MIME
takes advantage of the object-based features of MIME and allows secure
messages to be exchanged in mixed-transport systems.
 
Further, S/MIME can be used in automated message transfer agents that
use cryptographic security services that do not require any human
intervention, such as the signing of software-generated documents and
the encryption of FAX messages sent over the Internet.

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-msg-05.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-msg-05.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-smime-msg-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-msg-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-msg-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-cert-05.txt
Date: Mon, 10 Aug 1998 11:21:47 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: S/MIME Version 3 Certificate Handling
	Author(s)	: B. Ramsdell
	Filename	: draft-ietf-smime-cert-05.txt
	Pages		: 9
	Date		: 07-Aug-98
	
S/MIME (Secure/Multipurpose Internet Mail Extensions), described in
[SMIME-MSG], provides a method to send and receive secure MIME
messages. Before using a public key to provide security services, the
S/MIME agent MUST certify that the public key is valid. S/MIME agents
MUST use PKIX certificates to validate public keys as described in the
Internet X.509 Public Key Infrastructure (PKIX) Certificate and CRL
Profile [KEYM].  S/MIME agents MUST meet the S/MIME-specific
requirements documented in this I-D in addition to those stated in
[KEYM].
 
This specification is compatible with the Cryptographic Message Syntax
[CMS] in that it uses the data types defined by CMS. It also inherits
all the varieties of architectures for certificate-based key
management supported by CMS. Note that the method S/MIME messages make
certificate requests is defined in [SMIME-MSG].

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-cert-05.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-cert-05.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-smime-cert-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-cert-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-cert-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-ess-07.txt
Date: Thu, 06 Aug 1998 09:30:05 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: Enhanced Security Services for S/MIME
	Author(s)	: P. Hoffman
	Filename	: draft-ietf-smime-ess-07.txt
	Pages		: 31
	Date		: 05-Aug-98
	
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
 
The services described here are extensions to S/MIME version 3 [SMIME3],
and some of them can also be added to S/MIME version 2 [SMIME2]. The
extensions described here will not cause an S/MIME version 3 recipient to
be unable to read messages from an S/MIME version 2 sender. However, some
of the extensions will cause messages created by an S/MIME version 3 sender
to be unreadable by an S/MIME version 2 recipient.
 
The format of the messages are described in ASN.1:1988 [ASN1-1988].
 
This draft is being discussed on the 'ietf-smime' mailing list. To
subscribe, send a message to:
     [email-masked]
with the single word
     subscribe
in the body of the message. There is a Web site for the mailing list at
<http://www.imc.org/ietf-smime/>.

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-ess-07.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-ess-07.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-smime-ess-07.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-ess-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-ess-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Wed, 05 Aug 1998 13:42:53 -0400
To: EKR <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: draft-ietf-smime-x942-00.txt comments.
Cc: "[email-masked]" <[email-masked]>
Sender: [email-masked]

At 11:26 PM 8/4/98 -0700, EKR wrote:
>[email-masked] (John Pawling) writes:
>> 3) Sec 2.1.2:  This section states:  "pubInfo is a random string 
>> provided by the sender. In CMS, it is provided as a parameter in the 
>> UserKeyingMaterial field (a 512 bit byte string)."  Since pubInfo is 
>> defined as an OCTET STRING, shouldn't the value of pubInfo be 
>> expressed in octets (i.e. bytes)?  When you wrote "(a 512 bit byte 
>> string)", did you mean "(an OCTET STRING containing 64 octets)"?
>That's fine with me. I think this text came from Russ. Russ?

An octet string that is 64 bytes long is fine with me.

Russ

Date: Wed, 05 Aug 1998 14:23:13 +0100
To: [email-masked]
From: William Ottaway <[email-masked]>
Subject: Re: ESS-06 Comments
Sender: [email-masked]

If a message has more than one EquivalentLabels attribute it is up to local
policy as to what to do. I'm happy for it to be deleted but I'm also happy
with John's suggestion below, which still allows the recipient to do what
they want but also provides some guidance on what to do.

Bill.

At 16:45 04/08/98 -0400, you wrote:
>Paul,
>
>If anything, ESS should state: "If a message has more than one
>EquivalentLabels attribute, the receiving agent SHOULD 
>process the first one that it reads and validates that contains the security
>policy of interest to the receiving agent."
>
>- John Pawling
>
>
>At 11:36 AM 8/4/98 -0700, Paul Hoffman / IMC wrote:
>>I agree with all of John's suggested new wording, but am iffy on the
>>following:
>>
>>>4) Sec 3.4.2, 2nd para:  Recommend deleting: "If a message has more 
>>>than one EquivalentLabels attribute, the receiving agent SHOULD 
>>>process the first one that it reads and validates."
>>
>>I think we should give advice to a recipient about what to do if multiple
>>(possibly conflicting) EquivalentLabels are in a message, although I'm also
>>OK with deleting this. What do others think?
>>
>>--Paul Hoffman, Director
>>--Internet Mail Consortium
>>
>
>
_____________________________________________________________________
William Ottaway,             Tel: +44 (0)1684 894079
DERA Malvern,                Fax: +44 (0)1684 896113
St. Andrews Road,            email: [email-masked]
Malvern,
Worcs, WR14 3PS
UK

To: [email-masked] (John Pawling)
Cc: "[email-masked]" <[email-masked]>
Subject: Re: draft-ietf-smime-x942-00.txt comments.
From: EKR <[email-masked]>
Date: 04 Aug 1998 23:26:35 -0700
Lines: 55
Sender: [email-masked]

[email-masked] (John Pawling) writes:

> Eric,
> 
> Thank you for your excellent work on the draft-ietf-smime-x942-00 I-D. 
> I have the following minor comments and questions:
> 
> 
> 1) Sec 2.1.1:  Please change the following:
> 
> OLD: "In CMS, the recipient's key is identified by the CMS
> RecipientIdentifier, which points to the recipient's certificate.  The 
> sender's key is identified using the OriginatorIdentifier field, 
> either by reference to the sender's certificate or by inline inclusion 
> of a key."
> 
> NEW: "In CMS, the recipient's key is identified by the CMS 
> RecipientIdentifier, which points to the recipient's certificate or 
> directly to the recipient's key (via the subjectKeyIdentifier).  The 
> sender's public key is identified using the originatorIdentifierOrKey 
> field, either by reference to the sender's certificate, sender's 
> public key (via the subjectKeyIdentifier) or by inline inclusion of 
> the sender's public key."
I have no problem with this.

> 2) Sec 2.1.2:  The "[2]" tag is not needed in the following syntax 
> because the first occurrence of OCTET STRING is mandatory, so the 
> ASN.1 decoders can uniquely identify each OCTET STRING (i.e. pubInfo 
> and counter).
> 
>            OtherInfo ::= SEQUENCE {
>              keyInfo KeySpecificInfo,
>              pubInfo [2] OCTET STRING OPTIONAL,
>            }
> 
>            KeySpecificInfo ::= SEQUENCE {
>              algorithm OBJECT IDENTIFIER,
>              counter OCTET STRING SIZE (4..4) }
This is there for bits on the wire compatibility with X9.42, 
which has two other fields here which we're not using.

> 
> 3) Sec 2.1.2:  This section states:  "pubInfo is a random string 
> provided by the sender. In CMS, it is provided as a parameter in the 
> UserKeyingMaterial field (a 512 bit byte string)."  Since pubInfo is 
> defined as an OCTET STRING, shouldn't the value of pubInfo be 
> expressed in octets (i.e. bytes)?  When you wrote "(a 512 bit byte 
> string)", did you mean "(an OCTET STRING containing 64 octets)"?
That's fine with me. I think this text came from Russ. Russ?

-Ekr

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

Date: Tue, 4 Aug 1998 18:14:31 -0400
To: "[email-masked]" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: draft-ietf-smime-x942-00.txt comments.
Sender: [email-masked]

Eric,

Thank you for your excellent work on the draft-ietf-smime-x942-00 I-D. 
I have the following minor comments and questions:

1) Sec 2.1.1:  Please change the following:

OLD: "In CMS, the recipient's key is identified by the CMS
RecipientIdentifier, which points to the recipient's certificate.  The 
sender's key is identified using the OriginatorIdentifier field, 
either by reference to the sender's certificate or by inline inclusion 
of a key."

NEW: "In CMS, the recipient's key is identified by the CMS 
RecipientIdentifier, which points to the recipient's certificate or 
directly to the recipient's key (via the subjectKeyIdentifier).  The 
sender's public key is identified using the originatorIdentifierOrKey 
field, either by reference to the sender's certificate, sender's 
public key (via the subjectKeyIdentifier) or by inline inclusion of 
the sender's public key."

2) Sec 2.1.2:  The "[2]" tag is not needed in the following syntax 
because the first occurrence of OCTET STRING is mandatory, so the 
ASN.1 decoders can uniquely identify each OCTET STRING (i.e. pubInfo 
and counter).

           OtherInfo ::= SEQUENCE {
             keyInfo KeySpecificInfo,
             pubInfo [2] OCTET STRING OPTIONAL,
           }

           KeySpecificInfo ::= SEQUENCE {
             algorithm OBJECT IDENTIFIER,
             counter OCTET STRING SIZE (4..4) }

3) Sec 2.1.2:  This section states:  "pubInfo is a random string 
provided by the sender. In CMS, it is provided as a parameter in the 
UserKeyingMaterial field (a 512 bit byte string)."  Since pubInfo is 
defined as an OCTET STRING, shouldn't the value of pubInfo be 
expressed in octets (i.e. bytes)?  When you wrote "(a 512 bit byte 
string)", did you mean "(an OCTET STRING containing 64 octets)"?

================================
John Pawling, [email-masked]                             
J.G. Van Dyke & Associates, Inc.   
www.jgvandyke.com         
================================

Date: Tue, 4 Aug 1998 16:45:09 -0400
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: ESS-06 Comments
Sender: [email-masked]

Paul,

If anything, ESS should state: "If a message has more than one
EquivalentLabels attribute, the receiving agent SHOULD 
process the first one that it reads and validates that contains the security
policy of interest to the receiving agent."

- John Pawling

At 11:36 AM 8/4/98 -0700, Paul Hoffman / IMC wrote:
>I agree with all of John's suggested new wording, but am iffy on the
>following:
>
>>4) Sec 3.4.2, 2nd para:  Recommend deleting: "If a message has more 
>>than one EquivalentLabels attribute, the receiving agent SHOULD 
>>process the first one that it reads and validates."
>
>I think we should give advice to a recipient about what to do if multiple
>(possibly conflicting) EquivalentLabels are in a message, although I'm also
>OK with deleting this. What do others think?
>
>--Paul Hoffman, Director
>--Internet Mail Consortium
>

Date: Tue, 4 Aug 1998 16:42:50 -0400
To: Brian Korver <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: CMS-06 Comments
Cc: [email-masked]
Sender: [email-masked]

Brian,

Please note that I didn't change any of the text about which you are
inquiring.  When Russ wrote Section 9.2, he based the text on CMS Sec 5.4
(Message Digest Calculation Process) which was based on the following PKCS
#7, v1.5 text:

"(For clarity: The IMPLICIT [0] tag in the authenticatedAttributes field is
not part of the Attributes value. The Attributes value's tag is SET OF, and
the DER encoding of the SET OF tag, rather than of the IMPLICIT [0] tag, is
to be digested along with the length and contents octets of the Attributes
value.)"

In my opinion, I like Russ' "EXPLICIT SET OF" text because it emphasizes
that the SET OF tag must be a part of the DER encoded data which is input to
the MAC calculation process.

- John Pawling

At 09:45 AM 8/4/98 -0700, Brian Korver wrote:
>John,
>
>One minor nit....
>
>John Pawling writes:
>[snip]
>> The result of the MAC calculation process depends on whether the 
>> authenticatedAttributes field is present.  When the field is absent, 
>> the result is just the MAC of the content as described above.  When 
>> the field is present, however, the result is   the MAC of the complete 
>> DER encoding of the authenticatedAttributes value contained in the 
>> AuthAttributes field. Since the authenticatedAttributes value, when 
>> present, must contain the content-type and mac-value attributes, those 
>> values are indirectly included in the result.  A separate encoding of 
>> the authenticatedAttributes field is performed for MAC calculation.  
>> The IMPLICIT [0] tag in the authenticatedAttributes field is not used 
>> for the DER encoding, rather an EXPLICIT SET OF tag is used.  That is, 
>
>I know what you mean, but "EXPLICIT SET OF" looks almost like ASN.1.
>I'd suggest dropping EXPLICIT.  If it isn't clear enough, maybe we
>should parenthetically state the actual tag byte (0x31).
>
>
>> the DER encoding of the SET OF tag, rather than of the IMPLICIT [0] 
>> tag, is to be included in the MAC calculation along with the length 
>> and content octets of the authenticatedAttributes value.
>[snip]
>
>brian
>[email-masked]
>

Date: Tue, 04 Aug 1998 11:36:18 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: ESS-06 Comments
Sender: [email-masked]

I agree with all of John's suggested new wording, but am iffy on the
following:

>4) Sec 3.4.2, 2nd para:  Recommend deleting: "If a message has more 
>than one EquivalentLabels attribute, the receiving agent SHOULD 
>process the first one that it reads and validates."

I think we should give advice to a recipient about what to do if multiple
(possibly conflicting) EquivalentLabels are in a message, although I'm also
OK with deleting this. What do others think?

--Paul Hoffman, Director
--Internet Mail Consortium

From: Brian Korver <[email-masked]>
Subject: Re: CMS-06 Comments
To: [email-masked] (John Pawling)
Date: Tue, 4 Aug 1998 09:45:16 -0700 (PDT)
Cc: [email-masked]
Sender: [email-masked]

John,

One minor nit....

John Pawling writes:
[snip]
> The result of the MAC calculation process depends on whether the 
> authenticatedAttributes field is present.  When the field is absent, 
> the result is just the MAC of the content as described above.  When 
> the field is present, however, the result is   the MAC of the complete 
> DER encoding of the authenticatedAttributes value contained in the 
> AuthAttributes field. Since the authenticatedAttributes value, when 
> present, must contain the content-type and mac-value attributes, those 
> values are indirectly included in the result.  A separate encoding of 
> the authenticatedAttributes field is performed for MAC calculation.  
> The IMPLICIT [0] tag in the authenticatedAttributes field is not used 
> for the DER encoding, rather an EXPLICIT SET OF tag is used.  That is, 

I know what you mean, but "EXPLICIT SET OF" looks almost like ASN.1.
I'd suggest dropping EXPLICIT.  If it isn't clear enough, maybe we
should parenthetically state the actual tag byte (0x31).

> the DER encoding of the SET OF tag, rather than of the IMPLICIT [0] 
> tag, is to be included in the MAC calculation along with the length 
> and content octets of the authenticatedAttributes value.
[snip]

brian
[email-masked]

Date: Tue, 4 Aug 1998 10:39:36 -0400
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: CMS-06 Comments
Sender: [email-masked]

All,

I have a few minor comments to CMS-06:

1) Sec 9.2, MAC Generation:  A few months ago, the "Message Digest 
Calculation Process" section of CMS was updated to reflect the change 
from "ContentInfo" to "EncapsulatedContentInfo" in the signedData 
syntax.  Similar changes need to be made to the "MAC Generation" 
section of CMS to reflect the inclusion of "EncapsulatedContentInfo" 
in the authenticatedData syntax.  Recommend that the first 5 
paragraphs of the MAC Generation section of CMS should be changed to 
read as follows:

"9.2 MAC Generation

The MAC calculation process computes a message authentication code 
(MAC) on either the content being authenticated or the content 
together with the originator's authenticated attributes.  In either 
case, the initial input to the MAC calculation process is the "value" 
of the encapsulated content being authenticated.  Specifically, the 
initial input is the   encapContentInfo eContent OCTET STRING to which 
the authentication process is applied.  Only the octets comprising the 
value of the eContent OCTET STRING are input to the MAC algorithm, not 
the tag or the length octets.

The result of the MAC calculation process depends on whether the 
authenticatedAttributes field is present.  When the field is absent, 
the result is just the MAC of the content as described above.  When 
the field is present, however, the result is   the MAC of the complete 
DER encoding of the authenticatedAttributes value contained in the 
AuthAttributes field. Since the authenticatedAttributes value, when 
present, must contain the content-type and mac-value attributes, those 
values are indirectly included in the result.  A separate encoding of 
the authenticatedAttributes field is performed for MAC calculation.  
The IMPLICIT [0] tag in the authenticatedAttributes field is not used 
for the DER encoding, rather an EXPLICIT SET OF tag is used.  That is, 
the DER encoding of the SET OF tag, rather than of the IMPLICIT [0] 
tag, is to be included in the MAC calculation along with the length 
and content octets of the authenticatedAttributes value.

When the authenticatedAttributes field is absent, then only the octets 
comprising the value of the authenticatedData encapContentInfo 
eContent OCTET STRING (e.g., the contents of a file) are input to the 
MAC calculation.  This has the advantage that the length of the 
content being authenticated need not be known in advance of the MAC 
generation process.

Although the encapContentInfo eContent OCTET STRING tag and length 
octets are not included in the MAC calculation, they are still 
protected by other means.  The length octets are protected by the 
nature of the MAC algorithm since it is  computationally infeasible to 
find any two distinct messages of any length that have the same MAC."

2) Sec 11.1, Content Type: Please change as follows:

OLD: "A content-type attribute must have a single attribute value."

NEW: "The SignedAttributes and AuthAttributes syntaxes are each 
defined as a SET OF Attributes.  The SignedAttributes in a signerInfo 
MUST NOT include multiple instances of the content-type attribute.  
Similarly, the AuthAttributes in an AuthenticatedData MUST NOT include 
multiple instances of the content-type attribute.  The Attribute 
syntax defines attrValues as a SET OF AttributeValue.  A content-type 
attribute MUST only include a single instance of AttributeValue. There 
MUST NOT be zero or multiple instances of AttributeValue present in 
the attrValues SET OF AttributeValue."

3) Sec 11.2, Message Digest: Please change as follows:

OLD: "A message-digest attribute must have a single attribute value."

NEW: "The SignedAttributes syntax is defined as a SET OF Attributes.  
The SignedAttributes in a signerInfo MUST NOT include multiple 
instances of the message-digest attribute.  The Attribute syntax 
defines attrValues as a SET OF AttributeValue.  A message-digest 
attribute MUST only include a single instance of AttributeValue. There 
MUST NOT be zero or multiple instances of AttributeValue present in 
the attrValues SET OF AttributeValue."

4) Sec 11.3, Signing Time: Please change as follows:

OLD: "A signing-time attribute must have a single attribute value."

NEW: "The SignedAttributes syntax is defined as a SET OF Attributes.  
The SignedAttributes in a signerInfo MUST NOT include multiple 
instances of the signing-time attribute.  The Attribute syntax defines 
attrValues as a SET OF AttributeValue.  A signing-time attribute MUST 
only include a single instance of AttributeValue. There MUST NOT be 
zero or multiple instances of AttributeValue present in the attrValues 
SET OF AttributeValue."

5) Sec 11.4, Countersignature: Please change as follows:

OLD: "A countersignature attribute can have multiple attribute values."

NEW: "The UnsignedAttributes syntax is defined as a SET OF Attributes.  
The UnsignedAttributes in a signerInfo MAY include multiple instances 
of the countersignature attribute.  The Attribute syntax defines 
attrValues as a SET OF AttributeValue.  A countersignature attribute 
MUST only include a single instance of AttributeValue. There MUST NOT 
be zero or multiple instances of AttributeValue present in the 
attrValues SET OF AttributeValue."

6) Sec 11.5, MAC Value: Please change as follows:

OLD: "A MAC-value attribute must have a single attribute value."

NEW: "The AuthAttributes syntax is defined as a SET OF Attributes.  
The AuthAttributes in an AuthenticatedData MUST NOT include multiple 
instances of the MAC-value attribute.  The Attribute syntax defines 
attrValues as a SET OF AttributeValue.  A MAC-value attribute MUST 
only include a single instance of AttributeValue. There MUST NOT be 
zero or multiple instances of AttributeValue present in the attrValues 
SET OF AttributeValue."

================================
John Pawling, [email-masked]                             
J.G. Van Dyke & Associates, Inc.   
www.jgvandyke.com         
================================

From: [email-masked]
To: [email-masked]
Subject: Strong signature - weak cryptography
Date: 04 Aug 1998 15:47:34 +0200
Sender: [email-masked]

Hi,

yet another question for non-north americans !

Anybody knows if the following sequence of crypto algorithms is subject to the 
US export restictions?

- signature DSS  key-length > 512 ; since it can be used for the signature
- crypto rc4/40 :(by example) weak cryptography only 
- Sha:  digest

Since a strong signature is more critical than strong cryptography of the 
message this sequence could be more acceptable than todays export versions of 
S/mime.

regards , francesco zambon

<[email-masked]>

Date: Tue, 4 Aug 1998 09:09:45 -0400
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: CMS Section 12, take 3
Sender: [email-masked]

All,

I have a few comments/questions regarding CMS Section 12:

1) Sec 12.1, intro, last sent: Please change "Message Digest authenticated
attribute" to "Message Digest signed attribute".

2) Sec 12.2.1: Please change "The algorithm identifier for DSA is:" to "The
algorithm identifier for DSA used in conjunction with SHA-1 is:".  I assume
that if an organization requires DSA to be used with a hashing algorithm
other than SHA-1, then they will define their own OID in a separate document.

3) Sec 12.3.3.1: Please change "Distribution of the key material used to
encryption the message encryption" to "Distribution of the key material used
to encrypt the message encryption".

4) Sec 12.4, 3rd para states: "Triple-DES may be an exception here; the same
identifier is used for both 2-key and 3-key Triple DES.  This is probably
easily handled by always wrapping three keys, even if the first and third
keys match."  These sentences need to be clarified.  The words "may" and
"probably" set off interoperability alarm bells in my mind.  We need to
resolve this issue and clearly state the solution in the CMS spec.  

5) Sec 12.4: Please delete: "{{{I am going to assume that this was suppose
to be a random padding.}}}"

================================
John Pawling, [email-masked]                             
J.G. Van Dyke & Associates, Inc.   
www.jgvandyke.com         
================================

Date: Tue, 4 Aug 1998 08:26:30 -0400
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: ESS-06 Comments
Sender: [email-masked]

All,

I have the following comments to ESS-06:

1) Sec 1.3.4, 2nd para:  Please make the following editorial change:

OLD: "CMS defines signedAttrs as a SET OF SignedAttributes and defines
unsignedAttributes as a SET OF UnsignedAttributes. ESS defines the
contentHints, contentIdentifier, eSSecurityLabel, msgSigDigest,
mlExpansionHistory and receiptRequest attribute types."

NEW: "CMS defines signedAttrs as a SET OF Attributes and defines
unsignedAttributes as a SET OF Attributes. ESS defines the
contentHints, contentIdentifier, eSSecurityLabel, msgSigDigest,
mlExpansionHistory, receiptRequest, contentReference and
equivalentLabels attribute types."

2) Sec 1.3.4, 5th para:  Please make the following editorial change:

OLD: "Note that the inner and outer signatures are for different 
senders, so that the same attribute in the two signatures could lead 
to very different consequences."

NEW:  "Note that the inner and outer signatures are usually for 
different senders.  The same attribute in the two signatures could 
lead to very different consequences."

3) Sec 3.4, 2nd para:  Please make the following change:

OLD: "Receiving agents will not process an equivalent label in a 
message if the agent does not trust the signer of that attribute to 
specify an equivalent security policy. Some receiving agents will not 
process any equivalent labels at all, and will only process 
eSSSecurityLabels. All receiving agents SHOULD recognize equivalent 
labels even if they do not process them."

NEW: "Receiving agents MUST NOT process an equivalentLabels attribute 
in a message if the agent does not trust the signer of that attribute 
to translate the original eSSSecurityLabel values to the security 
policy included in the equivalentLabels attribute.  It is an optional 
requirement for receiving agents to process equivalentLabels 
attributes.  It is acceptable for a receiving agent to only process 
eSSSecurityLabels. All receiving agents SHOULD recognize 
equivalentLabels attributes even if they do not process them."

4) Sec 3.4.1, 5th para: Please make the following editorial change:

OLD: "CMS defines signedAttributes as a SET OF SignedAttribute."

NEW: "CMS defines signedAttributes as a SET OF Attribute."

3) Sec 3.4.2, 2nd para:  Please make the following change:

OLD:  "A receiving agent MUST NOT act on an EquivalentLabels attribute 
for which the signature could not be validated, and MUST NOT act on an 
EquivalentLabels attribute unless that attribute is signed by an
entity trusted to add or change access policies."

NEW: "A receiving agent MUST NOT act on an equivalentLabels attribute 
for which the signature could not be validated, and MUST NOT act on an 
equivalentLabels attribute unless that attribute is signed by an 
entity trusted to to translate the original eSSSecurityLabel values to 
to the security policy included in the equivalentLabels attribute."

4) Sec 3.4.2, 2nd para:  Recommend deleting: "If a message has more 
than one EquivalentLabels attribute, the receiving agent SHOULD 
process the first one that it reads and validates."

================================
John Pawling, [email-masked]                             
J.G. Van Dyke & Associates, Inc.   
www.jgvandyke.com         
================================

From: [email-masked] (John Pawling)
Subject: CMS-06 Comments
To: [email-masked]
Date: Mon, 3 Aug 1998 15:14:11 -0400 (EDT)
Sender: [email-masked]

All,

I have the following comments to ESS-06:

1) Sec 1.3.4, 2nd para:  Please make the following editorial change:

OLD: "CMS defines signedAttrs as a SET OF SignedAttributes and defines
unsignedAttributes as a SET OF UnsignedAttributes. ESS defines the
contentHints, contentIdentifier, eSSecurityLabel, msgSigDigest,
mlExpansionHistory and receiptRequest attribute types."

NEW: "CMS defines signedAttrs as a SET OF Attributes and defines
unsignedAttributes as a SET OF Attributes. ESS defines the
contentHints, contentIdentifier, eSSecurityLabel, msgSigDigest,
mlExpansionHistory, receiptRequest, contentReference and
equivalentLabels attribute types."

2) Sec 1.3.4, 5th para:  Please make the following editorial change:

OLD: "Note that the inner and outer signatures are for different 
senders, so that the same attribute in the two signatures could lead 
to very different consequences."

NEW:  "Note that the inner and outer signatures are usually for 
different senders.  The same attribute in the two signatures could 
lead to very different consequences."

3) Sec 3.4, 2nd para:  Please make the following change:

OLD: "Receiving agents will not process an equivalent label in a 
message if the agent does not trust the signer of that attribute to 
specify an equivalent security policy. Some receiving agents will not 
process any equivalent labels at all, and will only process 
eSSSecurityLabels. All receiving agents SHOULD recognize equivalent 
labels even if they do not process them."

NEW: "Receiving agents MUST NOT process an equivalentLabels attribute 
in a message if the agent does not trust the signer of that attribute 
to translate the original eSSSecurityLabel values to the security 
policy included in the equivalentLabels attribute.  It is an optional 
requirement for receiving agents to process equivalentLabels 
attributes.  It is acceptable for a receiving agent to only process 
eSSSecurityLabels. All receiving agents SHOULD recognize 
equivalentLabels attributes even if they do not process them."

4) Sec 3.4.1, 5th para: Please make the following editorial change:

OLD: "CMS defines signedAttributes as a SET OF SignedAttribute."

NEW: "CMS defines signedAttributes as a SET OF Attribute."

3) Sec 3.4.2, 2nd para:  Please make the following change:

OLD:  "A receiving agent MUST NOT act on an EquivalentLabels attribute 
for which the signature could not be validated, and MUST NOT act on an 
EquivalentLabels attribute unless that attribute is signed by an
entity trusted to add or change access policies."

NEW: "A receiving agent MUST NOT act on an equivalentLabels attribute 
for which the signature could not be validated, and MUST NOT act on an 
equivalentLabels attribute unless that attribute is signed by an 
entity trusted to to translate the original eSSSecurityLabel values to 
to the security policy included in the equivalentLabels attribute."

4) Sec 3.4.2, 2nd para:  Recommend deleting: "If a message has more 
than one EquivalentLabels attribute, the receiving agent SHOULD 
process the first one that it reads and validates."

================================
John Pawling, [email-masked]                             
J.G. Van Dyke & Associates, Inc.   
www.jgvandyke.com         
================================

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Summary of final changes to MSG draft
Date: Mon, 3 Aug 1998 18:44:24 -0700
Sender: [email-masked]

These are the changes that I am going to make to the -MSG draft for this
last cut.

1. SMIMECapabilities MUST be an authenticated attribute and MUST NOT be
unauthenticated, and there must only be one instance (John Pawling)
2. Ditto for SMIMEEncryptionKeyPreference (John Pawling)
3. RSA keylength minimums / maximums need to move to CMS (John Pawling)
4. SMIMECapabilities acceptance criteria cleanup (Stephen Henson)
5. List of supported CMS types (data, signed-data, enveloped-data) moved
back into MSG (John Pawling)
6. Slight wording changes in section 3.1 ("removed" becomes "processed")
for security services (Paul Hoffman and offline comments)
7. Mention risks of data integrity with enveloped-data (ciphertext
modifications are undetected) (Paul Hoffman and offline comments)
8. Signed and encrypted vs. encrypted and signed warnings (related to 7
above) (Paul Hoffman and offline comments)
9. Our broken version of ASN.1 is further broken by the omission of an
equalsign in CBCParameter (Paul Hoffman)

This list is a bit longer than the -CERT draft.

Flames welcome.  New draft submitted Wednesday AM if no complaints.

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

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Summary of final changes to CERT draft
Date: Mon, 3 Aug 1998 18:30:31 -0700
Sender: [email-masked]

These are the changes that I am going to make to the -CERT draft for
this last cut.

1. References to X.509 changed to PKIX (Denis Pinkas and Russ Housley)

There was a little discussion about name chaining and constraints, but I
believe that the current language reflects the consensus of the WG.
Also, there was some mumbling about attribute certificates, but I
believe that the current language is sufficient to use them if the need
ever arises.

Flames welcome.  New draft submitted Wednesday AM if no complaints.

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

Date: Mon, 03 Aug 1998 10:53:01 -0400
To: William Ottaway <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Question on adding an eSSSecurity Label
Cc: [email-masked]
Sender: [email-masked]

Yes, I think this shoud be true.

Russ

At 02:11 PM 7/29/98 +0100, William Ottaway wrote:
>Hi,
>
>In section 3.1.1 of ESS-06 it states :-
>
>"If any of the SignerInfos included in a SignedData object include an
>eSSSecurityLabel attribute, then all of the SignerInfos in that SignedData
>object MUST include an eSSSecurityLabel attribute and the value of each
>MUST be identical."
>
>Is this true even if a signerInfo does not have any signed attributes?
>
>For example, if the first SignerInfo does not have any signedAttrs and a
>second SignerInfo is added which contains an eSSSecurityLabel, the first
>SignerInfo must have an eSSSecurityLabel added, and therefore a contentType
>and messageDigest atrribute, and the signature recalculated.
>
>Bill
>
>
>_____________________________________________________________________
>William Ottaway,             Tel: +44 (0)1684 894079
>DERA Malvern,                Fax: +44 (0)1684 896113
>St. Andrews Road,            email: [email-masked]
>Malvern,
>Worcs, WR14 3PS
>UK
>