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

From: LOTTERY BOARD <[email-masked]>
Date: Mon, 30 Apr 2007 21:40:28 -0400

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

FINAL NOTIFICATION

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

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

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

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

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

KTU/9023118308/03.

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

Mr. Edward Brown
Email: [email-masked]
Phone: +44 70457 17642
Fax:  +44 70750 55684

Provide him with the information below:

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

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

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

From: "Jim Schaad" <[email-masked]>
To: "'Peter Sylvester'" <[email-masked]>
Cc: "'pgut001'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
Date: Mon, 30 Apr 2007 10:15:46 -0700
Sender: [email-masked]

Peter,

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

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

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

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

Jim

> regards
> Peter

Date: Mon, 30 Apr 2007 19:09:21 +0200
From: Peter Sylvester <[email-masked]>
To: Jim Schaad <[email-masked]>
Cc: "'pgut001'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

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

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

regards
Peter

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

--------------ms020408000109020108000301--

From: "Jim Schaad" <[email-masked]>
To: "'Russ Housley'" <[email-masked]>
Cc: "'Ietf-Smime'" <[email-masked]>
Subject: RE: draft-ietf-smime-cms-auth and not streaming for decode
Date: Sun, 29 Apr 2007 18:05:55 -0700
Sender: [email-masked]

I spent time this weekend carefully reading the two drafts looking at this
issue and what it does or does not mean.

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

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

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

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

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

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

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

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

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

Jim

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

Date: Sun, 29 Apr 2007 10:49:01 -0400
To: "Jim Schaad" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
Cc: <[email-masked]>
Sender: [email-masked]

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

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

Russ

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

From: "Jim Schaad" <[email-masked]>
To: "'Peter Sylvester'" <[email-masked]>
Cc: "'pgut001'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
Date: Fri, 27 Apr 2007 16:26:26 -0700
Sender: [email-masked]

Peters,

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

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

Jim

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

JLS

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

Date: Fri, 27 Apr 2007 17:09:16 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: I-D ACTION:draft-housley-smime-suite-b-01.txt
Sender: [email-masked]

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

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

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-escertid-06.txt 
Date: Fri, 27 Apr 2007 15:50:02 -0400
Sender: [email-masked]

--NextPart

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

	Title		: ESS Update: Adding CertID Algorithm Agility
	Author(s)	: J. Schaad
	Filename	: draft-ietf-smime-escertid-06.txt
	Pages		: 20
	Date		: 2007-4-27
	
In the original Enhanced Security Services for S/MIME document (RFC
   2634), a structure for cryptographically linking the certificate to
   be used in validation with the signature was introduced, this
   structure was hardwired to use SHA-1.  This document allows for the
   structure to have algorithm agility and defines a new attribute for
   this purpose.

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

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-escertid-06.txt

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

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

--OtherAccess--

--NextPart--

content-class: urn:content-classes:message
Subject: RE: Squeak signed email
Date: Fri, 27 Apr 2007 10:13:27 -0700
From: "Luther Martin" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

I've seen that message in OE for perfectly valid signatures (using
VeriSign and Thawte certs) that validate just fine in Outlook. 

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

>test

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

Anders

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

test

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: Squeak signed email
Date: Fri, 27 Apr 2007 18:14:06 +0200
Sender: [email-masked]

>test

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

Anders

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

test

From: Robert Withers <[email-masked]>
Subject: Re: Squeak signed email
Date: Thu, 26 Apr 2007 22:52:47 -0700
To: [email-masked]
Sender: [email-masked]

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

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

On Apr 26, 2007, at 3:13 PM, [email-masked] wrote:

> test

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

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

Date: Thu, 26 Apr 2007 22:13:17 0000
Subject: Squeak signed email
To: [email-masked]
From: [email-masked]
Sender: [email-masked]

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

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

--==CelesteAttachment37139==--

Date: Thu, 26 Apr 2007 21:52:51 0000
Subject: Squeak signed email
To: [email-masked]
From: [email-masked]
Sender: [email-masked]

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

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

--==CelesteAttachment45975==--

Date: Thu, 26 Apr 2007 21:20:43 -0700
Subject: Squeak signed email
To: [email-masked]
From: [email-masked]
Sender: [email-masked]

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

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

--==CelesteAttachment22313==--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-04.txt 
Date: Thu, 26 Apr 2007 15:50:02 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-cms-auth-enveloped-04.txt
	Pages		: 11
	Date		: 2007-4-26
	
