Subject: During Work

From: "Tyler.Thurman" <[email-masked]>
Date: Wed, 28 Feb 2007 16:58:34 -0800

Hi there, I hate to be the one but when people continue to talk about your weight issue, we'll it just disgusts me. Whether you know it by now, people are always chattering about one another at work but you come up more than enough. I wasn't the happiest or best fit up until a year ago or so but that changed. Thanks to my dam brother-in-law. Anyhow, it was for the best. What I am saying is you need to do something and I was saved a year ago and maybe I can make the same difference. Try this stuff out, I took it on the idea it's just more junk but it worked great. I see more positive reviews on it nowadays and makes me feel even better. So, I am encouraging a change, not only in the chatter around here but in you personally.

-Anonymous for now (using an anonymous email website to send this btw)
When it helps/works just send a memo with the name "Angel" in it. Then you can take me out to lunch to thank you.

WebSite---celefbriingo.com

From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, smime mailing list <[email-masked]>, smime chair <[email-masked]>
Subject: Protocol Action: 'Cryptographic Message Syntax (CMS)  Multiple Signer Clarification' to Proposed Standard 
Date: Mon, 26 Feb 2007 18:39:30 -0500
Sender: [email-masked]

The IESG has approved the following document:

- 'Cryptographic Message Syntax (CMS) Multiple Signer Clarification '
   <draft-ietf-smime-cms-mult-sign-03.txt> as a Proposed Standard

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

The IESG contact persons are Sam Hartman and Russ Housley.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-mult-sign-03.txt

Technical Summary
 
   This document clarifies the proper recipient handling of the
   SignedData content type when more than one digital signature is
   present. This draft updates RFC 3852.

Working Group Summary
 
   There was consensus to publish this within the WG.  One person
   raised two last call comments in IETF last call.  The first issue
   concerned how to handle signatures from different signers.  This
   issue was addressed.  The second issue proposed expanding the scope
   of the document to give more guidance on verifying signatures.
   This was discussed by the WG before the document was forwarded;
   there was no consensus to expand the scope in this way.
 
Protocol Quality
 
   This document has been reviewed by Sam Hartman for the IESG.

Reply-To: <[email-masked]>
From: "Turner, Sean P." <[email-masked]>
To: <[email-masked]>
Subject: IETF 68 Agenda Topics
Date: Thu, 15 Feb 2007 12:49:27 -0500
Organization: IECA, Inc.
Sender: [email-masked]

All,

We've got a one hour slot scheduled and here is a proposed agenda.  If
anybody has any ideas for topics to add please let me know:

Agenda Bashing (All)
WG Status (Sean)
 symkeydist
 esscertid
 cmsmultisign
 IBE drafts
Authenticated Enveloped Data (Russ)
AES-CCM and AES-GCM (Russ)
Multiple Signatures (Jim/Sean)
Wrap Up (Sean)

spt

Reply-To: <[email-masked]>
From: "Turner, Sean P." <[email-masked]>
To: <[email-masked]>
Subject: draft-ietf-smime-cms-mult-sign-03.txt 
Date: Wed, 14 Feb 2007 20:03:45 -0500
Organization: IECA, Inc.
Sender: [email-masked]

All,

A new version of the CMS Multiple Signer Clarification ID has been posted to
address a comment raised during IETF Last Call.  Please review and provide
any comments by 20 Feb 5pm EST.

The new draft can be found at:

http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-mult-sign-03.txt

spt

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-02.txt 
Date: Wed, 14 Feb 2007 15:50:02 -0500
Sender: [email-masked]

--NextPart

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

	Title		: Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-cms-auth-enveloped-02.txt
	Pages		: 10
	Date		: 2007-2-14
	
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-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] 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-02.txt".

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-cms-auth-enveloped-02.txt

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

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

--OtherAccess--

--NextPart--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-cms-mult-sign-03.txt 
Date: Wed, 14 Feb 2007 15:50:02 -0500
Sender: [email-masked]

--NextPart

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

	Title		: Cryptographic Message Syntax (CMS) Multiple Signer Clarification
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-cms-mult-sign-03.txt
	Pages		: 5
	Date		: 2007-2-14
	
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.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] 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-mult-sign-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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-cms-mult-sign-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="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-cms-mult-sign-03.txt

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

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

--OtherAccess--

--NextPart--

Date: Wed, 14 Feb 2007 03:09:26 -0800
From: Blake Ramsdell <[email-masked]>
To: [email-masked]
Subject: IBE drafts WG last call extended to 2/16
Sender: [email-masked]

I'm extending the WG last call for draft-ietf-smime-bfibecms and 
draft-ietf-smime-ibearch until Friday, 2/16, due to the unfortunate 
collision with the RSA conference.

