YOUR EMAIL.... HAS MAKE YOU A WINNER.......

[LOTTERY BOARD <[e-mail]>]

11 G Lower Dorset Street,
Dublin 1, Ireland.
P O Box 1010.

FINAL NOTIFICATION

We are pleased to inform you today 15th April, 2007 of the result of 
the winners of the IRISH NATIONAL LOTTERY ONLINE PROMO PROGRAMME, held on 

the Saturday 14th April  2007, ticketnumber:56475600545 188 with Serial number 

5368/02 this are your lucky numbers:09, 12, 22, 27, 31,43, Bonus 19.

You have therefore been approved for a lump sum pay out of £1,350,000(One 

million, three hundred and fifty thousand, pounds sterling) in cash credited to file 

KTU/9023118308/03.

To file for your claim, please contact our fiduciary agent:

Mr. Edward Brown
Email: [e-mail]
Phone: [phone]
Fax:  [phone]

Provide him with the information below:

1.Full Name:
2.Full Address:
3.Marital Status:
4.Occupation:
5.Age:
6.Sex:
7.Nationality:
8.Country Of Residence:
9.Telephone Number:

Congratulations once more from all members and staff of this program.

Sincerely, 
Sir.kolyn parkins 
Online coordinator for THE IRISH LOTTERY
Sweepstakes International Program.





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3UHGOYt097913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Apr 2007 10:16:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3UHGOCJ097912; Mon, 30 Apr 2007 10:16:24 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3UHG3nl097864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Mon, 30 Apr 2007 10:16:24 -0700 (MST) (envelope-from [e-mail])
Received: from GALATIONS (unknown [207.202.179.27]) by smtp3.pacifier.net (Postfix) with ESMTP id E4D056D9F0; Mon, 30 Apr 2007 10:15:46 -0700 (PDT)
From: "Jim Schaad" <[e-mail]>
To: "'Peter Sylvester'" <[e-mail]>
Cc: "'pgut001'" <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <04c801c78499$837eb390$8a7c1ab0$@com> <[e-mail]> <059701c7877c$7363c000$5a2b4000$@com> <[e-mail]> <000801c78923$7b365f10$71a31d30$@com> <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
Date: Mon, 30 Apr 2007 10:15:46 -0700
Message-ID: <022501c78b4b$3b1330f0$b13992d0$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AceLSp63nDA+GJxjSUyQ3Vo3jawOjgAADJgw
Content-Language: en-us
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,


> -----Original Message-----
> From: Peter Sylvester [mailto:[e-mail]]
> Sent: Monday, April 30, 2007 10:09 AM
> To: Jim Schaad
> Cc: 'pgut001'; [e-mail]; [e-mail]
> Subject: Re: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
> 
> Jim Schaad wrote:
> > Peters,
> >
> > I think that you are off base on this.  If you are going to make an
> > attribute that is dependent on the body you WANT the attributes to
> come
> > before the body.  If this is not the case, the authenticator does not
> know
> > that the attribute validation needs to be setup until the body has
> been
> > completely processed and it cannot be placed in stream anymore.  This
> does
> > make things harder for the encoder, but the authentication operation
> can be
> > assumed to occur more often than the encoding operation.
> >
> The messageDigest is an authenticated attribute that cannot be set
> before the data. You
> may need some information in order to start the compution, that's why
> there are the
> hash algorithms indicated before.

If you look at the structure, there are no hash indicators before-hand.  In
fact the document explicitly says don't put in a messageDigest attribute.

> 
> But the global application context or document context knows what you
> have to do,
> at least the creator cannot place such an attribute before the data.
> > If this swap is done for reasons of consistency I can agree with
> this.  If
> > this is done to satisfy the need for the argument based on the
> content of
> > the body I oppose swapping the body and the authenticated attributes.
> >
> How would you then insert such the attribute on the fly?

You don't.  What I said was that it is more important to make sure that
things are good for the validator and not for the encoder.  The encoder
knows what is going to be happening and can live with not streaming.  The
validator MUST know in advance what is going to happen in order to be able
to set things up correctly.

Jim

> 
> regards
> Peter



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3UHBbrR097266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Apr 2007 10:11:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3UHBbCO097265; Mon, 30 Apr 2007 10:11:37 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ganymede.on-x.com (ganymede.on-x.com [194.51.68.3]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3UHBaQ4097259 for <[e-mail]>; Mon, 30 Apr 2007 10:11:36 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (ganymede [127.0.0.1]) by ganymede.on-x.com (Postfix) with ESMTP id C76FA13; Mon, 30 Apr 2007 19:11:35 +0200 (CEST)
Received: from ganymede.on-x.com ([127.0.0.1]) by localhost (ganymede.on-x.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11349-08; Mon, 30 Apr 2007 19:11:33 +0200 (CEST)
Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id 551D1F; Mon, 30 Apr 2007 19:11:33 +0200 (CEST)
Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2007043019113224:228538 ; Mon, 30 Apr 2007 19:11:32 +0200 
Message-ID: <[e-mail]>
Date: Mon, 30 Apr 2007 19:09:21 +0200
From: Peter Sylvester <[e-mail]>
User-Agent: Thunderbird 1.5.0.9 (X11/20061206)
MIME-Version: 1.0
To: Jim Schaad <[e-mail]>
Cc: "'pgut001'" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
References: <04c801c78499$837eb390$8a7c1ab0$@com> <[e-mail]> <059701c7877c$7363c000$5a2b4000$@com> <[e-mail]> <000801c78923$7b365f10$71a31d30$@com>
In-Reply-To: <000801c78923$7b365f10$71a31d30$@com>
X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11  |July 24, 2002) at 04/30/2007 07:11:32 PM, Serialize by Router on vinea/ON-X(Release 5.0.11  |July 24, 2002) at 04/30/2007 07:11:32 PM, Serialize complete at 04/30/2007 07:11:32 PM
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020408000109020108000301"
X-Virus-Scanned: by amavisd-new at on-x.com
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 is a cryptographically signed message in MIME format.

--------------ms020408000109020108000301
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit

Jim Schaad wrote:
> Peters,
>
> I think that you are off base on this.  If you are going to make an
> attribute that is dependent on the body you WANT the attributes to come
> before the body.  If this is not the case, the authenticator does not know
> that the attribute validation needs to be setup until the body has been
> completely processed and it cannot be placed in stream anymore.  This does
> make things harder for the encoder, but the authentication operation can be
> assumed to occur more often than the encoding operation.
>   
The messageDigest is an authenticated attribute that cannot be set 
before the data. You
may need some information in order to start the compution, that's why 
there are the
hash algorithms indicated before.

But the global application context or document context knows what you 
have to do,
at least the creator cannot place such an attribute before the data.
> If this swap is done for reasons of consistency I can agree with this.  If
> this is done to satisfy the need for the argument based on the content of
> the body I oppose swapping the body and the authenticated attributes.
>   
How would you then insert such the attribute on the fly?

regards
Peter

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC
BHIwggLfoAMCAQICBgqvijKA3jANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G
A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs
UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNzAzMjYxMDM3MDNaFw0wOTA2MDMxMDM3MDNaMHAx
CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ
S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu
ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPB7ZSfmYsUuVIV0W2izxb1Zyvr6ZJ
IjPiqRMs77dbEQhQ6FZhhUSuABxxc8NjZvyPMRo0uuT0iVpRDktb0fWPTx3m9qTfdqrhWg2c
IOBKNbNQr8NogDJvG1AxRx4q9SXKZCVpZCoHu3fz2Rfji1kL7l597+7qBEsFd9IyvRaexQID
AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5
MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT
VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD
VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F
ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSZjq81LuJmsiiu1Yt/ezwCiUQSQTAfBgNV
HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA
A4IBfAAUq5MJ3gXhdKDpOm0ascDE9e1iMo0RQ24ujkc9IrFXhAJNS+3eNwcJEieU2vgZTsGb
zKeBZom1zVOFoh73VIRP6T08j4dDlndpDYZbxD20KzFt9zX6gV8IgR2zkkZXLQRbLyW16kw8
oFe3s//p1csCkCPAlZv1rZQYR5Psm0A1aiOiuSHhWUmgfAJxmIgfbmKtS3WpsUZVBuLQpThN
rWjLRAqJKYA++++qqo3ujqAAzJLe+MHrX5dai7+n6WBfV4qo1uDArR7XbmgVpV/EdPA75XRi
XEedLgbFDawJ9nAMN6WfL/NG6GZkEa7mZ7sH/gG34y21nq4w4mAAxn9wz7mDKMsEbJMZ5VlJ
TOp0g6TdYqGjNoc/rQg7pqjcRChVitwd1Rl8O31+bIdNSpv4UReNMDcffRQrt+pF1FxR4q6q
M9YLJU8NThx/89Mf/WF7fzrgVlsNJ78D9nJu0EhKes/9EX2qpIcHUfk/izOj8lCc1ksFgXpd
UEchE0DcMIIEcjCCAt+gAwIBAgIGCq+KMoDeMA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT
AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV
BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA3MDMyNjEwMzcwM1oXDTA5MDYwMzEw
MzcwM1owcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp
Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA
ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8HtlJ+ZixS5UhXRbaL
PFvVnK+vpkkiM+KpEyzvt1sRCFDoVmGFRK4AHHFzw2Nm/I8xGjS65PSJWlEOS1vR9Y9PHeb2
pN92quFaDZwg4Eo1s1Cvw2iAMm8bUDFHHir1JcpkJWlkKge7d/PZF+OLWQvuXn3v7uoESwV3
0jK9Fp7FAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl
Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl
ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF
BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F
ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJmOrzUu4mayKK7Vi397PAKJ
RBJBMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI
hvcNAQEFBQADggF8ABSrkwneBeF0oOk6bRqxwMT17WIyjRFDbi6ORz0isVeEAk1L7d43BwkS
J5Ta+BlOwZvMp4FmibXNU4WiHvdUhE/pPTyPh0OWd2kNhlvEPbQrMW33NfqBXwiBHbOSRlct
BFsvJbXqTDygV7ez/+nVywKQI8CVm/WtlBhHk+ybQDVqI6K5IeFZSaB8AnGYiB9uYq1Ldamx
RlUG4tClOE2taMtECokpgD7776qqje6OoADMkt74wetfl1qLv6fpYF9XiqjW4MCtHtduaBWl
X8R08DvldGJcR50uBsUNrAn2cAw3pZ8v80boZmQRruZnuwf+AbfjLbWerjDiYADGf3DPuYMo
ywRskxnlWUlM6nSDpN1ioaM2hz+tCDumqNxEKFWK3B3VGXw7fX5sh01Km/hRF40wNx99FCu3
6kXUXFHirqoz1gslTw1OHH/z0x/9YXt/OuBWWw0nvwP2cm7QSEp6z/0RfaqkhwdR+T+LM6Py
UJzWSwWBel1QRyETQNwwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL
MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL
STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0
MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj
ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI
hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M
ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe
1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt
qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd
UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH
pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS
cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB
CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0
dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C
AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV
HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3
UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy
4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz
QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u
US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj
PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq
Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf
Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y
rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6
PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL
d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18
k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg
d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD
VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ
S0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwNDMwMTcwOTIxWjAjBgkqhkiG9w0B
CQQxFgQUtA3MY/87vWtpjy/LVzfeu23pe3YwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D
BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC
ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY
MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy
c0dFTgIGCq+KMoDeMHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE
ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ
IEVkZWxXZWIgUGVyc0dFTgIGCq+KMoDeMA0GCSqGSIb3DQEBAQUABIGAua13GsQD4dMjKKtG
5r95Thv34+WlMvyt/cwaMUKoX0NxZF4D6FrE+fXNF6J+fY6ps2XbqVl0CDmSPUBLJDb7LrLI
H0DfkAMuVbXJcTngh9kew+G26PuzMMfB4lTZtkXcVUwef6tEYcoE5YzADTTwfdYA+qY4o2IX
8fDPUS3yoTUAAAAAAAA=
--------------ms020408000109020108000301--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3U19V1u058549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Apr 2007 18:09:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3U19V9h058546; Sun, 29 Apr 2007 18:09:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3U199qe058464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Sun, 29 Apr 2007 18:09:30 -0700 (MST) (envelope-from [e-mail])
Received: from GALATIONS (unknown [207.202.179.27]) by smtp1.pacifier.net (Postfix) with ESMTP id F07A26F1EA; Sun, 29 Apr 2007 18:05:55 -0700 (PDT)
From: "Jim Schaad" <[e-mail]>
To: "'Russ Housley'" <[e-mail]>
Cc: "'Ietf-Smime'" <[e-mail]>
References: <04cc01c7849b$77e71a20$67b54e60$@com> <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: RE: draft-ietf-smime-cms-auth and not streaming for decode
Date: Sun, 29 Apr 2007 18:05:55 -0700
Message-ID: <017601c78ac3$b52dec50$1f89c4f0$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AceF3POgdYx4k8wYSCWm4/UxCQVP0AE2M5Gw
Content-Language: en-us
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 spent time this weekend carefully reading the two drafts looking at this
issue and what it does or does not mean.

1.  Neither of the documents currently under consideration make any
statements dealing with the issue.

2.  The text in RFC 3610 can be read somewhat ambiguously.  The requirement
is placed on the Recipient not to release the until the content has been
validated.

3.  The text in RFC 3610 does not state if there is a security flaw with
releasing the content or if it is just a desirable property of the code.  

4.  Unless there is a security issue with allowing the content to be passed
on, I think that CMS implementation should threat this the same way as an
invalid signature.  The user application has the option of how to treat the
failure of validation on the decryption operation.  My expectation would be
that this is to fail in some way w/o displaying the content but this cannot
be assured.  This means no changes for either of the current documents.

5.  I would like RFC 3610 to be amended to state if there is a security
issue in revealing the contents in the event of a validation failure.  The
same thing should also be done for GCM.



I also found the following issue that should probably be addressed:

In aes-ccm-and-gcm-01, there are a couple of things about section 2.

1.  The heading uses "Automatic Key", but the text uses ""automated key" -
should these be the same?

2.  The document states that new key management systems need to check
against the requirements of the automated key management system, but there
is no list of what these requirements are or a pointer to the requirements.
I think this needs to be inserted.

Jim


> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]] On Behalf Of Russ Housley
> Sent: Monday, April 23, 2007 12:05 PM
> To: Jim Schaad
> Cc: Ietf-Smime
> Subject: Re: draft-ietf-smime-cms-auth and not streaming for decode
> 
> 
> That's why limited block sizes are very nice, but CMS does not have a
> maximum content size. The intent is for the overall hardware/software
> solution to only reveal plaintext after it is
> authenticated.  However, I recognize   a completely generic option
> with no limitations is desired.
> 
> Both AES-CCM and AES-GCM have requirements that require the integrity
> check to be performed before the plaintext is released.
> 
> Russ
> 
> 
> At 01:02 AM 4/22/2007, Jim Schaad wrote:
> >As the document is currently written, it is basically impossible to do
> >streaming on a decode operation due to the following statement.
> >
> >The recipient MUST verify the integrity of the received content
> >    before releasing any information, especially the plaintext of the
> >    content.  If the integrity verification fails, the receiver MUST
> >    destroy all of the plaintext of the content.
> >
> >My first reading of this assumed that the low-level decryption routine
> >should be the one to take care of this statement.  But the real
> question is
> >what is meant by "recipient".
> >
> >If one makes the statement that the low level decryption code is
> responsible
> >for this, then making a hardware device to do the decryption becomes
> >difficult unless it sets limits on the length of the data that can be
> >decrypted. (The hardware would be required to buffer the contents on
> the
> >chip until it had finished doing the validation operation.)
> >
> >If one makes the statement that the CMS code is responsible for this,
> code
> >could not be said to be compliant to RFC 3610 since it has a similar
> >statement in that document.
> >
> >I have to say that if I were to implement this code I would be very
> tempted
> >to go ahead and do the decryption, stream the data out and return an
> error
> >code of validation failed much as is currently done for the current
> >EncryptedData and EnvelopedData structures.
> >
> >Why should this document handle this differently that a padding
> failure for
> >those structures?  I propose removing that restriction.
> >
> >Jim




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3TEn6xU069621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Apr 2007 07:49:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3TEn6Q5069620; Sun, 29 Apr 2007 07:49:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l3TEn5rn069614 for <[e-mail]>; Sun, 29 Apr 2007 07:49:06 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 29217 invoked by uid 0); 29 Apr 2007 14:49:01 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.66.14.186) by woodstock.binhost.com with SMTP; 29 Apr 2007 14:49:01 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Sun, 29 Apr 2007 10:49:01 -0400
To: "Jim Schaad" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
Cc: <[e-mail]>
In-Reply-To: <000801c78923$7b365f10$71a31d30$@com>
References: <04c801c78499$837eb390$8a7c1ab0$@com> <[e-mail]> <059701c7877c$7363c000$5a2b4000$@com> <[e-mail]> <000801c78923$7b365f10$71a31d30$@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>

Thanks for taking a close look.  In the most recent version, I 
swapped the order.  I seemed to be the only one that thought they 
should come first.  I'm pleased to swap them back if others have an opinion.

Chairs:  Can we have a WG Last Call, and ask this question explicitly 
in the call?

Russ

At 07:26 PM 4/27/2007, Jim Schaad wrote:
>Peters,
>
>I think that you are off base on this.  If you are going to make an
>attribute that is dependent on the body you WANT the attributes to come
>before the body.  If this is not the case, the authenticator does not know
>that the attribute validation needs to be setup until the body has been
>completely processed and it cannot be placed in stream anymore.  This does
>make things harder for the encoder, but the authentication operation can be
>assumed to occur more often than the encoding operation.
>
>If this swap is done for reasons of consistency I can agree with this.  If
>this is done to satisfy the need for the argument based on the content of
>the body I oppose swapping the body and the authenticated attributes.
>
>Jim
>
>PS I apologize Russ, I should have spotted this sooner.  I knew that I was
>having a problem with the argument but I could not nail it down.
>
>JLS
>
> > -----Original Message-----
> > From: [e-mail] [mailto:owner-ietf-
> > [e-mail]] On Behalf Of Peter Sylvester
> > Sent: Thursday, April 26, 2007 2:12 AM
> > To: Jim Schaad
> > Cc: 'pgut001'; [e-mail]; [e-mail]
> > Subject: Re: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
> >
> > Jim Schaad wrote:
> > > Yes I agree that would be a problem,  can you suggest an attribute
> > which
> > > might need to be placed there that would have this attribute?
> > Currently the
> > > only one I could think of is a digest which is not needed as this is
> > dealt
> > > with by the encryption algorithm.
> > >
> > A time stamp, or something like a the 3 level wrapper of ESS to be
> > extracted from
> > some data that are structured, i.e. you would have an appliance that
> > streams
> > end encrypts and adds a resume.
> > > I don't need a real one, but I want to have some inkling that this
> > MIGHT be
> > > a real problem before trying to solve it.
> > >
> > See above. I am not sure but I always had the impression that the
> > possibility of streaming
> > is one of the fundamental features. If now we have an algorithm that
> > does allow this
> > in a reasonable, i.e. for example by splitting the message into chained
> > chunks that
> > can be authenticated (almost) on the fly and do not require an
> > undeterminable
> > size limit. requiring several mega of storage is not acceptable for
> > processing smime
> > message is not acceptable IMO.
> >
> > > Jim
> > >
> > >
> > >
> > >> -----Original Message-----
> > >> From: pgut001 [mailto:[e-mail]]
> > >> Sent: Wednesday, April 25, 2007 1:55 PM
> > >> To: [e-mail]; [e-mail];
> > >> [e-mail]
> > >> Cc: [e-mail]
> > >> Subject: RE: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
> > >>
> > >> "Jim Schaad" <[e-mail]> writes:
> > >>
> > >>
> > >>> I am having a problem seeing why having the attributes first causes
> > a
> > >>> problem for algorithms that want them second.  All that is needed
> > is
> > >>>
> > >> that
> > >>
> > >>> the encryption wrapper for the code understand that the attributes
> > are
> > >>>
> > >> going
> > >>
> > >>> to come in first and hold onto them until later.  This is assuming
> > >>>
> > >> that the
> > >>
> > >>> encryption wrapper understands the difference between the body and
> > the
> > >>> attributes.
> > >>>
> > >> What if the attributes depend on the data being processed (as Peter
> > >> Sylvester
> > >> pointed out)?  By putting them first, you can't emit the first byte
> > of
> > >> data
> > >> until you've processed every other byte of data.  This is why
> > current
> > >> CMS
> > >> practice puts the attributes last.
> > >>
> > >> Peter.
> > >>
> > >
> > >
> > >



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RNQsKW008014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Apr 2007 16:26:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3RNQsUj008013; Fri, 27 Apr 2007 16:26:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.174]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RNQXd1007979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 27 Apr 2007 16:26:54 -0700 (MST) (envelope-from [e-mail])
Received: from GALATIONS (unknown [207.202.179.27]) by smtp4.pacifier.net (Postfix) with ESMTP id E09236A6A4; Fri, 27 Apr 2007 16:26:27 -0700 (PDT)
From: "Jim Schaad" <[e-mail]>
To: "'Peter Sylvester'" <[e-mail]>
Cc: "'pgut001'" <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <04c801c78499$837eb390$8a7c1ab0$@com> <[e-mail]> <059701c7877c$7363c000$5a2b4000$@com> <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
Date: Fri, 27 Apr 2007 16:26:26 -0700
Message-ID: <000801c78923$7b365f10$71a31d30$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AceH48cKLo1ZEmptSyq/fk7HEOMUjQBPvacQ
Content-Language: en-us
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>

Peters,

I think that you are off base on this.  If you are going to make an
attribute that is dependent on the body you WANT the attributes to come
before the body.  If this is not the case, the authenticator does not know
that the attribute validation needs to be setup until the body has been
completely processed and it cannot be placed in stream anymore.  This does
make things harder for the encoder, but the authentication operation can be
assumed to occur more often than the encoding operation.

If this swap is done for reasons of consistency I can agree with this.  If
this is done to satisfy the need for the argument based on the content of
the body I oppose swapping the body and the authenticated attributes.

Jim

PS I apologize Russ, I should have spotted this sooner.  I knew that I was
having a problem with the argument but I could not nail it down.

JLS

> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]] On Behalf Of Peter Sylvester
> Sent: Thursday, April 26, 2007 2:12 AM
> To: Jim Schaad
> Cc: 'pgut001'; [e-mail]; [e-mail]
> Subject: Re: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
> 
> Jim Schaad wrote:
> > Yes I agree that would be a problem,  can you suggest an attribute
> which
> > might need to be placed there that would have this attribute?
> Currently the
> > only one I could think of is a digest which is not needed as this is
> dealt
> > with by the encryption algorithm.
> >
> A time stamp, or something like a the 3 level wrapper of ESS to be
> extracted from
> some data that are structured, i.e. you would have an appliance that
> streams
> end encrypts and adds a resume.
> > I don't need a real one, but I want to have some inkling that this
> MIGHT be
> > a real problem before trying to solve it.
> >
> See above. I am not sure but I always had the impression that the
> possibility of streaming
> is one of the fundamental features. If now we have an algorithm that
> does allow this
> in a reasonable, i.e. for example by splitting the message into chained
> chunks that
> can be authenticated (almost) on the fly and do not require an
> undeterminable
> size limit. requiring several mega of storage is not acceptable for
> processing smime
> message is not acceptable IMO.
> 
> > Jim
> >
> >
> >
> >> -----Original Message-----
> >> From: pgut001 [mailto:[e-mail]]
> >> Sent: Wednesday, April 25, 2007 1:55 PM
> >> To: [e-mail]; [e-mail];
> >> [e-mail]
> >> Cc: [e-mail]
> >> Subject: RE: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
> >>
> >> "Jim Schaad" <[e-mail]> writes:
> >>
> >>
> >>> I am having a problem seeing why having the attributes first causes
> a
> >>> problem for algorithms that want them second.  All that is needed
> is
> >>>
> >> that
> >>
> >>> the encryption wrapper for the code understand that the attributes
> are
> >>>
> >> going
> >>
> >>> to come in first and hold onto them until later.  This is assuming
> >>>
> >> that the
> >>
> >>> encryption wrapper understands the difference between the body and
> the
> >>> attributes.
> >>>
> >> What if the attributes depend on the data being processed (as Peter
> >> Sylvester
> >> pointed out)?  By putting them first, you can't emit the first byte
> of
> >> data
> >> until you've processed every other byte of data.  This is why
> current
> >> CMS
> >> practice puts the attributes last.
> >>
> >> Peter.
> >>
> >
> >
> >




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RL9iIW086211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Apr 2007 14:09:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3RL9i5C086210; Fri, 27 Apr 2007 14:09:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l3RL9Nq0086172 for <[e-mail]>; Fri, 27 Apr 2007 14:09:44 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 28988 invoked by uid 0); 27 Apr 2007 21:09:12 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.66.14.186) by woodstock.binhost.com with SMTP; 27 Apr 2007 21:09:12 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 27 Apr 2007 17:09:16 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: I-D ACTION:draft-housley-smime-suite-b-01.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>

I think this WG will be interested in this draft:
http://www.ietf.org/internet-drafts/draft-housley-smime-suite-b-01.txt