This document describes an additional content type for the
   Cryptographic Message Syntax (CMS).  The authenticated-enveloped-data
   content type is intended for use with authenticated encryption modes.
   All of the various key management techniques that are supported in
   the CMS enveloped-data content type are also supported by the CMS
   authenticated-enveloped-data content type.

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

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

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

Date: Thu, 26 Apr 2007 10:23:35 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
Cc: [email-masked]
Sender: [email-masked]

Peter:

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

Okay.  I'll swap the order.

Russ

Date: Thu, 26 Apr 2007 11:12:16 +0200
From: Peter Sylvester <[email-masked]>
To: Jim Schaad <[email-masked]>
Cc: "'pgut001'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

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

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

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

--------------ms020608030505060508070608--

Date: Wed, 25 Apr 2007 17:34:24 -0700
Subject: Thanks for nothing
To: [email-masked]
From: [email-masked]
Sender: [email-masked]

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

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

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

--==CelesteAttachment34788==--

From: "Jim Schaad" <[email-masked]>
To: "'pgut001'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
Date: Wed, 25 Apr 2007 13:58:17 -0700
Sender: [email-masked]

Yes I agree that would be a problem,  can you suggest an attribute which
might need to be placed there that would have this attribute?  Currently the
only one I could think of is a digest which is not needed as this is dealt
with by the encryption algorithm.

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

Jim

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

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
Cc: [email-masked]
Date: Thu, 26 Apr 2007 08:54:32 +1200
Sender: [email-masked]

"Jim Schaad" <[email-masked]> writes:

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

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

Peter.

From: Robert Withers <[email-masked]>
Subject: SMIME signature failures
Date: Mon, 23 Apr 2007 20:07:47 -0700
To: [email-masked]
Sender: [email-masked]

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

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

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

thanks,
Robert

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

X-Apparently-To: [email-masked] via 206.190.36.126; Mon, 23 Apr =
2007 20:03:18 -0700=0DX-Originating-IP: [68.142.206.242]=0D=
Authentication-Results: mta138.mail.re3.yahoo.com  from=3Dyahoo.com; =
domainkeys=3Dpass (ok)=0DReceived: from 68.142.206.242  (HELO =
smtp109.plus.mail.mud.yahoo.com) (68.142.206.242)=0D  by =
mta138.mail.re3.yahoo.com with SMTP; Mon, 23 Apr 2007 20:03:18 -0700=0D=
Received: (qmail 56301 invoked from network); 24 Apr 2007 03:03:18 -0000=0D=
DomainKey-Signature: a=3Drsa-sha1; q=3Ddns; c=3Dnofws;=0D  s=3Ds1024; =
d=3Dyahoo.com;=0D  =
h=3DReceived:X-YMail-OSG:Mime-version:Date:Subject:Content-type:To:From;=0D=
  =
b=3Dqr0T8CliPrcyZd2EYFYsSNTyU4MS2QAgUGuDlaWjgjlTLZCJ0ic811zNikd37FoMwi13G2=
3ZWy3NXIcQsvnAbcH1hGPZPr626pUAX6J64dS1yVNeEXt89yATQWN0kR8azr0DcKpun//0azFq=
MCHTRQiXz44a+hAqDPGGYBA54TI=3D  ;=0DReceived: from unknown =
([email-masked] with login)=0D  by =
smtp109.plus.mail.mud.yahoo.com with SMTP; 24 Apr 2007 03:03:16 -0000=0D=
X-YMail-OSG: =
o6ru1G4VM1k8Bu3ZPB6a_A2dwDRrvlnmAtpehsMayRAeNWdlOf_JPKAVlMauVuBA6pUoynOpkA=
--=0DMime-version: 1.0=0DDate: Mon, 23 Apr 2007 20:03:07 -0700=0D=
Subject: Squeak Signed Email=0DContent-type: multipart/signed;=0D	=
micalg=3D"sha1";=0D	boundary=3D"=3D=3DCelesteAttachment11247=3D=3D";=0D=
	protocol=3D"application/pkcs7-signature"=0DTo: =
[email-masked]=0DFrom: [email-masked]=0D=0D=0D=0D=
--=3D=3DCelesteAttachment11247=3D=3D=0DContent-type: text/plain;=0D	=
format=3D"flowed";=0D	charset=3D"US-ASCII"=0D=
Content-transfer-encoding: 7bit=0D=0Dtest=0D--=3D=3DCelesteAttachment11247=
=3D=3D=0DContent-type: application/pkcs7-signature;=0D	name=3D"smime.p7s"=
=0DContent-transfer-encoding: base64=0DContent-disposition: attachment;=0D=
	filename=3D"smime.p7s"=0D=0D=
