ETSI Draft CA Policy - comments requested

["Nick Pope" <[e-mail]>]

DRAFT FOR EDI WOKING GROUP - NOT FOR GENERAL DISTRIBUTION

Request for comments on draft ETSI standard:
"POLICY REQUIREMENTS FOR CERTIFICATION AUTHORITIES ISSUING PUBLIC KEY
CERTIFICATES"

The ETSI Electronic Signatures Infrastructure Working Group has drafted a
standard, which is based on TS 101 456 - Policy requirements for CAs issuing
qualified certificates, but specifies policy requirements for CAs supporting
the broad range of applications of public key certificates.    This includes
certificates used to support electronic signatures, digital signatures,
encryption, key exchange and key agreement mechanisms

COMMENTS ARE REQUESTED BY 14TH SEPTEMBER.  Details of how to obtain a copy
of this document and submit comments are given towards the end of this
message.

The specification presents sets of requirements for different quality
levels, including a “Normalised” level which is similar to that offered by
qualified certificates (as defined in the Electronic Signatures Directive)
conforming to on TS 101 456.

COMMENTS ARE SOUGHT PARTICULARLY ON THE FOLLOWING POINTS:

- A number of requirements have been selected for splitting into
alternatives, according to the different quality levels. Others are the same
for all levels. Selection criteria have been either critical effects of the
sensitivity of the service with regard to cost or/and security. Comments are
asked for about the selection of split requirements.

- Each quality level should represent a consistent set of requirements.
Consistency is related to threats and risks involved with the environment of
the service. Comments based on different business scenarios would help in
order to address wide segments of practical applications with the
requirements.

- Another aspect to consider is the relevance of the selected levels: are
they optimal from a market point of view or other level(s) may be more
useful?

This draft specification is being made publicly available for review and
comment by any company or organisation with interest in this area.  A copy
can be obtained through the ETSI El Sign web site (see below).

BACKGROUND

The development of this standard policy document is one of the tasks the
ETSI Electronic Signature and Infrastructure Working Group is progressing
within the European Electronic Signature Standardisation Initiative (EESSI).
The ETSI El Sign Web-site (see below) provides further information about the
ETSI activities and the EESSI program.

REQUESTED ACTION.

Please send your comments and suggestions not later than 14th September to
the ETSI El Sign e-mail list [e-mail], with copy to the editor
on [e-mail].   Please put "NonQCP" at the front of the Subject field
of all submissions to the e-mail list on this topic.

To register with the EL-SIGN list and download the draft document
(STF178Task2Draft.pdf) see:

http://www.etsi.org/sec/el-sign.htm

The purpose of the open e-mail list is to stimulate discussion of the
published comments and contributions. Therefore, early submissions are
welcome. We expect that discussions will go on through the open e-mail list
under and after the comments period.


With regards

Nick Pope, Security & Standards
Editor - Policy Requirements for CAs issuing public key certificates
[e-mail]

and

György Endersz, Telia Research AB
Chair ETSI ESI Working Group
[e-mail]







Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6UGklL06901 for ietf-smime-bks; Mon, 30 Jul 2001 09:46:47 -0700 (PDT)
Received: from btclick.com (mta02.btfusion.com [62.172.195.247]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6UGkjs06897 for <[e-mail]>; Mon, 30 Jul 2001 09:46:45 -0700 (PDT)
Received: from npwork2 ([213.123.188.84]) by btclick.com (Netscape Messaging Server 4.05) with SMTP id GHAP8E01.26O for <[e-mail]>; Mon, 30 Jul 2001 17:45:50 +0100 
From: "Nick Pope" <[e-mail]>
To: <[e-mail]>
Subject: ETSI Draft CA Policy - comments requested
Date: Mon, 30 Jul 2001 17:50:44 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

DRAFT FOR EDI WOKING GROUP - NOT FOR GENERAL DISTRIBUTION

Request for comments on draft ETSI standard:
"POLICY REQUIREMENTS FOR CERTIFICATION AUTHORITIES ISSUING PUBLIC KEY
CERTIFICATES"

The ETSI Electronic Signatures Infrastructure Working Group has drafted a
standard, which is based on TS 101 456 - Policy requirements for CAs issuing
qualified certificates, but specifies policy requirements for CAs supporting
the broad range of applications of public key certificates.    This includes
certificates used to support electronic signatures, digital signatures,
encryption, key exchange and key agreement mechanisms

COMMENTS ARE REQUESTED BY 14TH SEPTEMBER.  Details of how to obtain a copy
of this document and submit comments are given towards the end of this
message.

The specification presents sets of requirements for different quality
levels, including a “Normalised” level which is similar to that offered by
qualified certificates (as defined in the Electronic Signatures Directive)
conforming to on TS 101 456.

COMMENTS ARE SOUGHT PARTICULARLY ON THE FOLLOWING POINTS:

- A number of requirements have been selected for splitting into
alternatives, according to the different quality levels. Others are the same
for all levels. Selection criteria have been either critical effects of the
sensitivity of the service with regard to cost or/and security. Comments are
asked for about the selection of split requirements.

- Each quality level should represent a consistent set of requirements.
Consistency is related to threats and risks involved with the environment of
the service. Comments based on different business scenarios would help in
order to address wide segments of practical applications with the
requirements.

- Another aspect to consider is the relevance of the selected levels: are
they optimal from a market point of view or other level(s) may be more
useful?

This draft specification is being made publicly available for review and
comment by any company or organisation with interest in this area.  A copy
can be obtained through the ETSI El Sign web site (see below).

BACKGROUND

The development of this standard policy document is one of the tasks the
ETSI Electronic Signature and Infrastructure Working Group is progressing
within the European Electronic Signature Standardisation Initiative (EESSI).
The ETSI El Sign Web-site (see below) provides further information about the
ETSI activities and the EESSI program.

REQUESTED ACTION.

Please send your comments and suggestions not later than 14th September to
the ETSI El Sign e-mail list [e-mail], with copy to the editor
on [e-mail].   Please put "NonQCP" at the front of the Subject field
of all submissions to the e-mail list on this topic.

To register with the EL-SIGN list and download the draft document
(STF178Task2Draft.pdf) see:

http://www.etsi.org/sec/el-sign.htm

The purpose of the open e-mail list is to stimulate discussion of the
published comments and contributions. Therefore, early submissions are
welcome. We expect that discussions will go on through the open e-mail list
under and after the comments period.


With regards

Nick Pope, Security & Standards
Editor - Policy Requirements for CAs issuing public key certificates
[e-mail]

and

György Endersz, Telia Research AB
Chair ETSI ESI Working Group
[e-mail]






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6UCrUM27635 for ietf-smime-bks; Mon, 30 Jul 2001 05:53:30 -0700 (PDT)
Received: from sylvester (adsl-151-200-26-46.dc.adsl.bellatlantic.net [151.200.26.46]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6UCrSs27631 for <[e-mail]>; Mon, 30 Jul 2001 05:53:28 -0700 (PDT)
Received: from [192.168.0.11] by sylvester (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Mon, 30 Jul 2001 08:41:18 -0400
Message-ID: <[e-mail]>
Date: Mon, 30 Jul 2001 08:38:21 -0400
From: "Sean P. Turner" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Blake Ramsdell <[e-mail]>
CC: "'SMIME '" <[e-mail]>
Subject: Re: Password, compresion and symmetric keys -- are they CMSorS/ MIME ?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Blake,

I'll go ahead and change the name resubmit it (after the IETF).

spt

Blake Ramsdell wrote:

> The title (not the filename or the filename as referred to in the Document:
> header at the top of the draft) is "S/MIME Symmetric Key Distribution".
> Should this be CMS?
>
> I understand the draft naming convention, which includes the working group
> name, which in this case is smime, and is required.
>
> Blake
>
> -----Original Message-----
> From: Sean P. Turner
> To: Blake Ramsdell
> Cc: SMIME
> Sent: 7/23/2001 6:56 AM
> Subject: Re: Password, compresion and symmetric keys -- are they CMS orS/
> MIME ?
>
> Blake,
>
> I put S/MIME in the title only because it was produced in the S/MIME WG.
> S/MIME is referred to in the symmetric key distribution ID in:
>
> The headers: It's part of the document's title
> The abstract: Where is says this mechanisms may be used to support MLAs
> The introduction: As a lead in to a brief description of the differences
> between symmetric and asymmetric cryptography
> Paragraph 3.2.1 twice: Both as pointers to other document from the
> S/MIME WG
> Paragraph 9: Copies names of documents for the references.
>
> I'm not sure which of these you think should change.
>
> Cheers,
>
> spt
>
> Blake Ramsdell wrote:
>
> > snip....
> >
> > In the case of symkeydist, I still don't know if that was intended for
> > general CMS or S/MIME, so I will defer to the author of that document
> for
> > guidance, but there are indeed references to S/MIME.
> >
> > Blake
> >
> > -----Original Message-----
> > From: [e-mail]
> > To: Blake Ramsdell
> > Cc: [e-mail]
> > Sent: 7/20/2001 6:58 PM
> > Subject: Re: Password, compresion and symmetric keys -- are they CMS
> or
> > S/MIME ?
> >
> > "Blake Ramsdell" <[e-mail]> writes:
> >
> > >All three of these recent drafts (password, compression and
> symkeydist)
> > say
> > >S/MIME.
> >
> > Only the draft names because they're from the S/MIME WG.
> >
> > >Should any or all of these say CMS instead?
> >
> > The titles say CMS (eg "Password-based Encryption for CMS").
> >
> > >No, I haven't read 'em to figure it out for myself.  Go ahead and
> chew
> > me up.
> >
> > <chew></chew>
> >
> > Peter.




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6RMjSE02873 for ietf-smime-bks; Fri, 27 Jul 2001 15:45:28 -0700 (PDT)
Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6RMjRs02869 for <[e-mail]>; Fri, 27 Jul 2001 15:45:27 -0700 (PDT)
Received: from 208.236.41.137 by cane.deming.com with ESMTP (Tumbleweed MMS SMTP Relay (MMS v4.7)); Fri, 27 Jul 2001 15:45:25 -0700
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by cane.deming.com with Internet Mail Service (5.5.2650.21) id <PWZVWLYV>; Fri, 27 Jul 2001 15:45:25 -0700
Message-ID: <[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: New MSG, CERT and a bonus draft
Date: Fri, 27 Jul 2001 15:45:25 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
X-WSS-ID: 177F308F567-01-01
Content-Type: text/plain;  charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I submitted new MSG and CERT drafts that I believe reflect the current
working group consensus:

http://www.ietf.org/internet-drafts/draft-ramsdell-rfc2633bis-00.txt
http://www.ietf.org/internet-drafts/draft-ramsdell-rfc2632bis-00.txt

I also submitted another draft that I will discuss in London that has to do
with server-server S/MIME encryption (a subset of the functionality of
DOMSEC, but might be simply a profile of DOMSEC)

http://www.ietf.org/internet-drafts/draft-ramsdell-enc-smime-gateway-00.txt

Party on.

Blake
--
Blake C. Ramsdell, Tumbleweed Communications
Voice [phone] x103  Fax [phone]




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6RKd0400721 for ietf-smime-bks; Fri, 27 Jul 2001 13:39:00 -0700 (PDT)
Received: from smtp.nwlink.com (smtp.nwlink.com [209.20.130.57]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6RKcws00715 for <[e-mail]>; Fri, 27 Jul 2001 13:38:58 -0700 (PDT)
Received: from nwlink.com (www1.nwlink.com [209.20.130.81]) by smtp.nwlink.com (8.9.3/8.9.1) with SMTP id NAA09397; Fri, 27 Jul 2001 13:37:38 -0700 (PDT)
From: "Jim Schaad" <[e-mail]>
Reply-to: [e-mail]
To: [e-mail], [e-mail]
Date: Fri, 27 Jul 2001 16:38:53 -0400
Subject: 
Message-id: <[e-mail]>
X-User-Info: 63.36.12.199
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

One very minor comment.  I just went to implement the wrapping algorithm and
found that I made an error.  You might want to make a statement to the effect
that PKCS#7 padding is NOT done when talking about the key wrap algorithm. 
I did it and of course got the wrong answer.

Jim


Received: by above.proper.com (8.11.3/8.11.3) id f6RHGm126726 for ietf-smime-bks; Fri, 27 Jul 2001 10:16:48 -0700 (PDT)
Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6RHGks26722 for <[e-mail]>; Fri, 27 Jul 2001 10:16:46 -0700 (PDT)
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id f6RHGdB07677 for <[e-mail]>; Fri, 27 Jul 2001 10:16:39 -0700 (PDT)
Received: from netscape.com ([192.18.120.135]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GH56NQ00.NHU; Fri, 27 Jul 2001 10:16:38 -0700 
Message-ID: <[e-mail]>
Date: Fri, 27 Jul 2001 10:16:12 -0700
From: [e-mail] (Bob Relyea)
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.1+) Gecko/20010628 Netscape6/6.1b1
X-Accept-Language: en-us
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
CC: [e-mail]
Subject: Re: Comments to draft-ietf-smime-rfc2630bis-01
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Gutmann wrote:

>Here's a summary of the situation, hope I got all these right:
>
>Baltimore (old, SMT): Rejects message if version != 0
>Baltimote (new, KeyTools): Won't process the message unless it understands the
>  version (does this mean it requires version = 0...2?)
>cryptlib (older versions): Rejects message if unknown version encountered (value >2)
>cryptlib (newer versions): Ignores version
>Microsoft: Ignores version
>OpenSSL: Ignores version
>RSA: Rejects message if version != 0
>SFL: Ignores version (except for use in reporting errors)
>Tumbleweed: Rejects message if version != 0
>
>So it looks like there's about a 50/50 split between implementations which
>require the version to be 0 (or in some cases 0...2) and ones which ignore it
>entirely.
>
Netscape NSS, at least the current version: Ignores version on decode.

bob

>
>
>Peter.
>




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6RGdK425782 for ietf-smime-bks; Fri, 27 Jul 2001 09:39:20 -0700 (PDT)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6RGdIs25777 for <[e-mail]>; Fri, 27 Jul 2001 09:39:18 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id EAA03585 for <[e-mail]>; Sat, 28 Jul 2001 04:39:19 +1200 (NZST) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id EAA36158 for [e-mail]; Sat, 28 Jul 2001 04:39:19 +1200 (NZST) (sender [e-mail])
Date: Sat, 28 Jul 2001 04:39:19 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: Comments to draft-ietf-smime-rfc2630bis-01
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Here's a summary of the situation, hope I got all these right:

Baltimore (old, SMT): Rejects message if version != 0
Baltimote (new, KeyTools): Won't process the message unless it understands the
  version (does this mean it requires version = 0...2?)
cryptlib (older versions): Rejects message if unknown version encountered (value >2)
cryptlib (newer versions): Ignores version
Microsoft: Ignores version
OpenSSL: Ignores version
RSA: Rejects message if version != 0
SFL: Ignores version (except for use in reporting errors)
Tumbleweed: Rejects message if version != 0

So it looks like there's about a 50/50 split between implementations which
require the version to be 0 (or in some cases 0...2) and ones which ignore it
entirely.

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6QGsnm24550 for ietf-smime-bks; Thu, 26 Jul 2001 09:54:49 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6QGsms24546 for <[e-mail]>; Thu, 26 Jul 2001 09:54:48 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 26 Jul 2001 16:53:03 UT
Received: from tuna.rsa.com (tuna.rsa.com [10.80.211.153]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id MAA23559 for <[e-mail]>; Thu, 26 Jul 2001 12:54:47 -0400 (EDT)
Received: from rsasecurity.com ([10.81.217.242]) by tuna.rsa.com (8.8.8+Sun/8.8.8) with ESMTP id JAA10750 for <[e-mail]>; Thu, 26 Jul 2001 09:56:27 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 26 Jul 2001 09:53:19 -0700
From: Jeff Jacoby <[e-mail]>
Organization: RSA Security, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Comments to draft-ietf-smime-rfc2630bis-01
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Housley, Russ" wrote:
> 
> I agree!
> 
> >I'd really like to see
> >some comments from other implementors - Baltimore, MS, Entrust,
> OpenSSL,
> >Netscape, what do all of these implementations do?
> 
> We have heard about three implementations (from Peter, John, and
> Jim).  Would the rest of the implementors please speak up on this issue.
> 
> Russ

Sorry for the late reply.  Another data point...

The Cert-C toolkit currently will reject envelopedData messages when the
version number != 0.

Jeff
-- 
Jeff Jacoby, Sr. Programmer                
RSA Security Inc., SMDC                    [e-mail]
2755 Campus Dr., Ste. 300                  [phone]
San Mateo, CA  94403


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6OGqMZ00812 for ietf-smime-bks; Tue, 24 Jul 2001 09:52:22 -0700 (PDT)
Received: from btclick.com (mta02.btfusion.com [62.172.195.247]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6OGqFG00803 for <[e-mail]>; Tue, 24 Jul 2001 09:52:21 -0700 (PDT)
Received: from npwork2 ([213.123.188.4]) by btclick.com (Netscape Messaging Server 4.05) with SMTP id GGZLIZ03.71K for <[e-mail]>; Tue, 24 Jul 2001 17:52:11 +0100 
From: "Nick Pope" <[e-mail]>
To: <[e-mail]>
Subject: Draft ETSI TS "XML Advanced Electronic Signatures"
Date: Tue, 24 Jul 2001 17:58:00 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Request for comments on draft ETSI standard:
"XML Advanced Electronic Signatures (XAdES)"

The ETSI Electronic Signatures Infrastructure Working Group has drafted a
standard which specifies the XML format for Advanced Electronic Signatures
satisfying the requeriments defined in the European Directive
for Electronic Signatures, and with long term validity.

This draft specification is being made publicly available for review and
comment by any company or organisation with interest in this area.  A copy
can be obtained through the ETSI El Sign web site (see below).

Comments are requested by 14th September.

Background

The development of this standard

"XML Advanced Electronic Signatures"

is one of the tasks the ETSI Electronic Signature and Infrastructure Working
Group is progressing within the European Electronic Signature
Standardisation
Initiative (EESSI). The ETSI El Sign Web-site (see below) provides further
information about the ETSI activities and the EESSI program.

REQUESTED ACTION

Please send your comments and suggestions not later than 14 September to the
ETSI El Sign e-mail list [e-mail], with copy to the editor on
[e-mail] .   Please put "ETSI-XAdES" at the front of the Subject
field of all submissions to the e-mail list on this topic.

To register with the EL-SIGN list and download the draft document
(STF178Task3Draft.pdf) see:

http://www.etsi.org/sec/el-sign.htm


The purpose of the open e-mail list is to stimulate discussion of the
published comments and contributions. Therefore, early submissions are
welcome. We expect that discussions will go on through the open e-mail list
under and after the comments period.


With regards

Juan  Carlos Cruellas (Universitat Politecnica de Catalunya)
Editor - XML Advanced Electronic Signatures (XAdES)
[e-mail]

and

György Endersz, Telia Research AB
Chair ETSI ESI Working Group
[e-mail]



Received: by above.proper.com (8.11.3/8.11.3) id f6OAYiJ17038 for ietf-smime-bks; Tue, 24 Jul 2001 03:34:44 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6OAYhG17034 for <[e-mail]>; Tue, 24 Jul 2001 03:34:43 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06700; Tue, 24 Jul 2001 06:33:45 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-x400transport-03.txt
Date: Tue, 24 Jul 2001 06:33:44 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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		: Transporting S/MIME Objects in X.400
	Author(s)	: P. Hoffman, C. Bonatti
	Filename	: draft-ietf-smime-x400transport-03.txt
	Pages		: 
	Date		: 23-Jul-01
	
This document describes protocol options for conveying CMS-protected
objects associated with S/MIME version 3 over an X.400 message transfer
system.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-x400transport-03.txt

Internet-Drafts are also 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-x400transport-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-x400transport-03.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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-x400transport-03.txt

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: by above.proper.com (8.11.3/8.11.3) id f6OAYdw17031 for ietf-smime-bks; Tue, 24 Jul 2001 03:34:39 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6OAYbG17027 for <[e-mail]>; Tue, 24 Jul 2001 03:34:37 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06688; Tue, 24 Jul 2001 06:33:40 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-x400wrap-03.txt
Date: Tue, 24 Jul 2001 06:33:40 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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		: Securing X.400 Content with S/MIME
	Author(s)	: P. Hoffman, C. Bonatti
	Filename	: draft-ietf-smime-x400wrap-03.txt
	Pages		: 
	Date		: 23-Jul-01
	
This document describes a protocol for adding cryptographic signature
and encryption services to X.400 content.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-x400wrap-03.txt

Internet-Drafts are also 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-x400wrap-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-x400wrap-03.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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-x400wrap-03.txt

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: by above.proper.com (8.11.3/8.11.3) id f6NG7x228769 for ietf-smime-bks; Mon, 23 Jul 2001 09:07:59 -0700 (PDT)
Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6NG7wq28765 for <[e-mail]>; Mon, 23 Jul 2001 09:07:58 -0700 (PDT)
Received: from 208.236.41.137 by cane.deming.com with ESMTP (Tumbleweed MMS SMTP Relay (MMS v4.7)); Mon, 23 Jul 2001 09:07:54 -0700
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by cane.deming.com with Internet Mail Service (5.5.2650.21) id <M71BR4D9>; Mon, 23 Jul 2001 09:07:54 -0700
Message-ID: <[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "'Sean P. Turner '" <[e-mail]>
cc: "'SMIME '" <[e-mail]>
Subject: RE: Password, compresion and symmetric keys -- are they CMS orS/ MIME ?
Date: Mon, 23 Jul 2001 09:07:53 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
X-WSS-ID: 17429450130802-01-01
Content-Type: text/plain;  charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The title (not the filename or the filename as referred to in the Document:
header at the top of the draft) is "S/MIME Symmetric Key Distribution".
Should this be CMS?

I understand the draft naming convention, which includes the working group
name, which in this case is smime, and is required.

Blake

-----Original Message-----
From: Sean P. Turner
To: Blake Ramsdell
Cc: SMIME
Sent: 7/23/2001 6:56 AM
Subject: Re: Password, compresion and symmetric keys -- are they CMS orS/
MIME ?

Blake,

I put S/MIME in the title only because it was produced in the S/MIME WG.
S/MIME is referred to in the symmetric key distribution ID in:

The headers: It's part of the document's title
The abstract: Where is says this mechanisms may be used to support MLAs
The introduction: As a lead in to a brief description of the differences
between symmetric and asymmetric cryptography
Paragraph 3.2.1 twice: Both as pointers to other document from the
S/MIME WG
Paragraph 9: Copies names of documents for the references.

I'm not sure which of these you think should change.

Cheers,

spt

Blake Ramsdell wrote:

> snip....
>
> In the case of symkeydist, I still don't know if that was intended for
> general CMS or S/MIME, so I will defer to the author of that document
for
> guidance, but there are indeed references to S/MIME.
>
> Blake
>
> -----Original Message-----
> From: [e-mail]
> To: Blake Ramsdell
> Cc: [e-mail]
> Sent: 7/20/2001 6:58 PM
> Subject: Re: Password, compresion and symmetric keys -- are they CMS
or
> S/MIME ?
>
> "Blake Ramsdell" <[e-mail]> writes:
>
> >All three of these recent drafts (password, compression and
symkeydist)
> say
> >S/MIME.
>
> Only the draft names because they're from the S/MIME WG.
>
> >Should any or all of these say CMS instead?
>
> The titles say CMS (eg "Password-based Encryption for CMS").
>
> >No, I haven't read 'em to figure it out for myself.  Go ahead and
chew
> me up.
>
> <chew></chew>
>
> Peter.





Received: by above.proper.com (8.11.3/8.11.3) id f6NE0lX20084 for ietf-smime-bks; Mon, 23 Jul 2001 07:00:47 -0700 (PDT)
Received: from smtp7ve.mailsrvcs.net (smtp7vepub.gte.net [206.46.170.28]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6NE0jq20080 for <[e-mail]>; Mon, 23 Jul 2001 07:00:45 -0700 (PDT)
Received: from ieca.com (adsl-151-200-26-46.dc.adsl.bellatlantic.net [151.200.26.46]) by smtp7ve.mailsrvcs.net (8.9.1/8.9.1) with ESMTP id OAA46501757; Mon, 23 Jul 2001 14:00:36 GMT
Message-ID: <[e-mail]>
Date: Mon, 23 Jul 2001 09:56:58 -0400
From: "Sean P. Turner" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Blake Ramsdell <[e-mail]>
CC: SMIME <[e-mail]>
Subject: Re: Password, compresion and symmetric keys -- are they CMS orS/ MIME ?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Blake,

I put S/MIME in the title only because it was produced in the S/MIME WG.
S/MIME is referred to in the symmetric key distribution ID in:

The headers: It's part of the document's title
The abstract: Where is says this mechanisms may be used to support MLAs
The introduction: As a lead in to a brief description of the differences
between symmetric and asymmetric cryptography
Paragraph 3.2.1 twice: Both as pointers to other document from the S/MIME WG
Paragraph 9: Copies names of documents for the references.

I'm not sure which of these you think should change.

Cheers,

spt

Blake Ramsdell wrote:

> snip....
>
> In the case of symkeydist, I still don't know if that was intended for
> general CMS or S/MIME, so I will defer to the author of that document for
> guidance, but there are indeed references to S/MIME.
>
> Blake
>
> -----Original Message-----
> From: [e-mail]
> To: Blake Ramsdell
> Cc: [e-mail]
> Sent: 7/20/2001 6:58 PM
> Subject: Re: Password, compresion and symmetric keys -- are they CMS or
> S/MIME ?
>
> "Blake Ramsdell" <[e-mail]> writes:
>
> >All three of these recent drafts (password, compression and symkeydist)
> say
> >S/MIME.
>
> Only the draft names because they're from the S/MIME WG.
>
> >Should any or all of these say CMS instead?
>
> The titles say CMS (eg "Password-based Encryption for CMS").
>
> >No, I haven't read 'em to figure it out for myself.  Go ahead and chew
> me up.
>
> <chew></chew>
>
> Peter.



Received: by above.proper.com (8.11.3/8.11.3) id f6NAesn16315 for ietf-smime-bks; Mon, 23 Jul 2001 03:40:54 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6NAeqq16311 for <[e-mail]>; Mon, 23 Jul 2001 03:40:52 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09274; Mon, 23 Jul 2001 06:39:54 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-aes-alg-02.txt
Date: Mon, 23 Jul 2001 06:39:53 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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		: Use of the AES Encryption Algorithm and RSA-OAEP 
                          Key Transport in CMS
	Author(s)	: J. Schaad, R. Housley
	Filename	: draft-ietf-smime-aes-alg-02.txt
	Pages		: 14
	Date		: 18-Jul-01
	
This document specifies how to incorporate the Advanced Encryption
Standard (AES) algorithm [AES] and RSAES-OAEP key transport method of
key management into the S/MIME Cryptographic Message Syntax [CMS] as
additional algorithms.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-aes-alg-02.txt

Internet-Drafts are also 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-aes-alg-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-aes-alg-02.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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-aes-alg-02.txt

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: by above.proper.com (8.11.3/8.11.3) id f6M5A8t21684 for ietf-smime-bks; Sat, 21 Jul 2001 22:10:08 -0700 (PDT)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6M59uq21665 for <[e-mail]>; Sat, 21 Jul 2001 22:09:56 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id RAA07152; Sun, 22 Jul 2001 17:09:59 +1200 (NZST) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id RAA174274; Sun, 22 Jul 2001 17:09:59 +1200 (NZST) (sender [e-mail])
Date: Sun, 22 Jul 2001 17:09:59 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: Password, compresion and symmetric keys -- are they CMS or S/ MIME ?
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>S/MIME should be CMS.

I've fixed both of them, the final versions will say CMS throughout (well,
except for where they really do mean S/MIME).

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6LGhcq11245 for ietf-smime-bks; Sat, 21 Jul 2001 09:43:38 -0700 (PDT)
Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6LGhbq11241 for <[e-mail]>; Sat, 21 Jul 2001 09:43:37 -0700 (PDT)
Received: from 208.236.41.137 by cane.deming.com with ESMTP (Tumbleweed MMS SMTP Relay (MMS v4.7)); Sat, 21 Jul 2001 09:43:33 -0700
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by cane.deming.com with Internet Mail Service (5.5.2650.21) id <M71BRT42>; Sat, 21 Jul 2001 09:43:33 -0700
Message-ID: <[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "'[e-mail] '" <[e-mail]>
cc: "'[e-mail] '" <[e-mail]>
Subject: RE: Password, compresion and symmetric keys -- are they CMS or S/ MIME ?
Date: Sat, 21 Jul 2001 09:43:26 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
X-WSS-ID: 17476EBF126858-01-01
Content-Type: text/plain;  charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

OK, teeth boy, you made me actually think.

draft-ietf-smime-password-04:

The title in the announcement message was "Password-based Encryption for
S/MIME", which is indeed corrected in the actual document.

Section 1, the sentence:

"This document describes a password-based content encryption mechanism
for S/MIME."

S/MIME should be CMS.


draft-ietf-smime-compression-05:

The title in the announcement message was "Compressed Data Content Type for
S/MIME", which is indeed corrected in the actual document.

Section 1, the sentence:

"This document describes a compressed data content type for S/MIME."

S/MIME should be CMS.


In the case of symkeydist, I still don't know if that was intended for
general CMS or S/MIME, so I will defer to the author of that document for
guidance, but there are indeed references to S/MIME.

Blake


-----Original Message-----
From: [e-mail]
To: Blake Ramsdell
Cc: [e-mail]
Sent: 7/20/2001 6:58 PM
Subject: Re: Password, compresion and symmetric keys -- are they CMS or
S/MIME ?

"Blake Ramsdell" <[e-mail]> writes:

>All three of these recent drafts (password, compression and symkeydist)
say
>S/MIME.

Only the draft names because they're from the S/MIME WG.

>Should any or all of these say CMS instead?

The titles say CMS (eg "Password-based Encryption for CMS").

>No, I haven't read 'em to figure it out for myself.  Go ahead and chew
me up.

<chew></chew>

Peter.






Received: by above.proper.com (8.11.3/8.11.3) id f6LBECr00903 for ietf-smime-bks; Sat, 21 Jul 2001 04:14:12 -0700 (PDT)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6LBEAq00898 for <[e-mail]>; Sat, 21 Jul 2001 04:14:10 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id NAA24955; Sat, 21 Jul 2001 13:58:22 +1200 (NZST) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id NAA147780; Sat, 21 Jul 2001 13:58:21 +1200 (NZST) (sender [e-mail])
Date: Sat, 21 Jul 2001 13:58:21 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re:  Password, compresion and symmetric keys -- are they CMS or S/MIME ?
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Blake Ramsdell" <[e-mail]> writes:

>All three of these recent drafts (password, compression and symkeydist) say
>S/MIME.

Only the draft names because they're from the S/MIME WG.

>Should any or all of these say CMS instead?

The titles say CMS (eg "Password-based Encryption for CMS").

>No, I haven't read 'em to figure it out for myself.  Go ahead and chew me up.

<chew></chew>

Peter.




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6KM7ou20968 for ietf-smime-bks; Fri, 20 Jul 2001 15:07:50 -0700 (PDT)
Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6KM7nq20964 for <[e-mail]>; Fri, 20 Jul 2001 15:07:49 -0700 (PDT)
Received: from 208.236.41.137 by cane.deming.com with ESMTP (Tumbleweed MMS SMTP Relay (MMS v4.7)); Fri, 20 Jul 2001 15:07:47 -0700
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by cane.deming.com with Internet Mail Service (5.5.2650.21) id <M71BRTJ4>; Fri, 20 Jul 2001 15:07:47 -0700
Message-ID: <[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Password, compresion and symmetric keys -- are they CMS or S/MIME ?
Date: Fri, 20 Jul 2001 15:07:38 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
X-WSS-ID: 17467439124424-01-01
Content-Type: text/plain;  charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All three of these recent drafts (password, compression and symkeydist) say
S/MIME.

Should any or all of these say CMS instead?

No, I haven't read 'em to figure it out for myself.  Go ahead and chew me
up.

Blake
--
Blake C. Ramsdell, Tumbleweed Communications
Voice [phone] x103  Fax [phone]




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6KGaaL10143 for ietf-smime-bks; Fri, 20 Jul 2001 09:36:36 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6KGaVq10139 for <[e-mail]>; Fri, 20 Jul 2001 09:36:31 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 20 Jul 2001 16:34:53 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id MAA09651 for <[e-mail]>; Fri, 20 Jul 2001 12:36:31 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <LR8TTR5L>; Fri, 20 Jul 2001 12:36:27 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.44]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LR8TTR5H; Fri, 20 Jul 2001 12:36:22 -0400
From: "Housley, Russ" <[e-mail]>
To: Andrew Shellshear <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Fri, 20 Jul 2001 12:36:22 -0400
Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01
In-Reply-To: <[e-mail] rgo.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Andrew:

>By the way, while I'm here - the CMS in PKCS#7 is v1.5.
>What's the version of CMS in RFC2630?  How should we
>refer to it?

Is the RFC number sufficient?  If not, I can coordinate with the PKCS 
editor to sort this out.

Russ


Received: by above.proper.com (8.11.3/8.11.3) id f6KEpTM01366 for ietf-smime-bks; Fri, 20 Jul 2001 07:51:29 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6KEpQq01356 for <[e-mail]>; Fri, 20 Jul 2001 07:51:27 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 20 Jul 2001 14:49:48 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA00169 for <[e-mail]>; Fri, 20 Jul 2001 10:51:22 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <LR8TTQ1C>; Fri, 20 Jul 2001 10:51:17 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.44]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LR8TTQ1B; Fri, 20 Jul 2001 10:51:14 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Fri, 20 Jul 2001 10:51:15 -0400
Subject: 51st IETF - S/MIME WG Agenda
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

51st IETF - S/MIME WG Agenda
Chair: Russ Housley <[e-mail]>

Introductions				Russ Housley
Working Group Status			Russ Housley
Interoperability Matrix 			Jim Schaad
CMS and ESS Examples 		Paul Hoffman
Updates to CMS			Russ Housley
Updates to CERT & MSG		Blake Ramsdell
Symmetric Key Distribution		Sean Turner
X.400 and CMS			Chris Bonatti
Reuse of Content Encryption Keys	Steve Farrell
AES and RSA-OAEP			Jim Schaad
Elliptic Curve Crypto			Simon Blake-Wilson
S/MIME Gateway Protocol		Blake Ramsdell
XML Electronic Signature Syntax	John Ross
CSP and Time Stamps			Denis Pinkas
NIST S/MIME Activities		Mike Chernick
S/MIME Freeware Library [*]		Rich Nicholas
Wrap up				Russ Housley

[*] = If time permits


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6KE2eg29285 for ietf-smime-bks; Fri, 20 Jul 2001 07:02:40 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6KE2Yq29277 for <[e-mail]>; Fri, 20 Jul 2001 07:02:34 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 20 Jul 2001 14:00:55 UT
Received: from exrsa01.rsa.com (exrsa01.rsa.com [10.81.217.7]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA25683 for <[e-mail]>; Fri, 20 Jul 2001 10:02:34 -0400 (EDT)
Received: by exrsa01.rsa.com with Internet Mail Service (5.5.2653.19) id <NQCGCJG8>; Fri, 20 Jul 2001 07:01:56 -0700
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.44]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LR8TTP2G; Fri, 20 Jul 2001 10:02:23 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
X-Priority: 2 (High)
Date: Fri, 20 Jul 2001 09:59:45 -0400
Subject: Fwd: I-D ACTION:draft-ietf-smime-password-04.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

S/MIME WG:

With the posing of these changes, I believe that this document is ready foe 
IETF-wide Last Call.  Please speak right now if you disagree.

>         Title           : Password-based Encryption for S/MIME
>         Author(s)       : P. Gutmann
>         Filename        : draft-ietf-smime-password-04.txt
>         Pages           :
>         Date            : 19-Jul-01
>
>The Cryptographic Message Syntax data format doesn't currently contain
>any provisions for password-based data encryption.  This document
>provides a method of encrypting data using user-supplied passwords and,
>by extension, any form of variable-length keying material which isn't
>necessarily an algorithm-specific fixed-format key.

Russ


Received: by above.proper.com (8.11.3/8.11.3) id f6K9cxR19183 for ietf-smime-bks; Fri, 20 Jul 2001 02:38:59 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6K9cvq19179 for <[e-mail]>; Fri, 20 Jul 2001 02:38:57 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06844; Fri, 20 Jul 2001 05:38:00 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-symkeydist-05.txt
Date: Fri, 20 Jul 2001 05:37:59 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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 Symmetric Key Distribution
	Author(s)	: S. Turner
	Filename	: draft-ietf-smime-symkeydist-05.txt
	Pages		: 75
	Date		: 19-Jul-01
	
This document describes a mechanism to manage (i.e., setup,
distribute, and rekey) keys used with symmetric cryptographic
algorithms. Also defined herein is a mechanism to organize users
into groups to support distribution of encrypted content using
symmetric cryptographic algorithms. The mechanisms use the
Cryptographic Message Syntax (CMS) protocol [2] and Certificate
Management Message over CMS (CMC) protocol [3] to manage the
symmetric keys. Any member of the group can then later use this
distributed shared key to decrypt other CMS encrypted objects with
the symmetric key. This mechanism has been developed to support
S/MIME Mail List Agents (MLAs).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-symkeydist-05.txt

Internet-Drafts are also 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-symkeydist-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-symkeydist-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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: by above.proper.com (8.11.3/8.11.3) id f6K9crf19172 for ietf-smime-bks; Fri, 20 Jul 2001 02:38:53 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6K9cqq19167 for <[e-mail]>; Fri, 20 Jul 2001 02:38:52 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06800; Fri, 20 Jul 2001 05:37:55 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-password-04.txt
Date: Fri, 20 Jul 2001 05:37:54 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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		: Password-based Encryption for S/MIME
	Author(s)	: P. Gutmann
	Filename	: draft-ietf-smime-password-04.txt
	Pages		: 
	Date		: 19-Jul-01
	
The Cryptographic Message Syntax data format doesn't currently contain
any provisions for password-based data encryption.  This document
provides a method of encrypting data using user-supplied passwords and,
by extension, any form of variable-length keying material which isn't
necessarily an algorithm-specific fixed-format key.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-password-04.txt

Internet-Drafts are also 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-password-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-password-04.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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-password-04.txt

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: by above.proper.com (8.11.3/8.11.3) id f6K9cmu19165 for ietf-smime-bks; Fri, 20 Jul 2001 02:38:48 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6K9ckq19161 for <[e-mail]>; Fri, 20 Jul 2001 02:38:46 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06741; Fri, 20 Jul 2001 05:37:50 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-compression-05.txt
Date: Fri, 20 Jul 2001 05:37:49 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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		: Compressed Data Content Type for S/MIME
	Author(s)	: P. Gutmann
	Filename	: draft-ietf-smime-compression-05.txt
	Pages		: 
	Date		: 19-Jul-01
	
The Cryptographic Message Syntax data format doesn't currently contain
any provisions for compressing data before processing it. Compressing
data before transmission provides a number of advantages including the
elimination of data redundancy which could help an attacker, speeding
up processing by reducing the amount of data to be processed by later
steps such as signing or encryption, and reducing overall message size.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-compression-05.txt

Internet-Drafts are also 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-compression-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-compression-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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: by above.proper.com (8.11.3/8.11.3) id f6K6GYf25735 for ietf-smime-bks; Thu, 19 Jul 2001 23:16:34 -0700 (PDT)
Received: from mailg.telia.com (mailg.telia.com [194.22.194.26]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6K6GXq25730 for <[e-mail]>; Thu, 19 Jul 2001 23:16:33 -0700 (PDT)
Received: from arport ([212.181.94.147]) by mailg.telia.com (8.11.2/8.11.0) with SMTP id f6K6GXZ19228; Fri, 20 Jul 2001 08:16:34 +0200 (CEST)
Message-ID: <000701c110e2$6198ed30$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "David P. Kemp" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: Signing on behalf of somebody else
Date: Fri, 20 Jul 2001 08:08:21 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David,

>In S/MIME v3 there is no connection between "sent by" (the From:
>field in the unsigned RFC-822 message header) and "signed by"
>(the name(s) contained in the certificate that validates the
>signature).  V2 required certificates to contain an rfc822
>address and for that address to match an unsigned header field;
>those limitations were removed in v3. 

 Does this mean that you don't actually need any rfc822 address
at all in the certificate.  I.e. the s.c. "e-mail certificates" is in
v3 essentially a dead item?

Personally I think this is great for the reasons you mentioned!

Anders




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6K0fr913600 for ietf-smime-bks; Thu, 19 Jul 2001 17:41:53 -0700 (PDT)
Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6K0foq13596 for <[e-mail]>; Thu, 19 Jul 2001 17:41:51 -0700 (PDT)
Received: from sweepau.baltimore.com.au (sweepau.jp.zergo.com.au [10.61.2.6]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id KAA02573 for <[e-mail]>; Fri, 20 Jul 2001 10:53:07 +1000
Received: from sydneymail1.zergo.com.au (unverified) by sweepau.baltimore.com.au (Content Technologies SMTPRS 4.2.1) with ESMTP id <[e-mail]>; Fri, 20 Jul 2001 10:42:26 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2650.21) id <PG6AZVSD>; Fri, 20 Jul 2001 10:39:28 +1000
Message-ID: <[e-mail]>
From: Andrew Shellshear <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail]
Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01
Date: Fri, 20 Jul 2001 10:39:28 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Baltimore has two implementations.  The old implementation,
SMT, ignores the version number and will fail if it gets
anything that falls outside the PKCS#7 spec.  

The newer implementation, KeyTools S/MIME, pays attention
to the version number and won't process the message unless 
it understands it.  It's debatable - and I suppose that's 
what this is about - whether this is a better approach.

Taking a stab at it (and I haven't been reading this 
thread thoroughly, so apologies if this is treading old
ground) ideally, I'd ignore all the tagged ASN.1 that we 
don't know about, keep going until there's some parsing 
error we can't deal with, and *then* check the version 
number for error-reporting.  This would have gotten us
through the differences between PKCS#7 and RFC2630 
fairly handily.

By the way, while I'm here - the CMS in PKCS#7 is v1.5.
What's the version of CMS in RFC2630?  How should we
refer to it?

Andrew Shellshear.

"Guttman, Peter" <[e-mail]> writes:
> "Pawling, John" <[e-mail]> writes:
> 
> >Nobody (except for Peter) has stated that their 
> implementations rejected an
> >EnvelopedData based solely on the version value.
> 
> OTOH nobody (except for you) has stated that their 
> implementations won't reject
> an EnvelopedData based solely on the version value.  I'd 
> really like to see
> some comments from other implementors - Baltimore, MS, 
> Entrust, OpenSSL,
> Netscape, what do all of these implementations do?  If the 
> vendors won't
> respond, perhaps someone who has all this stuff installed for 
> interop testing
> or whatever could feed them some EnvelopedData with a weird 
> version number (eg
> 42) to see what they do.
> 
> Peter.


-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended 
for the addressee(s) only.  If you have received this message in error or 
there are any problems please notify the originator immediately.  The 
unauthorized use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for direct, 
special, indirect or consequential damages arising from alteration of the 
contents of this message by a third party or as a result of any virus being 
passed on.

In addition, certain Marketing collateral may be added from time to time to 
promote Baltimore Technologies products, services, Global e-Security or 
appearance at trade shows and conferences.
 
This footnote confirms that this email message has been swept by 
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.


Received: by above.proper.com (8.11.3/8.11.3) id f6JKdw905644 for ietf-smime-bks; Thu, 19 Jul 2001 13:39:58 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6JKdvq05639 for <[e-mail]>; Thu, 19 Jul 2001 13:39:57 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id f6JKfOQ15313 for <[e-mail]>; Thu, 19 Jul 2001 16:41:24 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 19 Jul 2001 16:34:45 -0400
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Signing on behalf of somebody else
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-H-S-Loop-Check-Ejzfr: 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Leaving aside DOMSEC, the subject is confusing - a person who
possesses a private key cannot sign "on behalf of" someone else
unless the private key belongs to (and the certificate was
issued to) someone else.  Perhaps the subject was intended to
be "Sending on behalf of somebody else"?

In S/MIME v3 there is no connection between "sent by" (the From:
field in the unsigned RFC-822 message header) and "signed by"
(the name(s) contained in the certificate that validates the
signature).  V2 required certificates to contain an rfc822
address and for that address to match an unsigned header field;
those limitations were removed in v3.  The person named in the
certificate is the one who's signature will be validated;
that person can send email from home or from work, and can
switch jobs or switch ISPs without invalidating message
signatures.  Mail servers can rewrite addresses without
invalidating message signatures.

I'm not sure how a message signed by person A could be "sent"
(as opposed to being forwarded or otherwise included as an
attachment) by person B, but if an application were created
that allowed A to sign a message and B to push the button that
sends it to a mail server, that application would not violate
the intent of S/MIME v3.  It is the signer's signature, not the
sender's From: address, that is being validated.

Dave




Nagaraj Mandya wrote:
> 
> Hi,
>    Is it possible for a mail being sent by one person
> be signed by a different person and still be treated
> as a valid signature?
> 
>    My problem is like this. Any mail that a client
> receives signed by a particular person's certificate
> should be considered valid by the client irrespective
> of who the actual sender is.
> 
>    Thanks.
> --
> Regards,
> Nagaraj


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6JIshk01551 for ietf-smime-bks; Thu, 19 Jul 2001 11:54:43 -0700 (PDT)
Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6JIsgq01547 for <[e-mail]>; Thu, 19 Jul 2001 11:54:43 -0700 (PDT)
Received: from 208.236.41.137 by cane.deming.com with ESMTP (Tumbleweed MMS SMTP Relay (MMS v4.7)); Thu, 19 Jul 2001 11:54:39 -0700
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by cane.deming.com with Internet Mail Service (5.5.2650.21) id <M71BRSV3>; Thu, 19 Jul 2001 11:54:39 -0700
Message-ID: <[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail], [e-mail]
Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01
Date: Thu, 19 Jul 2001 11:54:38 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
X-WSS-ID: 1749F365119722-01-01
Content-Type: text/plain;  charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

We blow out if the EnvelopedData version != 0.  I understand that this
prevents us from processing a message with mixed RecipientInfo structures.
In retrospect, we can probably get away with skipping any RecipientInfo for
which we don't recognize the version.

Blake

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Wednesday, July 18, 2001 5:32 PM
To: [e-mail]; [e-mail]
Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01



"Pawling, John" <[e-mail]> writes:

>Nobody (except for Peter) has stated that their implementations rejected an
>EnvelopedData based solely on the version value.

OTOH nobody (except for you) has stated that their implementations won't
reject
an EnvelopedData based solely on the version value.  I'd really like to see
some comments from other implementors - Baltimore, MS, Entrust, OpenSSL,
Netscape, what do all of these implementations do?  If the vendors won't
respond, perhaps someone who has all this stuff installed for interop
testing
or whatever could feed them some EnvelopedData with a weird version number
(eg
42) to see what they do.

Peter.




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6JFsl424042 for ietf-smime-bks; Thu, 19 Jul 2001 08:54:47 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6JFsjq24036 for <[e-mail]>; Thu, 19 Jul 2001 08:54:45 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 19 Jul 2001 15:53:08 UT
Received: from exeu00.securid.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA19397 for <[e-mail]>; Thu, 19 Jul 2001 11:54:45 -0400 (EDT)
Received: by exeu00.securid.com with Internet Mail Service (5.5.2653.19) id <NNPBDKCC>; Thu, 19 Jul 2001 16:54:34 +0100
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.241]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LR8TT1AZ; Thu, 19 Jul 2001 11:54:27 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 19 Jul 2001 11:54:27 -0400
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I agree!

>I'd really like to see
>some comments from other implementors - Baltimore, MS, Entrust, OpenSSL,
>Netscape, what do all of these implementations do?

We have heard about three implementations (from Peter, John, and 
Jim).  Would the rest of the implementors please speak up on this issue.

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6JEBEQ13105 for ietf-smime-bks; Thu, 19 Jul 2001 07:11:14 -0700 (PDT)
Received: from smtp.nwlink.com (smtp.nwlink.com [209.20.130.57]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6JEBDq13098 for <[e-mail]>; Thu, 19 Jul 2001 07:11:13 -0700 (PDT)
Received: from nwlink.com (www1.nwlink.com [209.20.130.81]) by smtp.nwlink.com (8.9.3/8.9.1) with SMTP id HAA17129; Thu, 19 Jul 2001 07:09:57 -0700 (PDT)
From: "Jim Schaad" <[e-mail]>
Reply-to: [e-mail]
To: [e-mail][e-mail][e-mail]
Date: Thu, 19 Jul 2001 07:11:09 -0700
Subject: 
Message-id: <[e-mail]>
X-User-Info: 4.54.133.116
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I believe that the Microsoft implentation would not reject the object based on
the version number, but would reject the object on a parse failure if any unknown
recipient info appeared in the message.

jim

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Peter Gutmann
> Sent: Wednesday, July 18, 2001 5:32 PM
> To: [e-mail]; [e-mail]
> Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01
> 
> 
> 
> "Pawling, John" <[e-mail]> writes:
> 
> >Nobody (except for Peter) has stated that their 
> implementations rejected an
> >EnvelopedData based solely on the version value.
> 
> OTOH nobody (except for you) has stated that their 
> implementations won't reject
> an EnvelopedData based solely on the version value.  I'd 
> really like to see
> some comments from other implementors - Baltimore, MS, 
> Entrust, OpenSSL,
> Netscape, what do all of these implementations do?  If the 
> vendors won't
> respond, perhaps someone who has all this stuff installed for 
> interop testing
> or whatever could feed them some EnvelopedData with a weird 
> version number (eg
> 42) to see what they do.
> 
> Peter.
> 


Received: by above.proper.com (8.11.3/8.11.3) id f6JB7Nw07290 for ietf-smime-bks; Thu, 19 Jul 2001 04:07:23 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6JB7Lq07286 for <[e-mail]>; Thu, 19 Jul 2001 04:07:21 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28613; Thu, 19 Jul 2001 07:06:26 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-aes-alg-02.txt
Date: Thu, 19 Jul 2001 07:06:26 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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		: Use of the AES Encryption Algorithm and RSA-OAEP 
                          Key Transport in CMS
	Author(s)	: J. Schaad, R. Housley
	Filename	: draft-ietf-smime-aes-alg-02.txt
	Pages		: 14
	Date		: 18-Jul-01
	
This document specifies how to incorporate the Advanced Encryption
Standard (AES) algorithm [AES] and RSAES-OAEP key transport method of
key management into the S/MIME Cryptographic Message Syntax [CMS] as
additional algorithms.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-aes-alg-02.txt

Internet-Drafts are also 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-aes-alg-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-aes-alg-02.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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-aes-alg-02.txt

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: by above.proper.com (8.11.3/8.11.3) id f6J1bSD25748 for ietf-smime-bks; Wed, 18 Jul 2001 18:37:28 -0700 (PDT)
Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net [194.217.242.38]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6J1bQq25743 for <[e-mail]>; Wed, 18 Jul 2001 18:37:27 -0700 (PDT)
Received: from drh-consultancy.demon.co.uk ([193.237.150.98] helo=celocom.com) by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1) id 15N2kr-00049b-0A for [e-mail]; Thu, 19 Jul 2001 01:37:29 +0000
Message-ID: <[e-mail]>
Date: Thu, 19 Jul 2001 02:40:08 +0100
From: Dr S N Henson <[e-mail]>
Organization: S N Henson
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Comments to draft-ietf-smime-rfc2630bis-01
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Gutmann wrote:
> 
> OTOH nobody (except for you) has stated that their implementations won't reject
> an EnvelopedData based solely on the version value.  I'd really like to see
> some comments from other implementors - Baltimore, MS, Entrust, OpenSSL,
> Netscape, what do all of these implementations do?  If the vendors won't
> respond, perhaps someone who has all this stuff installed for interop testing
> or whatever could feed them some EnvelopedData with a weird version number (eg
> 42) to see what they do.
> 

Well for current versions of OpenSSL...

It doesn't check the version value so an invalid value will be silently
permitted.

It will reject a message with an unexpected encoding such as a
RecipientInfo that isn't PKCS#7 compatible. 

It can be made more tolerant of unexpected encodings and may well end up
including CMS support anyway.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [e-mail] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [e-mail] PGP key: via homepage.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6J0WGO21789 for ietf-smime-bks; Wed, 18 Jul 2001 17:32:16 -0700 (PDT)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6J0WEq21785 for <[e-mail]>; Wed, 18 Jul 2001 17:32:14 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id MAA18956; Thu, 19 Jul 2001 12:32:16 +1200 (NZST) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id MAA92120; Thu, 19 Jul 2001 12:32:15 +1200 (NZST) (sender [e-mail])
Date: Thu, 19 Jul 2001 12:32:15 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Pawling, John" <[e-mail]> writes:

>Nobody (except for Peter) has stated that their implementations rejected an
>EnvelopedData based solely on the version value.

OTOH nobody (except for you) has stated that their implementations won't reject
an EnvelopedData based solely on the version value.  I'd really like to see
some comments from other implementors - Baltimore, MS, Entrust, OpenSSL,
Netscape, what do all of these implementations do?  If the vendors won't
respond, perhaps someone who has all this stuff installed for interop testing
or whatever could feed them some EnvelopedData with a weird version number (eg
42) to see what they do.

Peter.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6ILu8U16934 for ietf-smime-bks; Wed, 18 Jul 2001 14:56:08 -0700 (PDT)
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6ILu5q16925 for <[e-mail]>; Wed, 18 Jul 2001 14:56:05 -0700 (PDT)
Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 18 Jul 2001 15:55:58 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 6.0
Date: Wed, 18 Jul 2001 15:57:30 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Mandatory to Implement Algorithms in CMS
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f6ILu6q16926
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

My view on this would be dependent on what algorithms (mandatory or otherwise) are to be listed in the suite.

If CMS comes up with a very short list of those algorithms that are very highly regarded by the cryptographic community, AND have been (or promise to be) widely accepted by the vendor community, then yes, I would like to see a stable list of algorithms everyone could implement and interoperate with.  If not, I would hope that the individual standards committees would be more selective. 

On the other hand, the track record of the IETF in general, and the S/MIME group in particular, is very disappointing in this area, and so I don't hold out much hope overall.

Unfortunately, other criteria are given more weight than the factors I listed, including in particular intellectual property considerations.  Then there is what I call the "pet rock" problem, where everyone's favorite algorithm gets included regardless of its proven robustness (or lack thereof -- the proof, not necessarily the robustness) or commercial viability, just to avoid offending someone, or having to make a hard choice.

That way lies madness, IMHO, not to mention fat, bloated code that is unnecessarily slow and doesn't work reliably; together with horrendous interoperability problems.  

Moore's law predicts that hardware speeds will double every 18 months or so, but "Gate's law" says that software will run slower and slower to compensate.  (I'm not being fair to Microsoft -- it is the entire software industry that is causing this problem, including the so-called standards groups that are causing this problem.)

If the number of algorithms included in the standard set are N, then the theme variations in key wrapping, etc., tends to go up as N-squared, and the interoperability problems goes up as N-squared times M, or maybe M-squared, where M is the number of different implementations.  

We can't afford this sort of nonsense.

Bob



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6IKrth14935 for ietf-smime-bks; Wed, 18 Jul 2001 13:53:55 -0700 (PDT)
Received: from romeo.rtfm.com ([198.144.203.242]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6IKrmq14931 for <[e-mail]>; Wed, 18 Jul 2001 13:53:49 -0700 (PDT)
Received: (ekr@localhost) by romeo.rtfm.com (8.9.3/8.6.4) id OAA13709; Wed, 18 Jul 2001 14:00:26 -0700 (PDT)
To: <[e-mail]>
Cc: "'Housley, Russ'" <[e-mail]>, <[e-mail]>
Subject: Re: Mandatory to Implement Algorithms in CMS
References: <000d01c10fbe$4fa375c0$[e-mail]>
Reply-to: EKR <[e-mail]>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
From: Eric Rescorla <[e-mail]>
Date: 18 Jul 2001 14:00:26 -0700
In-Reply-To: "Jim Schaad"'s message of "Wed, 18 Jul 2001 12:17:38 -0700"
Message-ID: <[e-mail]>
Lines: 11
X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Jim Schaad" <[e-mail]> writes:
> 2.  I believe the there should be no MUST implement algorithms for CMS.
> This is an issue for the protocol itself to decide not for CMS to decide for
> all protocols.  Different protocols will progress on accepting or mandating
> new algorithms at different rates (look at how slow TLS has been on adopting
> AES).  Thus it is the protocol not the underlying CMS objects that will
> mandate what algorithms are to be used.
I agree with Jim.

-Ekr



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6IKoUU14833 for ietf-smime-bks; Wed, 18 Jul 2001 13:50:30 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6IKoSq14829 for <[e-mail]>; Wed, 18 Jul 2001 13:50:28 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 18 Jul 2001 20:48:53 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA13016 for <[e-mail]>; Wed, 18 Jul 2001 16:50:29 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <LR8TSYBJ>; Wed, 18 Jul 2001 16:50:25 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.59]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LR8TSYBG; Wed, 18 Jul 2001 16:50:16 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Wed, 18 Jul 2001 16:49:27 -0400
Subject: RE: Mandatory to Implement Algorithms in CMS
In-Reply-To: <000d01c10fbe$4fa375c0$[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jim:

I took that end of the spectrum because I knew that you would take the 
other.  Hopefully the result will be a good discussion that results in 
group consensus.

>I think that this is a bad idea.  I will counter this by proposing that the
>Algorithm document be written in the same vein as the Certificate algorithm
>draft.
>
>1.  I would like the basic structures to get to the standard level so that
>they are known stable by all entities.  If the algorithms are included in
>the document, it is my belief that there will be a regular reset on the
>status of this document.

I agree with this point, and it is the strongest reason to have no 
mandatory to implement algorithms for CMS.  However, no mandatory to 
implement algorithms forces each application of CMS to specify mandatory to 
implement algorithms, so the "reset" still happens, but it happens in 
another specification.

In the S/MIME case, the "reset" happens in the MSG specification.  Of 
course, there are other users of CMS, like CMC.

>2.  I believe the there should be no MUST implement algorithms for CMS.
>This is an issue for the protocol itself to decide not for CMS to decide for
>all protocols.  Different protocols will progress on accepting or mandating
>new algorithms at different rates (look at how slow TLS has been on adopting
>AES).  Thus it is the protocol not the underlying CMS objects that will
>mandate what algorithms are to be used.

As you point out above, this is the approach being taken for the PKIX 
certificate and CRL profile.  It is also the approach for the PKIX 
Attribute Certificate Profile.

I do get concerned if the using protocol is not being developed in the 
Security Area of the IETF.  People with the necessary background to provide 
algorithm advice may not be available.

>3.  You shoved this down my throat for Certificates (no manditory
>algorithms), so I think you need to accept the consequences of logical
>extensions.  If certificates, which may be common across multiple protocols
>are not going to have a fixed set of manditory algorithms, why should CMS
>based protocols be required to have a manditory set of algorithms.  The CMS
>messages are not going to be jumping between protocols except on a very
>specific level.  (Use of a CMS based SETI would not have these messages
>suddenly appear as S/MIME email messages unless you had SETI specific code
>to handle them.)

I understand your point.  I am not sure that I agree with the "you" in your 
first sentence, but I was certainly a part of those discussions.

>4.  Toolkits based on CMS are going to have to allow for addition of other
>algorithms. This can be seen from the number of documents that have appeared
>providing for other algorithms to be used with CMS. (Note that there has not
>been any additional algorithms proposed for certificates beyond the EC
>versions.)  Protocol specific code is going to be written to the manditory
>algorithms while toolkeys must be extensible.

I agree.  Toolkits need to be algorithm agile.

>5.  Even if you specify manditory algorithms for CMS, you still have the
>problem of dealing with protocols that will say.  Implement CMS, but the
>manditory algorithms are X, Y and Z not A, B and C.  Thus providing a
>manditory to implement for CMS only buys a small amount of breathing room
>for protocols that don't override the manditory algorithms.

I agree that applications of CMS should be able to select algorithms that 
are appropriate for their application.  On the other hand, specification of 
an mandatory to implement algorithm suite for CMS is one additional step 
closer to a common cryptographic algorithm suite for the whole IETF.  As 
you know, I have been an advocate for a common suite of algorithms for the 
IETF Security Area.  At the August 2000 IETF meeting, I made a presentation 
at the SAAG asking for the selection of such a suite after the announcement 
of the AES winner.

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6IJHi612313 for ietf-smime-bks; Wed, 18 Jul 2001 12:17:44 -0700 (PDT)
Received: from femail3.sdc1.sfba.home.com (femail3.sdc1.sfba.home.com [24.0.95.83]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6IJHgq12309 for <[e-mail]>; Wed, 18 Jul 2001 12:17:42 -0700 (PDT)
Received: from revelation ([65.4.166.11]) by femail3.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010718191740.BMZF21742.femail3.sdc1.sfba.home.com@revelation>; Wed, 18 Jul 2001 12:17:40 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>, <[e-mail]>
Subject: RE: Mandatory to Implement Algorithms in CMS
Date: Wed, 18 Jul 2001 12:17:38 -0700
Message-ID: <000d01c10fbe$4fa375c0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I think that this is a bad idea.  I will counter this by proposing that the
Algorithm document be written in the same vein as the Certificate algorithm
draft.

1.  I would like the basic structures to get to the standard level so that
they are known stable by all entities.  If the algorithms are included in
the document, it is my belief that there will be a regular reset on the
status of this document.

2.  I believe the there should be no MUST implement algorithms for CMS.
This is an issue for the protocol itself to decide not for CMS to decide for
all protocols.  Different protocols will progress on accepting or mandating
new algorithms at different rates (look at how slow TLS has been on adopting
AES).  Thus it is the protocol not the underlying CMS objects that will
mandate what algorithms are to be used.

3.  You shoved this down my throat for Certificates (no manditory
algorithms), so I think you need to accept the consequences of logical
extensions.  If certificates, which may be common across multiple protocols
are not going to have a fixed set of manditory algorithms, why should CMS
based protocols be required to have a manditory set of algorithms.  The CMS
messages are not going to be jumping between protocols except on a very
specific level.  (Use of a CMS based SETI would not have these messages
suddenly appear as S/MIME email messages unless you had SETI specific code
to handle them.)

4.  Toolkits based on CMS are going to have to allow for addition of other
algorithms. This can be seen from the number of documents that have appeared
providing for other algorithms to be used with CMS. (Note that there has not
been any additional algorithms proposed for certificates beyond the EC
versions.)  Protocol specific code is going to be written to the manditory
algorithms while toolkeys must be extensible.

5.  Even if you specify manditory algorithms for CMS, you still have the
problem of dealing with protocols that will say.  Implement CMS, but the
manditory algorithms are X, Y and Z not A, B and C.  Thus providing a
manditory to implement for CMS only buys a small amount of breathing room
for protocols that don't override the manditory algorithms.

jim

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Housley, Russ
> Sent: Tuesday, July 17, 2001 4:25 PM
> To: [e-mail]
> Subject: Re: Mandatory to Implement Algorithms in CMS
>
>
>
> I hoped that there would be considerable discussion on this
> issue.  Maybe I
> need to propose one extreme to get the debate rolling.
>
> I proposed that the protocol and algorithm discussion be
> placed in one
> document.
>
> Russ
>
>
> At 09:13 AM 6/28/2001 -0400, Housley, Russ wrote:
>
> >Dear S/MIME WG:
> >
> >A few weeks ago, Jim Schaad submitted a simple comment on
> >draft-ietf-smime-rfc2630bis-00.  Jim wrote:
> >
> >>2.  I have a sever problem with the following text
> "However, implementations
> >>of the CMS MUST support the mandatory to implement
> algorithms specified in
> >>[CMSALG], or its successor."  It is my believe that this
> statement should be
> >>removed for the following reasons:
> >>
> >>a)  This violates the letter and spirit of the IETF process
> rules for
> >>pushing documents to standards.  In my opinion if this
> becomes a standard
> >>then CMSALG must also be a standard.  Also if CMSALG is
> reset to draft, so
> >>must this draft.  The words "MUST support" is extremely normative.
> >>
> >>b)  If I create a toolkit or other system and publish that
> I am STD [CMS]
> >>conformant.  It does not make sense that by updating the
> set of required
> >>algorithms I loose conformance to that standard.  I was
> compliant, I loose
> >>compliance through no action of mine.  This argues that a
> new standard
> >>number should be applied.
> >>
> >>c)  The reasoning behind not having a MUST for certificates
> is even more
> >>strongly appliciable here.  While certificates and
> heirarchies can move
> >>between different applications (thus making the arugment
> that application
> >>spaces should mandate algorithms a somewhat odd argument),
> that is not the
> >>case with CMS objects.  If S/MIME and CMS/SET were to specificy that
> >>different content encryption algorithms be required, there is no
> >>interactions between the spaces.  An S/MIME message would
> never be consumed
> >>(successfully) by a CMS/SET application nor would one
> expect it to be used.
> >>
> >> From this standpoint I think that not requiring a MUST on
> algorithms from
> >>CMS makes sense.
> >
> >I have discussed this issue with both of the Security Area
> Directors.  Only
> >one thing is clear: we cannot have a MUST statement that references
> >"[CMSALG], or its successor."
> >
> >If we were to achieve Full Standard status with the
> specification that we
> >are working on, then changing the mandatory to implement
> algorithm would
> >reset the status of the updated protocol to Proposed
> Standard.  I expect
> >such a change at some point, probably to change the
> mandatory cipher from
> >Triple-DES CBC to AES CBC.
> >
> >There are other protocols besides S/MIME that are using CMS.
>  If CMS has
> >mandatory to implement algorithms, then many of the
> interoperability issues
> >are handled by a simple reference.  On the other hand, if
> CMS does not
> >include any mandatory to implement algorithms, then each
> reference must
> >specify them.
> >
> >As many of you know, I am arguing for a common set of cryptographic
> >algorithms throughout the IETF Security Area.  Having each
> CMS referee
> >specify their own set of algorithms does not support this objective.
> >
> >What do others think?
> >
> >Russ
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6IJ22E11638 for ietf-smime-bks; Wed, 18 Jul 2001 12:02:02 -0700 (PDT)
Received: from femail3.sdc1.sfba.home.com (femail3.sdc1.sfba.home.com [24.0.95.83]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6IJ21q11632 for <[e-mail]>; Wed, 18 Jul 2001 12:02:01 -0700 (PDT)
Received: from revelation ([65.4.166.11]) by femail3.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010718190158.BMUT21742.femail3.sdc1.sfba.home.com@revelation>; Wed, 18 Jul 2001 12:01:58 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01
Date: Wed, 18 Jul 2001 12:01:57 -0700
Message-ID: <000c01c10fbc$1e9739a0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

It is my opinion that there is no way to handle this for backwards
compatability.  In all likely hood my code will croak upon hitting John's
RecipientInfo in the current world.  This is the reason that we are adding
the requirement to accept new RecipientInfo structures without croaking on
them in the future.

It is my belief that the EnvelopedData version number will no longer need to
be incremented after CMS-bis is published since complient implemenations
will know that there is a hole for adding new RecipientInfo types to the
structure.  Something that might have been implied in the past but was
definitely not explicit.

jim

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Housley, Russ
> Sent: Tuesday, July 17, 2001 4:35 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01
>
>
>
> Peter raises an interesting point here.
>
> Does a change to a subordinate RecipientInfo structure
> necessarily require
> a change to the EnvelopedData version.  Consider the following.
>
> Peter wants to encrypt a message for two recipients, Jim and
> John.  Jim has
> S/MIME v2!  To accomodate Jim, Peter uses RSA PKCS#1 v1.5 key
> transport for
> the 3-DES key.  John has a new widget, so Peter uses it to
> send the same
> 3-DES CEK, but the new widget requires an updated RecipientInfo
> structure.  If the overall EnvelopedData version must be
> updated to handle
> the RecipientInfo for John, then Jim will reject the message,
> even though
> he would be able to parse the portion of the message intended
> for him.  Jim
> has no reason to decode the RecipientInfo intended for John.
>
> What is the best way to handle backward compatibility?
>
> Russ
>
> At 02:37 PM 7/11/2001 +0000, Peter Gutmann wrote:
>
> >"Pawling, John" <[e-mail]> writes:
> >
> > >    [*** NEW ***] version is the syntax version number.  The
> > >    appropriate value depends on originatorInfo, RecipientInfo, and
> > >    unprotectedAttrs.  The version MUST be assigned as follows:
> > >
> > >     IF ((originatorInfo is present) AND
> > >         (any version 2 attribute certificates are present)) OR
> > >         (any RecipientInfo structures are pwri CHOICE) OR
> > >         (any RecipientInfo structures are ori CHOICE)
> > >     THEN version is 3
> > >     ELSE
> > >         IF (originatorInfo is present) OR
> > >            (unprotectedAttrs is present) OR
> > >            (any RecipientInfo structures are a version
> other than 0)
> > >        THEN version is 2
> > >        ELSE version is 0]
> >
> >Didn't we already go through all of this in April?  My
> comment back then was:
> >
> >   If the EnvelopedData version was incremented whenever a new
> > RecipientInfo was
> >   added then it's bad, because adding a single vers.n+1 RI
> to a bunch of
> > vers.n
> >   RIs will change the EnvelopedData version even though
> there are vers.n RIs
> >   there which could be processed (that is, the code could
> still process the
> >   EnvelopedData except that the presence of the vers.n+1
> value for the
> >   EnvelopedData would stop it).  OTOH if the EnvelopedData
> version is only
> >   incremented when the overall structure of the
> EnvelopedData is changed then
> >   it's fine, because it won't try and decode something in a
> completely
> >   different format.
> >
> >Consider what will happen if the scheme you propose is used.
>  If I produce
> >something with RSA and <foo, where foo = some exotic new
> method> key transport
> >and set the syntax version number to anything other than 0,
> existing clients
> >will break.  If I set it to 0 there's at least some chance
> that existing
> >clients will handle it if they see the RSA RI first (that
> is, setting it to 0
> >may or may not work, but setting it to n will definitely
> break an existing
> >client... I think I modified my code at one point to
> specifically emit the
> >original RI's first so that existing apps would see them
> before they saw
> >any of
> >the new types).  In addition if an implementation sees a
> syntax version number
> >of n then that doesn't mean that there isn't version 0 (or whatever)
> >information in there which it can still use.  As a result
> the only behaviour
> >for an implementation which makes much sense is:
> >
> >   - When consuming data, ignore the version number.  Just
> because it's
> > labelled
> >     version 3 doesn't mean there isn't version 0
> information in there
> >     somewhere, which makes the syntax version value meaningless.
> >
> >   - When producing data, call it version 0.  This may or
> may not work with
> >     existing implementations, but it's better than calling
> it version 3
> > which
> >     definitely won't work with existing applications.
> >
> >As I mentioned in my previous post, once implementation developers
> >consider the
> >implications of the syntax version numbers it won't matter
> what the spec says,
> >what will be implemented is what causes the least interop
> problems.  I'll
> >repeat again my previous suggestion that in this area the
> spec codify what
> >implementations are doing rather than forcing arbitrary
> restrictions on them.
> >
> >Peter.
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6IIGV310243 for ietf-smime-bks; Wed, 18 Jul 2001 11:16:31 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6IIGUq10238 for <[e-mail]>; Wed, 18 Jul 2001 11:16:30 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id <PDHZRBNS>; Wed, 18 Jul 2001 14:16:44 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: [e-mail]
Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01
Date: Wed, 18 Jul 2001 14:16:43 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

I believe that the EnvelopedData version number-setting algorithm should be
changed when the
overall structure of the EnvelopedData syntax is changed (such as adding a
new alternative directly to the RecipientInfo CHOICE).  The ori syntax
provides a mechanism for adding support for additional key management
techniques to RecipientInfo without changing the overall structure of the
EnvelopedData syntax.  The EnvelopedData version number will not need to be
changed if new key management techniques are added using ori.  I still
believe that the EnvelopedData version number-setting text that I proposed
in earlier messages is the best solution.

In reference to your example, if the key management information required by
John is included in the ori alternative of the RecipientInfo CHOICE, then I
agree that Jim's receiving S/MIME implementation need not decode the
oriValue if it first finds a ktri alternative of the RecipientInfo CHOICE
for Jim.  However, if the key management information required by John is
included in a new alternative added directly to the RecipientInfo CHOICE,
then I disagree with the notion that all S/MIME implementations can ignore
an unrecognized alternative in a CHOICE. 

You stated: "If the overall EnvelopedData version must be updated to handle
the RecipientInfo for John, then Jim will reject the message,"  I disagree
with the theory that the EnvelopedData version value alone will cause
implementations to reject an EnvelopedData object.  Nobody (except for
Peter) has stated that their implementations rejected an EnvelopedData based
solely on the version value.  The S/MIME Freeware Library will not reject an
object based solely on the
version value.  Typically, the version value is used as part of the process
of trying to determine why an implementation could not successfully process
an EnvelopedData object.

In summary, adding new alternatives directly to the RecipientInfo CHOICE
does not maintain backwards compatibility with previous EnvelopedData
syntaxes.  Using the ori syntax to add support for an additional key
management technique does promote backwards compatibility because it does
not change the overall structure of the EnvelopedData syntax.

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================


-----Original Message-----
From: Housley, Russ [mailto:[e-mail]]
Sent: Tuesday, July 17, 2001 7:35 PM
To: [e-mail]
Cc: [e-mail]
Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01



Peter raises an interesting point here.

Does a change to a subordinate RecipientInfo structure necessarily require 
a change to the EnvelopedData version.  Consider the following.

Peter wants to encrypt a message for two recipients, Jim and John.  Jim has 
S/MIME v2!  To accomodate Jim, Peter uses RSA PKCS#1 v1.5 key transport for 
the 3-DES key.  John has a new widget, so Peter uses it to send the same 
3-DES CEK, but the new widget requires an updated RecipientInfo 
structure.  If the overall EnvelopedData version must be updated to handle 
the RecipientInfo for John, then Jim will reject the message, even though 
he would be able to parse the portion of the message intended for him.  Jim 
has no reason to decode the RecipientInfo intended for John.

What is the best way to handle backward compatibility?

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6ICvZ608022 for ietf-smime-bks; Wed, 18 Jul 2001 05:57:35 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6ICvTq08009 for <[e-mail]>; Wed, 18 Jul 2001 05:57:29 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 18 Jul 2001 12:55:52 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id IAA29864 for <[e-mail]>; Wed, 18 Jul 2001 08:57:23 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <LR8TSPQQ>; Wed, 18 Jul 2001 08:57:19 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.124]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LR8TSPQM; Wed, 18 Jul 2001 08:57:06 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Tue, 17 Jul 2001 19:34:39 -0400
Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter raises an interesting point here.

Does a change to a subordinate RecipientInfo structure necessarily require 
a change to the EnvelopedData version.  Consider the following.

Peter wants to encrypt a message for two recipients, Jim and John.  Jim has 
S/MIME v2!  To accomodate Jim, Peter uses RSA PKCS#1 v1.5 key transport for 
the 3-DES key.  John has a new widget, so Peter uses it to send the same 
3-DES CEK, but the new widget requires an updated RecipientInfo 
structure.  If the overall EnvelopedData version must be updated to handle 
the RecipientInfo for John, then Jim will reject the message, even though 
he would be able to parse the portion of the message intended for him.  Jim 
has no reason to decode the RecipientInfo intended for John.

What is the best way to handle backward compatibility?

Russ

At 02:37 PM 7/11/2001 +0000, Peter Gutmann wrote:

>"Pawling, John" <[e-mail]> writes:
>
> >    [*** NEW ***] version is the syntax version number.  The
> >    appropriate value depends on originatorInfo, RecipientInfo, and
> >    unprotectedAttrs.  The version MUST be assigned as follows:
> >
> >     IF ((originatorInfo is present) AND
> >         (any version 2 attribute certificates are present)) OR
> >         (any RecipientInfo structures are pwri CHOICE) OR
> >         (any RecipientInfo structures are ori CHOICE)
> >     THEN version is 3
> >     ELSE
> >         IF (originatorInfo is present) OR
> >            (unprotectedAttrs is present) OR
> >            (any RecipientInfo structures are a version other than 0)
> >        THEN version is 2
> >        ELSE version is 0]
>
>Didn't we already go through all of this in April?  My comment back then was:
>
>   If the EnvelopedData version was incremented whenever a new 
> RecipientInfo was
>   added then it's bad, because adding a single vers.n+1 RI to a bunch of 
> vers.n
>   RIs will change the EnvelopedData version even though there are vers.n RIs
>   there which could be processed (that is, the code could still process the
>   EnvelopedData except that the presence of the vers.n+1 value for the
>   EnvelopedData would stop it).  OTOH if the EnvelopedData version is only
>   incremented when the overall structure of the EnvelopedData is changed then
>   it's fine, because it won't try and decode something in a completely
>   different format.
>
>Consider what will happen if the scheme you propose is used.  If I produce
>something with RSA and <foo, where foo = some exotic new method> key transport
>and set the syntax version number to anything other than 0, existing clients
>will break.  If I set it to 0 there's at least some chance that existing
>clients will handle it if they see the RSA RI first (that is, setting it to 0
>may or may not work, but setting it to n will definitely break an existing
>client... I think I modified my code at one point to specifically emit the
>original RI's first so that existing apps would see them before they saw 
>any of
>the new types).  In addition if an implementation sees a syntax version number
>of n then that doesn't mean that there isn't version 0 (or whatever)
>information in there which it can still use.  As a result the only behaviour
>for an implementation which makes much sense is:
>
>   - When consuming data, ignore the version number.  Just because it's 
> labelled
>     version 3 doesn't mean there isn't version 0 information in there
>     somewhere, which makes the syntax version value meaningless.
>
>   - When producing data, call it version 0.  This may or may not work with
>     existing implementations, but it's better than calling it version 3 
> which
>     definitely won't work with existing applications.
>
>As I mentioned in my previous post, once implementation developers 
>consider the
>implications of the syntax version numbers it won't matter what the spec says,
>what will be implemented is what causes the least interop problems.  I'll
>repeat again my previous suggestion that in this area the spec codify what
>implementations are doing rather than forcing arbitrary restrictions on them.
>
>Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6ICvNe07992 for ietf-smime-bks; Wed, 18 Jul 2001 05:57:23 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6ICvKq07983 for <[e-mail]>; Wed, 18 Jul 2001 05:57:20 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 18 Jul 2001 12:55:44 UT
Received: from exno01.securitydynamics.com (exno01.securitydynamics.com [10.129.1.41]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id IAA29849 for <[e-mail]>; Wed, 18 Jul 2001 08:57:16 -0400 (EDT)
Received: by exno01.dynas.se with Internet Mail Service (5.5.2653.19) id <MYYQ4CAN>; Wed, 18 Jul 2001 14:57:15 +0200
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.124]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LR8TSPQL; Wed, 18 Jul 2001 08:57:05 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Tue, 17 Jul 2001 19:25:19 -0400
Subject: Re: Mandatory to Implement Algorithms in CMS
In-Reply-To: <[e-mail]. com>
References: <003801c0eece$aaec7230$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I hoped that there would be considerable discussion on this issue.  Maybe I 
need to propose one extreme to get the debate rolling.

I proposed that the protocol and algorithm discussion be placed in one 
document.

Russ


At 09:13 AM 6/28/2001 -0400, Housley, Russ wrote:

>Dear S/MIME WG:
>
>A few weeks ago, Jim Schaad submitted a simple comment on
>draft-ietf-smime-rfc2630bis-00.  Jim wrote:
>
>>2.  I have a sever problem with the following text "However, implementations
>>of the CMS MUST support the mandatory to implement algorithms specified in
>>[CMSALG], or its successor."  It is my believe that this statement should be
>>removed for the following reasons:
>>
>>a)  This violates the letter and spirit of the IETF process rules for
>>pushing documents to standards.  In my opinion if this becomes a standard
>>then CMSALG must also be a standard.  Also if CMSALG is reset to draft, so
>>must this draft.  The words "MUST support" is extremely normative.
>>
>>b)  If I create a toolkit or other system and publish that I am STD [CMS]
>>conformant.  It does not make sense that by updating the set of required
>>algorithms I loose conformance to that standard.  I was compliant, I loose
>>compliance through no action of mine.  This argues that a new standard
>>number should be applied.
>>
>>c)  The reasoning behind not having a MUST for certificates is even more
>>strongly appliciable here.  While certificates and heirarchies can move
>>between different applications (thus making the arugment that application
>>spaces should mandate algorithms a somewhat odd argument), that is not the
>>case with CMS objects.  If S/MIME and CMS/SET were to specificy that
>>different content encryption algorithms be required, there is no
>>interactions between the spaces.  An S/MIME message would never be consumed
>>(successfully) by a CMS/SET application nor would one expect it to be used.
>>
>> From this standpoint I think that not requiring a MUST on algorithms from
>>CMS makes sense.
>
>I have discussed this issue with both of the Security Area Directors.  Only
>one thing is clear: we cannot have a MUST statement that references
>"[CMSALG], or its successor."
>
>If we were to achieve Full Standard status with the specification that we
>are working on, then changing the mandatory to implement algorithm would
>reset the status of the updated protocol to Proposed Standard.  I expect
>such a change at some point, probably to change the mandatory cipher from
>Triple-DES CBC to AES CBC.
>
>There are other protocols besides S/MIME that are using CMS.  If CMS has
>mandatory to implement algorithms, then many of the interoperability issues
>are handled by a simple reference.  On the other hand, if CMS does not
>include any mandatory to implement algorithms, then each reference must
>specify them.
>
>As many of you know, I am arguing for a common set of cryptographic
>algorithms throughout the IETF Security Area.  Having each CMS referee
>specify their own set of algorithms does not support this objective.
>
>What do others think?
>
>Russ


Received: by above.proper.com (8.11.3/8.11.3) id f6I9bJN23328 for ietf-smime-bks; Wed, 18 Jul 2001 02:37:19 -0700 (PDT)
Received: from mail.eris.dera.gov.uk (ns0.eris.dera.gov.uk [128.98.1.1]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6I9bHq23320 for <[e-mail]>; Wed, 18 Jul 2001 02:37:17 -0700 (PDT)
Received: (qmail 15787 invoked from network); 18 Jul 2001 09:37:05 -0000
Received: from cray.eris.dera.gov.uk (HELO mailhost.eris.dera.gov.uk) (128.98.2.7) by ens0.eris.dera.gov.uk with SMTP; 18 Jul 2001 09:37:05 -0000
Received: (qmail 2429 invoked from network); 18 Jul 2001 09:37:04 -0000
Received: from wottaway.eris.dera.gov.uk (HELO WOTTAWAY) (128.98.10.192) by mailhost.eris.dera.gov.uk with SMTP; 18 Jul 2001 09:37:04 -0000
From: "William Ottaway" <[e-mail]>
To: "Rahul Banerjee" <[e-mail]>, "Nagaraj Mandya" <[e-mail]>, <[e-mail]>
Subject: RE: Signing on behalf of somebody else
Date: Wed, 18 Jul 2001 10:40:55 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Importance: Normal
In-Reply-To: <01f301c10f6c$703dfdc0$4201a8c0@blueeighteen>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Rahul,

DOMSEC also allows for another person to sign a message, as in the case when
you have a release authority. This could be an individual who verifies that
the message can be released.

Bill.

> -----Original Message-----
> From: Rahul Banerjee [mailto:[e-mail]]
> Sent: 18 July 2001 10:32
> To: William Ottaway; Nagaraj Mandya; [e-mail]
> Subject: Re: Signing on behalf of somebody else
>
>
> Hi,
>
> A Company-specific signature is definitely acceptable. I guess, Nagraj's
> question related to signing on behalf of another individual  ----
> and, this
> had security implications.
>
> Regards.
>
> Rahul
> ----- Original Message -----
> From: "William Ottaway" <[e-mail]>
> To: "Nagaraj Mandya" <[e-mail]>; <[e-mail]>
> Sent: Wednesday, July 18, 2001 01:40 PM
> Subject: RE: Signing on behalf of somebody else
>
>
> >
> > Hi Nagaraj,
> >
> > Have you looked at the DOMSEC draft?
> > http://www.ietf.org/internet-drafts/draft-ietf-smime-domsec-08.txt
> >
> > It allows for others to sign a message. It also specifies a
> domain/company
> > signature. A valid company signature means the message can be accepted
> > irrespective of whether there is an originator signature or not.
> >
> > Bill.
> >
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]]On Behalf Of Nagaraj Mandya
> > > Sent: 18 July 2001 05:13
> > > To: [e-mail]
> > > Subject: Signing on behalf of somebody else
> > >
> > >
> > >
> > > Hi,
> > >    Is it possible for a mail being sent by one person
> > > be signed by a different person and still be treated
> > > as a valid signature?
> > >
> > >    My problem is like this. Any mail that a client
> > > receives signed by a particular person's certificate
> > > should be considered valid by the client irrespective
> > > of who the actual sender is.
> > >
> > >    Thanks.
> > > --
> > > Regards,
> > > Nagaraj
> > >
> > > ____________________________________________________________
> > > Do You Yahoo!?
> > > For regular News updates go to http://in.news.yahoo.com
> >
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6I9Vxo22839 for ietf-smime-bks; Wed, 18 Jul 2001 02:31:59 -0700 (PDT)
Received: from asura.bits-pilani.ac.in (IDENT:root@[202.54.26.114]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6I9Vuq22833 for <[e-mail]>; Wed, 18 Jul 2001 02:31:56 -0700 (PDT)
Received: from blueeighteen (devil.bits-pilani.ac.in [202.54.26.125]) by asura.bits-pilani.ac.in (8.9.3/8.9.3) with SMTP id PAA10543; Wed, 18 Jul 2001 15:01:01 +0530
Message-ID: <01f301c10f6c$703dfdc0$4201a8c0@blueeighteen>
From: "Rahul Banerjee" <[e-mail]>
To: "William Ottaway" <[e-mail]>, "Nagaraj Mandya" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Signing on behalf of somebody else
Date: Wed, 18 Jul 2001 15:01:35 +0530
Organization: BITS, Pilan (India)
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

A Company-specific signature is definitely acceptable. I guess, Nagraj's
question related to signing on behalf of another individual  ---- and, this
had security implications.

Regards.

Rahul
----- Original Message -----
From: "William Ottaway" <[e-mail]>
To: "Nagaraj Mandya" <[e-mail]>; <[e-mail]>
Sent: Wednesday, July 18, 2001 01:40 PM
Subject: RE: Signing on behalf of somebody else


>
> Hi Nagaraj,
>
> Have you looked at the DOMSEC draft?
> http://www.ietf.org/internet-drafts/draft-ietf-smime-domsec-08.txt
>
> It allows for others to sign a message. It also specifies a domain/company
> signature. A valid company signature means the message can be accepted
> irrespective of whether there is an originator signature or not.
>
> Bill.
>
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]On Behalf Of Nagaraj Mandya
> > Sent: 18 July 2001 05:13
> > To: [e-mail]
> > Subject: Signing on behalf of somebody else
> >
> >
> >
> > Hi,
> >    Is it possible for a mail being sent by one person
> > be signed by a different person and still be treated
> > as a valid signature?
> >
> >    My problem is like this. Any mail that a client
> > receives signed by a particular person's certificate
> > should be considered valid by the client irrespective
> > of who the actual sender is.
> >
> >    Thanks.
> > --
> > Regards,
> > Nagaraj
> >
> > ____________________________________________________________
> > Do You Yahoo!?
> > For regular News updates go to http://in.news.yahoo.com
>



Received: by above.proper.com (8.11.3/8.11.3) id f6I8SI918671 for ietf-smime-bks; Wed, 18 Jul 2001 01:28:18 -0700 (PDT)
Received: from gateway.secude.com (linux.secude.com [141.12.207.27]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6I8SHq18666 for <[e-mail]>; Wed, 18 Jul 2001 01:28:17 -0700 (PDT)
Received: from remus.secude.com (remus.intranet.secude.com [192.168.2.2]) by gateway.secude.com (Postfix) with ESMTP id 559629592; Wed, 18 Jul 2001 10:28:37 +0200 (CEST)
Received: by remus.intranet.secude.com with Internet Mail Service (5.5.2653.19) id <3L2MAF9C>; Wed, 18 Jul 2001 10:32:35 +0200
Message-ID: <[e-mail]>
From: Jorg Beermann <[e-mail]>
To: "'Chung, KwonSung'" <[e-mail]>
Cc: [e-mail]
Subject: Re: simple question (for SMIME enveloped message)
Date: Wed, 18 Jul 2001 10:32:33 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="ks_c_5601-1987"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,
as input for a S/MIME enveloped message 
can be used any MIME entity, 
a whole message or just a BodyPart.
...if I understood your question right.

Joerg



-----Ursprungliche Nachricht-----
Von: Chung, KwonSung [mailto:[e-mail]]
Gesendet: Mittwoch, 18. Juli 2001 09:54
An: [e-mail]
Betreff: simple question (for SMIME enveloped message)



Hello Mr./Miz.,

I have tried to generate S/MIME enveloped message.

But I don't know what is the input of the encryption-process.

Can only plaintext string be used as the input ?

If not, what must be used ?

Please let me know about it.  Thank you.


Kwonsung



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6I86lb15816 for ietf-smime-bks; Wed, 18 Jul 2001 01:06:47 -0700 (PDT)
Received: from mail.eris.dera.gov.uk (ns0.eris.dera.gov.uk [128.98.1.1]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6I86iq15812 for <[e-mail]>; Wed, 18 Jul 2001 01:06:45 -0700 (PDT)
Received: (qmail 13551 invoked from network); 18 Jul 2001 08:06:31 -0000
Received: from cray.eris.dera.gov.uk (HELO mailhost.eris.dera.gov.uk) (128.98.2.7) by ens0.eris.dera.gov.uk with SMTP; 18 Jul 2001 08:06:31 -0000
Received: (qmail 675 invoked from network); 18 Jul 2001 08:06:31 -0000
Received: from wottaway.eris.dera.gov.uk (HELO WOTTAWAY) (128.98.10.192) by mailhost.eris.dera.gov.uk with SMTP; 18 Jul 2001 08:06:30 -0000
From: "William Ottaway" <[e-mail]>
To: "Nagaraj Mandya" <[e-mail]>, <[e-mail]>
Subject: RE: Signing on behalf of somebody else
Date: Wed, 18 Jul 2001 09:10:22 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Nagaraj,

Have you looked at the DOMSEC draft?
http://www.ietf.org/internet-drafts/draft-ietf-smime-domsec-08.txt

It allows for others to sign a message. It also specifies a domain/company
signature. A valid company signature means the message can be accepted
irrespective of whether there is an originator signature or not.

Bill.

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Nagaraj Mandya
> Sent: 18 July 2001 05:13
> To: [e-mail]
> Subject: Signing on behalf of somebody else
>
>
>
> Hi,
>    Is it possible for a mail being sent by one person
> be signed by a different person and still be treated
> as a valid signature?
>
>    My problem is like this. Any mail that a client
> receives signed by a particular person's certificate
> should be considered valid by the client irrespective
> of who the actual sender is.
>
>    Thanks.
> --
> Regards,
> Nagaraj
>
> ____________________________________________________________
> Do You Yahoo!?
> For regular News updates go to http://in.news.yahoo.com



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6I7sEX14458 for ietf-smime-bks; Wed, 18 Jul 2001 00:54:14 -0700 (PDT)
Received: from bcqre.com ([211.177.183.253]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6I7sBq14454 for <[e-mail]>; Wed, 18 Jul 2001 00:54:11 -0700 (PDT)
Received: from bcqre.com ([192.168.13.157]) by bcqre.com (8.11.0/8.11.0) with ESMTP id f6I7gQG17702 for <[e-mail]>; Wed, 18 Jul 2001 16:42:26 +0900
Message-ID: <[e-mail]>
Date: Wed, 18 Jul 2001 16:54:00 +0900
From: "Chung, KwonSung" <[e-mail]>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: simple question (for SMIME enveloped message)
Content-Type: text/plain; charset=EUC-KR
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello Mr./Miz.,

I have tried to generate S/MIME enveloped message.

But I don't know what is the input of the encryption-process.

Can only plaintext string be used as the input ?

If not, what must be used ?

Please let me know about it.  Thank you.


Kwonsung




Received: by above.proper.com (8.11.3/8.11.3) id f6I724W08185 for ietf-smime-bks; Wed, 18 Jul 2001 00:02:04 -0700 (PDT)
Received: from asura.bits-pilani.ac.in (IDENT:root@[202.54.26.114]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6I71cq08075 for <[e-mail]>; Wed, 18 Jul 2001 00:01:40 -0700 (PDT)
Received: from blueeighteen (devil.bits-pilani.ac.in [202.54.26.125]) by asura.bits-pilani.ac.in (8.9.3/8.9.3) with SMTP id MAA04994; Wed, 18 Jul 2001 12:30:56 +0530
Message-ID: <011501c10f57$7885ca90$4201a8c0@blueeighteen>
From: "Rahul Banerjee" <[e-mail]>
To: "Nagaraj Mandya" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Signing on behalf of somebody else
Date: Wed, 18 Jul 2001 12:31:30 +0530
Organization: BITS, Pilan (India)
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

IMHO, asking for this feature would probably defy the very reason of this
security provision.

Regards.

Rahul

----- Original Message -----
From: "Nagaraj Mandya" <[e-mail]>
To: <[e-mail]>
Sent: Wednesday, July 18, 2001 09:43 AM
Subject: Signing on behalf of somebody else


>
> Hi,
>    Is it possible for a mail being sent by one person
> be signed by a different person and still be treated
> as a valid signature?
>
>    My problem is like this. Any mail that a client
> receives signed by a particular person's certificate
> should be considered valid by the client irrespective
> of who the actual sender is.
>
>    Thanks.
> --
> Regards,
> Nagaraj
>
> ____________________________________________________________
> Do You Yahoo!?
> For regular News updates go to http://in.news.yahoo.com
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6I4DKr23540 for ietf-smime-bks; Tue, 17 Jul 2001 21:13:20 -0700 (PDT)
Received: from web8003.mail.in.yahoo.com ([203.199.70.21]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6I4DIq23536 for <[e-mail]>; Tue, 17 Jul 2001 21:13:19 -0700 (PDT)
Message-ID: <[e-mail]>
Received: from [202.144.91.253] by web8003.mail.in.yahoo.com via HTTP; Wed, 18 Jul 2001 05:13:11 BST
Date: Wed, 18 Jul 2001 05:13:11 +0100 (BST)
From: =?iso-8859-1?q?Nagaraj=20Mandya?= <[e-mail]>
Subject: Signing on behalf of somebody else
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,
   Is it possible for a mail being sent by one person
be signed by a different person and still be treated
as a valid signature?

   My problem is like this. Any mail that a client
receives signed by a particular person's certificate
should be considered valid by the client irrespective
of who the actual sender is.

   Thanks.
--
Regards,
Nagaraj

____________________________________________________________
Do You Yahoo!?
For regular News updates go to http://in.news.yahoo.com


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6HKVgZ13242 for ietf-smime-bks; Tue, 17 Jul 2001 13:31:42 -0700 (PDT)
Received: from btclick.com (mta02.btfusion.com [62.172.195.247]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6HKVZq13237 for <[e-mail]>; Tue, 17 Jul 2001 13:31:35 -0700 (PDT)
Received: from NPVAIOLAPTOP ([213.121.96.167]) by btclick.com (Netscape Messaging Server 4.05) with ESMTP id GGMX0E02.GDQ; Tue, 17 Jul 2001 21:31:26 +0100 
From: "Nick Pope" <[e-mail]>
To: <[e-mail]>
Subject: ETSI Draft Time-stamping Policy - comments requested
Date: Tue, 17 Jul 2001 21:27:48 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Request for comments on draft ETSI standard:
"POLICY REQUIREMENTS FOR TIME-STAMPING AUTHORITIES"

The ETSI Electronic Signatures Infrastructure Working Group has drafted a
standard which specifies policy requirements on the operation and management
practices of Time-Stamping Authorities such that subscribers and relying
parties may have confidence in the operation of its time-stamp services.

This draft specification is being made publicly available for review and
comment by any company or organisation with interest in this area.  A copy
can be obtained through the ETSI El Sign web site (see below).

Comments are requested by 7th September.

Background

The development of this standard policy document is one of the tasks the
ETSI Electronic Signature and Infrastructure Working Group is progressing
within the European Electronic Signature Standardisation Initiative (EESSI).
The ETSI El Sign Web-site (see below) provides further information about the
ETSI activities and the EESSI program.

Requested action.

Please send your comments and suggestions not later than 15 September to the
ETSI El Sign e-mail list [e-mail], with copy to the editor on
[e-mail].   Please put "TSA-Pol" at the front of the Subject field
of
all submissions to the e-mail list on this topic.

To register with the EL-SIGN list and download the draft document
(STF178Task1Draft.pdf) see:

http://www.etsi.org/sec/el-sign.htm

The purpose of the open e-mail list is to stimulate discussion of the
published comments and contributions. Therefore, early submissions are
welcome. We expect that discussions will go on through the open e-mail list
under and after the comments period.


With regards

Nick Pope, Security & Standards
Editor - Policy Requirements for Time-stamping Authorities
[e-mail]

and

György Endersz, Telia Research AB
Chair ETSI ESI Working Group
[e-mail]







Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6HGx8f08179 for ietf-smime-bks; Tue, 17 Jul 2001 09:59:08 -0700 (PDT)
Received: from nebula.x509.com (nebula.x509.com [199.175.150.19]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6HGx6q08174 for <[e-mail]>; Tue, 17 Jul 2001 09:59:06 -0700 (PDT)
Received: from crack.x509.com (mail.x509.com [199.175.150.1]) by nebula.x509.com (8.11.3/XCERT) with ESMTP id f6HGx1u03123 for <[e-mail]>; Tue, 17 Jul 2001 09:59:01 -0700 (PDT)
Received: from exvan01.x509.com (exvan01.x509.com [10.9.22.50]) by crack.x509.com (8.11.3/XCERT) with ESMTP id f6HGx0U04169 for <[e-mail]>; Tue, 17 Jul 2001 09:59:01 -0700 (PDT)
Received: by exvan01.x509.com with Internet Mail Service (5.5.2653.19) id <N4LJSWYS>; Tue, 17 Jul 2001 09:59:52 -0700
Received: from HOUSLEY-LAP.rsasecurity.com (housley-lap.securitydynamics.com [10.100.23.218]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LR8TSF91; Tue, 17 Jul 2001 12:58:50 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Mon, 16 Jul 2001 18:48:13 -0400
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: London Agenda
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear S/MIME WG:

Here is the agenda that I have for the two-hours session in London.
Please send corrections ASAP.

Russ

= = = = = = = = = =

Introductions				Russ Housley
Working Group Status			Russ Housley
Interoperability Matrix 			Jim Schaad
CMS and ESS Examples 			Paul Hoffman
Updates to CMS				Russ Housley
Updates to CERT & MSG		Blake Ramsdell
Symmetric Key Distribution		Sean Turner
X.400 and CMS				Chris Bonatti
Reuse of Content Encryption Keys	Steve Farrell
AES and RSA-OAEP			Jim Schaad
Elliptic Curve Crypto			Simon Blake-Wilson
XML Electronic Signature Syntax	John Ross
CSP and Time Stamps			Denis Pinkas
NIST S/MIME Activities			Mike Chernick
S/MIME Freeware Library [*]		Rich Nicholas
Wrap up					Russ Housley

[*] = If time permits


Received: by above.proper.com (8.11.3/8.11.3) id f6FDvZw23844 for ietf-smime-bks; Sun, 15 Jul 2001 06:57:35 -0700 (PDT)
Received: from c015.sfo.cp.net (c015-h006.c015.sfo.cp.net [209.228.12.120]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6FDvWq23834 for <[e-mail]>; Sun, 15 Jul 2001 06:57:32 -0700 (PDT)
Received: (cpmta 10431 invoked from network); 15 Jul 2001 06:57:26 -0700
Received: from unknown (HELO BONATTIOMNI) (166.142.144.242) by smtp.omnisky.net (209.228.12.120) with SMTP; 15 Jul 2001 06:57:26 -0700
X-Sent: 15 Jul 2001 13:57:26 GMT
Reply-To: <[e-mail]>
From: "Bonatti, Chris" <[e-mail]>
To: "Paul Hoffman / IMC" <[e-mail]>, <[e-mail]>
Subject: RE: New x400wrap I-D? (was RE: SMIME-TYPE question)
Date: Sun, 15 Jul 2001 09:57:24 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-reply-to: <p05100326b77139b5e28f@[165.227.249.20]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

My apologies.  As one of the editors taking some time, I have to admit that
I've been out of town for a couple of days and have gotten a little behind.
I'm using the weekend to catch up.  I've been through Jim's recent comments,
and just have to draft a little bit of text now.

Chris


-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Paul Hoffman / IMC
Sent: Tuesday, July 10, 2001 19:03
To: [e-mail]
Subject: RE: New x400wrap I-D? (was RE: SMIME-TYPE question)



At 3:41 PM -0700 7/10/01, Musy Michel-P28089 wrote:
>John,
>
>Will this new version of the x400wrap document be posted this week and
>advertised in the working groups?

John is not an editor of the document. I announced earlier this week
that a new draft would be out very soon. I now have to amend that
statement, or at least bend the definition of "soon". The
ever-watchful Jim Schaad has asked some very good questions, and it
is going to take some time for the editors to respond. This week if
we are lucky, next week is more likely.

--Paul Hoffman, Director
--Internet Mail Consortium



Received: by above.proper.com (8.11.3/8.11.3) id f6CEm3B22975 for ietf-smime-bks; Thu, 12 Jul 2001 07:48:03 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6CEm0m22965 for <[e-mail]>; Thu, 12 Jul 2001 07:48:00 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 12 Jul 2001 14:46:30 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA28667; Wed, 11 Jul 2001 09:04:36 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <LR8TQDT9>; Wed, 11 Jul 2001 09:04:33 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.38]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LR8TQDT8; Wed, 11 Jul 2001 09:04:30 -0400
From: "Housley, Russ" <[e-mail]>
To: Musy Michel-P28089 <[e-mail]>
Cc: "Pawling, John" <[e-mail]>, "SMIME WG (E-mail)" <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Wed, 11 Jul 2001 09:04:29 -0400
Subject: RE: New x400wrap I-D? (was RE: SMIME-TYPE question)
In-Reply-To: <[e-mail] .com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Yes.

At 03:41 PM 7/10/2001 -0700, Musy Michel-P28089 wrote:
>Will this new version of the x400wrap document be posted this week and
>advertised in the working groups?


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6CEbVX22586 for ietf-smime-bks; Thu, 12 Jul 2001 07:37:31 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6CEbTm22581 for <[e-mail]>; Thu, 12 Jul 2001 07:37:29 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 12 Jul 2001 14:36:00 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA06574 for <[e-mail]>; Wed, 11 Jul 2001 16:24:07 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <LR8TQL18>; Wed, 11 Jul 2001 16:24:02 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.70]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LR8TQL15; Wed, 11 Jul 2001 16:23:59 -0400
From: "Housley, Russ" <[e-mail]>
To: "Pawling, John" <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Wed, 11 Jul 2001 16:12:29 -0400
Subject: RE: Comments: draft-ietf-smime-rfc2630bis-00
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

John:

>25) Section 6.2.1, para "rid":  Please change "support one at least of these
>alternatives." to  "support at least one of these alternatives."

Done.

>29) Section 6.3, para 2:  You want to preserve the following sentence: "The
>input to the content-encryption process is the "value" of the content being
>enveloped."  In my opinion, this sentence is not needed and is confusing.
>For example, when encrypting an ASN.1 encoded content, an implementer might
>interpret this statement to mean that the tag and length octets of the ASN.1
>encoded content should not be encrypted.  I still believe that the first
>paragraph is fine (as is included in draft-ietf-smime-rfc2630bis-01) and
>that the second paragraph should be deleted.

Here is the text that I have in the yet-to-be-published -02 draft.

6.3  Content-encryption Process

    The content-encryption key for the desired content-encryption
    algorithm is randomly generated.  The input to the content-encryption
    process is the "value" of the content being enveloped.  This input
    data is padded as described below, then the padded data is encrypted
    using the content-encryption key.  The encryption operation maps an
    arbitrary string of octets (the data) to another string of octets
    (the ciphertext) under control of a content-encryption key.  The
    encrypted data is included in the envelopedData encryptedContentInfo
    encryptedContent OCTET STRING.

    Some content-encryption algorithms assume the input length is a
    multiple of k octets, where k is greater than one.  For such
    algorithms, the input shall be padded at the trailing end with
    k-(lth mod k) octets all having value k-(lth mod k), where lth is
    the length of the input.  In other words, the input is padded at
    the trailing end with one of the following strings:

                      01 -- if lth mod k = k-1
                   02 02 -- if lth mod k = k-2
                       .
                       .
                       .
             k k ... k k -- if lth mod k = 0

    The padding can be removed unambiguously since all input is padded,
    including input values that are already a multiple of the block size,
    and no padding string is a suffix of another.  This padding method is
    well defined if and only if k is less than 256.

Are you happy with this text?  If not, I suspect your concerns are in the 
1st paragraph, not the 2nd one.

>36) countersignatures: Also, please change Section 5.4, para 2, as follows:
>
>OLD: "The content type attribute is not required when used as part of a
>countersignature unsigned attribute as defined in section 11.4."
>
>NEW: "The content-type attribute MUST NOT be used as part of a
>countersignature unsigned attribute as defined in section 11.4."

Done.

Russ


Received: by above.proper.com (8.11.3/8.11.3) id f6CEbVP22585 for ietf-smime-bks; Thu, 12 Jul 2001 07:37:31 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6CEbSm22577 for <[e-mail]>; Thu, 12 Jul 2001 07:37:28 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 12 Jul 2001 14:35:59 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA09361 for <[e-mail]>; Wed, 11 Jul 2001 16:58:24 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <LR8TQLWT>; Wed, 11 Jul 2001 16:58:21 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.70]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LR8TQLWS; Wed, 11 Jul 2001 16:58:17 -0400
From: "Housley, Russ" <[e-mail]>
To: "Pawling, John" <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Wed, 11 Jul 2001 16:58:11 -0400
Subject: RE: Comments: draft-ietf-smime-rfc2630bis-00
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

John:

>I would prefer to see Section 6.3, paragraph 1, as follows:
>
>     The content-encryption key for the desired content-encryption
>     algorithm is randomly generated.  The data to be protected
>     is padded as described below, then the padded data is encrypted
>     using the content-encryption key.  The encryption operation maps an
>     arbitrary string of octets (the data) to another string of octets
>     (the ciphertext) under control of a content-encryption key.  The
>     encrypted data is included in the envelopedData encryptedContentInfo
>     encryptedContent OCTET STRING.

Done.

I recall the addition of the sentence we just removed.  It was added to 
avoid confusion about which octets are encrypted.  I guess that the 
sentence did not add clarity.

Russ



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6BKgYj06878 for ietf-smime-bks; Wed, 11 Jul 2001 13:42:34 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6BKfDm06845 for <[e-mail]>; Wed, 11 Jul 2001 13:41:14 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id <KZJ99YJS>; Wed, 11 Jul 2001 16:41:28 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Comments: draft-ietf-smime-rfc2630bis-00
Date: Wed, 11 Jul 2001 16:41:26 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

I would prefer to see Section 6.3, paragraph 1, as follows:
 
    The content-encryption key for the desired content-encryption
    algorithm is randomly generated.  The data to be protected 
    is padded as described below, then the padded data is encrypted
    using the content-encryption key.  The encryption operation maps an
    arbitrary string of octets (the data) to another string of octets
    (the ciphertext) under control of a content-encryption key.  The
    encrypted data is included in the envelopedData encryptedContentInfo
    encryptedContent OCTET STRING.

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================


Received: by above.proper.com (8.11.3/8.11.3) id f6BHlAw00650 for ietf-smime-bks; Wed, 11 Jul 2001 10:47:10 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6BHl9m00646 for <[e-mail]>; Wed, 11 Jul 2001 10:47:09 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id <KZJ99W45>; Wed, 11 Jul 2001 13:47:24 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: [e-mail]
Subject: RE: Key Wrap Algorithms
Date: Wed, 11 Jul 2001 13:47:17 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

I agree that the cmsalg spec should state that "CMS implementations MUST
include Triple-DES key-   encryption keys wrapping Triple-DES
content-encryption keys."

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================



Received: by above.proper.com (8.11.3/8.11.3) id f6BH3ET29049 for ietf-smime-bks; Wed, 11 Jul 2001 10:03:14 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6BH3Dm29043 for <[e-mail]>; Wed, 11 Jul 2001 10:03:14 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id <KZJ99WHS>; Wed, 11 Jul 2001 13:03:28 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: [e-mail]
Subject: RE: Jim's Comments: draft-ietf-smime-cmsalg-00
Date: Wed, 11 Jul 2001 13:03:24 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ/Jim,

I agree with "Implementations SHOULD generate SHA-1 AlgorithmIdentifiers as
absent".

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================


Received: by above.proper.com (8.11.3/8.11.3) id f6BG7VA27312 for ietf-smime-bks; Wed, 11 Jul 2001 09:07:31 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6BG6Am27255 for <[e-mail]>; Wed, 11 Jul 2001 09:06:10 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id <KZJ99VZW>; Wed, 11 Jul 2001 12:06:25 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01
Date: Wed, 11 Jul 2001 12:06:20 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

I agree with your counter-proposals.

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================

-----Original Message-----
From: Housley, Russ [mailto:[e-mail]]
Sent: Tuesday, July 10, 2001 11:31 AM
To: Pawling, John
Cc: [e-mail]
Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01


John:

>Regarding Jim's comment 7: In previous messages, I proposed changes to the
>Section 6.1, EnvelopedData version-setting algorithm that address your
>comments.  I repeated the proposal today in my reply to Peter Gutmann's
>message sent to the S/MIME mail list.
>
>Regarding Jim's comment 11: In a previous reply to Jim (which he concurred
>with), I proposed the following:
>
>[John: I agree that a non-match is a critical security error.  Propose that
>the following sentence be added to Section 5.6 Message Signature
>Verification Process as the last paragraph:  "If the signedData signerInfo
>includes signedAttributes and the content-type attribute value is different
>from the signedData encapContentInfo eContentType value, then the CMS
>implementation MUST report an error."

How about an additional paragraph that says:  "If the SignedData signerInfo 
includes signedAttributes, then the content-type attribute value MUST match 
the SignedData encapContentInfo eContentType value."

>Propose that the following sentence be added to Section 9.3 MAC
Verification
>as the last paragraph:  "If the authenticatedData includes
>authenticatedAttributes and the content-type attribute value is different
>from the authenticatedData encapContentInfo eContentType value, then the
CMS
>implementation MUST report an error."]

To be parrallel, I propose a new paragraph in section 9.3 that says: "If 
the AuthenticatedData includes authenticatedAttributes, then the 
content-type attribute value MUST match the AuthenticatedData 
encapContentInfo eContentType value."

Russ


Received: by above.proper.com (8.11.3/8.11.3) id f6BFToS22465 for ietf-smime-bks; Wed, 11 Jul 2001 08:29:50 -0700 (PDT)
Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6BFTmm22456 for <[e-mail]>; Wed, 11 Jul 2001 08:29:48 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id DAA29899; Thu, 12 Jul 2001 03:29:46 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <99486538625526>; Thu, 12 Jul 2001 03:29:46 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Thu, 12 Jul 2001 03:29:46 (NZST)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Pawling, John" <[e-mail]> writes:

>When we had this discussion in April, nobody (except for you) stated that
>their implementations rejected an EnvelopedData based solely on the version
>value.

Actually there were only two bits of code surveyed, the SFL and my code, which
have completely different interpretations of how to handle the version number
issue.  It could be that both of our views are wrong, and that everyone else
does something different again.  I'd like to see some comments from other
implementors on what their code will do when it finds an unexpected version
number in the EnvelopedData.

NB: Quietly changing your code, then reporting what the updated code does, is
    cheating :-).

Peter.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6BF6ES20718 for ietf-smime-bks; Wed, 11 Jul 2001 08:06:14 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6BF6Dm20714 for <[e-mail]>; Wed, 11 Jul 2001 08:06:13 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id <KZJ99VH5>; Wed, 11 Jul 2001 11:06:28 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: [e-mail]
Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01
Date: Wed, 11 Jul 2001 11:06:24 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

My comments are in-line.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Wednesday, July 11, 2001 10:38 AM
To: [e-mail]; [e-mail]
Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01

<snip>

Didn't we already go through all of this in April? My comment back then was:

  If the EnvelopedData version was incremented whenever a new RecipientInfo
was
  added then it's bad, 

[John: That is not what I am proposing.  I am proposing that the
EnvelopedData version number-setting algorithm should be changed because the
overall structure of the EnvelopedData syntax is being changed due to the
addition of the pwri and ori alternatives to RecipientInfo; and due to the
addition of the 2000 X.509 Attribute Certificate syntax to OriginatorInfo.
The ori syntax provides a mechanism for adding support for additional key
management techniques to RecipientInfo without changing the overall
structure of the EnvelopedData syntax.  The EnvelopedData version number
will not need to be changed if new key management techniques are added using
ori.] 

  because adding a single vers.n+1 RI to a bunch of vers.n
  RIs will change the EnvelopedData version even though there are vers.n RIs
  there which could be processed (that is, the code could still process the
  EnvelopedData except that the presence of the vers.n+1 value for the
  EnvelopedData would stop it). 

[John: I disagree with your statement that the EnvelopedData version number
value alone will cause implementations to reject an EnvelopedData.  When we
had this discussion in April, nobody (except for you) stated that their
implementations rejected an EnvelopedData based solely on the version value.
The S/MIME Freeware Library will not reject an object based solely on the
version value.  Typically, the version value is used as part of the process
of trying to determine why an implementation could not successfully process
an EnvelopedData object.] 

 OTOH if the EnvelopedData version is only
  incremented when the overall structure of the EnvelopedData is changed
then
  it's fine, because it won't try and decode something in a completely
  different format.

[John: The overall structure of the EnvelopedData is being changed.]

Consider what will happen if the scheme you propose is used.  If I produce
something with RSA and <foo, where foo = some exotic new method> key
transport
and set the syntax version number to anything other than 0, existing clients
will break.  

[John: I disagree with your statement that the EnvelopedData version number
value alone will cause implementations to reject an EnvelopedData.] 

If I set it to 0 there's at least some chance that existing
clients will handle it if they see the RSA RI first (that is, setting it to
0
may or may not work, but setting it to n will definitely break an existing
client...I think I modified my code at one point to specifically emit the
original RI's first so that existing apps would see them before they saw any
of
the new types).  In addition if an implementation sees a syntax version
number
of n then that doesn't mean that there isn't version 0 (or whatever)
information in there which it can still use.  As a result the only behaviour
for an implementation which makes much sense is:

  - When consuming data, ignore the version number.  Just because it's
labelled
    version 3 doesn't mean there isn't version 0 information in there
    somewhere, which makes the syntax version value meaningless.

[John: I disagree.  The version value is used as part of the process of
trying to determine why an implementation could not successfully process an
EnvelopedData object.]

  - When producing data, call it version 0.  This may or may not work with
    existing implementations, but it's better than calling it version 3
which 
    definitely won't work with existing applications.

[John: I disagree with your statement that the EnvelopedData version number
value alone will cause implementations to reject an EnvelopedData.] 

As I mentioned in my previous post, once implementation developers consider
the
implications of the syntax version numbers it won't matter what the spec
says,
what will be implemented is what causes the least interop problems.  I'll
repeat again my previous suggestion that in this area the spec codify what
implementations are doing rather than forcing arbitrary restrictions on
them.

[John: I believe that most implementations will not reject an EnvelopedData
based solely on the version number value, so I believe that my proposal does
not force arbitrary restrictions on them.]

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6B34NA13528 for ietf-smime-bks; Tue, 10 Jul 2001 20:04:23 -0700 (PDT)
Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6B331m13512 for <[e-mail]>; Tue, 10 Jul 2001 20:03:01 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id PAA01847; Wed, 11 Jul 2001 15:02:52 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <99482057224494>; Wed, 11 Jul 2001 15:02:52 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: RE: Jim's Comments: draft-ietf-smime-cmsalg-00
Cc: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Wed, 11 Jul 2001 15:02:52 (NZST)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Jim Schaad" <[e-mail]> writes:

>If this is the preferred encoding, it is certianly not displayed as such in
>the current text.  If you really think that is true then we need to make the
>following change:
>
>"Implementations SHOULD generate SHA-1 AlgorithmIdentifiers as absent".

Wouldn't it be better to just include the historical note about
AlgorithmIdentifier parameters and let implementors decide on what to do?
Telling people why it's the way it is would help reduce a lot of confusion when
implementors who aren't aware of this piece of ASN.1 trivia find both forms in
use, in my drafts I've included the correct (or more precisely currently
fashionable) form, but with a note to say that people should be prepared to
encounter the other alternative (I'm happy with SHOULD, I'd just like to see a
caveat included so that every new implementor who comes along doesn't fall into
the same trap).

Peter.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6B2ba413167 for ietf-smime-bks; Tue, 10 Jul 2001 19:37:36 -0700 (PDT)
Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6B2bYm13163 for <[e-mail]>; Tue, 10 Jul 2001 19:37:34 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id OAA32668; Wed, 11 Jul 2001 14:37:35 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <99481905424341>; Wed, 11 Jul 2001 14:37:34 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Wed, 11 Jul 2001 14:37:34 (NZST)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Pawling, John" <[e-mail]> writes:

>    [*** NEW ***] version is the syntax version number.  The
>    appropriate value depends on originatorInfo, RecipientInfo, and
>    unprotectedAttrs.  The version MUST be assigned as follows:
>
>     IF ((originatorInfo is present) AND
>         (any version 2 attribute certificates are present)) OR
>         (any RecipientInfo structures are pwri CHOICE) OR
>         (any RecipientInfo structures are ori CHOICE)
>     THEN version is 3
>     ELSE
>         IF (originatorInfo is present) OR
>            (unprotectedAttrs is present) OR
>            (any RecipientInfo structures are a version other than 0)
>        THEN version is 2
>        ELSE version is 0]

Didn't we already go through all of this in April?  My comment back then was:

  If the EnvelopedData version was incremented whenever a new RecipientInfo was
  added then it's bad, because adding a single vers.n+1 RI to a bunch of vers.n
  RIs will change the EnvelopedData version even though there are vers.n RIs
  there which could be processed (that is, the code could still process the
  EnvelopedData except that the presence of the vers.n+1 value for the
  EnvelopedData would stop it).  OTOH if the EnvelopedData version is only
  incremented when the overall structure of the EnvelopedData is changed then
  it's fine, because it won't try and decode something in a completely
  different format.

Consider what will happen if the scheme you propose is used.  If I produce
something with RSA and <foo, where foo = some exotic new method> key transport
and set the syntax version number to anything other than 0, existing clients
will break.  If I set it to 0 there's at least some chance that existing
clients will handle it if they see the RSA RI first (that is, setting it to 0
may or may not work, but setting it to n will definitely break an existing
client... I think I modified my code at one point to specifically emit the
original RI's first so that existing apps would see them before they saw any of
the new types).  In addition if an implementation sees a syntax version number
of n then that doesn't mean that there isn't version 0 (or whatever)
information in there which it can still use.  As a result the only behaviour
for an implementation which makes much sense is:

  - When consuming data, ignore the version number.  Just because it's labelled
    version 3 doesn't mean there isn't version 0 information in there
    somewhere, which makes the syntax version value meaningless.

  - When producing data, call it version 0.  This may or may not work with
    existing implementations, but it's better than calling it version 3 which 
    definitely won't work with existing applications.

As I mentioned in my previous post, once implementation developers consider the
implications of the syntax version numbers it won't matter what the spec says,
what will be implemented is what causes the least interop problems.  I'll
repeat again my previous suggestion that in this area the spec codify what
implementations are doing rather than forcing arbitrary restrictions on them.

Peter.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6AN4DU08349 for ietf-smime-bks; Tue, 10 Jul 2001 16:04:13 -0700 (PDT)
Received: from [165.227.249.20] (ip20.proper.com [165.227.249.20]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6AN4Bm08345 for <[e-mail]>; Tue, 10 Jul 2001 16:04:11 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100326b77139b5e28f@[165.227.249.20]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Tue, 10 Jul 2001 16:03:26 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: RE: New x400wrap I-D? (was RE: SMIME-TYPE question)
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 3:41 PM -0700 7/10/01, Musy Michel-P28089 wrote:
>John,
>
>Will this new version of the x400wrap document be posted this week and
>advertised in the working groups?

John is not an editor of the document. I announced earlier this week 
that a new draft would be out very soon. I now have to amend that 
statement, or at least bend the definition of "soon". The 
ever-watchful Jim Schaad has asked some very good questions, and it 
is going to take some time for the editors to respond. This week if 
we are lucky, next week is more likely.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6AMf9807814 for ietf-smime-bks; Tue, 10 Jul 2001 15:41:09 -0700 (PDT)
Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6AMf7m07810 for <[e-mail]>; Tue, 10 Jul 2001 15:41:07 -0700 (PDT)
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id PAA08982 for <[e-mail]>; Tue, 10 Jul 2001 15:41:10 -0700 (MST)]
Received: [from az33exi01.corp.mot.com (az33exi01.corp.mot.com [199.2.84.10]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id PAA23908 for <[e-mail]>; Tue, 10 Jul 2001 15:41:09 -0700 (MST)]
Received: by az33exi01.corp.mot.com with Internet Mail Service (5.5.2653.19) id <3D4GVN97>; Tue, 10 Jul 2001 15:41:09 -0700
Message-ID: <[e-mail]>
From: Musy Michel-P28089 <[e-mail]>
To: "Pawling, John" <[e-mail]>
Cc: "SMIME WG (E-mail)" <[e-mail]>
Subject: RE: New x400wrap I-D? (was RE: SMIME-TYPE question)
Date: Tue, 10 Jul 2001 15:41:06 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

John,

Will this new version of the x400wrap document be posted this week and 
advertised in the working groups? 

Michel  


-----Original Message-----
From: Musy Michel-P28089 [mailto:[e-mail]]
Sent: Monday, July 09, 2001 4:50 PM
To: Pawling, John
Cc: SMIME WG (E-mail)
Subject: RE: New x400wrap I-D? (was RE: SMIME-TYPE question)



Thanks to Jim for the clarification, to John for confirming and helping
by suggesting publication of the new version of the related document.

Michel

-----Original Message-----
From: Pawling, John [mailto:[e-mail]]
Sent: Monday, July 09, 2001 12:58 PM
To: 'Musy Michel-P28089'
Cc: SMIME WG (E-mail)
Subject: New x400wrap I-D? (was RE: SMIME-TYPE question)



Michel,

I agree with everything that Jim stated except that I have not seen the
updated x400wrap document to which he referred.  The x400wrap authors should
submit the updated document so that implementers can develop to the same
spec.  

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================

-----Original Message-----
From: Jim Schaad [mailto:[e-mail]]
Sent: Friday, July 06, 2001 6:39 PM
To: 'Musy Michel-P28089'; 'Ietf-Smime (E-mail)'
Subject: RE: SMIME-TYPE question



Michel,

I understand where you went wrong -- you didn't.  I have seen a later draft
of this document and this has been changed.  Since EncapsulatedContentInfo
and ContentInfo have the exact same content (i.e. an OID and ANY), having
both is actually redunant.  This means that the ContentInfo can be omitted
and just the EncapsulatedContentInfo used to convay the same information.

jim


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6AKmgw05069 for ietf-smime-bks; Tue, 10 Jul 2001 13:48:42 -0700 (PDT)
Received: from femail3.sdc1.sfba.home.com (femail3.sdc1.sfba.home.com [24.0.95.83]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6AKmfm05065 for <[e-mail]>; Tue, 10 Jul 2001 13:48:41 -0700 (PDT)
Received: from revelation ([65.4.166.11]) by femail3.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010710204839.EDJW11925.femail3.sdc1.sfba.home.com@revelation>; Tue, 10 Jul 2001 13:48:39 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: cmsalg-00 Comments
Date: Tue, 10 Jul 2001 13:48:37 -0700
Message-ID: <001e01c10981$b22f25b0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The historical remark is to try and make sure that this problem is not
repeated again.  If you have similar text in the body it probably does not
matter.

jim

> -----Original Message-----
> From: Housley, Russ [mailto:[e-mail]]
> Sent: Tuesday, July 10, 2001 1:10 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: RE: cmsalg-00 Comments
>
>
> Jim:
>
> I understand the purpose of the MUST and SHOULD statements,
> but I do not
> see any reason to include the remark about history.
>
> Russ
>
>
> At 12:40 PM 7/10/2001 -0700, Jim Schaad wrote:
> >Russ,
> > > >9) Table 1, Message Authentication note:  Please add this note to
> > > >immediately follow the table: "Note 3: Only those CMS
> > > implementations that
> > > >support the AuthenticatedData content-type MUST implement
> > > the HMAC with
> > > >SHA-1 algorithm."
> > >
> > > Done.  Here is the updated table (view it in a fixed pitch font):
> > >
> > >              Table 1.  CMS Implementation Algorithm Requirements
> > >
> > >     Algorithm Type            MUST implement
> SHOULD implement
> > >
> -----------------------------------------------------------------
> > >     Message Digest            SHA-1                  MD5
> > >     Signature                 DSA and RSA (1)        --
> > >     Key Management
> > >        Key Agreement          --                     X9.42 E-S D-H
> > >        Key Transport          RSA                    --
> > >        Symmetric KEK Wrap     Triple-DES Key Wrap    RC2 Key Wrap
> > >        Key Derivation         PBKDF2 (2)             --
> > >     Content Encryption        Triple-DES CBC         RC2 CBC
> > >     Message Authentication    HMAC with SHA-1 (3)    --
> > >
> > >     Note 1:  CMS implementations MUST be able to verify signatures
> > >              with both DSA and RSA (PKCS #1 v1.5), and
> they MUST be
> > >              able to generate signatures with at least
> one of them.
> > >
> > >     Note 2:  Only those CMS implementations that support password-
> > >              based key management MUST implement the PBKDF2 key
> > >              derivation algorithm as specified in RFC
> 2898 [PKCS#5].
> > >
> > >     Note 3:  Only those CMS implementations that support
> > >              authenticated-data MUST implement the HMAC with SHA-1
> > >              algorithm as specified in RFC 2104 [HMAC].
> >
> >Given the confusion and other items for RSA I would like to see the
> >following done:
> >
> >Note 4: The use of RSA as a signature algorithm is for
> historical purposes
> >only and does not imply that it needs to work with all message digest
> >algorithms.  RSA (PKCS #1 v1.5) signatures using SHA-1 MUST
> be implemented.
> >RSA (PKCS #1 v1.5) signatures using MD5 SHOULD be implemented.
> >
> > >
> > >
> > > Russ
> > >
> >
> >jim
>



Received: by above.proper.com (8.11.3/8.11.3) id f6AKAIK04047 for ietf-smime-bks; Tue, 10 Jul 2001 13:10:18 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6AKAHm04043 for <[e-mail]>; Tue, 10 Jul 2001 13:10:17 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 10 Jul 2001 20:08:50 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA16774 for <[e-mail]>; Tue, 10 Jul 2001 16:10:18 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <LR8TP8MR>; Tue, 10 Jul 2001 16:10:16 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.15]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LR8TP8MQ; Tue, 10 Jul 2001 16:10:12 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Tue, 10 Jul 2001 16:10:09 -0400
Subject: RE: cmsalg-00 Comments
In-Reply-To: <001a01c10978$34e98810$[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jim:

I understand the purpose of the MUST and SHOULD statements, but I do not 
see any reason to include the remark about history.

Russ


At 12:40 PM 7/10/2001 -0700, Jim Schaad wrote:
>Russ,
> > >9) Table 1, Message Authentication note:  Please add this note to
> > >immediately follow the table: "Note 3: Only those CMS
> > implementations that
> > >support the AuthenticatedData content-type MUST implement
> > the HMAC with
> > >SHA-1 algorithm."
> >
> > Done.  Here is the updated table (view it in a fixed pitch font):
> >
> >              Table 1.  CMS Implementation Algorithm Requirements
> >
> >     Algorithm Type            MUST implement         SHOULD implement
> >     -----------------------------------------------------------------
> >     Message Digest            SHA-1                  MD5
> >     Signature                 DSA and RSA (1)        --
> >     Key Management
> >        Key Agreement          --                     X9.42 E-S D-H
> >        Key Transport          RSA                    --
> >        Symmetric KEK Wrap     Triple-DES Key Wrap    RC2 Key Wrap
> >        Key Derivation         PBKDF2 (2)             --
> >     Content Encryption        Triple-DES CBC         RC2 CBC
> >     Message Authentication    HMAC with SHA-1 (3)    --
> >
> >     Note 1:  CMS implementations MUST be able to verify signatures
> >              with both DSA and RSA (PKCS #1 v1.5), and they MUST be
> >              able to generate signatures with at least one of them.
> >
> >     Note 2:  Only those CMS implementations that support password-
> >              based key management MUST implement the PBKDF2 key
> >              derivation algorithm as specified in RFC 2898 [PKCS#5].
> >
> >     Note 3:  Only those CMS implementations that support
> >              authenticated-data MUST implement the HMAC with SHA-1
> >              algorithm as specified in RFC 2104 [HMAC].
>
>Given the confusion and other items for RSA I would like to see the
>following done:
>
>Note 4: The use of RSA as a signature algorithm is for historical purposes
>only and does not imply that it needs to work with all message digest
>algorithms.  RSA (PKCS #1 v1.5) signatures using SHA-1 MUST be implemented.
>RSA (PKCS #1 v1.5) signatures using MD5 SHOULD be implemented.
>
> >
> >
> > Russ
> >
>
>jim


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6AK64r03844 for ietf-smime-bks; Tue, 10 Jul 2001 13:06:04 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6AK62m03840 for <[e-mail]>; Tue, 10 Jul 2001 13:06:02 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 10 Jul 2001 20:04:36 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA16280 for <[e-mail]>; Tue, 10 Jul 2001 16:03:44 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <LR8TP8J3>; Tue, 10 Jul 2001 16:03:42 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.15]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LR8TP8JL; Tue, 10 Jul 2001 16:03:37 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Tue, 10 Jul 2001 16:03:35 -0400
Subject: RE: Jim's Comments: draft-ietf-smime-cmsalg-00
In-Reply-To: <001701c10976$bffb8f90$[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jim:

> > > > 2) Section 2.1:  Jim stated: "I believe that the MUST and SHOULD 
> statements
> > > > in this paragraph are in conflict.  ie. MUST encode as and  SHOULD 
> generate
> > > > with.  These should be resolved as MUST in both locations."
> > > >
> > > > [JP: I disagree with Jim that the MUST and SHOULD statements are in
> > > > conflict.  The paragraph states: "If present, the parameters field MUST
> > > > contain an ASN.1 NULL."  In my opinion, it is clear that the MUST
> > > > requirement does not apply if the parameters field is absent.  I also
> > > > disagree with Jim's recommendation to change the spec to state that
> > > > implementations MUST populate the algorithmIdentifier parameters 
> field with
> > > > an ASN.1 NULL.  I believe that the text should remain unchanged.]
> > >
> > >[Jim: If present, the parameters field MUST contain an ASN.1 NULL.
> > >Implementations SHOULD generate SHA-1 AlgorithmIdentifiers with NULL
> > >parameters.
> > >
> > >I believe that the second line is a MUST not a SHOULD.  I don't object to
> > >the SHOULD handle if it is wrong, but generation needs to be with NULL
> > >parameters.]
> > >
> > >[John: This is a style choice.  I do not feel strongly about this issue.
> > >RFC 2630 implementations should be populating this field with NULL anyway
> > >(since it was a SHOULD requirement in RFC 2630).  In summary, I do not
> > >object to your proposed change and I do not believe that it will cause any
> > >interoperability problems.  Recommend the following new text: "The
> > >AlgorithmIdentifier parameters field MUST be present, and the parameters
> > >field MUST contain NULL.  Implementations SHOULD accept SHA-1
> > >AlgorithmIdentifiers with absent parameters as well as NULL parameters.
> > >
> > >Also, the following text should be added to section 3.2 RSA: "The
> > >AlgorithmIdentifier parameters field MUST be present, and the parameters
> > >field MUST contain NULL.  Implementations MAY accept rsaEncryption
> > >AlgorithmIdentifiers with absent parameters as well as NULL parameters."]
> >
> > I believe that the preferred encoding is with parameters absent!  Yet, we
> > allow the use of NULL for interoperability with folks that like to follow
> > the convention used with MD2, MD4, and MD5.
> >
> > Current text is: "Implementations SHOULD generate SHA-1
> > AlgorithmIdentifiers with NULL parameters."  If we make any
> > change, I would like to see the SHOULD changed to a MAY.
>
>If this is the preferred encoding, it is certianly not displayed as such in
>the current text.  If you really think that is true then we need to make the
>following change:
>
>"Implementations SHOULD generate SHA-1 AlgorithmIdentifiers as absent".

Done.

> > > > 6) Section 3.2:  Jim stated "Boy we really messed this one
> > > > up.  Section 3.2 should occur
> > > > as two different sections one for RSAwithMD5 and one for
> > > > RSAwithSHA1.  I will never understand how all of us missed this one.
> > > >
> > > > The OIDs for this should be:
> > > >        sha1withRSAEncryption (1 2 840 113549 1 1 5)
> > > > or
> > > > #define szOID_OIWSEC_sha1RSASign "1.3.14.3.2.29"
> > > >
> > > >        md5withRSAEncryption (1 2 840 113549 1 1 4)"
> > > >
> > > > [JP: I disagree with Jim's statements.  To support backwards 
> compatibility
> > > > with S/MIME v2 implementations that only recognize the 
> rsaEncryption OID, we
> > > > specified that the rsaEncryption OID must be included in the signedData
> > > > signerInfo signatureAlgorithm field.  We decided not to specify the 
> use of
> > > > the sha-1WithRSAEncryption, md2withRSAEncryption, or 
> md5withRSAEncryption
> > > > OIDs in the signerInfo signatureAlgorithm field.]
> > >
> > >[Jim stated: John -- If I look in the examples draft, the OID that is 
> in the
> > >signatureAlgorithm field of a SignerInfo field is
> > >   119 30   13:             SEQUENCE {
> > >   121 06    9:               OBJECT IDENTIFIER
> > >              :                 sha1withRSAEncryption (1 2 840 113549 
> 1 1 5)
> > >              :                 (PKCS #1)
> > >   132 05    0:               NULL
> > >              :               }
> > >Not RSA.  I don't have the foggiest idea of what you are talking about for
> > >backwards compatability.  This is not an argument that I have ever heard
> > >before (I think).
> > >
> > >I think you have not looked at this correctly and ask that you 
> re-check what
> > >I am saying.]
> > >
> > >
> > >[John: Your quote from the examples-06 document is for an RSA 
> signature on a
> > >certificate (not a signedData signerInfo signatureAlgorithm field).
> > >Examples 5.2, 5.5 and 11.2 in the examples-06 document all include the
> > >rsaEncryption (1 2 840 113549 1 1 1) OID in the signerInfo
> > >signatureAlgorithm field as specified in RFC 2630, section 12.2.2.
> > >
> > >There is definitely an inconsistency between the specification of the
> > >rsaEncryption and id-dsa-with-sha1 OIDs in the signerInfo 
> signatureAlgorithm
> > >field.  While RFC 2630 was being developed, I pointed out that
> > >inconsistency.  I was told that the rsaEncryption OID was specified to
> > >support backwards compatibility with S/MIME v2 implementations that only
> > >recognize the rsaEncryption OID.  I was also told that the signerInfo
> > >digestAlgorithm field indicates the algorithm used to calculate the 
> message
> > >digest value used as an input to the signature algorithm, so the use 
> of the
> > >rsaEncryption OID (rather than sha-1withRSAEncryption, 
> md2withRSAEncryption,
> > >or md5withRSAEncryption) was appropriate.  I then proposed that the id-dsa
> > >OID should be used in the signerInfo signatureAlgorithm field to be
> > >consistent with the use of the rsaEncryption OID.  I was told that 
> since DSA
> > >is always used with SHA-1, then the id-dsa-with-sha1 OID is 
> appropriate for
> > >use in the signerInfo signatureAlgorithm field.
> > >
> > >Having said all of that, I would support a change to cmsalg to specify the
> > >use of the sha-1withRSAEncryption, md2withRSAEncryption, or
> > >md5withRSAEncryption OIDs (rather than  rsaEncryption) in the signerInfo
> > >signatureAlgorithm field.  This would be consistent with the use of those
> > >OIDs in PKIX X.509 certificates.  It would also eliminate the current
> > >situation in which the rsaEncryption OID is being used for two very
> > >different purposes (to indicate an RSA signature in the signerInfo
> > >signatureAlgorithm field and to indicate an RSA public key in a PKIX X.509
> > >certificate).]
> >
> > The OIWSEC_sha1RSASign OID  (1.3.14.3.2.29) is not appropriate here.  This
> > OID is used with X9.31 padding (not PKCS#1 v1.5 padding).  As far as I
> > know, no one supports X9.31 padding in any S/MIME (v2 or v3) product,
> > freeware, or tool kit.
> >
> > The confusion here is which algorithm identifier goes in the public key
> > certificate and which algorithm identifier goes with the signature
> > value.  The text clearly needs to handle both situations.
>
>I have looked back and tried to remember what was going on then.  I find
>that John is correct, for the current algorithms we definately only use the
>rsa OID.  I think we want to "fix" this for the new signature algorithms
>when they come along bit it's too late for these.
>
>I do, however, think that this confusion deserves some explation text as to
>why it is not a "signature" algorithm but a public key algorithm for RSA
>v1.5.

I have just finished composing text that I hope will make this much more 
clear.  It is fairly long, so I will simply post a new version of the 
Internet-Draft.  It should be there tomorrow.

Russ


Received: by above.proper.com (8.11.3/8.11.3) id f6AJelT02323 for ietf-smime-bks; Tue, 10 Jul 2001 12:40:47 -0700 (PDT)
Received: from femail12.sdc1.sfba.home.com (femail12.sdc1.sfba.home.com [24.0.95.108]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6AJekm02318 for <[e-mail]>; Tue, 10 Jul 2001 12:40:46 -0700 (PDT)
Received: from revelation ([65.4.166.11]) by femail12.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010710194043.THUJ1573.femail12.sdc1.sfba.home.com@revelation>; Tue, 10 Jul 2001 12:40:43 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>, "'Pawling, John'" <[e-mail]>
Cc: "'SMIME WG \(E-mail\)'" <[e-mail]>
Subject: RE: cmsalg-00 Comments
Date: Tue, 10 Jul 2001 12:40:41 -0700
Message-ID: <001a01c10978$34e98810$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,
> >9) Table 1, Message Authentication note:  Please add this note to
> >immediately follow the table: "Note 3: Only those CMS
> implementations that
> >support the AuthenticatedData content-type MUST implement
> the HMAC with
> >SHA-1 algorithm."
>
> Done.  Here is the updated table (view it in a fixed pitch font):
>
>              Table 1.  CMS Implementation Algorithm Requirements
>
>     Algorithm Type            MUST implement         SHOULD implement
>     -----------------------------------------------------------------
>     Message Digest            SHA-1                  MD5
>     Signature                 DSA and RSA (1)        --
>     Key Management
>        Key Agreement          --                     X9.42 E-S D-H
>        Key Transport          RSA                    --
>        Symmetric KEK Wrap     Triple-DES Key Wrap    RC2 Key Wrap
>        Key Derivation         PBKDF2 (2)             --
>     Content Encryption        Triple-DES CBC         RC2 CBC
>     Message Authentication    HMAC with SHA-1 (3)    --
>
>     Note 1:  CMS implementations MUST be able to verify signatures
>              with both DSA and RSA (PKCS #1 v1.5), and they MUST be
>              able to generate signatures with at least one of them.
>
>     Note 2:  Only those CMS implementations that support password-
>              based key management MUST implement the PBKDF2 key
>              derivation algorithm as specified in RFC 2898 [PKCS#5].
>
>     Note 3:  Only those CMS implementations that support
>              authenticated-data MUST implement the HMAC with SHA-1
>              algorithm as specified in RFC 2104 [HMAC].

Given the confusion and other items for RSA I would like to see the
following done:

Note 4: The use of RSA as a signature algorithm is for historical purposes
only and does not imply that it needs to work with all message digest
algorithms.  RSA (PKCS #1 v1.5) signatures using SHA-1 MUST be implemented.
RSA (PKCS #1 v1.5) signatures using MD5 SHOULD be implemented.

>
>
> Russ
>

jim



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6AJaop02110 for ietf-smime-bks; Tue, 10 Jul 2001 12:36:50 -0700 (PDT)
Received: from femail12.sdc1.sfba.home.com (femail12.sdc1.sfba.home.com [24.0.95.108]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6AJanm02104 for <[e-mail]>; Tue, 10 Jul 2001 12:36:49 -0700 (PDT)
Received: from revelation ([65.4.166.11]) by femail12.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010710193646.TCMP1573.femail12.sdc1.sfba.home.com@revelation>; Tue, 10 Jul 2001 12:36:46 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Blake Ramsdell'" <[e-mail]>, "'Ietf-Smime \(E-mail\)'" <[e-mail]>
Subject: RE: SMIME-TYPE question
Date: Tue, 10 Jul 2001 12:36:44 -0700
Message-ID: <001901c10977$a7609f10$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Blake,

Based on this I would like to see some text added to the message draft in
section 3.2.2

"In some instances an smime-type will be created that only reflects one
security service (such as certs-only which is only for signed), however as
new layers are wrapped this smime-type SHOULD be propigated upwards.  Thus
if a certs-only message were to be encrypted, or wrapped in a new SignedData
structure, the smime-type of certs-only should be propigated  up to the next
mime wrapper."

jim

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Blake Ramsdell
> Sent: Friday, July 06, 2001 1:06 PM
> To: '[e-mail]'; 'Ietf-Smime (E-mail)'
> Subject: RE: SMIME-TYPE question
>
>
>
> I believe that if I wanted to see a pretty icon in my mail
> agent, I would
> want to see the one that reflected the fact that it was a
> receipt, so yes.
>
> Blake
>
> -----Original Message-----
> From: Jim Schaad [mailto:[e-mail]]
> Sent: Friday, July 06, 2001 1:04 PM
> To: Blake Ramsdell; 'Ietf-Smime (E-mail)'
> Subject: RE: SMIME-TYPE question
>
>
> I am unclear, do you believe that an encrypted signed-receipt
> should have an
> smime-type of signed-receipt then?
>
> jim
>
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]On Behalf Of Blake Ramsdell
> > Sent: Friday, July 06, 2001 10:54 AM
> > To: '[e-mail]'; Ietf-Smime (E-mail)
> > Subject: RE: SMIME-TYPE question
> >
> >
> >
> > To tell you the truth, I've never liked smime-type, and it
> > wasn't my doing.
> > I think that lgl put this in.
> >
> > If I had to take a stab at it, I would characterize it as
> > being a shortcut
> > hint to present to the client, and if it is inaccurate, it
> > should have no
> > effect on processing.  So if you wanted to provide an icon to
> > indicate the
> > message type, without tearing through the contents, this
> > would be your boy.
> >
> > Now, I think that only RFC2633 profiles any smime-type (with
> > the exception
> > of signed-receipt in ESS).  If I had to summarize what went
> > in the value and
> > when to change the value, I would say "whenever there is
> > significant client
> > benefit".
> >
> > I think that the micalg parameter in RFC1847 is in somewhat
> > the same boat --
> > it's meant to be a hint, the values aren't really well
> > specified, and you
> > just expect the worst and work it out in processing.
> >
> > Blake
> >
> > -----Original Message-----
> > From: Jim Schaad [mailto:[e-mail]]
> > Sent: Friday, July 06, 2001 1:40 AM
> > To: Ietf-Smime (E-mail)
> > Subject: SMIME-TYPE question
> >
> >
> >
> > I have a general question that I once knew the answer for but
> > am  no longer
> > sure that is the case.
> >
> > The SMIME-TYPE attribute was defined so that a mime-level
> > processor could
> > have some idea of the content type without having to pull
> > apart the message
> > and look at the contentHint attribute or the innermost
> > eContent.  (Or at
> > least that is what I remember it as being for.)  This being
> > the case, what
> > is the correct value of smime-type on a triple wrapped
> message with a
> > signedReceipt as the content?  It is signed-data or
> > signed-receipt.  Should
> > the answer change if the inner mime-layers were to be omitted
> > (relevant for
> > the X.400 case).
> >
> > Does the answer change if you have an encrypted receipt (i.e.
> > E(S(Receipt)))
> > What is the correct value of smime-type now?  signedReceipt or
> > encrypted-data?  Again does the answer change if the mime
> > layer were to be
> > omitted.
> >
> > Signed-receipt means that the top level processor knows what
> > is going to
> > happen before it gets there and can make intellegent decisions.
> >
> > Signed-Data is "correct" because the encapsulated content
> > contained in this
> > SignedData object is id-data or MIME content.
> >
> > NOTE: For the simple case of data (or MIME) content the question is
> > accedemic as signed-data and encrypted-data both imply data content.
> >
> > My original answer was the the correct answer is that
> > signed-receipt should
> > be propigated up over all of the layers, but I don't find any
> > statements
> > about this in either the message or ESS RFCs.
> >
> > jim
> >
> >
>
>
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6AJVWR01788 for ietf-smime-bks; Tue, 10 Jul 2001 12:31:32 -0700 (PDT)
Received: from femail12.sdc1.sfba.home.com (femail12.sdc1.sfba.home.com [24.0.95.108]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6AJVVm01784 for <[e-mail]>; Tue, 10 Jul 2001 12:31:31 -0700 (PDT)
Received: from revelation ([65.4.166.11]) by femail12.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010710193129.SVNQ1573.femail12.sdc1.sfba.home.com@revelation>; Tue, 10 Jul 2001 12:31:29 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>, <[e-mail]>
Subject: RE: Key Wrap Algorithms
Date: Tue, 10 Jul 2001 12:31:26 -0700
Message-ID: <001801c10976$ea5ba4f0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

I agree this needs to be a MUST for the cms-alg draft.  I think this is a
SHOULD for the S/MIME message draft if it decides to be different from the
cms-alg draft.

jim

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Housley, Russ
> Sent: Tuesday, July 10, 2001 9:51 AM
> To: [e-mail]
> Subject: Key Wrap Algorithms
>
>
>
> All:
>
> After a fairly long debate, the consensus on key management has been
> reached.  We seem to agree that:
>
>     Implementations MUST support key transport, key
> agreement, and previously
>     distributed symmetric key-encryption keys, as represented
> by ktri,
> kari, and
>     kekri, respectively.  Implementations MAY support the
> password-based key
>     management as represented by pwri.  Implementations MAY
> support any other
>     key management technique as represented by ori.
>
> At the last IETF meeting, we agreed on the mandatory to implement
> algorithms.  The Minutes say:
>
>     Signature: DSA and RSA (PKCS #1 v1.5) as per Russ' proposal
>     Message digest: SHA-1
>     Key Management: RSA (PKCS #1 v1.5)
>     Encryption: Triple-DES
>
> But, the Minutes are silent about key wrapping.
>
> It is my view that we should require implementations to
> support Triple-DES
> Key Wrap.  This view is reflected in
> draft-ietf-smime-cmsalg-00. And, I
> think that this approach will facilitate the adoption of mail lists.
>
> I want to hear from others.  What do you think is the best
> MUST and SHOULD
> statements regarding key wrap algorithms?
>
> Russ
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6AJUOt01670 for ietf-smime-bks; Tue, 10 Jul 2001 12:30:24 -0700 (PDT)
Received: from femail12.sdc1.sfba.home.com (femail12.sdc1.sfba.home.com [24.0.95.108]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6AJUMm01663 for <[e-mail]>; Tue, 10 Jul 2001 12:30:22 -0700 (PDT)
Received: from revelation ([65.4.166.11]) by femail12.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010710193018.SUEP1573.femail12.sdc1.sfba.home.com@revelation>; Tue, 10 Jul 2001 12:30:18 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Jim's Comments: draft-ietf-smime-cmsalg-00
Date: Tue, 10 Jul 2001 12:30:15 -0700
Message-ID: <001701c10976$bffb8f90$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,
>
> John & Jim:
>
> > > 2) Section 2.1:  Jim stated: "I believe that the MUST and
> SHOULD statements
> > > in this paragraph are in conflict.  ie. MUST encode as
> and  SHOULD generate
> > > with.  These should be resolved as MUST in both locations."
> > >
> > > [JP: I disagree with Jim that the MUST and SHOULD
> statements are in
> > > conflict.  The paragraph states: "If present, the
> parameters field MUST
> > > contain an ASN.1 NULL."  In my opinion, it is clear that the MUST
> > > requirement does not apply if the parameters field is
> absent.  I also
> > > disagree with Jim's recommendation to change the spec to
> state that
> > > implementations MUST populate the algorithmIdentifier
> parameters field with
> > > an ASN.1 NULL.  I believe that the text should remain unchanged.]
> >
> >[Jim: If present, the parameters field MUST contain an ASN.1 NULL.
> >Implementations SHOULD generate SHA-1 AlgorithmIdentifiers with NULL
> >parameters.
> >
> >I believe that the second line is a MUST not a SHOULD.  I
> don't object to
> >the SHOULD handle if it is wrong, but generation needs to be
> with NULL
> >parameters.]
> >
> >[John: This is a style choice.  I do not feel strongly about
> this issue.
> >RFC 2630 implementations should be populating this field
> with NULL anyway
> >(since it was a SHOULD requirement in RFC 2630).  In
> summary, I do not
> >object to your proposed change and I do not believe that it
> will cause any
> >interoperability problems.  Recommend the following new text: "The
> >AlgorithmIdentifier parameters field MUST be present, and
> the parameters
> >field MUST contain NULL.  Implementations SHOULD accept SHA-1
> >AlgorithmIdentifiers with absent parameters as well as NULL
> parameters.
> >
> >Also, the following text should be added to section 3.2 RSA: "The
> >AlgorithmIdentifier parameters field MUST be present, and
> the parameters
> >field MUST contain NULL.  Implementations MAY accept rsaEncryption
> >AlgorithmIdentifiers with absent parameters as well as NULL
> parameters."]
>
> I believe that the preferred encoding is with parameters
> absent!  Yet, we
> allow the use of NULL for interoperability with folks that
> like to follow
> the convention used with MD2, MD4, and MD5.
>
> Current text is: "Implementations SHOULD generate SHA-1
> AlgorithmIdentifiers with NULL parameters."  If we make any
> change, I would
> like to see the SHOULD changed to a MAY.

If this is the preferred encoding, it is certianly not displayed as such in
the current text.  If you really think that is true then we need to make the
following change:

"Implementations SHOULD generate SHA-1 AlgorithmIdentifiers as absent".

>
> > > 6) Section 3.2:  Jim stated "Boy we really messed this one
> > > up.  Section 3.2 should occur
> > > as two different sections one for RSAwithMD5 and one for
> > > RSAwithSHA1.  I will never understand how all of us
> missed this one.
> > >
> > > The OIDs for this should be:
> > >        sha1withRSAEncryption (1 2 840 113549 1 1 5)
> > > or
> > > #define szOID_OIWSEC_sha1RSASign "1.3.14.3.2.29"
> > >
> > >        md5withRSAEncryption (1 2 840 113549 1 1 4)"
> > >
> > > [JP: I disagree with Jim's statements.  To support
> backwards compatibility
> > > with S/MIME v2 implementations that only recognize the
> rsaEncryption
> > OID, we
> > > specified that the rsaEncryption OID must be included in
> the signedData
> > > signerInfo signatureAlgorithm field.  We decided not to
> specify the use of
> > > the sha-1WithRSAEncryption, md2withRSAEncryption, or
> md5withRSAEncryption
> > > OIDs in the signerInfo signatureAlgorithm field.]
> >
> >[Jim stated: John -- If I look in the examples draft, the
> OID that is in the
> >signatureAlgorithm field of a SignerInfo field is
> >   119 30   13:             SEQUENCE {
> >   121 06    9:               OBJECT IDENTIFIER
> >              :                 sha1withRSAEncryption (1 2
> 840 113549 1 1 5)
> >              :                 (PKCS #1)
> >   132 05    0:               NULL
> >              :               }
> >Not RSA.  I don't have the foggiest idea of what you are
> talking about for
> >backwards compatability.  This is not an argument that I
> have ever heard
> >before (I think).
> >
> >I think you have not looked at this correctly and ask that
> you re-check what
> >I am saying.]
> >
> >
> >[John: Your quote from the examples-06 document is for an
> RSA signature on a
> >certificate (not a signedData signerInfo signatureAlgorithm field).
> >Examples 5.2, 5.5 and 11.2 in the examples-06 document all
> include the
> >rsaEncryption (1 2 840 113549 1 1 1) OID in the signerInfo
> >signatureAlgorithm field as specified in RFC 2630, section 12.2.2.
> >
> >There is definitely an inconsistency between the specification of the
> >rsaEncryption and id-dsa-with-sha1 OIDs in the signerInfo
> signatureAlgorithm
> >field.  While RFC 2630 was being developed, I pointed out that
> >inconsistency.  I was told that the rsaEncryption OID was
> specified to
> >support backwards compatibility with S/MIME v2
> implementations that only
> >recognize the rsaEncryption OID.  I was also told that the signerInfo
> >digestAlgorithm field indicates the algorithm used to
> calculate the message
> >digest value used as an input to the signature algorithm, so
> the use of the
> >rsaEncryption OID (rather than sha-1withRSAEncryption,
> md2withRSAEncryption,
> >or md5withRSAEncryption) was appropriate.  I then proposed
> that the id-dsa
> >OID should be used in the signerInfo signatureAlgorithm field to be
> >consistent with the use of the rsaEncryption OID.  I was
> told that since DSA
> >is always used with SHA-1, then the id-dsa-with-sha1 OID is
> appropriate for
> >use in the signerInfo signatureAlgorithm field.
> >
> >Having said all of that, I would support a change to cmsalg
> to specify the
> >use of the sha-1withRSAEncryption, md2withRSAEncryption, or
> >md5withRSAEncryption OIDs (rather than  rsaEncryption) in
> the signerInfo
> >signatureAlgorithm field.  This would be consistent with the
> use of those
> >OIDs in PKIX X.509 certificates.  It would also eliminate the current
> >situation in which the rsaEncryption OID is being used for two very
> >different purposes (to indicate an RSA signature in the signerInfo
> >signatureAlgorithm field and to indicate an RSA public key
> in a PKIX X.509
> >certificate).]
>
> The OIWSEC_sha1RSASign OID  (1.3.14.3.2.29) is not
> appropriate here.  This
> OID is used with X9.31 padding (not PKCS#1 v1.5 padding).  As
> far as I
> know, no one supports X9.31 padding in any S/MIME (v2 or v3) product,
> freeware, or tool kit.
>
> The confusion here is which algorithm identifier goes in the
> public key
> certificate and which algorithm identifier goes with the signature
> value.  The text clearly needs to handle both situations.

I have looked back and tried to remember what was going on then.  I find
that John is correct, for the current algorithms we definately only use the
rsa OID.  I think we want to "fix" this for the new signature algorithms
when they come along bit it's too late for these.

I do, however, think that this confusion deserves some explation text as to
why it is not a "signature" algorithm but a public key algorithm for RSA
v1.5.

>
> > > 12) Section 7:  Jim stated: "I do not believe this section
> > > needs any MUSTS for inclusion
> > > of algorithms.  That is covered in section 4."
> > >
> > > [JP: Rather than delete the first sentence of Section 7,
> I believe that it
> > > should be changed to: "CMS implementations that support the
> > > previously-distributed symmetric KEK or key agreement key
> management
> > > techniques MUST include encryption of a Triple-DES
> content-encryption key
> > > with a Triple-DES key-encryption key using the algorithm
> specified in
> > > Sections 7.2 and 7.3."]
> >
> >[Jim: I stand by my original comment.  This is a duplication
> of a MUST and
> >should
> >be where it makes sense (where the algorithm is used) not here.]
> >
> >[John: I do not object to your comment.  If the MUST
> language is removed
> >from the first sentence, then the SHOULD language should be
> removed from the
> >second sentence.]
>
> My recollection from the last IETF meeting was that we wanted
> the key wrap
> algorithm to remain mandatory to implement.  This was to
> facilitate mail
> list deployment.  I cannot find anything in the minutes to support my
> recollection, but I cannot find anything in the minutes that
> contradicts my
> recollection either.  I will start a separate message thread
> to debate this
> issue.
>
> Russ
>


jim



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6AIBkY28565 for ietf-smime-bks; Tue, 10 Jul 2001 11:11:46 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6AIBjm28554 for <[e-mail]>; Tue, 10 Jul 2001 11:11:45 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 10 Jul 2001 18:10:18 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA05362 for <[e-mail]>; Tue, 10 Jul 2001 14:11:46 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <LR8TP6C3>; Tue, 10 Jul 2001 14:11:44 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.15]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LR8TP6CJ; Tue, 10 Jul 2001 14:11:38 -0400
From: "Housley, Russ" <[e-mail]>
To: Mike Just <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Tue, 10 Jul 2001 14:11:33 -0400
Subject: RE: Key Wrap Algorithms
In-Reply-To: <[e-mail].c om>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<html>
Mike:<br>
<br>
In the current draft, support for the protocol elements is required, but
no specific algorithm is required.&nbsp; This inconsistency is the basis
of my question.<br>
<br>
Russ<br>
<br>
At 02:06 PM 7/10/2001 -0400, Mike Just wrote:<br>
<br>
<blockquote type=cite class=cite cite><font size=2>Apologies Russ, but
I'm not clear on exactly what you're stating below.&nbsp; You're
introductory text indicates that implementations MUST support key
transport, key agreement and previously distributed key-encryption keys
(PDKEK), but the table from the minutes you include below only indicates
a MUST for key transport (using RSA PKCS#1 v1.5).&nbsp; I would have
assumed that only key transport MUST be implemented?&nbsp; If key
agreement and PDKEK MUST be implemented, I must admit that I didn't
notice any consensus for this on the list.<br>
</font><br>
<font size=2>Mike</font> <br>
<br>
<font size=2>&gt; -----Original Message-----</font> <br>
<font size=2>&gt; From: Housley, Russ
[<a href="mailto:[e-mail]">mailto:[e-mail]</a>]</font>
<br>
<font size=2>&gt; Sent: Tuesday, July 10, 2001 12:51 PM</font> <br>
<font size=2>&gt; To: [e-mail]</font> <br>
<font size=2>&gt; Subject: Key Wrap Algorithms</font> <br>
<font size=2>&gt; </font><br>
<font size=2>&gt; </font><br>
<font size=2>&gt; </font><br>
<font size=2>&gt; All:</font> <br>
<font size=2>&gt; </font><br>
<font size=2>&gt; After a fairly long debate, the consensus on key
management has been </font><br>
<font size=2>&gt; reached.&nbsp; We seem to agree that:</font> <br>
<font size=2>&gt; </font><br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Implementations MUST support
key transport, key </font><br>
<font size=2>&gt; agreement, and previously</font> <br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; distributed symmetric
key-encryption keys, as represented </font><br>
<font size=2>&gt; by ktri, </font><br>
<font size=2>&gt; kari, and</font> <br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; kekri, respectively.&nbsp;
Implementations MAY support the </font><br>
<font size=2>&gt; password-based key</font> <br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; management as represented by
pwri.&nbsp; Implementations MAY </font><br>
<font size=2>&gt; support any other</font> <br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; key management technique as
represented by ori.</font> <br>
<font size=2>&gt; </font><br>
<font size=2>&gt; At the last IETF meeting, we agreed on the mandatory to
implement </font><br>
<font size=2>&gt; algorithms.&nbsp; The Minutes say:</font> <br>
<font size=2>&gt; </font><br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Signature: DSA and RSA (PKCS #1
v1.5) as per Russ' proposal</font> <br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Message digest: SHA-1</font>
<br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Key Management: RSA (PKCS #1 v1.5)</font> <br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Encryption: Triple-DES</font> <br>
<font size=2>&gt; </font><br>
<font size=2>&gt; But, the Minutes are silent about key wrapping.</font> <br>
<font size=2>&gt; </font><br>
<font size=2>&gt; It is my view that we should require implementations to </font><br>
<font size=2>&gt; support Triple-DES </font><br>
<font size=2>&gt; Key Wrap.&nbsp; This view is reflected in </font><br>
<font size=2>&gt; draft-ietf-smime-cmsalg-00. And, I </font><br>
<font size=2>&gt; think that this approach will facilitate the adoption of mail lists.</font> <br>
<font size=2>&gt; </font><br>
<font size=2>&gt; I want to hear from others.&nbsp; What do you think is the best </font><br>
<font size=2>&gt; MUST and SHOULD </font><br>
<font size=2>&gt; statements regarding key wrap algorithms?</font> <br>
<font size=2>&gt; </font><br>
<font size=2>&gt; Russ</font> <br>
<font size=2>&gt; </font></blockquote></html>


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6AI6eZ28424 for ietf-smime-bks; Tue, 10 Jul 2001 11:06:40 -0700 (PDT)
Received: from sottmxs02.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6AI6bm28420 for <[e-mail]>; Tue, 10 Jul 2001 11:06:38 -0700 (PDT)
Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id <NL0CGK82>; Tue, 10 Jul 2001 14:06:32 -0400
Message-ID: <[e-mail]>
From: Mike Just <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>, [e-mail]
Subject: RE: Key Wrap Algorithms
Date: Tue, 10 Jul 2001 14:06:22 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1096B.06C1A830"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

------_=_NextPart_001_01C1096B.06C1A830
Content-Type: text/plain

Apologies Russ, but I'm not clear on exactly what you're stating below.
You're introductory text indicates that implementations MUST support key
transport, key agreement and previously distributed key-encryption keys
(PDKEK), but the table from the minutes you include below only indicates a
MUST for key transport (using RSA PKCS#1 v1.5).  I would have assumed that
only key transport MUST be implemented?  If key agreement and PDKEK MUST be
implemented, I must admit that I didn't notice any consensus for this on the
list.

Mike

> -----Original Message-----
> From: Housley, Russ [mailto:[e-mail]]
> Sent: Tuesday, July 10, 2001 12:51 PM
> To: [e-mail]
> Subject: Key Wrap Algorithms
> 
> 
> 
> All:
> 
> After a fairly long debate, the consensus on key management has been 
> reached.  We seem to agree that:
> 
>     Implementations MUST support key transport, key 
> agreement, and previously
>     distributed symmetric key-encryption keys, as represented 
> by ktri, 
> kari, and
>     kekri, respectively.  Implementations MAY support the 
> password-based key
>     management as represented by pwri.  Implementations MAY 
> support any other
>     key management technique as represented by ori.
> 
> At the last IETF meeting, we agreed on the mandatory to implement 
> algorithms.  The Minutes say:
> 
>     Signature: DSA and RSA (PKCS #1 v1.5) as per Russ' proposal
>     Message digest: SHA-1
>     Key Management: RSA (PKCS #1 v1.5)
>     Encryption: Triple-DES
> 
> But, the Minutes are silent about key wrapping.
> 
> It is my view that we should require implementations to 
> support Triple-DES 
> Key Wrap.  This view is reflected in 
> draft-ietf-smime-cmsalg-00. And, I 
> think that this approach will facilitate the adoption of mail lists.
> 
> I want to hear from others.  What do you think is the best 
> MUST and SHOULD 
> statements regarding key wrap algorithms?
> 
> Russ
> 

------_=_NextPart_001_01C1096B.06C1A830
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: Key Wrap Algorithms</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Apologies Russ, but I'm not clear on exactly what =
you're stating below.&nbsp; You're introductory text indicates that =
implementations MUST support key transport, key agreement and =
previously distributed key-encryption keys (PDKEK), but the table from =
the minutes you include below only indicates a MUST for key transport =
(using RSA PKCS#1 v1.5).&nbsp; I would have assumed that only key =
transport MUST be implemented?&nbsp; If key agreement and PDKEK MUST be =
implemented, I must admit that I didn't notice any consensus for this =
on the list.</FONT></P>

<P><FONT SIZE=3D2>Mike</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Housley, Russ [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]=
</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, July 10, 2001 12:51 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Key Wrap Algorithms</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; All:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; After a fairly long debate, the consensus on =
key management has been </FONT>
<BR><FONT SIZE=3D2>&gt; reached.&nbsp; We seem to agree that:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Implementations MUST =
support key transport, key </FONT>
<BR><FONT SIZE=3D2>&gt; agreement, and previously</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; distributed symmetric =
key-encryption keys, as represented </FONT>
<BR><FONT SIZE=3D2>&gt; by ktri, </FONT>
<BR><FONT SIZE=3D2>&gt; kari, and</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; kekri, =
respectively.&nbsp; Implementations MAY support the </FONT>
<BR><FONT SIZE=3D2>&gt; password-based key</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; management as =
represented by pwri.&nbsp; Implementations MAY </FONT>
<BR><FONT SIZE=3D2>&gt; support any other</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; key management =
technique as represented by ori.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; At the last IETF meeting, we agreed on the =
mandatory to implement </FONT>
<BR><FONT SIZE=3D2>&gt; algorithms.&nbsp; The Minutes say:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Signature: DSA and RSA =
(PKCS #1 v1.5) as per Russ' proposal</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Message digest: =
SHA-1</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Key Management: RSA =
(PKCS #1 v1.5)</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Encryption: =
Triple-DES</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; But, the Minutes are silent about key =
wrapping.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; It is my view that we should require =
implementations to </FONT>
<BR><FONT SIZE=3D2>&gt; support Triple-DES </FONT>
<BR><FONT SIZE=3D2>&gt; Key Wrap.&nbsp; This view is reflected in =
</FONT>
<BR><FONT SIZE=3D2>&gt; draft-ietf-smime-cmsalg-00. And, I </FONT>
<BR><FONT SIZE=3D2>&gt; think that this approach will facilitate the =
adoption of mail lists.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I want to hear from others.&nbsp; What do you =
think is the best </FONT>
<BR><FONT SIZE=3D2>&gt; MUST and SHOULD </FONT>
<BR><FONT SIZE=3D2>&gt; statements regarding key wrap =
algorithms?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Russ</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1096B.06C1A830--


Received: by above.proper.com (8.11.3/8.11.3) id f6AHYA627384 for ietf-smime-bks; Tue, 10 Jul 2001 10:34:10 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6AHY4m27380 for <[e-mail]>; Tue, 10 Jul 2001 10:34:04 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 10 Jul 2001 17:32:37 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id NAA01941 for <[e-mail]>; Tue, 10 Jul 2001 13:34:05 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <LR8TP5N3>; Tue, 10 Jul 2001 13:34:03 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.15]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LR8TP5NM; Tue, 10 Jul 2001 13:34:00 -0400
From: "Housley, Russ" <[e-mail]>
To: "Pawling, John" <[e-mail]>
Cc: "SMIME WG (E-mail)" <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Tue, 10 Jul 2001 13:33:57 -0400
Subject: RE: cmsalg-00 Comments
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

John:

>1) Section 4.1, 2nd para: Please change the following to be consistent with
>Table 1:
>
>OLD: "CMS implementations MUST include Triple-DES wrapping of Triple-DES
>content-encryption keys and RC2 wrapping of RC2 content-encryption keys."
>
>NEW: "CMS implementations MUST include Triple-DES wrapping of Triple-DES
>content-encryption keys and SHOULD include RC2 wrapping of RC2
>content-encryption keys."

Agree.  Done.

>2) Recommend the following change in your recommended text for section 4.4
>as follows:
>
>OLD: Key derivation algorithms identifiers are...
>
>NEW: Key derivation algorithm identifiers are...

Agree.  Done.

>3) Recommend the following change in your recommended text for section 4.4
>as follows:
>
>OLD: The content-encryption keys encrypted with password-derived
>key-encryption keys are located in the EnvelopedData RecipientInfos
>PasswordRecipientInfo encryptedKey field.  The message-authentication keys
>encrypted with password-derived key-encryption keys are located in the
>AuthenticatedData RecipientInfos PasswordRecipientInfo encryptedKey field.
>
>NEW: The content-encryption key encrypted with the password-derived
>key-encryption key is located in the EnvelopedData RecipientInfos
>PasswordRecipientInfo encryptedKey field.  The message-authentication key
>encrypted with the password-derived key-encryption key is located in the
>AuthenticatedData RecipientInfos PasswordRecipientInfo encryptedKey field.

I was trying to be parallel.  The plural is used in other places.  See, for 
example, section 4.2.

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6AGpR425898 for ietf-smime-bks; Tue, 10 Jul 2001 09:51:27 -0700 (PDT)
Received: from [203.46.112.10] (mail.rsasecurity.com.au [203.46.112.10]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6AGpOm25893 for <[e-mail]>; Tue, 10 Jul 2001 09:51:25 -0700 (PDT)
Received: from [192.168.18.3] by [203.46.112.10] via smtpd (for [208.184.76.43]) with SMTP; 12 Mar 2001 14:50:48 UT
Received: from exaus01.local.aus.rsa.com (exaus01.local.aus.rsa.com [10.177.1.15]) by grover.local.aus.rsa.com (8.10.2/8.10.2) with ESMTP id f6AGtFB21664 for <[e-mail]>; Wed, 11 Jul 2001 02:55:16 +1000 (EST)
Received: by exaus01.local.aus.rsa.com with Internet Mail Service (5.5.2653.19) id <KW2C53FS>; Wed, 11 Jul 2001 02:51:05 +1000
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.15]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LR8TPZV8; Tue, 10 Jul 2001 12:50:57 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Tue, 10 Jul 2001 12:50:56 -0400
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: Key Wrap Algorithms
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All:

After a fairly long debate, the consensus on key management has been 
reached.  We seem to agree that:

    Implementations MUST support key transport, key agreement, and previously
    distributed symmetric key-encryption keys, as represented by ktri, 
kari, and
    kekri, respectively.  Implementations MAY support the password-based key
    management as represented by pwri.  Implementations MAY support any other
    key management technique as represented by ori.

At the last IETF meeting, we agreed on the mandatory to implement 
algorithms.  The Minutes say:

    Signature: DSA and RSA (PKCS #1 v1.5) as per Russ' proposal
    Message digest: SHA-1
    Key Management: RSA (PKCS #1 v1.5)
    Encryption: Triple-DES

But, the Minutes are silent about key wrapping.

It is my view that we should require implementations to support Triple-DES 
Key Wrap.  This view is reflected in draft-ietf-smime-cmsalg-00. And, I 
think that this approach will facilitate the adoption of mail lists.

I want to hear from others.  What do you think is the best MUST and SHOULD 
statements regarding key wrap algorithms?

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6AGdCU25444 for ietf-smime-bks; Tue, 10 Jul 2001 09:39:12 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6AGdAm25440 for <[e-mail]>; Tue, 10 Jul 2001 09:39:11 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 10 Jul 2001 16:37:44 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id MAA27164; Tue, 10 Jul 2001 12:39:06 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <LR8TPZRG>; Tue, 10 Jul 2001 12:39:03 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.15]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LR8TPZR1; Tue, 10 Jul 2001 12:39:00 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Tue, 10 Jul 2001 12:39:00 -0400
Subject: RE: Jim's Comments: draft-ietf-smime-cmsalg-00
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

John & Jim:

> > 2) Section 2.1:  Jim stated: "I believe that the MUST and SHOULD statements
> > in this paragraph are in conflict.  ie. MUST encode as and  SHOULD generate
> > with.  These should be resolved as MUST in both locations."
> >
> > [JP: I disagree with Jim that the MUST and SHOULD statements are in
> > conflict.  The paragraph states: "If present, the parameters field MUST
> > contain an ASN.1 NULL."  In my opinion, it is clear that the MUST
> > requirement does not apply if the parameters field is absent.  I also
> > disagree with Jim's recommendation to change the spec to state that
> > implementations MUST populate the algorithmIdentifier parameters field with
> > an ASN.1 NULL.  I believe that the text should remain unchanged.]
>
>[Jim: If present, the parameters field MUST contain an ASN.1 NULL.
>Implementations SHOULD generate SHA-1 AlgorithmIdentifiers with NULL
>parameters.
>
>I believe that the second line is a MUST not a SHOULD.  I don't object to
>the SHOULD handle if it is wrong, but generation needs to be with NULL
>parameters.]
>
>[John: This is a style choice.  I do not feel strongly about this issue.
>RFC 2630 implementations should be populating this field with NULL anyway
>(since it was a SHOULD requirement in RFC 2630).  In summary, I do not
>object to your proposed change and I do not believe that it will cause any
>interoperability problems.  Recommend the following new text: "The
>AlgorithmIdentifier parameters field MUST be present, and the parameters
>field MUST contain NULL.  Implementations SHOULD accept SHA-1
>AlgorithmIdentifiers with absent parameters as well as NULL parameters.
>
>Also, the following text should be added to section 3.2 RSA: "The
>AlgorithmIdentifier parameters field MUST be present, and the parameters
>field MUST contain NULL.  Implementations MAY accept rsaEncryption
>AlgorithmIdentifiers with absent parameters as well as NULL parameters."]

I believe that the preferred encoding is with parameters absent!  Yet, we 
allow the use of NULL for interoperability with folks that like to follow 
the convention used with MD2, MD4, and MD5.

Current text is: "Implementations SHOULD generate SHA-1 
AlgorithmIdentifiers with NULL parameters."  If we make any change, I would 
like to see the SHOULD changed to a MAY.

> > 6) Section 3.2:  Jim stated "Boy we really messed this one
> > up.  Section 3.2 should occur
> > as two different sections one for RSAwithMD5 and one for
> > RSAwithSHA1.  I will never understand how all of us missed this one.
> >
> > The OIDs for this should be:
> >        sha1withRSAEncryption (1 2 840 113549 1 1 5)
> > or
> > #define szOID_OIWSEC_sha1RSASign "1.3.14.3.2.29"
> >
> >        md5withRSAEncryption (1 2 840 113549 1 1 4)"
> >
> > [JP: I disagree with Jim's statements.  To support backwards compatibility
> > with S/MIME v2 implementations that only recognize the rsaEncryption 
> OID, we
> > specified that the rsaEncryption OID must be included in the signedData
> > signerInfo signatureAlgorithm field.  We decided not to specify the use of
> > the sha-1WithRSAEncryption, md2withRSAEncryption, or md5withRSAEncryption
> > OIDs in the signerInfo signatureAlgorithm field.]
>
>[Jim stated: John -- If I look in the examples draft, the OID that is in the
>signatureAlgorithm field of a SignerInfo field is
>   119 30   13:             SEQUENCE {
>   121 06    9:               OBJECT IDENTIFIER
>              :                 sha1withRSAEncryption (1 2 840 113549 1 1 5)
>              :                 (PKCS #1)
>   132 05    0:               NULL
>              :               }
>Not RSA.  I don't have the foggiest idea of what you are talking about for
>backwards compatability.  This is not an argument that I have ever heard
>before (I think).
>
>I think you have not looked at this correctly and ask that you re-check what
>I am saying.]
>
>
>[John: Your quote from the examples-06 document is for an RSA signature on a
>certificate (not a signedData signerInfo signatureAlgorithm field).
>Examples 5.2, 5.5 and 11.2 in the examples-06 document all include the
>rsaEncryption (1 2 840 113549 1 1 1) OID in the signerInfo
>signatureAlgorithm field as specified in RFC 2630, section 12.2.2.
>
>There is definitely an inconsistency between the specification of the
>rsaEncryption and id-dsa-with-sha1 OIDs in the signerInfo signatureAlgorithm
>field.  While RFC 2630 was being developed, I pointed out that
>inconsistency.  I was told that the rsaEncryption OID was specified to
>support backwards compatibility with S/MIME v2 implementations that only
>recognize the rsaEncryption OID.  I was also told that the signerInfo
>digestAlgorithm field indicates the algorithm used to calculate the message
>digest value used as an input to the signature algorithm, so the use of the
>rsaEncryption OID (rather than sha-1withRSAEncryption, md2withRSAEncryption,
>or md5withRSAEncryption) was appropriate.  I then proposed that the id-dsa
>OID should be used in the signerInfo signatureAlgorithm field to be
>consistent with the use of the rsaEncryption OID.  I was told that since DSA
>is always used with SHA-1, then the id-dsa-with-sha1 OID is appropriate for
>use in the signerInfo signatureAlgorithm field.
>
>Having said all of that, I would support a change to cmsalg to specify the
>use of the sha-1withRSAEncryption, md2withRSAEncryption, or
>md5withRSAEncryption OIDs (rather than  rsaEncryption) in the signerInfo
>signatureAlgorithm field.  This would be consistent with the use of those
>OIDs in PKIX X.509 certificates.  It would also eliminate the current
>situation in which the rsaEncryption OID is being used for two very
>different purposes (to indicate an RSA signature in the signerInfo
>signatureAlgorithm field and to indicate an RSA public key in a PKIX X.509
>certificate).]

The OIWSEC_sha1RSASign OID  (1.3.14.3.2.29) is not appropriate here.  This 
OID is used with X9.31 padding (not PKCS#1 v1.5 padding).  As far as I 
know, no one supports X9.31 padding in any S/MIME (v2 or v3) product, 
freeware, or tool kit.

The confusion here is which algorithm identifier goes in the public key 
certificate and which algorithm identifier goes with the signature 
value.  The text clearly needs to handle both situations.

> > 12) Section 7:  Jim stated: "I do not believe this section
> > needs any MUSTS for inclusion
> > of algorithms.  That is covered in section 4."
> >
> > [JP: Rather than delete the first sentence of Section 7, I believe that it
> > should be changed to: "CMS implementations that support the
> > previously-distributed symmetric KEK or key agreement key management
> > techniques MUST include encryption of a Triple-DES content-encryption key
> > with a Triple-DES key-encryption key using the algorithm specified in
> > Sections 7.2 and 7.3."]
>
>[Jim: I stand by my original comment.  This is a duplication of a MUST and 
>should
>be where it makes sense (where the algorithm is used) not here.]
>
>[John: I do not object to your comment.  If the MUST language is removed
>from the first sentence, then the SHOULD language should be removed from the
>second sentence.]

My recollection from the last IETF meeting was that we wanted the key wrap 
algorithm to remain mandatory to implement.  This was to facilitate mail 
list deployment.  I cannot find anything in the minutes to support my 
recollection, but I cannot find anything in the minutes that contradicts my 
recollection either.  I will start a separate message thread to debate this 
issue.

Russ


Received: by above.proper.com (8.11.3/8.11.3) id f6AFuJp22835 for ietf-smime-bks; Tue, 10 Jul 2001 08:56:19 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6AFuHm22831 for <[e-mail]>; Tue, 10 Jul 2001 08:56:18 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id <KZJ993FZ>; Tue, 10 Jul 2001 11:56:31 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "SMIME WG (E-mail)" <[e-mail]>
Subject: RE: cmsalg-00 Comments
Date: Tue, 10 Jul 2001 11:56:29 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

Thank you for your responses to my comments.  I agree with all of your
responses except that I have the following comments:


1) Section 4.1, 2nd para: Please change the following to be consistent with
Table 1:

OLD: "CMS implementations MUST include Triple-DES wrapping of Triple-DES
content-encryption keys and RC2 wrapping of RC2 content-encryption keys."

NEW: "CMS implementations MUST include Triple-DES wrapping of Triple-DES
content-encryption keys and SHOULD include RC2 wrapping of RC2
content-encryption keys."


2) Recommend the following change in your recommended text for section 4.4
as follows:

OLD: Key derivation algorithms identifiers are...

NEW: Key derivation algorithm identifiers are...


3) Recommend the following change in your recommended text for section 4.4
as follows:

OLD: The content-encryption keys encrypted with password-derived
key-encryption keys are located in the EnvelopedData RecipientInfos
PasswordRecipientInfo encryptedKey field.  The message-authentication keys
encrypted with password-derived key-encryption keys are located in the
AuthenticatedData RecipientInfos PasswordRecipientInfo encryptedKey field.

NEW: The content-encryption key encrypted with the password-derived
key-encryption key is located in the EnvelopedData RecipientInfos
PasswordRecipientInfo encryptedKey field.  The message-authentication key
encrypted with the password-derived key-encryption key is located in the
AuthenticatedData RecipientInfos PasswordRecipientInfo encryptedKey field.

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================


Received: by above.proper.com (8.11.3/8.11.3) id f6AFUnV18818 for ietf-smime-bks; Tue, 10 Jul 2001 08:30:49 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6AFUkm18808 for <[e-mail]>; Tue, 10 Jul 2001 08:30:46 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 10 Jul 2001 15:29:19 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA20302 for <[e-mail]>; Tue, 10 Jul 2001 11:30:43 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <LR8TPYGZ>; Tue, 10 Jul 2001 11:30:41 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.15]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LR8TPYGY; Tue, 10 Jul 2001 11:30:40 -0400
From: "Housley, Russ" <[e-mail]>
To: "Pawling, John" <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Tue, 10 Jul 2001 11:30:38 -0400
Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

John:

>Regarding Jim's comment 7: In previous messages, I proposed changes to the
>Section 6.1, EnvelopedData version-setting algorithm that address your
>comments.  I repeated the proposal today in my reply to Peter Gutmann's
>message sent to the S/MIME mail list.
>
>Regarding Jim's comment 11: In a previous reply to Jim (which he concurred
>with), I proposed the following:
>
>[John: I agree that a non-match is a critical security error.  Propose that
>the following sentence be added to Section 5.6 Message Signature
>Verification Process as the last paragraph:  "If the signedData signerInfo
>includes signedAttributes and the content-type attribute value is different
>from the signedData encapContentInfo eContentType value, then the CMS
>implementation MUST report an error."

How about an additional paragraph that says:  "If the SignedData signerInfo 
includes signedAttributes, then the content-type attribute value MUST match 
the SignedData encapContentInfo eContentType value."

>Propose that the following sentence be added to Section 9.3 MAC Verification
>as the last paragraph:  "If the authenticatedData includes
>authenticatedAttributes and the content-type attribute value is different
>from the authenticatedData encapContentInfo eContentType value, then the CMS
>implementation MUST report an error."]

To be parrallel, I propose a new paragraph in section 9.3 that says: "If 
the AuthenticatedData includes authenticatedAttributes, then the 
content-type attribute value MUST match the AuthenticatedData 
encapContentInfo eContentType value."

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6AFCOE17173 for ietf-smime-bks; Tue, 10 Jul 2001 08:12:24 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6AFCHm17165 for <[e-mail]>; Tue, 10 Jul 2001 08:12:18 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 10 Jul 2001 15:10:51 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA18335 for <[e-mail]>; Tue, 10 Jul 2001 11:12:17 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <LR8TPX5H>; Tue, 10 Jul 2001 11:12:14 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.15]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LR8TPX51; Tue, 10 Jul 2001 11:12:11 -0400
From: "Housley, Russ" <[e-mail]>
To: "Pawling, John" <[e-mail]>
Cc: "SMIME WG (E-mail)" <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Tue, 10 Jul 2001 11:12:10 -0400
Subject: Re: cmsalg-00 Comments
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

John:

>1) General comment: Since there are multiple techniques for using the RSA
>algorithm, please replace all occurrences of "RSA" with "RSA (PKCS #1 v1.5)"
>as appropriate.

I put "(PKCS #1 v1.5)" several places.  When the new draft comes out, you 
can tell me if I should have put it any other places.

>2) Section 1, para 2: Please change "implantations" to "implementations".

Done.

>3) Section 1, para 3:  Please change "Algorithm are be identified" to
>"Algorithms can be identified".

I changed it to "Algorithm are identified"

>4) Section 1, para 3: Please change:
>OLD: "The algorithm identifiers for each algorithm are specified"
>NEW: "The algorithm identifier for each algorithm is specified"

Done.

>5) Table 1, title: Please change "Implantation" to "Implementation".

Done.

>6) Table 1, Symmetric KEK Wrap note:  Please add this note to immediately
>follow the table: "Note 2: Only those CMS implementations that support the
>previously-distributed symmetric KEK or key agreement key management
>techniques MUST implement the Triple-DES Key Wrap algorithm."  An alternate
>solution is to change the table such that "Triple-DES Key Wrap" is a SHOULD
>implement requirement.

I disagree.  My understanding from the discussion is that we want to 
encourage support for mail lists, so we are requiring support for the key 
wrap algorithm and previously distributed KEKs.

>7) Table 1: I believe that a row should be added to represent key derivation
>algorithms since the password-based key management technique is documented
>in the rfc2630bis-01 I-D.  The draft-ietf-smime-password-03.txt I-D includes
>the PBKDF2 [RFC2898] key derivation algorithm as a MUST implement
>requirement, so I recommend that the following row should be added to Table
>1:
>
>  Algorithm Type            MUST implement         SHOULD implement
>  -----------------------------------------------------------------
>  Key Derivation            PBKDF2 [RFC2898]       --

Done.

>8) Table 1. Key Derivation Note: Please add this note to immediately follow
>the table: "Note 3: Only those CMS implementations that support the
>password-based key management technique MUST implement the PBKDF2 [RFC2898]
>key derivation algorithm."  An alternate solution would be to change the
>table to include the PBKDF2 [RFC2898] key derivation algorithm as a SHOULD
>implement requirement, but then it would not be consistent with the
>draft-ietf-smime-password-03.txt I-D.

Done.

>9) Table 1, Message Authentication note:  Please add this note to
>immediately follow the table: "Note 3: Only those CMS implementations that
>support the AuthenticatedData content-type MUST implement the HMAC with
>SHA-1 algorithm."

Done.  Here is the updated table (view it in a fixed pitch font):

             Table 1.  CMS Implementation Algorithm Requirements

    Algorithm Type            MUST implement         SHOULD implement
    -----------------------------------------------------------------
    Message Digest            SHA-1                  MD5
    Signature                 DSA and RSA (1)        --
    Key Management
       Key Agreement          --                     X9.42 E-S D-H
       Key Transport          RSA                    --
       Symmetric KEK Wrap     Triple-DES Key Wrap    RC2 Key Wrap
       Key Derivation         PBKDF2 (2)             --
    Content Encryption        Triple-DES CBC         RC2 CBC
    Message Authentication    HMAC with SHA-1 (3)    --

    Note 1:  CMS implementations MUST be able to verify signatures
             with both DSA and RSA (PKCS #1 v1.5), and they MUST be
             able to generate signatures with at least one of them.

    Note 2:  Only those CMS implementations that support password-
             based key management MUST implement the PBKDF2 key
             derivation algorithm as specified in RFC 2898 [PKCS#5].

    Note 3:  Only those CMS implementations that support
             authenticated-data MUST implement the HMAC with SHA-1
             algorithm as specified in RFC 2104 [HMAC].

>10) Section 2, intro, 3rd para: Please replace:
>
>OLD: "Digest values are located in the DigestedData digest field, and digest
>values are located in the Message Digest authenticated attribute."
>
>NEW: "Digest values are located in the DigestedData digest field and Message
>Digest attribute."

Done.

>11) Section 4, intro: Please change as follows:
>
>OLD: "CMS accommodates three general key management techniques: key
>agreement, key transport, and previously distributed symmetric
>key-encryption keys."
>
>NEW: "CMS accommodates the following general key management techniques: key
>agreement, key transport, previously distributed symmetric key-encryption
>keys, and passwords."

Done.

>12) Section 4.1, 2nd para: Please change the following:
>
>OLD: "CMS implementations MUST include Triple-DES wrapping of Triple-DES
>content-encryption keys and RC2 wrapping of RC2 content-encryption keys."
>
>NEW: "CMS implementations that support the key agreement key management
>technique MUST implement Triple-DES wrapping of Triple-DES
>content-encryption keys and SHOULD implement RC2 wrapping of RC2
>content-encryption keys."

This one is not so simple. I agree that these are required to support key 
agreement, but they are also required to support previously distributed 
KEKs.  RFC 2630 simply requires them, and I think that we should continue 
to do so to encourage the implementation of mail lists.

>13) Section 4.3, 1rst para, 1rst sent: Please change MUST to SHOULD in the
>following sentence: "CMS implementations MUST support symmetric
>key-encryption key management."  I don't believe that the S/MIME working
>group has ever agreed that the previously-distributed symmetric KEK key
>management technique is a MUST implement requirement.

As above, RFC 2630 requires implementation of the key wrap, and I think 
that we should continue to do so to encourage the implementation of mail lists.

>14) Section 4.3, 1rst para, 2nd sent: Please change the following:
>
>OLD: "CMS implementations MUST include Triple-DES key-encryption keys
>wrapping Triple-DES content-encryption keys."
>
>NEW: "CMS implementations that support the previously-distributed symmetric
>KEK or key agreement key management techniques MUST include Triple-DES
>key-encryption keys wrapping Triple-DES content-encryption keys."

As above, RFC 2630 requires implementation of the key wrap, and I think 
that we should continue to do so to encourage the implementation of mail lists.

>15) Section 4.4, Please add:
>
>"4.4 Key Derivation Algorithms
>
>Key derivation algorithms are used to convert a password into a KEK as part
>of the password-based key management technique.  CMS implementations that
>support the password-based key management technique MUST implement the
>PBKDF2 [RFC2898] key derivation algorithm.  The
>KeyDerivationAlgorithmIdentifer identifies the key-derivation algorithm, and
>any associated parameters, used to derive the KEK from the user-supplied
>password.  The object identifier for the PBKDF2 [RFC2898] key derivation
>algorithm is TBD."

Here is the text that I added to create section 4.4:

4.4  Key Derivation Algorithms

    Key derivation algorithms are used to convert a password into a key-
    encryption key as part of the password-based key management
    technique.  CMS implementations that support the password-based key
    management technique MUST implement the PBKDF2 key derivation
    algorithm specified in RFC 2898 [PKCS#5].

    Key derivation algorithms identifiers are located in the
    EnvelopedData RecipientInfos PasswordRecipientInfo
    keyDerivationAlgorithm and AuthenticatedData RecipientInfos
    PasswordRecipientInfo keyDerivationAlgorithm fields.

    The key-encryption key that is derived from the password is used to
    encrypt the content-encryption key

    The content-encryption keys encrypted with password-derived key-
    encryption keys are located in the EnvelopedData RecipientInfos
    PasswordRecipientInfo encryptedKey field.  The message-authentication
    keys encrypted with password-derived key-encryption keys are located
    in the AuthenticatedData RecipientInfos PasswordRecipientInfo
    encryptedKey field.

4.4.1  PBKDF2

    The PBKDF2 key derivation algorithm specified in RFC 2898 [PKCS#5].
    The KeyDerivationAlgorithmIdentifer identifies the key-derivation
    algorithm, and any associated parameters, used to derive the key-
    encryption key from the user-supplied password.  The algorithm
    identifier for the PBKDF2 key derivation algorithm is:

       id-PBKDF2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
           rsadsi(113549) pkcs(1) pkcs-5(5) 12 }

    The AlgorithmIdentifier parameter field MUST be PBKDF2-params:

       PBKDF2-params ::= SEQUENCE {
         salt CHOICE {
           specified OCTET STRING,
           otherSource AlgorithmIdentifier },
         iterationCount INTEGER (1..MAX),
         keyLength INTEGER (1..MAX) OPTIONAL,
         prf AlgorithmIdentifier DEFAULT hMAC-SHA1 }


>16) Section 5, 1rst para: Please change "MS" to "CMS" in the following: "MS
>implementations SHOULD support Two-Key Triple-DES in CBC mode."

Done.

>17) Section 7, 1rst paragraph: Please change the following:
>
>OLD: "CMS implementations MUST include encryption of a Triple-DES
>content-encryption key with a Triple-DES key-encryption key using the
>algorithm specified in Sections 7.2 and 7.3."
>
>NEW: "CMS implementations that support the previously-distributed symmetric
>KEK or key agreement key management techniques MUST include encryption of a
>Triple-DES content-encryption key with a Triple-DES key-encryption key using
>the algorithm specified in Sections 7.2 and 7.3."

As above, RFC 2630 requires implementation of the key wrap, and I think 
that we should continue to do so to encourage the implementation of mail lists.

>18) Section 7.2, bullet 2: Please change "Section 12.6.1" to "Section 7.1".

Done.  Thanks for the careful read necessary to catch this one.

>19) Section 7.3, bullet 7: Please change "Section 12.6.1" to "Section 7.1".

Done.

>20) Section 7.4, bullet 4: Please change "Section 12.6.1" to "Section 7.1".

Done.

>21) Section 7.5, bullet 7: Please change "Section 12.6.1" to "Section 7.1".

Done.

>22) Security Considerations: Please delete the countersignature section
>because it is much more applicable to the rfc2630bis-01 I-D.

Done.

Russ


Received: by above.proper.com (8.11.3/8.11.3) id f6AEm8W13847 for ietf-smime-bks; Tue, 10 Jul 2001 07:48:08 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6AEm7m13843 for <[e-mail]>; Tue, 10 Jul 2001 07:48:07 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id <KZJ99NP9>; Tue, 10 Jul 2001 10:48:21 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: [e-mail]
Subject: RE: More Comments to rfc2630bis-01
Date: Tue, 10 Jul 2001 10:48:18 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ and Jim,

I see your point.  You guys have convinced me that Section 6.2 should
continue to mandate that "implementations MUST support key transport, key
agreement, and  previously distributed symmetric key-encryption keys, as
represented by ktri, kari, and kekri, respectively".  In fact, the S/MIME
Freeware Library (SFL) was developed using the same architectural principles
as discussed in your replies.  The SFL is composed of a high-level library
that implements the RFC2630 and RFC2634 specifications independently of the
crypto algorithms used to protect a specific object. The SFL high-level
library makes calls to a generic, algorithm-independent crypto API.  Using
this architecture, the high-level SFL library does not need to be modified
to support new crypto libraries, algorithms or tokens.  The SFL source code
is freely available to everyone from
<http://www.getronicsgov.com/hot/sfl_home.htm>.  

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================


-----Original Message-----
From: Housley, Russ [mailto:[e-mail]]
Sent: Tuesday, July 10, 2001 9:24 AM
To: [e-mail]
Cc: [e-mail]
Subject: RE: More Comments to rfc2630bis-01


John:

In an architecture where a cryptographic API is employed, the protocol 
implementation must be able to handle any of the algorithms that might be 
offered by the cryptographic implementation behind the API.  When the 
cryptographic implementation is based on a hardware token (e.g., smart 
card), the protocol implementation can encounter a large number of 
different algorithm combinations.

I would like to see the specifications encourage support for modular 
implemntations that support hardware tokens.

Russ


At 04:27 PM 7/9/2001 -0700, Jim Schaad wrote:

>John,
>
>I am afraid I must disagree with you on this issue.
>
>IMHO, rfc2630bis should require implementation of all of the defined
>alternatives.  What we are looking at here is the toolkit side of the
issue.
>S/MIME can come along and require implementation of only a partial set of
>the alternatives by requiring a partial set of the algorithms.
>
>I think that toolkits that do not implement all of the different
>alternatives have to state that they are only partially compliant with what
>will hopefully be the CMS Standard.  This is not an issue for toolkits that
>are implemented for specific protocals.  It may be that this point of view
>will be modified in some way by the lack of implementations for items.  But
>that is the only reason that I think one of these items should be lowered
>from MUST implement to MAY implement (note that I see no benifit here for
>SHOULD implement).
>
>jim


Received: by above.proper.com (8.11.3/8.11.3) id f6AE9QQ12297 for ietf-smime-bks; Tue, 10 Jul 2001 07:09:26 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6AE9Pm12293 for <[e-mail]>; Tue, 10 Jul 2001 07:09:26 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id <KZJ99N1M>; Tue, 10 Jul 2001 10:09:40 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: [e-mail]
Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01
Date: Tue, 10 Jul 2001 10:09:34 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ and Jim,

Regarding Jim's comment 7: In previous messages, I proposed changes to the
Section 6.1, EnvelopedData version-setting algorithm that address your
comments.  I repeated the proposal today in my reply to Peter Gutmann's
message sent to the S/MIME mail list.

Regarding Jim's comment 11: In a previous reply to Jim (which he concurred
with), I proposed the following: 

[John: I agree that a non-match is a critical security error.  Propose that
the following sentence be added to Section 5.6 Message Signature
Verification Process as the last paragraph:  "If the signedData signerInfo
includes signedAttributes and the content-type attribute value is different
from the signedData encapContentInfo eContentType value, then the CMS
implementation MUST report an error."  

Propose that the following sentence be added to Section 9.3 MAC Verification
as the last paragraph:  "If the authenticatedData includes
authenticatedAttributes and the content-type attribute value is different
from the authenticatedData encapContentInfo eContentType value, then the CMS
implementation MUST report an error."]

Regarding Jim's comment 12: I agree with your recommended text.

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================



Received: by above.proper.com (8.11.3/8.11.3) id f6ADpUl11879 for ietf-smime-bks; Tue, 10 Jul 2001 06:51:30 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6ADpSm11874 for <[e-mail]>; Tue, 10 Jul 2001 06:51:29 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id <KZJ99NAA>; Tue, 10 Jul 2001 09:51:42 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: [e-mail]
Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01
Date: Tue, 10 Jul 2001 09:51:31 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

I agree that the Password-based Encryption spec should not include
requirements for setting the EnvelopedData version field.  I agree that the
rfc2630bis spec is the correct document in which to specify the
EnvelopedData version-setting algorithm.  I proposed that the rfc2630bis
spec, Section 6.1, EnvelopedData version-setting algorithm should be changed
as follows: (same as proposed in my 7/2 reply to Russ and 7/5 reply to Jim):
 
    [*** NEW ***] version is the syntax version number.  The
    appropriate value depends on originatorInfo, RecipientInfo, and
    unprotectedAttrs.  The version MUST be assigned as follows:
 
     IF ((originatorInfo is present) AND 
 	 (any version 2 attribute certificates are present)) OR
 	 (any RecipientInfo structures are pwri CHOICE) OR
  	 (any RecipientInfo structures are ori CHOICE)
     THEN version is 3
     ELSE
 	 IF (originatorInfo is present) OR
 	    (unprotectedAttrs is present) OR
 	    (any RecipientInfo structures are a version other than 0)
        THEN version is 2
        ELSE version is 0]

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================

 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Tuesday, July 10, 2001 1:21 PM
To: [e-mail]; [e-mail];
[e-mail]
Cc: [e-mail]
Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01


"Jim Schaad" <[e-mail]> writes:

>I do not think that the EnvelopedData version number field was ever
addressed
>in the Peter's document.  I agree that the algorithm needs to be updated.

That was deliberate, I don't see that a new RecipientInfo definition (or
anything similar) should be placing contraints on RFC 2630.  If there's a
need
to change EnvelopedData then it should be done where it's defined, not in an
external document.

(While I'm commenting on this, I also feel that the best way to resolve this
is
to issue a draft which leaves the issue unspecified, then in the next draft
write down what it is that implementations are doing, which will ensure that
(a) it's consensus behaviour and (b) the RFC reflects the real world.
Trying
to second-guess the behaviour of implementations seems risky at best).

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6ADNtO11198 for ietf-smime-bks; Tue, 10 Jul 2001 06:23:55 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6ADNnm11194 for <[e-mail]>; Tue, 10 Jul 2001 06:23:49 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 10 Jul 2001 13:22:21 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA07007 for <[e-mail]>; Tue, 10 Jul 2001 09:23:49 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <LR8TPVRA>; Tue, 10 Jul 2001 09:23:46 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.15]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LR8TPVQ6; Tue, 10 Jul 2001 09:23:40 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Tue, 10 Jul 2001 09:23:36 -0400
Subject: RE: More Comments to rfc2630bis-01
In-Reply-To: <000d01c108ce$c6f7d360$[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

John:

In an architecture where a cryptographic API is employed, the protocol 
implementation must be able to handle any of the algorithms that might be 
offered by the cryptographic implementation behind the API.  When the 
cryptographic implementation is based on a hardware token (e.g., smart 
card), the protocol implementation can encounter a large number of 
different algorithm combinations.

I would like to see the specifications encourage support for modular 
implemntations that support hardware tokens.

Russ


At 04:27 PM 7/9/2001 -0700, Jim Schaad wrote:

>John,
>
>I am afraid I must disagree with you on this issue.
>
>IMHO, rfc2630bis should require implementation of all of the defined
>alternatives.  What we are looking at here is the toolkit side of the issue.
>S/MIME can come along and require implementation of only a partial set of
>the alternatives by requiring a partial set of the algorithms.
>
>I think that toolkits that do not implement all of the different
>alternatives have to state that they are only partially compliant with what
>will hopefully be the CMS Standard.  This is not an issue for toolkits that
>are implemented for specific protocals.  It may be that this point of view
>will be modified in some way by the lack of implementations for items.  But
>that is the only reason that I think one of these items should be lowered
>from MUST implement to MAY implement (note that I see no benifit here for
>SHOULD implement).
>
>jim
>
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]On Behalf Of Pawling, John
> > Sent: Monday, July 09, 2001 2:28 PM
> > To: SMIME WG (E-mail)
> > Subject: RE: More Comments to rfc2630bis-01
> >
> >
> >
> > Russ,
> >
> > I agree that the "MUST implement" requirements regarding
> > support of the
> > alternatives within the RecipientInfo CHOICE are indirect in
> > RFC 2630.  In
> > my opinion, they should also be indirect in rfc2630bis.  My
> > recommended text
> > provides this indirection.  The "MUST implement" algorithms
> > specified in
> > cmsalg will indirectly mandate which alternatives within the
> > RecipientInfo
> > CHOICE are "MUST implement" requirements.
> >
> > I believe that my recommended text provides the IETF with flexibility
> > regarding the separation of the protocol and the mandatory to
> > implement
> > algorithms.  Compliant implementations will support  the
> > alternatives within
> > the RecipientInfo CHOICE required to support the
> > mandatory-to-implement
> > algorithms stated in cmsalg.  If the IETF changes the
> > mandatory-to-implement
> > algorithms in cmsalg such that a different RecipientInfo
> > CHOICE is required,
> > then vendors will enhance their implementations to support
> > the required
> > RecipientInfo CHOICE in conjunction with implementing the new
> > algorithm.
> >
> > Compliance testing is another issue with the current
> > rfc2630bis-01 text.
> > For example, how will a product be tested for compliance with
> > the "MUST
> > implement" KARI alternative in the RecipientInfo CHOICE if
> > that product does
> > not implement any key agreement algorithms?  Similar question
> > regarding the
> > KEKRI alternative?  Will vendors be forced to implement
> > algorithms solely to
> > test their compliance with the "MUST implement" alternatives
> > within the
> > RecipientInfo CHOICE?
> >
> > ===========================================
> > John Pawling, [e-mail]
> > Getronics Government Solutions, LLC
> > ==========================================
> >
> >
> > -----Original Message-----
> > From: Housley, Russ [mailto:[e-mail]]
> > Sent: Monday, July 09, 2001 4:23 PM
> > To: Pawling, John
> > Cc: SMIME WG (E-mail)
> > Subject: Re: More Comments to rfc2630bis-01
> >
> >
> > John:
> >
> > This is not quite true.  The MUST implement statements were
> > indirect. They
> > came from the mandatory to implement algorithms.  In order to support
> > Ephemeral-Static Diffie-Helman, one must implement kari.
> >
> > At the last IETF meeting, we discussed the desire for
> > separation of the
> > protocol and the mandatory to implement algorithm.  For the
> > IETF to have
> > any flexibility in this area, the protocol implementation
> > must support the
> > major choices.
> >
> > Russ
> >
> > At 04:40 PM 7/5/2001 -0400, Pawling, John wrote:
> >
> > >All,
> > >
> > >I have the following comment to rfc2630bis-01 (in addition to those
> > >submitted on 27 June):
> > >
> > >1) Section 6.2, RecipientInfo description:  RFC 2630 did not
> > include any
> > >"MUST implement" requirements regarding support of the
> > alternatives within
> > >the RecipientInfo CHOICE.  I don't believe that rfc2630bis
> > should include
> > >any such "MUST implement" requirements either.  Please make
> > the following
> > >change to the third paragraph:
> > >
> > >OLD:
> > >[*** NEW ***] Implementations MUST support key transport,
> > key agreement,
> > and
> > >previously distributed symmetric key-encryption keys, as
> > represented by
> > >ktri, kari, and kekri, respectively.
> > >Implementations MAY support the password-based key management as
> > represented
> > >by pwri.  Implementations MAY support any other key
> > management technique as
> > >represented by ori.
> > >
> > >NEW:
> > >[*** NEW ***] The ktri, kari, kekri, and pwri alternatives in the
> > >RecipientInfo CHOICE are used for the key transport, key agreement,
> > >previously distributed symmetric key-encryption keys, and
> > password-based
> > key
> > >management techniques, respectively.  The ori alternative in the
> > >RecipientInfo CHOICE is used for any other key management technique.
> > >
> > >===========================================
> > >John Pawling, [e-mail]
> > >Getronics Government Solutions, LLC
> > >===========================================
> >


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6ADHIw11012 for ietf-smime-bks; Tue, 10 Jul 2001 06:17:18 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6ADHHm11007 for <[e-mail]>; Tue, 10 Jul 2001 06:17:17 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 10 Jul 2001 13:15:49 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA06401 for <[e-mail]>; Tue, 10 Jul 2001 09:17:16 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <LR8TPVNR>; Tue, 10 Jul 2001 09:17:14 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.15]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LR8TPVN3; Tue, 10 Jul 2001 09:17:12 -0400
From: "Housley, Russ" <[e-mail]>
To: "Pawling, John" <[e-mail]>
Cc: "SMIME WG (E-mail)" <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Tue, 10 Jul 2001 09:15:23 -0400
Subject: RE: More Comments to rfc2630bis-01
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

John:

The problem is that the advice that we are getting from the IESG says that 
we cannot proceed in a completely modular fashion.  If the protocol 
specification depends on the algorithm specification, then they must 
proceed from proposed o Draft to Full Standard together.  A change to the 
algorithm specification will cause both documents to return to Proposed 
Standard!

I would expect a change from Triple-DES to AES in the future...  Given this 
situation, maybe sooner is better than later.

Russ

At 05:27 PM 7/9/2001 -0400, Pawling, John wrote:

>Russ,
>
>I agree that the "MUST implement" requirements regarding support of the
>alternatives within the RecipientInfo CHOICE are indirect in RFC 2630.  In
>my opinion, they should also be indirect in rfc2630bis.  My recommended text
>provides this indirection.  The "MUST implement" algorithms specified in
>cmsalg will indirectly mandate which alternatives within the RecipientInfo
>CHOICE are "MUST implement" requirements.
>
>I believe that my recommended text provides the IETF with flexibility
>regarding the separation of the protocol and the mandatory to implement
>algorithms.  Compliant implementations will support  the alternatives within
>the RecipientInfo CHOICE required to support the mandatory-to-implement
>algorithms stated in cmsalg.  If the IETF changes the mandatory-to-implement
>algorithms in cmsalg such that a different RecipientInfo CHOICE is required,
>then vendors will enhance their implementations to support the required
>RecipientInfo CHOICE in conjunction with implementing the new algorithm.
>
>Compliance testing is another issue with the current rfc2630bis-01 text.
>For example, how will a product be tested for compliance with the "MUST
>implement" KARI alternative in the RecipientInfo CHOICE if that product does
>not implement any key agreement algorithms?  Similar question regarding the
>KEKRI alternative?  Will vendors be forced to implement algorithms solely to
>test their compliance with the "MUST implement" alternatives within the
>RecipientInfo CHOICE?
>
>===========================================
>John Pawling, [e-mail]
>Getronics Government Solutions, LLC
>==========================================
>
>
>-----Original Message-----
>From: Housley, Russ [mailto:[e-mail]]
>Sent: Monday, July 09, 2001 4:23 PM
>To: Pawling, John
>Cc: SMIME WG (E-mail)
>Subject: Re: More Comments to rfc2630bis-01
>
>
>John:
>
>This is not quite true.  The MUST implement statements were indirect. They
>came from the mandatory to implement algorithms.  In order to support
>Ephemeral-Static Diffie-Helman, one must implement kari.
>
>At the last IETF meeting, we discussed the desire for separation of the
>protocol and the mandatory to implement algorithm.  For the IETF to have
>any flexibility in this area, the protocol implementation must support the
>major choices.
>
>Russ
>
>At 04:40 PM 7/5/2001 -0400, Pawling, John wrote:
>
> >All,
> >
> >I have the following comment to rfc2630bis-01 (in addition to those
> >submitted on 27 June):
> >
> >1) Section 6.2, RecipientInfo description:  RFC 2630 did not include any
> >"MUST implement" requirements regarding support of the alternatives within
> >the RecipientInfo CHOICE.  I don't believe that rfc2630bis should include
> >any such "MUST implement" requirements either.  Please make the following
> >change to the third paragraph:
> >
> >OLD:
> >[*** NEW ***] Implementations MUST support key transport, key agreement,
>and
> >previously distributed symmetric key-encryption keys, as represented by
> >ktri, kari, and kekri, respectively.
> >Implementations MAY support the password-based key management as
>represented
> >by pwri.  Implementations MAY support any other key management technique as
> >represented by ori.
> >
> >NEW:
> >[*** NEW ***] The ktri, kari, kekri, and pwri alternatives in the
> >RecipientInfo CHOICE are used for the key transport, key agreement,
> >previously distributed symmetric key-encryption keys, and password-based
>key
> >management techniques, respectively.  The ori alternative in the
> >RecipientInfo CHOICE is used for any other key management technique.
> >
> >===========================================
> >John Pawling, [e-mail]
> >Getronics Government Solutions, LLC
> >===========================================


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6A5LL609316 for ietf-smime-bks; Mon, 9 Jul 2001 22:21:21 -0700 (PDT)
Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6A5LJm09312 for <[e-mail]>; Mon, 9 Jul 2001 22:21:19 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id RAA11815; Tue, 10 Jul 2001 17:21:07 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <99474246720140>; Tue, 10 Jul 2001 17:21:07 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01
Cc: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Tue, 10 Jul 2001 17:21:07 (NZST)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Jim Schaad" <[e-mail]> writes:

>I do not think that the EnvelopedData version number field was ever addressed
>in the Peter's document.  I agree that the algorithm needs to be updated.

That was deliberate, I don't see that a new RecipientInfo definition (or
anything similar) should be placing contraints on RFC 2630.  If there's a need
to change EnvelopedData then it should be done where it's defined, not in an
external document.

(While I'm commenting on this, I also feel that the best way to resolve this is
to issue a draft which leaves the issue unspecified, then in the next draft
write down what it is that implementations are doing, which will ensure that
(a) it's consensus behaviour and (b) the RFC reflects the real world.  Trying
to second-guess the behaviour of implementations seems risky at best).

Peter.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f69NoMQ03497 for ietf-smime-bks; Mon, 9 Jul 2001 16:50:22 -0700 (PDT)
Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f69NoLm03493 for <[e-mail]>; Mon, 9 Jul 2001 16:50:21 -0700 (PDT)
Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate3.mot.com (motgate3 2.1) with ESMTP id QAA17398 for <[e-mail]>; Mon, 9 Jul 2001 16:43:20 -0700 (MST)]
Received: [from az33exi01.corp.mot.com (az33exi01.corp.mot.com [199.2.84.10]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id QAA09597 for <[e-mail]>; Mon, 9 Jul 2001 16:43:16 -0700 (MST)]
Received: by az33exi01.corp.mot.com with Internet Mail Service (5.5.2653.19) id <3D4G4PCJ>; Mon, 9 Jul 2001 16:50:23 -0700
Message-ID: <[e-mail]>
From: Musy Michel-P28089 <[e-mail]>
To: "Pawling, John" <[e-mail]>
Cc: "SMIME WG (E-mail)" <[e-mail]>
Subject: RE: New x400wrap I-D? (was RE: SMIME-TYPE question)
Date: Mon, 9 Jul 2001 16:50:20 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thanks to Jim for the clarification, to John for confirming and helping
by suggesting publication of the new version of the related document.

Michel

-----Original Message-----
From: Pawling, John [mailto:[e-mail]]
Sent: Monday, July 09, 2001 12:58 PM
To: 'Musy Michel-P28089'
Cc: SMIME WG (E-mail)
Subject: New x400wrap I-D? (was RE: SMIME-TYPE question)



Michel,

I agree with everything that Jim stated except that I have not seen the
updated x400wrap document to which he referred.  The x400wrap authors should
submit the updated document so that implementers can develop to the same
spec.  

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================

-----Original Message-----
From: Jim Schaad [mailto:[e-mail]]
Sent: Friday, July 06, 2001 6:39 PM
To: 'Musy Michel-P28089'; 'Ietf-Smime (E-mail)'
Subject: RE: SMIME-TYPE question



Michel,

I understand where you went wrong -- you didn't.  I have seen a later draft
of this document and this has been changed.  Since EncapsulatedContentInfo
and ContentInfo have the exact same content (i.e. an OID and ANY), having
both is actually redunant.  This means that the ContentInfo can be omitted
and just the EncapsulatedContentInfo used to convay the same information.

jim


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f69NRuH03082 for ietf-smime-bks; Mon, 9 Jul 2001 16:27:56 -0700 (PDT)
Received: from femail4.sdc1.sfba.home.com (femail4.sdc1.sfba.home.com [24.0.95.84]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f69NRtm03077 for <[e-mail]>; Mon, 9 Jul 2001 16:27:55 -0700 (PDT)
Received: from revelation ([65.4.166.11]) by femail4.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010709232754.QABT9548.femail4.sdc1.sfba.home.com@revelation>; Mon, 9 Jul 2001 16:27:54 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Pawling, John'" <[e-mail]>, "'SMIME WG \(E-mail\)'" <[e-mail]>
Subject: RE: More Comments to rfc2630bis-01
Date: Mon, 9 Jul 2001 16:27:52 -0700
Message-ID: <000d01c108ce$c6f7d360$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

John,

I am afraid I must disagree with you on this issue.

IMHO, rfc2630bis should require implementation of all of the defined
alternatives.  What we are looking at here is the toolkit side of the issue.
S/MIME can come along and require implementation of only a partial set of
the alternatives by requiring a partial set of the algorithms.

I think that toolkits that do not implement all of the different
alternatives have to state that they are only partially compliant with what
will hopefully be the CMS Standard.  This is not an issue for toolkits that
are implemented for specific protocals.  It may be that this point of view
will be modified in some way by the lack of implementations for items.  But
that is the only reason that I think one of these items should be lowered
from MUST implement to MAY implement (note that I see no benifit here for
SHOULD implement).

jim

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Pawling, John
> Sent: Monday, July 09, 2001 2:28 PM
> To: SMIME WG (E-mail)
> Subject: RE: More Comments to rfc2630bis-01
>
>
>
> Russ,
>
> I agree that the "MUST implement" requirements regarding
> support of the
> alternatives within the RecipientInfo CHOICE are indirect in
> RFC 2630.  In
> my opinion, they should also be indirect in rfc2630bis.  My
> recommended text
> provides this indirection.  The "MUST implement" algorithms
> specified in
> cmsalg will indirectly mandate which alternatives within the
> RecipientInfo
> CHOICE are "MUST implement" requirements.
>
> I believe that my recommended text provides the IETF with flexibility
> regarding the separation of the protocol and the mandatory to
> implement
> algorithms.  Compliant implementations will support  the
> alternatives within
> the RecipientInfo CHOICE required to support the
> mandatory-to-implement
> algorithms stated in cmsalg.  If the IETF changes the
> mandatory-to-implement
> algorithms in cmsalg such that a different RecipientInfo
> CHOICE is required,
> then vendors will enhance their implementations to support
> the required
> RecipientInfo CHOICE in conjunction with implementing the new
> algorithm.
>
> Compliance testing is another issue with the current
> rfc2630bis-01 text.
> For example, how will a product be tested for compliance with
> the "MUST
> implement" KARI alternative in the RecipientInfo CHOICE if
> that product does
> not implement any key agreement algorithms?  Similar question
> regarding the
> KEKRI alternative?  Will vendors be forced to implement
> algorithms solely to
> test their compliance with the "MUST implement" alternatives
> within the
> RecipientInfo CHOICE?
>
> ===========================================
> John Pawling, [e-mail]
> Getronics Government Solutions, LLC
> ==========================================
>
>
> -----Original Message-----
> From: Housley, Russ [mailto:[e-mail]]
> Sent: Monday, July 09, 2001 4:23 PM
> To: Pawling, John
> Cc: SMIME WG (E-mail)
> Subject: Re: More Comments to rfc2630bis-01
>
>
> John:
>
> This is not quite true.  The MUST implement statements were
> indirect. They
> came from the mandatory to implement algorithms.  In order to support
> Ephemeral-Static Diffie-Helman, one must implement kari.
>
> At the last IETF meeting, we discussed the desire for
> separation of the
> protocol and the mandatory to implement algorithm.  For the
> IETF to have
> any flexibility in this area, the protocol implementation
> must support the
> major choices.
>
> Russ
>
> At 04:40 PM 7/5/2001 -0400, Pawling, John wrote:
>
> >All,
> >
> >I have the following comment to rfc2630bis-01 (in addition to those
> >submitted on 27 June):
> >
> >1) Section 6.2, RecipientInfo description:  RFC 2630 did not
> include any
> >"MUST implement" requirements regarding support of the
> alternatives within
> >the RecipientInfo CHOICE.  I don't believe that rfc2630bis
> should include
> >any such "MUST implement" requirements either.  Please make
> the following
> >change to the third paragraph:
> >
> >OLD:
> >[*** NEW ***] Implementations MUST support key transport,
> key agreement,
> and
> >previously distributed symmetric key-encryption keys, as
> represented by
> >ktri, kari, and kekri, respectively.
> >Implementations MAY support the password-based key management as
> represented
> >by pwri.  Implementations MAY support any other key
> management technique as
> >represented by ori.
> >
> >NEW:
> >[*** NEW ***] The ktri, kari, kekri, and pwri alternatives in the
> >RecipientInfo CHOICE are used for the key transport, key agreement,
> >previously distributed symmetric key-encryption keys, and
> password-based
> key
> >management techniques, respectively.  The ori alternative in the
> >RecipientInfo CHOICE is used for any other key management technique.
> >
> >===========================================
> >John Pawling, [e-mail]
> >Getronics Government Solutions, LLC
> >===========================================
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f69NL9f02975 for ietf-smime-bks; Mon, 9 Jul 2001 16:21:09 -0700 (PDT)
Received: from femail4.sdc1.sfba.home.com (femail4.sdc1.sfba.home.com [24.0.95.84]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f69NL8m02971 for <[e-mail]>; Mon, 9 Jul 2001 16:21:08 -0700 (PDT)
Received: from revelation ([65.4.166.11]) by femail4.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010709232056.PSOG9548.femail4.sdc1.sfba.home.com@revelation>; Mon, 9 Jul 2001 16:20:56 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01
Date: Mon, 9 Jul 2001 16:20:54 -0700
Message-ID: <000c01c108cd$ce24a330$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

> -----Original Message-----
> From: Housley, Russ [mailto:[e-mail]]
> Sent: Monday, July 09, 2001 2:00 PM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01
>
>
> Jim & John:
>
> > > 7) Section 6.2.4, recommend changing
> PasswordRecipientInfo version value to
> > > 1.  This would cause the EnvelopedData version number to
> be set to 2 if the
> > > PasswordRecipientInfo was present.  This would assist
> with debugging and
> > > error reporting.
> >
> >I disagree with this.  This is the version struture of the
> >PasswordRecipientInfo structure and is independent of the
> EnvelopedData
> >version number.
> >
> >I think however that the version number of EnvelopedData
> needs to be 3 if
> >either PasswordRecipientInfo or OtherRecipient is present as
> these are "new"
> >structure and thus modify the behavior of the processing an
> EnvelopedData
> >object.  I don't think that this will necessaryly need to be
> changed in the
> >future as we now have an explicit statement that
> implemenations MUST handle
> >other choices in the RecipientInfo.  This was not imposed in the past
> >however.
>
> I cannot find anything in draft-ietf-smime-password-03 regarding the
> EnvelopedData version value when PasswordRecipientInfo is used.
>
> RFC 2630 says: "If any of the RecipientInfo structures
> included have a
> version other than 0, then the version shall be 2."  However,
> this text was
> written before PasswordRecipientInfo was defined with a
> version of zero.
>
> The proposed algorithm for version in RFC2630bis is:
>     IF (originatorInfo is present) OR (unprotectedAttrs is present)
>     THEN
>        IF (any version 2 attribute certificates are present)
>        THEN version is 3
>        ELSE version is 2
>     ELSE
>        IF (any RecipientInfo structures are a version other than 0)
>        THEN version is 2
>        ELSE version is 0
>
> Based on this discussion, this algorithm is not acceptable.
> It needs to be
> modified to set version to 3 if either PasswordRecipientInfo or
> OtherRecipientInfo is present.  Agree?

I do not think that the EnvelopedData version number field was ever
addressed in the Peter's document.  I agree that the algorithm needs to be
updated.

>
> > > 11) Section 11.1 Content Type:  Please add as last
> sentence of first
> > > paragraph: "The content-type attribute value MUST match the
> > encapContentInfo
> > > eContentType value in the signed-data or authenticated-data."
> >
> >Do we consider a non-match to be a signature failure?  This
> is not currently
> >stated anyplace.  I think that we should probably add this.
>
> I have added the sentence suggested by John.  What more are
> you proposing.

I was thinking about putting it into section 5.6 as part of the signature
validation process.

>
> > > 12) Section 11.2 Message Digest: Please replace the last
> > > paragraph with the
> > > following:
> > >
> > >    "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 message-digest
> > > attribute.  Similarly,
> > >    the AuthAttributes in an AuthenticatedData MUST NOT
> > > include multiple
> > >    instances of the message-digest attribute."
> >
> >I agree that the AuthAttributes stateemnt needs to be added.
>  However, I
> >think this should be a MUST not a MUST NOT as MUST NOT is
> not testable.
>
> Okay.  How about:
>
>     The SignedAttributes syntax and AuthAttributes syntax are each
>     defined as a SET OF Attributes.  The SignedAttributes in
> a signerInfo
>     MUST include only one instance of the message-digest attribute.
>     Similarly, the AuthAttributes in an AuthenticatedData MUST include
>     only one instance of the message-digest attribute.

looks good

>
> Russ
>

jim



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f69LRhP29736 for ietf-smime-bks; Mon, 9 Jul 2001 14:27:43 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f69LRgm29732 for <[e-mail]>; Mon, 9 Jul 2001 14:27:42 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id <KZJ99J0K>; Mon, 9 Jul 2001 17:27:58 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "SMIME WG (E-mail)" <[e-mail]>
Subject: RE: More Comments to rfc2630bis-01
Date: Mon, 9 Jul 2001 17:27:57 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

I agree that the "MUST implement" requirements regarding support of the
alternatives within the RecipientInfo CHOICE are indirect in RFC 2630.  In
my opinion, they should also be indirect in rfc2630bis.  My recommended text
provides this indirection.  The "MUST implement" algorithms specified in
cmsalg will indirectly mandate which alternatives within the RecipientInfo
CHOICE are "MUST implement" requirements.

I believe that my recommended text provides the IETF with flexibility
regarding the separation of the protocol and the mandatory to implement
algorithms.  Compliant implementations will support  the alternatives within
the RecipientInfo CHOICE required to support the mandatory-to-implement
algorithms stated in cmsalg.  If the IETF changes the mandatory-to-implement
algorithms in cmsalg such that a different RecipientInfo CHOICE is required,
then vendors will enhance their implementations to support the required
RecipientInfo CHOICE in conjunction with implementing the new algorithm. 

Compliance testing is another issue with the current rfc2630bis-01 text.
For example, how will a product be tested for compliance with the "MUST
implement" KARI alternative in the RecipientInfo CHOICE if that product does
not implement any key agreement algorithms?  Similar question regarding the
KEKRI alternative?  Will vendors be forced to implement algorithms solely to
test their compliance with the "MUST implement" alternatives within the
RecipientInfo CHOICE?

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
==========================================
   

-----Original Message-----
From: Housley, Russ [mailto:[e-mail]]
Sent: Monday, July 09, 2001 4:23 PM
To: Pawling, John
Cc: SMIME WG (E-mail)
Subject: Re: More Comments to rfc2630bis-01


John:

This is not quite true.  The MUST implement statements were indirect. They 
came from the mandatory to implement algorithms.  In order to support 
Ephemeral-Static Diffie-Helman, one must implement kari.

At the last IETF meeting, we discussed the desire for separation of the 
protocol and the mandatory to implement algorithm.  For the IETF to have 
any flexibility in this area, the protocol implementation must support the 
major choices.

Russ

At 04:40 PM 7/5/2001 -0400, Pawling, John wrote:

>All,
>
>I have the following comment to rfc2630bis-01 (in addition to those
>submitted on 27 June):
>
>1) Section 6.2, RecipientInfo description:  RFC 2630 did not include any
>"MUST implement" requirements regarding support of the alternatives within
>the RecipientInfo CHOICE.  I don't believe that rfc2630bis should include
>any such "MUST implement" requirements either.  Please make the following
>change to the third paragraph:
>
>OLD:
>[*** NEW ***] Implementations MUST support key transport, key agreement,
and
>previously distributed symmetric key-encryption keys, as represented by
>ktri, kari, and kekri, respectively.
>Implementations MAY support the password-based key management as
represented
>by pwri.  Implementations MAY support any other key management technique as
>represented by ori.
>
>NEW:
>[*** NEW ***] The ktri, kari, kekri, and pwri alternatives in the
>RecipientInfo CHOICE are used for the key transport, key agreement,
>previously distributed symmetric key-encryption keys, and password-based
key
>management techniques, respectively.  The ori alternative in the
>RecipientInfo CHOICE is used for any other key management technique.
>
>===========================================
>John Pawling, [e-mail]
>Getronics Government Solutions, LLC
>===========================================


Received: by above.proper.com (8.11.3/8.11.3) id f69LHx829525 for ietf-smime-bks; Mon, 9 Jul 2001 14:17:59 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.3/8.11.3) with SMTP id f69LHvm29521 for <[e-mail]>; Mon, 9 Jul 2001 14:17:57 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 9 Jul 2001 21:16:32 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id RAA28340 for <[e-mail]>; Mon, 9 Jul 2001 17:17:59 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <LR8TPPWD>; Mon, 9 Jul 2001 17:17:57 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.105]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LR8TPPWA; Mon, 9 Jul 2001 17:17:51 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Mon, 09 Jul 2001 17:17:48 -0400
Subject: Re: New x400wrap I-D? (was RE: SMIME-TYPE question)
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

John:

They have been resolving WG Last Call comments.  Nothing nasty is going on.

I expect the document to be posted this week.

Russ


At 03:57 PM 7/9/2001 -0400, Pawling, John wrote:

>Michel,
>
>I agree with everything that Jim stated except that I have not seen the
>updated x400wrap document to which he referred.  The x400wrap authors should
>submit the updated document so that implementers can develop to the same
>spec.
>
>===========================================
>John Pawling, [e-mail]
>Getronics Government Solutions, LLC
>===========================================
>
>-----Original Message-----
>From: Jim Schaad [mailto:[e-mail]]
>Sent: Friday, July 06, 2001 6:39 PM
>To: 'Musy Michel-P28089'; 'Ietf-Smime (E-mail)'
>Subject: RE: SMIME-TYPE question
>
>
>
>Michel,
>
>I understand where you went wrong -- you didn't.  I have seen a later draft
>of this document and this has been changed.  Since EncapsulatedContentInfo
>and ContentInfo have the exact same content (i.e. an OID and ANY), having
>both is actually redunant.  This means that the ContentInfo can be omitted
>and just the EncapsulatedContentInfo used to convay the same information.
>
>jim


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f69LELT29453 for ietf-smime-bks; Mon, 9 Jul 2001 14:14:21 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.3/8.11.3) with SMTP id f69LEJm29447 for <[e-mail]>; Mon, 9 Jul 2001 14:14:19 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 9 Jul 2001 21:12:54 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id RAA28074; Mon, 9 Jul 2001 17:14:20 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <LR8TPP4Q>; Mon, 9 Jul 2001 17:14:18 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.105]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LR8TPP43; Mon, 9 Jul 2001 17:14:14 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Mon, 09 Jul 2001 17:00:00 -0400
Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01
In-Reply-To: <000801c10409$aefa71b0$[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jim & John:

> > 7) Section 6.2.4, recommend changing PasswordRecipientInfo version value to
> > 1.  This would cause the EnvelopedData version number to be set to 2 if the
> > PasswordRecipientInfo was present.  This would assist with debugging and
> > error reporting.
>
>I disagree with this.  This is the version struture of the
>PasswordRecipientInfo structure and is independent of the EnvelopedData
>version number.
>
>I think however that the version number of EnvelopedData needs to be 3 if
>either PasswordRecipientInfo or OtherRecipient is present as these are "new"
>structure and thus modify the behavior of the processing an EnvelopedData
>object.  I don't think that this will necessaryly need to be changed in the
>future as we now have an explicit statement that implemenations MUST handle
>other choices in the RecipientInfo.  This was not imposed in the past
>however.

I cannot find anything in draft-ietf-smime-password-03 regarding the 
EnvelopedData version value when PasswordRecipientInfo is used.

RFC 2630 says: "If any of the RecipientInfo structures included have a 
version other than 0, then the version shall be 2."  However, this text was 
written before PasswordRecipientInfo was defined with a version of zero.

The proposed algorithm for version in RFC2630bis is:
    IF (originatorInfo is present) OR (unprotectedAttrs is present)
    THEN
       IF (any version 2 attribute certificates are present)
       THEN version is 3
       ELSE version is 2
    ELSE
       IF (any RecipientInfo structures are a version other than 0)
       THEN version is 2
       ELSE version is 0

Based on this discussion, this algorithm is not acceptable.  It needs to be 
modified to set version to 3 if either PasswordRecipientInfo or 
OtherRecipientInfo is present.  Agree?

> > 11) Section 11.1 Content Type:  Please add as last sentence of first
> > paragraph: "The content-type attribute value MUST match the 
> encapContentInfo
> > eContentType value in the signed-data or authenticated-data."
>
>Do we consider a non-match to be a signature failure?  This is not currently
>stated anyplace.  I think that we should probably add this.

I have added the sentence suggested by John.  What more are you proposing.

> > 12) Section 11.2 Message Digest: Please replace the last
> > paragraph with the
> > following:
> >
> >    "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 message-digest
> > attribute.  Similarly,
> >    the AuthAttributes in an AuthenticatedData MUST NOT
> > include multiple
> >    instances of the message-digest attribute."
>
>I agree that the AuthAttributes stateemnt needs to be added.  However, I
>think this should be a MUST not a MUST NOT as MUST NOT is not testable.

Okay.  How about:

    The SignedAttributes syntax and AuthAttributes syntax are each
    defined as a SET OF Attributes.  The SignedAttributes in a signerInfo
    MUST include only one instance of the message-digest attribute.
    Similarly, the AuthAttributes in an AuthenticatedData MUST include
    only one instance of the message-digest attribute.

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f69L2aJ29081 for ietf-smime-bks; Mon, 9 Jul 2001 14:02:36 -0700 (PDT)
Received: from [165.227.249.20] (ip20.proper.com [165.227.249.20]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f69L2Ym29077 for <[e-mail]>; Mon, 9 Jul 2001 14:02:34 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100307b76fcc0e15bc@[165.227.249.20]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Mon, 9 Jul 2001 14:01:49 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: New x400wrap I-D? (was RE: SMIME-TYPE question)
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 3:57 PM -0400 7/9/01, Pawling, John wrote:
>I agree with everything that Jim stated except that I have not seen the
>updated x400wrap document to which he referred.  The x400wrap authors should
>submit the updated document so that implementers can develop to the same
>spec.

Look for it this week. There have been a fair number of corrections 
and I'm still coordinating among the authors.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f69KVKr28125 for ietf-smime-bks; Mon, 9 Jul 2001 13:31:20 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.3/8.11.3) with SMTP id f69KVIm28119 for <[e-mail]>; Mon, 9 Jul 2001 13:31:18 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 9 Jul 2001 20:29:53 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA24789 for <[e-mail]>; Mon, 9 Jul 2001 16:31:20 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <LR8TP395>; Mon, 9 Jul 2001 16:31:18 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.105]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LR8TP39W; Mon, 9 Jul 2001 16:31:15 -0400
From: "Housley, Russ" <[e-mail]>
To: "Pawling, John" <[e-mail]>
Cc: "SMIME WG (E-mail)" <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Mon, 09 Jul 2001 16:22:37 -0400
Subject: Re: More Comments to rfc2630bis-01
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

John:

This is not quite true.  The MUST implement statements were indirect. They 
came from the mandatory to implement algorithms.  In order to support 
Ephemeral-Static Diffie-Helman, one must implement kari.

At the last IETF meeting, we discussed the desire for separation of the 
protocol and the mandatory to implement algorithm.  For the IETF to have 
any flexibility in this area, the protocol implementation must support the 
major choices.

Russ

At 04:40 PM 7/5/2001 -0400, Pawling, John wrote:

>All,
>
>I have the following comment to rfc2630bis-01 (in addition to those
>submitted on 27 June):
>
>1) Section 6.2, RecipientInfo description:  RFC 2630 did not include any
>"MUST implement" requirements regarding support of the alternatives within
>the RecipientInfo CHOICE.  I don't believe that rfc2630bis should include
>any such "MUST implement" requirements either.  Please make the following
>change to the third paragraph:
>
>OLD:
>[*** NEW ***] Implementations MUST support key transport, key agreement, and
>previously distributed symmetric key-encryption keys, as represented by
>ktri, kari, and kekri, respectively.
>Implementations MAY support the password-based key management as represented
>by pwri.  Implementations MAY support any other key management technique as
>represented by ori.
>
>NEW:
>[*** NEW ***] The ktri, kari, kekri, and pwri alternatives in the
>RecipientInfo CHOICE are used for the key transport, key agreement,
>previously distributed symmetric key-encryption keys, and password-based key
>management techniques, respectively.  The ori alternative in the
>RecipientInfo CHOICE is used for any other key management technique.
>
>===========================================
>John Pawling, [e-mail]
>Getronics Government Solutions, LLC
>===========================================


Received: by above.proper.com (8.11.3/8.11.3) id f69Jvdg27175 for ietf-smime-bks; Mon, 9 Jul 2001 12:57:39 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f69Jvcm27171 for <[e-mail]>; Mon, 9 Jul 2001 12:57:39 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id <KZJ99J2T>; Mon, 9 Jul 2001 15:57:54 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "'Musy Michel-P28089'" <[e-mail]>
Cc: "SMIME WG (E-mail)" <[e-mail]>
Subject: New x400wrap I-D? (was RE: SMIME-TYPE question)
Date: Mon, 9 Jul 2001 15:57:47 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michel,

I agree with everything that Jim stated except that I have not seen the
updated x400wrap document to which he referred.  The x400wrap authors should
submit the updated document so that implementers can develop to the same
spec.  

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================

-----Original Message-----
From: Jim Schaad [mailto:[e-mail]]
Sent: Friday, July 06, 2001 6:39 PM
To: 'Musy Michel-P28089'; 'Ietf-Smime (E-mail)'
Subject: RE: SMIME-TYPE question



Michel,

I understand where you went wrong -- you didn't.  I have seen a later draft
of this document and this has been changed.  Since EncapsulatedContentInfo
and ContentInfo have the exact same content (i.e. an OID and ANY), having
both is actually redunant.  This means that the ContentInfo can be omitted
and just the EncapsulatedContentInfo used to convay the same information.

jim


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f66Mcfq17713 for ietf-smime-bks; Fri, 6 Jul 2001 15:38:41 -0700 (PDT)
Received: from femail12.sdc1.sfba.home.com (femail12.sdc1.sfba.home.com [24.0.95.108]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f66Mcem17706 for <[e-mail]>; Fri, 6 Jul 2001 15:38:40 -0700 (PDT)
Received: from revelation ([65.4.166.11]) by femail12.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010706223838.IFWA1573.femail12.sdc1.sfba.home.com@revelation>; Fri, 6 Jul 2001 15:38:38 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Musy Michel-P28089'" <[e-mail]>, "'Ietf-Smime \(E-mail\)'" <[e-mail]>
Subject: RE: SMIME-TYPE question
Date: Fri, 6 Jul 2001 15:38:36 -0700
Message-ID: <003101c1066c$65aa78b0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michel,

I understand where you went wrong -- you didn't.  I have seen a later draft
of this document and this has been changed.  Since EncapsulatedContentInfo
and ContentInfo have the exact same content (i.e. an OID and ANY), having
both is actually redunant.  This means that the ContentInfo can be omitted
and just the EncapsulatedContentInfo used to convay the same information.

jim


> -----Original Message-----
> From: Musy Michel-P28089 [mailto:[e-mail]]
> Sent: Friday, July 06, 2001 3:12 PM
> To: [e-mail]; 'Musy Michel-P28089'; 'Ietf-Smime
> \\\(E-mail\\\)'
> Subject: RE: SMIME-TYPE question
>
>
> Jim,
>
> Thanks a lot for the answers to all. I mistakenly thought that the
> Receipt was the signed-receipt, the signature on the receipt is that
> of the originator. So the good thing is that a signed-receipt
> may contain a label since a receipt is wrapped into a signed data.
>
> About the answer to 2.3 and 2.4 I would disagree at the moment but
> of course I can be wrong:
> According to the draft-ietf-smime-x400wrap-02, it seems that each
> layer of a triple wrapped X.400 are wrapped with a ContentInfo.
> Looking at this document in section:
> 3.4.1 Creating a Triple Wrapped Message With an X.400 Content,
> Step 3. and Step 4. seems to indicate this. Please let me know if
> here also there is something that I missed or misunderstood.
> I am including below the text of Step 3., Step 4., and Step 5.
>
> Michel
>
> =============================================================
> Step 3. Sign the result of step 2 (the original content). The
> SignedData
> encapContentInfo eContentType MUST contain the object
> identifier of the
> X.400 content. The SignedData structure is encapsulated by a
> ContentInfo
> SEQUENCE with a contentType of id-signedData.
>
> Step 4. Encrypt the result of step 3 as a single block. The
> EnvelopedData encryptedContentInfo contentType MUST be set to
> id-ct-contentInfo. This is called the "encrypted body". The
> EnvelopedData structure is encapsulated by a ContentInfo
> SEQUENCE with a
> contentType of id-envelopedData.
>
> Step 5. Using the same logic as in step 2 and 3 above, sign the result
> of step 5 (the encrypted body) as a single block. The SignedData
> structure is encapsulated by a ContentInfo SEQUENCE with a contentType
> of id-signedData.
> =============================================================
>
> -----Original Message-----
> From: Jim Schaad [mailto:[e-mail]]
> Sent: Friday, July 06, 2001 10:27 AM
> To: 'Musy Michel-P28089'; 'Ietf-Smime \\\(E-mail\\\)'
> Subject: RE: SMIME-TYPE question
>
>
> Michel,
>
> I will attempt to answer your questions.
>
> > -----Original Message-----
> > From: Musy Michel-P28089 [mailto:[e-mail]]
> > Sent: Friday, July 06, 2001 9:34 AM
> > To: [e-mail]; Ietf-Smime \(E-mail\)
> > Subject: RE: SMIME-TYPE question
> >
> >
> > First I'd like to answer Jim's question. Doing so makes me question
> > a few things that I thought I knew. Perhaps someone else
> > knows all of them.
> >
> > (1) I thought that according to RFC-2634, a signed-receipt
> identified
> >     with a content-type OID id-ct-receipt is the content by itself,
> >     never needs to be wrapped in a signed data, never is encrypted.
> >     I thought that there would never exist a signed-receipt triple
> >     wrapped. Please comment.
>
> id-ct-receipt is a content type which does not provide any security in
> itself.  As such a receipt content is always signed to provide the
> origination and integrety on the receipt structure.  Thus
> id-ct-receipt
> would always appear as the encapsulted content of a
> SignedData structure.
> The SignedData structure is then placed in a ContentInfo
> structure or else
> where.
>
> One could then encrypt either the SignedData structure or a
> MIME wrapped
> version of the ContentInfo structure if there was a reason to provide
> privacy on the receipt as well.  (One can conceive of a
> traffic analysis
> attack againist the receipt content.)  And of course if it is
> encrypted then
> it could be triple wrapped.
>
> If you have a hard time dealing with the concept of doing a
> triple wrapped
> reciept, think of doing it with a CMC enrollment message.  The same
> questions appear there as well.
>
> >
> > The following 4 are somehow the same question but still I'd
> appreciate
> > if someone could confirm or correct each.
> >
> > (2.1) I thought that there would always be an outer layer
> > with a Content
> >     Info containing precisely the content-type. Can someone please
> >     comment?
>
> The outermost layer will be a ContentInfo object for all
> items that we are
> currently dealing with.  It is possible somebody could do
> somthing with a
> SignedData outer most layer, but none of the tool kits I know of will
> support this.
>
> >
> > (2.2) According to CMS rfc-2630bis, each layer signed-data,
> >     enveloped-data, or signed-receipt would be encapsulated in a
> >     ContentInfo.
>
> Please provide the section reference for this.  I don't
> remember seeing
> this.  For S/MIME this is a true statement because there is a
> MIME wrapper
> between each layer thus making each layer the "outermost"
> layer.  This is
> not a true statement when looking at the x.400 wrap draft
> where the MIME
> wrapping is omitted for inner layers.
>
> >
> > (2.3) For MIME there is the additional inner id-data that does not
> >     exist with X.400, but I thought that both X.400 and MIME use
> >     the outer ContentInfo wrapping. Please comment.
>
> This is true only for the outermost layer, not for inner layers.
>
> >
> > (2.4)I thought that it implies that a signed-receipt also is wrapped
> >     in a ContentInfo. Please comment and correct if I am wrong.
>
> You could wrap a signed-receipt in a ContentInfo object, but
> you would lose
> all security services.  Look at section 2.4 (Signed Receipt
> Creation) in the
> ESS document (RFC 2634).
>
> >
> > Michel Musy: [e-mail]
> >
>
> jim
>
> > -----Original Message-----
> > From: Jim Schaad [mailto:[e-mail]]
> > Sent: Friday, July 06, 2001 1:40 AM
> > To: Ietf-Smime \(E-mail\)
> > Subject: SMIME-TYPE question
> >
> >
> >
> > I have a general question that I once knew the answer for but
> > am  no longer
> > sure that is the case.
> >
> > The SMIME-TYPE attribute was defined so that a mime-level
> > processor could
> > have some idea of the content type without having to pull
> > apart the message
> > and look at the contentHint attribute or the innermost
> > eContent.  (Or at
> > least that is what I remember it as being for.)  This being
> > the case, what
> > is the correct value of smime-type on a triple wrapped
> message with a
> > signedReceipt as the content?  It is signed-data or
> > signed-receipt.  Should
> > the answer change if the inner mime-layers were to be omitted
> > (relevant for
> > the X.400 case).
> >
> > Does the answer change if you have an encrypted receipt (i.e.
> > E(S(Receipt)))
> > What is the correct value of smime-type now?  signedReceipt or
> > encrypted-data?  Again does the answer change if the mime
> > layer were to be
> > omitted.
> >
> > Signed-receipt means that the top level processor knows what
> > is going to
> > happen before it gets there and can make intellegent decisions.
> >
> > Signed-Data is "correct" because the encapsulated content
> > contained in this
> > SignedData object is id-data or MIME content.
> >
> > NOTE: For the simple case of data (or MIME) content the question is
> > accedemic as signed-data and encrypted-data both imply data content.
> >
> > My original answer was the the correct answer is that
> > signed-receipt should
> > be propigated up over all of the layers, but I don't find any
> > statements
> > about this in either the message or ESS RFCs.
> >
> > jim
> >
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f66MC6717309 for ietf-smime-bks; Fri, 6 Jul 2001 15:12:06 -0700 (PDT)
Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f66MC4m17305 for <[e-mail]>; Fri, 6 Jul 2001 15:12:04 -0700 (PDT)
Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (motgate 2.1) with ESMTP id PAA01661 for <[e-mail]>; Fri, 6 Jul 2001 15:12:06 -0700 (MST)]
Received: [from az33exb01.corp.mot.com (az33exb01.corp.mot.com [199.2.84.12]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id PAA13849 for <[e-mail]>; Fri, 6 Jul 2001 15:12:06 -0700 (MST)]
Received: by az33exb01.corp.mot.com with Internet Mail Service (5.5.2653.19) id <3N1BDR4X>; Fri, 6 Jul 2001 15:12:06 -0700
Message-ID: <[e-mail]>
From: Musy Michel-P28089 <[e-mail]>
To: [e-mail], "'Musy Michel-P28089'" <[e-mail]>, "'Ietf-Smime \\\\\\(E-mail\\\\\\)'" <[e-mail]>
Subject: RE: SMIME-TYPE question
Date: Fri, 6 Jul 2001 15:12:03 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="ISO-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jim,

Thanks a lot for the answers to all. I mistakenly thought that the 
Receipt was the signed-receipt, the signature on the receipt is that
of the originator. So the good thing is that a signed-receipt
may contain a label since a receipt is wrapped into a signed data.

About the answer to 2.3 and 2.4 I would disagree at the moment but
of course I can be wrong:
According to the draft-ietf-smime-x400wrap-02, it seems that each
layer of a triple wrapped X.400 are wrapped with a ContentInfo.
Looking at this document in section: 
3.4.1 Creating a Triple Wrapped Message With an X.400 Content,
Step 3. and Step 4. seems to indicate this. Please let me know if 
here also there is something that I missed or misunderstood.
I am including below the text of Step 3., Step 4., and Step 5.

Michel

=============================================================
Step 3. Sign the result of step 2 (the original content). The SignedData
encapContentInfo eContentType MUST contain the object identifier of the
X.400 content. The SignedData structure is encapsulated by a ContentInfo
SEQUENCE with a contentType of id-signedData.

Step 4. Encrypt the result of step 3 as a single block. The
EnvelopedData encryptedContentInfo contentType MUST be set to
id-ct-contentInfo. This is called the "encrypted body". The
EnvelopedData structure is encapsulated by a ContentInfo SEQUENCE with a
contentType of id-envelopedData.

Step 5. Using the same logic as in step 2 and 3 above, sign the result
of step 5 (the encrypted body) as a single block. The SignedData
structure is encapsulated by a ContentInfo SEQUENCE with a contentType
of id-signedData.
=============================================================

-----Original Message-----
From: Jim Schaad [mailto:[e-mail]]
Sent: Friday, July 06, 2001 10:27 AM
To: 'Musy Michel-P28089'; 'Ietf-Smime \\\(E-mail\\\)'
Subject: RE: SMIME-TYPE question


Michel,

I will attempt to answer your questions.

> -----Original Message-----
> From: Musy Michel-P28089 [mailto:[e-mail]]
> Sent: Friday, July 06, 2001 9:34 AM
> To: [e-mail]; Ietf-Smime \(E-mail\)
> Subject: RE: SMIME-TYPE question
>
>
> First I'd like to answer Jim's question. Doing so makes me question
> a few things that I thought I knew. Perhaps someone else
> knows all of them.
>
> (1) I thought that according to RFC-2634, a signed-receipt identified
>     with a content-type OID id-ct-receipt is the content by itself,
>     never needs to be wrapped in a signed data, never is encrypted.
>     I thought that there would never exist a signed-receipt triple
>     wrapped. Please comment.

id-ct-receipt is a content type which does not provide any security in
itself.  As such a receipt content is always signed to provide the
origination and integrety on the receipt structure.  Thus id-ct-receipt
would always appear as the encapsulted content of a SignedData structure.
The SignedData structure is then placed in a ContentInfo structure or else
where.

One could then encrypt either the SignedData structure or a MIME wrapped
version of the ContentInfo structure if there was a reason to provide
privacy on the receipt as well.  (One can conceive of a traffic analysis
attack againist the receipt content.)  And of course if it is encrypted then
it could be triple wrapped.

If you have a hard time dealing with the concept of doing a triple wrapped
reciept, think of doing it with a CMC enrollment message.  The same
questions appear there as well.

>
> The following 4 are somehow the same question but still I'd appreciate
> if someone could confirm or correct each.
>
> (2.1) I thought that there would always be an outer layer
> with a Content
>     Info containing precisely the content-type. Can someone please
>     comment?

The outermost layer will be a ContentInfo object for all items that we are
currently dealing with.  It is possible somebody could do somthing with a
SignedData outer most layer, but none of the tool kits I know of will
support this.

>
> (2.2) According to CMS rfc-2630bis, each layer signed-data,
>     enveloped-data, or signed-receipt would be encapsulated in a
>     ContentInfo.

Please provide the section reference for this.  I don't remember seeing
this.  For S/MIME this is a true statement because there is a MIME wrapper
between each layer thus making each layer the "outermost" layer.  This is
not a true statement when looking at the x.400 wrap draft where the MIME
wrapping is omitted for inner layers.

>
> (2.3) For MIME there is the additional inner id-data that does not
>     exist with X.400, but I thought that both X.400 and MIME use
>     the outer ContentInfo wrapping. Please comment.

This is true only for the outermost layer, not for inner layers.

>
> (2.4)I thought that it implies that a signed-receipt also is wrapped
>     in a ContentInfo. Please comment and correct if I am wrong.

You could wrap a signed-receipt in a ContentInfo object, but you would lose
all security services.  Look at section 2.4 (Signed Receipt Creation) in the
ESS document (RFC 2634).

>
> Michel Musy: [e-mail]
>

jim

> -----Original Message-----
> From: Jim Schaad [mailto:[e-mail]]
> Sent: Friday, July 06, 2001 1:40 AM
> To: Ietf-Smime \(E-mail\)
> Subject: SMIME-TYPE question
>
>
>
> I have a general question that I once knew the answer for but
> am  no longer
> sure that is the case.
>
> The SMIME-TYPE attribute was defined so that a mime-level
> processor could
> have some idea of the content type without having to pull
> apart the message
> and look at the contentHint attribute or the innermost
> eContent.  (Or at
> least that is what I remember it as being for.)  This being
> the case, what
> is the correct value of smime-type on a triple wrapped message with a
> signedReceipt as the content?  It is signed-data or
> signed-receipt.  Should
> the answer change if the inner mime-layers were to be omitted
> (relevant for
> the X.400 case).
>
> Does the answer change if you have an encrypted receipt (i.e.
> E(S(Receipt)))
> What is the correct value of smime-type now?  signedReceipt or
> encrypted-data?  Again does the answer change if the mime
> layer were to be
> omitted.
>
> Signed-receipt means that the top level processor knows what
> is going to
> happen before it gets there and can make intellegent decisions.
>
> Signed-Data is "correct" because the encapsulated content
> contained in this
> SignedData object is id-data or MIME content.
>
> NOTE: For the simple case of data (or MIME) content the question is
> accedemic as signed-data and encrypted-data both imply data content.
>
> My original answer was the the correct answer is that
> signed-receipt should
> be propigated up over all of the layers, but I don't find any
> statements
> about this in either the message or ESS RFCs.
>
> jim
>


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f66K5d714883 for ietf-smime-bks; Fri, 6 Jul 2001 13:05:39 -0700 (PDT)
Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by above.proper.com (8.11.3/8.11.3) with SMTP id f66K5cm14879 for <[e-mail]>; Fri, 6 Jul 2001 13:05:38 -0700 (PDT)
Received: from 208.236.41.137 by cane.deming.com with ESMTP (Tumbleweed MMS SMTP Relay (MMS v4.7)); Fri, 06 Jul 2001 13:05:35 -0700
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by cane.deming.com with Internet Mail Service (5.5.2650.21) id <M71BRMMW>; Fri, 6 Jul 2001 13:05:35 -0700
Message-ID: <[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'Ietf-Smime (E-mail)'" <[e-mail]>
Subject: RE: SMIME-TYPE question
Date: Fri, 6 Jul 2001 13:05:34 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
X-WSS-ID: 1758C58573593-01-01
Content-Type: text/plain;  charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I believe that if I wanted to see a pretty icon in my mail agent, I would
want to see the one that reflected the fact that it was a receipt, so yes.

Blake

-----Original Message-----
From: Jim Schaad [mailto:[e-mail]]
Sent: Friday, July 06, 2001 1:04 PM
To: Blake Ramsdell; 'Ietf-Smime (E-mail)'
Subject: RE: SMIME-TYPE question


I am unclear, do you believe that an encrypted signed-receipt should have an
smime-type of signed-receipt then?

jim

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Blake Ramsdell
> Sent: Friday, July 06, 2001 10:54 AM
> To: '[e-mail]'; Ietf-Smime (E-mail)
> Subject: RE: SMIME-TYPE question
>
>
>
> To tell you the truth, I've never liked smime-type, and it
> wasn't my doing.
> I think that lgl put this in.
>
> If I had to take a stab at it, I would characterize it as
> being a shortcut
> hint to present to the client, and if it is inaccurate, it
> should have no
> effect on processing.  So if you wanted to provide an icon to
> indicate the
> message type, without tearing through the contents, this
> would be your boy.
>
> Now, I think that only RFC2633 profiles any smime-type (with
> the exception
> of signed-receipt in ESS).  If I had to summarize what went
> in the value and
> when to change the value, I would say "whenever there is
> significant client
> benefit".
>
> I think that the micalg parameter in RFC1847 is in somewhat
> the same boat --
> it's meant to be a hint, the values aren't really well
> specified, and you
> just expect the worst and work it out in processing.
>
> Blake
>
> -----Original Message-----
> From: Jim Schaad [mailto:[e-mail]]
> Sent: Friday, July 06, 2001 1:40 AM
> To: Ietf-Smime (E-mail)
> Subject: SMIME-TYPE question
>
>
>
> I have a general question that I once knew the answer for but
> am  no longer
> sure that is the case.
>
> The SMIME-TYPE attribute was defined so that a mime-level
> processor could
> have some idea of the content type without having to pull
> apart the message
> and look at the contentHint attribute or the innermost
> eContent.  (Or at
> least that is what I remember it as being for.)  This being
> the case, what
> is the correct value of smime-type on a triple wrapped message with a
> signedReceipt as the content?  It is signed-data or
> signed-receipt.  Should
> the answer change if the inner mime-layers were to be omitted
> (relevant for
> the X.400 case).
>
> Does the answer change if you have an encrypted receipt (i.e.
> E(S(Receipt)))
> What is the correct value of smime-type now?  signedReceipt or
> encrypted-data?  Again does the answer change if the mime
> layer were to be
> omitted.
>
> Signed-receipt means that the top level processor knows what
> is going to
> happen before it gets there and can make intellegent decisions.
>
> Signed-Data is "correct" because the encapsulated content
> contained in this
> SignedData object is id-data or MIME content.
>
> NOTE: For the simple case of data (or MIME) content the question is
> accedemic as signed-data and encrypted-data both imply data content.
>
> My original answer was the the correct answer is that
> signed-receipt should
> be propigated up over all of the layers, but I don't find any
> statements
> about this in either the message or ESS RFCs.
>
> jim
>
>





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f66K3qK14825 for ietf-smime-bks; Fri, 6 Jul 2001 13:03:52 -0700 (PDT)
Received: from femail12.sdc1.sfba.home.com (femail12.sdc1.sfba.home.com [24.0.95.108]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f66K3pm14821 for <[e-mail]>; Fri, 6 Jul 2001 13:03:51 -0700 (PDT)
Received: from revelation ([65.4.166.11]) by femail12.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010706200348.BCIH1573.femail12.sdc1.sfba.home.com@revelation>; Fri, 6 Jul 2001 13:03:48 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Blake Ramsdell'" <[e-mail]>, "'Ietf-Smime \(E-mail\)'" <[e-mail]>
Subject: RE: SMIME-TYPE question
Date: Fri, 6 Jul 2001 13:03:46 -0700
Message-ID: <002d01c10656$c4a6e2b0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I am unclear, do you believe that an encrypted signed-receipt should have an
smime-type of signed-receipt then?

jim

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Blake Ramsdell
> Sent: Friday, July 06, 2001 10:54 AM
> To: '[e-mail]'; Ietf-Smime (E-mail)
> Subject: RE: SMIME-TYPE question
>
>
>
> To tell you the truth, I've never liked smime-type, and it
> wasn't my doing.
> I think that lgl put this in.
>
> If I had to take a stab at it, I would characterize it as
> being a shortcut
> hint to present to the client, and if it is inaccurate, it
> should have no
> effect on processing.  So if you wanted to provide an icon to
> indicate the
> message type, without tearing through the contents, this
> would be your boy.
>
> Now, I think that only RFC2633 profiles any smime-type (with
> the exception
> of signed-receipt in ESS).  If I had to summarize what went
> in the value and
> when to change the value, I would say "whenever there is
> significant client
> benefit".
>
> I think that the micalg parameter in RFC1847 is in somewhat
> the same boat --
> it's meant to be a hint, the values aren't really well
> specified, and you
> just expect the worst and work it out in processing.
>
> Blake
>
> -----Original Message-----
> From: Jim Schaad [mailto:[e-mail]]
> Sent: Friday, July 06, 2001 1:40 AM
> To: Ietf-Smime (E-mail)
> Subject: SMIME-TYPE question
>
>
>
> I have a general question that I once knew the answer for but
> am  no longer
> sure that is the case.
>
> The SMIME-TYPE attribute was defined so that a mime-level
> processor could
> have some idea of the content type without having to pull
> apart the message
> and look at the contentHint attribute or the innermost
> eContent.  (Or at
> least that is what I remember it as being for.)  This being
> the case, what
> is the correct value of smime-type on a triple wrapped message with a
> signedReceipt as the content?  It is signed-data or
> signed-receipt.  Should
> the answer change if the inner mime-layers were to be omitted
> (relevant for
> the X.400 case).
>
> Does the answer change if you have an encrypted receipt (i.e.
> E(S(Receipt)))
> What is the correct value of smime-type now?  signedReceipt or
> encrypted-data?  Again does the answer change if the mime
> layer were to be
> omitted.
>
> Signed-receipt means that the top level processor knows what
> is going to
> happen before it gets there and can make intellegent decisions.
>
> Signed-Data is "correct" because the encapsulated content
> contained in this
> SignedData object is id-data or MIME content.
>
> NOTE: For the simple case of data (or MIME) content the question is
> accedemic as signed-data and encrypted-data both imply data content.
>
> My original answer was the the correct answer is that
> signed-receipt should
> be propigated up over all of the layers, but I don't find any
> statements
> about this in either the message or ESS RFCs.
>
> jim
>
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f66Jhu314387 for ietf-smime-bks; Fri, 6 Jul 2001 12:43:56 -0700 (PDT)
Received: from [165.227.249.20] (ip20.proper.com [165.227.249.20]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f66Jhqm14383; Fri, 6 Jul 2001 12:43:52 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05101000b76bc28d65a2@[165.227.249.20]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Fri, 6 Jul 2001 12:32:42 -0700
To: "Blake Ramsdell" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "Ietf-Smime (E-mail)" <[e-mail]>
From: Paul Hoffman / IMC <[e-mail]>
Subject: RE: SMIME-TYPE question
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 10:53 AM -0700 7/6/01, Blake Ramsdell wrote:
>To tell you the truth, I've never liked smime-type, and it wasn't my doing.
>I think that lgl put this in.

Well,we all agreed to it, but I do think it was Lawrence who proposed it.

>If I had to take a stab at it, I would characterize it as being a shortcut
>hint to present to the client, and if it is inaccurate, it should have no
>effect on processing.  So if you wanted to provide an icon to indicate the
>message type, without tearing through the contents, this would be your boy.

Yup, that's what I remember about the reasoning.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: by above.proper.com (8.11.3/8.11.3) id f66Hrs911705 for ietf-smime-bks; Fri, 6 Jul 2001 10:53:54 -0700 (PDT)
Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by above.proper.com (8.11.3/8.11.3) with SMTP id f66Hrrm11700 for <[e-mail]>; Fri, 6 Jul 2001 10:53:54 -0700 (PDT)
Received: from 208.236.41.137 by cane.deming.com with ESMTP (Tumbleweed MMS SMTP Relay (MMS v4.7)); Fri, 06 Jul 2001 10:53:50 -0700
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by cane.deming.com with Internet Mail Service (5.5.2650.21) id <M71BRM2F>; Fri, 6 Jul 2001 10:53:50 -0700
Message-ID: <[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "Ietf-Smime (E-mail)" <[e-mail]>
Subject: RE: SMIME-TYPE question
Date: Fri, 6 Jul 2001 10:53:48 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
X-WSS-ID: 175B24A472571-01-01
Content-Type: text/plain;  charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

To tell you the truth, I've never liked smime-type, and it wasn't my doing.
I think that lgl put this in.

If I had to take a stab at it, I would characterize it as being a shortcut
hint to present to the client, and if it is inaccurate, it should have no
effect on processing.  So if you wanted to provide an icon to indicate the
message type, without tearing through the contents, this would be your boy.

Now, I think that only RFC2633 profiles any smime-type (with the exception
of signed-receipt in ESS).  If I had to summarize what went in the value and
when to change the value, I would say "whenever there is significant client
benefit".

I think that the micalg parameter in RFC1847 is in somewhat the same boat --
it's meant to be a hint, the values aren't really well specified, and you
just expect the worst and work it out in processing.

Blake

-----Original Message-----
From: Jim Schaad [mailto:[e-mail]]
Sent: Friday, July 06, 2001 1:40 AM
To: Ietf-Smime (E-mail)
Subject: SMIME-TYPE question



I have a general question that I once knew the answer for but am  no longer
sure that is the case.

The SMIME-TYPE attribute was defined so that a mime-level processor could
have some idea of the content type without having to pull apart the message
and look at the contentHint attribute or the innermost eContent.  (Or at
least that is what I remember it as being for.)  This being the case, what
is the correct value of smime-type on a triple wrapped message with a
signedReceipt as the content?  It is signed-data or signed-receipt.  Should
the answer change if the inner mime-layers were to be omitted (relevant for
the X.400 case).

Does the answer change if you have an encrypted receipt (i.e. E(S(Receipt)))
What is the correct value of smime-type now?  signedReceipt or
encrypted-data?  Again does the answer change if the mime layer were to be
omitted.

Signed-receipt means that the top level processor knows what is going to
happen before it gets there and can make intellegent decisions.

Signed-Data is "correct" because the encapsulated content contained in this
SignedData object is id-data or MIME content.

NOTE: For the simple case of data (or MIME) content the question is
accedemic as signed-data and encrypted-data both imply data content.

My original answer was the the correct answer is that signed-receipt should
be propigated up over all of the layers, but I don't find any statements
about this in either the message or ESS RFCs.

jim




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f66HRUg11220 for ietf-smime-bks; Fri, 6 Jul 2001 10:27:30 -0700 (PDT)
Received: from femail12.sdc1.sfba.home.com (femail12.sdc1.sfba.home.com [24.0.95.108]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f66HRTm11216 for <[e-mail]>; Fri, 6 Jul 2001 10:27:29 -0700 (PDT)
Received: from revelation ([65.4.166.11]) by femail12.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010706172726.TOHR1573.femail12.sdc1.sfba.home.com@revelation>; Fri, 6 Jul 2001 10:27:26 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Musy Michel-P28089'" <[e-mail]>, "'Ietf-Smime \\\(E-mail\\\)'" <[e-mail]>
Subject: RE: SMIME-TYPE question
Date: Fri, 6 Jul 2001 10:27:23 -0700
Message-ID: <002b01c10640$ecca5080$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michel,

I will attempt to answer your questions.

> -----Original Message-----
> From: Musy Michel-P28089 [mailto:[e-mail]]
> Sent: Friday, July 06, 2001 9:34 AM
> To: [e-mail]; Ietf-Smime \(E-mail\)
> Subject: RE: SMIME-TYPE question
>
>
> First I'd like to answer Jim's question. Doing so makes me question
> a few things that I thought I knew. Perhaps someone else
> knows all of them.
>
> (1) I thought that according to RFC-2634, a signed-receipt identified
>     with a content-type OID id-ct-receipt is the content by itself,
>     never needs to be wrapped in a signed data, never is encrypted.
>     I thought that there would never exist a signed-receipt triple
>     wrapped. Please comment.

id-ct-receipt is a content type which does not provide any security in
itself.  As such a receipt content is always signed to provide the
origination and integrety on the receipt structure.  Thus id-ct-receipt
would always appear as the encapsulted content of a SignedData structure.
The SignedData structure is then placed in a ContentInfo structure or else
where.

One could then encrypt either the SignedData structure or a MIME wrapped
version of the ContentInfo structure if there was a reason to provide
privacy on the receipt as well.  (One can conceive of a traffic analysis
attack againist the receipt content.)  And of course if it is encrypted then
it could be triple wrapped.

If you have a hard time dealing with the concept of doing a triple wrapped
reciept, think of doing it with a CMC enrollment message.  The same
questions appear there as well.

>
> The following 4 are somehow the same question but still I'd appreciate
> if someone could confirm or correct each.
>
> (2.1) I thought that there would always be an outer layer
> with a Content
>     Info containing precisely the content-type. Can someone please
>     comment?

The outermost layer will be a ContentInfo object for all items that we are
currently dealing with.  It is possible somebody could do somthing with a
SignedData outer most layer, but none of the tool kits I know of will
support this.

>
> (2.2) According to CMS rfc-2630bis, each layer signed-data,
>     enveloped-data, or signed-receipt would be encapsulated in a
>     ContentInfo.

Please provide the section reference for this.  I don't remember seeing
this.  For S/MIME this is a true statement because there is a MIME wrapper
between each layer thus making each layer the "outermost" layer.  This is
not a true statement when looking at the x.400 wrap draft where the MIME
wrapping is omitted for inner layers.

>
> (2.3) For MIME there is the additional inner id-data that does not
>     exist with X.400, but I thought that both X.400 and MIME use
>     the outer ContentInfo wrapping. Please comment.

This is true only for the outermost layer, not for inner layers.

>
> (2.4)I thought that it implies that a signed-receipt also is wrapped
>     in a ContentInfo. Please comment and correct if I am wrong.

You could wrap a signed-receipt in a ContentInfo object, but you would lose
all security services.  Look at section 2.4 (Signed Receipt Creation) in the
ESS document (RFC 2634).

>
> Michel Musy: [e-mail]
>

jim

> -----Original Message-----
> From: Jim Schaad [mailto:[e-mail]]
> Sent: Friday, July 06, 2001 1:40 AM
> To: Ietf-Smime \(E-mail\)
> Subject: SMIME-TYPE question
>
>
>
> I have a general question that I once knew the answer for but
> am  no longer
> sure that is the case.
>
> The SMIME-TYPE attribute was defined so that a mime-level
> processor could
> have some idea of the content type without having to pull
> apart the message
> and look at the contentHint attribute or the innermost
> eContent.  (Or at
> least that is what I remember it as being for.)  This being
> the case, what
> is the correct value of smime-type on a triple wrapped message with a
> signedReceipt as the content?  It is signed-data or
> signed-receipt.  Should
> the answer change if the inner mime-layers were to be omitted
> (relevant for
> the X.400 case).
>
> Does the answer change if you have an encrypted receipt (i.e.
> E(S(Receipt)))
> What is the correct value of smime-type now?  signedReceipt or
> encrypted-data?  Again does the answer change if the mime
> layer were to be
> omitted.
>
> Signed-receipt means that the top level processor knows what
> is going to
> happen before it gets there and can make intellegent decisions.
>
> Signed-Data is "correct" because the encapsulated content
> contained in this
> SignedData object is id-data or MIME content.
>
> NOTE: For the simple case of data (or MIME) content the question is
> accedemic as signed-data and encrypted-data both imply data content.
>
> My original answer was the the correct answer is that
> signed-receipt should
> be propigated up over all of the layers, but I don't find any
> statements
> about this in either the message or ESS RFCs.
>
> jim
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f66GYK610152 for ietf-smime-bks; Fri, 6 Jul 2001 09:34:20 -0700 (PDT)
Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f66GYJm10148 for <[e-mail]>; Fri, 6 Jul 2001 09:34:19 -0700 (PDT)
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id JAA28760 for <[e-mail]>; Fri, 6 Jul 2001 09:34:20 -0700 (MST)]
Received: [from az33exb01.corp.mot.com (az33exb01.corp.mot.com [199.2.84.12]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id JAA19329 for <[e-mail]>; Fri, 6 Jul 2001 09:34:20 -0700 (MST)]
Received: by az33exb01.corp.mot.com with Internet Mail Service (5.5.2653.19) id <N7TKAVTG>; Fri, 6 Jul 2001 09:34:19 -0700
Message-ID: <[e-mail]>
From: Musy Michel-P28089 <[e-mail]>
To: [e-mail], "Ietf-Smime \\(E-mail\\)" <[e-mail]>
Subject: RE: SMIME-TYPE question
Date: Fri, 6 Jul 2001 09:34:16 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="ISO-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

First I'd like to answer Jim's question. Doing so makes me question
a few things that I thought I knew. Perhaps someone else 
knows all of them.

(1) I thought that according to RFC-2634, a signed-receipt identified
    with a content-type OID id-ct-receipt is the content by itself,
    never needs to be wrapped in a signed data, never is encrypted.
    I thought that there would never exist a signed-receipt triple
    wrapped. Please comment.

The following 4 are somehow the same question but still I'd appreciate
if someone could confirm or correct each.

(2.1) I thought that there would always be an outer layer with a Content
    Info containing precisely the content-type. Can someone please 
    comment?

(2.2) According to CMS rfc-2630bis, each layer signed-data,
    enveloped-data, or signed-receipt would be encapsulated in a 
    ContentInfo.

(2.3) For MIME there is the additional inner id-data that does not 
    exist with X.400, but I thought that both X.400 and MIME use
    the outer ContentInfo wrapping. Please comment. 

(2.4)I thought that it implies that a signed-receipt also is wrapped
    in a ContentInfo. Please comment and correct if I am wrong.

Michel Musy: [e-mail] 

-----Original Message-----
From: Jim Schaad [mailto:[e-mail]]
Sent: Friday, July 06, 2001 1:40 AM
To: Ietf-Smime \(E-mail\)
Subject: SMIME-TYPE question



I have a general question that I once knew the answer for but am  no longer
sure that is the case.

The SMIME-TYPE attribute was defined so that a mime-level processor could
have some idea of the content type without having to pull apart the message
and look at the contentHint attribute or the innermost eContent.  (Or at
least that is what I remember it as being for.)  This being the case, what
is the correct value of smime-type on a triple wrapped message with a
signedReceipt as the content?  It is signed-data or signed-receipt.  Should
the answer change if the inner mime-layers were to be omitted (relevant for
the X.400 case).

Does the answer change if you have an encrypted receipt (i.e. E(S(Receipt)))
What is the correct value of smime-type now?  signedReceipt or
encrypted-data?  Again does the answer change if the mime layer were to be
omitted.

Signed-receipt means that the top level processor knows what is going to
happen before it gets there and can make intellegent decisions.

Signed-Data is "correct" because the encapsulated content contained in this
SignedData object is id-data or MIME content.

NOTE: For the simple case of data (or MIME) content the question is
accedemic as signed-data and encrypted-data both imply data content.

My original answer was the the correct answer is that signed-receipt should
be propigated up over all of the layers, but I don't find any statements
about this in either the message or ESS RFCs.

jim


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f668eNu25556 for ietf-smime-bks; Fri, 6 Jul 2001 01:40:23 -0700 (PDT)
Received: from femail12.sdc1.sfba.home.com (femail12.sdc1.sfba.home.com [24.0.95.108]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f668eMm25552 for <[e-mail]>; Fri, 6 Jul 2001 01:40:22 -0700 (PDT)
Received: from revelation ([65.4.166.11]) by femail12.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010706084017.BPBS1573.femail12.sdc1.sfba.home.com@revelation> for <[e-mail]>; Fri, 6 Jul 2001 01:40:17 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "Ietf-Smime \(E-mail\)" <[e-mail]>
Subject: SMIME-TYPE question
Date: Fri, 6 Jul 2001 01:40:15 -0700
Message-ID: <002901c105f7$48839b10$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I have a general question that I once knew the answer for but am  no longer
sure that is the case.

The SMIME-TYPE attribute was defined so that a mime-level processor could
have some idea of the content type without having to pull apart the message
and look at the contentHint attribute or the innermost eContent.  (Or at
least that is what I remember it as being for.)  This being the case, what
is the correct value of smime-type on a triple wrapped message with a
signedReceipt as the content?  It is signed-data or signed-receipt.  Should
the answer change if the inner mime-layers were to be omitted (relevant for
the X.400 case).

Does the answer change if you have an encrypted receipt (i.e. E(S(Receipt)))
What is the correct value of smime-type now?  signedReceipt or
encrypted-data?  Again does the answer change if the mime layer were to be
omitted.

Signed-receipt means that the top level processor knows what is going to
happen before it gets there and can make intellegent decisions.

Signed-Data is "correct" because the encapsulated content contained in this
SignedData object is id-data or MIME content.

NOTE: For the simple case of data (or MIME) content the question is
accedemic as signed-data and encrypted-data both imply data content.

My original answer was the the correct answer is that signed-receipt should
be propigated up over all of the layers, but I don't find any statements
about this in either the message or ESS RFCs.

jim



Received: by above.proper.com (8.11.3/8.11.3) id f65Ke9D23777 for ietf-smime-bks; Thu, 5 Jul 2001 13:40:09 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f65Ke8m23773 for <[e-mail]>; Thu, 5 Jul 2001 13:40:09 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id <KZJ98ZT4>; Thu, 5 Jul 2001 16:40:25 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "SMIME WG (E-mail)" <[e-mail]>
Subject: More Comments to rfc2630bis-01
Date: Thu, 5 Jul 2001 16:40:18 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

I have the following comment to rfc2630bis-01 (in addition to those
submitted on 27 June):

1) Section 6.2, RecipientInfo description:  RFC 2630 did not include any
"MUST implement" requirements regarding support of the alternatives within
the RecipientInfo CHOICE.  I don't believe that rfc2630bis should include
any such "MUST implement" requirements either.  Please make the following
change to the third paragraph:

OLD: 
[*** NEW ***] Implementations MUST support key transport, key agreement, and
previously distributed symmetric key-encryption keys, as represented by
ktri, kari, and kekri, respectively.
Implementations MAY support the password-based key management as represented
by pwri.  Implementations MAY support any other key management technique as
represented by ori.  

NEW: 
[*** NEW ***] The ktri, kari, kekri, and pwri alternatives in the
RecipientInfo CHOICE are used for the key transport, key agreement,
previously distributed symmetric key-encryption keys, and password-based key
management techniques, respectively.  The ori alternative in the
RecipientInfo CHOICE is used for any other key management technique. 

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f65JhL822358 for ietf-smime-bks; Thu, 5 Jul 2001 12:43:21 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f65JhLm22353 for <[e-mail]>; Thu, 5 Jul 2001 12:43:21 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id <KZJ98ZGF>; Thu, 5 Jul 2001 15:43:36 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "'Ietf-Smime (E-mail)'" <[e-mail]>
Subject: RE: Jim's Comments: draft-ietf-smime-cmsalg-00
Date: Thu, 5 Jul 2001 15:43:34 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jim,

Thank you for your responses to my comments.  My responses are included in
the message below.  I snipped the text that we agree on. 

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================
 

-----Original Message-----
From: Jim Schaad [mailto:[e-mail]]
Sent: Tuesday, July 03, 2001 6:58 PM
To: 'Pawling, John'; 'Ietf-Smime (E-mail)'
Subject: RE: Jim's Comments: draft-ietf-smime-cmsalg-00


John,

Here are my responses to your comments.

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Pawling, John
> Sent: Tuesday, July 03, 2001 8:31 AM
> To: Ietf-Smime (E-mail)
> Subject: RE: Jim's Comments: draft-ietf-smime-cmsalg-00
>
>
>
> All,
>
> I have the following comments regarding Jim Schaad's 7 June
> comments to the
> draft-ietf-smime-cmsalg-00.txt Internet-Draft.  My comments [JP] are
> numbered consistently with Jim's original message.  I omitted
> Jim's comments
> with which I agree.
>
> 2) Section 2.1:  Jim stated: "I believe that the MUST and
> SHOULD statements
> in this paragraph are in conflict.  ie. MUST encode as and
> SHOULD generate
> with.  These should be resolved as MUST in both locations."
>
> [JP: I disagree with Jim that the MUST and SHOULD statements are in
> conflict.  The paragraph states: "If present, the parameters
> field MUST
> contain an ASN.1 NULL."  In my opinion, it is clear that the MUST
> requirement does not apply if the parameters field is absent.  I also
> disagree with Jim's recommendation to change the spec to state that
> implementations MUST populate the algorithmIdentifier
> parameters field with
> an ASN.1 NULL.  I believe that the text should remain unchanged.]

[Jim: If present, the parameters field MUST contain an ASN.1 NULL.
Implementations SHOULD generate SHA-1 AlgorithmIdentifiers with NULL
parameters.  

I believe that the second line is a MUST not a SHOULD.  I don't object to
the SHOULD handle if it is wrong, but generation needs to be with NULL
parameters.]

[John: This is a style choice.  I do not feel strongly about this issue.
RFC 2630 implementations should be populating this field with NULL anyway
(since it was a SHOULD requirement in RFC 2630).  In summary, I do not
object to your proposed change and I do not believe that it will cause any
interoperability problems.  Recommend the following new text: "The
AlgorithmIdentifier parameters field MUST be present, and the parameters
field MUST contain NULL.  Implementations SHOULD accept SHA-1
AlgorithmIdentifiers with absent parameters as well as NULL parameters.

Also, the following text should be added to section 3.2 RSA: "The
AlgorithmIdentifier parameters field MUST be present, and the parameters
field MUST contain NULL.  Implementations MAY accept rsaEncryption
AlgorithmIdentifiers with absent parameters as well as NULL parameters."]
    

> 6) Section 3.2:  Jim stated "Boy we really messed this one
> up.  Section 3.2
> should occur
> as two different sections one for RSAwithMD5 and one for
> RSAwithSHA1.  I
> will never understand how all of us missed this one.
>
> The OIDs for this should be:
>        sha1withRSAEncryption (1 2 840 113549 1 1 5)
> or
> #define szOID_OIWSEC_sha1RSASign "1.3.14.3.2.29"
>
>        md5withRSAEncryption (1 2 840 113549 1 1 4)"
>
> [JP: I disagree with Jim's statements.  To support backwards
> compatibility
> with S/MIME v2 implementations that only recognize the
> rsaEncryption OID, we
> specified that the rsaEncryption OID must be included in the
> signedData
> signerInfo signatureAlgorithm field.  We decided not to
> specify the use of
> the sha-1WithRSAEncryption, md2withRSAEncryption, or
> md5withRSAEncryption
> OIDs in the signerInfo signatureAlgorithm field.]

[Jim stated: John -- If I look in the examples draft, the OID that is in the
signatureAlgorithm field of a SignerInfo field is
  119 30   13:             SEQUENCE {
  121 06    9:               OBJECT IDENTIFIER
             :                 sha1withRSAEncryption (1 2 840 113549 1 1 5)
             :                 (PKCS #1)
  132 05    0:               NULL
             :               }
Not RSA.  I don't have the foggiest idea of what you are talking about for
backwards compatability.  This is not an argument that I have ever heard
before (I think).

I think you have not looked at this correctly and ask that you re-check what
I am saying.]


[John: Your quote from the examples-06 document is for an RSA signature on a
certificate (not a signedData signerInfo signatureAlgorithm field).
Examples 5.2, 5.5 and 11.2 in the examples-06 document all include the
rsaEncryption (1 2 840 113549 1 1 1) OID in the signerInfo
signatureAlgorithm field as specified in RFC 2630, section 12.2.2.  

There is definitely an inconsistency between the specification of the
rsaEncryption and id-dsa-with-sha1 OIDs in the signerInfo signatureAlgorithm
field.  While RFC 2630 was being developed, I pointed out that
inconsistency.  I was told that the rsaEncryption OID was specified to
support backwards compatibility with S/MIME v2 implementations that only
recognize the rsaEncryption OID.  I was also told that the signerInfo
digestAlgorithm field indicates the algorithm used to calculate the message
digest value used as an input to the signature algorithm, so the use of the
rsaEncryption OID (rather than sha-1withRSAEncryption, md2withRSAEncryption,
or md5withRSAEncryption) was appropriate.  I then proposed that the id-dsa
OID should be used in the signerInfo signatureAlgorithm field to be
consistent with the use of the rsaEncryption OID.  I was told that since DSA
is always used with SHA-1, then the id-dsa-with-sha1 OID is appropriate for
use in the signerInfo signatureAlgorithm field.  

Having said all of that, I would support a change to cmsalg to specify the
use of the sha-1withRSAEncryption, md2withRSAEncryption, or
md5withRSAEncryption OIDs (rather than  rsaEncryption) in the signerInfo
signatureAlgorithm field.  This would be consistent with the use of those
OIDs in PKIX X.509 certificates.  It would also eliminate the current
situation in which the rsaEncryption OID is being used for two very
different purposes (to indicate an RSA signature in the signerInfo
signatureAlgorithm field and to indicate an RSA public key in a PKIX X.509
certificate).]


> 12) Section 7:  Jim stated: "I do not believe this section
> needs any MUSTS
> for inclusion
> of algorithms.  That is covered in section 4."
>
> [JP: Rather than delete the first sentence of Section 7, I
> believe that it
> should be changed to: "CMS implementations that support the
> previously-distributed symmetric KEK or key agreement key management
> techniques MUST include encryption of a Triple-DES
> content-encryption key
> with a Triple-DES key-encryption key using the algorithm specified in
> Sections 7.2 and 7.3."]

[Jim: I stand by my original comment.  This is a duplication of a MUST and
should
be where it makes sense (where the algorithm is used) not here.]

[John: I do not object to your comment.  If the MUST language is removed
from the first sentence, then the SHOULD language should be removed from the
second sentence.] 



>
> ===========================================
> John Pawling, [e-mail]
> Getronics Government Solutions, LLC
> ===========================================
>


jim


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f65Hoqb19672 for ietf-smime-bks; Thu, 5 Jul 2001 10:50:52 -0700 (PDT)
Received: from femail12.sdc1.sfba.home.com (femail12.sdc1.sfba.home.com [24.0.95.108]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f65Hopm19667 for <[e-mail]>; Thu, 5 Jul 2001 10:50:51 -0700 (PDT)
Received: from revelation ([65.4.166.11]) by femail12.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010705175047.HUQL29724.femail12.sdc1.sfba.home.com@revelation>; Thu, 5 Jul 2001 10:50:47 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Pawling, John'" <[e-mail]>
Cc: "'SMIME WG \(E-mail\)'" <[e-mail]>
Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01
Date: Thu, 5 Jul 2001 10:50:45 -0700
Message-ID: <001701c1057b$0539e0c0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I agree with John's suggestions.

jim

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Pawling, John
> Sent: Thursday, July 05, 2001 9:21 AM
> To: '[e-mail]'
> Cc: 'SMIME WG (E-mail)'
> Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01
> 
> 
> 
> Jim,
> 
> Thank you for your responses to my comments.  My responses 
> are included in
> the message below.  I snipped the text that we agree on.
> 
> ===========================================
> John Pawling, [e-mail]
> Getronics Government Solutions, LLC
> ===========================================
> 
> 
> -----Original Message-----
> From: Jim Schaad [mailto:[e-mail]]
> Sent: Tuesday, July 03, 2001 5:47 PM
> To: 'Pawling, John'; 'SMIME WG (E-mail)'
> Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01
> 
> 
> Here are my comments on John.  I have left the number the same as the
> orginal message.
> 
> <snip>
> 
> >
> > 4) Section 6.2, RecipientInfo description:  Please delete
> > "are" from the
> > following sentence: "  [*** NEW ***] All implementations MUST
> > support the
> > mandatory to implement key management algorithms are
> > specified in [CMSALG],
> > or its successor."
> 
> [Jim: As I have said before - and is a new topic - I disagree 
> and feel the
> entire
> paragragh should be deleted.]
> 
> [John: The intent of my comment was simply to correct the 
> grammar of the
> sentence.  I believe that this issue should be discussed in 
> messages sent in
> response to Russ' 28 June "Mandatory to Implement Algorithms 
> in CMS" message
> that addressed your original comment.]
> 
> <snip>
> 
> 
> > 7) Section 6.2.4, recommend changing PasswordRecipientInfo
> > version value to
> > 1.  This would cause the EnvelopedData version number to be
> > set to 2 if the
> > PasswordRecipientInfo was present.  This would assist with
> > debugging and
> > error reporting.
> 
> [Jim: I disagree with this.  This is the version struture of the
> PasswordRecipientInfo structure and is independent of the 
> EnvelopedData
> version number.  I think however that the version number of 
> EnvelopedData
> needs to be 3 if
> either PasswordRecipientInfo or OtherRecipient is present as 
> these are "new"
> structure and thus modify the behavior of the processing an 
> EnvelopedData
> object.]
> 
> [John: I agree that the PasswordRecipientInfo version value 
> should not be
> changed.  I also agree that the Section 6.1, EnvelopedData 
> version-setting
> algorithm should be changed as you describe.  I propose the following
> replacement text (same as proposed in my 7/2 reply to Russ):
> 
>    [*** NEW ***] version is the syntax version number.  The
>    appropriate value depends on originatorInfo, RecipientInfo, and
>    unprotectedAttrs.  The version MUST be assigned as follows:
> 
>     IF ((originatorInfo is present) AND 
> 	 (any version 2 attribute certificates are present)) OR
> 	 (any RecipientInfo structures are pwri CHOICE) OR
>  	 (any RecipientInfo structures are ori CHOICE)
>     THEN version is 3
>     ELSE
> 	 IF (originatorInfo is present) OR
> 	    (unprotectedAttrs is present) OR
> 	    (any RecipientInfo structures are a version other than 0)
>        THEN version is 2
>        ELSE version is 0]
> 
> 
> [Jim: I don't think that this will necessaryly need to be 
> changed in the
> future as we now have an explicit statement that 
> implemenations MUST handle
> other choices in the RecipientInfo.  This was not imposed in the past
> however.]
> 
> [John: I agree that the EnvelopedData version-setting 
> algorithm will not
> need to be changed for new syntaxes defined for use within 
> the RecipientInfo
> ori CHOICE.  The EnvelopedData version-setting algorithm 
> should be changed
> if new syntaxes are added directly to the RecipientInfo 
> CHOICE in future
> versions of the CMS spec.  I believe that the text to which you are
> referring was present in rfc2630bis-00, but deleted from 
> rfc2630bis-01.
> rfc2630bis-01 states: "all implementations MUST gracefully handle
> unimplemented alternatives within the RecipientInfo CHOICE".]
> 
> 
> > 11) Section 11.1 Content Type:  Please add as last sentence of first
> > paragraph: "The content-type attribute value MUST match the
> > encapContentInfo
> > eContentType value in the signed-data or authenticated-data."
> 
> [Jim: Do we consider a non-match to be a signature failure?  
> This is not
> currently
> stated anyplace.  I think that we should probably add this.]
> 
> [John: I agree that a non-match is a critical security error. 
>  Propose that
> the following sentence be added to Section 5.6 Message Signature
> Verification Process as the last paragraph:  "If the 
> signedData signerInfo
> includes signedAttributes and the content-type attribute 
> value is different
> from the signedData encapContentInfo eContentType value, then the CMS
> implementation MUST report an error."  
> 
> Propose that the following sentence be added to Section 9.3 
> MAC Verification
> as the last paragraph:  "If the authenticatedData includes
> authenticatedAttributes and the content-type attribute value 
> is different
> from the authenticatedData encapContentInfo eContentType 
> value, then the CMS
> implementation MUST report an error."]
> 
> 
> > 12) Section 11.2 Message Digest: Please replace the last
> > paragraph with the
> > following:
> >
> >    "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 message-digest
> > attribute.  Similarly,
> >    the AuthAttributes in an AuthenticatedData MUST NOT
> > include multiple
> >    instances of the message-digest attribute."
> 
> [Jim: I agree that the AuthAttributes statement needs to be 
> added.  However,
> I
> think this should be a MUST not a MUST NOT as MUST NOT is not 
> testable.]
> 
> [John: Agree.  Propose the following new text:  "The 
> SignedAttributes syntax
> and AuthAttributes syntax are each defined as a SET OF 
> Attributes.  The
> SignedAttributes in a signerInfo MUST include a single instance of the
> message-digest attribute.  Similarly, the AuthAttributes in an
> AuthenticatedData MUST include a single instance of the message-digest
> attribute."
> 
> Also, we should make the following replacement in Section 
> 11.1 Content Type:
> 
> 
> OLD: 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.
> 
> NEW: The SignedAttributes syntax and AuthAttributes syntax 
> are each defined 
>      as a SET OF Attributes.  The SignedAttributes in a 
> signerInfo MUST 
>      include a single instance of the content-type attribute. 
>  Similarly,
>      the AuthAttributes in an AuthenticatedData MUST include a single
>      instance of the content-type attribute.]
> 
> == jim
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f65Hnwd19637 for ietf-smime-bks; Thu, 5 Jul 2001 10:49:58 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f65Hnvm19633 for <[e-mail]>; Thu, 5 Jul 2001 10:49:57 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id <KZJ98YMR>; Thu, 5 Jul 2001 13:50:12 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "'SMIME WG (E-mail)'" <[e-mail]>
Subject: RE: cmsalg-00 Comments
Date: Thu, 5 Jul 2001 13:50:11 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jim, 

Thank you for your responses to my comments.  My responses are included in
the message below.  

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================


-----Original Message-----
From: Jim Schaad [mailto:[e-mail]]
Sent: Tuesday, July 03, 2001 6:46 PM
To: 'Pawling, John'; 'SMIME WG (E-mail)'
Subject: RE: cmsalg-00 Comments


John,

Here are the comments I have:

>
> 1) General comment: Since there are multiple techniques for
> using the RSA
> algorithm, please replace all occurrences of "RSA" with "RSA
> (PKCS #1 v1.5)"
> as appropriate.

[Jim: I thought about recommending this change as well.  The reason that I
did not
was that the only reference in the document was to the v1.5.  I could go
either way on this issue.]

[John: I too could go either way on this issue.  cmsalg-00 already defines
the techniques for using the RSA algorithm.  Section 3.2 states: "The RSA
signature algorithm is defined in RFC 2437 [NEWPKCS#1]".  Section 4.2.1
states: "The RSA key transport algorithm is the RSA encryption scheme
defined in RFC 2313 [PKCS#1]."  However, the security considerations section
does discuss PKCS #1 v2.0.  In summary, I will leave it up to Russ.  I will
not object if he ignores this comment.] 


> 3) Section 1, para 3:  Please change "Algorithm are be identified" to
> "Algorithms can be identified".

[Jim: I disagree with this change.  The correct text is "are" as this is the
only
way we are identifing these algorithms.  If you think it should be "can",
please show another way that they can be identified.]

[John: I agree with you.  Recommend that the text should be changed from
"Algorithm are be identified" to "Algorithms are identified".]


> 6) Table 1, Symmetric KEK Wrap note:  Please add this note to
> immediately
> follow the table: "Note 2: Only those CMS implementations
> that support the
> previously-distributed symmetric KEK or key agreement key management
> techniques MUST implement the Triple-DES Key Wrap algorithm."
>  An alternate
> solution is to change the table such that "Triple-DES Key
> Wrap" is a SHOULD
> implement requirement.

[Jim: I disagree with the addition of this node.  I don't think that the
table is
where this should be specified.  This type of text belongs with the
algorithm description.]

[John: Section 1 states: "Table 1 summarizes the algorithms that CMS
implantations MUST support and SHOULD support."  Without the addition of the
recommended note, then Table 1 incorrectly states that Triple-DES Key Wrap
and HMAC with SHA-1 are MUST algorithms for all CMS implementations.  That
is not true.  Only those CMS implementations that support the
previously-distributed symmetric KEK or key agreement key management
techniques MUST implement the Triple-DES Key Wrap algorithm.  Similarly,
only those CMS implementations that support the AuthenticatedData
content-type MUST implement the HMAC with SHA-1 algorithm.  If my
recommended  notes are not added, then Table 1 must be changed to indicate
that Triple-DES Key Wrap and HMAC with SHA-1 are SHOULD algorithms for all
CMS implementations.  In that case, I would agree that the text in the
algorithm description sections could include the notes that I recommended.
In summary, I believe that Table 1 must state the MUST requirements to be
consistent with the following message sent by Russ following the March 2001
S/MIME working group meeting:

"At the face-to-face S/MIME WG meeting yesterday, we came to consensus on a 
new set of mandatory to implement algorithms.  The people present 
overwhelmingly agreed on the following:

	Encryption:	Triple-DES

	Key Mgmt:	RSA (using PKCS #1 v1.5)

	Msg Digest:	SHA-1

	Signature:	DSA and RSA  (using PKCS #1 v1.5)

On signature, we will require that implementations are able to verify 
signatures on certificates and messages using both algorithms; however, 
implementations are required to generates signatures on messages using at 
least one of the signature algorithms."]


> 7) Table 1: I believe that a row should be added to represent
> key derivation
> algorithms since the password-based key management technique
> is documented
> in the rfc2630bis-01 I-D.  The
> draft-ietf-smime-password-03.txt I-D includes
> the PBKDF2 [RFC2898] key derivation algorithm as a MUST implement
> requirement, so I recommend that the following row should be
> added to Table
> 1:
>
>  Algorithm Type            MUST implement         SHOULD implement
>  -----------------------------------------------------------------
>  Key Derivation            PBKDF2 [RFC2898]       --

[Jim: I agree that this item needs to be added, however the full PBKDF2 is
not
what is currently specified by the document.  The password algorithm
information should be added to this document and the MUST should reference
this document.]

[John: Recommend that Peter Gutmann and/or yourself should propose the text
to be added to this document.]


> 8) Table 1. Key Derivation Note: Please add this note to
> immediately follow
> the table: "Note 3: Only those CMS implementations that support the
> password-based key management technique MUST implement the
> PBKDF2 [RFC2898]
> key derivation algorithm."  An alternate solution would be to
> change the
> table to include the PBKDF2 [RFC2898] key derivation
> algorithm as a SHOULD
> implement requirement, but then it would not be consistent with the
> draft-ietf-smime-password-03.txt I-D.

[Jim: See my comment on item #6]

[John: Without the addition of the recommended note, then Table 1 would
incorrectly state that PBKDF2 [RFC2898] is a MUST algorithm for all CMS
implementations.  That is not true.  Only those CMS implementations that
support the password-based key management technique MUST implement the
PBKDF2 [RFC2898] key derivation algorithm.  If the note is not added, then
Table 1 must indicate that PBKDF2 [RFC2898] is a SHOULD algorithm for all
CMS implementations.  In that case, I would agree that the text in the
password-based algorithm description section could include the note that I
recommended.]


> 9) Table 1, Message Authentication note:  Please add this note to
> immediately follow the table: "Note 3: Only those CMS
> implementations that
> support the AuthenticatedData content-type MUST implement the
> HMAC with
> SHA-1 algorithm."

[Jim: See my comment on item #6]

[John: Please see my response to item #6]


> 13) Section 4.3, 1rst para, 1rst sent: Please change MUST to
> SHOULD in the
> following sentence: "CMS implementations MUST support symmetric
> key-encryption key management."  I don't believe that the
> S/MIME working
> group has ever agreed that the previously-distributed
> symmetric KEK key
> management technique is a MUST implement requirement.

[Jim: I strongly support the original text.  This is a case where CMS and
S/MIME
have different requirements and that is reflected in this text.  CMS needs
to support KEK while S/MIME does not.]

[John: Why is supporting "symmetric KEK management" a MUST requirement for
CMS?  The S/MIME WG decided that RSA (PKCS #1 v1.5) will be the only MUST
implement key management algorithm.  Symmetric KEK algorithms are not
required to support the use of RSA (PKCS #1 v1.5) in conjunction with the
key transport key management technique.  Furthermore, RFC 2630 does not
state that supporting the previously-distributed symmetric KEK key
management technique (i.e. KEKRecipientInfo type) is a MUST requirement.
Are you making that proposal?  Am I missing something?  In summary, I still
believe that my recommended change should be made.]


> 14) Section 4.3, 1rst para, 2nd sent: Please change the following:
>
> OLD: "CMS implementations MUST include Triple-DES key-encryption keys
> wrapping Triple-DES content-encryption keys."
>
> NEW: "CMS implementations that support the
> previously-distributed symmetric
> KEK or key agreement key management techniques MUST include Triple-DES
> key-encryption keys wrapping Triple-DES content-encryption keys."
>

[Jim: See response to #13.  If that does not change then this does not need
to
change.]

[John: Please see my response to #13.  I still believe that my recommended
change should be made.]


> 15) Section 4.4, Please add:
>
> "4.4 Key Derivation Algorithms
>
> Key derivation algorithms are used to convert a password into
> a KEK as part
> of the password-based key management technique.  CMS
> implementations that
> support the password-based key management technique MUST implement the
> PBKDF2 [RFC2898] key derivation algorithm.  The
> KeyDerivationAlgorithmIdentifer identifies the key-derivation
> algorithm, and
> any associated parameters, used to derive the KEK from the
> user-supplied
> password.  The object identifier for the PBKDF2 [RFC2898] key
> derivation
> algorithm is TBD."

[Jim: I agree that this needs to be included, however the text is more
complicated
that this and needs to reflect the current state of the password document.]

[John: Recommend that Peter Gutmann and/or yourself should propose the text
to be added to this document.]

>
> 17) Section 7, 1rst paragraph: Please change the following:
>
> OLD: "CMS implementations MUST include encryption of a Triple-DES
> content-encryption key with a Triple-DES key-encryption key using the
> algorithm specified in Sections 7.2 and 7.3."
>
> NEW: "CMS implementations that support the
> previously-distributed symmetric
> KEK or key agreement key management techniques MUST include
> encryption of a
> Triple-DES content-encryption key with a Triple-DES
> key-encryption key using
> the algorithm specified in Sections 7.2 and 7.3."
>

[Jim: Ditto for response #14]

[John: Please see my response to #13.  I still believe that my recommended
change should be made.]

>
> ===========================================
> John Pawling, [e-mail]
> Getronics Government Solutions, LLC
> ===========================================
>


jim


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f65GKNt17516 for ietf-smime-bks; Thu, 5 Jul 2001 09:20:23 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f65GKMm17512 for <[e-mail]>; Thu, 5 Jul 2001 09:20:22 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id <KZJ98XXA>; Thu, 5 Jul 2001 12:20:37 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "'SMIME WG (E-mail)'" <[e-mail]>
Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01
Date: Thu, 5 Jul 2001 12:20:35 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jim,

Thank you for your responses to my comments.  My responses are included in
the message below.  I snipped the text that we agree on.

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================


-----Original Message-----
From: Jim Schaad [mailto:[e-mail]]
Sent: Tuesday, July 03, 2001 5:47 PM
To: 'Pawling, John'; 'SMIME WG (E-mail)'
Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01


Here are my comments on John.  I have left the number the same as the
orginal message.

<snip>

>
> 4) Section 6.2, RecipientInfo description:  Please delete
> "are" from the
> following sentence: "  [*** NEW ***] All implementations MUST
> support the
> mandatory to implement key management algorithms are
> specified in [CMSALG],
> or its successor."

[Jim: As I have said before - and is a new topic - I disagree and feel the
entire
paragragh should be deleted.]

[John: The intent of my comment was simply to correct the grammar of the
sentence.  I believe that this issue should be discussed in messages sent in
response to Russ' 28 June "Mandatory to Implement Algorithms in CMS" message
that addressed your original comment.]

<snip>


> 7) Section 6.2.4, recommend changing PasswordRecipientInfo
> version value to
> 1.  This would cause the EnvelopedData version number to be
> set to 2 if the
> PasswordRecipientInfo was present.  This would assist with
> debugging and
> error reporting.

[Jim: I disagree with this.  This is the version struture of the
PasswordRecipientInfo structure and is independent of the EnvelopedData
version number.  I think however that the version number of EnvelopedData
needs to be 3 if
either PasswordRecipientInfo or OtherRecipient is present as these are "new"
structure and thus modify the behavior of the processing an EnvelopedData
object.]

[John: I agree that the PasswordRecipientInfo version value should not be
changed.  I also agree that the Section 6.1, EnvelopedData version-setting
algorithm should be changed as you describe.  I propose the following
replacement text (same as proposed in my 7/2 reply to Russ):

   [*** NEW ***] version is the syntax version number.  The
   appropriate value depends on originatorInfo, RecipientInfo, and
   unprotectedAttrs.  The version MUST be assigned as follows:

    IF ((originatorInfo is present) AND 
	 (any version 2 attribute certificates are present)) OR
	 (any RecipientInfo structures are pwri CHOICE) OR
 	 (any RecipientInfo structures are ori CHOICE)
    THEN version is 3
    ELSE
	 IF (originatorInfo is present) OR
	    (unprotectedAttrs is present) OR
	    (any RecipientInfo structures are a version other than 0)
       THEN version is 2
       ELSE version is 0]


[Jim: I don't think that this will necessaryly need to be changed in the
future as we now have an explicit statement that implemenations MUST handle
other choices in the RecipientInfo.  This was not imposed in the past
however.]

[John: I agree that the EnvelopedData version-setting algorithm will not
need to be changed for new syntaxes defined for use within the RecipientInfo
ori CHOICE.  The EnvelopedData version-setting algorithm should be changed
if new syntaxes are added directly to the RecipientInfo CHOICE in future
versions of the CMS spec.  I believe that the text to which you are
referring was present in rfc2630bis-00, but deleted from rfc2630bis-01.
rfc2630bis-01 states: "all implementations MUST gracefully handle
unimplemented alternatives within the RecipientInfo CHOICE".]


> 11) Section 11.1 Content Type:  Please add as last sentence of first
> paragraph: "The content-type attribute value MUST match the
> encapContentInfo
> eContentType value in the signed-data or authenticated-data."

[Jim: Do we consider a non-match to be a signature failure?  This is not
currently
stated anyplace.  I think that we should probably add this.]

[John: I agree that a non-match is a critical security error.  Propose that
the following sentence be added to Section 5.6 Message Signature
Verification Process as the last paragraph:  "If the signedData signerInfo
includes signedAttributes and the content-type attribute value is different
from the signedData encapContentInfo eContentType value, then the CMS
implementation MUST report an error."  

Propose that the following sentence be added to Section 9.3 MAC Verification
as the last paragraph:  "If the authenticatedData includes
authenticatedAttributes and the content-type attribute value is different
from the authenticatedData encapContentInfo eContentType value, then the CMS
implementation MUST report an error."]


> 12) Section 11.2 Message Digest: Please replace the last
> paragraph with the
> following:
>
>    "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 message-digest
> attribute.  Similarly,
>    the AuthAttributes in an AuthenticatedData MUST NOT
> include multiple
>    instances of the message-digest attribute."

[Jim: I agree that the AuthAttributes statement needs to be added.  However,
I
think this should be a MUST not a MUST NOT as MUST NOT is not testable.]

[John: Agree.  Propose the following new text:  "The SignedAttributes syntax
and AuthAttributes syntax are each defined as a SET OF Attributes.  The
SignedAttributes in a signerInfo MUST include a single instance of the
message-digest attribute.  Similarly, the AuthAttributes in an
AuthenticatedData MUST include a single instance of the message-digest
attribute."

Also, we should make the following replacement in Section 11.1 Content Type:


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

NEW: The SignedAttributes syntax and AuthAttributes syntax are each defined 
     as a SET OF Attributes.  The SignedAttributes in a signerInfo MUST 
     include a single instance of the content-type attribute.  Similarly,
     the AuthAttributes in an AuthenticatedData MUST include a single
     instance of the content-type attribute.]

== jim


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f63MwU601551 for ietf-smime-bks; Tue, 3 Jul 2001 15:58:30 -0700 (PDT)
Received: from femail12.sdc1.sfba.home.com (femail12.sdc1.sfba.home.com [24.0.95.108]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f63MwTm01546 for <[e-mail]>; Tue, 3 Jul 2001 15:58:29 -0700 (PDT)
Received: from revelation ([65.4.166.11]) by femail12.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010703225826.BLDI29724.femail12.sdc1.sfba.home.com@revelation>; Tue, 3 Jul 2001 15:58:26 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Pawling, John'" <[e-mail]>, "'Ietf-Smime \(E-mail\)'" <[e-mail]>
Subject: RE: Jim's Comments: draft-ietf-smime-cmsalg-00
Date: Tue, 3 Jul 2001 15:58:24 -0700
Message-ID: <000c01c10413$aaad5320$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

John,

Here are my responses to your comments.

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Pawling, John
> Sent: Tuesday, July 03, 2001 8:31 AM
> To: Ietf-Smime (E-mail)
> Subject: RE: Jim's Comments: draft-ietf-smime-cmsalg-00
>
>
>
> All,
>
> I have the following comments regarding Jim Schaad's 7 June
> comments to the
> draft-ietf-smime-cmsalg-00.txt Internet-Draft.  My comments [JP] are
> numbered consistently with Jim's original message.  I omitted
> Jim's comments
> with which I agree.
>
> 2) Section 2.1:  Jim stated: "I believe that the MUST and
> SHOULD statements
> in this paragraph are in conflict.  ie. MUST encode as and
> SHOULD generate
> with.  These should be resolved as MUST in both locations."
>
> [JP: I disagree with Jim that the MUST and SHOULD statements are in
> conflict.  The paragraph states: "If present, the parameters
> field MUST
> contain an ASN.1 NULL."  In my opinion, it is clear that the MUST
> requirement does not apply if the parameters field is absent.  I also
> disagree with Jim's recommendation to change the spec to state that
> implementations MUST populate the algorithmIdentifier
> parameters field with
> an ASN.1 NULL.  I believe that the text should remain unchanged.]

If present, the parameters field MUST contain an ASN.1 NULL.
Implementations SHOULD generate SHA-1 AlgorithmIdentifiers with NULL
parameters.

I believe that the second line is a MUST not a SHOULD.  I don't object to
the SHOULD handle if it is wrong, but generation needs to be with NULL
parameters.

>
>
> 6) Section 3.2:  Jim stated "Boy we really messed this one
> up.  Section 3.2
> should occur
> as two different sections one for RSAwithMD5 and one for
> RSAwithSHA1.  I
> will never understand how all of us missed this one.
>
> The OIDs for this should be:
>        sha1withRSAEncryption (1 2 840 113549 1 1 5)
> or
> #define szOID_OIWSEC_sha1RSASign "1.3.14.3.2.29"
>
>        md5withRSAEncryption (1 2 840 113549 1 1 4)"
>
> [JP: I disagree with Jim's statements.  To support backwards
> compatibility
> with S/MIME v2 implementations that only recognize the
> rsaEncryption OID, we
> specified that the rsaEncryption OID must be included in the
> signedData
> signerInfo signatureAlgorithm field.  We decided not to
> specify the use of
> the sha-1WithRSAEncryption, md2withRSAEncryption, or
> md5withRSAEncryption
> OIDs in the signerInfo signatureAlgorithm field.]

John -- If I look in the examples draft, the OID that is in the
signatureAlgorithm field of a SignerInfo field is
  119 30   13:             SEQUENCE {
  121 06    9:               OBJECT IDENTIFIER
             :                 sha1withRSAEncryption (1 2 840 113549 1 1 5)
             :                 (PKCS #1)
  132 05    0:               NULL
             :               }
Not RSA.  I don't have the foggiest idea of what you are talking about for
backwards compatability.  This is not an argument that I have ever heard
before (I think).

I think you have not looked at this correctly and ask that you re-check what
I am saying.

>
>
> 7a) Section 4.1, para 2:  Jim stated: "There is a different
> in language
> here.
> -   if ContentEncryptionAlg MUST KEK Alg.
> -   SHOULD 3DES KEK
> -   SHOULD RC2 KEK
> -   MUST 3DES KEK on 3DES Content
> -   MUST RC2 KEK on RC2 content.
>
> Let me make a new stab at this:
>
> Keep para 1 from section 4.1.
>
> The following is the rest of section 4.1:
>
> A key agreement algorithm consists of the following items:
> 1.  A shared secrect computation that takes the originator
> and receipient
> keys and computes a shared secret.
> 2.  A symmetric key derivation algorithm that uses the shared
> secret to
> compute a symmetric key.
> 3.  A key-wrap algorithm which uses the symmetric key
> generated by 2 to
> encryption the CEK producing the value encded in the CMS kari
> structure."
>
> [JP: I do not object to the addition of Jim's new text
> (bullets 1-3 above),
> but I do object to the deletion of the remainder of section 4.1 (i.e.
> paragraphs 2-7).  I believe that text is necessary to explain
> the use of the
> KeyAgreeRecipientInfo fields.]

I agree that the paragraphs describing how to use the different fields does
need to be included.

>
>
> 7b) Jim stated:
> "4.1.1  X9.42 Ephemeral-Static Diffie-Hellman
>
> The shared-secret computation and symmetric key derivation
> algorithms for
> Ephemeral-Static Diffie-Hellman key agreement are defined in RFC 2631
>    [DH-X9.42].  E-S D-H uses the KEK algorithms defined in
> section 4.3 for
> the key wrap algorithm.  ES DH MUST support the 3DES KEK for
> key wrapping.
> ES DH SHOULD support RC2 KEK for key wrapping."
>
> [JP: I agree with the intent of Jim's comments.  Recommend that the
> following sentences should replace the first sentence in
> section 4.1.1, para
> 1:
>
> "The shared-secret computation and symmetric key derivation
> algorithms for
> Ephemeral-Static (E-S) Diffie-Hellman (D-H) key agreement are
> defined in RFC
> 2631 [DH-X9.42].  The key wrap algorithms defined in section
> 4.3 of this
> document are used in conjunction with E-S D-H.  CMS
> implementations that
> include E-S D-H MUST support the use of Triple-DES
> key-encryption keys to
> wrap Triple-DES content-encryption keys and SHOULD support
> the use of RC2
> key-encryption keys to wrap RC2 content-encryption keys."]
>
>
> 7c) Jim stated: "keyEncryptionAlgorithm MUST be the
> id-alg-ESDH algorithm
> << Changed
>       identifier.  The algorithm identifier parameter field
> for id-alg-
>       ESDH is KeyWrapAlgorithm, and this parameter MUST be
> present.  The
> << Changed
>       KeyWrapAlgorithm denotes the key wrap algorithm used
> << Changed
>       to encrypt the content-encryption key with the pairwise key-
>       encryption key generated using the X9.42
> Ephemeral-Static Diffie-
>       Hellman key agreement algorithm.  The document uses the
> KEK algorithms
> defined in section 4.3 as the key wrap algorithms.  The KEK
> algorithm used
> is defined in the KeyWrapAlgorithm parameter."
>
> [JP: I agree with Jim's comments, except that I believe that the last
> sentence should be deleted because it is redundant with the
> third sentence.
> Also, I recommend the following wordsmithing of the fourth
> sentence:  "The
> document uses the key wrap algorithms defined in section 4.3.".]

This seems fine.

>
>
> 7d) Jim stated: "New requirement: When deriving a Triple-DES
> key, a three
> key Triple-DES key
> MUST be derived.  When deriving a Triple-DES key wrap key,
> the parity on
> each of the three sub-keys MUST be correctly generated after the key
> derivation process is complete."
>
> [JP: Agree.]
>
>
> 12) Section 7:  Jim stated: "I do not believe this section
> needs any MUSTS
> for inclusion
> of algorithms.  That is covered in section 4."
>
> [JP: Rather than delete the first sentence of Section 7, I
> believe that it
> should be changed to: "CMS implementations that support the
> previously-distributed symmetric KEK or key agreement key management
> techniques MUST include encryption of a Triple-DES
> content-encryption key
> with a Triple-DES key-encryption key using the algorithm specified in
> Sections 7.2 and 7.3."]

I stand by my original comment.  This is a duplication of a MUST and should
be where it makes sense (where the algorithm is used) not here.

>
> ===========================================
> John Pawling, [e-mail]
> Getronics Government Solutions, LLC
> ===========================================
>


jim



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f63MkXh01222 for ietf-smime-bks; Tue, 3 Jul 2001 15:46:33 -0700 (PDT)
Received: from femail12.sdc1.sfba.home.com (femail12.sdc1.sfba.home.com [24.0.95.108]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f63MkWm01218 for <[e-mail]>; Tue, 3 Jul 2001 15:46:32 -0700 (PDT)
Received: from revelation ([65.4.166.11]) by femail12.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010703224630.WPD29724.femail12.sdc1.sfba.home.com@revelation>; Tue, 3 Jul 2001 15:46:30 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Pawling, John'" <[e-mail]>, "'SMIME WG \(E-mail\)'" <[e-mail]>
Subject: RE: cmsalg-00 Comments
Date: Tue, 3 Jul 2001 15:46:24 -0700
Message-ID: <000b01c10411$fdeae770$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

John,

Here are the comments I have:

>
> 1) General comment: Since there are multiple techniques for
> using the RSA
> algorithm, please replace all occurrences of "RSA" with "RSA
> (PKCS #1 v1.5)"
> as appropriate.

I thought about recommending this change as well.  The reason that I did not
was that the only reference in the document was to the v1.5.  I could go
either way on this issue.

>
> 3) Section 1, para 3:  Please change "Algorithm are be identified" to
> "Algorithms can be identified".

I disagree with this change.  The correct text is "are" as this is the only
way we are identifing these algorithms.  If you think it should be "can",
please show another way that they can be identified.

>
> 6) Table 1, Symmetric KEK Wrap note:  Please add this note to
> immediately
> follow the table: "Note 2: Only those CMS implementations
> that support the
> previously-distributed symmetric KEK or key agreement key management
> techniques MUST implement the Triple-DES Key Wrap algorithm."
>  An alternate
> solution is to change the table such that "Triple-DES Key
> Wrap" is a SHOULD
> implement requirement.

I disagree with the addition of this node.  I don't think that the table is
where this should be specified.  This type of text belongs with the
algorithm description.

>
> 7) Table 1: I believe that a row should be added to represent
> key derivation
> algorithms since the password-based key management technique
> is documented
> in the rfc2630bis-01 I-D.  The
> draft-ietf-smime-password-03.txt I-D includes
> the PBKDF2 [RFC2898] key derivation algorithm as a MUST implement
> requirement, so I recommend that the following row should be
> added to Table
> 1:
>
>  Algorithm Type            MUST implement         SHOULD implement
>  -----------------------------------------------------------------
>  Key Derivation            PBKDF2 [RFC2898]       --

I agree that this item needs to be added, however the full PBKDF2 is not
what is currently specified by the document.  The password algorithm
information should be added to this document and the MUST should reference
this document.

>
> 8) Table 1. Key Derivation Note: Please add this note to
> immediately follow
> the table: "Note 3: Only those CMS implementations that support the
> password-based key management technique MUST implement the
> PBKDF2 [RFC2898]
> key derivation algorithm."  An alternate solution would be to
> change the
> table to include the PBKDF2 [RFC2898] key derivation
> algorithm as a SHOULD
> implement requirement, but then it would not be consistent with the
> draft-ietf-smime-password-03.txt I-D.

See my comment on item #6

>
> 9) Table 1, Message Authentication note:  Please add this note to
> immediately follow the table: "Note 3: Only those CMS
> implementations that
> support the AuthenticatedData content-type MUST implement the
> HMAC with
> SHA-1 algorithm."

See my comment on item #6

> 13) Section 4.3, 1rst para, 1rst sent: Please change MUST to
> SHOULD in the
> following sentence: "CMS implementations MUST support symmetric
> key-encryption key management."  I don't believe that the
> S/MIME working
> group has ever agreed that the previously-distributed
> symmetric KEK key
> management technique is a MUST implement requirement.

I strongly support the original text.  This is a case where CMS and S/MIME
have different requirements and that is reflected in this text.  CMS needs
to support KEK while S/MIME does not.

>
> 14) Section 4.3, 1rst para, 2nd sent: Please change the following:
>
> OLD: "CMS implementations MUST include Triple-DES key-encryption keys
> wrapping Triple-DES content-encryption keys."
>
> NEW: "CMS implementations that support the
> previously-distributed symmetric
> KEK or key agreement key management techniques MUST include Triple-DES
> key-encryption keys wrapping Triple-DES content-encryption keys."
>

See response to #13.  If that does not change then this does not need to
change.

>
> 15) Section 4.4, Please add:
>
> "4.4 Key Derivation Algorithms
>
> Key derivation algorithms are used to convert a password into
> a KEK as part
> of the password-based key management technique.  CMS
> implementations that
> support the password-based key management technique MUST implement the
> PBKDF2 [RFC2898] key derivation algorithm.  The
> KeyDerivationAlgorithmIdentifer identifies the key-derivation
> algorithm, and
> any associated parameters, used to derive the KEK from the
> user-supplied
> password.  The object identifier for the PBKDF2 [RFC2898] key
> derivation
> algorithm is TBD."

I agree that this needs to be included, however the text is more complicated
that this and needs to reflect the current state of the password document.

>
> 17) Section 7, 1rst paragraph: Please change the following:
>
> OLD: "CMS implementations MUST include encryption of a Triple-DES
> content-encryption key with a Triple-DES key-encryption key using the
> algorithm specified in Sections 7.2 and 7.3."
>
> NEW: "CMS implementations that support the
> previously-distributed symmetric
> KEK or key agreement key management techniques MUST include
> encryption of a
> Triple-DES content-encryption key with a Triple-DES
> key-encryption key using
> the algorithm specified in Sections 7.2 and 7.3."
>

Ditto for response #14

>
> ===========================================
> John Pawling, [e-mail]
> Getronics Government Solutions, LLC
> ===========================================
>


jim



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f63MHBd00679 for ietf-smime-bks; Tue, 3 Jul 2001 15:17:11 -0700 (PDT)
Received: from femail12.sdc1.sfba.home.com (femail12.sdc1.sfba.home.com [24.0.95.108]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f63MHAm00675 for <[e-mail]>; Tue, 3 Jul 2001 15:17:10 -0700 (PDT)
Received: from revelation ([65.4.166.11]) by femail12.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010703221703.ZJZW29724.femail12.sdc1.sfba.home.com@revelation>; Tue, 3 Jul 2001 15:17:03 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Comments: draft-ietf-smime-rfc2630bis-00
Date: Tue, 3 Jul 2001 15:17:00 -0700
Message-ID: <000a01c1040d$e26ffac0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

Here are my responses, where an item is omitted you can assume that I agree
with your resolution.

>
> > > >1.  "The CMS ..." should be uniformly changed to "CMS ...".
> > > I think that "The Cryptographic Message Syntax (CMS) ..."
> is correct.  Are
> > > there places that I omitted "the"?
> >
> >Actually I have no problems with "The Crryptographic Message
> Syntax (CMS)".
> >However as I look at the abstract for draft -00, the second
> paragraph starts
> >"The CMS is derived from PKCS#7 ..."  In doing searches of
> the draft the
> >phrase "the CMS" is quite common.  I count 5 that should be altered.
>
> Okay.  I added "the" in the places that seems appropriate.

I will need to read what you did.  I was actully asking for "the" to be
omitted. I think that "The CMS" is incorrect.

> > > >16) Section 5.3, para "attrValues":  Append the
> following sentence.
> > > >"attrType may impose additional restrictions on the
> number of items in the
> > > >set."
> > >
> > > How about:
> > >
> > >     attrValues is a set of values that comprise the
> attribute.  The
> > >     type of each value in the set can be determined uniquely by
> > >     attrType.  The attrType MAY impose restrictions on
> the number of
> > >     items in the set.
> >
> >I think this should be may not MAY as there is no protocol
> statement at this
> >point.  If you want one then it should be "Signatures MUST
> fail verification
> >if any restrictions on the number of items in the set, imposed by an
> >attrType definition, are not met."
>
> Agree, the "MAY" should be "can".
>
> I go not agree with the MUST statement that you suggest.  To
> enforce this,
> a recipient must know all possible OIDs and the restrictions
> associated
> with them.
>
> The text now reads (I provided a bit more surrounding text
> for context):
>
>     The fields of type SignedAttribute and UnsignedAttribute have the
>     following meanings:
>
>        attrType indicates the type of attribute.  It is an object
>        identifier.
>
>        attrValues is a set of values that comprise the attribute.  The
>        type of each value in the set can be determined uniquely by
>        attrType.  The attrType can impose restrictions on the
> number of
>        items in the set.

Can we add the statement about failing verification to the attributes that
we have defined where it make sense?  I think that if there are two
content-type or two message-digest attributes that the verification process
really needs to fail.  I am more unsure what should be done for other
attributes as you are correct that an exhaustive set would be required to
verify.  Let me think about this issue.

> > > >25) Section 6.2.1, para "rid": Two items
> > > >a)  do we want to change to text to allow for SKI's to be
> > non-certificate based.
> >[Snip]
> >
> > > >c)  do we need to support both for specifying the
> certificate or just for
> > > >locating a certificate? (i.e. encode vs decode)
> > >
> > > We need both (for send and receive).  I prefer the
> subject key identifier;
> > > it is smaller.  However, S/MIME v2 requires issuer and
> serial number, which
> > > is bigger than a subject key identifier.  If you do not
> think that the MUST
> > > statement is complete, please propose an alternative.
> >
> >Alternative:  "Implementations MUST support both
> alternatives for specifying
> >the recipient's certificate when decoding.  Implementations
> MUST support one
> >of these alternatives for encoding."
>
> John Pawling said: Recommend changing second sentence to:
> "Implementations
> MUST support at least one of these alternatives for encoding.".
>
> In an attempt to use the same terminology as the rest of the
> paragraph, I
> prefer "recipient processing" to "decode" and "sender
> processing" to "encode."
>
> How about:
>
>        rid specifies the recipient's certificate or key that
> was used by
>        the sender to protect the content-encryption key.  The
>        RecipientIdentifier provides two alternatives for
> specifying the
>        recipient's certificate, and thereby the recipient's
> public key.
>        The recipient's certificate MUST contain a key transport public
>        key.  The content-encryption key is encrypted with the
> recipient's
>        public key.  The issuerAndSerialNumber alternative
> identifies the
>        recipient's certificate by the issuer's distinguished
> name and the
>        certificate serial number; the subjectKeyIdentifier
> identifies the
>        recipient's certificate by the X.509 subjectKeyIdentifier
>        extension value.  [*** NEW ***] For recipient processing,
>        implementations MUST support both of these alternatives for
>        specifying the recipient's certificate; and for sender
> processing,
>        implementations MUST support one at least of these
> alternatives.

I would have liked to allow for SKI to be used in a non-certificate
environment, but I don't have any problems with the updated text.

>
> > > >27) Section 6.2.2, para "ukm":  I believe this is a MUST
> not a SHOULD
> > > >statement.  I understand that we don't require it for the default
> > algorithm
> > > >(ESDH), but it is premitted to occur.  If UKM is not
> supported then
> > all that
> > > >could be done would be to ignore the recipient.  (Note:
> there is a
> > MUST use
> > > >UKM in rfc2631 for one case.)
> > >
> > > UKM is required for Static-Static Diffie-Hellman.  I
> basically agree with
> > > your point, and it is not a big burden on an
> implementation. However, I
> > > would like to hear from more implementors before I make a
> change here.
> >
> >John - please respond.
>
> John Pawling said: Recommend the following replacement:
>
> OLD:  [*** NEW ***] Implementations SHOULD support UKM
> processing.  Implementations that do not process UKMs MUST gracefully
> handle the presence of UKMs.
>
> NEW:  [*** NEW ***] Implementations MUST support ASN.1 decoding a
> KeyAgreeRecipientInfo SEQUENCE that includes a ukm field.
> Implementations
> that do not fully support the processing of UKMs MUST
> gracefully handle the
> presence of UKMs.
>
> Thanks John.  Again, in an attempt to use common terminology, I prefer
> "recipient processing" to "decode."  How about:
>
>        ukm is optional.  With some key agreement algorithms,
> the sender
>        provides a User Keying Material (UKM) to ensure that a
> different
>        key is generated each time the same two parties generate a
>        pairwise key.  [*** NEW ***] Implementations MUST support
>        recipient processing of a KeyAgreeRecipientInfo SEQUENCE that
>        includes a ukm field.  Implementations that do not support key
>        agreement algorithms that make use of UKMs MUST
> gracefully handle
>        the presence of UKMs.

I agree with the update.

>
> > > >28) Section 6.3.  Lets seperate the discussion on how to
> pad from the
> > > >content encryption process.  I believe this should be
> moved to the
> > algorithm
> > > >section or a seperate section in this document.  The CEK
> algorithm is what
> > > >determines the padding method not CMS.
> > >
> > > Not true.  CMS encryption always uses this padding.  CMS
> also supports
> > > algorithms that do not require any padding (for example,
> a stream cipher),
> > > but if padding is needed, this is the padding technique
> that MUST be used.
> >
> >I beg to differ with you on this issue.  I believe that I
> could define a new
> >OID for RC5 with Ron's funky padding mode where the cipher
> text and plain
> >text are the same lengths.  More importantly, with some of
> the new chaining
> >modes for AES where there is interleaving between mutiple
> chains, I can see
> >the padding to be done over a multiple of n blocks of data
> rather than one.
> >I repeat, the padding alogorithm is a fucntion of the
> specified encryption
> >algorithm and is not fixed.
>
> You have not convinced me.  The way that I read the RFC 2630
> text, we are
> saying that if padding is needed, then this one padding
> technique must be
> used.  If no padding is needed, as is the case if Triple-DES
> CFB8 is used,
> then no padding is present.  If one of the proposed AES modes
> that provide
> integrity and confidentiality were employed, the value of k
> might not match
> the AES block size, but padding is still needed.
>
> Right now, if padding is needed, we have one and only one way
> to do it.  I
> want to preserve this feature.  In my view, support for other padding
> approaches will only lead to more ways to fail interoperability.
>
> If you still feel strongly about this one, please start a
> separate thread
> for the discussion.

You have not convinced me, but I will think about this.

>
> > > >29) Section 6.3, para 2:  I don't like the second
> sentence in this
> > > >paragraph.  The content begin encrypted has little or
> nothing to do
> > with the
> > > >value of the encrypted data octet string.  This is the
> post encryption
> > > >value.
> > >
> > > I understand your point.  These words have not changed in
> a very long
> > > time.  Perhaps you would like to propose some better ones.
> >
> >Proposal:  "The input to the content-encryption process is
> the "value" of
> >the content being enveloped.  The resulting value of the
> encryption process
> >is then wrapped in an OCTET string for transporting."
>
> John Pawling said: I believe that this paragraph should be
> deleted because
> it is redundant to the first paragraph in section 6.3.
>
> There was one point in the second paragraph that I thought should be
> preserved.  I have merged the two paragraphs as follows:
>
>     The content-encryption key for the desired content-encryption
>     algorithm is randomly generated.  The input to the
> content-encryption
>     process is the "value" of the content being enveloped.  This input
>     data is padded as described below, then the padded data
> is encrypted
>     using the content-encryption key.  The encryption
> operation maps an
>     arbitrary string of octets (the data) to another string of octets
>     (the ciphertext) under control of a content-encryption key.  The
>     encrypted data is included in the envelopedData
> encryptedContentInfo
>     encryptedContent OCTET STRING.
>
> Note:  Nothing is marked as "[*** NEW ***]."  I consider this
> change to be
> completely editorial.

I don't like the text "This input data is padded as described below, ...".
However as this relates to my comment #28, I will think about this before
objecting.

>
> > > >37) Section 11.1: There MUST be exactly one instance of
> AttributeValue
> > > >present.  -- MUST NOT is not testable.
> > >
> > > It says: "A content-type attribute MUST have a single
> attribute value, even
> > > though the syntax is defined as a SET OF AttributeValue.
> There MUST NOT be
> > > zero or multiple instances of AttributeValue present."
> > >
> > > So, you agree with the first sentence.  I think the
> second sentence is a
> > > restatement of the first.  Does the second sentence help
> anyone understand?
> >
> >I don't believe that the second statement helps.  I did miss
> the fact that
> >it is a restatement of the first.
>
> Perhaps making it all one sentence will make it clear that
> there is only
> one idea being expressed.  I consider this an editorial
> change, and I did
> not insert "[*** NEW ***]."
>
> How about:
>
>     Even though the syntax is defined as a SET OF AttributeValue, a
>     content-type attribute MUST have a single attribute value; zero or
>     multiple instances of AttributeValue are not permitted.
>

I find this much clearer

>
> Russ
>


jim



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f63Lnm129968 for ietf-smime-bks; Tue, 3 Jul 2001 14:49:48 -0700 (PDT)
Received: from femail12.sdc1.sfba.home.com (femail12.sdc1.sfba.home.com [24.0.95.108]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f63Lnlm29964 for <[e-mail]>; Tue, 3 Jul 2001 14:49:47 -0700 (PDT)
Received: from revelation ([65.4.166.11]) by femail12.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010703214944.YBKE29724.femail12.sdc1.sfba.home.com@revelation>; Tue, 3 Jul 2001 14:49:44 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Pawling, John'" <[e-mail]>, <[e-mail]>
Subject: RE: Comments: draft-ietf-smime-rfc2630bis-00
Date: Tue, 3 Jul 2001 14:49:42 -0700
Message-ID: <000901c1040a$121bcb40$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I have no problems with any of John's comments.

jim

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Pawling, John
> Sent: Wednesday, June 27, 2001 12:50 PM
> To: [e-mail]
> Subject: RE: Comments: draft-ietf-smime-rfc2630bis-00
> 
> 
> 
> All,
> 
> I agree with the majority of Jim's comments and Russ' 
> responses.  I have a
> few comments regarding their statements.  My comments are numbered
> consistently with Jim's original message.   
> 
> 
> 14) Section 5.3, SignerInfo signature description:  Jim 
> stated: "I don't
> understand the MUST in this paragraph.  The field is not 
> optional how can it
> be omitted?  The MUST is redundant."  I agree with Jim.  Recommend the
> following replacement:
> 
> OLD: [*** NEW ***] This field MUST be present; however, the 
> details of the
> signature
>      depend on the signature algorithm employed.
> 
> NEW: [*** NEW ***] The details of the signature depend on the 
> signature
> algorithm employed.
> 
> 
> 21) Section 6.1, EnvelopedData:  I agree with Jim's recommendation as
> follows: "Should change the ASN to "RecipientInfos ::= SET 
> SIZE (1..MAX) OF
> RecipientInfo" to reflect the MUST in the text?"
> 
> 
> 25) Section 6.2.1, KeyTransRecipientInfo rid description: Jim 
> proposed:
> "Alternative:  "Implementations MUST support both alternatives for
> specifying the recipient's certificate when decoding.  
> Implementations MUST
> support one of these alternatives for encoding."  Recommend 
> changing second
> sentence to: "Implementations MUST support at least one of these
> alternatives for encoding.".
> 
> 
> 27) Section 6.2.2, KeyAgreeRecipientInfo ukm description: Jim 
> stated: "I
> believe this is a MUST not a SHOULD statement."  Recommend 
> the following
> replacement:
> 
> OLD:  [*** NEW ***] Implementations SHOULD support UKM
>       processing.  Implementations that do not process UKMs MUST
>       gracefully handle the presence of UKMs.
> 
> NEW:  [*** NEW ***] Implementations MUST support ASN.1 decoding a 
> 	KeyAgreeRecipientInfo SEQUENCE that includes a ukm field.
> 	Implementations that do not fully support the processing of
> 	UKMs MUST gracefully handle the presence of UKMs.  
> 
> 
> 29) Section 6.3 Content-encryption Process, paragraph 2:  Jim 
> Proposed: "The
> input to the content-encryption process is the "value" of the 
> content being
> enveloped.  The resulting value of the encryption process is 
> then wrapped in
> an OCTET string for transporting."  I believe that this 
> paragraph should be
> deleted because it is redundant to the first paragraph in 
> section 6.3.  
> 
> 
> 36) Section 11.1 Content Type:  Jim proposed: "Content-type 
> MUST be omitted
> when building counter signatures."  I agree with Jim.  Recommend the
> following re-wording of his proposal be added as the last 
> sentence of the
> 1rst paragraph: "The content-type attribute MUST be omitted 
> when used as
> part of a countersignature unsigned attribute as defined in 
> section 11.4."
> 
> 
> 39) Section 11.3 Signing Time:  Jim stated and Russ agreed: 
> "I think we
> should loosen up the locations allows for signing-time.  I 
> would like to see
> it allowed as an autenticated attribute."
> I don't object to this change.  If the change is made, please make the
> following replacement:
> 
> OLD: 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.
> 
> 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 signing-time 
> attribute.  Similarly,
>      the AuthAttributes in an AuthenticatedData MUST NOT 
> include multiple
>      instances of the signing-time attribute.
> 
> 
> 43) Section 11.4 Countersignature:  Jim stated "Item 1 in the values.
> Change to "... but MUST NOT contain a content-type attribute. 
> (No content
> type has been defined for a counter-signature.)"  Recommend 
> the following
> replacement:
> 
> OLD:  1.  The signedAttributes field MUST contain a message-digest
>       attribute if it contains any other attributes, but need not
>       contain a content-type attribute, as there is no 
> content type for
>       countersignatures.
> 
> NEW:  1.  The signedAttributes field MUST contain a message-digest
>       attribute if it contains any other attributes.
> 
> 	2.  The signedAttributes field MUST NOT contain a content-type
> 	attribute, because there is no content type for 
> countersignatures.
> 
> 
> ===========================================
> John Pawling, [e-mail]
> Getronics Government Solutions, LLC
> ===========================================
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f63Ll1V29916 for ietf-smime-bks; Tue, 3 Jul 2001 14:47:01 -0700 (PDT)
Received: from femail12.sdc1.sfba.home.com (femail12.sdc1.sfba.home.com [24.0.95.108]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f63Ll0m29912 for <[e-mail]>; Tue, 3 Jul 2001 14:47:00 -0700 (PDT)
Received: from revelation ([65.4.166.11]) by femail12.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010703214658.XXRH29724.femail12.sdc1.sfba.home.com@revelation>; Tue, 3 Jul 2001 14:46:58 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Pawling, John'" <[e-mail]>, "'SMIME WG \(E-mail\)'" <[e-mail]>
Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01
Date: Tue, 3 Jul 2001 14:46:56 -0700
Message-ID: <000801c10409$aefa71b0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Here are my comments on John.  I have left the number the same as the
orginal message.

>
> 2) Section 5.1, SignedData certificates description:  Please
> delete: "As
> discussed above, if attribute certificates are present, then
> the value of
> version MUST be 3."  I don't believe that we need to repeat
> the version
> setting algorithm in this text.

I very much agree with this.  Having a MUST requirement specified multiple
times is confusing in many ways.

>
> 4) Section 6.2, RecipientInfo description:  Please delete
> "are" from the
> following sentence: "  [*** NEW ***] All implementations MUST
> support the
> mandatory to implement key management algorithms are
> specified in [CMSALG],
> or its successor."

As I have said before - and is a new topic - I disagree and feel the entire
paragragh should be deleted.

>
> 5) Section 6.2: I strongly agree that the pwri and ori
> CHOICES should be
> included in RecipientInfo.

I concur with this.

> 7) Section 6.2.4, recommend changing PasswordRecipientInfo
> version value to
> 1.  This would cause the EnvelopedData version number to be
> set to 2 if the
> PasswordRecipientInfo was present.  This would assist with
> debugging and
> error reporting.

I disagree with this.  This is the version struture of the
PasswordRecipientInfo structure and is independent of the EnvelopedData
version number.

I think however that the version number of EnvelopedData needs to be 3 if
either PasswordRecipientInfo or OtherRecipient is present as these are "new"
structure and thus modify the behavior of the processing an EnvelopedData
object.  I don't think that this will necessaryly need to be changed in the
future as we now have an explicit statement that implemenations MUST handle
other choices in the RecipientInfo.  This was not imposed in the past
however.

> 11) Section 11.1 Content Type:  Please add as last sentence of first
> paragraph: "The content-type attribute value MUST match the
> encapContentInfo
> eContentType value in the signed-data or authenticated-data."

Do we consider a non-match to be a signature failure?  This is not currently
stated anyplace.  I think that we should probably add this.

>
> 12) Section 11.2 Message Digest: Please replace the last
> paragraph with the
> following:
>
>    "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 message-digest
> attribute.  Similarly,
>    the AuthAttributes in an AuthenticatedData MUST NOT
> include multiple
>    instances of the message-digest attribute."

I agree that the AuthAttributes stateemnt needs to be added.  However, I
think this should be a MUST not a MUST NOT as MUST NOT is not testable.


== jim



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f63KwcF28784 for ietf-smime-bks; Tue, 3 Jul 2001 13:58:38 -0700 (PDT)
Received: from femail12.sdc1.sfba.home.com (femail12.sdc1.sfba.home.com [24.0.95.108]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f63Kwbm28780 for <[e-mail]>; Tue, 3 Jul 2001 13:58:37 -0700 (PDT)
Received: from revelation ([65.4.166.11]) by femail12.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010703205833.VMLH29724.femail12.sdc1.sfba.home.com@revelation>; Tue, 3 Jul 2001 13:58:33 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Blake Ramsdell'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: How to recognize an S/MIME message?
Date: Tue, 3 Jul 2001 13:58:31 -0700
Message-ID: <000701c10402$eb310ab0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I would agree that Outlook is out of spec.  It is forced on the product by
the Exchange server as previously stated.

I don't agree that this can be clarifed by an example.  However, I do think
that language should be included that applications MUST NOT generate the
octet-stream version of a message.  This is strictly left for "unfriendly"
gateways.

jim

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Blake Ramsdell
> Sent: Tuesday, June 19, 2001 12:14 PM
> To: '[e-mail]'; '[e-mail]'
> Subject: RE: How to recognize an S/MIME message?
>
>
>
> Perhaps this can be clarified with an example in the new RFC2633:
>
> 1. If the Content-Type is application/pkcs7-mime, then the
> content should be
> interpreted as a CMS object as specified in section 3.2
>
> 2. If the Content-Type is application/octet-stream, and the
> file extension
> is P7M, then the content ahould be interpreted as a CMS
> object as specified
> in section 3.2
>
> 3. If the Content-Type is application/pkcs7-signature then the content
> should be interpreted per sction 3.4.3.1
>
> 4. If the Content-Type is application/octet-stream, and the
> file extension
> is P7S, then the content should be interpreted per section 3.4.3.1
>
> Personally, I think that Outlook is out-of-spec, but I can
> see how section
> 3.8 could be misunderstood.
>
> Blake
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Tuesday, June 19, 2001 4:14 AM
> To: [e-mail]
> Subject: How to recognize an S/MIME message?
>
>
>
>
>
>
> My company is currently evaluating PKI and S/MIME components
> and we came
> across
> an apparent contradiction in the S/MIME v2 and v3 RFCs (RFC2311 and
> RFC2633).
>
>    Both documents have the following words in section 3.2.1:
>
>    Including a file name serves two purposes. It facilitates
> easier use
>    of S/MIME objects as files on disk. It also can convey type
>    information across gateways. When a MIME entity of type
>    application/pkcs7-mime (for example) arrives at a gateway
> that has no
>    special knowledge of S/MIME, it will default the entity's MIME type
>    to application/octet-stream and treat it as a generic attachment,
>    thus losing the type information. However, the suggested
> filename for
>    an attachment is often carried across a gateway. This often allows
>    the receiving systems to determine the appropriate application to
>    hand the attachment off to, in this case a stand-alone S/MIME
>    processing application. Note that this mechanism is provided as a
>    convenience for implementations in certain environments. A proper
>    S/MIME implementation MUST use the MIME types and MUST NOT rely on
>    the file extensions.
>
>    This clearly states that an S/MIME-capable E-Mail client must only
> recognize
> S/MIME messages when they use the correct MIME types.
> However, section 3.8
> of
> both documents seem to contradict section 3.2.1:
>
> 3.8 Identifying an S/MIME Message
>
>    Because S/MIME takes into account interoperation in non-MIME
>    environments, several different mechanisms are employed to
> carry the
>    type information, and it becomes a bit difficult to identify S/MIME
>    messages. The following table lists criteria for
> determining whether
>    or not a message is an S/MIME message. A message is considered an
>    S/MIME message if it matches any below.
>
>    The file suffix in the table below comes from the "name"
> parameter in
>    the content-type header, or the "filename" parameter on
> the content-
>    disposition header. These parameters that give the file suffix are
>    not listed below as part of the parameter section.
>
>    MIME type:   application/pkcs7-mime
>    parameters:  any
>    file suffix: any
>
>    MIME type:   multipart/signed
>    parameters:  protocol="application/pkcs7-signature"
>    file suffix: any
>
>    MIME type:   application/octet-stream
>    parameters:  any
>    file suffix: p7m, p7s, p7c
>
>    This clearly states that a MIME type
> application/octet-stream with a file
> suffix of e.g. p7m is a valid S/MIME message.
>
>    It seems that not only we but also the vendors are confused by this
> apparent
> contradiction. Microsoft's Outlook adheres to section 3.2.1
> and does not
> recognize S/MIME messages with MIME type
> application/octet-stream and file
> suffix p7m while Netscape's Messenger does.
>
>    Can anybody shed some light on this? Maybe it would be a
> good idea to
> clarify
> the standard on this topic.
>
>
>    Regards,
>
>    Frank Schwab
>    TLC GmbH
>
>
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f63FV2x19621 for ietf-smime-bks; Tue, 3 Jul 2001 08:31:02 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f63FV1m19616 for <[e-mail]>; Tue, 3 Jul 2001 08:31:01 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id <KZJ98P3K>; Tue, 3 Jul 2001 11:31:16 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "Ietf-Smime (E-mail)" <[e-mail]>
Subject: RE: Jim's Comments: draft-ietf-smime-cmsalg-00
Date: Tue, 3 Jul 2001 11:31:14 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

I have the following comments regarding Jim Schaad's 7 June comments to the
draft-ietf-smime-cmsalg-00.txt Internet-Draft.  My comments [JP] are
numbered consistently with Jim's original message.  I omitted Jim's comments
with which I agree.   
  
2) Section 2.1:  Jim stated: "I believe that the MUST and SHOULD statements
in this paragraph are in conflict.  ie. MUST encode as and SHOULD generate
with.  These should be resolved as MUST in both locations."

[JP: I disagree with Jim that the MUST and SHOULD statements are in
conflict.  The paragraph states: "If present, the parameters field MUST
contain an ASN.1 NULL."  In my opinion, it is clear that the MUST
requirement does not apply if the parameters field is absent.  I also
disagree with Jim's recommendation to change the spec to state that
implementations MUST populate the algorithmIdentifier parameters field with
an ASN.1 NULL.  I believe that the text should remain unchanged.]


6) Section 3.2:  Jim stated "Boy we really messed this one up.  Section 3.2
should occur
as two different sections one for RSAwithMD5 and one for RSAwithSHA1.  I
will never understand how all of us missed this one.

The OIDs for this should be:
       sha1withRSAEncryption (1 2 840 113549 1 1 5)
or
#define szOID_OIWSEC_sha1RSASign "1.3.14.3.2.29"

       md5withRSAEncryption (1 2 840 113549 1 1 4)"

[JP: I disagree with Jim's statements.  To support backwards compatibility
with S/MIME v2 implementations that only recognize the rsaEncryption OID, we
specified that the rsaEncryption OID must be included in the signedData
signerInfo signatureAlgorithm field.  We decided not to specify the use of
the sha-1WithRSAEncryption, md2withRSAEncryption, or md5withRSAEncryption
OIDs in the signerInfo signatureAlgorithm field.]


7a) Section 4.1, para 2:  Jim stated: "There is a different in language
here.
-   if ContentEncryptionAlg MUST KEK Alg.
-   SHOULD 3DES KEK
-   SHOULD RC2 KEK
-   MUST 3DES KEK on 3DES Content
-   MUST RC2 KEK on RC2 content.

Let me make a new stab at this:

Keep para 1 from section 4.1.

The following is the rest of section 4.1:

A key agreement algorithm consists of the following items:
1.  A shared secrect computation that takes the originator and receipient
keys and computes a shared secret.
2.  A symmetric key derivation algorithm that uses the shared secret to
compute a symmetric key.
3.  A key-wrap algorithm which uses the symmetric key generated by 2 to
encryption the CEK producing the value encded in the CMS kari structure."

[JP: I do not object to the addition of Jim's new text (bullets 1-3 above),
but I do object to the deletion of the remainder of section 4.1 (i.e.
paragraphs 2-7).  I believe that text is necessary to explain the use of the
KeyAgreeRecipientInfo fields.]


7b) Jim stated: 
"4.1.1  X9.42 Ephemeral-Static Diffie-Hellman

The shared-secret computation and symmetric key derivation algorithms for
Ephemeral-Static Diffie-Hellman key agreement are defined in RFC 2631
   [DH-X9.42].  E-S D-H uses the KEK algorithms defined in section 4.3 for
the key wrap algorithm.  ES DH MUST support the 3DES KEK for key wrapping.
ES DH SHOULD support RC2 KEK for key wrapping."

[JP: I agree with the intent of Jim's comments.  Recommend that the
following sentences should replace the first sentence in section 4.1.1, para
1:

"The shared-secret computation and symmetric key derivation algorithms for
Ephemeral-Static (E-S) Diffie-Hellman (D-H) key agreement are defined in RFC
2631 [DH-X9.42].  The key wrap algorithms defined in section 4.3 of this
document are used in conjunction with E-S D-H.  CMS implementations that
include E-S D-H MUST support the use of Triple-DES key-encryption keys to
wrap Triple-DES content-encryption keys and SHOULD support the use of RC2
key-encryption keys to wrap RC2 content-encryption keys."]

  
7c) Jim stated: "keyEncryptionAlgorithm MUST be the id-alg-ESDH algorithm
<< Changed
      identifier.  The algorithm identifier parameter field for id-alg-
      ESDH is KeyWrapAlgorithm, and this parameter MUST be present.  The
<< Changed
      KeyWrapAlgorithm denotes the key wrap algorithm used
<< Changed
      to encrypt the content-encryption key with the pairwise key-
      encryption key generated using the X9.42 Ephemeral-Static Diffie-
      Hellman key agreement algorithm.  The document uses the KEK algorithms
defined in section 4.3 as the key wrap algorithms.  The KEK algorithm used
is defined in the KeyWrapAlgorithm parameter."

[JP: I agree with Jim's comments, except that I believe that the last
sentence should be deleted because it is redundant with the third sentence.
Also, I recommend the following wordsmithing of the fourth sentence:  "The
document uses the key wrap algorithms defined in section 4.3.".]  


7d) Jim stated: "New requirement: When deriving a Triple-DES key, a three
key Triple-DES key
MUST be derived.  When deriving a Triple-DES key wrap key, the parity on
each of the three sub-keys MUST be correctly generated after the key
derivation process is complete."

[JP: Agree.]


12) Section 7:  Jim stated: "I do not believe this section needs any MUSTS
for inclusion
of algorithms.  That is covered in section 4."

[JP: Rather than delete the first sentence of Section 7, I believe that it
should be changed to: "CMS implementations that support the
previously-distributed symmetric KEK or key agreement key management
techniques MUST include encryption of a Triple-DES content-encryption key
with a Triple-DES key-encryption key using the algorithm specified in
Sections 7.2 and 7.3."]

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f62M8Mo20883 for ietf-smime-bks; Mon, 2 Jul 2001 15:08:22 -0700 (PDT)
Received: from [165.227.249.20] (ip20.proper.com [165.227.249.20]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f62M8Jm20879; Mon, 2 Jul 2001 15:08:19 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100359b766a0a7d1ed@[165.227.249.20]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Mon, 2 Jul 2001 15:08:21 -0700
To: "Pawling, John" <[e-mail]>, "SMIME WG (E-mail)" <[e-mail]>
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: cmsalg-00 Comments
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 4:44 PM -0400 7/2/01, Pawling, John wrote:
>2) Section 1, para 2: Please change "implantations" to "implementations".

ROTFL. On the other hand, this indicates that almost no one (myself 
included) has read this document carefully.


--Paul Hoffman, Director
--Internet Mail Consortium


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f62L2lC16856 for ietf-smime-bks; Mon, 2 Jul 2001 14:02:47 -0700 (PDT)
Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f62L2jm16850 for <[e-mail]>; Mon, 2 Jul 2001 14:02:45 -0700 (PDT)
Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id RAA18192 for <[e-mail]>; Mon, 2 Jul 2001 17:02:46 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Mon, 02 Jul 2001 17:02:24 -0400
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: Draft NIST S/MIME Profile available
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

FYI,

I have attached below the announcement for a recently released NIST draft 
document concerning S/MIME V3.  The document is intended to define an 
appropriate subset of the S/MIME standards for broad application in the 
U.S. Federal Government.  NIST will be supporting this document through the 
development of an automated conformance testing tool.  We hope the 
deployment of this tool will ease the development of conformant S/MIME V3 
clients!

We are very interested in comments from both developers and the user 
community.  Please take the time to review the draft profile and NIST's 
plans for the automated testing facility.  We would appreciate comments on 
the profile by 17 August 2001.  Please send  comments to Mike Chernick 
(NIST's S/MIME project leader) at <[e-mail]>.

BTW, Mike will be presenting an overview of this project in the S/MIME WG 
during the London IETF meeting.  Both Mike and I will be there all week, 
and will be available to discuss this project.

Thanks!

Tim Polk


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

The U.S. National Institute of Standards and Technology (NIST) has recently 
released a draft S/MIME V3 Client Profile. This profile was produced as 
guidance in the development and procurement of commercial-off-the-shelf 
(COTS) S/MIME-compliant products. This profile document identifies 
requirements for a secure and interoperable S/MIME V3 client 
implementation. The profile cites requirements for sending and receiving 
both signed and encrypted messages, as well as requirements for signed 
receipt processing.

Although the S/MIME specifications were designed to promote interoperable 
secure electronic mail, implementations may support different optional 
services and the specifications may unintentionally allow multiple 
interpretations. As a result, different implementations of S/MIME may not 
be fully interoperable or provide the desired level of security. 
Conformance to this proposed profile will help to assure that S/MIME 
implementations will be able to interoperate and provide reasonable 
security assurance to users.

The Draft Profile is available (in PDF format) for public comment at: 
http://csrc.ncsl.nist.gov/pki/smime/draft_SMIMEProfile.pdf

Comments are requested by 17 August 2001 and should be sent to 
[e-mail].

NIST is developing tests and testing tools to determine the level of 
conformance of an S/MIME V3 client implementation with this profile. It is 
planned that within the next several months, NIST will have a remote 
testing facility on-line which will allow S/MIME V3 messages to be sent to 
the NIST test site for processing to determine if the remotely generated 
messages conform to the profile. In addition, messages may be sent to the 
test site to cause the NIST site to emit S/MIME V3 messages so that a 
remote system may receive S/MIME V3 messages, and verify that remote system 
can process the messages correctly.

Further information on the NIST S/MIME Program may be obtained at
http://csrc.ncsl.nist.gov/pki/smime/welcome.htm or by contacting Michael 
Chernick  at <[e-mail]>.







Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f62KiSS15343 for ietf-smime-bks; Mon, 2 Jul 2001 13:44:28 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f62KiRm15338 for <[e-mail]>; Mon, 2 Jul 2001 13:44:27 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id <KZJ98LKS>; Mon, 2 Jul 2001 16:44:43 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "SMIME WG (E-mail)" <[e-mail]>
Subject: cmsalg-00 Comments
Date: Mon, 2 Jul 2001 16:44:35 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

In my opinion, Russ has done an outstanding job of producing the
draft-ietf-smime-cmsalg-00.txt Internet-Draft.  I agree with the vast
majority of the document.  I have comments as follows:

1) General comment: Since there are multiple techniques for using the RSA
algorithm, please replace all occurrences of "RSA" with "RSA (PKCS #1 v1.5)"
as appropriate.

2) Section 1, para 2: Please change "implantations" to "implementations".

3) Section 1, para 3:  Please change "Algorithm are be identified" to
"Algorithms can be identified".

4) Section 1, para 3: Please change:
OLD: "The algorithm identifiers for each algorithm are specified"  
NEW: "The algorithm identifier for each algorithm is specified" 

5) Table 1, title: Please change "Implantation" to "Implementation".

6) Table 1, Symmetric KEK Wrap note:  Please add this note to immediately
follow the table: "Note 2: Only those CMS implementations that support the
previously-distributed symmetric KEK or key agreement key management
techniques MUST implement the Triple-DES Key Wrap algorithm."  An alternate
solution is to change the table such that "Triple-DES Key Wrap" is a SHOULD
implement requirement.

7) Table 1: I believe that a row should be added to represent key derivation
algorithms since the password-based key management technique is documented
in the rfc2630bis-01 I-D.  The draft-ietf-smime-password-03.txt I-D includes
the PBKDF2 [RFC2898] key derivation algorithm as a MUST implement
requirement, so I recommend that the following row should be added to Table
1:

 Algorithm Type            MUST implement         SHOULD implement
 -----------------------------------------------------------------
 Key Derivation            PBKDF2 [RFC2898]       --

8) Table 1. Key Derivation Note: Please add this note to immediately follow
the table: "Note 3: Only those CMS implementations that support the
password-based key management technique MUST implement the PBKDF2 [RFC2898]
key derivation algorithm."  An alternate solution would be to change the
table to include the PBKDF2 [RFC2898] key derivation algorithm as a SHOULD
implement requirement, but then it would not be consistent with the
draft-ietf-smime-password-03.txt I-D.  

9) Table 1, Message Authentication note:  Please add this note to
immediately follow the table: "Note 3: Only those CMS implementations that
support the AuthenticatedData content-type MUST implement the HMAC with
SHA-1 algorithm."

10) Section 2, intro, 3rd para: Please replace: 

OLD: "Digest values are located in the DigestedData digest field, and digest
values are located in the Message Digest authenticated attribute."

NEW: "Digest values are located in the DigestedData digest field and Message
Digest attribute."


11) Section 4, intro: Please change as follows:

OLD: "CMS accommodates three general key management techniques: key
agreement, key transport, and previously distributed symmetric
key-encryption keys."

NEW: "CMS accommodates the following general key management techniques: key
agreement, key transport, previously distributed symmetric key-encryption
keys, and passwords."


12) Section 4.1, 2nd para: Please change the following:

OLD: "CMS implementations MUST include Triple-DES wrapping of Triple-DES
content-encryption keys and RC2 wrapping of RC2 content-encryption keys."  

NEW: "CMS implementations that support the key agreement key management
technique MUST implement Triple-DES wrapping of Triple-DES
content-encryption keys and SHOULD implement RC2 wrapping of RC2
content-encryption keys." 


13) Section 4.3, 1rst para, 1rst sent: Please change MUST to SHOULD in the
following sentence: "CMS implementations MUST support symmetric
key-encryption key management."  I don't believe that the S/MIME working
group has ever agreed that the previously-distributed symmetric KEK key
management technique is a MUST implement requirement.

14) Section 4.3, 1rst para, 2nd sent: Please change the following:

OLD: "CMS implementations MUST include Triple-DES key-encryption keys
wrapping Triple-DES content-encryption keys." 

NEW: "CMS implementations that support the previously-distributed symmetric
KEK or key agreement key management techniques MUST include Triple-DES
key-encryption keys wrapping Triple-DES content-encryption keys."  


15) Section 4.4, Please add: 

"4.4 Key Derivation Algorithms

Key derivation algorithms are used to convert a password into a KEK as part
of the password-based key management technique.  CMS implementations that
support the password-based key management technique MUST implement the
PBKDF2 [RFC2898] key derivation algorithm.  The
KeyDerivationAlgorithmIdentifer identifies the key-derivation algorithm, and
any associated parameters, used to derive the KEK from the user-supplied
password.  The object identifier for the PBKDF2 [RFC2898] key derivation
algorithm is TBD."


16) Section 5, 1rst para: Please change "MS" to "CMS" in the following: "MS
implementations SHOULD support Two-Key Triple-DES in CBC mode."

17) Section 7, 1rst paragraph: Please change the following:

OLD: "CMS implementations MUST include encryption of a Triple-DES
content-encryption key with a Triple-DES key-encryption key using the
algorithm specified in Sections 7.2 and 7.3."

NEW: "CMS implementations that support the previously-distributed symmetric
KEK or key agreement key management techniques MUST include encryption of a
Triple-DES content-encryption key with a Triple-DES key-encryption key using
the algorithm specified in Sections 7.2 and 7.3."


18) Section 7.2, bullet 2: Please change "Section 12.6.1" to "Section 7.1".

19) Section 7.3, bullet 7: Please change "Section 12.6.1" to "Section 7.1".

20) Section 7.4, bullet 4: Please change "Section 12.6.1" to "Section 7.1".

21) Section 7.5, bullet 7: Please change "Section 12.6.1" to "Section 7.1".

22) Security Considerations: Please delete the countersignature section
because it is much more applicable to the rfc2630bis-01 I-D. 

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================



Received: by above.proper.com (8.11.3/8.11.3) id f62EcK119719 for ietf-smime-bks; Mon, 2 Jul 2001 07:38:20 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f62EcIm19715 for <[e-mail]>; Mon, 2 Jul 2001 07:38:19 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id <KZJ982DB>; Mon, 2 Jul 2001 10:38:33 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "SMIME WG (E-mail)" <[e-mail]>
Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01
Date: Mon, 2 Jul 2001 10:38:31 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

I change my proposal for the Section 6.1, EnvelopedData version setting
algorithm to:

    IF ((originatorInfo is present) AND 
	 (any version 2 attribute certificates are present)) OR
	 (any RecipientInfo structures are pwri CHOICE) OR
 	 (any RecipientInfo structures are ori CHOICE)
    THEN version is 3
    ELSE
	 IF (originatorInfo is present) OR
	    (unprotectedAttrs is present) OR
	    (any RecipientInfo structures are a version other than 0)
       THEN version is 2
       ELSE version is 0

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================



-----Original Message-----
From: Pawling, John [mailto:[e-mail]]
Sent: Friday, June 29, 2001 2:45 PM
To: SMIME WG (E-mail)
Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01



Russ,

Thank you for your thoughtful responses to my comments.  I agree with all of
your responses and counter-proposals except for the following:
  
I stated: "7) Section 6.2.4, recommend changing PasswordRecipientInfo
version value to 1.  This would cause the EnvelopedData version number to be
set to 2 if the PasswordRecipientInfo was present.  This would assist with
debugging and error reporting."

You responded; "Please raise this on a separate thread.  This is a comment
on draft-ietf-smime-password, not CMS.  Right now, draft-ietf-smime-password
says to use version 0.

We can change the version setting algorithm...."


A few months ago, I proposed that the PasswordRecipientInfo version value
should be changed in draft-ietf-smime-password.  My proposal met with
resistance.  I propose that the Section 6.1, EnvelopedData version setting
algorithm should be changed as follows:

   [*** NEW ***] version is the syntax version number.  The
   appropriate value depends on originatorInfo, RecipientInfo, and
   unprotectedAttrs.  The version MUST be assigned as follows:

   IF (originatorInfo is present) OR (unprotectedAttrs is present)
     THEN
        IF (any version 2 attribute certificates are present)
        THEN version is 3
        ELSE version is 2
     ELSE
        IF (any RecipientInfo structures are a version other than 0) OR
           (any RecipientInfo structures are pwri CHOICE) 
        THEN version is 2
        ELSE version is 0

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================