The minimal changes since the -00 version can bee seen at:
http://potaroo.net/cgi-bin/htmlwdiff?f1=%2e%2e%2fall%2dids%2fdraft%2dhousley%2dsmime%2dsuite%2db%2d01%2etxt&f2=%2e%2e%2fall%2dids%2fdraft%2dhousley%2dsmime%2dsuite%2db%2d00%2etxt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RJoNrl075099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Apr 2007 12:50:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3RJoNeT075097; Fri, 27 Apr 2007 12:50:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ns4.neustar.com (ns4.neustar.com [156.154.24.139]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RJo20o075030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 27 Apr 2007 12:50:23 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 852202ACAF; Fri, 27 Apr 2007 19:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HhWSA-0002QQ-9B; Fri, 27 Apr 2007 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-escertid-06.txt 
Message-Id: <[e-mail]>
Date: Fri, 27 Apr 2007 15:50:02 -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		: ESS Update: Adding CertID Algorithm Agility
	Author(s)	: J. Schaad
	Filename	: draft-ietf-smime-escertid-06.txt
	Pages		: 20
	Date		: 2007-4-27
	
In the original Enhanced Security Services for S/MIME document (RFC
   2634), a structure for cryptographically linking the certificate to
   be used in validation with the signature was introduced, this
   structure was hardwired to use SHA-1.  This document allows for the
   structure to have algorithm agility and defines a new attribute for
   this purpose.

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

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-escertid-06.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-escertid-06.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-escertid-06.txt

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

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

--OtherAccess--

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RHDXCP057997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Apr 2007 10:13:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3RHDXvI057996; Fri, 27 Apr 2007 10:13:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.voltage.com (mail.voltage.com [209.213.222.98]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RHDCXq057985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 27 Apr 2007 10:13:33 -0700 (MST) (envelope-from [e-mail])
Received: from influenza.voltage.com (influenza.voltage.com [172.16.0.77]) by mail.voltage.com (8.13.7/8.13.7) with ESMTP id l3RHDN8j004589 for <[e-mail]>; Fri, 27 Apr 2007 10:13:23 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Squeak signed email
Date: Fri, 27 Apr 2007 10:13:27 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Squeak signed email
Thread-Index: AceI7sqa9SGg3ORIR9KX3BnEG0pTQgAAHVwg
References: <[e-mail]> <003901c788e7$15f88560$82c5a8c0@arport2v>
From: "Luther Martin" <[e-mail]>
To: <[e-mail]>
X-Proofpoint-Virus-Version: vendor=fsecure engine=4.65.5502:2.3.11,1.2.37,4.0.164 definitions=2007-04-27_06:2007-04-27,2007-04-27,2007-04-27 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=3.1.0-0703060001 definitions=main-0704270092
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l3RHDXXp057991
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've seen that message in OE for perfectly valid signatures (using
VeriSign and Thawte certs) that validate just fine in Outlook. 

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Anders Rundgren
Sent: Friday, April 27, 2007 9:14 AM
To: [e-mail]; [e-mail]
Subject: Re: Squeak signed email


>test

Failed.  Did not validate in Outlook Express.
Broken signature seems to be the case since OE says "Message has been
tampered with".

Anders

----- Original Message ----- 
From: <[e-mail]>
To: <[e-mail]>
Sent: Friday, April 27, 2007 06:20
Subject: Squeak signed email