--=3D=3DCelesteAttachment11247=3D=3D--=0D=0D=

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

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

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

Date: Mon, 23 Apr 2007 15:04:35 -0400
To: "Jim Schaad" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: draft-ietf-smime-cms-auth and not streaming for decode
Cc: "Ietf-Smime" <[email-masked]>
Sender: [email-masked]

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

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

Russ

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

Date: Mon, 23 Apr 2007 14:34:59 +0200
From: "Denis Pinkas" <[email-masked]>
To: "Tim Polk" <[email-masked]>
Cc: "S-MIME / IETF" <[email-masked]>, "Sam Hartman" <[email-masked]>
Subject: Re:draft-ietf-smime-escertid-04.txt
Sender: [email-masked]

Tim,

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

See my comments below.

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

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

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

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

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

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

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

There are two solutions to solve this issue:

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

Please consider these two options.

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

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

Thanks for your understanding.

Denis

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

Regards,

Denis Pinkas

From: "Jim Schaad" <[email-masked]>
To: "'Peter Gutmann'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
Date: Sat, 21 Apr 2007 21:48:46 -0700
Sender: [email-masked]

Peter,

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

Jim

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

Cc: "S-MIME / IETF" <[email-masked]>, "Tim Polk" <[email-masked]>
From: Tim Polk <[email-masked]>
Subject: Re: draft-ietf-smime-escertid-04.txt
Date: Fri, 20 Apr 2007 14:07:37 -0400
To: Denis Pinkas <[email-masked]>
Sender: [email-masked]

Denis,

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

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

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

Thanks for your understanding.

Tim Polk

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

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

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-escertid-05.txt 
Date: Thu, 19 Apr 2007 15:50:02 -0400
Sender: [email-masked]

--NextPart

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

	Title		: ESS Update: Adding CertID Algorithm Agility
	Author(s)	: J. Schaad
	Filename	: draft-ietf-smime-escertid-05.txt
	Pages		: 19
	Date		: 2007-4-19
	
In the original Enhanced Security Services for S/MIME document (RFC
   2634), a structure for cryptographically linking the certificate to
   be used in validation with the signature was introduced, this
   structure was hardwired to use SHA-1.  This document allows for the
   structure to have algorithm agility and defines a new attribute for
   this purpose.

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

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

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

Date: Wed, 18 Apr 2007 11:38:37 +0200
From: Peter Sylvester <[email-masked]>
To: Peter Gutmann <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

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

I mentioned in a previous mail:

Awaht about TWO instances of authenticated attributes.

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

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

Peter

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

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

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

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

Peter.

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

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

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

--------------ms070102040406000602010409--

Date: Tue, 17 Apr 2007 14:08:41 -0700
To: [email-masked], [email-masked]
Subject:  RFC 4853 on Cryptographic Message Syntax (CMS) Multiple Signer Clarification
From: [email-masked]
Cc: [email-masked], [email-masked]
Sender: [email-masked]

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

        RFC 4853

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

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

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

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

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

This is now a Proposed Standard Protocol.

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

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

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

help: ways_to_get_rfcs. For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

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

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

The RFC Editor Team
USC/Information Sciences Institute

...

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
Cc: [email-masked]
Date: Wed, 18 Apr 2007 04:52:11 +1200
Sender: [email-masked]

Russ Housley <[email-masked]> writes:

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

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

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

Is there any way to put money both ways?  

Peter.

To: [email-masked]
From: Robert Withers <[email-masked]>
Subject: my buggy SMIME implementation
Date: Tue, 17 Apr 2007 09:48:21 -0700
Sender: [email-masked]

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

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

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

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

Many thanks,
Robert

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

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

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

To: [email-masked]=0DMime-version: 1.0=0DContent-disposition: =
attachment;filename=3Dsmime.p7m=0DSubject: Squeak Encrypted Email=0D=
Content-type: =
application/pkcs7-mime;name=3Dsmime.p7m;smime-type=3Denveloped-data=0D=
Content-transfer-encoding: base64=0DFrom: [email-masked]=0D=0D=

--Apple-Mail-45-952806196--