I'm a little nervous that there hasn't been any discussion about these 
during last call. I explained to Mark that this either represents a) 
perfection, or b) a lack of review. I'm all for a), but I fear it's b).

Can I get some amount of noise from anyone who has done a review of 
these drafts? I know we took a poll at the WG meeting in San Diego, and 
there were several people who intended to take a look. Just a "hey, I 
took a look, and these are the nicest drafts I've ever seen" would 
certainly make me feel better.

And certainly if you intended to look at the drafts, you've got some 
extra time now.

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

Date: Tue, 13 Feb 2007 16:43:57 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-smime-cms-aes-ccm-and-gcm-00.txt 
Cc: [email-masked]
Sender: [email-masked]

Sean:

>Minor nits (and maybe showing my lack of understanding):
>
>Sections 1.4 and 1.5 refer to the outputs as a ciphertext and an
>authentication tag.  Can we add the following parenthetical to the 1st
>sentence of the last para in 3 to tie the two paras together?: ... "for the
>AuthEnvelopedData mac field (i.e., the authentication tag)."  The
>authentication tag is referred to in AuthEnvelopedData ID.

I changed the algorithm descriptions in 1.4 and 1.5 to provide the 
linkage.   It now says:

AES-CCM/AES-GCM generates two outputs: a ciphertext and message 
authentication code (also called an authentication tag).

>Also 1.4 and 1.5 say there are four inputs to the process and the last para
>of 2.2 of the AuthEvelopedData ID says there's 3.  There's no reference to
>the nonce. Is the nonce just part of the random content encryption key?

AES-CCM and AES-GCM require a nonce.  This is carried in an algorithm 
parameter, so it is not really described in the AuthEnvelopedData 
document.  If one was to turn AES Key Wrap into an authenticated 
encryption mode, it would not need such a nonce.

I have added the missing piece of information to the 3rd paragraph of 
sections 1.4 and 1.5, which now read:

The nonce is generated by the party performing the authenticated 
encryption operation.  Within the scope of any 
authenticated-encryption key, the nonce value MUST be unique.  That 
is, the set of nonce values used with any given key MUST NOT contain 
any duplicate values.  Using the same nonce for two different 
messages encrypted with the same key destroys the security properties.

Russ

Reply-To: <[email-masked]>
From: "Turner, Sean P." <[email-masked]>
To: <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-smime-cms-aes-ccm-and-gcm-00.txt 
Date: Tue, 13 Feb 2007 15:28:03 -0500
Organization: IECA, Inc.
Sender: [email-masked]

Russ,

Minor nits (and maybe showing my lack of understanding):

Sections 1.4 and 1.5 refer to the outputs as a ciphertext and an
authentication tag.  Can we add the following parenthetical to the 1st
sentence of the last para in 3 to tie the two paras together?: ... "for the
AuthEnvelopedData mac field (i.e., the authentication tag)."  The
authentication tag is referred to in AuthEnvelopedData ID.

Also 1.4 and 1.5 say there are four inputs to the process and the last para
of 2.2 of the AuthEvelopedData ID says there's 3.  There's no reference to
the nonce. Is the nonce just part of the random content encryption key?

spt

Reply-To: <[email-masked]>
From: "Turner, Sean P." <[email-masked]>
To: "'Russ Housley'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-01.txt 
Date: Tue, 13 Feb 2007 14:43:48 -0500
Organization: IECA, Inc.
Sender: [email-masked]

Okay the oid in AuthEnvelopedData EncryptedContentInfo
contentEncryptionAlgorithm field is all encompassing.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Russ Housley
> Sent: Tuesday, February 13, 2007 12:56 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-01.txt 
> 
> 
> Sean:
> 
> >Two comments/questions:
> >
> >Sec 2.1: Don't we need an algorithm identifier for the mac algorithm?
> 
> No.  Authenticated encryption provides both.  Please see 
> draft-ietf-smime-cms-aes-ccm-and-gcm-00.txt to see two examples.
> 
> >Sec 2.1: Since the mac description says a digest is not used 
> should we 
> >say in the authAttrs description that the message digest 
> attribute must 
> >not be included if authenticated attributes are included 
> (9.1 requires 
> >message digest if authenticated attributes are used)?
> 
> Yes.  That is a good improvement.
> 
> Russ
> 
> 

Date: Tue, 13 Feb 2007 12:55:40 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-01.txt 
Cc: [email-masked]
Sender: [email-masked]

Sean:

>Two comments/questions:
>
>Sec 2.1: Don't we need an algorithm identifier for the mac algorithm?

No.  Authenticated encryption provides both.  Please see
draft-ietf-smime-cms-aes-ccm-and-gcm-00.txt to see two examples.