test





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RGEeoP053029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Apr 2007 09:14:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3RGEe3a053028; Fri, 27 Apr 2007 09:14:40 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout2-sn1.fre.skanova.net (pne-smtpout2-sn1.fre.skanova.net [81.228.11.159]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RGEIDT052998 for <[e-mail]>; Fri, 27 Apr 2007 09:14:39 -0700 (MST) (envelope-from [e-mail])
Received: from arport2v (81.232.45.243) by pne-smtpout2-sn1.fre.skanova.net (7.2.075) (authenticated as u18116613) id 46134812005F9D8C; Fri, 27 Apr 2007 18:14:17 +0200
Message-ID: <003901c788e7$15f88560$82c5a8c0@arport2v>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Squeak signed email
Date: Fri, 27 Apr 2007 18:14:06 +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 6.00.2800.1807
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896
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>

>test

Failed.  Did not validate in Outlook Express.
Broken signature seems to be the case since OE says "Message has been tampered with".

Anders

----- Original Message ----- 
From: <[e-mail]>
To: <[e-mail]>
Sent: Friday, April 27, 2007 06:20
Subject: Squeak signed email


test



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3R5rFhu077052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Apr 2007 22:53:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3R5rFxu077051; Thu, 26 Apr 2007 22:53:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp104.plus.mail.mud.yahoo.com (smtp104.plus.mail.mud.yahoo.com [68.142.206.237]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l3R5qsFr076974 for <[e-mail]>; Thu, 26 Apr 2007 22:53:14 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 51219 invoked from network); 27 Apr 2007 05:52:54 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-YMail-OSG:Mime-Version:In-Reply-To:References:Content-Type:Message-Id:From:Subject:Date:To:X-Mailer; b=GB7Mpx9A/1T3wWZrSsdDhsFbeb+k04+gXEqrFH+yUCjIukZbVewo4AY2/aGH81znpczcSUNDnKw4+Izcz9yGLLlBvIuLb1RXbP3rFQO0hPq2GhMHwQX3QaWzDE69FM+OnJQR+i+AAO4wAptKif7c+a+mSGP10puPcRvNkbIalsU=  ;
Received: from unknown (HELO ?192.168.1.2?) (reefedjib@67.161.111.196 with plain) by smtp104.plus.mail.mud.yahoo.com with SMTP; 27 Apr 2007 05:52:53 -0000
X-YMail-OSG: 2C_Xt5wVM1ljwJtfORPpz00QTJtcGw6NubRICmwdnU1KV.z0_gXBLSo6WOx5AIEeOwMVcA5PFQ--
Mime-Version: 1.0 (Apple Message framework v752.2)
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4--370010778; protocol="application/pkcs7-signature"
Message-Id: <[e-mail]>
From: Robert Withers <[e-mail]>
Subject: Re: Squeak signed email
Date: Thu, 26 Apr 2007 22:52:47 -0700
To: [e-mail]
X-Mailer: Apple Mail (2.752.2)
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>

--Apple-Mail-4--370010778
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

Sorry about this.  This is the last one I believe.  I use a script  
for testing and had this address in the To line.

On Apr 26, 2007, at 3:13 PM, [e-mail] wrote:

> test


--Apple-Mail-4--370010778
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJzCCAuAw
ggJJoAMCAQICEGXvVKR4LXErXHeSqUjXMp4wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDQxMDA1NTMzOFoXDTA4MDQwOTA1NTMz
OFowRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEiMCAGCSqGSIb3DQEJARYTcmVl
ZmVkamliQHlhaG9vLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJXg+stvYG/O
LyD7LX9yUj0kERvKrVkYOzQ28EOW61taZAkHvylZpwMIHmGFKj/wDZ/q/c07KGQ9UpZNBVd9gKuc
81ZvfMGgCtStJbtPrLgar5ErdO9bvBROtObnIHaJb35J8CVt4pi1soERj6LLVHLTznZ+lUHMpNdP
bHJ88sXk/EYwqGTjcsj+aEtviTklvrhfy0+UO/oooBrkh0w+be2PU03NugrLaqhj52XTqb/b1LaR
CU63V3aT6pO2mFUd0gUFF9Mni5m0onTto8knq6ic6eQjJFlu7nCGohken5k3EJdT7Qg9hIXmvW3F
C4J5x/qp32rl0yU2HIk4Aylp33sCAwEAAaMwMC4wHgYDVR0RBBcwFYETcmVlZmVkamliQHlhaG9v
LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAIK8GbxBhMXZSM4kX36bVR3dtDtd
Yc+im0H12bYGFLZJiCx4195sO/Hhe4+IlD+eWjGBCfUDqdJy4A5nipCLeIEP90x3rdQTU+0A1wvk
x1qVx39xq8BTXOMaQ/ZW82+DNKs//8Zz/8TmqnUX55u+BvfqPwmeOL5wlT7Fh2AQcLJGMIIDPzCC
AqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl
cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo
MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3Rl
IFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0
aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDE
pjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J
8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+n
ttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4
oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmww
CwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODAN
BgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0
HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghO
rvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMC
WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0
ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBl71SkeC1xK1x3kqlI1zKeMAkGBSsOAwIa
BQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3MDQyNzA1
NTI0OFowIwYJKoZIhvcNAQkEMRYEFKw5GVD0LrApK1SBmTXucxzlBcd+MIGFBgkrBgEEAYI3EAQx
eDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu
MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQZe9UpHgtcStc
d5KpSNcynjCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3
dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h
aWwgSXNzdWluZyBDQQIQZe9UpHgtcStcd5KpSNcynjANBgkqhkiG9w0BAQEFAASCAQAIvEA4jP4e
6EVXaHcy4BdF4yiCNCyaYCeu+ayc3aL8L4SnSy32Ba0K68w1w7Mid2zMqjqCcVRmB6TtxT63NlEh
t2i976GnYW/eEXgirnZgTkSVPidShSS3bB5W43oDvPYiXVl0bdVtvsSfSR0WtifVSl6VdqbjaKWX
psYY6KLW+Am3HbpnGLvHAFhHjbfNTYOC1zbT7UN/GDKIKOXk5LCOhcjYsf4T4kfj/GElAzS+MWj2
hY6UfNV9Wl//696FPxrpP6GUW5vNj5Ul7gu4uayklmu1IrFdcLaH7y3lCWNeRtBLeZIgo75OTkoJ
UZBZ81NFRRdT7si1Ut5BoomNs0U3AAAAAAAA

--Apple-Mail-4--370010778--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3R5DT8v071218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Apr 2007 22:13:29 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3R5DTTb071217; Thu, 26 Apr 2007 22:13:29 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp102.plus.mail.mud.yahoo.com (smtp102.plus.mail.mud.yahoo.com [68.142.206.235]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l3R5DSrY071210 for <[e-mail]>; Thu, 26 Apr 2007 22:13:28 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 42206 invoked from network); 27 Apr 2007 05:13:27 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-YMail-OSG:Mime-version:Date:Subject:Content-type:To:From; b=vHeqbhEuvUfVXDRdsJ+C0fDfwMJBAfagA+T+s33xhVLNfUN4JDeCmygzJD3T+31NzNaPv3LSD9U7IhEWiER8iT5msA5X6pZT8REdjtmsQgdjUcq2j6KmlW15B4r1+tRwYY17FMFRNKGl7isWeOK9SSKsUvqy/GwyMh82n/I9ZiY=  ;
Received: from unknown (reefedjib@67.161.111.196 with login) by smtp102.plus.mail.mud.yahoo.com with SMTP; 27 Apr 2007 05:13:25 -0000
X-YMail-OSG: 50ypxaYVM1kfeq_24BJIc1bfW62NcGQHUVYNCXBE_22HRXd.m6r.bI7x4pcyeCHWIgyc6RlOTA--
Mime-version: 1.0
Date: Thu, 26 Apr 2007 22:13:17 0000
Subject: Squeak signed email
Content-type: multipart/signed; micalg="sha1"; boundary="==CelesteAttachment37139=="; protocol="application/pkcs7-signature"
To: [e-mail]
From: [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>

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

test
--==CelesteAttachment37139==
Content-type: application/pkcs7-signature;
	name="smime.p7s"
Content-transfer-encoding: base64
Content-disposition: attachment;
	filename="smime.p7s"

MIIJbwYJKoZIhvcNAQcCoIIJYDCCCVwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BicwggLgMIICSaADAgECAhBl71SkeC1xK1x3kqlI1zKeMA0GCSqGSIb3DQEBBQUAMGIxCzAJ
BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD
VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNzA0MTAwNTUz
MzhaFw0wODA0MDkwNTUzMzhaMEUxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx
IjAgBgkqhkiG9w0BCQEWE3JlZWZlZGppYkB5YWhvby5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQCV4PrLb2Bvzi8g+y1/clI9JBEbyq1ZGDs0NvBDlutbWmQJB78pWacD
CB5hhSo/8A2f6v3NOyhkPVKWTQVXfYCrnPNWb3zBoArUrSW7T6y4Gq+RK3TvW7wUTrTm5yB2
iW9+SfAlbeKYtbKBEY+iy1Ry0852fpVBzKTXT2xyfPLF5PxGMKhk43LI/mhLb4k5Jb64X8tP
lDv6KKAa5IdMPm3tj1NNzboKy2qoY+dl06m/29S2kQlOt1d2k+qTtphVHdIFBRfTJ4uZtKJ0
7aPJJ6uonOnkIyRZbu5whqIZHp+ZNxCXU+0IPYSF5r1txQuCecf6qd9q5dMlNhyJOAMpad97
AgMBAAGjMDAuMB4GA1UdEQQXMBWBE3JlZWZlZGppYkB5YWhvby5jb20wDAYDVR0TAQH/BAIw
ADANBgkqhkiG9w0BAQUFAAOBgQCCvBm8QYTF2UjOJF9+m1Ud3bQ7XWHPoptB9dm2BhS2SYgs
eNfebDvx4XuPiJQ/nloxgQn1A6nScuAOZ4qQi3iBD/dMd63UE1PtANcL5Mdalcd/cavAU1zj
GkP2VvNvgzSrP//Gc//E5qp1F+ebvgb36j8Jnji+cJU+xYdgEHCyRjCCAz8wggKooAMCAQIC
AQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh
cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAm
BgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0
ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h
aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV
BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQD
EyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEF
AAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B
1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79A
gAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E
CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3
dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEa
MBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7M
DaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa
C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk1
3iSx0x1G/11fZU8xggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3
dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl
ZW1haWwgSXNzdWluZyBDQQIQZe9UpHgtcStcd5KpSNcynjAJBgUrDgMCGgUAoIIBbzAYBgkq
hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNzA0MjYyMjEzMTdaMCMG
CSqGSIb3DQEJBDEWBBQyxWFdizqj60D+8/wYcFb79bBYvzCBhQYJKwYBBAGCNxAEMXgwdjBi
MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEs
MCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGXvVKR4LXEr
XHeSqUjXMp4wgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc
VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFs
IEZyZWVtYWlsIElzc3VpbmcgQ0ECEGXvVKR4LXErXHeSqUjXMp4wDQYJKoZIhvcNAQEBBQAE
ggEASa5piXYfKTw6IXEP6hehiI96gsEiMCoF6JCXw7CdOWb2fjCxdOpJceykc7kzs/3rkZ0j
NLTr/9XGwEVWZoypJTFqGV8ol+76CDC7MbJNMRNilvcdn0vxCS4+DdU6CKShzZbcvvkMTbld
k7atsQ8Dbny8GiMJifvQ0U5NFg3PLOlWhsNnZ+Dc4HXAkRuCdf0gdP/rg5HO/JHRhvYrNNfA
FZW8ICZQkO/vjjhIHMGBw2aZT5Yt6+ukwuz6f0EaFyxzE1M/ylioB9FofO8oD+B6KMThyWQg
rweD3LCGAhHarQcZ+sznDuojgWWCF+9RmXM7BOPUJLehJqK6mwPNDMfkog==
--==CelesteAttachment37139==--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3R4rP0N068043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Apr 2007 21:53:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3R4rP7Z068042; Thu, 26 Apr 2007 21:53:25 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp107.plus.mail.mud.yahoo.com (smtp107.plus.mail.mud.yahoo.com [68.142.206.240]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l3R4r3v7067995 for <[e-mail]>; Thu, 26 Apr 2007 21:53:23 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 37847 invoked from network); 27 Apr 2007 04:52:59 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-YMail-OSG:Mime-version:Date:Subject:Content-type:To:From; b=X2JHi8iIoeCV9xx2z54WRFzsSOgGfhoPB8db7UIWJl3HaN+oPh1HLXn4tH2wELa3rrCspf8qrHm+BYheH80R7/DRu4wcPmScQE50Oofs/LvPBvoE+Vy8so32E1xi6TkSfzgI2jBKyrdPlPxqG40lUeBJdMaEl0OwcgMt8JBb+74=  ;
Received: from unknown (reefedjib@67.161.111.196 with login) by smtp107.plus.mail.mud.yahoo.com with SMTP; 27 Apr 2007 04:52:58 -0000
X-YMail-OSG: RkdvOHsVM1mNOBceYVDfeRYR4A47v._.RiA6vSVjheWu0yn2ZujaWNceK55wDIKaRckrSXq29w--
Mime-version: 1.0
Date: Thu, 26 Apr 2007 21:52:51 0000
Subject: Squeak signed email
Content-type: multipart/signed; micalg="sha1"; boundary="==CelesteAttachment45975=="; protocol="application/pkcs7-signature"
To: [e-mail]
From: [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>

--==CelesteAttachment45975==
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed

test
--==CelesteAttachment45975==
Content-type: application/pkcs7-signature;
	name="smime.p7s"
Content-transfer-encoding: base64
Content-disposition: attachment;
	filename="smime.p7s"

MIIJbwYJKoZIhvcNAQcCoIIJYDCCCVwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BicwggLgMIICSaADAgECAhBl71SkeC1xK1x3kqlI1zKeMA0GCSqGSIb3DQEBBQUAMGIxCzAJ
BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD
VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNzA0MTAwNTUz
MzhaFw0wODA0MDkwNTUzMzhaMEUxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx
IjAgBgkqhkiG9w0BCQEWE3JlZWZlZGppYkB5YWhvby5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQCV4PrLb2Bvzi8g+y1/clI9JBEbyq1ZGDs0NvBDlutbWmQJB78pWacD
CB5hhSo/8A2f6v3NOyhkPVKWTQVXfYCrnPNWb3zBoArUrSW7T6y4Gq+RK3TvW7wUTrTm5yB2
iW9+SfAlbeKYtbKBEY+iy1Ry0852fpVBzKTXT2xyfPLF5PxGMKhk43LI/mhLb4k5Jb64X8tP
lDv6KKAa5IdMPm3tj1NNzboKy2qoY+dl06m/29S2kQlOt1d2k+qTtphVHdIFBRfTJ4uZtKJ0
7aPJJ6uonOnkIyRZbu5whqIZHp+ZNxCXU+0IPYSF5r1txQuCecf6qd9q5dMlNhyJOAMpad97
AgMBAAGjMDAuMB4GA1UdEQQXMBWBE3JlZWZlZGppYkB5YWhvby5jb20wDAYDVR0TAQH/BAIw
ADANBgkqhkiG9w0BAQUFAAOBgQCCvBm8QYTF2UjOJF9+m1Ud3bQ7XWHPoptB9dm2BhS2SYgs
eNfebDvx4XuPiJQ/nloxgQn1A6nScuAOZ4qQi3iBD/dMd63UE1PtANcL5Mdalcd/cavAU1zj
GkP2VvNvgzSrP//Gc//E5qp1F+ebvgb36j8Jnji+cJU+xYdgEHCyRjCCAz8wggKooAMCAQIC
AQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh
cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAm
BgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0
ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h
aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV
BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQD
EyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEF
AAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B
1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79A
gAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E
CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3
dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEa
MBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7M
DaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa
C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk1
3iSx0x1G/11fZU8xggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3
dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl
ZW1haWwgSXNzdWluZyBDQQIQZe9UpHgtcStcd5KpSNcynjAJBgUrDgMCGgUAoIIBbzAYBgkq
hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNzA0MjcwNDIwMDFaMCMG
CSqGSIb3DQEJBDEWBBTsWr1SWNYtUXsxg26qu1LP7lrO/zCBhQYJKwYBBAGCNxAEMXgwdjBi
MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEs
MCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGXvVKR4LXEr
XHeSqUjXMp4wgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc
VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFs
IEZyZWVtYWlsIElzc3VpbmcgQ0ECEGXvVKR4LXErXHeSqUjXMp4wDQYJKoZIhvcNAQEBBQAE
ggEAQCPu/DIsgCYkCzGN5gigjINmICIG/vO1++klO6q1CCbbTZEEe4c/q/HLez2WTbLjym9M
gmy2FVVA9WL2w2OZyUxHX3F74Y5Gq7+JZSyVdsTQI3JbD9u+vzVn80nLOdzbwMH9E+ca6LrW
kLPI/oTrfBfwslNeCoxI+irMUjlaJ2AyOsUPGtgZaXvnHUW4w32smUUkGYydLaf2HwdpeJgp
pt38NNyfiC3YNkyp1GH9RI7G9k25MBlEEMQYaJX33lEiNeBprZo4prMhCLyYs5Y/ZWUh7vCh
ZtpBFTl5oPMC+ZZWnhIBNBuElE4Xp7jSMZs3i43WWr8NErypG9Vp+PqSQA==
--==CelesteAttachment45975==--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3R4LEfv063186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Apr 2007 21:21:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3R4LEAl063185; Thu, 26 Apr 2007 21:21:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp102.plus.mail.mud.yahoo.com (smtp102.plus.mail.mud.yahoo.com [68.142.206.235]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l3R4KrnW063144 for <[e-mail]>; Thu, 26 Apr 2007 21:21:13 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 44827 invoked from network); 27 Apr 2007 04:20:52 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-YMail-OSG:Mime-version:Date:Subject:Content-type:To:From; b=sIZ/sE7QZ14e68jdpjs6PnV2byWjr+jgu5rk02WDBkIZ3/9rUJaDBH7OgYnpTidHZ/vnxDpX9bRzaOhOYSinPtwRfCLUJJ7u1aue5w/gzcmK4PhiWz4ZavqGoKuklsrMK2UyOwdyhSkDr6nhHnswZ49IVffEqGaHJiJK7ojkhhs=  ;
Received: from unknown (reefedjib@67.161.111.196 with login) by smtp102.plus.mail.mud.yahoo.com with SMTP; 27 Apr 2007 04:20:50 -0000
X-YMail-OSG: W5DUDvwVM1lAeN8U66Aar72GVMdG3vyFU_2o2lfZl_uVUTV2WiEfkCWLAPk0W9E5p61DANrJjA--
Mime-version: 1.0
Date: Thu, 26 Apr 2007 21:20:43 -0700
Subject: Squeak signed email
Content-type: multipart/signed; micalg="sha1"; boundary="==CelesteAttachment22313=="; protocol="application/pkcs7-signature"
To: [e-mail]
From: [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>

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

test
--==CelesteAttachment22313==
Content-type: application/pkcs7-signature;
	name="smime.p7s"
Content-transfer-encoding: base64
Content-disposition: attachment;
	filename="smime.p7s"

MIIJbwYJKoZIhvcNAQcCoIIJYDCCCVwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BicwggLgMIICSaADAgECAhBl71SkeC1xK1x3kqlI1zKeMA0GCSqGSIb3DQEBBQUAMGIxCzAJ
BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD
VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNzA0MTAwNTUz
MzhaFw0wODA0MDkwNTUzMzhaMEUxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx
IjAgBgkqhkiG9w0BCQEWE3JlZWZlZGppYkB5YWhvby5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQCV4PrLb2Bvzi8g+y1/clI9JBEbyq1ZGDs0NvBDlutbWmQJB78pWacD
CB5hhSo/8A2f6v3NOyhkPVKWTQVXfYCrnPNWb3zBoArUrSW7T6y4Gq+RK3TvW7wUTrTm5yB2
iW9+SfAlbeKYtbKBEY+iy1Ry0852fpVBzKTXT2xyfPLF5PxGMKhk43LI/mhLb4k5Jb64X8tP
lDv6KKAa5IdMPm3tj1NNzboKy2qoY+dl06m/29S2kQlOt1d2k+qTtphVHdIFBRfTJ4uZtKJ0
7aPJJ6uonOnkIyRZbu5whqIZHp+ZNxCXU+0IPYSF5r1txQuCecf6qd9q5dMlNhyJOAMpad97
AgMBAAGjMDAuMB4GA1UdEQQXMBWBE3JlZWZlZGppYkB5YWhvby5jb20wDAYDVR0TAQH/BAIw
ADANBgkqhkiG9w0BAQUFAAOBgQCCvBm8QYTF2UjOJF9+m1Ud3bQ7XWHPoptB9dm2BhS2SYgs
eNfebDvx4XuPiJQ/nloxgQn1A6nScuAOZ4qQi3iBD/dMd63UE1PtANcL5Mdalcd/cavAU1zj
GkP2VvNvgzSrP//Gc//E5qp1F+ebvgb36j8Jnji+cJU+xYdgEHCyRjCCAz8wggKooAMCAQIC
AQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh
cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAm
BgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0
ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h
aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV
BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQD
EyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEF
AAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B
1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79A
gAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E
CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3
dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEa
MBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7M
DaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa
C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk1
3iSx0x1G/11fZU8xggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3
dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl
ZW1haWwgSXNzdWluZyBDQQIQZe9UpHgtcStcd5KpSNcynjAJBgUrDgMCGgUAoIIBbzAYBgkq
hkiG9w0BCQMxCwYJKoZIhvcNAQcBMCMGCSqGSIb3DQEJBDEWBBQyxWFdizqj60D+8/wYcFb7
9bBYvzAcBgkqhkiG9w0BCQUxDxcNMDcwNDI2MjEyMDM4WjCBhQYJKwYBBAGCNxAEMXgwdjBi
MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEs
MCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGXvVKR4LXEr
XHeSqUjXMp4wgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc
VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFs
IEZyZWVtYWlsIElzc3VpbmcgQ0ECEGXvVKR4LXErXHeSqUjXMp4wDQYJKoZIhvcNAQEBBQAE
ggEAPEss3yk4schpEFlFzcZqNQmBPA7U4KxAn+4/nvAGU6oZp+amRdXDosZX7y7d3qaqDvYd
iaXO9CstxjcNiNVLv8DUB0OCJjHc2SO0luEitH9OeVCQ62S9NZgsTA6Dez9avToFzqKwA/Hp
DP2wZ4fMRfm+O5vFQnuLYJ6fTb5ih+h6huFX7/8l72sZ/Rl1XPEl+kKOaX5H/KkoM1P8lIl0
RanQn8hgRrxewhaEmHp72ofL6wrkcWjIbEJKpDPJXbeGdFwpK4Koe/Eqd0SqhdhoMAxzZqKT
8c1NbpeOoPnMrNm3/RE73i2/C3/yIQ2VP9bcsW8h64H1t+uITNgxkS3C8w==
--==CelesteAttachment22313==--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3QJoNLu085986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Apr 2007 12:50:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3QJoNqq085985; Thu, 26 Apr 2007 12:50:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ns4.neustar.com (ns4.neustar.com [156.154.24.139]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3QJo2oP085943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 26 Apr 2007 12:50:23 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 8828E2ACA3; Thu, 26 Apr 2007 19:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hh9yc-00069O-AQ; Thu, 26 Apr 2007 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-04.txt 
Message-Id: <[e-mail]>
Date: Thu, 26 Apr 2007 15:50:02 -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		: Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-cms-auth-enveloped-04.txt
	Pages		: 11
	Date		: 2007-4-26
	
This document describes an additional content type for the
   Cryptographic Message Syntax (CMS).  The authenticated-enveloped-data
   content type is intended for use with authenticated encryption modes.
   All of the various key management techniques that are supported in
   the CMS enveloped-data content type are also supported by the CMS
   authenticated-enveloped-data content type.

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

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-cms-auth-enveloped-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-cms-auth-enveloped-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-cms-auth-enveloped-04.txt

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

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

--OtherAccess--

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3QEO0Tt048250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Apr 2007 07:24:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3QEO0PZ048249; Thu, 26 Apr 2007 07:24:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l3QENd1V048238 for <[e-mail]>; Thu, 26 Apr 2007 07:23:59 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 15679 invoked by uid 0); 26 Apr 2007 14:23:36 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.66.14.186) by woodstock.binhost.com with SMTP; 26 Apr 2007 14:23:36 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 26 Apr 2007 10:23:35 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[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:

> >The difference is the swapped order of authAttrs and 
> authEncryptedContentInfo.
>
>Yup.

Okay.  I'll swap the order.

Russ



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3Q9EvHD022803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Apr 2007 02:14:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3Q9EvoM022802; Thu, 26 Apr 2007 02:14:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ganymede.on-x.com (ganymede.on-x.com [194.51.68.3]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3Q9EYOk022785 for <[e-mail]>; Thu, 26 Apr 2007 02:14:56 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (ganymede [127.0.0.1]) by ganymede.on-x.com (Postfix) with ESMTP id AE2E623; Thu, 26 Apr 2007 11:14:29 +0200 (CEST)
Received: from ganymede.on-x.com ([127.0.0.1]) by localhost (ganymede.on-x.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26083-02; Thu, 26 Apr 2007 11:14:27 +0200 (CEST)
Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id BA13B22; Thu, 26 Apr 2007 11:14:27 +0200 (CEST)
Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2007042611142658:223010 ; Thu, 26 Apr 2007 11:14:26 +0200 
Message-ID: <[e-mail]>
Date: Thu, 26 Apr 2007 11:12:16 +0200
From: Peter Sylvester <[e-mail]>
User-Agent: Thunderbird 1.5.0.9 (X11/20061206)
MIME-Version: 1.0
To: Jim Schaad <[e-mail]>
Cc: "'pgut001'" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
References: <04c801c78499$837eb390$8a7c1ab0$@com> <[e-mail]> <059701c7877c$7363c000$5a2b4000$@com>
In-Reply-To: <059701c7877c$7363c000$5a2b4000$@com>
X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11  |July 24, 2002) at 04/26/2007 11:14:26 AM, Serialize by Router on vinea/ON-X(Release 5.0.11  |July 24, 2002) at 04/26/2007 11:14:27 AM, Serialize complete at 04/26/2007 11:14:27 AM
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020608030505060508070608"
X-Virus-Scanned: by amavisd-new at on-x.com
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 is a cryptographically signed message in MIME format.

--------------ms020608030505060508070608
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit

Jim Schaad wrote:
> Yes I agree that would be a problem,  can you suggest an attribute which
> might need to be placed there that would have this attribute?  Currently the
> only one I could think of is a digest which is not needed as this is dealt
> with by the encryption algorithm.
>   
A time stamp, or something like a the 3 level wrapper of ESS to be 
extracted from
some data that are structured, i.e. you would have an appliance that streams
end encrypts and adds a resume.
> I don't need a real one, but I want to have some inkling that this MIGHT be
> a real problem before trying to solve it.
>   
See above. I am not sure but I always had the impression that the 
possibility of streaming
is one of the fundamental features. If now we have an algorithm that 
does allow this
in a reasonable, i.e. for example by splitting the message into chained 
chunks that
can be authenticated (almost) on the fly and do not require an 
undeterminable
size limit. requiring several mega of storage is not acceptable for 
processing smime
message is not acceptable IMO.

> Jim
>
>
>   
>> -----Original Message-----
>> From: pgut001 [mailto:[e-mail]]
>> Sent: Wednesday, April 25, 2007 1:55 PM
>> To: [e-mail]; [e-mail];
>> [e-mail]
>> Cc: [e-mail]
>> Subject: RE: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
>>
>> "Jim Schaad" <[e-mail]> writes:
>>
>>     
>>> I am having a problem seeing why having the attributes first causes a
>>> problem for algorithms that want them second.  All that is needed is
>>>       
>> that
>>     
>>> the encryption wrapper for the code understand that the attributes are
>>>       
>> going
>>     
>>> to come in first and hold onto them until later.  This is assuming
>>>       
>> that the
>>     
>>> encryption wrapper understands the difference between the body and the
>>> attributes.
>>>       
>> What if the attributes depend on the data being processed (as Peter
>> Sylvester
>> pointed out)?  By putting them first, you can't emit the first byte of
>> data
>> until you've processed every other byte of data.  This is why current
>> CMS
>> practice puts the attributes last.
>>
>> Peter.
>>     
>
>
>   


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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC
BHIwggLfoAMCAQICBgqvijKA3jANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G
A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs
UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNzAzMjYxMDM3MDNaFw0wOTA2MDMxMDM3MDNaMHAx
CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ
S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu
ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPB7ZSfmYsUuVIV0W2izxb1Zyvr6ZJ
IjPiqRMs77dbEQhQ6FZhhUSuABxxc8NjZvyPMRo0uuT0iVpRDktb0fWPTx3m9qTfdqrhWg2c
IOBKNbNQr8NogDJvG1AxRx4q9SXKZCVpZCoHu3fz2Rfji1kL7l597+7qBEsFd9IyvRaexQID
AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5
MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT
VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD
VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F
ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSZjq81LuJmsiiu1Yt/ezwCiUQSQTAfBgNV
HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA
A4IBfAAUq5MJ3gXhdKDpOm0ascDE9e1iMo0RQ24ujkc9IrFXhAJNS+3eNwcJEieU2vgZTsGb
zKeBZom1zVOFoh73VIRP6T08j4dDlndpDYZbxD20KzFt9zX6gV8IgR2zkkZXLQRbLyW16kw8
oFe3s//p1csCkCPAlZv1rZQYR5Psm0A1aiOiuSHhWUmgfAJxmIgfbmKtS3WpsUZVBuLQpThN
rWjLRAqJKYA++++qqo3ujqAAzJLe+MHrX5dai7+n6WBfV4qo1uDArR7XbmgVpV/EdPA75XRi
XEedLgbFDawJ9nAMN6WfL/NG6GZkEa7mZ7sH/gG34y21nq4w4mAAxn9wz7mDKMsEbJMZ5VlJ
TOp0g6TdYqGjNoc/rQg7pqjcRChVitwd1Rl8O31+bIdNSpv4UReNMDcffRQrt+pF1FxR4q6q
M9YLJU8NThx/89Mf/WF7fzrgVlsNJ78D9nJu0EhKes/9EX2qpIcHUfk/izOj8lCc1ksFgXpd
UEchE0DcMIIEcjCCAt+gAwIBAgIGCq+KMoDeMA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT
AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV
BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA3MDMyNjEwMzcwM1oXDTA5MDYwMzEw
MzcwM1owcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp
Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA
ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8HtlJ+ZixS5UhXRbaL
PFvVnK+vpkkiM+KpEyzvt1sRCFDoVmGFRK4AHHFzw2Nm/I8xGjS65PSJWlEOS1vR9Y9PHeb2
pN92quFaDZwg4Eo1s1Cvw2iAMm8bUDFHHir1JcpkJWlkKge7d/PZF+OLWQvuXn3v7uoESwV3
0jK9Fp7FAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl
Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl
ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF
BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F
ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJmOrzUu4mayKK7Vi397PAKJ
RBJBMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI
hvcNAQEFBQADggF8ABSrkwneBeF0oOk6bRqxwMT17WIyjRFDbi6ORz0isVeEAk1L7d43BwkS
J5Ta+BlOwZvMp4FmibXNU4WiHvdUhE/pPTyPh0OWd2kNhlvEPbQrMW33NfqBXwiBHbOSRlct
BFsvJbXqTDygV7ez/+nVywKQI8CVm/WtlBhHk+ybQDVqI6K5IeFZSaB8AnGYiB9uYq1Ldamx
RlUG4tClOE2taMtECokpgD7776qqje6OoADMkt74wetfl1qLv6fpYF9XiqjW4MCtHtduaBWl
X8R08DvldGJcR50uBsUNrAn2cAw3pZ8v80boZmQRruZnuwf+AbfjLbWerjDiYADGf3DPuYMo
ywRskxnlWUlM6nSDpN1ioaM2hz+tCDumqNxEKFWK3B3VGXw7fX5sh01Km/hRF40wNx99FCu3
6kXUXFHirqoz1gslTw1OHH/z0x/9YXt/OuBWWw0nvwP2cm7QSEp6z/0RfaqkhwdR+T+LM6Py
UJzWSwWBel1QRyETQNwwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL
MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL
STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0
MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj
ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI
hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M
ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe
1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt
qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd
UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH
pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS
cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB
CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0
dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C
AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV
HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3
UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy
4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz
QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u
US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj
PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq
Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf
Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y
rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6
PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL
d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18
k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg
d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD
VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ
S0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwNDI2MDkxMjE2WjAjBgkqhkiG9w0B
CQQxFgQUmvRI/c91sLpmuTFK9zW7KrlDgVUwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D
BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC
ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY
MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy
c0dFTgIGCq+KMoDeMHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE
ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ
IEVkZWxXZWIgUGVyc0dFTgIGCq+KMoDeMA0GCSqGSIb3DQEBAQUABIGAKzPCj2Fjni0WuNE5
SbdJBPk5V3YumVRQ2UbJR0qtKmtNKFAOLb+4PEIU+fx8jHlGThx6/V0CU3E5HKFeFCUQ29TS
L7dsMj2jkrO7ybyiB4kL0MU2mDeDHZFkGLC5mzNxcxR2wfCsWM4LxC0isWotrjNeL4dlpyW3
SneqWajxhWgAAAAAAAA=
--------------ms020608030505060508070608--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3Q0Z6A9047404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Apr 2007 17:35:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3Q0Z60w047403; Wed, 25 Apr 2007 17:35:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp102.plus.mail.mud.yahoo.com (smtp102.plus.mail.mud.yahoo.com [68.142.206.235]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l3Q0YjZN047358 for <[e-mail]>; Wed, 25 Apr 2007 17:35:05 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 95723 invoked from network); 26 Apr 2007 00:34:31 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-YMail-OSG:Mime-version:Date:Subject:Content-type:To:From; b=n1emBOa5yIlOeluKBkkeMiTwcdIN9U6W/tTcOZDs4MOCUVyxNZQYWf79EsOdn8MjMD/r+2mwv5GOcwQoZ9bfRktZw8AMBhr0SmoFyy/FccUY1807t/ZI+CqUuhUxjxwc2b9+6oWYOjBF7uzWsdIIsx7yBPxZa/nPNnbENXlTbkY=  ;
Received: from unknown (reefedjib@67.161.111.196 with login) by smtp102.plus.mail.mud.yahoo.com with SMTP; 26 Apr 2007 00:34:29 -0000
X-YMail-OSG: 2z0XeHQVM1kYlVCpRJhn8EQNQtxw9HUQkO8AdIf2wne_fiF9dvjzEygG_bvCH5h.OPkWJZciOg--
Mime-version: 1.0
Date: Wed, 25 Apr 2007 17:34:24 -0700
Subject: Thanks for nothing
Content-type: multipart/signed; micalg="sha1"; boundary="==CelesteAttachment34788=="; protocol="application/pkcs7-signature"
To: [e-mail]
From: [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>

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

You all are supposed to be the experts, but nobody has time to help an earnest individual with an implementation question.  Well, that's crap.

--==CelesteAttachment34788==
Content-type: application/pkcs7-signature;
	name="smime.p7s"
Content-transfer-encoding: base64
Content-disposition: attachment;
	filename="smime.p7s"

MIIJbwYJKoZIhvcNAQcCoIIJYDCCCVwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BicwggLgMIICSaADAgECAhBl71SkeC1xK1x3kqlI1zKeMA0GCSqGSIb3DQEBBQUAMGIxCzAJ
BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD
VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNzA0MTAwNTUz
MzhaFw0wODA0MDkwNTUzMzhaMEUxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx
IjAgBgkqhkiG9w0BCQEWE3JlZWZlZGppYkB5YWhvby5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQCV4PrLb2Bvzi8g+y1/clI9JBEbyq1ZGDs0NvBDlutbWmQJB78pWacD
CB5hhSo/8A2f6v3NOyhkPVKWTQVXfYCrnPNWb3zBoArUrSW7T6y4Gq+RK3TvW7wUTrTm5yB2
iW9+SfAlbeKYtbKBEY+iy1Ry0852fpVBzKTXT2xyfPLF5PxGMKhk43LI/mhLb4k5Jb64X8tP
lDv6KKAa5IdMPm3tj1NNzboKy2qoY+dl06m/29S2kQlOt1d2k+qTtphVHdIFBRfTJ4uZtKJ0
7aPJJ6uonOnkIyRZbu5whqIZHp+ZNxCXU+0IPYSF5r1txQuCecf6qd9q5dMlNhyJOAMpad97
AgMBAAGjMDAuMB4GA1UdEQQXMBWBE3JlZWZlZGppYkB5YWhvby5jb20wDAYDVR0TAQH/BAIw
ADANBgkqhkiG9w0BAQUFAAOBgQCCvBm8QYTF2UjOJF9+m1Ud3bQ7XWHPoptB9dm2BhS2SYgs
eNfebDvx4XuPiJQ/nloxgQn1A6nScuAOZ4qQi3iBD/dMd63UE1PtANcL5Mdalcd/cavAU1zj
GkP2VvNvgzSrP//Gc//E5qp1F+ebvgb36j8Jnji+cJU+xYdgEHCyRjCCAz8wggKooAMCAQIC
AQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh
cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAm
BgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0
ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h
aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV
BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQD
EyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEF
AAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B
1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79A
gAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E
CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3
dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEa
MBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7M
DaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa
C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk1
3iSx0x1G/11fZU8xggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3
dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl
ZW1haWwgSXNzdWluZyBDQQIQZe9UpHgtcStcd5KpSNcynjAJBgUrDgMCGgUAoIIBbzAYBgkq
hkiG9w0BCQMxCwYJKoZIhvcNAQcBMCMGCSqGSIb3DQEJBDEWBBQ5H+iej7XA7ZmajaH5oOWl
/v7Y5DAcBgkqhkiG9w0BCQUxDxcNMDcwNDI1MTczNDE4WjCBhQYJKwYBBAGCNxAEMXgwdjBi
MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEs
MCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGXvVKR4LXEr
XHeSqUjXMp4wgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc
VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFs
IEZyZWVtYWlsIElzc3VpbmcgQ0ECEGXvVKR4LXErXHeSqUjXMp4wDQYJKoZIhvcNAQEBBQAE
ggEACf/r7WDMAaZSVTTs49IDUgBo/RBYGdHQLjWE3a0754H8xT90iu4SM9IJ+d5bZe54KJdu
EZVmJcDHYbHpqGpnszz2Ph28LcGSKJr79cv0S+BgWxs+XJzT2RFta6j7Sb1YaASOkMyrhMsb
UexxlArDT646355jTbqQfuUx6i/jTWRMFPshxtZIwMfmGLw7CR0NlW/CYHTWPFVMv7u2JD8X
h7TEcriBaO037nZDS/PmV0mm/8z+TLrbC8fXUgXv1/h+rPt0r7WNxUXndtghsXwF+dESWUZR
5buf749TwLhVS8DMhff/a43xhODp7pUDn/EGJF6ddPDweI20ggK255y88g==
--==CelesteAttachment34788==--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3PL0x1g014668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Apr 2007 14:00:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3PL0xUd014667; Wed, 25 Apr 2007 14:00:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.174]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3PL0bJC014630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 25 Apr 2007 14:00:59 -0700 (MST) (envelope-from [e-mail])
Received: from GALATIONS (unknown [207.202.179.27]) by smtp4.pacifier.net (Postfix) with ESMTP id 11E726A9A8; Wed, 25 Apr 2007 13:58:17 -0700 (PDT)
From: "Jim Schaad" <[e-mail]>
To: "'pgut001'" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
References: <04c801c78499$837eb390$8a7c1ab0$@com> <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
Date: Wed, 25 Apr 2007 13:58:17 -0700
Message-ID: <059701c7877c$7363c000$5a2b4000$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
thread-index: AceHe+z7YyY1tRw0RKerzn5uRBIH4wAAEF6Q
Content-Language: en-us
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 I agree that would be a problem,  can you suggest an attribute which
might need to be placed there that would have this attribute?  Currently the
only one I could think of is a digest which is not needed as this is dealt
with by the encryption algorithm.

I don't need a real one, but I want to have some inkling that this MIGHT be
a real problem before trying to solve it.

Jim


> -----Original Message-----
> From: pgut001 [mailto:[e-mail]]
> Sent: Wednesday, April 25, 2007 1:55 PM
> To: [e-mail]; [e-mail];
> [e-mail]
> Cc: [e-mail]
> Subject: RE: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
> 
> "Jim Schaad" <[e-mail]> writes:
> 
> >I am having a problem seeing why having the attributes first causes a
> >problem for algorithms that want them second.  All that is needed is
> that
> >the encryption wrapper for the code understand that the attributes are
> going
> >to come in first and hold onto them until later.  This is assuming
> that the
> >encryption wrapper understands the difference between the body and the
> >attributes.
> 
> What if the attributes depend on the data being processed (as Peter
> Sylvester
> pointed out)?  By putting them first, you can't emit the first byte of
> data
> until you've processed every other byte of data.  This is why current
> CMS
> practice puts the attributes last.
> 
> Peter.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3PKssUU014163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Apr 2007 13:54:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3PKss5D014162; Wed, 25 Apr 2007 13:54:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.10.121]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3PKsXCs014118 for <[e-mail]>; Wed, 25 Apr 2007 13:54:53 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id AAA994803F3; Thu, 26 Apr 2007 08:54:32 +1200 (NZST)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7m9YOOHShI7C; Thu, 26 Apr 2007 08:54:32 +1200 (NZST)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 8A97F4803EC; Thu, 26 Apr 2007 08:54:32 +1200 (NZST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 12240128007; Thu, 26 Apr 2007 08:54:31 +1200 (NZST)
Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1HgoVU-0006Wx-00; Thu, 26 Apr 2007 08:54:32 +1200
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: RE: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
Cc: [e-mail]
In-Reply-To: <04c801c78499$837eb390$8a7c1ab0$@com>
Message-Id: <[e-mail]>
Date: Thu, 26 Apr 2007 08:54:32 +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>

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

>I am having a problem seeing why having the attributes first causes a
>problem for algorithms that want them second.  All that is needed is that
>the encryption wrapper for the code understand that the attributes are going
>to come in first and hold onto them until later.  This is assuming that the
>encryption wrapper understands the difference between the body and the
>attributes.

What if the attributes depend on the data being processed (as Peter Sylvester
pointed out)?  By putting them first, you can't emit the first byte of data
until you've processed every other byte of data.  This is why current CMS
practice puts the attributes last.

Peter.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3O38VJI057408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2007 20:08:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3O38VUa057407; Mon, 23 Apr 2007 20:08:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp108.plus.mail.mud.yahoo.com (smtp108.plus.mail.mud.yahoo.com [68.142.206.241]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l3O389Mj057346 for <[e-mail]>; Mon, 23 Apr 2007 20:08:29 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 70129 invoked from network); 24 Apr 2007 03:08:05 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-YMail-OSG:Mime-Version:In-Reply-To:References:Content-Type:Message-Id:From:Subject:Date:To:X-Mailer; b=ovARaFvnuwMPo8MhY2747Z/brHmxsizgSxrp2yorGirz2KrtWozR1hT7JxnDBbzDri0Fl9n2hnsFaSFrFSBueKElfhw4QCvabYtGvXx3QDPOWMyw2/JQy5MB1kqIbhbdXaCNWMiS0Vhce/5134J6fNJkkUQnNj0Ht3+OQWyk3pA=  ;
Received: from unknown (HELO ?192.168.1.2?) (reefedjib@67.161.111.196 with plain) by smtp108.plus.mail.mud.yahoo.com with SMTP; 24 Apr 2007 03:08:00 -0000
X-YMail-OSG: _YVRdg8VM1nUgV4eSRdIeJv.6MawaxYx7PG.Rc1S1.8AkHmmgw2bXwPaOClw8Zu9RchJrQxhMSpOXbRUlWRol2AFIiqPDmYeWBDevif2ti5hipFBxwSF7R5exR4OMQ--
Mime-Version: 1.0 (Apple Message framework v752.2)
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4--639111286; protocol="application/pkcs7-signature"
Message-Id: <[e-mail]>
From: Robert Withers <[e-mail]>
Subject: SMIME signature failures
Date: Mon, 23 Apr 2007 20:07:47 -0700
To: [e-mail]
X-Mailer: Apple Mail (2.752.2)
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>

--Apple-Mail-4--639111286
Content-Type: multipart/mixed;
	boundary=Apple-Mail-3--639111958


--Apple-Mail-3--639111958
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

I got encryption working with my SMIME implementation, but I am still  
having problems with signed email.  I have attached an email which is  
failing to be verified on my Mac Email program.  Could somebody take  
a look, try to verify it and let me know what the problem is?

thanks,
Robert


--Apple-Mail-3--639111958
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	x-mac-type=54455854;
	x-unix-mode=0644;
	x-mac-creator=522A6368;
	name=SqueakSignedEmail.text
Content-Disposition: attachment;
	filename=SqueakSignedEmail.text

X-Apparently-To: [e-mail] via 206.190.36.126; Mon, 23 Apr =
2007 20:03:18 -0700=0DX-Originating-IP: [68.142.206.242]=0D=
Authentication-Results: mta138.mail.re3.yahoo.com  from=3Dyahoo.com; =
domainkeys=3Dpass (ok)=0DReceived: from 68.142.206.242  (HELO =
smtp109.plus.mail.mud.yahoo.com) (68.142.206.242)=0D  by =
mta138.mail.re3.yahoo.com with SMTP; Mon, 23 Apr 2007 20:03:18 -0700=0D=
Received: (qmail 56301 invoked from network); 24 Apr 2007 03:03:18 -0000=0D=
DomainKey-Signature: a=3Drsa-sha1; q=3Ddns; c=3Dnofws;=0D  s=3Ds1024; =
d=3Dyahoo.com;=0D  =
h=3DReceived:X-YMail-OSG:Mime-version:Date:Subject:Content-type:To:From;=0D=
  =
b=3Dqr0T8CliPrcyZd2EYFYsSNTyU4MS2QAgUGuDlaWjgjlTLZCJ0ic811zNikd37FoMwi13G2=
3ZWy3NXIcQsvnAbcH1hGPZPr626pUAX6J64dS1yVNeEXt89yATQWN0kR8azr0DcKpun//0azFq=
MCHTRQiXz44a+hAqDPGGYBA54TI=3D  ;=0DReceived: from unknown =
(reefedjib@67.161.111.196 with login)=0D  by =
smtp109.plus.mail.mud.yahoo.com with SMTP; 24 Apr 2007 03:03:16 -0000=0D=
X-YMail-OSG: =
o6ru1G4VM1k8Bu3ZPB6a_A2dwDRrvlnmAtpehsMayRAeNWdlOf_JPKAVlMauVuBA6pUoynOpkA=
--=0DMime-version: 1.0=0DDate: Mon, 23 Apr 2007 20:03:07 -0700=0D=
Subject: Squeak Signed Email=0DContent-type: multipart/signed;=0D	=
micalg=3D"sha1";=0D	boundary=3D"=3D=3DCelesteAttachment11247=3D=3D";=0D=
	protocol=3D"application/pkcs7-signature"=0DTo: =
[e-mail]=0DFrom: [e-mail]=0D=0D=0D=0D=
--=3D=3DCelesteAttachment11247=3D=3D=0DContent-type: text/plain;=0D	=
format=3D"flowed";=0D	charset=3D"US-ASCII"=0D=
Content-transfer-encoding: 7bit=0D=0Dtest=0D--=3D=3DCelesteAttachment11247=
=3D=3D=0DContent-type: application/pkcs7-signature;=0D	name=3D"smime.p7s"=
=0DContent-transfer-encoding: base64=0DContent-disposition: attachment;=0D=
	filename=3D"smime.p7s"=0D=0D=
MIIJbwYJKoZIhvcNAQcCoIIJYDCCCVwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC=0D=
BicwggLgMIICSaADAgECAhBl71SkeC1xK1x3kqlI1zKeMA0GCSqGSIb3DQEBBQUAMGIxCzAJ=0D=
BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD=0D=
VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNzA0MTAwNTUz=0D=
MzhaFw0wODA0MDkwNTUzMzhaMEUxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx=0D=
IjAgBgkqhkiG9w0BCQEWE3JlZWZlZGppYkB5YWhvby5jb20wggEiMA0GCSqGSIb3DQEBAQUA=0D=
A4IBDwAwggEKAoIBAQCV4PrLb2Bvzi8g+y1/clI9JBEbyq1ZGDs0NvBDlutbWmQJB78pWacD=0D=
CB5hhSo/8A2f6v3NOyhkPVKWTQVXfYCrnPNWb3zBoArUrSW7T6y4Gq+RK3TvW7wUTrTm5yB2=0D=
iW9+SfAlbeKYtbKBEY+iy1Ry0852fpVBzKTXT2xyfPLF5PxGMKhk43LI/mhLb4k5Jb64X8tP=0D=
lDv6KKAa5IdMPm3tj1NNzboKy2qoY+dl06m/29S2kQlOt1d2k+qTtphVHdIFBRfTJ4uZtKJ0=0D=
7aPJJ6uonOnkIyRZbu5whqIZHp+ZNxCXU+0IPYSF5r1txQuCecf6qd9q5dMlNhyJOAMpad97=0D=
AgMBAAGjMDAuMB4GA1UdEQQXMBWBE3JlZWZlZGppYkB5YWhvby5jb20wDAYDVR0TAQH/BAIw=0D=
ADANBgkqhkiG9w0BAQUFAAOBgQCCvBm8QYTF2UjOJF9+m1Ud3bQ7XWHPoptB9dm2BhS2SYgs=0D=
eNfebDvx4XuPiJQ/nloxgQn1A6nScuAOZ4qQi3iBD/dMd63UE1PtANcL5Mdalcd/cavAU1zj=0D=
GkP2VvNvgzSrP//Gc//E5qp1F+ebvgb36j8Jnji+cJU+xYdgEHCyRjCCAz8wggKooAMCAQIC=0D=
AQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh=0D=
cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAm=0D=
BgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0=0D=
ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h=0D=
aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV=0D=
BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQD=0D=
EyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEF=0D=
AAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B=0D=
1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79A=0D=
gAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E=0D=
CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3=0D=
dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEa=0D=
MBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7M=0D=
DaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa=0D=
C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk1=0D=
3iSx0x1G/11fZU8xggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3=0D=
dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl=0D=
ZW1haWwgSXNzdWluZyBDQQIQZe9UpHgtcStcd5KpSNcynjAJBgUrDgMCGgUAoIIBbzAYBgkq=0D=
hkiG9w0BCQMxCwYJKoZIhvcNAQcBMCMGCSqGSIb3DQEJBDEWBBQyxWFdizqj60D+8/wYcFb7=0D=
9bBYvzAcBgkqhkiG9w0BCQUxDxcNMDcwNDIzMjAwMzAyWjCBhQYJKwYBBAGCNxAEMXgwdjBi=0D=
MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEs=0D=
MCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGXvVKR4LXEr=0D=
XHeSqUjXMp4wgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc=0D=
VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFs=0D=
IEZyZWVtYWlsIElzc3VpbmcgQ0ECEGXvVKR4LXErXHeSqUjXMp4wDQYJKoZIhvcNAQEBBQAE=0D=
ggEAXaotNDosKY5f4xtkVw6fXCu1Jrytp2F8sjkMjxrtgwtSmxy073RV6CkLvyYtltAsHIIw=0D=
Zlotixe/AmccpASH4dkwM79Q9ZqTIoMmjxQ+GFPDJctQybmBhwSNLlO7BbrwJxxQdGFZruts=0D=
H7JNgNLwo4mLMM0gp36rqAZOotKRAJBdinY95e9GF6k9oskSM9l871qVsLE0WYyMmsovurof=0D=
CjeJbJj0SiF29X5Pyj7O4cDHUJi9iagsjxw8G0nmnTVvWD86s0khkSvHwX8Z4pn2+dXEsZVp=0D=
7ltLzpwgnAGbT1bTKJRTbRTlY7GlTb4WxmnXur9D36MYLHAvbci4cJn1ZA=3D=3D=0D=
--=3D=3DCelesteAttachment11247=3D=3D--=0D=0D=

--Apple-Mail-3--639111958--

--Apple-Mail-4--639111286
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJzCCAuAw
ggJJoAMCAQICEGXvVKR4LXErXHeSqUjXMp4wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDQxMDA1NTMzOFoXDTA4MDQwOTA1NTMz
OFowRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEiMCAGCSqGSIb3DQEJARYTcmVl
ZmVkamliQHlhaG9vLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJXg+stvYG/O
LyD7LX9yUj0kERvKrVkYOzQ28EOW61taZAkHvylZpwMIHmGFKj/wDZ/q/c07KGQ9UpZNBVd9gKuc
81ZvfMGgCtStJbtPrLgar5ErdO9bvBROtObnIHaJb35J8CVt4pi1soERj6LLVHLTznZ+lUHMpNdP
bHJ88sXk/EYwqGTjcsj+aEtviTklvrhfy0+UO/oooBrkh0w+be2PU03NugrLaqhj52XTqb/b1LaR
CU63V3aT6pO2mFUd0gUFF9Mni5m0onTto8knq6ic6eQjJFlu7nCGohken5k3EJdT7Qg9hIXmvW3F
C4J5x/qp32rl0yU2HIk4Aylp33sCAwEAAaMwMC4wHgYDVR0RBBcwFYETcmVlZmVkamliQHlhaG9v
LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAIK8GbxBhMXZSM4kX36bVR3dtDtd
Yc+im0H12bYGFLZJiCx4195sO/Hhe4+IlD+eWjGBCfUDqdJy4A5nipCLeIEP90x3rdQTU+0A1wvk
x1qVx39xq8BTXOMaQ/ZW82+DNKs//8Zz/8TmqnUX55u+BvfqPwmeOL5wlT7Fh2AQcLJGMIIDPzCC
AqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl
cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo
MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3Rl
IFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0
aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDE
pjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J
8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+n
ttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4
oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmww
CwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODAN
BgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0
HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghO
rvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMC
WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0
ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBl71SkeC1xK1x3kqlI1zKeMAkGBSsOAwIa
BQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3MDQyNDAz
MDc0OFowIwYJKoZIhvcNAQkEMRYEFAKf6gSZG6e9vBaxcwc38wx7xeO+MIGFBgkrBgEEAYI3EAQx
eDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu
MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQZe9UpHgtcStc
d5KpSNcynjCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3
dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h
aWwgSXNzdWluZyBDQQIQZe9UpHgtcStcd5KpSNcynjANBgkqhkiG9w0BAQEFAASCAQBeW+nopyDI
2SEhMdqp8i5camKODEAcnTRvuKCjzSo4BNFVJnkYR2RotYRp8mljyGcbbVrrN6HsaAmCaVhYjf68
NZqi5A2YM5dX5ov3CBD95TOLuK4mzQ8cs/yZ9w/T4s9XYELaEgPUGQ7pAw3TUjBt+VIZpDzkGTqz
nlmvm15VDRA7aNlMD7sTP540QcY2JeuZdguMuRqEtruqaoySwZHv7k8iBBdo6BtQwr9rMDoIxr9R
1L6dtDFLvaDcZSDIXhOYTKvNFOMxCxupUfZIkCyQkFUSci3sFxk0n/6qEAjgdMYTgVLILs6rbdwY
SK/00nCaOvie/yBkCL+ISCnRYOYbAAAAAAAA

--Apple-Mail-4--639111286--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NJLgYd090736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2007 12:21:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3NJLgaK090735; Mon, 23 Apr 2007 12:21:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l3NJLKj9090666 for <[e-mail]>; Mon, 23 Apr 2007 12:21:41 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 22885 invoked by uid 0); 23 Apr 2007 19:21:13 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.66.14.186) by woodstock.binhost.com with SMTP; 23 Apr 2007 19:21:13 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 23 Apr 2007 15:04:35 -0400
To: "Jim Schaad" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: draft-ietf-smime-cms-auth and not streaming for decode
Cc: "Ietf-Smime" <[e-mail]>
In-Reply-To: <04cc01c7849b$77e71a20$67b54e60$@com>
References: <04cc01c7849b$77e71a20$67b54e60$@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>

That's why limited block sizes are very nice, but CMS does not have a 
maximum content size. The intent is for the overall hardware/software 
solution to only reveal plaintext after it is 
authenticated.  However, I recognize   a completely generic option 
with no limitations is desired.

Both AES-CCM and AES-GCM have requirements that require the integrity 
check to be performed before the plaintext is released.

Russ


At 01:02 AM 4/22/2007, Jim Schaad wrote:
>As the document is currently written, it is basically impossible to do
>streaming on a decode operation due to the following statement.
>
>The recipient MUST verify the integrity of the received content
>    before releasing any information, especially the plaintext of the
>    content.  If the integrity verification fails, the receiver MUST
>    destroy all of the plaintext of the content.
>
>My first reading of this assumed that the low-level decryption routine
>should be the one to take care of this statement.  But the real question is
>what is meant by "recipient".
>
>If one makes the statement that the low level decryption code is responsible
>for this, then making a hardware device to do the decryption becomes
>difficult unless it sets limits on the length of the data that can be
>decrypted. (The hardware would be required to buffer the contents on the
>chip until it had finished doing the validation operation.)
>
>If one makes the statement that the CMS code is responsible for this, code
>could not be said to be compliant to RFC 3610 since it has a similar
>statement in that document.
>
>I have to say that if I were to implement this code I would be very tempted
>to go ahead and do the decryption, stream the data out and return an error
>code of validation failed much as is currently done for the current
>EncryptedData and EnvelopedData structures.
>
>Why should this document handle this differently that a padding failure for
>those structures?  I propose removing that restriction.
>
>Jim



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NCZbbY041565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2007 05:35:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3NCZbHa041564; Mon, 23 Apr 2007 05:35:37 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NCZDNl041520 for <[e-mail]>; Mon, 23 Apr 2007 05:35:34 -0700 (MST) (envelope-from [e-mail])
Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA18830; Mon, 23 Apr 2007 14:40:01 +0200
Received: from frcls4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2007042314350160:157189 ; Mon, 23 Apr 2007 14:35:01 +0200 
Date: Mon, 23 Apr 2007 14:34:59 +0200
From: "Denis Pinkas" <[e-mail]>
To: "Tim Polk" <[e-mail]>
Cc: "S-MIME / IETF" <[e-mail]>, "Sam Hartman" <[e-mail]>
Subject: Re:draft-ietf-smime-escertid-04.txt
X-mailer: Foxmail 5.0 [-fr-]
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 23/04/2007 14:35:01, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 23/04/2007 14:35:05, Serialize complete at 23/04/2007 14:35:05
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by balder-227.proper.com id l3NCZbNl041559
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>

Tim,

These are your first steps as Security Area Advisor of the S/MIME WG 
and as Security Area Director.

See my comments below.

>Denis,
>
>The unaddressed Last Call comments noted by Russ were actually IETF  
>Last Call comments from the Gen-ART document review team.
>
>As I understand it, your comments were submitted during working group  
>deliberations, but working group consensus was *not* demonstrated.    

When there are two people expressing their views: one saying YES and one saying NO, 
is it possible to speak of a consensus ?

Anyway, the IETF last call level is also there to address issues that could not be solved 
at the WG  level.

I send a copy of this message to Sam Hartman, your Security Area Director co-chair, 
so that you can discuss this issue together.

>In addition, this document was explicitly scoped to address algorithm  
>agility for the esscertid structure.  The changes you propose are  
>focused on an unrelated issue - name uniqueness.  I understand that  
>name uniqueness is a hot button issue for you, but it is out of scope  
>for this particular document.

The key issue is about the following sentence which is wrong:

"The issuer/serial number pair would therefore normally be  
sufficient to identify the correct signing certificate.  (This assumes the 
same  issuer name is not re-used from the set of trust anchors) ." 

There are two solutions to solve this issue:

 1) correct the sentence (and I have made a proposal for it); or
 2) delete the sentence (fall-back solution).

Please consider these two options.

>Organizations (including ETSI) are starting to specify this structure  
>in other documents.  We have an urgent need to complete this document  
>so they have a stable reference, and I do not want to hold up the  
>train for unrelated issues. 

I am indeed well placed to know that we (at ETSI) need this document to go out.

Thanks for your understanding.

Denis

> I have asked Jim Schaad to address the  
>gen-ART comments before I forward this document to the IESG, but I  
>will not impose the same conditions for your comments.
>
>Thanks for your understanding.
>
>Tim Polk
>
>On Apr 17, 2007, at 10:06 AM, Denis Pinkas wrote:
>
>> Jim,
>>
>> draft-ietf-smime-escertid-04.txt is currently on hold, since the  
>> Security Area Director (Russ) said :
>>
>> « Several Last Call comments were received that deserve a response.
>> The author has not answered them yet.  It is clear that a revised I- 
>> D will be needed. »
>>
>> This document needs to be progressed.
>>
>> Three issues need to be solved:
>>
>> 1) In November 2006, I asked changes for the following paragraph:
>>
>>    The issuer/serial number pair is the method of identification of
>>    certificates used in [PKIXCERT].  That document imposes a  
>> restriction
>>    for certificates that the issuer distinguished name must be  
>> present.
>>    The issuer/serial number pair would therefore normally be  
>> sufficient
>>    to identify the correct signing certificate.  (This assumes the  
>> same
>>    issuer name is not re-used from the set of trust anchors.)  The
>>    issuer/serial number pair can be stored in the sid field of the
>>    SignerInfo object.  However the sid field is not covered by the
>>    signature.  In the cases where the issuer/serial number pair is not
>>    used in the sid or the issuer/serial number pair needs to be  
>> signed,
>>    it SHOULD be placed in the issuerSerial field of the ESSCertIDv2
>>    structure.
>>
>> I now propose the following:
>>
>>    That document imposes a restriction for certificates that the
>>    issuer distinguished name (DN) must be present.  If certificate
>>    issuers had unique names, then the issuer/serial number pair would
>>    be sufficient to uniquely identify the correct signing certificate.
>>    However the uniqueness of the DN of a certificate issuer cannot be
>>    guaranteed, hence two certificate issuers might use the same DN,
>>    either without knowing it or intentionally.  The issuer name
>>    contained in the issuer/serial number pair should thus only be used
>>    as an hint to identify a certificate issuer.
>>
>>    In the case where the issuer/serial number pair is not used in the
>>    sid, it SHOULD be placed in the issuerSerial field of the
>>    ESSCertIDv2 structure.
>>
>> 2) I asked to switch the second and the third paragraph of section  
>> (5.4.1.1)
>> since it is more logical to say that one information provides a hint,
>> while the second provides assurance that the certificate is the  
>> right one.
>> Hereafter is a full text replacement:
>>
>>    That document imposes a restriction for certificates that the
>>    issuer distinguished name (DN) must be present.  If certificate
>>    issuers had unique names, then the issuer/serial number pair would
>>    be sufficient to uniquely identify the correct signing certificate.
>>    However the uniqueness of the DN of a certificate issuer cannot be
>>    guaranteed, hence two certificate issuers might use the same DN,
>>    either without knowing it or intentionally.  The issuer name
>>    contained in the issuer/serial number pair should thus only be used
>>    as an hint to identify a certificate issuer.
>>
>>    In the case where the issuer/serial number pair is not used in the
>>    sid, it SHOULD be placed in the issuerSerial field of the
>>    ESSCertIDv2 structure.
>>
>>    The hash of the entire certificate allows for a verifier to check
>>    that the certificate used in the verification process was the same
>>    certificate the signer intended.  Hashes are convenient in that  
>> they
>>    are frequently used by certificate stores as a method of  
>> indexing and
>>    retrieving certificates as well.  The use of the hash is  
>> required by
>>    this structure since the detection of substituted certificates is
>>    based on the fact they would map to different hash values.
>>
>> 3) The definition of serialNumber is not fully adequate since it takes
>> the view of the issuer (“for the issuer”).  It would be more  
>> appropriate
>> to take the view from the relying party.
>>
>> The current definition is:
>>
>>    serialNumber  holds the serial number that uniquely identifies the
>>       certificate for the issuer.
>>
>> The following definition is proposed instead:
>>
>>    serialNumber  holds a serial number that is unique for each
>>       certificate issued by a given CA.
>>
>> Denis
>>