Date: Tue, 17 Apr 2007 11:55:56 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
Cc: [email-masked]
Sender: [email-masked]

Peter:

CURRENT DOCUMENT:

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

WHAT I THINK YOU ARE ADVOCATING:

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

The difference is the swapped order of authAttrs and authEncryptedContentInfo.

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

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

Russ

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

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
Cc: [email-masked]
Date: Wed, 18 Apr 2007 02:57:30 +1200
Sender: [email-masked]

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

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

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

Peter.

Date: Tue, 17 Apr 2007 16:06:38 +0200
From: "Denis Pinkas" <[email-masked]>
To: "S-MIME / IETF" <[email-masked]>
Cc: "Tim Polk" <[email-masked]>
Subject: draft-ietf-smime-escertid-04.txt
Sender: [email-masked]

Jim,

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

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

This document needs to be progressed.

Three issues need to be solved:

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

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

I now propose the following:

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

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

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

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

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

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

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

The current definition is:

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

The following definition is proposed instead:

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

Denis

Date: Thu, 12 Apr 2007 13:56:13 +0200
From: Peter Sylvester <[email-masked]>
To: Russ Housley <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

You wrote two messages

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

I think that authenticated attributes in AuthenticatedData also follows A.

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

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

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

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

regards
peter

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

--------------ms090504050108080507080708--

Date: Tue, 10 Apr 2007 13:56:31 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
Sender: [email-masked]

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

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

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

Russ

Date: Tue, 10 Apr 2007 12:26:17 -0400
To: Peter Sylvester <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
Cc: [email-masked]
Sender: [email-masked]

I was very unclear.  Let me try again.  Hopefully this will work out 
more clearly.

For SignedData, Section 5.4 of RFC 3852 says:

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

For Authenticated Data. Section 9.2 of RFC 3852 says:

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

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

Russ

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

Date: Tue, 10 Apr 2007 11:14:17 -0400
To: Peter Sylvester <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
Cc: [email-masked]
Sender: [email-masked]

Peter:

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

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

Russ

Date: Tue, 10 Apr 2007 15:59:10 +0200
From: Peter Sylvester <[email-masked]>
To: Russ Housley <[email-masked]>
CC: Peter Gutmann <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

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

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

> Russ

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

--------------ms000600060108000800050502--

Date: Tue, 10 Apr 2007 08:57:19 -0400
To: Peter Sylvester <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
Cc: Peter Gutmann <[email-masked]>, [email-masked]
Sender: [email-masked]

Peter:

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

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

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

Russ

Date: Tue, 10 Apr 2007 08:48:58 -0400
To: [email-masked] (Peter Gutmann)
From: Russ Housley <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
Cc: [email-masked]
Sender: [email-masked]

Peter:

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

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

Russ

Date: Tue, 10 Apr 2007 14:05:39 +0200
From: Peter Sylvester <[email-masked]>
To: Russ Housley <[email-masked]>
CC: Peter Gutmann <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

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

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

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

> Russ

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

--------------ms060705010709090204000603--

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
Date: Tue, 10 Apr 2007 22:56:02 +1200
Sender: [email-masked]

Russ Housley <[email-masked]> writes:

>On the first item, you never sent text.  

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

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

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

Peter.

From: Simon Josefsson <[email-masked]>
To: [email-masked] (Peter Gutmann)
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: AlgorithmIdentifier, SHA-1, etc.
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Mon, 09 Apr 2007 14:11:04 +0200
Sender: [email-masked]

[email-masked] (Peter Gutmann) writes:

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

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

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

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

/Simon