>Sec 2.1: Since the mac description says a digest is not used should we say
>in the authAttrs description that the message digest attribute must not be
>included if authenticated attributes are included (9.1 requires message
>digest if authenticated attributes are used)?

Yes.  That is a good improvement.

Russ

Reply-To: <[email-masked]>
From: "Turner, Sean P." <[email-masked]>
To: <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-01.txt 
Date: Mon, 12 Feb 2007 21:25:38 -0500
Organization: IECA, Inc.
Sender: [email-masked]

Russ,

Two comments/questions:

Sec 2.1: Don't we need an algorithm identifier for the mac algorithm?

Sec 2.1: Since the mac description says a digest is not used should we say
in the authAttrs description that the message digest attribute must not be
included if authenticated attributes are included (9.1 requires message
digest if authenticated attributes are used)?

spt

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Tuesday, January 30, 2007 3:50 PM
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-01.txt 

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		: The CMS AuthEnvelopedData Content Type
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-cms-auth-enveloped-01.txt
	Pages		: 10
	Date		: 2007-1-30
	
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-01.t
xt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] 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-01.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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-cms-auth-enveloped-01.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.

To: [email-masked]
From: [email-masked]
Date: Tue, 30 Jan 2007 15:50:02 -0500
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-01.txt 
Reply-To: [email-masked]
Sender: [email-masked]

--NextPart

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

	Title		: The CMS AuthEnvelopedData Content Type
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-cms-auth-enveloped-01.txt
	Pages		: 10
	Date		: 2007-1-30
	
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-01.txt

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-cms-auth-enveloped-01.txt

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

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

--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--NextPart--

Reply-To: [email-masked]
Sensitivity: Normal
Importance: Normal
To: "Anders Rundgren" <[email-masked]>, [email-masked], "Hallam-Baker, Phillip" <[email-masked]>, [email-masked]
Subject: Re: Goal for S/MIME 2007?
From: "Christine Karman" <[email-masked]>
Date: Fri, 2 Feb 2007 02:03:11 +0000 GMT
Sender: [email-masked]

Anders,
For secure portable storage of your keys, you can use a USB token. We use them, works very well. For public keys there are other solutions that work.

Christine

---
www.izecom.com

-----Original Message-----
From: "Anders Rundgren" <[email-masked]>
Date: Thu, 1 Feb 2007 19:25:29 
To:"Hallam-Baker, Phillip" <[email-masked]>, <[email-masked]>
Subject: Re: Goal for S/MIME 2007?

"If we can persuade the people deploying DKIM at the client"

Putting DKIM in the client is IMHO not the right medicine.  Any scheme that
requires locally stored keys essentially suffer from the same basic problem;
that we [still] have no [reasonable] mechanism for carrying such keys.

"dependable transactional signatures"

Transactions are typically performed by transaction systems.  Due to this, I
cannot really see that S/MIME will play an important role in a future IT
landscape.

"I don't want to make S/MIME looser"

Neithe do I but  it is enough that a message from [email-masked]
is really coming from the example.com domain and is encrypted during its
transport to the reveiver domain.  Well, this probably only caters for some
99.9% of all use-cases, but for most people that is "good-enough".  If a
0.1% "market-share" will keep S/MIME alive and kicking is yet to see.
I would not bet on it at least.

Anders R

----- Original Message -----
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>; <[email-masked]>
Sent: Friday, January 26, 2007 03:52
Subject: RE: Goal for S/MIME 2007?

I think that in order to address that particular market we would have to spend a lot of time re-engineering S/MIME to be less
strict.

I don't want to make S/MIME looser. I want to work out a way to get people signing and encrypting their email. I don't particularly
care what technology they use to do that.