Regards,

Denis Pinkas




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3M4nCmU050562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Apr 2007 21:49:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3M4nCes050561; Sat, 21 Apr 2007 21:49:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3M4mosZ050490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Sat, 21 Apr 2007 21:49:11 -0700 (MST) (envelope-from [e-mail])
Received: from GALATIONS (unknown [207.202.179.27]) by smtp3.pacifier.net (Postfix) with ESMTP id D88BE6D926; Sat, 21 Apr 2007 21:48:47 -0700 (PDT)
From: "Jim Schaad" <[e-mail]>
To: "'Peter Gutmann'" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
Date: Sat, 21 Apr 2007 21:48:46 -0700
Message-ID: <04c801c78499$837eb390$8a7c1ab0$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AceBENeZmp//VhlGSn+gv5VMD7EgrADiHM9Q
Content-language: en-us
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 am having a problem seeing why having the attributes first causes a
problem for algorithms that want them second.  All that is needed is that
the encryption wrapper for the code understand that the attributes are going
to come in first and hold onto them until later.  This is assuming that the
encryption wrapper understands the difference between the body and the
attributes.

Jim


> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]] On Behalf Of Peter Gutmann
> Sent: Tuesday, April 17, 2007 9:52 AM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: Re: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
> 
> 
> Russ Housley <[e-mail]> writes:
> 
> >The difference is the swapped order of authAttrs and
> authEncryptedContentInfo.
> 
> Yup.  That is, I'm not saying they absolutely have to be last, but that
> forcing them to be first rules out the use of some algorithms (and vice
> versa).
> 
> >The best placement seems to depend on the authenticated encryption
> >modes that one thinks will become most popular in the Internet over
> >time.  We each have examples that support our preferred placement.  I
> >do not know which of us has the better crystal ball.
> 
> Is there any way to put money both ways?
> 
> Peter.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3KI8o7r038724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Apr 2007 11:08:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3KI8ool038723; Fri, 20 Apr 2007 11:08:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3KI8NX0038392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 20 Apr 2007 11:08:45 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.15.166] (bethany.ncsl.nist.gov [129.6.52.15]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id l3KI7bjr012300; Fri, 20 Apr 2007 14:07:58 -0400
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Cc: "S-MIME / IETF" <[e-mail]>, "Tim Polk" <[e-mail]>
From: Tim Polk <[e-mail]>
Subject: Re: draft-ietf-smime-escertid-04.txt
Date: Fri, 20 Apr 2007 14:07:37 -0400
To: Denis Pinkas <[e-mail]>
X-Mailer: Apple Mail (2.752.2)
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l3KI8jWx038662
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>

Denis,

The unaddressed Last Call comments noted by Russ were actually IETF  
Last Call comments from the Gen-ART document review team.

As I understand it, your comments were submitted during working group  
deliberations, but working group consensus was *not* demonstrated.    
In addition, this document was explicitly scoped to address algorithm  
agility for the esscertid structure.  The changes you propose are  
focused on an unrelated issue - name uniqueness.  I understand that  
name uniqueness is a hot button issue for you, but it is out of scope  
for this particular document.

Organizations (including ETSI) are starting to specify this structure  
in other documents.  We have an urgent need to complete this document  
so they have a stable reference, and I do not want to hold up the  
train for unrelated issues.  I have asked Jim Schaad to address the  
gen-ART comments before I forward this document to the IESG, but I  
will not impose the same conditions for your comments.

Thanks for your understanding.

Tim Polk

On Apr 17, 2007, at 10:06 AM, Denis Pinkas wrote:

> Jim,
>
> draft-ietf-smime-escertid-04.txt is currently on hold, since the  
> Security Area Director (Russ) said :
>
> « Several Last Call comments were received that deserve a response.
> The author has not answered them yet.  It is clear that a revised I- 
> D will be needed. »
>
> This document needs to be progressed.
>
> Three issues need to be solved:
>
> 1) In November 2006, I asked changes for the following paragraph:
>
>    The issuer/serial number pair is the method of identification of
>    certificates used in [PKIXCERT].  That document imposes a  
> restriction
>    for certificates that the issuer distinguished name must be  
> present.
>    The issuer/serial number pair would therefore normally be  
> sufficient
>    to identify the correct signing certificate.  (This assumes the  
> same
>    issuer name is not re-used from the set of trust anchors.)  The
>    issuer/serial number pair can be stored in the sid field of the
>    SignerInfo object.  However the sid field is not covered by the
>    signature.  In the cases where the issuer/serial number pair is not
>    used in the sid or the issuer/serial number pair needs to be  
> signed,
>    it SHOULD be placed in the issuerSerial field of the ESSCertIDv2
>    structure.
>
> I now propose the following:
>
>    That document imposes a restriction for certificates that the
>    issuer distinguished name (DN) must be present.  If certificate
>    issuers had unique names, then the issuer/serial number pair would
>    be sufficient to uniquely identify the correct signing certificate.
>    However the uniqueness of the DN of a certificate issuer cannot be
>    guaranteed, hence two certificate issuers might use the same DN,
>    either without knowing it or intentionally.  The issuer name
>    contained in the issuer/serial number pair should thus only be used
>    as an hint to identify a certificate issuer.
>
>    In the case where the issuer/serial number pair is not used in the
>    sid, it SHOULD be placed in the issuerSerial field of the
>    ESSCertIDv2 structure.
>
> 2) I asked to switch the second and the third paragraph of section  
> (5.4.1.1)
> since it is more logical to say that one information provides a hint,
> while the second provides assurance that the certificate is the  
> right one.
> Hereafter is a full text replacement:
>
>    That document imposes a restriction for certificates that the
>    issuer distinguished name (DN) must be present.  If certificate
>    issuers had unique names, then the issuer/serial number pair would
>    be sufficient to uniquely identify the correct signing certificate.
>    However the uniqueness of the DN of a certificate issuer cannot be
>    guaranteed, hence two certificate issuers might use the same DN,
>    either without knowing it or intentionally.  The issuer name
>    contained in the issuer/serial number pair should thus only be used
>    as an hint to identify a certificate issuer.
>
>    In the case where the issuer/serial number pair is not used in the
>    sid, it SHOULD be placed in the issuerSerial field of the
>    ESSCertIDv2 structure.
>
>    The hash of the entire certificate allows for a verifier to check
>    that the certificate used in the verification process was the same
>    certificate the signer intended.  Hashes are convenient in that  
> they
>    are frequently used by certificate stores as a method of  
> indexing and
>    retrieving certificates as well.  The use of the hash is  
> required by
>    this structure since the detection of substituted certificates is
>    based on the fact they would map to different hash values.
>
> 3) The definition of serialNumber is not fully adequate since it takes
> the view of the issuer (“for the issuer”).  It would be more  
> appropriate
> to take the view from the relying party.
>
> The current definition is:
>
>    serialNumber  holds the serial number that uniquely identifies the
>       certificate for the issuer.
>
> The following definition is proposed instead:
>
>    serialNumber  holds a serial number that is unique for each
>       certificate issued by a given CA.
>
> Denis
>




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3JJoNSH043030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Apr 2007 12:50:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3JJoN90043029; Thu, 19 Apr 2007 12:50:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ns3.neustar.com (ns3.neustar.com [156.154.24.138]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3JJo3Pp042953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 19 Apr 2007 12:50:23 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 79A041773F; Thu, 19 Apr 2007 19:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hecdm-0007wk-8d; Thu, 19 Apr 2007 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-escertid-05.txt 
Message-Id: <[e-mail]>
Date: Thu, 19 Apr 2007 15:50:02 -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		: ESS Update: Adding CertID Algorithm Agility
	Author(s)	: J. Schaad
	Filename	: draft-ietf-smime-escertid-05.txt
	Pages		: 19
	Date		: 2007-4-19
	
In the original Enhanced Security Services for S/MIME document (RFC
   2634), a structure for cryptographically linking the certificate to
   be used in validation with the signature was introduced, this
   structure was hardwired to use SHA-1.  This document allows for the
   structure to have algorithm agility and defines a new attribute for
   this purpose.

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

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-escertid-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-escertid-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-escertid-05.txt

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

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

--OtherAccess--

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3I9fQMR060748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Apr 2007 02:41:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3I9fQQW060747; Wed, 18 Apr 2007 02:41:26 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ganymede.on-x.com (ganymede.on-x.com [194.51.68.3]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3I9f4bB060732 for <[e-mail]>; Wed, 18 Apr 2007 02:41:25 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (ganymede [127.0.0.1]) by ganymede.on-x.com (Postfix) with ESMTP id 4942420; Wed, 18 Apr 2007 11:40:57 +0200 (CEST)
Received: from ganymede.on-x.com ([127.0.0.1]) by localhost (ganymede.on-x.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01316-08; Wed, 18 Apr 2007 11:40:55 +0200 (CEST)
Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id 2BBA0F; Wed, 18 Apr 2007 11:40:55 +0200 (CEST)
Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2007041811405415:207388 ; Wed, 18 Apr 2007 11:40:54 +0200 
Message-ID: <[e-mail]>
Date: Wed, 18 Apr 2007 11:38:37 +0200
From: Peter Sylvester <[e-mail]>
User-Agent: Thunderbird 1.5.0.9 (X11/20061206)
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11  |July 24, 2002) at 04/18/2007 11:40:54 AM, Serialize by Router on vinea/ON-X(Release 5.0.11  |July 24, 2002) at 04/18/2007 11:40:54 AM, Serialize complete at 04/18/2007 11:40:54 AM
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070102040406000602010409"
X-Virus-Scanned: by amavisd-new at on-x.com
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 is a cryptographically signed message in MIME format.

--------------ms070102040406000602010409
Content-Type: multipart/alternative;
 boundary="------------050505090309050908050104"

This is a multi-part message in MIME format.
--------------050505090309050908050104
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I mentioned in a previous mail:

Awaht about TWO instances of authenticated attributes.

- the ones that come after can be created/validated in the same way
  as with signedData or authenticatedData, and can, in particular,
  depend on the encapsulatedData.

- If there is something that needs to be added before the data,
  do this independantly. And if this depends on the recipients,
  one should put this in the recipientinfo, ...

Peter

Peter Gutmann wrote:
> Russ Housley <[e-mail]> writes:
>   
>>>> On the second item, I disagree.  The authenticated attributes are 
>>>>         
>>> handled the
>>>       
>>>> same as in AuthenticatedData.
>>>>         
>>> They're placed before the data, not after it, which is unlike any other use of
>>> authenticated attributes in any CMS PDU.  As both Peter Sylvester and myself
>>> have already pointed out, this makes one-pass/streaming processing impossible.
>>>       
>> As I already said in response, AES-CCM and AES-GCM both require the 
>> processing of the "additional authenticated data" (the authenticated 
>> attributes in this structure) prior to the processing of the payload 
>> (the encapsulated content in this structure).  Thus, the only way 
>> that one-pass processing can be accomplished with these authenticated 
>> encryption modes is for the authenticated attributes to appear first.
>>     
>
> Hmm, we already went through this one in private mail... what you're doing is 
> tying the data format to an artefact of a particular crypto algorithm.  Your 
> algorithm choice happens to put the authenticated data first because it was 
> designed for use with 802.11 rather than CMS, but there are other algorithms 
> like CWC that put them last as per normal CMS usage.  By arbitrarily putting 
> the authenticated attributes first, you're forcing implementors to use a 
> small subset of 802.11-optimised algorithms for AuthenticatedData rather 
> than making it a general-purpose format, and more worryingly making it 
> impossible to create a one-pass implementation because with 802.11, fixed 
> authenticated headers at the start, and short data packets it's not a concern, 
> but with CMS and arbitrary-length data it is.
>
> In order to make this general-purpose, you'd need some provision for having
> the auth.attributes either before or after, depending on the algorithm being
> used, or some similar way to handle the quirks of different algorithms.
>
> Peter.
>
>
>   


--------------050505090309050908050104
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
I mentioned in a previous mail:<br>
<br>
Awaht about TWO instances of authenticated attributes.<br>
<br>
- the ones that come after can be created/validated in the same way<br>
&nbsp; as with signedData or authenticatedData, and can, in particular,<br>
&nbsp; depend on the encapsulatedData.<br>
<br>
- If there is something that needs to be added before the data,<br>
&nbsp; do this independantly. And if this depends on the recipients,<br>
&nbsp; one should put this in the recipientinfo, ...<br>
<br>
Peter<br>
<br>
Peter Gutmann wrote:
<blockquote cite="[e-mail]"
 type="cite">
  <pre wrap="">Russ Housley <a class="moz-txt-link-rfc2396E" href="mailto:[e-mail]">&lt;[e-mail]&gt;</a> writes:
  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <blockquote type="cite">
        <pre wrap="">On the second item, I disagree.  The authenticated attributes are 
        </pre>
      </blockquote>
      <pre wrap="">handled the
      </pre>
      <blockquote type="cite">
        <pre wrap="">same as in AuthenticatedData.
        </pre>
      </blockquote>
      <pre wrap="">They're placed before the data, not after it, which is unlike any other use of
authenticated attributes in any CMS PDU.  As both Peter Sylvester and myself
have already pointed out, this makes one-pass/streaming processing impossible.
      </pre>
    </blockquote>
    <pre wrap="">As I already said in response, AES-CCM and AES-GCM both require the 
processing of the "additional authenticated data" (the authenticated 
attributes in this structure) prior to the processing of the payload 
(the encapsulated content in this structure).  Thus, the only way 
that one-pass processing can be accomplished with these authenticated 
encryption modes is for the authenticated attributes to appear first.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Hmm, we already went through this one in private mail... what you're doing is 
tying the data format to an artefact of a particular crypto algorithm.  Your 
algorithm choice happens to put the authenticated data first because it was 
designed for use with 802.11 rather than CMS, but there are other algorithms 
like CWC that put them last as per normal CMS usage.  By arbitrarily putting 
the authenticated attributes first, you're forcing implementors to use a 
small subset of 802.11-optimised algorithms for AuthenticatedData rather 
than making it a general-purpose format, and more worryingly making it 
impossible to create a one-pass implementation because with 802.11, fixed 
authenticated headers at the start, and short data packets it's not a concern, 
but with CMS and arbitrary-length data it is.

In order to make this general-purpose, you'd need some provision for having
the auth.attributes either before or after, depending on the algorithm being
used, or some similar way to handle the quirks of different algorithms.

Peter.


  </pre>
</blockquote>
<br>
</body>
</html>

--------------050505090309050908050104--

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC
BHIwggLfoAMCAQICBgqvijKA3jANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G
A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs
UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNzAzMjYxMDM3MDNaFw0wOTA2MDMxMDM3MDNaMHAx
CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ
S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu
ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPB7ZSfmYsUuVIV0W2izxb1Zyvr6ZJ
IjPiqRMs77dbEQhQ6FZhhUSuABxxc8NjZvyPMRo0uuT0iVpRDktb0fWPTx3m9qTfdqrhWg2c
IOBKNbNQr8NogDJvG1AxRx4q9SXKZCVpZCoHu3fz2Rfji1kL7l597+7qBEsFd9IyvRaexQID
AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5
MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT
VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD
VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F
ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSZjq81LuJmsiiu1Yt/ezwCiUQSQTAfBgNV
HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA
A4IBfAAUq5MJ3gXhdKDpOm0ascDE9e1iMo0RQ24ujkc9IrFXhAJNS+3eNwcJEieU2vgZTsGb
zKeBZom1zVOFoh73VIRP6T08j4dDlndpDYZbxD20KzFt9zX6gV8IgR2zkkZXLQRbLyW16kw8
oFe3s//p1csCkCPAlZv1rZQYR5Psm0A1aiOiuSHhWUmgfAJxmIgfbmKtS3WpsUZVBuLQpThN
rWjLRAqJKYA++++qqo3ujqAAzJLe+MHrX5dai7+n6WBfV4qo1uDArR7XbmgVpV/EdPA75XRi
XEedLgbFDawJ9nAMN6WfL/NG6GZkEa7mZ7sH/gG34y21nq4w4mAAxn9wz7mDKMsEbJMZ5VlJ
TOp0g6TdYqGjNoc/rQg7pqjcRChVitwd1Rl8O31+bIdNSpv4UReNMDcffRQrt+pF1FxR4q6q
M9YLJU8NThx/89Mf/WF7fzrgVlsNJ78D9nJu0EhKes/9EX2qpIcHUfk/izOj8lCc1ksFgXpd
UEchE0DcMIIEcjCCAt+gAwIBAgIGCq+KMoDeMA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT
AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV
BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA3MDMyNjEwMzcwM1oXDTA5MDYwMzEw
MzcwM1owcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp
Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA
ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8HtlJ+ZixS5UhXRbaL
PFvVnK+vpkkiM+KpEyzvt1sRCFDoVmGFRK4AHHFzw2Nm/I8xGjS65PSJWlEOS1vR9Y9PHeb2
pN92quFaDZwg4Eo1s1Cvw2iAMm8bUDFHHir1JcpkJWlkKge7d/PZF+OLWQvuXn3v7uoESwV3
0jK9Fp7FAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl
Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl
ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF
BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F
ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJmOrzUu4mayKK7Vi397PAKJ
RBJBMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI
hvcNAQEFBQADggF8ABSrkwneBeF0oOk6bRqxwMT17WIyjRFDbi6ORz0isVeEAk1L7d43BwkS
J5Ta+BlOwZvMp4FmibXNU4WiHvdUhE/pPTyPh0OWd2kNhlvEPbQrMW33NfqBXwiBHbOSRlct
BFsvJbXqTDygV7ez/+nVywKQI8CVm/WtlBhHk+ybQDVqI6K5IeFZSaB8AnGYiB9uYq1Ldamx
RlUG4tClOE2taMtECokpgD7776qqje6OoADMkt74wetfl1qLv6fpYF9XiqjW4MCtHtduaBWl
X8R08DvldGJcR50uBsUNrAn2cAw3pZ8v80boZmQRruZnuwf+AbfjLbWerjDiYADGf3DPuYMo
ywRskxnlWUlM6nSDpN1ioaM2hz+tCDumqNxEKFWK3B3VGXw7fX5sh01Km/hRF40wNx99FCu3
6kXUXFHirqoz1gslTw1OHH/z0x/9YXt/OuBWWw0nvwP2cm7QSEp6z/0RfaqkhwdR+T+LM6Py
UJzWSwWBel1QRyETQNwwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL
MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL
STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0
MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj
ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI
hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M
ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe
1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt
qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd
UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH
pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS
cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB
CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0
dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C
AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV
HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3
UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy
4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz
QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u
US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj
PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq
Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf
Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y
rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6
PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL
d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18
k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg
d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD
VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ
S0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwNDE4MDkzODM3WjAjBgkqhkiG9w0B
CQQxFgQU3EpIhfp1U82g4+FoJia5fqZ1Sq0wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D
BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC
ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY
MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy
c0dFTgIGCq+KMoDeMHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE
ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ
IEVkZWxXZWIgUGVyc0dFTgIGCq+KMoDeMA0GCSqGSIb3DQEBAQUABIGAT8qiiX8dxglHbUwq
lNT6nhDxRBB0fhbFdPKplFShz9Lte+G0qx2uBSgojA5RjHPxbVqkDTI1oL6jYXSIFSAiPRaN
0MhoBU/1ZOfTI90G8g79tNo9DkdTLfYCWJk95Xo56jbuUsY/r5CosuKqDGc/utsu81k6o8g2
0lbpVbuEeiQAAAAAAAA=
--------------ms070102040406000602010409--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3HL987O028251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Apr 2007 14:09:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3HL98FK028250; Tue, 17 Apr 2007 14:09:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from nit.isi.edu (nit.isi.edu [128.9.160.116]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3HL8hNw028195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 17 Apr 2007 14:09:06 -0700 (MST) (envelope-from [e-mail])
Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id l3HL8fMd007689; Tue, 17 Apr 2007 14:08:41 -0700
Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id l3HL8fbg007688; Tue, 17 Apr 2007 14:08:41 -0700
Date: Tue, 17 Apr 2007 14:08:41 -0700
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject:  RFC 4853 on Cryptographic Message Syntax (CMS) Multiple Signer Clarification
From: [e-mail]
Cc: [e-mail], [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>

A new Request for Comments is now available in online RFC libraries.

        
        RFC 4853

        Title:      Cryptographic Message Syntax (CMS) Multiple 
                    Signer Clarification 
        Author:     R. Housley
        Status:     Standards Track
        Date:       April 2007
        Mailbox:    [e-mail]
        Pages:      5
        Characters: 10146
        Updates:    RFC3852
        See-Also:   

        I-D Tag:    draft-ietf-smime-cms-mult-sign-03.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4853.txt

This document updates the Cryptographic Message Syntax (CMS), which is
published in RFC 3852.  This document clarifies the proper handling of
the SignedData protected content type when more than one digital
signature is present.  [STANDARDS TRACK]

This document is a product of the S/MIME Mail Security
Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and 
suggestions for improvements.Please refer to the current edition of the 
Internet Official Protocol Standards (STD 1) for the standardization
state and status of this protocol.  Distribution of this memo is 
unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 

help: ways_to_get_rfcs. For example:

        To: [e-mail]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


The RFC Editor Team
USC/Information Sciences Institute

...




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3HGqPIf072828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Apr 2007 09:52:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3HGqPSX072827; Tue, 17 Apr 2007 09:52:25 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.10.122]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3HGq3wI072760 for <[e-mail]>; Tue, 17 Apr 2007 09:52:24 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 4FE4C1833B; Wed, 18 Apr 2007 04:52:03 +1200 (NZST)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GgQYHCkhcKKU; Wed, 18 Apr 2007 04:52:03 +1200 (NZST)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 345C818324; Wed, 18 Apr 2007 04:52:03 +1200 (NZST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id A8185514010; Wed, 18 Apr 2007 04:52:00 +1200 (NZST)
Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1HdquZ-0007ge-00; Wed, 18 Apr 2007 04:52:11 +1200
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Date: Wed, 18 Apr 2007 04:52:11 +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>

Russ Housley <[e-mail]> writes:

>The difference is the swapped order of authAttrs and authEncryptedContentInfo.

Yup.  That is, I'm not saying they absolutely have to be last, but that
forcing them to be first rules out the use of some algorithms (and vice versa).

>The best placement seems to depend on the authenticated encryption 
>modes that one thinks will become most popular in the Internet over 
>time.  We each have examples that support our preferred placement.  I 
>do not know which of us has the better crystal ball.

Is there any way to put money both ways?  

Peter.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3HGmn9S072164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Apr 2007 09:48:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3HGmnaH072163; Tue, 17 Apr 2007 09:48:49 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp101.plus.mail.mud.yahoo.com (smtp101.plus.mail.mud.yahoo.com [68.142.206.234]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l3HGmSJi072097 for <[e-mail]>; Tue, 17 Apr 2007 09:48:48 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 57912 invoked from network); 17 Apr 2007 16:48:23 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-YMail-OSG:Mime-Version:To:Message-Id:Content-Type:From:Subject:Date:X-Mailer; b=IG5UghPnRogpHWCF25/EtyCgCE4l0M2hQPCxMZJzuxRYXY+CwucFIUuvYanIj8GZn/hguckmuAOjviU6owePFaahszZU7085GZHYnadfIbvLiCXYrUSOui6BBeTzefh3KgLsxe+xRjsA6HySNBKSyl6pNmOwLQNiq0jxYPKXhSU=  ;
Received: from unknown (HELO ?192.168.1.2?) (reefedjib@67.161.111.196 with plain) by smtp101.plus.mail.mud.yahoo.com with SMTP; 17 Apr 2007 16:48:23 -0000
X-YMail-OSG: I4oeXu8VM1mSCcpK2tsJt4mVCZqtmcftHamtYURv7HMFMVG8ALcO.93yKrQaXEim0_GXhFm91A--
Mime-Version: 1.0 (Apple Message framework v752.2)
To: [e-mail]
Message-Id: <[e-mail]>
Content-Type: multipart/mixed; boundary=Apple-Mail-45-952806196
From: Robert Withers <[e-mail]>
Subject: my buggy SMIME implementation
Date: Tue, 17 Apr 2007 09:48:21 -0700
X-Mailer: Apple Mail (2.752.2)
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>

--Apple-Mail-45-952806196
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

I realize this list is for the purpose of discussing the SMIME  
specification and that my implementation question is not pertinent.   
Nevertheless, I hope some kind soul will have the means to assist me  
in figuring out where my implementation is failing.  I could think of  
no other place to go ask this question.

I have written an SMIME client in Squeak, a programming environment.   
I got the CMS put together and I can read signed and encrypted  
messages sent by my Mac Email client.  When I generate signed and  
encrypted emails, however, the Mac Email client cannot read them.  I  
am using the same Certificate and PrivateKey in both email programs,  
so I know that the actual encryption should work, since the Mac email  
decrypts on both the Mac email client and the Squeak client.   
Furthermore, the Mac Email client only tells me that it failed to  
decrypt or failed to verify signature, but no other details.  Is  
there an SMIME Client that runs on the Mac, which could tell me  
exactly where my encrypted msg is bogus?

I have attached a sample encrypted email from both the Mac and  
Squeak.  Without the certs and the privateKey, could someone look at  
the CMS structure and tell me why my Squeak email is failing to decrypt?

Many thanks,
Robert


--Apple-Mail-45-952806196
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	x-mac-type=54455854;
	x-unix-mode=0644;
	x-mac-creator=522A6368;
	name=MacEncryptedEmail.txt
Content-Disposition: attachment;
	filename=MacEncryptedEmail.txt

Content-Type: application/pkcs7-mime; name=3Dsmime.p7m; =
smime-type=3Denveloped-data=0DMessage-Id: =
<[e-mail]>=0DContent-Disposition: =
attachment; filename=3Dsmime.p7m=0DContent-Transfer-Encoding: base64=0D=
From: Robert Withers <[e-mail]>=0DSubject: Mac Encrypted =
Email=0DDate: Tue, 17 Apr 2007 08:58:37 -0700=0DTo: Robert Withers =
<[e-mail]>=0DX-Mailer: Apple Mail (2.752.2)=0D=0D=
MIAGCSqGSIb3DQEHA6CAMIACAQAxggGSMIIBjgIBADB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQ=
QK=0D=
ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYW=
wg=0D=
RnJlZW1haWwgSXNzdWluZyBDQQIQZe9UpHgtcStcd5KpSNcynjANBgkqhkiG9w0BAQEFAASCAQ=
CP=0D=
QSgH+ZXEUq1CjsS1fiyCY9BrQOkUWvT8BUe6wQaxEq2RE8Ei5TDnYIoEtY+Zip4GJEGlS1eJn7=
4/=0D=
KpRqzPPJJS/VQr5hUbiwc+OwLKYp3aP+pADU4+VyoR74ih55/IoRFactPfJ+b+auKthbhSW220=
2c=0D=
V5iCy/BUlNbt+cIXKONfTFRaJSGElnYZYdV/qlA/1/ZTJ/PeznuwBQYX9+Pto0H2MHUtJtss2j=
nm=0D=
biTlLWlQw9Ut1GHL++eF+4kOPy6ufLIQxY3gc8RQ5TltAGJ2RGbbn6dca7+viaT3S6hwExPsnl=
xY=0D=
CGcXoM1xGmx0KazVmrhXzWyFegOUhUq1yg4BMIAGCSqGSIb3DQEHATAUBggqhkiG9w0DBwQIUu=
5k=0D=
bzileMaggAQYBKgw+ERLm3LsMpmSq0vGcRvO7RgHnQniBAj3uZyqQKFhFAQYbwzAT54TMijmoo=
rT=0D=
L2EDrtQLEhSyQ2znBBC8MhrBpHZHa4a1NCs6KI3CBAiETOqQHpBjrgQIcZH6JSfvAJsECNYgZW=
H1=0DyQx+BAj/Edtajdq3dAAAAAAAAAAAAAA=3D=0D=

--Apple-Mail-45-952806196
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	x-mac-type=54455854;
	x-unix-mode=0644;
	x-mac-creator=522A6368;
	name=SqueakEncryptedEmail.txt
Content-Disposition: attachment;
	filename=SqueakEncryptedEmail.txt

To: [e-mail]=0DMime-version: 1.0=0DContent-disposition: =
attachment;filename=3Dsmime.p7m=0DSubject: Squeak Encrypted Email=0D=
Content-type: =
application/pkcs7-mime;name=3Dsmime.p7m;smime-type=3Denveloped-data=0D=
Content-transfer-encoding: base64=0DFrom: [e-mail]=0D=0D=
MIICMgYJKoZIhvcNAQcDoIICIzCCAh8CAQAxggGSMIIBjgIBADB2MGIxCzAJBgNVBAYTAlpB=0D=
MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3=0D=
dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQZe9UpHgtcStcd5KpSNcynjANBgkq=0D=
hkiG9w0BAQEFAASCAQB0tZ79mNw7KsFQYvzXF+ycVZh8UwiQoD0v0B0fwUR0PLuiTbbrYaWD=0D=
jNXP83ylBy9bZF3BtZAKV2Y0PPk2kezGYnxQ5tq309Li/3VuX2Cqqsvckt2t2Ioy0HH/ID/w=0D=
fnfc7y/J6habhWp6AhkFUZnOtRMBlYjeWszPi0oA6DvMf6eCH7yVDCniYtst7l5vWsRkKU6j=0D=
4ylISN16YgOib5C/H0u1U99dj+l3d3JqTem+QGFWX9PNiF8hyzZu/05KAMJ7DXhJwyPRs4pd=0D=
SQbR2ZnHBcZ9mGwsbgliPhwEmVOiyolN3SqbM3Odhet7FTr8EGeHH7IaXxQSG5KARaK+TIp/=0D=
MIGDBgkqhkiG9w0BBwEwFAYIKoZIhvcNAwcECNZ8STx2LkUZgGBzXZzDibIfxxPU7i1AJii+=0D=
K2VqvVzvlRpVG3BYPjmzGKXspyribUW1bc+ELesaYzQwambWIv1Rc9VlvvAaKqoMK7xt/86k=0D=
+aP2YcFKK3rzMRmBOl8Lt0tk4N8YJ9rK7Fo=3D=0D=

--Apple-Mail-45-952806196--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3HFuAdx062340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Apr 2007 08:56:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3HFuAMK062339; Tue, 17 Apr 2007 08:56:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l3HFu9jA062333 for <[e-mail]>; Tue, 17 Apr 2007 08:56:10 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 28202 invoked by uid 0); 17 Apr 2007 15:56:05 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (129.6.255.11) by woodstock.binhost.com with SMTP; 17 Apr 2007 15:56:05 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 17 Apr 2007 11:55:56 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[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:

CURRENT DOCUMENT:

       AuthEnvelopedData ::= SEQUENCE {
         version CMSVersion,
         originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
         recipientInfos RecipientInfos,
         authAttrs [1] IMPLICIT AuthAttributes OPTIONAL,
         authEncryptedContentInfo EncryptedContentInfo,
         mac MessageAuthenticationCode,
         unauthAttrs [2] IMPLICIT UnauthAttributes OPTIONAL }

WHAT I THINK YOU ARE ADVOCATING:

       AuthEnvelopedData ::= SEQUENCE {
         version CMSVersion,
         originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
         recipientInfos RecipientInfos,
         authEncryptedContentInfo EncryptedContentInfo,
         authAttrs [1] IMPLICIT AuthAttributes OPTIONAL,
         mac MessageAuthenticationCode,
         unauthAttrs [2] IMPLICIT UnauthAttributes OPTIONAL }

The difference is the swapped order of authAttrs and authEncryptedContentInfo.

The best placement seems to depend on the authenticated encryption 
modes that one thinks will become most popular in the Internet over 
time.  We each have examples that support our preferred placement.  I 
do not know which of us has the better crystal ball.

I do agree that the placement that you advocate has the same ordering 
as AuthenicatedData.

Russ


> >> >On the second item, I disagree.  The authenticated attributes 
> are handled the
> >> >same as in AuthenticatedData.
> >>
> >>They're placed before the data, not after it, which is unlike any 
> other use of
> >>authenticated attributes in any CMS PDU.  As both Peter Sylvester 
> and myself
> >>have already pointed out, this makes one-pass/streaming 
> processing impossible.
> >
> >As I already said in response, AES-CCM and AES-GCM both require the
> >processing of the "additional authenticated data" (the authenticated
> >attributes in this structure) prior to the processing of the payload
> >(the encapsulated content in this structure).  Thus, the only way
> >that one-pass processing can be accomplished with these authenticated
> >encryption modes is for the authenticated attributes to appear first.
>
>Hmm, we already went through this one in private mail... what you're doing is
>tying the data format to an artefact of a particular crypto algorithm.  Your
>algorithm choice happens to put the authenticated data first because it was
>designed for use with 802.11 rather than CMS, but there are other algorithms
>like CWC that put them last as per normal CMS usage.  By arbitrarily putting
>the authenticated attributes first, you're forcing implementors to use a
>small subset of 802.11-optimised algorithms for AuthenticatedData rather
>than making it a general-purpose format, and more worryingly making it
>impossible to create a one-pass implementation because with 802.11, fixed
>authenticated headers at the start, and short data packets it's not 
>a concern,
>but with CMS and arbitrary-length data it is.
>
>In order to make this general-purpose, you'd need some provision for having
>the auth.attributes either before or after, depending on the algorithm being
>used, or some similar way to handle the quirks of different algorithms.
>
>Peter.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3HEvkuI053029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Apr 2007 07:57:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3HEvklV053028; Tue, 17 Apr 2007 07:57:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.10.121]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3HEvMG6052992 for <[e-mail]>; Tue, 17 Apr 2007 07:57:45 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 1BDA4480387; Wed, 18 Apr 2007 02:57:22 +1200 (NZST)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFQPBIPVsOmd; Wed, 18 Apr 2007 02:57:22 +1200 (NZST)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id F409A480338; Wed, 18 Apr 2007 02:57:21 +1200 (NZST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 418C8514010; Wed, 18 Apr 2007 02:57:21 +1200 (NZST)
Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1Hdp7a-0005eE-00; Wed, 18 Apr 2007 02:57:30 +1200
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Date: Wed, 18 Apr 2007 02:57:30 +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>

Russ Housley <[e-mail]> writes:
>> >On the second item, I disagree.  The authenticated attributes are 
>> handled the
>> >same as in AuthenticatedData.
>>
>>They're placed before the data, not after it, which is unlike any other use of
>>authenticated attributes in any CMS PDU.  As both Peter Sylvester and myself
>>have already pointed out, this makes one-pass/streaming processing impossible.
>
>As I already said in response, AES-CCM and AES-GCM both require the 
>processing of the "additional authenticated data" (the authenticated 
>attributes in this structure) prior to the processing of the payload 
>(the encapsulated content in this structure).  Thus, the only way 
>that one-pass processing can be accomplished with these authenticated 
>encryption modes is for the authenticated attributes to appear first.

Hmm, we already went through this one in private mail... what you're doing is 
tying the data format to an artefact of a particular crypto algorithm.  Your 
algorithm choice happens to put the authenticated data first because it was 
designed for use with 802.11 rather than CMS, but there are other algorithms 
like CWC that put them last as per normal CMS usage.  By arbitrarily putting 
the authenticated attributes first, you're forcing implementors to use a 
small subset of 802.11-optimised algorithms for AuthenticatedData rather 
than making it a general-purpose format, and more worryingly making it 
impossible to create a one-pass implementation because with 802.11, fixed 
authenticated headers at the start, and short data packets it's not a concern, 
but with CMS and arbitrary-length data it is.

In order to make this general-purpose, you'd need some provision for having
the auth.attributes either before or after, depending on the algorithm being
used, or some similar way to handle the quirks of different algorithms.

Peter.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3HE6Z90045486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Apr 2007 07:06:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3HE6ZGm045485; Tue, 17 Apr 2007 07:06:35 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3HE6ClX045413 for <[e-mail]>; Tue, 17 Apr 2007 07:06:33 -0700 (MST) (envelope-from [e-mail])
Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA33652; Tue, 17 Apr 2007 16:10:59 +0200
Received: from frcls4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2007041716064124:15924 ; Tue, 17 Apr 2007 16:06:41 +0200 
Date: Tue, 17 Apr 2007 16:06:38 +0200
From: "Denis Pinkas" <[e-mail]>
To: "S-MIME / IETF" <[e-mail]>
Cc: "Tim Polk" <[e-mail]>
Subject: draft-ietf-smime-escertid-04.txt
X-mailer: Foxmail 5.0 [-fr-]
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 17/04/2007 16:06:41, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 17/04/2007 16:06:47, Serialize complete at 17/04/2007 16:06:47
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by balder-227.proper.com id l3HE6ZlX045477
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,

draft-ietf-smime-escertid-04.txt is currently on hold, since the Security Area Director (Russ) said :

« Several Last Call comments were received that deserve a response.  
The author has not answered them yet.  It is clear that a revised I-D will be needed. »

This document needs to be progressed.

Three issues need to be solved:

1) In November 2006, I asked changes for the following paragraph:

   The issuer/serial number pair is the method of identification of
   certificates used in [PKIXCERT].  That document imposes a restriction
   for certificates that the issuer distinguished name must be present.
   The issuer/serial number pair would therefore normally be sufficient
   to identify the correct signing certificate.  (This assumes the same
   issuer name is not re-used from the set of trust anchors.)  The
   issuer/serial number pair can be stored in the sid field of the
   SignerInfo object.  However the sid field is not covered by the
   signature.  In the cases where the issuer/serial number pair is not
   used in the sid or the issuer/serial number pair needs to be signed,
   it SHOULD be placed in the issuerSerial field of the ESSCertIDv2
   structure.

I now propose the following:

   That document imposes a restriction for certificates that the 
   issuer distinguished name (DN) must be present.  If certificate 
   issuers had unique names, then the issuer/serial number pair would 
   be sufficient to uniquely identify the correct signing certificate.  
   However the uniqueness of the DN of a certificate issuer cannot be 
   guaranteed, hence two certificate issuers might use the same DN, 
   either without knowing it or intentionally.  The issuer name 
   contained in the issuer/serial number pair should thus only be used 
   as an hint to identify a certificate issuer.

   In the case where the issuer/serial number pair is not used in the 
   sid, it SHOULD be placed in the issuerSerial field of the 
   ESSCertIDv2 structure.

2) I asked to switch the second and the third paragraph of section (5.4.1.1) 
since it is more logical to say that one information provides a hint, 
while the second provides assurance that the certificate is the right one. 
Hereafter is a full text replacement:

   That document imposes a restriction for certificates that the 
   issuer distinguished name (DN) must be present.  If certificate 
   issuers had unique names, then the issuer/serial number pair would 
   be sufficient to uniquely identify the correct signing certificate.  
   However the uniqueness of the DN of a certificate issuer cannot be 
   guaranteed, hence two certificate issuers might use the same DN, 
   either without knowing it or intentionally.  The issuer name 
   contained in the issuer/serial number pair should thus only be used 
   as an hint to identify a certificate issuer.

   In the case where the issuer/serial number pair is not used in the 
   sid, it SHOULD be placed in the issuerSerial field of the 
   ESSCertIDv2 structure.

   The hash of the entire certificate allows for a verifier to check
   that the certificate used in the verification process was the same
   certificate the signer intended.  Hashes are convenient in that they
   are frequently used by certificate stores as a method of indexing and
   retrieving certificates as well.  The use of the hash is required by
   this structure since the detection of substituted certificates is
   based on the fact they would map to different hash values.

3) The definition of serialNumber is not fully adequate since it takes 
the view of the issuer (“for the issuer”).  It would be more appropriate 
to take the view from the relying party.

The current definition is:

   serialNumber  holds the serial number that uniquely identifies the
      certificate for the issuer. 

The following definition is proposed instead:

   serialNumber  holds a serial number that is unique for each 
      certificate issued by a given CA.

Denis




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CBx87Y093097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 04:59:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3CBx8Oe093096; Thu, 12 Apr 2007 04:59:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ganymede.on-x.com (ganymede.on-x.com [194.51.68.3]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CBwkdR093046 for <[e-mail]>; Thu, 12 Apr 2007 04:59:07 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (ganymede [127.0.0.1]) by ganymede.on-x.com (Postfix) with ESMTP id 8D6701F; Thu, 12 Apr 2007 13:58:36 +0200 (CEST)
Received: from ganymede.on-x.com ([127.0.0.1]) by localhost (ganymede.on-x.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29684-09; Thu, 12 Apr 2007 13:58:33 +0200 (CEST)
Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id A21131E; Thu, 12 Apr 2007 13:58:23 +0200 (CEST)
Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2007041213582233:199330 ; Thu, 12 Apr 2007 13:58:22 +0200 
Message-ID: <[e-mail]>
Date: Thu, 12 Apr 2007 13:56:13 +0200
From: Peter Sylvester <[e-mail]>
User-Agent: Thunderbird 1.5.0.9 (X11/20061206)
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
Cc: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11  |July 24, 2002) at 04/12/2007 01:58:22 PM, Serialize by Router on vinea/ON-X(Release 5.0.11  |July 24, 2002) at 04/12/2007 01:58:32 PM, Serialize complete at 04/12/2007 01:58:32 PM
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090504050108080507080708"
X-Virus-Scanned: by amavisd-new at on-x.com
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 is a cryptographically signed message in MIME format.

--------------ms090504050108080507080708
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

You wrote two messages

Russ Housley wrote:
> I'd like to add one point.  Please look at section 9 of RFC 3852.  The 
> authenticated attributes in AuthenticatedData follow choice B).

I think that authenticated attributes in AuthenticatedData also follows A.

The question is badly presented anyway: Do you ask whether the input of 
the hash function used to
calculate the hash of the authenticated attributes is not identical with 
the transmitted encoding
as with AuthenticatedData and SignedData (choice A) or whether it is 
identical? (B)?
>
> Russ
>
>
> At 01:34 PM 3/27/2007, Turner, Sean P. wrote:
>
>> At IETF 68, Russ Housley presented an summary of the 
>> Authenticated-Enveloped-Data content type (the slides can be found at 
>> https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=68 
>> <https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=68> 
>> ).  There was one open issue (the last slide) that dealt with the 
>> encoding of authenticated attributes.  It was discussed at the 
>> meeting; however, responses from a wider audience (i.e., this list) 
>> is necessary.  Please indicate your preference on whether:
>>
>> A) The encoding of the authenticated attributes should be done 
>> exactly the same as in SignedData.
>>
>> B) The encoding of the authenticated attributes should use the 
>> encoding that will be transmitted.
>>
>> We are soliciting feed until 10 April 2007.
>>
>> spt 



