Subject: Re: Order status

From: <[email-masked]>
Date: Sun, 30 Nov 2008 17:26:49 -0800 (PST)

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAM8b1XX008465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 22 Nov 2008 01:37:01 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAM8b1ZF008464; Sat, 22 Nov 2008 01:37:01 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from pne-smtpout1-sn2.hy.skanova.net (pne-smtpout1-sn2.hy.skanova.net [81.228.8.83]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAM8aoak008445 for ; Sat, 22 Nov 2008 01:37:01 -0700 (MST) (envelope-from [email-masked])
Received: from AndersPC (81.232.45.215) by pne-smtpout1-sn2.hy.skanova.net (7.3.129) id 48A144C501AE708E for [email-masked]; Sat, 22 Nov 2008 09:36:50 +0100
Message-ID:
From: "Anders Rundgren"
To:
Subject: Slamming S/MIME. Re: How-to guide for email encryption
Date: Sat, 22 Nov 2008 09:36:52 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_006D_01C94C85.D9E3DC00"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6000.20661
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

This is a multi-part message in MIME format.

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

>From a recent Mozilla discussion...

Services like Skype already provide end-to-end encryption to hundreds of =
millions of users without any need for a guide or so.

S/MIME encryption OTOH is a dated off-line scheme requiring message =
encryption and decryption, while still not addressing core issues such =
as who is talking to who, although that becomes fairly irrelevant since =
there are no users worth mentioning.

It is in this context worth mentioning that governments in the EU are =
creating WS*-based messaging frameworks that (within their own community =
at least) offer transparent encryption and signatures. Due to the fact =
that governments should not indulge in secret actions (excluding CIA =
here), encryption at the service level is exactly what they want; i.e. =
you should be able to see what has been exchanged based on logging.

How can you trust a service? I don't have a conclusive answer to that =
except that this is a fact, otherwise Microsoft Live, Google mail, and =
hundreds of thousands of other "cloud computing" services wouldn't =
exist.

Another related issue is secure citizen-to-government communication. In =
the EU, practically all states work with centralized mail-boxes on the =
web to which you authenticate to. My own work FWIW, is very much =
focused on these developments because they have proved to scale and are =
in fact just government versions of Microsoft's and Google's stuff.

Please go ahead with S/MIME but be aware that the odds that you succeed =
are extremely low. If I had an interest in scalable secure end-to-end =
messaging, I would start with a blank piece of paper and see what the =
options are. In case you do, please send me the draft because I'm still =
a little bit curious at least :-)

Sincerely
Anders Rundgren
------=_NextPart_000_006D_01C94C85.D9E3DC00
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

From a recent Mozilla =
discussion...

Services like Skype already provide =
end-to-end=20
encryption to hundreds of millions of users without any need for a guide =
or=20
so.

S/MIME encryption OTOH is a dated =
off-line scheme=20
requiring message encryption and decryption, while still not addressing =
core=20
issues such as who is talking to who, although that becomes fairly =
irrelevant=20
since there are no users worth mentioning.

It is in this context worth mentioning =
that=20
governments in the EU are creating WS*-based messaging frameworks that =
(within=20
their own community at least) offer transparent encryption and=20
signatures.   Due to the fact that governments should not =
indulge in=20
secret actions (excluding CIA here), encryption at the service level is =
exactly=20
what they want; i.e. you should be able to see what has been exchanged =
based on=20
logging.

How can you trust a service?  I =
don't have a=20
conclusive answer to that except that this is a fact, otherwise =
Microsoft=20
Live, Google mail, and hundreds of thousands of other "cloud =
computing"=20
services wouldn't exist.

Another related issue is secure=20
citizen-to-government communication.  In the EU, practically all =
states=20
work with centralized mail-boxes on the web to which you authenticate =
to. =20
My own work FWIW, is very much focused on these developments because =
they have=20
proved to scale and are in fact just government versions of Microsoft's =
and=20
Google's stuff.

Please go ahead with S/MIME but be =
aware that the=20
odds that you succeed are extremely low.   If I had an =
interest in=20
scalable secure end-to-end messaging, I would start with a blank =
piece of=20
paper and see what the options are.  In case you do, please send=20
me the draft because I'm still a little bit curious at least=20
:-)

Sincerely

Anders =
Rundgren

------=_NextPart_000_006D_01C94C85.D9E3DC00--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAKJjOoY029097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Nov 2008 12:45:24 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAKJjOiG029096; Thu, 20 Nov 2008 12:45:24 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp101.biz.mail.mud.yahoo.com (smtp101.biz.mail.mud.yahoo.com [68.142.200.236]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mAKJjDIT029068 for ; Thu, 20 Nov 2008 12:45:23 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 45920 invoked from network); 20 Nov 2008 19:45:12 -0000
Received: from unknown (HELO Wylie) ([email-masked] with login) by smtp101.biz.mail.mud.yahoo.com with SMTP; 20 Nov 2008 19:45:12 -0000
X-YMail-OSG: W4GEGooVM1lL2xKV2viPjF4bS.LhPbhHdlMV0z9FbGlDZcNa1_sRpJtqvewpgzglalzrqwKaZ4ZT6fS7hzzWbj7zO09ZNgTeLxIDHbvFfD.9ReGIBr7IewaLxrM5VYOJgzB_8P8DmAqTW_eXSfc1nnrNwIezFQCvMzbmt55J
X-Yahoo-Newman-Property: ymail-3
From: "Turner, Sean P."
To: "secdir"
Cc:
Subject: SMIME WG summary
Date: Thu, 20 Nov 2008 13:44:47 -0600
Organization: IECA, Inc.
Message-ID: <6C0AE36C1E164AA5AF1A6EAAA3A08991@Wylie>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
thread-index: AclLSHHdw4pey/R4Q1SH0WsjF38iLA==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

The SMIME WG did not meeting at IETF 73. The SMIME WG has 9 IDs. Here is
the status of those IDs:

In RFC Editors Queue:

- draft-ietf-smime-multisig: Pinned on draft-ietf-smime-3850bis &
draft-ietf-smime-3850bis IDs.
- draft-ietf-smime-ibearch: In EDIT state.
- draft-ietf-smime-bfibecms: In EDIT state.

With AD (status: Passed IETF LC)
- draft-ietf-smime-3850bis: Awaiting GEN-ART comments
- draft-ietf-smime-3851bis: Addressed IETF LC comments.
Will publish when GEN-ART comments on
draft-ietf-smime-3850bis are addressed.

With AD (status: In 2nd IETF LC):
- draft-ietf-smime-sha2: No comments so far.

With AD (status: Awaiting new ID from authors):
- draft-ietf-smime-rfc3278-update: Addressing WG LC comments.
New version published shortly after
meeting. Expected to go to WG LC.
- draft-ietf-smime-cms-rsa-kem: A new version was posted, but another
is needed to address Steve Kent's
SECDIR comments.

With WG
- draft-ietf-smime-new-asn1: This ID updates many/most of the ASN.1
modules in the S/MIME WG to the '02 ASN.1. The authors want
reviewers. It is expected that the ID will be ready for WG LC
in December '08.