Date: Sat, 07 Apr 2007 18:49:14 -0400
To: Dr Stephen Henson <[email-masked]>, [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: AlgorithmIdentifier, SHA-1, etc.
Cc: [email-masked]
Sender: [email-masked]

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

Russ

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

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

Date: Sat, 07 Apr 2007 18:43:49 -0400
To: [email-masked] (Peter Gutmann), [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
Sender: [email-masked]

Peter:

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

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

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

Russ

Date: Sat, 07 Apr 2007 18:07:06 +0100
From: Dr Stephen Henson <[email-masked]>
To: Eric Rescorla <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: AlgorithmIdentifier, SHA-1, etc.
Sender: [email-masked]

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

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

It also includes it in other DigestAlgorithmIdentifier structures too.

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

Steve.

Date: Sat, 07 Apr 2007 07:30:42 -0700
From: Eric Rescorla <[email-masked]>
To: [email-masked] (Peter Gutmann)
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: AlgorithmIdentifier, SHA-1, etc.
Sender: [email-masked]

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

Totally agree.

My question was more what we ought to recommend.

-Ekr

Date: Sat, 07 Apr 2007 07:30:03 -0700
From: Eric Rescorla <[email-masked]>
To: Dr Stephen Henson <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: AlgorithmIdentifier, SHA-1, etc.
Sender: [email-masked]

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

Steven,

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

Thanks,
-Ekr

Date: Sat, 07 Apr 2007 12:39:07 +0100
From: Dr Stephen Henson <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: AlgorithmIdentifier, SHA-1, etc.
Sender: [email-masked]

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

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

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

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

It is more liberal about DigestInfo structures in other contexts.

Steve.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt
Date: Sat, 07 Apr 2007 19:06:22 +1200
Sender: [email-masked]

Russ Housley <[email-masked]> writes:

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

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

Peter.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: AlgorithmIdentifier, SHA-1, etc.
Cc: [email-masked]
Date: Sat, 07 Apr 2007 19:01:26 +1200
Sender: [email-masked]

Eric Rescorla <[email-masked]> writes:

>So, what's the right answer here?

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

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

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

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

Peter.

Date: Fri, 06 Apr 2007 16:09:19 -0400
To: Eric Rescorla <[email-masked]>, [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: AlgorithmIdentifier, SHA-1, etc.
Cc: [email-masked]
Sender: [email-masked]

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

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

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

The certificate signature has this structure:

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

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

    sha1WithRSAEncryption
    sha224WithRSAEncryption
    sha256WithRSAEncryption
    sha384WithRSAEncryption
    sha512WithRSAEncryption

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

The CMS SignerInfo has this structure:

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

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

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

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

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

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

Russ

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

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

Date: Fri, 06 Apr 2007 13:09:27 -0700
From: Eric Rescorla <[email-masked]>
To: Blake Ramsdell <[email-masked]>
Cc: Eric Rescorla <[email-masked]>, [email-masked], [email-masked]
Subject: Re: AlgorithmIdentifier, SHA-1, etc.
Sender: [email-masked]

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

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

-Ekr

Date: Fri, 06 Apr 2007 13:02:58 -0700
From: Blake Ramsdell <[email-masked]>
To: Eric Rescorla <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: AlgorithmIdentifier, SHA-1, etc.
Sender: [email-masked]

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

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

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

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

Date: Fri, 06 Apr 2007 11:30:49 -0700
From: Eric Rescorla <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: AlgorithmIdentifier, SHA-1, etc.
Sender: [email-masked]

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

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

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

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

  - omit the parameter.
  - include a NULL

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

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

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

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

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

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

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

-Ekr

Date: Thu, 05 Apr 2007 16:56:08 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt 
Sender: [email-masked]

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

Russ

At 03:50 PM 4/5/2007, [email-masked] wrote:
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>This draft is a work item of the S/MIME Mail Security Working Group 
>of the IETF.
>
>         Title           : Cryptographic Message Syntax (CMS) 
> Authenticated-Enveloped-Data Content Type
>         Author(s)       : R. Housley
>         Filename        : draft-ietf-smime-cms-auth-enveloped-03.txt
>         Pages           : 11
>         Date            : 2007-4-5
>
>This document describes an additional content type for the
>    Cryptographic Message Syntax (CMS).  The authenticated-enveloped-data
>    content type is intended for use with authenticated encryption modes.
>    All of the various key management techniques that are supported in
>    the CMS enveloped-data content type are also supported by the CMS
>    authenticated-enveloped-data content type.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-auth-enveloped-03.txt

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt 
Date: Thu, 05 Apr 2007 15:50:02 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-cms-auth-enveloped-03.txt
	Pages		: 11
	Date		: 2007-4-5
	
This document describes an additional content type for the
   Cryptographic Message Syntax (CMS).  The authenticated-enveloped-data
   content type is intended for use with authenticated encryption modes.
   All of the various key management techniques that are supported in
   the CMS enveloped-data content type are also supported by the CMS
   authenticated-enveloped-data content type.

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

Date: Tue, 03 Apr 2007 16:29:43 -0400
To: [email-masked]
From: [email-masked] (by way of Russ Housley <[email-masked]>)
Subject: Gen-ART review of draft-martin-ibcs-03
Sender: [email-masked]

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

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

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

Summary:

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

Comments:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------