Russ Housley wrote:
>
> The encoding issue raised by Peter and Peter needs to be very clear.  
> The current document really handles this by reference, which is 
> probably not the best.
>
> I suggest the re-write of the 3rd paragraph of section 2.2 to handle 
> this directly instead of by reference:
>
>    If optional authenticated attributes are present, then they are DER
>    encoded.  A separate encoding of the authAttrs field is performed to
>    construct the authenticated associated data (AAD) input to the
>    authenticated encryption algorithm.  The IMPLICIT [1] tag in the
>    authAttrs field is not used for the DER encoding, rather an EXPLICIT
>    SET OF tag is used.  That is, the DER encoding of the SET OF tag,
>    rather than of the IMPLICIT [1] tag, is to be included in the
>    construction of the AAD along with the length and content octets of
>    the authAttrs value.  If the authenticated encryption algorithm
>    requires the AAD to be padded to a multiple of some block size, then
>    the padding MUST be added as described in Section 6.3 of [CMS].  This
>    padding method is well defined if and only if number of octets in the
>    block size is less than 256.
>
> Russ
>
Now I get lost? What is then the strong poll for, isn't this proposed 
section choice A?

Anyway, the other problem of 'one pass' has not been addressed. What is
necessary: I think it would be helpful to have a like like:

- some information concerning each recipient available before the data
- some information concerning the sealing parties available after the data
- some global information (like helpful messagedigest etc).

regards
peter


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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC
BHIwggLfoAMCAQICBgqvijKA3jANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G
A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs
UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNzAzMjYxMDM3MDNaFw0wOTA2MDMxMDM3MDNaMHAx
CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ
S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu
ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPB7ZSfmYsUuVIV0W2izxb1Zyvr6ZJ
IjPiqRMs77dbEQhQ6FZhhUSuABxxc8NjZvyPMRo0uuT0iVpRDktb0fWPTx3m9qTfdqrhWg2c
IOBKNbNQr8NogDJvG1AxRx4q9SXKZCVpZCoHu3fz2Rfji1kL7l597+7qBEsFd9IyvRaexQID
AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5
MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT
VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD
VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F
ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSZjq81LuJmsiiu1Yt/ezwCiUQSQTAfBgNV
HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA
A4IBfAAUq5MJ3gXhdKDpOm0ascDE9e1iMo0RQ24ujkc9IrFXhAJNS+3eNwcJEieU2vgZTsGb
zKeBZom1zVOFoh73VIRP6T08j4dDlndpDYZbxD20KzFt9zX6gV8IgR2zkkZXLQRbLyW16kw8
oFe3s//p1csCkCPAlZv1rZQYR5Psm0A1aiOiuSHhWUmgfAJxmIgfbmKtS3WpsUZVBuLQpThN
rWjLRAqJKYA++++qqo3ujqAAzJLe+MHrX5dai7+n6WBfV4qo1uDArR7XbmgVpV/EdPA75XRi
XEedLgbFDawJ9nAMN6WfL/NG6GZkEa7mZ7sH/gG34y21nq4w4mAAxn9wz7mDKMsEbJMZ5VlJ
TOp0g6TdYqGjNoc/rQg7pqjcRChVitwd1Rl8O31+bIdNSpv4UReNMDcffRQrt+pF1FxR4q6q
M9YLJU8NThx/89Mf/WF7fzrgVlsNJ78D9nJu0EhKes/9EX2qpIcHUfk/izOj8lCc1ksFgXpd
UEchE0DcMIIEcjCCAt+gAwIBAgIGCq+KMoDeMA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT
AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV
BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA3MDMyNjEwMzcwM1oXDTA5MDYwMzEw
MzcwM1owcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp
Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA
ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8HtlJ+ZixS5UhXRbaL
PFvVnK+vpkkiM+KpEyzvt1sRCFDoVmGFRK4AHHFzw2Nm/I8xGjS65PSJWlEOS1vR9Y9PHeb2
pN92quFaDZwg4Eo1s1Cvw2iAMm8bUDFHHir1JcpkJWlkKge7d/PZF+OLWQvuXn3v7uoESwV3
0jK9Fp7FAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl
Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl
ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF
BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F
ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJmOrzUu4mayKK7Vi397PAKJ
RBJBMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI
hvcNAQEFBQADggF8ABSrkwneBeF0oOk6bRqxwMT17WIyjRFDbi6ORz0isVeEAk1L7d43BwkS
J5Ta+BlOwZvMp4FmibXNU4WiHvdUhE/pPTyPh0OWd2kNhlvEPbQrMW33NfqBXwiBHbOSRlct
BFsvJbXqTDygV7ez/+nVywKQI8CVm/WtlBhHk+ybQDVqI6K5IeFZSaB8AnGYiB9uYq1Ldamx
RlUG4tClOE2taMtECokpgD7776qqje6OoADMkt74wetfl1qLv6fpYF9XiqjW4MCtHtduaBWl
X8R08DvldGJcR50uBsUNrAn2cAw3pZ8v80boZmQRruZnuwf+AbfjLbWerjDiYADGf3DPuYMo
ywRskxnlWUlM6nSDpN1ioaM2hz+tCDumqNxEKFWK3B3VGXw7fX5sh01Km/hRF40wNx99FCu3
6kXUXFHirqoz1gslTw1OHH/z0x/9YXt/OuBWWw0nvwP2cm7QSEp6z/0RfaqkhwdR+T+LM6Py
UJzWSwWBel1QRyETQNwwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL
MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL
STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0
MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj
ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI
hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M
ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe
1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt
qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd
UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH
pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS
cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB
CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0
dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C
AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV
HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3
UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy
4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz
QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u
US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj
PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq
Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf
Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y
rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6
PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL
d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18
k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg
d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD
VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ
S0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwNDEyMTE1NjEzWjAjBgkqhkiG9w0B
CQQxFgQUmwJH/f6uYHJPlNKq5sARaZR1mA8wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D
BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC
ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY
MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy
c0dFTgIGCq+KMoDeMHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE
ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ
IEVkZWxXZWIgUGVyc0dFTgIGCq+KMoDeMA0GCSqGSIb3DQEBAQUABIGArTCSX1bJeLBzJEys
4Mdx+xUBx3BOkRlFmUYGjz62dNy0iPAgLZvfF+rhFZZjqCd0j+sqhEU0oj0Qq6umywNlAu0T
nkdh5o1AI52tTqcsH23A2Vn6xt8LaiGdts6sHPeH1dMel5nP3Tz4A6TG7gO8Nmc/cjo3Y1TY
5WkwG9KdUJcAAAAAAAA=
--------------ms090504050108080507080708--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3AHuiuL075307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Apr 2007 10:57:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3AHuiu6075306; Tue, 10 Apr 2007 10:56:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l3AHuhr5075296 for <[e-mail]>; Tue, 10 Apr 2007 10:56:43 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 10571 invoked by uid 0); 10 Apr 2007 17:56:37 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.66.14.186) by woodstock.binhost.com with SMTP; 10 Apr 2007 17:56:37 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 10 Apr 2007 13:56:31 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[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>

The encoding issue raised by Peter and Peter needs to be very 
clear.  The current document really handles this by reference, which 
is probably not the best.

I suggest the re-write of the 3rd paragraph of section 2.2 to handle 
this directly instead of by reference:

    If optional authenticated attributes are present, then they are DER
    encoded.  A separate encoding of the authAttrs field is performed to
    construct the authenticated associated data (AAD) input to the
    authenticated encryption algorithm.  The IMPLICIT [1] tag in the
    authAttrs field is not used for the DER encoding, rather an EXPLICIT
    SET OF tag is used.  That is, the DER encoding of the SET OF tag,
    rather than of the IMPLICIT [1] tag, is to be included in the
    construction of the AAD along with the length and content octets of
    the authAttrs value.  If the authenticated encryption algorithm
    requires the AAD to be padded to a multiple of some block size, then
    the padding MUST be added as described in Section 6.3 of [CMS].  This
    padding method is well defined if and only if number of octets in the
    block size is less than 256.

Russ




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3AHZaYJ073123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Apr 2007 10:35:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3AHZa1j073122; Tue, 10 Apr 2007 10:35:36 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l3AHZFZJ073110 for <[e-mail]>; Tue, 10 Apr 2007 10:35:36 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 19273 invoked by uid 0); 10 Apr 2007 17:35:10 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.66.14.186) by woodstock.binhost.com with SMTP; 10 Apr 2007 17:35:10 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 10 Apr 2007 12:26:17 -0400
To: Peter Sylvester <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[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 was very unclear.  Let me try again.  Hopefully this will work out 
more clearly.

For SignedData, Section 5.4 of RFC 3852 says:

    ... A separate encoding
    of the signedAttrs field is performed for message digest calculation.
    The IMPLICIT [0] tag in the signedAttrs is not used for the DER
    encoding, rather an EXPLICIT SET OF tag is used.  That is, the DER
    encoding of the EXPLICIT SET OF tag, rather than of the IMPLICIT [0]
    tag, MUST be included in the message digest calculation along with
    the length and content octets of the SignedAttributes value.

For Authenticated Data. Section 9.2 of RFC 3852 says:

    ... A separate
    encoding of the authAttrs field is performed for message digest
    calculation.  The IMPLICIT [2] tag in the authAttrs field is not used
    for the DER encoding, rather an EXPLICIT SET OF tag is used.  That
    is, the DER encoding of the SET OF tag, rather than of the IMPLICIT
    [2] tag, is to be included in the message digest calculation along
    with the length and content octets of the authAttrs value.

So, the same encoding is used to the computation of the hash value, 
but a different initial tag is used in the encoding that is transmitted.

Russ

The same encoding is used At 11:14 AM 4/10/2007, Russ Housley wrote:
>Peter:
>
>>>I'm pleased to listen to implementors on this point.  So far, two 
>>>have spoken.  One suggesting the move to SEQUENCE and one 
>>>preferring to use their existing attribute handling 
>>>routines.  Both said, that it was not a really big deal either 
>>>way.  Given that input, I went with consistency with AuthenticatedData.
>>
>>What do you mean with consistency with AuthenticatedData? Isn't 
>>it  the same as with SignedData?
>>Having them before is not what I would call consistant. I think you 
>>may consider two sets.
>
>No.  They both use SET, but there is a difference in the first tag 
>of the DER encoding that is used for the hash value 
>computation.  SignedData has a bit of extra complexity for backward 
>compatibility.  PKCS#7 V1.5 did not have AuthenticatedData, so the 
>extra complexity is not required.
>
>Russ



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3AFaT7f060012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Apr 2007 08:36:29 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3AFaTZV060010; Tue, 10 Apr 2007 08:36:29 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l3AFaQR1060002 for <[e-mail]>; Tue, 10 Apr 2007 08:36:29 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 4287 invoked by uid 0); 10 Apr 2007 15:36:20 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.66.14.186) by woodstock.binhost.com with SMTP; 10 Apr 2007 15:36:20 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 10 Apr 2007 11:14:17 -0400
To: Peter Sylvester <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[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:

>>I'm pleased to listen to implementors on this point.  So far, two 
>>have spoken.  One suggesting the move to SEQUENCE and one 
>>preferring to use their existing attribute handling routines.  Both 
>>said, that it was not a really big deal either way.  Given that 
>>input, I went with consistency with AuthenticatedData.
>
>What do you mean with consistency with AuthenticatedData? Isn't 
>it  the same as with SignedData?
>Having them before is not what I would call consistant. I think you 
>may consider two sets.

No.  They both use SET, but there is a difference in the first tag of 
the DER encoding that is used for the hash value 
computation.  SignedData has a bit of extra complexity for backward 
compatibility.  PKCS#7 V1.5 did not have AuthenticatedData, so the 
extra complexity is not required.

Russ



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3AE1Y6U051603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Apr 2007 07:01:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3AE1Ylw051602; Tue, 10 Apr 2007 07:01:34 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3AE1VWR051594 for <[e-mail]>; Tue, 10 Apr 2007 07:01:32 -0700 (MST) (envelope-from [e-mail])
Received: from [193.51.14.5] (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id l3AE1J525916; Tue, 10 Apr 2007 16:01:19 +0200 (MEST)
Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by edelweb.fr (nospam/2.4); Tue, 10 Apr 2007 16:01:19 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Tue, 10 Apr 2007 15:59:10 +0200
From: Peter Sylvester <[e-mail]>
User-Agent: Thunderbird 1.5.0.9 (X11/20061206)
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: Peter Gutmann <[e-mail]>, [e-mail]
Subject: Re: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000600060108000800050502"
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 is a cryptographically signed message in MIME format.

--------------ms000600060108000800050502
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Russ Housley wrote:
>
> Peter:
>
>> Your argument about SEQUENCE  vs SET sounds wrong to me: If you have 
>> an implicit tagging that
>> replaces sequence or set, then coding or decoding becomes essentially 
>> the same except that you
>> won't need to sort the attributes before coding, but it wouldn't hurt 
>> if you do. On the other
>> hand, if you really verify the order when decoding, then sequence 
>> hurts, but there are several
>> implementations which ignore the encoded order as far as I know and 
>> others which fail to
>> sort etc.
>
> Such implementations would not be considered compliant with RFC 3852 
> or any of its predecessors, including PKCS#7 v1.5.  I do not think we 
> should penalize implementors that followed the specification.
Right. But that was not the point. no matter IMO anyway.
>
> I'm pleased to listen to implementors on this point.  So far, two have 
> spoken.  One suggesting the move to SEQUENCE and one preferring to use 
> their existing attribute handling routines.  Both said, that it was 
> not a really big deal either way.  Given that input, I went with 
> consistency with AuthenticatedData.

What do you mean with consistency with AuthenticatedData? Isn't it  the 
same as with SignedData?
Having them before is not what I would call consistant. I think you may 
consider two sets.

>
> Russ
>
>
>
>
>


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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC
BHIwggLfoAMCAQICBgqvijKA3jANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G
A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs
UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNzAzMjYxMDM3MDNaFw0wOTA2MDMxMDM3MDNaMHAx
CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ
S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu
ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPB7ZSfmYsUuVIV0W2izxb1Zyvr6ZJ
IjPiqRMs77dbEQhQ6FZhhUSuABxxc8NjZvyPMRo0uuT0iVpRDktb0fWPTx3m9qTfdqrhWg2c
IOBKNbNQr8NogDJvG1AxRx4q9SXKZCVpZCoHu3fz2Rfji1kL7l597+7qBEsFd9IyvRaexQID
AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5
MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT
VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD
VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F
ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSZjq81LuJmsiiu1Yt/ezwCiUQSQTAfBgNV
HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA
A4IBfAAUq5MJ3gXhdKDpOm0ascDE9e1iMo0RQ24ujkc9IrFXhAJNS+3eNwcJEieU2vgZTsGb
zKeBZom1zVOFoh73VIRP6T08j4dDlndpDYZbxD20KzFt9zX6gV8IgR2zkkZXLQRbLyW16kw8
oFe3s//p1csCkCPAlZv1rZQYR5Psm0A1aiOiuSHhWUmgfAJxmIgfbmKtS3WpsUZVBuLQpThN
rWjLRAqJKYA++++qqo3ujqAAzJLe+MHrX5dai7+n6WBfV4qo1uDArR7XbmgVpV/EdPA75XRi
XEedLgbFDawJ9nAMN6WfL/NG6GZkEa7mZ7sH/gG34y21nq4w4mAAxn9wz7mDKMsEbJMZ5VlJ
TOp0g6TdYqGjNoc/rQg7pqjcRChVitwd1Rl8O31+bIdNSpv4UReNMDcffRQrt+pF1FxR4q6q
M9YLJU8NThx/89Mf/WF7fzrgVlsNJ78D9nJu0EhKes/9EX2qpIcHUfk/izOj8lCc1ksFgXpd
UEchE0DcMIIEcjCCAt+gAwIBAgIGCq+KMoDeMA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT
AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV
BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA3MDMyNjEwMzcwM1oXDTA5MDYwMzEw
MzcwM1owcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp
Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA
ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8HtlJ+ZixS5UhXRbaL
PFvVnK+vpkkiM+KpEyzvt1sRCFDoVmGFRK4AHHFzw2Nm/I8xGjS65PSJWlEOS1vR9Y9PHeb2
pN92quFaDZwg4Eo1s1Cvw2iAMm8bUDFHHir1JcpkJWlkKge7d/PZF+OLWQvuXn3v7uoESwV3
0jK9Fp7FAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl
Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl
ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF
BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F
ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJmOrzUu4mayKK7Vi397PAKJ
RBJBMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI
hvcNAQEFBQADggF8ABSrkwneBeF0oOk6bRqxwMT17WIyjRFDbi6ORz0isVeEAk1L7d43BwkS
J5Ta+BlOwZvMp4FmibXNU4WiHvdUhE/pPTyPh0OWd2kNhlvEPbQrMW33NfqBXwiBHbOSRlct
BFsvJbXqTDygV7ez/+nVywKQI8CVm/WtlBhHk+ybQDVqI6K5IeFZSaB8AnGYiB9uYq1Ldamx
RlUG4tClOE2taMtECokpgD7776qqje6OoADMkt74wetfl1qLv6fpYF9XiqjW4MCtHtduaBWl
X8R08DvldGJcR50uBsUNrAn2cAw3pZ8v80boZmQRruZnuwf+AbfjLbWerjDiYADGf3DPuYMo
ywRskxnlWUlM6nSDpN1ioaM2hz+tCDumqNxEKFWK3B3VGXw7fX5sh01Km/hRF40wNx99FCu3
6kXUXFHirqoz1gslTw1OHH/z0x/9YXt/OuBWWw0nvwP2cm7QSEp6z/0RfaqkhwdR+T+LM6Py
UJzWSwWBel1QRyETQNwwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL
MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL
STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0
MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj
ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI
hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M
ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe
1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt
qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd
UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH
pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS
cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB
CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0
dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C
AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV
HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3
UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy
4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz
QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u
US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj
PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq
Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf
Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y
rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6
PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL
d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18
k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg
d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD
VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ
S0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwNDEwMTM1OTEwWjAjBgkqhkiG9w0B
CQQxFgQUaYuZ4TWzRw0Ra9/LnUaAYvnmVf4wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D
BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC
ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY
MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy
c0dFTgIGCq+KMoDeMHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE
ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ
IEVkZWxXZWIgUGVyc0dFTgIGCq+KMoDeMA0GCSqGSIb3DQEBAQUABIGAgncV3JkbK7BB6jDx
QHiWUdRZWq3QHwthIc173auElxxsm99/F1hhw5YT8iVXZquIToUpMX+G10y8FWAfAkcKgsAQ
bm7U+g3RaAUrqxO6JGE6Q7chhSyNNn2XRQoxHdAj+RPbOUil6l0hpMoveNmSAZlDe0SJpjl3
QgAnKJZQ2FsAAAAAAAA=
--------------ms000600060108000800050502--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3ADMI1U049263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Apr 2007 06:22:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3ADMIkp049262; Tue, 10 Apr 2007 06:22:18 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l3ADMHb7049256 for <[e-mail]>; Tue, 10 Apr 2007 06:22:17 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 31757 invoked by uid 0); 10 Apr 2007 13:22:15 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.66.14.186) by woodstock.binhost.com with SMTP; 10 Apr 2007 13:22:15 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 10 Apr 2007 08:57:19 -0400
To: Peter Sylvester <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
Cc: Peter Gutmann <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[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:

>Your argument about SEQUENCE  vs SET sounds wrong to me: If you have 
>an implicit tagging that
>replaces sequence or set, then coding or decoding becomes 
>essentially the same except that you
>won't need to sort the attributes before coding, but it wouldn't 
>hurt if you do. On the other
>hand, if you really verify the order when decoding, then sequence 
>hurts, but there are several
>implementations which ignore the encoded order as far as I know and 
>others which fail to
>sort etc.

Such implementations would not be considered compliant with RFC 3852 
or any of its predecessors, including PKCS#7 v1.5.  I do not think we 
should penalize implementors that followed the specification.

I'm pleased to listen to implementors on this point.  So far, two 
have spoken.  One suggesting the move to SEQUENCE and one preferring 
to use their existing attribute handling routines.  Both said, that 
it was not a really big deal either way.  Given that input, I went 
with consistency with AuthenticatedData.

Russ





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3ACnRv5046942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Apr 2007 05:49:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3ACnRej046941; Tue, 10 Apr 2007 05:49:27 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l3ACn2nQ046923 for <[e-mail]>; Tue, 10 Apr 2007 05:49:26 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 30990 invoked by uid 0); 10 Apr 2007 12:48:59 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.66.14.186) by woodstock.binhost.com with SMTP; 10 Apr 2007 12:48:59 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 10 Apr 2007 08:48:58 -0400
To: [e-mail] (Peter Gutmann)
From: Russ Housley <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[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:

> >On the second item, I disagree.  The authenticated attributes are 
> handled the
> >same as in AuthenticatedData.
>
>They're placed before the data, not after it, which is unlike any other use of
>authenticated attributes in any CMS PDU.  As both Peter Sylvester and myself
>have already pointed out, this makes one-pass/streaming processing impossible.

As I already said in response, AES-CCM and AES-GCM both require the 
processing of the "additional authenticated data" (the authenticated 
attributes in this structure) prior to the processing of the payload 
(the encapsulated content in this structure).  Thus, the only way 
that one-pass processing can be accomplished with these authenticated 
encryption modes is for the authenticated attributes to appear first.

Russ



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3AC8KuO044502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Apr 2007 05:08:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3AC8KTQ044501; Tue, 10 Apr 2007 05:08:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3AC7weT044490 for <[e-mail]>; Tue, 10 Apr 2007 05:08:19 -0700 (MST) (envelope-from [e-mail])
Received: from [193.51.14.5] (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id l3AC7q520092; Tue, 10 Apr 2007 14:07:52 +0200 (MEST)
Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by edelweb.fr (nospam/2.4); Tue, 10 Apr 2007 14:07:52 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Tue, 10 Apr 2007 14:05:39 +0200
From: Peter Sylvester <[e-mail]>
User-Agent: Thunderbird 1.5.0.9 (X11/20061206)
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: Peter Gutmann <[e-mail]>, [e-mail]
Subject: Re: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060705010709090204000603"
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 is a cryptographically signed message in MIME format.

--------------ms060705010709090204000603
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


>
>
> On the second item, I disagree.  The authenticated attributes are 
> handled the same as in AuthenticatedData.  While I understand that the 
> use of a SEQUENCE instead of a SET would be easier to process, but 
> that would mean that an implementation could not take advantage of 
> existing attribute handling routines.
in your proposal, the attributes are placed before the data. Why?

As far as I understand, there is no difference between handling of 
authenticated attributed between
signedData and authenticatedData, so why introducing any new mode here?

Your argument about SEQUENCE  vs SET sounds wrong to me: If you have an 
implicit tagging that
replaces sequence or set, then coding or decoding becomes essentially 
the same except that you
won't need to sort the attributes before coding, but it wouldn't hurt if 
you do. On the other
hand, if you really verify the order when decoding, then sequence hurts, 
but there are several
implementations which ignore the encoded order as far as I know and 
others which fail to
sort etc.

>
> Russ
>
>
>


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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC
BHIwggLfoAMCAQICBgqvijKA3jANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G
A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs
UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNzAzMjYxMDM3MDNaFw0wOTA2MDMxMDM3MDNaMHAx
CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ
S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu
ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPB7ZSfmYsUuVIV0W2izxb1Zyvr6ZJ
IjPiqRMs77dbEQhQ6FZhhUSuABxxc8NjZvyPMRo0uuT0iVpRDktb0fWPTx3m9qTfdqrhWg2c
IOBKNbNQr8NogDJvG1AxRx4q9SXKZCVpZCoHu3fz2Rfji1kL7l597+7qBEsFd9IyvRaexQID
AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5
MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT
VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD
VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F
ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSZjq81LuJmsiiu1Yt/ezwCiUQSQTAfBgNV
HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA
A4IBfAAUq5MJ3gXhdKDpOm0ascDE9e1iMo0RQ24ujkc9IrFXhAJNS+3eNwcJEieU2vgZTsGb
zKeBZom1zVOFoh73VIRP6T08j4dDlndpDYZbxD20KzFt9zX6gV8IgR2zkkZXLQRbLyW16kw8
oFe3s//p1csCkCPAlZv1rZQYR5Psm0A1aiOiuSHhWUmgfAJxmIgfbmKtS3WpsUZVBuLQpThN
rWjLRAqJKYA++++qqo3ujqAAzJLe+MHrX5dai7+n6WBfV4qo1uDArR7XbmgVpV/EdPA75XRi
XEedLgbFDawJ9nAMN6WfL/NG6GZkEa7mZ7sH/gG34y21nq4w4mAAxn9wz7mDKMsEbJMZ5VlJ
TOp0g6TdYqGjNoc/rQg7pqjcRChVitwd1Rl8O31+bIdNSpv4UReNMDcffRQrt+pF1FxR4q6q
M9YLJU8NThx/89Mf/WF7fzrgVlsNJ78D9nJu0EhKes/9EX2qpIcHUfk/izOj8lCc1ksFgXpd
UEchE0DcMIIEcjCCAt+gAwIBAgIGCq+KMoDeMA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT
AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV
BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA3MDMyNjEwMzcwM1oXDTA5MDYwMzEw
MzcwM1owcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp
Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA
ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8HtlJ+ZixS5UhXRbaL
PFvVnK+vpkkiM+KpEyzvt1sRCFDoVmGFRK4AHHFzw2Nm/I8xGjS65PSJWlEOS1vR9Y9PHeb2
pN92quFaDZwg4Eo1s1Cvw2iAMm8bUDFHHir1JcpkJWlkKge7d/PZF+OLWQvuXn3v7uoESwV3
0jK9Fp7FAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl
Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl
ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF
BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F
ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJmOrzUu4mayKK7Vi397PAKJ
RBJBMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI
hvcNAQEFBQADggF8ABSrkwneBeF0oOk6bRqxwMT17WIyjRFDbi6ORz0isVeEAk1L7d43BwkS
J5Ta+BlOwZvMp4FmibXNU4WiHvdUhE/pPTyPh0OWd2kNhlvEPbQrMW33NfqBXwiBHbOSRlct
BFsvJbXqTDygV7ez/+nVywKQI8CVm/WtlBhHk+ybQDVqI6K5IeFZSaB8AnGYiB9uYq1Ldamx
RlUG4tClOE2taMtECokpgD7776qqje6OoADMkt74wetfl1qLv6fpYF9XiqjW4MCtHtduaBWl
X8R08DvldGJcR50uBsUNrAn2cAw3pZ8v80boZmQRruZnuwf+AbfjLbWerjDiYADGf3DPuYMo
ywRskxnlWUlM6nSDpN1ioaM2hz+tCDumqNxEKFWK3B3VGXw7fX5sh01Km/hRF40wNx99FCu3
6kXUXFHirqoz1gslTw1OHH/z0x/9YXt/OuBWWw0nvwP2cm7QSEp6z/0RfaqkhwdR+T+LM6Py
UJzWSwWBel1QRyETQNwwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL
MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL
STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0
MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj
ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI
hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M
ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe
1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt
qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd
UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH
pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS
cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB
CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0
dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C
AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV
HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3
UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy
4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz
QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u
US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj
PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq
Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf
Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y
rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6
PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL
d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18
k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg
d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD
VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ
S0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwNDEwMTIwNTM5WjAjBgkqhkiG9w0B
CQQxFgQU+Y5wGBfVGH4wrBQE/xoAwpfvAxcwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D
BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC
ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY
MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy
c0dFTgIGCq+KMoDeMHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE
ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ
IEVkZWxXZWIgUGVyc0dFTgIGCq+KMoDeMA0GCSqGSIb3DQEBAQUABIGAH4Zn/nk0ICPXRO5j
LZc6D+KPOz7tmf5xLJq0vV7rUDIl+DPU8couQY8IlpKThT6xkX7idDz5o6Xf2l0Afraond/I
qhiX48sxg+FTyNF3ijI0hvzyY6jyPg+4bc8pA2dwJLzl4NScXM//2QCWuQ/9uBfR/dNVr3Bv
XcMcpusBxZUAAAAAAAA=
--------------ms060705010709090204000603--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3AAuJv3040211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Apr 2007 03:56:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3AAuJ9Y040210; Tue, 10 Apr 2007 03:56:19 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.10.121]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3AAtw4F040175 for <[e-mail]>; Tue, 10 Apr 2007 03:56:18 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 6C387480156; Tue, 10 Apr 2007 22:55:57 +1200 (NZST)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1tE2ZUM49Bkg; Tue, 10 Apr 2007 22:55:57 +1200 (NZST)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 5015E48014B; Tue, 10 Apr 2007 22:55:57 +1200 (NZST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 58B76514010; Tue, 10 Apr 2007 22:55:54 +1200 (NZST)
Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1HbE14-0004Qj-00; Tue, 10 Apr 2007 22:56:02 +1200
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Date: Tue, 10 Apr 2007 22:56:02 +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>

Russ Housley <[e-mail]> writes:

>On the first item, you never sent text.  

Oh, I thought that what I'd sent you was enough to go on.  Looks like it was
just a communications problem then, I'll try and get you something soonish.

>On the second item, I disagree.  The authenticated attributes are handled the
>same as in AuthenticatedData. 

They're placed before the data, not after it, which is unlike any other use of
authenticated attributes in any CMS PDU.  As both Peter Sylvester and myself
have already pointed out, this makes one-pass/streaming processing impossible.

Peter.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l39BBud4086159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Apr 2007 04:11:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l39BBu3W086158; Mon, 9 Apr 2007 04:11:56 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l39BBWWt086104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Apr 2007 04:11:54 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l39BB7gw012799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Apr 2007 13:11:07 +0200
From: Simon Josefsson <[e-mail]>
To: [e-mail] (Peter Gutmann)
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: AlgorithmIdentifier, SHA-1, etc.
References: <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:070409:[e-mail]::3QoFEDKqVNPqTq5Q:MsX
X-Hashcash: 1:22:070409:[e-mail]::tQBP8tX8HMZykdCj:6/O+
X-Hashcash: 1:22:070409:[e-mail]::ZPi90spiQd3Aos3c:DKnD
X-Hashcash: 1:22:070409:[e-mail]::Nnw/iCZnyUzfe4w7:LBLl
Date: Mon, 09 Apr 2007 14:11:04 +0200
In-Reply-To: <[e-mail]> (Peter Gutmann's message of "Sat\, 07 Apr 2007 19\:01\:26 +1200")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.95 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.8 required=4.0 tests=AWL,BAYES_50, FORGED_RCVD_HELO autolearn=ham version=3.1.1
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv
X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com
X-Virus-Status: Clean
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>

[e-mail] (Peter Gutmann) writes:

> Eric Rescorla <[e-mail]> writes:
>
>>So, what's the right answer here?
>
> Read the OID and hash value, toss the rest.  Doing anything else is just
> asking for trouble.
>
> (There's really no question here: There are two ways to do this, knowing in
>  advance what you'll encounter in the field isn't possible, so the only
>  workable solution is to not compare the encoded value, or if you must,
>  compare two pre-encoded alternatives for each possible hash algorithm.  This
>  still breaks though if someone gets the encoding slightly wrong... comparing
>  a pre-built value is just asking for trouble).

That approach, to not validate the parameters field, is what led to
the variant of Bleichenbacher's attack in several TLS implementations.
I'm strongly opposed to permit this in conforming implementations.

Even if we restrict it to either absent parameters or NULL parameters,
that would enable a side-channel: you can "leak" one bit of
information by deciding which of NULL or absent you use.  It is not
clear to me how important that threat is.  There are other ways to
leak information in the TLS protocol (packet ordering, random values,
etc).  However, there may be some value in not expanding the ways to
leak information further.

I could live with MUST generate NULL parameters fields on encoding,
and MUST accept both NULL and absent fields on decoding.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l37N0khc083778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Apr 2007 16:00:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l37N0jQr083777; Sat, 7 Apr 2007 16:00:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l37N0iZi083765 for <[e-mail]>; Sat, 7 Apr 2007 16:00:44 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 12222 invoked by uid 0); 7 Apr 2007 23:00:36 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.66.14.186) by woodstock.binhost.com with SMTP; 7 Apr 2007 23:00:36 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Sat, 07 Apr 2007 18:49:14 -0400
To: Dr Stephen Henson <[e-mail]>, [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: AlgorithmIdentifier, SHA-1, etc.
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[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>

Thanks for pointing this out.  I did say that you needed to make sure 
it was a valid parameter encoding, but I should have included this 
important additional information.  Thanks.

Russ

At 07:39 AM 4/7/2007, Dr Stephen Henson wrote:

>Russ Housley wrote:
> >
> > Note that the DigestInfoValue is part of the structure that is
> > "encrypted" with the RSA private key when generating a signature.  It is
> > recovered by "decrypting" the signature value with the RSA public key.
> >
>
>Note that care should be taken when handling the DigestInfo structure
>recovered from an RSA signature.
>
>As well as the original Bleichenbacher signature forgery attack (caused
>by ignoring trailing garbage after DigestInfo) there is a variant which
>inserts garbage in the middle of the recovered structure. Allowing
>arbitrary parameter values in the DigestAlgorithmIdentifier (for example
>large OCTET STRINGs) is one way to do this. Unlike the original attack
>this variant produces a "valid" DigestInfo structure.
>
>As a result in the specific case of the recovered DigestInfo from an RSA
>signature OpenSSL now only tolerates a NULL or absent parameter field.
>This is OK for all existing digests.
>
>It is more liberal about DigestInfo structures in other contexts.
>
>Steve.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l37MkITY083003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Apr 2007 15:46:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l37MkIKp083002; Sat, 7 Apr 2007 15:46:18 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l37MjvgT082953 for <[e-mail]>; Sat, 7 Apr 2007 15:46:17 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 31851 invoked by uid 0); 7 Apr 2007 22:45:46 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.66.14.186) by woodstock.binhost.com with SMTP; 7 Apr 2007 22:45:46 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Sat, 07 Apr 2007 18:43:49 -0400
To: [e-mail] (Peter Gutmann), [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[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:

> >I believe that this document and the companion document that tells 
> how to use
> >AES-CCM and AES-GCM are ready for WGLC.
>
>Uhhmmm, I beg to differ... it still doesn't contain the changes I sent some
>time ago to handle encrypt + MAC combinations (e.g. AES + HMAC), and there was
>no agreement about handling of auth.attributes - two people pointed out that
>the existing scheme has problems, but this hasn't been resolved yet.

On the first item, you never sent text.  We discussed potential ways 
to handle it, but you never provided a section to add to the 
document.  I see no reason to delay the AES-CCM and AES-GCM  document 
until you do so.

On the second item, I disagree.  The authenticated attributes are 
handled the same as in AuthenticatedData.  While I understand that 
the use of a SEQUENCE instead of a SET would be easier to process, 
but that would mean that an implementation could not take advantage 
of existing attribute handling routines.

Russ



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l37H7hdX048304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Apr 2007 10:07:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l37H7hxu048303; Sat, 7 Apr 2007 10:07:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from relay1.mail.uk.clara.net (relay1.mail.uk.clara.net [80.168.70.181]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l37H7MVF048229; Sat, 7 Apr 2007 10:07:42 -0700 (MST) (envelope-from [e-mail])
Received: from [149.254.200.218] (helo=[10.33.180.177]) by relay1.mail.uk.clara.net with esmtpa (Exim 4.62) (envelope-from <[e-mail]>) id 1HaENj-0004qT-AT; Sat, 07 Apr 2007 18:07:21 +0100
Message-ID: <[e-mail]>
Date: Sat, 07 Apr 2007 18:07:06 +0100
From: Dr Stephen Henson <[e-mail]>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: Eric Rescorla <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: AlgorithmIdentifier, SHA-1, etc.
References: <[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Clara-Relay: Message sent using Claranet Relay Service using auth code: drh
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>

Eric Rescorla wrote:
> At Sat, 07 Apr 2007 12:39:07 +0100,
> Dr Stephen Henson wrote:
>>
>> Russ Housley wrote:
>>> Note that the DigestInfoValue is part of the structure that is
>>> "encrypted" with the RSA private key when generating a signature.  It is
>>> recovered by "decrypting" the signature value with the RSA public key.
>>>
>> Note that care should be taken when handling the DigestInfo structure
>> recovered from an RSA signature.
>>
>> As well as the original Bleichenbacher signature forgery attack (caused
>> by ignoring trailing garbage after DigestInfo) there is a variant which
>> inserts garbage in the middle of the recovered structure. Allowing
>> arbitrary parameter values in the DigestAlgorithmIdentifier (for example
>> large OCTET STRINGs) is one way to do this. Unlike the original attack
>> this variant produces a "valid" DigestInfo structure.
>>
>> As a result in the specific case of the recovered DigestInfo from an RSA
>> signature OpenSSL now only tolerates a NULL or absent parameter field.
>> This is OK for all existing digests.
>>
>> It is more liberal about DigestInfo structures in other contexts.
> 
> Steven,
> 
> As I recall OpenSSL puts the NULL in the digestAlgorithm encoding
> as well. Am I right about that? 
> 
> 

Yes. It places the NULL in the DigestAlgortihmIdentifier for RSA
signatures DigestInfo according to PKCS#1.

It also includes it in other DigestAlgorithmIdentifier structures too.

As I recall (I'd have to check some ancient email archives) the NULL was
needed to pass an old S/MIME v2 compliance test some years back.

Steve.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l37EWaMJ030750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Apr 2007 07:32:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l37EWaZ2030749; Sat, 7 Apr 2007 07:32:36 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from randymail-a2.g.dreamhost.com (sd-green-bigip-81.dreamhost.com [208.97.132.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l37EWGNA030720; Sat, 7 Apr 2007 07:32:36 -0700 (MST) (envelope-from [e-mail])
Received: from delta.rtfm.com (unknown [74.95.2.169]) by randymail-a2.g.dreamhost.com (Postfix) with ESMTP id 7353EEEBB8; Sat,  7 Apr 2007 07:32:15 -0700 (PDT)
Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 7B2CC1CC3D; Sat,  7 Apr 2007 07:30:42 -0700 (PDT)
Date: Sat, 07 Apr 2007 07:30:42 -0700
From: Eric Rescorla <[e-mail]>
To: [e-mail] (Peter Gutmann)
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: AlgorithmIdentifier, SHA-1, etc.
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
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>

At Sat, 07 Apr 2007 19:01:26 +1200,
Peter Gutmann wrote:
> 
> 
> Eric Rescorla <[e-mail]> writes:
> 
> >So, what's the right answer here?
> 
> Read the OID and hash value, toss the rest.  Doing anything else is just
> asking for trouble.
> 
> (There's really no question here: There are two ways to do this, knowing in
>  advance what you'll encounter in the field isn't possible, so the only
>  workable solution is to not compare the encoded value, or if you must,
>  compare two pre-encoded alternatives for each possible hash algorithm.  This
>  still breaks though if someone gets the encoding slightly wrong... comparing
>  a pre-built value is just asking for trouble).

Totally agree.

My question was more what we ought to recommend.

-Ekr



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l37EVxOD030704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Apr 2007 07:31:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l37EVxwU030703; Sat, 7 Apr 2007 07:31:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from randymail-a3.g.dreamhost.com (sd-green-bigip-145.dreamhost.com [208.97.132.145]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l37EVcNY030681; Sat, 7 Apr 2007 07:31:58 -0700 (MST) (envelope-from [e-mail])
Received: from delta.rtfm.com (unknown [74.95.2.169]) by randymail-a3.g.dreamhost.com (Postfix) with ESMTP id B0A06185976; Sat,  7 Apr 2007 07:31:36 -0700 (PDT)
Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 73D811CC3D; Sat,  7 Apr 2007 07:30:03 -0700 (PDT)
Date: Sat, 07 Apr 2007 07:30:03 -0700
From: Eric Rescorla <[e-mail]>
To: Dr Stephen Henson <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: AlgorithmIdentifier, SHA-1, etc.
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
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>

At Sat, 07 Apr 2007 12:39:07 +0100,
Dr Stephen Henson wrote:
> 
> 
> Russ Housley wrote:
> > 
> > Note that the DigestInfoValue is part of the structure that is
> > "encrypted" with the RSA private key when generating a signature.  It is
> > recovered by "decrypting" the signature value with the RSA public key.
> > 
> 
> Note that care should be taken when handling the DigestInfo structure
> recovered from an RSA signature.
> 
> As well as the original Bleichenbacher signature forgery attack (caused
> by ignoring trailing garbage after DigestInfo) there is a variant which
> inserts garbage in the middle of the recovered structure. Allowing
> arbitrary parameter values in the DigestAlgorithmIdentifier (for example
> large OCTET STRINGs) is one way to do this. Unlike the original attack
> this variant produces a "valid" DigestInfo structure.
> 
> As a result in the specific case of the recovered DigestInfo from an RSA
> signature OpenSSL now only tolerates a NULL or absent parameter field.
> This is OK for all existing digests.
> 
> It is more liberal about DigestInfo structures in other contexts.

Steven,

As I recall OpenSSL puts the NULL in the digestAlgorithm encoding
as well. Am I right about that? 

Thanks,
-Ekr



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l37BdciR009494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Apr 2007 04:39:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l37BdcMb009493; Sat, 7 Apr 2007 04:39:38 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from relay1.mail.uk.clara.net (relay1.mail.uk.clara.net [80.168.70.181]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l37BdGwY009477; Sat, 7 Apr 2007 04:39:37 -0700 (MST) (envelope-from [e-mail])
Received: from [149.254.200.222] (helo=[10.36.182.67]) by relay1.mail.uk.clara.net with esmtpa (Exim 4.62) (envelope-from <[e-mail]>) id 1Ha9GF-0002s9-8U; Sat, 07 Apr 2007 12:39:15 +0100
Message-ID: <[e-mail]>
Date: Sat, 07 Apr 2007 12:39:07 +0100
From: Dr Stephen Henson <[e-mail]>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: AlgorithmIdentifier, SHA-1, etc.
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Clara-Relay: Message sent using Claranet Relay Service using auth code: drh
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 Housley wrote:
> 
> Note that the DigestInfoValue is part of the structure that is
> "encrypted" with the RSA private key when generating a signature.  It is
> recovered by "decrypting" the signature value with the RSA public key.
> 

Note that care should be taken when handling the DigestInfo structure
recovered from an RSA signature.

As well as the original Bleichenbacher signature forgery attack (caused
by ignoring trailing garbage after DigestInfo) there is a variant which
inserts garbage in the middle of the recovered structure. Allowing
arbitrary parameter values in the DigestAlgorithmIdentifier (for example
large OCTET STRINGs) is one way to do this. Unlike the original attack
this variant produces a "valid" DigestInfo structure.

As a result in the specific case of the recovered DigestInfo from an RSA
signature OpenSSL now only tolerates a NULL or absent parameter field.
This is OK for all existing digests.

It is more liberal about DigestInfo structures in other contexts.

Steve.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3776JLG081599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Apr 2007 00:06:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3776JBv081598; Sat, 7 Apr 2007 00:06:19 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.10.123]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3776G07081589 for <[e-mail]>; Sat, 7 Apr 2007 00:06:17 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 983B59C65E; Sat,  7 Apr 2007 19:06:16 +1200 (NZST)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNrv4p4bTsb7; Sat,  7 Apr 2007 19:06:16 +1200 (NZST)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 7C3479C65D; Sat,  7 Apr 2007 19:06:16 +1200 (NZST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 2020A514010; Sat,  7 Apr 2007 19:06:16 +1200 (NZST)
Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1Ha50A-0002eN-00; Sat, 07 Apr 2007 19:06:22 +1200
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Date: Sat, 07 Apr 2007 19:06:22 +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>

Russ Housley <[e-mail]> writes:

>I believe that this document and the companion document that tells how to use
>AES-CCM and AES-GCM are ready for WGLC.

Uhhmmm, I beg to differ... it still doesn't contain the changes I sent some
time ago to handle encrypt + MAC combinations (e.g. AES + HMAC), and there was
no agreement about handling of auth.attributes - two people pointed out that
the existing scheme has problems, but this hasn't been resolved yet.

Peter.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3771k8E080873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Apr 2007 00:01:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3771k9K080872; Sat, 7 Apr 2007 00:01:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.10.123]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3771OZ1080808; Sat, 7 Apr 2007 00:01:45 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 045B09C671; Sat,  7 Apr 2007 19:01:24 +1200 (NZST)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTmWuDzOKBYY; Sat,  7 Apr 2007 19:01:23 +1200 (NZST)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id D5BBE9C670; Sat,  7 Apr 2007 19:01:23 +1200 (NZST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id E6298514010; Sat,  7 Apr 2007 19:01:20 +1200 (NZST)
Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1Ha4vO-0002Z4-00; Sat, 07 Apr 2007 19:01:26 +1200
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: AlgorithmIdentifier, SHA-1, etc.
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Date: Sat, 07 Apr 2007 19:01:26 +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>

Eric Rescorla <[e-mail]> writes:

>So, what's the right answer here?

Read the OID and hash value, toss the rest.  Doing anything else is just
asking for trouble.

(There's really no question here: There are two ways to do this, knowing in
 advance what you'll encounter in the field isn't possible, so the only
 workable solution is to not compare the encoded value, or if you must,
 compare two pre-encoded alternatives for each possible hash algorithm.  This
 still breaks though if someone gets the encoding slightly wrong... comparing
 a pre-built value is just asking for trouble).

>My understanding from discussions in Prague is that this reflects NIST's
>current guidance as well.

This would put them in conflict with ISO, who (the last time I checked) say
the parameter should be omitted.  In any case though it doesn't really matter
which side wants to hold their breath the longest, if you read the OID and
hash and work with that you can't go wrong.

Peter.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l36K9ijm018527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Apr 2007 13:09:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l36K9iPW018525; Fri, 6 Apr 2007 13:09:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l36K9MMG018505 for <[e-mail]>; Fri, 6 Apr 2007 13:09:43 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 5038 invoked by uid 0); 6 Apr 2007 20:09:16 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.66.14.186) by woodstock.binhost.com with SMTP; 6 Apr 2007 20:09:16 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 06 Apr 2007 16:09:19 -0400
To: Eric Rescorla <[e-mail]>, [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: AlgorithmIdentifier, SHA-1, etc.
Cc: [e-mail]
In-Reply-To: <[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>

Note that the DigestInfoValue is part of the structure that is 
"encrypted" with the RSA private key when generating a signature.  It 
is recovered by "decrypting" the signature value with the RSA public key.

An implementation should check that the expected digest algorithm was 
used.  As Eric point out, this check is easier to perform if the two 
values are encoded in exactly the same manner.

One needs to look deeper into signatures in certificates and CMS 
SignerInfo to see where these comparisons are really performed.

The certificate signature has this structure:

    Certificate  ::=  SEQUENCE  {
         tbsCertificate       TBSCertificate,
         signatureAlgorithm   AlgorithmIdentifier,
         signatureValue       BIT STRING  }

In practice, the signature algorithm tells the digest algorithm as 
well as the digital signature algorithm. The ones that are relevant 
to this question are:

    sha1WithRSAEncryption
    sha224WithRSAEncryption
    sha256WithRSAEncryption
    sha384WithRSAEncryption
    sha512WithRSAEncryption

There is no filed that explicitly carries a digest algorithm 
identifier.  So, the digest algorithm for comparison to the 
DigestInfoValue inside the signature value must be generated in some 
manner by the implementation.  I believe than many implementations 
use a simple internal table.  Adding entries to this table is part of 
the work needed to add support for additional RSA signature 
algorithms.  So, the table should contain exactly the octet string 
that will appear in DigestInfoValue, including the NULL parameter 
required by PKCS#1.

The CMS SignerInfo has this structure:

       SignerInfo ::= SEQUENCE {
         version CMSVersion,
         sid SignerIdentifier,
         digestAlgorithm DigestAlgorithmIdentifier,
         signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
         signatureAlgorithm SignatureAlgorithmIdentifier,
         signature SignatureValue,
         unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }

Again, the signature algorithm tells the digest algorithm. The same 
set of algorithm identifiers are used here.

In each case, the digestAlgorithm must contain the digest algorithm 
identifier that is implicitly named by the signature algorithm, and 
the DigestInfoValue must contain the same digest algorithm identifier.

As Eric has already explained, the parameter in DigestInfoValue must 
be NULL, but we are "forgiving" in the processing of the parameter 
for digestAlgorithm.  The parameter can be NULL or absent.

In order to use the same signature validation routines for CMS and 
certificates, I believe that most implementations use the same 
internal table as discussed above for the DigestInfoValue 
comparison.  Then, in addition, the digest algorithm identifier is 
compared to the digestAlgorithm field in SignerInfo.  The signature 
value must contain exactly the expected digest algorithm identifier 
with a NULL parameter.

So, the only comparison that is not an exact match is the comparison 
from the internal table entry to the digestAlgorithm field.  I 
suggest that the object identifiers must match, but one can ignore 
the parameters, after making sure they are either absent or 
NULL.  That is, do not let the parameters carry some inappropriate value.

Russ


At 02:30 PM 4/6/2007, Eric Rescorla wrote:

>I'm trying to get a handle on how one ought to encode AlgorithmIdentifier.
>
>As people will perhaps remember, the ASN.1 is:
>
>
>AlgorithmIdentifier  ::=  SEQUENCE  {
>      algorithm               OBJECT IDENTIFIER,
>      parameters              ANY DEFINED BY algorithm OPTIONAL  }
>                                 -- contains a value of the type
>                                 -- registered for use with the
>                                 -- algorithm object identifier value
>
>Present hash functions do not take any useful parameters, leaving
>us with two encoding options:
>
>   - omit the parameter.
>   - include a NULL
>
>To make things more complicated, there are (at least) two different
>contexts in which this production appears:
>
>   - The S/MIME DigestAlgorithmIdentifier production.
>   - Inside the DigestInfo of the S/MIME signature.
>
>RFC 3370's guidance is to omit the parameter for SHA-1 and include
>a NULL for MD5 (see S 2.1 and 2.2.).
>
>However, the current PKCS#1 errata
>(ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1errata.txt)
>recommend that when one is encoding DigestInfo, one should
>encode it as NULL:
>
>   Exception: When formatting the DigestInfoValue in EMSA-PKCS1-V1.5
>   (see 9.2), the parameters field associated with id-sha1, id-sha256,
>   id-sha384 and id-sha512 SHALL have a value of type NULL. This is to
>   maintain compatibility with existing implementations and with the
>   numeric information values already published for EMSA-PKCS1-V1.5
>   which are also reflected in IEEE 1363a-2004[27].
>
>My understanding from discussions in Prague is that this reflects
>NIST's current guidance as well.
>
>Technically these don't conflict, but obviously, it's undesirable to
>have the encoding in the message not match that in the DigestInfo,
>since doing binary comparisons is common practice here. So, what's the
>right answer here?
>
>-Ekr



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l36K8mmS018487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Apr 2007 13:08:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l36K8mrS018486; Fri, 6 Apr 2007 13:08:48 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from laser.networkresonance.com (74-95-2-162-SFBA.hfc.comcastbusiness.net [74.95.2.162] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l36K8l7s018473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Apr 2007 13:08:47 -0700 (MST) (envelope-from [e-mail])
Received: from raman.networkresonance.com (unknown [74.95.2.163]) by laser.networkresonance.com (Postfix) with ESMTP id 2B7F15C027; Fri,  6 Apr 2007 13:08:07 -0700 (PDT)
Date: Fri, 06 Apr 2007 13:09:27 -0700
From: Eric Rescorla <[e-mail]>
To: Blake Ramsdell <[e-mail]>
Cc: Eric Rescorla <[e-mail]>, [e-mail], [e-mail]
Subject: Re: AlgorithmIdentifier, SHA-1, etc.
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
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>

At Fri, 06 Apr 2007 13:02:58 -0700,
Blake Ramsdell wrote:
> 
> Eric Rescorla wrote:
> > Technically these don't conflict, but obviously, it's undesirable to
> > have the encoding in the message not match that in the DigestInfo,
> > since doing binary comparisons is common practice here. So, what's the
> > right answer here?
> 
> In my case when I receive a digest AlgorithmIdentifier, I bust it open 
> and get the OID out and discard the wrapper (the outer 
> AlgorithmIdentifier). So I'm not affected by a mismatch if I do that.
> 
> But yeah, short of normalizing the values in some way, you're pretty 
> much done. That is, there's no binary comparison, and you perform an 
> equivalence check by converting both values in such a way that the same 
> answer comes out. So if you have { sha-1, NULL } and { sha-1 } you get 
> the same answer.

Yeah, my thinking is that it would be better for these to match
so that naive implementations work.

-Ekr



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l36K3N27018237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Apr 2007 13:03:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l36K3NHl018235; Fri, 6 Apr 2007 13:03:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from foon.sendmail.com (smtp-out.sendmail.com [209.246.26.45]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l36K32Bw018210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 6 Apr 2007 13:03:22 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.0.4] (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) (authenticated bits=0) by foon.sendmail.com (Switch-3.2.5/Switch-3.2.0) with ESMTP id l36K5jaW030920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 6 Apr 2007 13:05:46 -0700
X-DKIM: Sendmail DKIM Filter v0.5.1 foon.sendmail.com l36K5jaW030920
DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=sendmail.com; s=tls.dkim; t=1175889948; bh=aVUBogemJPBCmvA6TmGQBDPKvVw=; h=X-DomainKeys: DomainKey-Signature:Message-ID:Date:From:User-Agent:MIME-Version: To:CC:Subject:References:In-Reply-To:Content-Type: Content-Transfer-Encoding; b=P8zcssmaxmJQn2uS2mduKb+pZqYph502du+Rhj oz4yZfQaArDkNt7AfRsfFo5FSvLAAC1CFH7rfPqj6sUMw4CObhoW2wsWI5GfPXIbLvC Gvuwm3xeBdUzwpvrgGrOBRWDRitcAzYrL0vH08tYsyv4+tiA0XtFvZFj2flnI2dT9o=
X-DomainKeys: Sendmail DomainKeys Filter v0.4.1 foon.sendmail.com l36K5jaW030920
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=M7QxpsVFvlDXTcT5fBvQfqV4pzi8V2LciIPs1Mr4TkNwYbmHCLgP25WxWutq8Tfca UIJAoXLOcUuro2ug33LJ5hdBmAtdYg/0yQCgktOuYBdouWnS4c/noP3Slxw+cDB1u4b AlbcVO/fyzIZ9O5Zl69vGmDx2GwEh45JB7/V3WY=
Message-ID: <[e-mail]>
Date: Fri, 06 Apr 2007 13:02:58 -0700
From: Blake Ramsdell <[e-mail]>
User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221)
MIME-Version: 1.0
To: Eric Rescorla <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: AlgorithmIdentifier, SHA-1, etc.
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; 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>

Eric Rescorla wrote:
> Technically these don't conflict, but obviously, it's undesirable to
> have the encoding in the message not match that in the DigestInfo,
> since doing binary comparisons is common practice here. So, what's the
> right answer here?

In my case when I receive a digest AlgorithmIdentifier, I bust it open 
and get the OID out and discard the wrapper (the outer 
AlgorithmIdentifier). So I'm not affected by a mismatch if I do that.

But yeah, short of normalizing the values in some way, you're pretty 
much done. That is, there's no binary comparison, and you perform an 
equivalence check by converting both values in such a way that the same 
answer comes out. So if you have { sha-1, NULL } and { sha-1 } you get 
the same answer.

Blake
-- 
Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l36IU9Pl009908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Apr 2007 11:30:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l36IU9A8009907; Fri, 6 Apr 2007 11:30:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from laser.networkresonance.com (74-95-2-162-SFBA.hfc.comcastbusiness.net [74.95.2.162] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l36IU8Dj009894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Apr 2007 11:30:08 -0700 (MST) (envelope-from [e-mail])
Received: from raman.networkresonance.com (unknown [74.95.2.163]) by laser.networkresonance.com (Postfix) with ESMTP id 6C6E65C02B; Fri,  6 Apr 2007 11:29:28 -0700 (PDT)
Date: Fri, 06 Apr 2007 11:30:49 -0700
From: Eric Rescorla <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: AlgorithmIdentifier, SHA-1, etc.
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
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>

I'm trying to get a handle on how one ought to encode AlgorithmIdentifier.

As people will perhaps remember, the ASN.1 is:


AlgorithmIdentifier  ::=  SEQUENCE  {
     algorithm               OBJECT IDENTIFIER,
     parameters              ANY DEFINED BY algorithm OPTIONAL  }
                                -- contains a value of the type
                                -- registered for use with the
                                -- algorithm object identifier value

Present hash functions do not take any useful parameters, leaving
us with two encoding options:

  - omit the parameter.
  - include a NULL

To make things more complicated, there are (at least) two different
contexts in which this production appears:

  - The S/MIME DigestAlgorithmIdentifier production.
  - Inside the DigestInfo of the S/MIME signature.

RFC 3370's guidance is to omit the parameter for SHA-1 and include
a NULL for MD5 (see S 2.1 and 2.2.).

However, the current PKCS#1 errata
(ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1errata.txt)
recommend that when one is encoding DigestInfo, one should
encode it as NULL:

  Exception: When formatting the DigestInfoValue in EMSA-PKCS1-V1.5 
  (see 9.2), the parameters field associated with id-sha1, id-sha256, 
  id-sha384 and id-sha512 SHALL have a value of type NULL. This is to 
  maintain compatibility with existing implementations and with the 
  numeric information values already published for EMSA-PKCS1-V1.5 
  which are also reflected in IEEE 1363a-2004[27].

My understanding from discussions in Prague is that this reflects
NIST's current guidance as well.

Technically these don't conflict, but obviously, it's undesirable to
have the encoding in the message not match that in the DigestInfo,
since doing binary comparisons is common practice here. So, what's the
right answer here?

-Ekr






Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l35KvAKv087512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Apr 2007 13:57:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l35KvALm087510; Thu, 5 Apr 2007 13:57:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l35KulrD087491 for <[e-mail]>; Thu, 5 Apr 2007 13:57:09 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 18219 invoked by uid 0); 5 Apr 2007 20:56:40 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.66.14.186) by woodstock.binhost.com with SMTP; 5 Apr 2007 20:56:40 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 05 Apr 2007 16:56:08 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt 
In-Reply-To: <[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>

I believe that this document and the companion document that tells 
how to use AES-CCM and AES-GCM are ready for WGLC.

Russ


At 03:50 PM 4/5/2007, [e-mail] wrote:
>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           : Cryptographic Message Syntax (CMS) 
> Authenticated-Enveloped-Data Content Type
>         Author(s)       : R. Housley
>         Filename        : draft-ietf-smime-cms-auth-enveloped-03.txt
>         Pages           : 11
>         Date            : 2007-4-5
>
>This document describes an additional content type for the
>    Cryptographic Message Syntax (CMS).  The authenticated-enveloped-data
>    content type is intended for use with authenticated encryption modes.
>    All of the various key management techniques that are supported in
>    the CMS enveloped-data content type are also supported by the CMS
>    authenticated-enveloped-data content type.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-auth-enveloped-03.txt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l35JoO84081695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Apr 2007 12:50:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l35JoO5Z081694; Thu, 5 Apr 2007 12:50:24 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ns0.neustar.com (ns0.neustar.com [156.154.16.158]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l35Jo3gq081678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 5 Apr 2007 12:50:24 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 95829329C2; Thu,  5 Apr 2007 19:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HZXy6-000469-FB; Thu, 05 Apr 2007 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt 
Message-Id: <[e-mail]>
Date: Thu, 05 Apr 2007 15:50:02 -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		: Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-cms-auth-enveloped-03.txt
	Pages		: 11
	Date		: 2007-4-5
	
This document describes an additional content type for the
   Cryptographic Message Syntax (CMS).  The authenticated-enveloped-data
   content type is intended for use with authenticated encryption modes.
   All of the various key management techniques that are supported in
   the CMS enveloped-data content type are also supported by the CMS
   authenticated-enveloped-data content type.

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

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-cms-auth-enveloped-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-cms-auth-enveloped-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-cms-auth-enveloped-03.txt

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

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

--OtherAccess--

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l33KU8jj093631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Apr 2007 13:30:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l33KU86s093630; Tue, 3 Apr 2007 13:30:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l33KTlDa093610 for <[e-mail]>; Tue, 3 Apr 2007 13:30:08 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 4371 invoked by uid 0); 3 Apr 2007 20:29:40 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.66.14.186) by woodstock.binhost.com with SMTP; 3 Apr 2007 20:29:40 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 03 Apr 2007 16:29:43 -0400
To: [e-mail]
From: [e-mail] (by way of Russ Housley <[e-mail]>)
Subject: Gen-ART review of draft-martin-ibcs-03
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 have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call
comments you may receive.

Document: draft-martin-ibcs-03
Reviewer: David L. Black
Review Date: April 3, 2007
IETF LC End Date: April 9, 2007

Summary:

This draft is on the right track, but has open issues, described
in the review.

Comments:

The draft contains an immense amount of cryptographic mathematics,
beyond what is reasonably possible for me to review in detail.
The draft needs detailed review by an expert cryptographer to
look for subtle errors in the notation and mathematics - this
is not such a review.

The draft has a number of open issues - the most important are:
[1] Lack of hash agility
[2] Lack of IPR disclosures
[3] Use of a stream cipher without discussion of protection
	against <key, IV> reuse.
These three items are tagged with their numbers below.

In addition, there is no discussion of rekeying - based on [3]
it will be necessary to change the "key" for an identity in order
to avoid collisions.  In order to do that it will be necessary
to change the "possibly augmented with a time stamp and other
attributes" identity material alluded to in the definition of
Identity in section 2.  This is not discussed or specified.

There is no guidance about use of the mechanisms in this document.
It is *very* important to understand that the ability to encrypt
or decrypt on behalf of an identity is not proof of that identity,
and hence the mechanisms described in this draft MUST NOT be used
for authentication purposes, and any identity used with these
mechanisms MUST be authenticated or verified by other means.

The architecture behind this work envisions a key server that
would have to impose access controls on its clients if there is
a  need to enforce trust restrictions that prevent an arbitrary
client from encrypting/decrypting on behalf of an arbitrary
identity.  This topic is not discussed in the draft.

[1] The most important issue is that algorithms in this draft
lack secure hash agility - SHA1 is hard-coded as the only hash
supported, and the ASN.1 module in this draft does not contain
any information to identify the hash that was used.  This
is a very bad design practice, particularly as the security
considerations section describes how SHA1 collisions can be
used to attack the techniques in this draft (i.e., pre-images
are not necessary to mount an attack), so the possibility of
needing to change the hash algorithm is realistic.  If it is
necessary to approve this draft as submitted, the IESG should
add a strong statement expressing disapproval of the lack of
hash agility and strongly discouraging non-hash-agile designs.

[2] I do not see any IPR disclosures for this draft - a search
for Voltage Security as the Assignee at the USPTO suggests that
an IPR Disclosure may be required.  The IESG should obtain an
explicit affirmative assurance from the draft authors that they
have complied with the IPR disclosure provisions of RFC 3979,
and should withhold approval of this draft until that assurance
is obtained.  In addition, due to this draft's extensive use of
elliptic curve cryptography, efforts should be made to obtain
either an IPR disclosure from Certicom or a third-party IPR
Disclosure from the draft authors regarding Certicom's patent
portfolio.

The security considerations (section 13) describe parameters
for 3 cryptographic strength levels, 80-bit, 112-bit, and
128-bit, but the algorithm in Section 5.1.1 only supports the
80-bit level.  This needs to be explained in the security
considerations section or corrected in Section 5.1.1.  Also,
the absence of levels of security beyond 128-bit in this
discussion renders this draft incomplete by comparison to
other IETF work that includes the 256-bit level of security.
SHA1 will not be usable to realize 256-bit level security,
see issue [1] above.

The use of ASN.1 as the standard output encoding is unfortunate.
With the exception of certificates (where ASN.1 is a necessity),
ASN.1 is not the most convenient format for usage in IETF
protocols.

There appear to be a number of unstated range or boundary
assumptions on the numbers used in this draft.  Here are two
examples:
- The final modulus computation in Section 4.1 is questionable
	if n has an order of magnitude close to that of v_1.
	That computation appears to be assuming that v_1 is
	>>>> (much, much, much, much larger) than n.
- Algorithm 4.1 will misbehave badly if its input n is <= 1.
	This is an example of what appear to be multiple failures
	to range-check the input to the lg() function - the draft
	needs an editing pass to range-check the inputs to all
	instances of the lg() function.
The entire draft needs to be checked for all similar unstated
assumptions, and statements of them need to be added, including
adding algorithm checks for violations of them.

I asked a cryptographer (Landon Noll, Neoscale) to take a look
at the draft.  In addition to the boundary conditions discussed
above, he found a number of other things in a brief review:
- Sections 4.1 and 4.2 reinvent cryptographic mechanisms that
   are already well-known.  It is not clear why this reinvention
   is being done or whether the results are as sound as the
   existing mechanisms.  Specifically:
	- For Section 4.1, see FIPS publication 800-90 (updated
		March 13, 2007) for a random bit generator that can
		be used to realize this function.
	- For Section 4.2, see Annex C of FIPS 140-2 (updated
		March 19, 2007).
- The function HashToRangeq() is used in several places - it's
	apparently a specific instantiation of HashtoRangen()
	defined in Section 4.1, but this notation is problematic,
	for example, HashtoRange-n() and HashtoRange-q() would be
	better.  Is the "-n" or "-q" here required to be identical
	to the second argument of this function?
- Section 5.4 says:
         3. Select s random 160-bit vector rho, represented as
		20-byte string in big-endian convention.
	This is ambiguous about whether rho is a single vector or
	a sequence of s vectors - based on step 12, the latter
	appears to have been intended, in which case "vector" should
	be "vectors" and "string" should be "strings", but then step
	11 needs to be clarified to only use the first vector.  The
	other possibility is that "s random" should have been "a
	random, and step 12 is wrong (see below).  Why does the
	representation of rho (big-endian) need to be specified,
	as rho is internal to this algorithm?
- Section 5.5: In steps 5 and 6, should V, W and w instead be
	V', W' and w' respectively?
- Section 5.4, step 12: should "W = HashStream(|m|, rho XOR m)"
	instead be "W = HashStream(|m|, rho) XOR m" ?  The latter is
	consistent with the corresponding decryption step (5.5, step
	6), whereas the former appears to use the message as part of
	the IV for keystream generation, which is peculiar.
- [3] The encryption and decryption operations in this draft are
	stream ciphers, but this draft contains no warnings about
	or defenses against <key, IV> collisions for stream ciphers.
	That's not acceptable.  Correcting this will require
	additions to the requirements on the generation of
	rho in section 5.4.  Using a non-repeating salt as part
	of the IV (e.g., as is done in GCM) is one possibility.

Minor Issue: The draft uses the word "believed" in several places
to assert the strength of the cryptographic mechanisms it
describes. The draft should cite references in support of
this belief.

Important Nit: The algorithm numbers do not match the section
numbers (e.g., Algorithm 3.5.2 is in section 3.5.1).  They
should be aligned in order to improve readability.

Nit: lg(x) is the base-2 logarithm.  This needs to be added
to the notation section.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
[phone]             FAX: [phone]
[e-mail]        Mobile: [phone]
----------------------------------------------------