spt

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAEIXMth002666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Nov 2008 11:33:22 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAEIXMP6002665; Fri, 14 Nov 2008 11:33:22 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp104.biz.mail.re2.yahoo.com (smtp104.biz.mail.re2.yahoo.com [206.190.52.173]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mAEIXAXQ002650 for ; Fri, 14 Nov 2008 11:33:21 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 19528 invoked from network); 14 Nov 2008 18:33:10 -0000
Received: from unknown (HELO Wylie) ([email-masked] with login) by smtp104.biz.mail.re2.yahoo.com with SMTP; 14 Nov 2008 18:33:10 -0000
X-YMail-OSG: nXSJSEsVM1mCmHfjO7KfIONDbCSHd4u0jqy729vcHQ4e6lbB0gW08SaRyMgU1wjsdey9xdrtYdUWARbe77a8eD5miX5gDxzJEL_BIl7xaX1MmbPDPYtdihPDYBo8.yPSzJHwuwWWUhF3O4EMvMWWvLi3B5yC0s1cwkZ9l4s_JlRKpXacAeI4NlwNa9IQ
X-Yahoo-Newman-Property: ymail-3
From: "Turner, Sean P."
To: "=?iso-8859-1?Q?'Alfred_H=CEnes'?=" ,
References: <[email-masked]>
Subject: RE: draft-ietf-smime-3278bis-03 incremental review
Date: Fri, 14 Nov 2008 13:32:53 -0500
Organization: IECA, Inc.
Message-ID:
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Thread-Index: AclF9nJgcRuG/gDXSjGaTLFVj4BDLAAkNUyg
In-Reply-To: <[email-masked]>
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Alfred,

I should have a version that incorporates all of you changes by the end =
of
next week.

spt=20