S/MIME implementations lack a small amount of glue to make them more usable. If we can persuade the people deploying DKIM at the
client end to add those small necessary pieces of glue to make the user experience seamless we end up with the best of both worlds,
ubiquitous lightweight signatures, dependable transactional signatures and message encryption.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Anders Rundgren
> Sent: Thursday, January 25, 2007 4:31 PM
> To: [email-masked]
> Subject: Re: Goal for S/MIME 2007?
>
>
> In theory S/MIME could be one "cure" against spam, viruses
> and phishing.
>
> There are at least two things making this stay as "theory".
>
> 1.
> There is no S/MIME trust structure that works except rather
> locally, effectively making every person on the net a "PKI
> trust administrator".
> Although the DoD have a solution (
> http://www.certipath.com/services.htm ), few other
> organizations can spend huge amounts of tax-payer money just
> to prove that "it can be done", but are rather evaluating
> other options.
>
> 2.
> The unavailability of a cheap, mobile, secure and fully
> standardized container makes the certificate requirement a
> much too high bar.  That not even the financial sector have
> managed to deploy such schemes to more than 1-2% in spite of
> 10+ years of on-line banking is in my opinion good enough as
> a proof.  The virtual explosion of Web-mail and mobile phone
> mail, actually makes the S/MIME-card-everywhere-vision more
> distant than ever.  Well, the DoD have no problems [of
> course],
> http://www.karbonsystems.com/BlackBerry-SMIME-CAC-products_det
ail-83.html
> but who else would buy $200+ card-readers?
>
>
> It might be interesting knowing that some governments have indeed
> removed S/MIME from their C2G (Citizen-to-Government) PKI
> schemes since they have noted that the web is a more powerful way
> of delivering services as well as offering encryption for free.
>
> Regarding the failed DOMSEC experimental RFC, I believe that it
> [partly] failed because the authors did not realize that
> there already was
> a globally working PKI they should have hooked into; the web-server
> SSL PKI.  Imagine, securing an entire e-mail domain for a measly $100-
> $200 annually!  Too simple, too obvious, and too commercial I guess.
>
> AR
>
>

From: "Anders Rundgren" <[email-masked]>
To: "Hallam-Baker, Phillip" <[email-masked]>, <[email-masked]>
Subject: Re: Goal for S/MIME 2007?
Date: Thu, 1 Feb 2007 19:25:29 +0100
Sender: [email-masked]

"If we can persuade the people deploying DKIM at the client"

Putting DKIM in the client is IMHO not the right medicine.  Any scheme that
requires locally stored keys essentially suffer from the same basic problem;
that we [still] have no [reasonable] mechanism for carrying such keys.

"dependable transactional signatures"

Transactions are typically performed by transaction systems.  Due to this, I
cannot really see that S/MIME will play an important role in a future IT
landscape.

"I don't want to make S/MIME looser"

Neithe do I but  it is enough that a message from [email-masked]
is really coming from the example.com domain and is encrypted during its
transport to the reveiver domain.  Well, this probably only caters for some
99.9% of all use-cases, but for most people that is "good-enough".  If a
0.1% "market-share" will keep S/MIME alive and kicking is yet to see.
I would not bet on it at least.

Anders R

----- Original Message -----
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>; <[email-masked]>
Sent: Friday, January 26, 2007 03:52
Subject: RE: Goal for S/MIME 2007?

I think that in order to address that particular market we would have to spend a lot of time re-engineering S/MIME to be less
strict.

I don't want to make S/MIME looser. I want to work out a way to get people signing and encrypting their email. I don't particularly
care what technology they use to do that.

S/MIME implementations lack a small amount of glue to make them more usable. If we can persuade the people deploying DKIM at the
client end to add those small necessary pieces of glue to make the user experience seamless we end up with the best of both worlds,
ubiquitous lightweight signatures, dependable transactional signatures and message encryption.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Anders Rundgren
> Sent: Thursday, January 25, 2007 4:31 PM
> To: [email-masked]
> Subject: Re: Goal for S/MIME 2007?
>
>
> In theory S/MIME could be one "cure" against spam, viruses
> and phishing.
>
> There are at least two things making this stay as "theory".
>
> 1.
> There is no S/MIME trust structure that works except rather
> locally, effectively making every person on the net a "PKI
> trust administrator".
> Although the DoD have a solution (
> http://www.certipath.com/services.htm ), few other
> organizations can spend huge amounts of tax-payer money just
> to prove that "it can be done", but are rather evaluating
> other options.
>
> 2.
> The unavailability of a cheap, mobile, secure and fully
> standardized container makes the certificate requirement a
> much too high bar.  That not even the financial sector have
> managed to deploy such schemes to more than 1-2% in spite of
> 10+ years of on-line banking is in my opinion good enough as
> a proof.  The virtual explosion of Web-mail and mobile phone
> mail, actually makes the S/MIME-card-everywhere-vision more
> distant than ever.  Well, the DoD have no problems [of
> course],
> http://www.karbonsystems.com/BlackBerry-SMIME-CAC-products_det
ail-83.html
> but who else would buy $200+ card-readers?
>
>
> It might be interesting knowing that some governments have indeed
> removed S/MIME from their C2G (Citizen-to-Government) PKI
> schemes since they have noted that the web is a more powerful way
> of delivering services as well as offering encryption for free.
>
> Regarding the failed DOMSEC experimental RFC, I believe that it
> [partly] failed because the authors did not realize that
> there already was
> a globally working PKI they should have hooked into; the web-server
> SSL PKI.  Imagine, securing an entire e-mail domain for a measly $100-
> $200 annually!  Too simple, too obvious, and too commercial I guess.
>
> AR
>
>