>-----Original Message-----
>From: [email-masked]=20
>[mailto:[email-masked]] On Behalf Of Alfred H=CEnes
>Sent: Thursday, November 13, 2008 7:51 PM
>To: [email-masked]
>Subject: draft-ietf-smime-3278bis-03 incremental review
>
>
>Folks,
>I have performed another (incremental) review of
> draft-ietf-smime-3278bis-03
>and I apologize that it could not be completed in time.
>Nevertheless, I hope it will still be useful.
>
>The only significant proposal I have is based on the=20
>observation that the change information vs. RFC 3278 has grown=20
>to an extent that it better should be moved to the end of the=20
>document (new Appendix B ?).
>The carefully collected information there should be kept in=20
>this detail for historical record, and to educate implementors=20
>tackling software updates, but it now seems to over-stress the=20
>basic character of an Introduction.
>
>Beyond that, I found a bunch of editorials that will be sent=20
>off-list (ASAP, I hope tomorrow), after a final cross-checking=20
>with Sean's summary posted on 6 Nov 2008 (to remove potential=20
>redundancy).
>
>My primary conclusion is that the draft should go ahead after=20
>the next minor polishing update to address the comments.
>
>
>Sean and Dan: please still be patient for the details to come.
>
>
>Kind regards,
> Alfred H=CEnes.
>
>--=20
>
>+------------------------+--------------------------------------------+
>| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. |
>| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 |
>| D-71254 Ditzingen | E-Mail: [email-masked] |
>+------------------------+--------------------------------------------+
>

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAEBdYQp078472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Nov 2008 04:39:34 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAEBdYoR078471; Fri, 14 Nov 2008 04:39:34 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from ganymede.on-x.com (ganymede.on-x.com [194.51.68.3]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAEBdLjJ078430 for ; Fri, 14 Nov 2008 04:39:32 -0700 (MST) (envelope-from [email-masked])
Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id 009DF2E; Fri, 14 Nov 2008 12:39:17 +0100 (CET)
Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2008111412391565:218695 ; Fri, 14 Nov 2008 12:39:15 +0100
Message-ID: <[email-masked]>
Date: Fri, 14 Nov 2008 12:36:07 +0100
From: Peter Sylvester
User-Agent: Thunderbird 1.5.0.9 (X11/20061206)
MIME-Version: 1.0
Cc: [email-masked], [email-masked], [email-masked]
Subject: Last Call: draft-ietf-smime-3851bis (Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification) to Proposed Standard
References: <[email-masked]> <6A85CB8D97994AB496262EFF38FD178B@Wylie> <[email-masked]>
In-Reply-To:
X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 11/14/2008 12:39:15 PM, Serialize by Router on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 11/14/2008 12:39:16 PM, Serialize complete at 11/14/2008 12:39:16 PM
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000108070309040400080706"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

This is a cryptographically signed message in MIME format.

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

Hi

Would it be possible to add a comment concerning the multipart/signed
creation
or better some section mulipart/signed parsing that a system should nicely
treat a multipart/signed message that has more than two parts.

It may be not the right doc, probably better in CMS.

it happens that some firewalls add "disclaimers" as an additional body-part
as soon as they see that the top level mime is multipart/*

At least one well known user agent refuses to show such messages.

TIA for consideration.
Peter Sylvester

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOhTCC
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
UJzWSwWBel1QRyETQNwwggWVMIIDMKADAgECAgYKwoI0lJgwDQYJKoZIhvcNAQEFBQAwUjEL
MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL
STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDcwNjI4MTc0MDU0WhcNMTQwNTAyMTc0
MDU0WjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj
ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI
hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M
ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe
1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt
qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd
UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH
pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS
cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB
CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4GgMIGdMDoGA1UdHwQzMDEwL6AtoCuGKWh0
dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C
AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAfBgNV
HSMEGDAWgBSo2SuP1LBnur1JXLwz/HdSEblnnTANBgkqhkiG9w0BAQUFAAOCAk4AUgtIR4Jh
Ynyk939SM6X4YZPNYIgDio8Gp064P1MBILDgI/hzSwyxT5bb1qUQub+icXO9/5ufsDufr/ff
2gCzKMuo3hC26iey630PzHTvJgrTcEp9c92IZPt3UKeouqy+95Lz2r58dbfouKLZVwiKQ0jP
2c2U5tPWmzW4CAjFWUKRYlrhbt+tjzW8CAA0DHO1xrrzAuTyuGNKcH4LlLuVo7MbDPn/uLma
1fAVYvH2c6OTwGHJyKTQVveYw4UqgAhErJMFWJDKm+Q9h91mCzkjrA1Eu0nVDUTV1+dW6mNT
DPLIq0qSdqP7iT2WcNzQVy/0PiXT2aaEH9lE2W1SSD6PnT8y+aqJTGjRMK1cl7VSJHxbq8U9
lIS+6eiV5VrogAa8X52pKF0u91i+/CBZ3e5Mi2/BwMrMN/mXA/ZwL3p+jZpnijpqnqdz8iCn
qR9ExhR+BpN/b56RqEu7llLrcwOS44kjbubALjxe0+XutidWjt/6/tLYuM7rJ6Hk1EweFGVd
kRejKogD3GzZ3gOAIF/D28VBJcTRcyF7OI/k/3jPD0gHUGN1uxk2Krz8SE9GEPvP/JehCBl/
FrQOCsEUmszi7Se0Vxr2k1P7icxT7L/AcWt/djIgp/vsQNurbi0+5+q7YS2b2bc1HchjsmaI
cXy8ha5IGk4+F1qrHZsGqTm5M7TzZN6k0X2llMaozrtPzxNMC6uvf1uRvHYHf1x0Q0pdxTzZ
PuuFw1PUlu6o5xPHbf3ZgC7ZNSDry13ZEXmlG2Re0u9WwEJJ1nYqlcDvNzGCAq4wggKqAgEB
MGUwWzELMAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2Ug
RWRlbFBLSTEgMB4GA1UEAxMXRWRlbFBLSSBFZGVsV2ViIFBlcnNHRU4CBgqvijKA3jAJBgUr
DgMCGgUAoIIBnzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w
ODExMTQxMTM2MDdaMCMGCSqGSIb3DQEJBDEWBBTTSDhAyDd5gascjzefTGI/bcIrMDBSBgkq
hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB
QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB0BgkrBgEEAYI3EAQxZzBlMFsxCzAJBgNVBAYT
AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV
BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wdgYLKoZIhvcNAQkQAgsxZ6Bl
MFsxCzAJBgNVBAYTAkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVk
ZWxQS0kxIDAeBgNVBAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wDQYJKoZI
hvcNAQEBBQAEgYBSJC3iw+YmQwBLHKJNk9mJzSsIeG7I08+EiBmKaw8fdkZ7uU/Jg++TIJTN
0H2e6lTxAl8dZqh5DuqQmOwV/LQwnv1V4EPmcp2KbVEmbkrKFtDc/W4ufzmgXvo65sbUeBn7
AtMyl9RF4M3LoWuW6IMsufBd8qdMcqNcG+9AbyZSDQAAAAAAAA==
--------------ms000108070309040400080706--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAE0qGZd047388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Nov 2008 17:52:16 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAE0qGY0047387; Thu, 13 Nov 2008 17:52:16 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAE0q3ZT047378 for ; Thu, 13 Nov 2008 17:52:15 -0700 (MST) (envelope-from [email-masked])
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA152433837; Fri, 14 Nov 2008 01:50:37 +0100
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id BAA19456; Fri, 14 Nov 2008 01:50:36 +0100 (MEZ)
From: Alfred =?hp-roman8?B?SM5uZXM=?=
Message-Id: <[email-masked]>
Subject: draft-ietf-smime-3278bis-03 incremental review
To: [email-masked]
Date: Fri, 14 Nov 2008 01:50:36 +0100 (MEZ)
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset=hp-roman8
Content-Transfer-Encoding: 8bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Folks,
I have performed another (incremental) review of
draft-ietf-smime-3278bis-03
and I apologize that it could not be completed in time.
Nevertheless, I hope it will still be useful.

The only significant proposal I have is based on the
observation that the change information vs. RFC 3278
has grown to an extent that it better should be moved
to the end of the document (new Appendix B ?).
The carefully collected information there should be kept
in this detail for historical record, and to educate
implementors tackling software updates, but it now seems
to over-stress the basic character of an Introduction.

Beyond that, I found a bunch of editorials that will be sent
off-list (ASAP, I hope tomorrow), after a final cross-checking
with Sean's summary posted on 6 Nov 2008 (to remove potential
redundancy).

My primary conclusion is that the draft should go ahead after
the next minor polishing update to address the comments.

Sean and Dan: please still be patient for the details to come.

Kind regards,
Alfred HÎnes.

--

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. |
| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 |
| D-71254 Ditzingen | E-Mail: [email-masked] |
+------------------------+--------------------------------------------+

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mADLrAe7039892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Nov 2008 14:53:10 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mADLrABV039891; Thu, 13 Nov 2008 14:53:10 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp107.biz.mail.re2.yahoo.com (smtp107.biz.mail.re2.yahoo.com [206.190.52.176]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mADLqwCZ039869 for ; Thu, 13 Nov 2008 14:53:09 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 90791 invoked from network); 13 Nov 2008 21:52:53 -0000
Received: from unknown (HELO Wylie) ([email-masked] with login) by smtp107.biz.mail.re2.yahoo.com with SMTP; 13 Nov 2008 21:52:53 -0000
X-YMail-OSG: 1H.4_.UVM1nQ3PUr2KitvORwKCU6AE2dZktgawIDRgkDagAzErh9YGDgySBKzhKiaFYutlPHT2TtDg.b4VsbsAB0GilRY6W8ks08_5yuwZ2pSj1BWEF_xKh7ABLwLLLB0oajMiXPwp3Wf9BkwTmXgFOfMfX5r45YvMcMeLLvjDFB7ve3.I_u3r_r0PML
X-Yahoo-Newman-Property: ymail-3
From: "Turner, Sean P."
To: "'Paul Hoffman'" , "'Russ Housley'" , ,
References: <[email-masked]> <6A85CB8D97994AB496262EFF38FD178B@Wylie> <[email-masked]>
Subject: RE: Last Call: draft-ietf-smime-3851bis (Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification) to Proposed Standard
Date: Thu, 13 Nov 2008 16:52:39 -0500
Organization: IECA, Inc.
Message-ID: <6DE25C581C4E42ED81E5E96388C19658@Wylie>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Thread-Index: AclF1GqQbAiaJSExT/+8S8a/2jE3qAAAdI+Q
In-Reply-To:
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

>-----Original Message-----
>From: Paul Hoffman [mailto:[email-masked]]
>Sent: Thursday, November 13, 2008 4:12 PM
>To: Russ Housley; Turner, Sean P.; [email-masked]; [email-masked]
>Subject: RE: Last Call: draft-ietf-smime-3851bis
>(Secure/Multipurpose Internet Mail Extensions (S/MIME) Version
>3.2 Message Specification) to Proposed Standard
>
>At 4:00 PM -0500 11/13/08, Russ Housley wrote:
>>>Wouldn't it be much simpler to say that the key wrap
>algorithm must be the same as the content encryption
>algorithm? Yes, one *might* want a keywrap of greater strength
>as you have above, but that forces implementations to have
>tables of what "greater" means. Saying they need to be the
>same is much more straight forward.
>>
>>The keysize could be the same, but the mode will probably be
>different. One would not want to use AES Key Wrap for the content.
>
>Sorry, of course. I meant "same underlying encryption
>function", not "same algorithm".

Paul,

Yes, it would be simpler.

When DH ephemeral-static is used, a key wrap algorithm is also specified in
the KeyEncryptionAlgorithmIdentifier [CMS]. The underlying encryption
functions for the key wrap and content encryption algorithms ([CMSALG] and
[CMSAES]) and the key sizes for the two algorithms MUST be the same (e.g.,
AES 128 key wrap algorithm with AES 128 content encryption algorithm). As
AES 128 CBC is the mandatory to implement content encryption algorithm thus,
when DH ephemeral-static is supported, AES-128 key wrap algorithm MUST also
be supported.

spt

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mADLBjZB038133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Nov 2008 14:11:45 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mADLBi2P038132; Thu, 13 Nov 2008 14:11:44 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mADLBa2o038112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Nov 2008 14:11:37 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <6A85CB8D97994AB496262EFF38FD178B@Wylie> <[email-masked]>
Date: Thu, 13 Nov 2008 13:11:34 -0800
To: Russ Housley , "Turner, Sean P." , ,
From: Paul Hoffman
Subject: RE: Last Call: draft-ietf-smime-3851bis (Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification) to Proposed Standard
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At 4:00 PM -0500 11/13/08, Russ Housley wrote:
>>Wouldn't it be much simpler to say that the key wrap algorithm must be the same as the content encryption algorithm? Yes, one *might* want a keywrap of greater strength as you have above, but that forces implementations to have tables of what "greater" means. Saying they need to be the same is much more straight forward.
>
>The keysize could be the same, but the mode will probably be different. One would not want to use AES Key Wrap for the content.

Sorry, of course. I meant "same underlying encryption function", not "same algorithm".

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mADL0qfo037612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Nov 2008 14:00:52 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mADL0qPO037611; Thu, 13 Nov 2008 14:00:52 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mADL0fNw037593 for ; Thu, 13 Nov 2008 14:00:51 -0700 (MST) (envelope-from [email-masked])
Message-Id: <[email-masked]>
Received: (qmail 20543 invoked by uid 0); 13 Nov 2008 21:00:34 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.143.189) by woodstock.binhost.com with SMTP; 13 Nov 2008 21:00:34 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 13 Nov 2008 16:00:37 -0500
To: Paul Hoffman , "Turner, Sean P." , ,
From: Russ Housley
Subject: RE: Last Call: draft-ietf-smime-3851bis (Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification) to Proposed Standard
In-Reply-To:
References: <[email-masked]> <6A85CB8D97994AB496262EFF38FD178B@Wylie>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

> >One thing I noted is that to ensure interoperability of the SHOULD- for the
> >DH ephemeral-static requirement we need to pick a MUST key wrap algorithm
> >(note that E-S DH was a SHOULD in RFC 3851 but RFC 3851 did not include
> >requirements for a key wrap algorithm). The text should not only indicate
> >which key wrap algorithms to use but what kind of content encryption keys
> >the algorithm is "good" for. I suggest adding the following text to Section
> >2.3 right after the bullets (all of the references were already normative
> >references):
> >
> >When DH ephemeral-static is used, a key wrap algorithm is also specified in
> >the KeyEncryptionAlgorithmIdentifier [CMS]. When DH ephemeral-static is
> >used with an AES content encryption algorithm (see Section 2.7), the key
> >wrap algorithm MUST be an AES key wrap algorithm from [CMSAES]. When DH
> >ephemeral-static is used with the Triple DES content encryption algorithm
> >(see Section 2.7), the key wrap algorithm MUST be either Triple DES key wrap
> >from [CMSALG] or one of the AES key wraps from [CMSAES]. The strength of
> >the key wrap algorithm MUST be as strong as the content encryption
> >algorithm:
> >
> >- The Triple-DES key wrap algorithm can be used with the Triple-DES content
> > encryption algorithm,
> >- The AES 128 key wrap algorithm can be used with The Triple-DES and AES 128
> > content encryption algorithms,
> >- The AES 192 key wrap algorithm can be used with The Triple-DES, AES 128,
> > and AES 192 content encryption algorithms,
> >- The AES 256 key wrap algorithm can be used with The Triple-DES, AES 128,
> > AES 192, and AES 256 content encryption algorithms.
>
>Wouldn't it be much simpler to say that the key wrap algorithm must
>be the same as the content encryption algorithm? Yes, one *might*
>want a keywrap of greater strength as you have above, but that
>forces implementations to have tables of what "greater" means.
>Saying they need to be the same is much more straight forward.

The keysize could be the same, but the mode will probably be
different. One would not want to use AES Key Wrap for the content.

Russ

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mADKjuHa036988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Nov 2008 13:45:56 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mADKju5Y036986; Thu, 13 Nov 2008 13:45:56 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mADKjm4r036974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Nov 2008 13:45:49 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To: <6A85CB8D97994AB496262EFF38FD178B@Wylie>
References: <[email-masked]> <6A85CB8D97994AB496262EFF38FD178B@Wylie>
Date: Thu, 13 Nov 2008 12:45:46 -0800
To: "Turner, Sean P." , ,
From: Paul Hoffman
Subject: RE: Last Call: draft-ietf-smime-3851bis (Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification) to Proposed Standard
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At 1:05 PM -0500 11/13/08, Turner, Sean P. wrote:
>One thing I noted is that to ensure interoperability of the SHOULD- for the
>DH ephemeral-static requirement we need to pick a MUST key wrap algorithm
>(note that E-S DH was a SHOULD in RFC 3851 but RFC 3851 did not include
>requirements for a key wrap algorithm). The text should not only indicate
>which key wrap algorithms to use but what kind of content encryption keys
>the algorithm is "good" for. I suggest adding the following text to Section
>2.3 right after the bullets (all of the references were already normative
>references):
>
>When DH ephemeral-static is used, a key wrap algorithm is also specified in
>the KeyEncryptionAlgorithmIdentifier [CMS]. When DH ephemeral-static is
>used with an AES content encryption algorithm (see Section 2.7), the key
>wrap algorithm MUST be an AES key wrap algorithm from [CMSAES]. When DH
>ephemeral-static is used with the Triple DES content encryption algorithm
>(see Section 2.7), the key wrap algorithm MUST be either Triple DES key wrap
>from [CMSALG] or one of the AES key wraps from [CMSAES]. The strength of
>the key wrap algorithm MUST be as strong as the content encryption
>algorithm:
>
>- The Triple-DES key wrap algorithm can be used with the Triple-DES content
> encryption algorithm,
>- The AES 128 key wrap algorithm can be used with The Triple-DES and AES 128
> content encryption algorithms,
>- The AES 192 key wrap algorithm can be used with The Triple-DES, AES 128,
> and AES 192 content encryption algorithms,
>- The AES 256 key wrap algorithm can be used with The Triple-DES, AES 128,
> AES 192, and AES 256 content encryption algorithms.

Wouldn't it be much simpler to say that the key wrap algorithm must be the same as the content encryption algorithm? Yes, one *might* want a keywrap of greater strength as you have above, but that forces implementations to have tables of what "greater" means. Saying they need to be the same is much more straight forward.

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mADI5S64023132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Nov 2008 11:05:28 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mADI5S91023131; Thu, 13 Nov 2008 11:05:28 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp109.biz.mail.re2.yahoo.com (smtp109.biz.mail.re2.yahoo.com [206.190.53.8]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mADI5HHj023096 for ; Thu, 13 Nov 2008 11:05:27 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 76522 invoked from network); 13 Nov 2008 18:05:16 -0000
Received: from unknown (HELO Wylie) ([email-masked] with login) by smtp109.biz.mail.re2.yahoo.com with SMTP; 13 Nov 2008 18:05:16 -0000
X-YMail-OSG: Ri.tU_gVM1m_idOWwjSdnYUy2kTDA3tdHEKziwqC7o5.8El79eiQasEt_7tHJ9H7AGpGPlGCCIfZuqlmwkVdTAkqs51YuwO.euS08PcIgI6RUnU126tvDKJO7slqEAKjKaD_ZkfSiDyRbtueS0ELKIKHJF8d8cZktQslvJgPMhiVobcHkDzvYRbzgwGW
X-Yahoo-Newman-Property: ymail-3
From: "Turner, Sean P."
To: ,
References: <[email-masked]>
Subject: RE: Last Call: draft-ietf-smime-3851bis (Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification) to Proposed Standard
Date: Thu, 13 Nov 2008 13:05:02 -0500
Organization: IECA, Inc.
Message-ID: <6A85CB8D97994AB496262EFF38FD178B@Wylie>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Thread-Index: Ack6rtPdEuque2DLR8yPNyX5TMydiwLCQuhA
In-Reply-To: <[email-masked]>
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

One thing I noted is that to ensure interoperability of the SHOULD- for the
DH ephemeral-static requirement we need to pick a MUST key wrap algorithm
(note that E-S DH was a SHOULD in RFC 3851 but RFC 3851 did not include
requirements for a key wrap algorithm). The text should not only indicate
which key wrap algorithms to use but what kind of content encryption keys
the algorithm is "good" for. I suggest adding the following text to Section
2.3 right after the bullets (all of the references were already normative
references):

When DH ephemeral-static is used, a key wrap algorithm is also specified in
the KeyEncryptionAlgorithmIdentifier [CMS]. When DH ephemeral-static is
used with an AES content encryption algorithm (see Section 2.7), the key
wrap algorithm MUST be an AES key wrap algorithm from [CMSAES]. When DH
ephemeral-static is used with the Triple DES content encryption algorithm
(see Section 2.7), the key wrap algorithm MUST be either Triple DES key wrap
from [CMSALG] or one of the AES key wraps from [CMSAES]. The strength of
the key wrap algorithm MUST be as strong as the content encryption
algorithm:

- The Triple-DES key wrap algorithm can be used with the Triple-DES content
encryption algorithm,
- The AES 128 key wrap algorithm can be used with The Triple-DES and AES 128
content encryption algorithms,
- The AES 192 key wrap algorithm can be used with The Triple-DES, AES 128,
and AES 192 content encryption algorithms,
- The AES 256 key wrap algorithm can be used with The Triple-DES, AES 128,
AES 192, and AES 256 content encryption algorithms.

spt

>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]] On Behalf Of The IESG
>Sent: Thursday, October 30, 2008 12:42 PM
>To: IETF-Announce
>Cc: [email-masked]
>Subject: Last Call: draft-ietf-smime-3851bis
>(Secure/Multipurpose Internet Mail Extensions (S/MIME) Version
>3.2 Message Specification) to Proposed Standard
>
>The IESG has received a request from the S/MIME Mail Security
>WG (smime) to consider the following document:
>
>- 'Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2
> Message Specification '
> as a Proposed Standard
>
>The IESG plans to make a decision in the next few weeks, and
>solicits final comments on this action.
>
>In particular, the IESG solicits comments on the cryptographic
>strength requirements specified in section 4.1 through 4.5,
>and the following statement from Section 6, Security Considerations:
>
> "Today, 512-bit RSA, DSA and DH keys are considered by many experts
> to be cryptographically insecure."
>
>These sections allow the continued use of RSA, DSA, and DH key
>lengths between 512 and 1024 bits. Given that other
>organizations are moving to a minimum key length of 2048 bits,
>the IESG wishes to verify IETF consensus for the cryptographic
>minimums in this document.
>
>Please send substantive comments to the
>[email-masked] mailing lists by 2008-11-13. Exceptionally,
>comments may be sent to [email-masked] instead. In either case,
>please retain the beginning of the Subject line to allow
>automated sorting.
>
>The file can be obtained via
>http://www.ietf.org/internet-drafts/draft-ietf-smime-3851bis-08.txt
>
>
>IESG discussion can be tracked via
>https://datatracker.ietf.org/public/pidtracker.cgi?command=view
>_id&dTag=16577&rfc_flag=0
>
>_______________________________________________
>IETF-Announce mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ietf-announce

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAAITw0L077518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Nov 2008 11:29:59 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAAITwkJ077517; Mon, 10 Nov 2008 11:29:58 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAAITwYM077510 for ; Mon, 10 Nov 2008 11:29:58 -0700 (MST) (envelope-from [email-masked])
Received: by core3.amsl.com (Postfix, from userid 0) id 34F5928C137; Mon, 10 Nov 2008 10:30:00 -0800 (PST)
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-cms-rsa-kem-06.txt
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[email-masked]>
Date: Mon, 10 Nov 2008 10:30:01 -0800 (PST)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

--NextPart

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

Title : Use of the RSA-KEM Key Transport Algorithm in CMS
Author(s) : J. Randall, B. Kaliski
Filename : draft-ietf-smime-cms-rsa-kem-06.txt
Pages : 23
Date : 2008-11-10

The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward)
mechanism for transporting keying data to a recipient using the
recipient's RSA public key. This document specifies the conventions
for using the RSA-KEM Key Transport Algorithm with the Cryptographic
Message Syntax (CMS). The ASN.1 syntax is aligned with ANS X9.44 and
ISO/IEC 18033-2.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
name="draft-ietf-smime-cms-rsa-kem-06.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"

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

--NextPart--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAAI3Tfw073759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Nov 2008 11:03:29 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAAI3TQr073758; Mon, 10 Nov 2008 11:03:29 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAAI3SCQ073751 for ; Mon, 10 Nov 2008 11:03:29 -0700 (MST) (envelope-from [email-masked])
Received: by core3.amsl.com (Postfix, from userid 30) id 6512128C0F6; Mon, 10 Nov 2008 10:03:31 -0800 (PST)
X-idtracker: yes
From: The IESG
To: IETF-Announce
Cc: Internet Architecture Board , RFC Editor , smime mailing list , smime chair
Subject: Document Action: 'Using the Boneh-Franklin and Boneh-Boyen identity-based Encryption Algorithms with the Cryptographic Message Syntax (CMS)' to Informational RFC
Message-Id: <[email-masked]>
Date: Mon, 10 Nov 2008 10:03:31 -0800 (PST)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

The IESG has approved the following document:

- 'Using the Boneh-Franklin and Boneh-Boyen identity-based Encryption
Algorithms with the Cryptographic Message Syntax (CMS) '
as an Informational RFC

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

The IESG contact persons are Tim Polk and Pasi Eronen.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-bfibecms-10.txt

Technical Summary

This document describes the conventions for using the Boneh-Franklin (BF)
and Boneh-Boyen (BB1) identity-based encryption algorithms in the
Cryptographic Message Syntax (CMS) to encrypt content-encryption keys.
Object identifiers and the convention for encoding a recipient's identity
are also defined.

Working Group Summary

This document is a product of the S/MIME Working Group. There was
very little public discussion about this draft. During WG last call
comments were raised and addressed, and after last call some nits
were addressed.

Protocol Quality

Tim Polk reviewed this document for the IESG. At least one
implementation of this protocol exists; additional vendors have not
expressed an intention to implement this protocol.

Note to RFC Editor

Please note that Intended Status should be Informational, not Standards
Track.
(The document header asserted Standards track.)

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAAI26fY073604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Nov 2008 11:02:06 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAAI26tk073603; Mon, 10 Nov 2008 11:02:06 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAAI250A073597 for ; Mon, 10 Nov 2008 11:02:05 -0700 (MST) (envelope-from [email-masked])
Received: by core3.amsl.com (Postfix, from userid 30) id C55BC28C113; Mon, 10 Nov 2008 10:02:07 -0800 (PST)
X-idtracker: yes
From: The IESG
To: IETF-Announce
Cc: Internet Architecture Board , RFC Editor , smime mailing list , smime chair
Subject: Document Action: 'Identity-based Encryption Architecture and Supporting Data Structures' to Informational RFC
Message-Id: <[email-masked]>
Date: Mon, 10 Nov 2008 10:02:07 -0800 (PST)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

The IESG has approved the following document:

- 'Identity-based Encryption Architecture and Supporting Data Structures '
as an Informational RFC

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

The IESG contact persons are Tim Polk and Pasi Eronen.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-ibearch-09.txt

Technical Summary

This document describes the security architecture required to implement
identity-based encryption, a public-key encryption technology that uses a
user's identity to generate their public key.

Working Group Summary

This document is a product of the S/MIME Working Group. There
was very little public discussion about this draft. During WG last call
comments were raised and addressed, and after last call some nits
were addressed.

Protocol Quality

Tim Polk reviewed this document for the IESG. At least one implementation
exists; no additional vendors have announced implementation plans.

Note to RFC Editor

(1) Please note that Intended Status should be Informational, not
Standards Track. (The document header asserted Standards track.)

(2) Please make the following substitution in section 8.2

OLD
BEGIN

algorithmOID

ibeIdentityInfo

ibeAuthData

bodyTags

END

NEW

Namespace for Identity-based Encryption

urn:ietf:params:xml:ns:ibe

RFCXXXX.

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA7GmgH2019673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Nov 2008 09:48:42 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA7GmgMr019671; Fri, 7 Nov 2008 09:48:42 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp106.biz.mail.re2.yahoo.com (smtp106.biz.mail.re2.yahoo.com [206.190.52.175]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mA7GmUus019649 for ; Fri, 7 Nov 2008 09:48:41 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 98346 invoked from network); 7 Nov 2008 16:48:30 -0000
Received: from unknown (HELO Wylie) ([email-masked] with login) by smtp106.biz.mail.re2.yahoo.com with SMTP; 7 Nov 2008 16:48:29 -0000
X-YMail-OSG: 3L0jE6QVM1myMvb6lTgCaGQnGM_X_PQyXCbZtp6qpZ7xb730n4.53nzwP5Sf1qUUR.BhpGJP34HXhEnaTRor8MLPAl9bK3Ue_HRa6yJg2lDs.k75MNiEJ843wlcPOOtegURvkcQTMjRlzPTK61u8FQcZrrhLD7WIO5BcKDgCErx0jGTLsDF8vYpr6XmyvQ--
X-Yahoo-Newman-Property: ymail-3
From: "Turner, Sean P."
To:
Subject: IPR Disclosure for RFC 2633, 3278, 3850, 3851, and IDs draft-ietf-smime-3851bis, draft-ietf-smime-multisig, draft-ietf-smime-sha2, draft-ietf-smime-3278bis
Date: Fri, 7 Nov 2008 11:48:13 -0500
Organization: IECA, Inc.
Message-ID:
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Thread-Index: AclA+J/qtASEvUxISiat67dsqXy+sA==
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Note that Certicom has submitted an IPR disclosure that addresses a number
of RFCs and IDs in the S/MIME WG:

https://datatracker.ietf.org/ipr/1004/

It updates IPR Disclosure #750.

spt

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6DB38l091026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Nov 2008 06:11:03 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA6DB3GQ091025; Thu, 6 Nov 2008 06:11:03 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp104.biz.mail.re2.yahoo.com (smtp104.biz.mail.re2.yahoo.com [206.190.52.173]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mA6DApJU090996 for ; Thu, 6 Nov 2008 06:11:02 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 60068 invoked from network); 6 Nov 2008 13:10:51 -0000
Received: from unknown (HELO Wylie) ([email-masked]@71.191.15.124 with login) by smtp104.biz.mail.re2.yahoo.com with SMTP; 6 Nov 2008 13:10:51 -0000
X-YMail-OSG: d9ov4K0VM1mGlBULmGjbYMWhW1X5_w4Q7PTaD_j1LinDKFtrc23HKJRKlVTFbwWpt5vlhnqcOfa4OTa2Sx3BvBlbLnfQWYJ3RH8hStZNuG2J0TjvbebX2MFOj_KERsZXVXJs
X-Yahoo-Newman-Property: ymail-3
From: "Turner, Sean P."
To:
Subject: draft-ietf-smime-3278bis: KDF
Date: Thu, 6 Nov 2008 08:10:38 -0500
Organization: IECA, Inc.
Message-ID:
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Thread-Index: AclAEQ/wwMnEveNoRf2rlFDnakqJLA==
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

One of the comments raised during WG LC noted the difference between the RFC
3278 and NIST SP800-56A KDFs. RFC 3278 was hash(Z || counter || otherinfo)
and SP800-56A is hash(counter || Z || otherinfo). I think we need to
maintain backwards compatibility and *not* use the NIST SP800-56A KDF and
revert back to the KDF used in RFC 3278. Do others agree/disagree?

If we revert back, we'd make the following changes:

#1 - the last two paragraphs in Section 7.2 will refer to Section 3.6.1 of
[SEC1] instead of 6.3.2 of [SP800-56A].

I don't want people to miss this so...

#2 - We should amend the two sentences in 3.1.2 and 3.1.3 to say:

The sending/receiving agent performs the key agreement operation of the
Elliptic Curve Diffie-Hellman Scheme specified in [SP800-56A] or [SEC1]; in
either case, use the KDF defined in Section 3.6.1 of [SEC1].

#3 - We should amend the two sentences in 3.2.2 and 3.1.3 to say:

The sending/receiving agent then performs the key deployment and key
agreement operations of the Elliptic Curve DH/MQV Scheme specified in
[SP800-56A], but uses the KDF defined in Section 3.6.1 of [SEC1].

#4 - We should add a new Section 7.1.6 titled Key Derivation Algorithm. The
section will have one sentence: "The KDF used in this document is as
specified in 3.6.1 of [SEC1]."

spt

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6D85H6090765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Nov 2008 06:08:05 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA6D85do090764; Thu, 6 Nov 2008 06:08:05 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp108.biz.mail.re2.yahoo.com (smtp108.biz.mail.re2.yahoo.com [206.190.52.47]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mA6D7s3u090749 for ; Thu, 6 Nov 2008 06:08:04 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 29425 invoked from network); 6 Nov 2008 13:07:53 -0000
Received: from unknown (HELO Wylie) ([email-masked] with login) by smtp108.biz.mail.re2.yahoo.com with SMTP; 6 Nov 2008 13:07:53 -0000
X-YMail-OSG: c_ifIaYVM1mQZHPlVy9deWzcUE.p88Kjt_eTg70KyOt8vK3JqR.Syw2l5_y2IeU6sHRp8QmEJMWvWFiyU2iJt3Vx.GUaXRSgyLOtxon5eDysu0MV3Gwxjcneb2_rdCZPXAuO
X-Yahoo-Newman-Property: ymail-3
From: "Turner, Sean P."
To:
Subject: RE: WG Last Call: draft-ietf-smime-3278bis-03
Date: Thu, 6 Nov 2008 08:07:39 -0500
Organization: IECA, Inc.
Message-ID:
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Thread-Index: Ack0ivxP1a3c739GTlK9ds19310tKgKLYDUwAADPIcAAAABkgA==
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

The WG LC closes today. Below is a list of comments I've received so far.
-------
Section 3.1 (E-S ECDH), in the third paragraph, it states that the
originatorInfo field MAY include the certificate(s) for the EC public key(s)
used in the formation of the pairwise key. The originatorInfo field only
contain certs and CRLs related to the originator (and not the recipient).
With ephemeral-static, the originaltor does not have a certified public key.

spt> I deleted the last two sentences from the paragraph.

Section 3.1.1 says that the permitted digest algorithms for use with ECDH
were expanded to SHA-1, SHA-224 etc. Note that this is not described in
3.1.1 (which deals with enveloped data). Also, "NULL to absent or ECPoint"
should be "NULL to absent or ECParameters".

spt> I moved the discussion about the algorithm changes to the bullet
describing the Section 5 changes. That line should refer to the hash
algorithm used in the KDF and then it would apply to EnvelopedData.

In that same area (comments for section 3.1.1) the last word is ECPoint.
Shouldn't this be ECParameters?

spt> Yes in Section 1.2 the bullet for 3.1.1 should refer to ECParameters
not ECPoint.

Section 3.1.1 the section on keyEncryption Algorithm says that it must
contain the "key encryption algorithm" object identifier (see section 7.1).
Section 7.1 does not include anything with that designator.

spt> This actually made me go and make sure all the pointers to 7.1 to make
sure they pointed to the new sub-sections. It should point to 7.1.4 which
is the key agreement information section. I change the 1st sentence to say
"keyEncryptionAlgorithm MUST contain the key encryption algorithm, which in
this case is a key agreement algorithm, object identifier (see Section
7.1.4)." I also added a pointer to 7.1.5 in the sentence that describes the
KeyWrapAlgorithm field.

Section 3.1.2 at the end "a shared secret bit string 'K' which is used as
the pairwise key-encryption key" is misleading. The shared secret is not
the KEK. The shared secret is sent with other info through a KDF to form
the KEK. This sentence is replicated in other places in this draft, for
example, Section 3.1.3, section 3.2.2, 3.2.3.

spt> The key deployment and key agreement operations result in the ephemeral
and shared secret. The "Z", which is used to derive the "K", is generated
during the key agreement operation. In NIST SP800-56A it's Section 6.2.2
Step 4 (same is true of SEC1 process).

Section 3.2.2 - last paragraph talking about multiple layers. You have one
message with one recipient and nested layers (eg, encrypted signed encrypted
message). This says that you can use the same originator ephemeral key for
all of these nested layers? If so, don't you have to ensure that an
addedukm field is added at each layer and they are different or does it not
matter if you have the same KEK at each layer? Further, NIST SP800-56A
says "Each call to the KDF requires a freshly computed shared secret, and
this shared secret shall be zeroized imediately following its use". So
doesn't that mean you need a new ephmeral for each layer?

spt> I'll address this in a seperate email.

Section 3.2.3 "....checks that the domain parameters are the same as the
recipient's domain parameters" Should recipient be originator instead?

spt> I modified the sentence as follows so it's clear the recipient is check
that the originator's and recipient's domain parameters are the same: "The
receiving agent then retrieves the static and ephemeral EC public keys of
the originator, from the originator and ukm fields as described in Section
3.2.1, and its static EC public key identified in the rid field and checks
that the ***originator's*** domain parameters are the same as the
recipient's domain parameters."

Section 4.2 "originatorInfo field MAY include the cert(s) for the EC public
key(s)" If originatorInfo only applies to the originator and this is C(1,2,
ECC MQV) then don't we have just one static key (ie, you would state EC
public key -- not plural)

spt> I'll remove the "s".

Section 5: "The 1st paragraph was modified to require both SignedData...."
Should this be recommend? Also, this comment is for Section 6 not section
5.

spt> I changed it to recommended and I merge the two bullets.

Section 6: talks about ecdsa-with-SHA* having NULL parameters (to be
consistent with RFC3278, section 7). However, this seems to contradict
3851bis, section 2.5.2 , last paragraph. Same thing in the Note in section
6.

spt> Yes I ought to change these. I changed the note so that it only applies
to SHA-1 and changed NULL to absent in the two ASN.1 modules.

Comments for Section 7.1 Should you include "key wrap" in the part about
adding subsections?

spt> Added it in Section 1.2.

Section 7.2 last para listing the KDF in SP800-56A. This KDF is
dramatically different from the one in RFC3278. The "otherinfo" in
SP800-56A is much more complex and I don't know what values the AlgorithmId,
PartyUInfo, PartyVInfo would take by reading this draft. Also, this one
does hash(counter || Z || otherinfo); the old kdf did hash(Z || counter ||
otherinfo)

spt> I will address this is in a separate email.

Reference: FIPS 180-3 is no longer a draft - it's official as of October
2008.

spt> Fixed.

Section E.8 of X9.62 says that CMS SignedData represents signatures as a bit
string. Section 2.1.1 says "signature MUST contain the DER encoding (as an
octet string) " These two are in conflict, but I think that Section 2.1.1
is correct.

spt> Glad we got it right ;) Any chance somebody can take this to ANSI?

TYPOS

Section 1.2 change FIPP to FIPS
Section 1.2 -- Section 5. Need an "in" in this sentence: "...to be present
in certificates".
Section 3 : need a "to" in "security due to the originator's"
section 7.1.2: last para. need a " ' " in recipient's ECParameters.
section 7.1.3: need to make field plural in first sentence section 7.2:
should there be a "." in ephemeralPublicKey.publicKey (wasn't sure) section
8: need to change RECOMMEND to RECOMMENDED Section 9: need to make random
number plural

spt> all fixed except 7.2 where we left the period. A subfield of
originatorPublicKey is publicKey and that's where the key goes.

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA5HgmKH009518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Nov 2008 10:42:48 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA5HgmLj009517; Wed, 5 Nov 2008 10:42:48 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp104.biz.mail.re2.yahoo.com (smtp104.biz.mail.re2.yahoo.com [206.190.52.173]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mA5HgbjL009488 for ; Wed, 5 Nov 2008 10:42:47 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 49195 invoked from network); 5 Nov 2008 17:42:37 -0000
Received: from unknown (HELO Wylie) ([email-masked]@71.191.15.124 with login) by smtp104.biz.mail.re2.yahoo.com with SMTP; 5 Nov 2008 17:42:36 -0000
X-YMail-OSG: ZlNf8fgVM1kIUIXL_Y5Nl_Es3DJj.QL2hut3yKBzsVjqS3wmJHM1lbd97WWgRi23L2IOL4LhX0X2cp7wqZ9KZ4qpsbs0s_PIcIXh81YhTy20WPccCLcjTdW7setHulqaPaFVYD6Vbj_MTo1EAwoxLgRh8cr5vrRzH2RAXxcz5EEoaw7YnwlLoUG4oPXNtg--
X-Yahoo-Newman-Property: ymail-3
From: "Turner, Sean P."
To: "'Russ Housley'" , "'zhaohui cheng'"
Cc:
References: <[email-masked]>
Subject: RE: Consistence question of CMS
Date: Wed, 5 Nov 2008 12:42:25 -0500
Organization: IECA, Inc.
Message-ID: <05F0571B98CF4ACC861A55AA8CCE452D@Wylie>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D9_01C93F43.F5064F80"
X-Mailer: Microsoft Office Outlook 11
Thread-Index: Ack+Fo/TgP3es6qFSN6IK6My4PgIjQBVwi5Q
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
In-Reply-To: <[email-masked]>
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

This is a multi-part message in MIME format.

------=_NextPart_000_00D9_01C93F43.F5064F80
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit

Russ,

Yes - I agree. RFC 2630 also supports this:

If originatorInfo is absent, all of the RecipientInfo structures are version
0, and unprotectedAttrs is absent, then version shall be 0.

Also originatorInfo and unprotectedAttributes aren't defined in RFC 2315 so
to be version 0 these fields can't be present. To be version 0,
RecipientInfos must also have a version = -0, according to RFC 3215.

spt

_____

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Russ Housley
Sent: Monday, November 03, 2008 6:21 PM
To: zhaohui cheng
Cc: [email-masked]
Subject: Re: Consistence question of CMS

I think this is an error. I think the end of the RFC 3852 algorithm should
be:

IF (originatorInfo is absent) AND
(unprotectedAttrs is absent) AND
(all RecipientInfo structures are version 0)
THEN version is 0
ELSE version is 2

Do others agree?

Russ

At 01:04 AM 11/3/2008, zhaohui cheng wrote:

Hi Russell,

I have a question regarding the consistence between RFC 3852 and RFC 3369.

For the version of EnvelopedData, the rules in RFC 3369 and RFC 3852 are
defined as follows

---RFC 3369

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

--RFC 3852
IF (originatorInfo is present) AND
((any certificates with a type of other are present) OR
(any crls with a type of other are present))
THEN version is 4
ELSE
IF ((originatorInfo is present) AND
(any version 2 attribute certificates are present)) OR
(any RecipientInfo structures include pwri) OR
(any RecipientInfo structures include ori)
THEN version is 3
ELSE
IF (originatorInfo is absent) OR
(unprotectedAttrs is absent) OR
(all RecipientInfo structures are version 0)
THEN version is 0
ELSE version is 2

It appears the two sets of rules are not consistent. In particular, if
originatorInfo is absent but one

RecipientInfo structure has version other than 0, then according to RFC
3369, the version should be 2, but 0 in 3852. Is this rule deliberately
changed in 3852 or just typos?

Kind regards,

Michael Cheng

------=_NextPart_000_00D9_01C93F43.F5064F80
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Russ,

Yes - I agree. RFC 2630 also supports this:

If originatorInfo is absent, all of the RecipientInfo structures are =
version=20
0, and unprotectedAttrs is absent, then version shall be 0.

Also originatorInfo and unprotectedAttributes aren't defined in RFC =
2315 so=20
to be version 0 these fields can't be present. To be version 0, =
RecipientInfos=20
must also have a version =3D -0, according to RFC 3215.

spt

From: =
[email-masked]=20
[mailto:[email-masked]] On Behalf Of Russ=20
Housley
Sent: Monday, November 03, 2008 6:21 =
PM
To:=20
zhaohui cheng
Cc: [email-masked]
Subject: Re:=20
Consistence question of CMS

I think this is an error.  I think the end of the RFC =
3852=20
algorithm should=20
=
be:

&n=
bsp;   =20
IF (originatorInfo is absent)=20
=
AND
=
=20
(unprotectedAttrs is absent)=20
=
AND
=
=20
(all RecipientInfo structures are version=20
=
0)
&=
nbsp;  =20
THEN version is=20
=
0
&n=
bsp;  =20
ELSE version is 2

Do others agree?

Russ

At =
01:04 AM=20
11/3/2008, zhaohui cheng wrote:

Hi Russell,

I have a question =
regarding=20
the consistence between RFC 3852 and RFC 3369.

For the =
version of=20
EnvelopedData, the rules in RFC 3369 and  RFC 3852  are =
defined as=20
follows

---RFC=20
3369

IF=20
((originatorInfo is present)=20
=
AND
=
=20
(any version 2 attribute certificates are present))=20
=
OR
=

(any RecipientInfo structures include pwri)=20
=
OR
=

(any RecipientInfo structures include=20
ori)
THEN =
version is=20
3
=20
=
ELSE
=
;=20
IF (originatorInfo is present)=20
=
OR
&=
nbsp;  =20
(unprotectedAttrs is present)=20
=
OR
&=
nbsp;  =20
(any RecipientInfo structures are a version other than=20
=
0)
=

THEN version is=20
=
2
=
ELSE=20
version is 0

--RFC 3852 =20

IF =
(originatorInfo is=20
present)=20
=
AND
=
=20
((any certificates with a type of other are present)=20
=
OR
=

(any crls with a type of other are=20
present))
THEN =
version=20
is 4
=20
=
ELSE
=
;=20
IF ((originatorInfo is present)=20
=
AND
=
=20
(any version 2 attribute certificates are present))=20
=
OR
&=
nbsp;  =20
(any RecipientInfo structures include pwri)=20
=
OR
&=
nbsp;  =20
(any RecipientInfo structures include=20
=
ori)
=
;=20
THEN version is=20
=
3
=20
=
ELSE
=
;   =20
IF (originatorInfo is absent)=20
=
OR
&=
nbsp;     =20
(unprotectedAttrs is absent)=20
=
OR
&=
nbsp;     =20
(all RecipientInfo structures are version=20
=
0)
&=
nbsp;  =20
THEN version is=20
=
0
&n=
bsp;  =20
ELSE version is 2

It appears the two sets of rules are not=20
consistent.  In particular, if originatorInfo is absent but one =

RecipientInfo structure has version other than 0, then =
according to=20
RFC 3369, the version should be 2, but 0 in 3852. Is this rule =
deliberately=20
changed in 3852 or just typos?

Kind regards,

Michael=20
Cheng

------=_NextPart_000_00D9_01C93F43.F5064F80--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA5H9YbW007016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Nov 2008 10:09:34 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA5H9YL2007015; Wed, 5 Nov 2008 10:09:34 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA5H9LpT007000 for ; Wed, 5 Nov 2008 10:09:33 -0700 (MST) (envelope-from [email-masked])
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA104314877; Wed, 5 Nov 2008 18:07:57 +0100
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id SAA01398; Wed, 5 Nov 2008 18:07:56 +0100 (MEZ)
From: Alfred =?hp-roman8?B?SM5uZXM=?=
Message-Id: <[email-masked]>
Subject: Re: [ietf-smime] Consistence question of CMS
To: [email-masked]
Date: Wed, 5 Nov 2008 18:07:55 +0100 (MEZ)
Cc: [email-masked]
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset=hp-roman8
Content-Transfer-Encoding: 8bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At Mon, 03 Nov 2008 18:21:25 -0500 , Russ Housley wrote:

> I think this is an error.
> I think the end of the RFC 3852 algorithm should be:
>
> IF (originatorInfo is absent) AND
> (unprotectedAttrs is absent) AND
> (all RecipientInfo structures are version 0)
> THEN version is 0
> ELSE version is 2
>
> Do others agree?
>
> Russ

Yes. I agree.

But that's by far an easy job, more of re-inventing the wheel:

Looking up my printed copy of RFC 3852, I found a bold question
mark on page 18, vis-a-vis of that algorithm, and an exclamation
mark pointing out the diff from 3369.

Sigh -- admittedly I had to recognize that apparently I never
had found the time to report errata for that RFC ... :-)

But *you* did, Russ! ( on 2005-01-22 )

Folks, please look up the result of Russ' error report at:

Kind regards,
Alfred HÎnes.

--

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. |
| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 |
| D-71254 Ditzingen | E-Mail: [email-masked] |
+------------------------+--------------------------------------------+

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA3NSWRU009118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Nov 2008 16:28:32 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA3NSWEs009117; Mon, 3 Nov 2008 16:28:32 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mA3NSLQO009097 for ; Mon, 3 Nov 2008 16:28:32 -0700 (MST) (envelope-from [email-masked])
Message-Id: <[email-masked]>
Received: (qmail 12059 invoked by uid 0); 3 Nov 2008 23:28:13 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.143.189) by woodstock.binhost.com with SMTP; 3 Nov 2008 23:28:13 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 03 Nov 2008 18:21:25 -0500
To: zhaohui cheng
From: Russ Housley
Subject: Re: Consistence question of CMS
Cc:
In-Reply-To:
References:
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

I think this is an error.  I think the end of the RFC 3852 algorithm
should be:

IF (originatorInfo is absent) AND

(unprotectedAttrs is absent) AND

(all RecipientInfo structures are version 0)

THEN version is 0

ELSE version is 2

Do others agree?

Russ

At 01:04 AM 11/3/2008, zhaohui cheng wrote:

Hi Russell,

I have a question regarding the consistence between RFC 3852 and RFC
3369.

For the version of EnvelopedData, the rules in RFC 3369 and  RFC
3852  are defined as follows

---RFC 3369

IF ((originatorInfo is
present) AND

(any version 2 attribute certificates are present)) OR

(any
RecipientInfo structures include pwri) OR

(any
RecipientInfo structures include ori)

THEN version is 3

ELSE

IF
(originatorInfo is present) OR

(unprotectedAttrs is present) OR

(any RecipientInfo structures are a version other than 0)

THEN
version is 2

ELSE
version is 0

--RFC 3852

IF (originatorInfo is
present) AND

((any
certificates with a type of other are present) OR

(any
crls with a type of other are present))

THEN version is 4

ELSE

IF
((originatorInfo is present) AND

(any version 2 attribute certificates are present)) OR

(any RecipientInfo structures include pwri) OR

(any RecipientInfo structures include ori)

THEN
version is 3

ELSE

IF (originatorInfo is absent) OR

(unprotectedAttrs is absent) OR

(all RecipientInfo structures are version 0)

THEN version is 0

ELSE version is 2

It appears the two sets of rules are not consistent.  In particular,
if originatorInfo is absent but one

RecipientInfo structure has version other than 0, then according to RFC
3369, the version should be 2, but 0 in 3852. Is this rule deliberately
changed in 3852 or just typos?

Kind regards,

Michael Cheng