Subject: Get a 3.75% mortgage

From: "Jessie" <[email-masked]>
Date: Sun, 30 Apr 2006 05:31:06 -0800

Looking to re-mortgage your home?
Or maybe you need a loan?

We got the largest companies competing with eachother for your business,
so you know you're getting the best deal.

Get rates as low as 3.75%

http://www.rugtrin.com/9cb/

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-cms-mult-sign-00.txt 
Date: Fri, 21 Apr 2006 18:50:01 -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) Multiple Signer Clarification

	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-cms-mult-sign-00.txt
	Pages		: 5
	Date		: 2006-4-21
	
   This document updates the Cryptographic Message Syntax (CMS), which
   is published in RFC 3852.  This document clarifies the proper
   handling of the SignedData protected content type when more than one
   digital signature is present.

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

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-cms-mult-sign-00.txt".

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-cades-01.txt 
Date: Wed, 19 Apr 2006 15:50:01 -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		: CMS Advanced Electronic Signatures (CAdES)
	Author(s)	: J. Ross, et al.
	Filename	: draft-ietf-smime-cades-01.txt
	Pages		: 130
	Date		: 2006-4-19
	
This document defines the format of an electronic signature that can
remain valid over long periods.  This includes evidence as to its
validity even if the signer or verifying party later attempts to deny
(i.e., repudiates the validity of the signature). The format can be
considered as an extension to RFC 3852 [4] and RFC 2634 [5], where, 
when appropriate additional signed and unsigned attributes have been
defined.  The contents of this Informational RFC amounts to a 
transposition of the ETSI TS 101 733 V.1.6.3 (CMS Advanced 
Electronic Signatures - CAdES) [TS101733] and is technically 
equivalent to it.

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

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-cades-01.txt".

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-cades-01.txt

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

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

--OtherAccess--

--NextPart--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-escertid-01.txt 
Date: Tue, 18 Apr 2006 18:50:01 -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-01.txt
	Pages		: 18
	Date		: 2006-4-18
	
In the original Enhanced Security Services for S/MIME draft, 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 new attributes to deal with the
updating.

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

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-escertid-01.txt".

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

From: "Jim Schaad" <[email-masked]>
To: "'Nick Pope'" <[email-masked]>, <[email-masked]>
Subject: RE: Protect Algorithm identifiers?
Date: Tue, 18 Apr 2006 08:43:48 -0700
Sender: [email-masked]

Nick,

The case that worries me to some extent is the upcomming algorithms with
parameters.  It might be that creating collisions is simplier when you can
play with the parameters than with the body.  This depends in part on how
the keying of the hash function is done.

Jim

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Nick Pope
> Sent: Tuesday, April 18, 2006 2:49 AM
> To: [email-masked]; [email-masked]
> Subject: RE: Protect Algorithm identifiers?
> 
> 
> Jim,
> 
> If the verifier is prepared to accept a weak hash algorithm 
> whereby a new body value can be created with the same hash 
> value, how can the algorithm identifier be protected ?
> 
> Nick Pope
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Jim Schaad
> > Sent: 18 April 2006 04:38
> > To: [email-masked]
> > Subject: Protect Algorithm identifiers?
> >
> >
> >
> > In the process of reviewing documents dealing with multiple 
> signature 
> > processing, I suddenly realized that we currently do not have any 
> > attribute which lets us verify that the correct digest and 
> signature 
> > algorithms have been used in verifying a SignerInfo.  The 
> question is 
> > do we need to do this?
> >
> > More details on what I mean:
> >
> > When you create a signer info you:
> >
> > 1.  Hash the body of the message, place the digest value as 
> a signed 
> > attribute and the digest algorithm into the SignerInfo 
> structure in an 
> > unprotected location.
> >
> > 2.  Create the sequence of signed attributes, hash the 
> value, create a 
> > signature value using your private key and place the signature 
> > algorithm and the signature in unprotected locations.
> >
> > The signature does not need any additional protection, however one 
> > could change the digest algorithms being used in both the signature 
> > and body digest locations without a verifier being able to 
> know that 
> > it has happened.
> >
> >
> > The attack I envision would be to find a body that has a 
> digest of the 
> > same length, but uses a different algorithm and update the 
> SignerInfo 
> > structure with the new digest algorithm data and the body with the 
> > updated body.  This would currently be undetectable by a verifier.
> >
> > Jim
> >
> >
> >
> 
> 
> 
> 
> 

Date: Tue, 18 Apr 2006 17:42:12 +0200
From: Alfonso De Gregorio <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Protect Algorithm identifiers?
Sender: [email-masked]

Jim,

Let H be the set of message digest algorithms supported by the standard
(e.g., SHA-1 and MD5).

If I understand correctly your point, an adversary would be able to mount
the attack whenever _any_ hash function in H is found to be not resistant
against preimage attacks.

Preimage attacks against currently standardized message digest
algorithms would represent a significant cryptanalytic advance.

However, giving the adversaries the freedom to tamper with algorithm
identifiers means increasing their chance of succeeding in attacks
intended to compromise the integrity of the data.

Preimage resistance of all the functions in H at any given moment in
time, is a stronger requirement than preimage resistance for a given
hash function.

In fact, the adversary here is challenged to find any preimage x' such
that h2(x') = y when given any y = h1(x) (h1 in H) and any h2 in H with
h2 != h1.

Hence, I think we should counter this attack by adding integrity to the
selected digest suite. We should look at CMS envelopes as datagrams of
a store-and-forward protocol.

Phasing out weak algorithms may not always be a satisfactory approach,
since legacy systems can be slow to modify.

Workaround:
More resiliency to advances in cryptanalysis of hash functions can be
provided also using different message digest algorithms to compute
multiple digest values of data and requiring the verifier to check
the integrity of the data according to each specified digest algorithm
- while requiring the use of at least two different algorithms.

Alfonso

Jim Schaad wrote:
> In the process of reviewing documents dealing with multiple signature
> processing, I suddenly realized that we currently do not have any attribute
> which lets us verify that the correct digest and signature algorithms have
> been used in verifying a SignerInfo.  The question is do we need to do this?
>
> More details on what I mean:
>
> When you create a signer info you:
>
> 1.  Hash the body of the message, place the digest value as a signed
> attribute and the digest algorithm into the SignerInfo structure in an
> unprotected location.
>
> 2.  Create the sequence of signed attributes, hash the value, create a
> signature value using your private key and place the signature algorithm and
> the signature in unprotected locations.
>
> The signature does not need any additional protection, however one could
> change the digest algorithms being used in both the signature and body
> digest locations without a verifier being able to know that it has happened.
>
>
> The attack I envision would be to find a body that has a digest of the same
> length, but uses a different algorithm and update the SignerInfo structure
> with the new digest algorithm data and the body with the updated body.  This
> would currently be undetectable by a verifier.
>
> Jim
>
>
>   

From: "Nick Pope" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: RE: Protect Algorithm identifiers?
Date: Tue, 18 Apr 2006 10:48:53 +0100
Importance: Normal
Sender: [email-masked]

Jim,

If the verifier is prepared to accept a weak hash algorithm whereby a new
body value can be created with the same hash value, how can the algorithm
identifier be protected ?

Nick Pope

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jim Schaad
> Sent: 18 April 2006 04:38
> To: [email-masked]
> Subject: Protect Algorithm identifiers?
>
>
>
> In the process of reviewing documents dealing with multiple signature
> processing, I suddenly realized that we currently do not have any
> attribute
> which lets us verify that the correct digest and signature algorithms have
> been used in verifying a SignerInfo.  The question is do we need
> to do this?
>
> More details on what I mean:
>
> When you create a signer info you:
>
> 1.  Hash the body of the message, place the digest value as a signed
> attribute and the digest algorithm into the SignerInfo structure in an
> unprotected location.
>
> 2.  Create the sequence of signed attributes, hash the value, create a
> signature value using your private key and place the signature
> algorithm and
> the signature in unprotected locations.
>
> The signature does not need any additional protection, however one could
> change the digest algorithms being used in both the signature and body
> digest locations without a verifier being able to know that it
> has happened.
>
>
> The attack I envision would be to find a body that has a digest
> of the same
> length, but uses a different algorithm and update the SignerInfo structure
> with the new digest algorithm data and the body with the updated
> body.  This
> would currently be undetectable by a verifier.
>
> Jim
>
>
>

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: <[email-masked]>
Subject: Protect Algorithm identifiers?
Date: Mon, 17 Apr 2006 20:38:19 -0700
Sender: [email-masked]

In the process of reviewing documents dealing with multiple signature
processing, I suddenly realized that we currently do not have any attribute
which lets us verify that the correct digest and signature algorithms have
been used in verifying a SignerInfo.  The question is do we need to do this?

More details on what I mean:

When you create a signer info you:

1.  Hash the body of the message, place the digest value as a signed
attribute and the digest algorithm into the SignerInfo structure in an
unprotected location.

2.  Create the sequence of signed attributes, hash the value, create a
signature value using your private key and place the signature algorithm and
the signature in unprotected locations.

The signature does not need any additional protection, however one could
change the digest algorithms being used in both the signature and body
digest locations without a verifier being able to know that it has happened.

The attack I envision would be to find a body that has a digest of the same
length, but uses a different algorithm and update the SignerInfo structure
with the new digest algorithm data and the body with the updated body.  This
would currently be undetectable by a verifier.

Jim

Date: Fri, 07 Apr 2006 19:41:53 +0200
From: Peter Sylvester <[email-masked]>
To: Denis Pinkas <[email-masked]>
CC: "[email-masked]" <[email-masked]>, Jim Schaad <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-smime-escertid-00.txt
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms000906030506070903080702
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

As far as I remember PKIX only has exchanges some message with several 
syntactical
proposals for an attributs, some of them broken, but not talked about the
semantics, or what to do in relation with the surrounding signature 
attribute.

The last seems to me an interesting thing, but it should be done top down,
i.e. what do we really want to signal with this attribute.

Question: As soon as the signature hash algo becomes something like sha256
is there any benefit to use another hash algorithm in some 'id attribute'?

Question: What should be the default value of a hash algorithm, note that
I don't talk about defining it in ASN.1 as DEFAULT something. The field
can be marked OPTIONAL so that it can can easily default to
a value with or without the NULL parameter. 

Furthermore, we have then at least two possible interpretations of an 
absent alog.
1 - A fixed value like sha256
2 - the same as in the signature (or some more elaborated rule like
  if hash length > 160 bits then identical to the sign alg else sha1

Question: If one changes the existing definition of ESSCertid to use
2 above, would this hurt existing implementations to an unacceptable
way, i.e. how many RSA+sha256 signature certs have been deployed.

Question: How much time is necessary to fix the existing software which
is technically already prepared to use sha256 in signatures but not in 
ESSCertIds.
The day this has been agreed and months before the RFC is out? :-)
>
> So, it would make sense to have SHA-256 as the default algorithm 
> for the new structure.
>   
Not necssarily.
> In this thread, some people advocated implicit signaling of the algorithm.
> It made me think that we should provide some additional guidance for 
> implementors. For example, if SHA-256 with RSA is the signature algorithm, 
> then it would make sense, *not* to use ESSCerID :-) but rather to use the 
> new structure with SHA-256.
>   
And it it is sha512+RSA, then one needs to indicate the algo? What make 
sha256
so important that it can be a default?
> Now, the case where SHA-1 with RSA is the signature algorithm is more 
> complicated. ESSCertID should be used. Should we, in addition, recommend 
> to use the new structure with SHA-256 ? It would not hurt, but in case 
> SHA-1 is broken, does it really provide additional security ? I leave the 
> floor open to cryptographers.
>   
If you recommend that the ESSCertid SHOULD contain the IssuerSerial then it
is probably a bit more difficult to create a a true fake cert that not 
only has a proper
ASN.1 encoding, a proper signature, and also a forced issuer name and a 
seriual number.
> F

-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorité; 
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. 

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

--------------ms000906030506070903080702--

From: "Jim Schaad" <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>, <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-smime-escertid-00.txt
Date: Wed, 5 Apr 2006 18:29:46 -0700
Sender: [email-masked]

Denis, 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Denis Pinkas
> Sent: Wednesday, April 05, 2006 6:32 AM
> To: [email-masked]; Jim Schaad
> Subject: Re: I-D ACTION:draft-ietf-smime-escertid-00.txt
> 
> 
> Jim,
> 
> After more thoughs and exchange of arguments I am inclined to 
> accept your position.
> 
> I believe that the rule should be: 
> if SHA-1 is used, then ESSCertID MUST be used.

I would totally agree with this wording.

> 
> So, it would make sense to have SHA-256 as the default 
> algorithm for the new structure.
> 
> In this thread, some people advocated implicit signaling of 
> the algorithm.
> It made me think that we should provide some additional 
> guidance for implementors. For example, if SHA-256 with RSA 
> is the signature algorithm, then it would make sense, *not* 
> to use ESSCerID :-) but rather to use the new structure with SHA-256.
> 
> Now, the case where SHA-1 with RSA is the signature algorithm 
> is more complicated. ESSCertID should be used. Should we, in 
> addition, recommend to use the new structure with SHA-256 ? 
> It would not hurt, but in case
> SHA-1 is broken, does it really provide additional security ? 
> I leave the floor open to cryptographers.
> 
> Finally, I have a minor naming problem: what is it called  
> ESSCertIDEx and not ESSCertIDv2 ? What means "Ex" ?!?  

I have no problems with this change in the name of the structure.  The use
of Ex shows the time that I used to work at Microsoft, Ex stands for
Extended and was applied to system API calls. 

Jim

> 
> I would rather prefer ESSCertIDv2 which is more meaningful 
> without any explanation. 
> 
> Denis
> 
> >Denis,
> >
> >I am well aware that the issue was debated on the PKIX mailing list, 
> >and I ignored it because it was not of immediate importance 
> to me at the time.
> >
> >I am not sure that I agree that the PKIX proposal is really 
> backwards 
> >compatable.  What can be said is that if you use it in a specific 
> >manner then it produces the same bits on the wire, however consider 
> >what the reality of things is.
> >
> >In the S/MIME world the new structure is identified by a new 
> OID, thus 
> >an old client would see that there is an attribute that it 
> does not understand.
> >This means that the new structure is really backwards 
> compatable, if an 
> >old client gets a message from a new client the item is 
> ignored and the 
> >old client can successfully process the message.  Likewise if an old 
> >client sends a message and includes this attribute the new client 
> >should still understand and process the extension correctly.  (This 
> >would also be true with the timestamp protocol in RFC 3161.)
> >
> >Now lets look at what happens with this in RFC 3029 if you simply 
> >replace ESSCertID with your proposed ESSCertIDEx.  If an old client 
> >sends a message to the new client, it works since the new 
> client can correctly decode it.
> >If a new client sends a message to an old client, it MUST 
> use the SHA-1 
> >hash algorithm as any other would cause the old client to 
> have a decode 
> >algorithm.  But it is not clear that the new client can recognize in 
> >advance that it is dealing with an old client so it would ALWAYS use 
> >SHA-1 just in case.  TO me this means that you might as well 
> not change the protocol.
> >(Side note - there is not versioning in the low level 
> structures that I 
> >could see.  If you update the version number then there is 
> no problem 
> >with changing the structure itself.
> >
> >There is some logic to the argument that was put forward by 
> Peter that 
> >having the same effective structure would allow for writing 
> of a single 
> >decode/encode routine and thus potentially save code space.
> >
> >I personally think that we should be moving out of SHA-1 and 
> onto SHA-2 
> >in the standards as quickly as possible.  If I belive this 
> then I need 
> >to take the position that either 1) size is not an issue or 
> 2) the defaults should
> >be the algorithms that we think should be used in the 
> immediate future.   I
> >am a strong supporter of option 2.
> >
> >I will look at your suggested re-write as part of the up-coming 
> >revision of the document.
> >
> >jim   
> >
> >> -----Original Message-----
> >> From: [email-masked]
> >> [mailto:[email-masked]] On Behalf Of Denis Pinkas
> >> Sent: Thursday, March 30, 2006 6:59 AM
> >> To: [email-masked]
> >> Subject: Re: I-D ACTION:draft-ietf-smime-escertid-00.txt
> >> 
> >> 
> >> Jim, and the working group
> >> 
> >> 
> >> 1 - This topic has been debated on the PKIX mailing list and a 
> >>     proposal has been made. The proposed ASN.1 structure 
> is different 
> >>     from the one described in draft-ietf-smime-escertid-00.txt.
> >> 
> >> The current ASN.1 in RFC 2634 is:
> >> 
> >>    ESSCertID ::=  SEQUENCE {
> >>         certHash                 Hash,
> >>         issuerSerial             IssuerSerial OPTIONAL
> >>    }
> >> 
> >> The proposal from draft-ietf-smime-escertid-00.txt is:
> >> 
> >>       ESSCertIDEx ::=  SEQUENCE {
> >>            certHash                 Hash,
> >>            hashAlg                  AlgorithmIdentifier 
> >> DEFAULT {id-sha256},
> >>            issuerSerial             IssuerSerial OPTIONAL
> >>       }
> >>  
> >> The proposal made on the PKIX mailing list is:
> >> 
> >> ESSCertIDv2 ::= SEQUENCE {
> >>     certHash         OCTET STRING,
> >>     issuerSerial     IssuerSerial,
> >>     hashAlgorithm    AlgorithmIdentifier DEFAULT { sha-1 } 
> >> 
> >> The advantage of the last proposal is backward 
> compatibility with the 
> >> existing structure. The disadvantage is that it is less "natural" 
> >> than invented from scratch, but some explanations can 
> easily overcome 
> >> this drawback.
> >> 
> >> I would propose to adopt the proposal made on the PKIX 
> mailing list.
> >> 
> >> In addition, I would take advantage of the rewriting of 
> this section 
> >> to correct some past "errors" in section 5.4.1.
> >> 
> >> 2 - Proposed rewritting:
> >> 
> >> "5.4.1. Certificate Identification
> >> 
> >>    The best way to identify certificates is an 
> often-discussed issue.
> >> 
> >>    When an issuer/serial number pair is included in the SignedData 
> >>    object, that information is not part of the message digest 
> >>    calculation process may thus be changed without being detected.
> >>    That information may only be used as an hint and by 
> itself, does 
> >>    not allow to make sure that the right certificate is being 
> >> accessed.    
> >> 
> >>    A hash of the entire certificate allows a verifier to 
> verify that 
> >>    the certificate that was chosen by the signer is being 
> used when 
> >> the
> >>    signature is verified. It permits a detection of certificate 
> >>    substitution attacks.
> >> 
> >>    Duplication of the issuer/serial number pair within the Signing 
> >>    Certificate attribute is not fully necessary, but has the 
> >>    advantage to get the whole information from that attribute. 
> >> 
> >>    Attribute certificates and additional public key certificates
> >>    containing authorization information do not have an 
> issuer/serial
> >>    number pair represented anywhere in a SignerInfo object. When an
> >>    attribute certificate or an additional public key 
> certificate is 
> >> not
> >>    included in the SignedData object, it becomes much more 
> difficult 
> >> to
> >>    get the correct set of certificates based only on a hash of the
> >>    certificate. For this reason, these certificates SHOULD be 
> >> identified
> >>    by the IssuerSerial object."
> >> 
> >> 3 - It is a matter of taste, but I would rather prefer: 
> >>     SigningCertificatev2 instead of SigningCertificateEx
> >> 
> >> 4 - It would be nice to correct the typos from RFC 2634, e.g. 
> >> "requred".
> >>     There are other typos like: "certficates", "subsiquent", 
> >> "Indentification", ...
> >>     Please use a spell checker.
> >> 
> >> Denis
> >> 
> >> >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-00.txt
> >> >	Pages		: 18
> >> >	Date		: 2006-3-24
> >> >	
> >> >In the original Enhanged Security Services for S/MIME draft, 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 new attributes to deal with
> >> the updating.
> >> >
> >> >
> >> >A URL for this Internet-Draft is:
> >> 
> >http://www.ietf.org/internet-drafts/draft-ietf-smime-escertid-00.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-00.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-00.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.
> >> >
> >> >Content-Type: text/plain
> >> >Content-ID:	<[email-masked]>
> >> >
> >> >ENCODING mime
> >> >FILE /internet-drafts/draft-ietf-smime-escertid-00.txt
> >> 
> 
> Denis Pinkas
> 
> 
> 
> 
> 

Date: Wed, 05 Apr 2006 17:15:36 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Proposed updates to CMS
Sender: [email-masked]

Here are the proposed changes to CMS in support of hash function migration.

Please review and comment.

Russ

= = = = = = = = =

Updates to Section 5: Signed-data Content Type

    Replace the next to the last paragraph in section 5 as follows.

    OLD:

|  A recipient independently computes the message digest.  This message
|  digest and the signer's public key are used to verify the signature
|  value.  The signer's public key is referenced either by an issuer
|  distinguished name along with an issuer-specific serial number or by
|  a subject key identifier that uniquely identifies the certificate
|  containing the public key.  The signer's certificate can be included
|  in the SignedData certificates field.

    NEW:

|  A recipient independently computes the message digest.  This message
|  digest and the signer's public key are used to verify the signature
|  value.  The signer's public key is referenced either by an issuer
|  distinguished name along with an issuer-specific serial number or by
|  a subject key identifier that uniquely identifies the certificate
|  containing the public key.  The signer's certificate can be included
|  in the SignedData certificates field.
|
|  When more than one signature is present, the successful validation
|  of any one of these signatures ought to be treated as a successful
|  validation of the signed-data content type.  The primary reason
|  is that signers may include seperate signatures for different
|  communities of recipients.  For example, the signed-data content
|  type might include signatures generated with the RSA signature
|  algorithm and with the ECDSA signature algorithm.  This allows
|  recipients able to verify one algorithm or the other.

Updates to Section 5.1: SignedData Type

    Replace the next to the last paragraph in section 5.1 as follows.

    OLD:

|     signerInfos is a collection of per-signer information.  There MAY
|     be any number of elements in the collection, including zero.  The
|     details of the SignerInfo type are discussed in section 5.3.
|     Since each signer can employ a digital signature technique and
|     future specifications could update the syntax, all implementations
|     MUST gracefully handle unimplemented versions of SignerInfo.
|     Further, since all implementations will not support every possible
|     signature algorithm, all implementations MUST gracefully handle
|     unimplemented signature algorithms when they are encountered.

    NEW:

|     signerInfos is a collection of per-signer information.  There MAY
|     be any number of elements in the collection, including zero.  When
|     the collection represents more than one signature, the successful
|     validation of any one of these collection members ought to be
|     treated as a successful validation of the signed-data content
|     type.  The details of the SignerInfo type are discussed in
|     section 5.3.  Since each signer can employ a digital signature
|     technique and future specifications could update the syntax, all
|     implementations MUST gracefully handle unimplemented versions of
|     SignerInfo.  Further, since all implementations will not support
|     every possible signature algorithm, all implementations MUST
|     gracefully handle unimplemented signature algorithms when they
|     are encountered.

Date: Wed, 05 Apr 2006 12:17:02 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-smime-escertid-00.txt
Sender: [email-masked]

I can support this approach:

         if SHA-1 is used, then ESSCertID MUST be used.

         if a hash other than SHA-1 is used, then ESSCertIDv2 MUST be used.

Russ

At 09:31 AM 4/5/2006, Denis Pinkas wrote:

>Jim,
>
>After more thoughs and exchange of arguments I am inclined to accept
>your position.
>
>I believe that the rule should be:
>if SHA-1 is used, then ESSCertID MUST be used.
>
>So, it would make sense to have SHA-256 as the default algorithm
>for the new structure.
>
>In this thread, some people advocated implicit signaling of the algorithm.
>It made me think that we should provide some additional guidance for
>implementors. For example, if SHA-256 with RSA is the signature algorithm,
>then it would make sense, *not* to use ESSCerID :-) but rather to use the
>new structure with SHA-256.
>
>Now, the case where SHA-1 with RSA is the signature algorithm is more
>complicated. ESSCertID should be used. Should we, in addition, recommend
>to use the new structure with SHA-256 ? It would not hurt, but in case
>SHA-1 is broken, does it really provide additional security ? I leave the
>floor open to cryptographers.
>
>Finally, I have a minor naming problem: what is it called  ESSCertIDEx
>and not ESSCertIDv2 ? What means "Ex" ?!?
>
>I would rather prefer ESSCertIDv2 which is more meaningful
>without any explanation.
>
>Denis
>
> >Denis,
> >
> >I am well aware that the issue was debated on the PKIX mailing list, and I
> >ignored it because it was not of immediate importance to me at the time.
> >
> >I am not sure that I agree that the PKIX proposal is really backwards
> >compatable.  What can be said is that if you use it in a specific manner
> >then it produces the same bits on the wire, however consider what the
> >reality of things is.
> >
> >In the S/MIME world the new structure is identified by a new OID, thus an
> >old client would see that there is an attribute that it does not understand.
> >This means that the new structure is really backwards compatable, if an old
> >client gets a message from a new client the item is ignored and the old
> >client can successfully process the message.  Likewise if an old client
> >sends a message and includes this attribute the new client should still
> >understand and process the extension correctly.  (This would also be true
> >with the timestamp protocol in RFC 3161.)
> >
> >Now lets look at what happens with this in RFC 3029 if you simply replace
> >ESSCertID with your proposed ESSCertIDEx.  If an old client sends a message
> >to the new client, it works since the new client can correctly decode it.
> >If a new client sends a message to an old client, it MUST use the SHA-1 hash
> >algorithm as any other would cause the old client to have a decode
> >algorithm.  But it is not clear that the new client can recognize in advance
> >that it is dealing with an old client so it would ALWAYS use SHA-1 just in
> >case.  TO me this means that you might as well not change the protocol.
> >(Side note - there is not versioning in the low level structures that I
> >could see.  If you update the version number then there is no problem with
> >changing the structure itself.
> >
> >There is some logic to the argument that was put forward by Peter that
> >having the same effective structure would allow for writing of a single
> >decode/encode routine and thus potentially save code space.
> >
> >I personally think that we should be moving out of SHA-1 and onto SHA-2 in
> >the standards as quickly as possible.  If I belive this then I need to take
> >the position that either 1) size is not an issue or 2) the defaults should
> >be the algorithms that we think should be used in the immediate future.   I
> >am a strong supporter of option 2.
> >
> >I will look at your suggested re-write as part of the up-coming revision of
> >the document.
> >
> >jim
> >
> >> -----Original Message-----
> >> From: [email-masked]
> >> [mailto:[email-masked]] On Behalf Of Denis Pinkas
> >> Sent: Thursday, March 30, 2006 6:59 AM
> >> To: [email-masked]
> >> Subject: Re: I-D ACTION:draft-ietf-smime-escertid-00.txt
> >>
> >>
> >> Jim, and the working group
> >>
> >>
> >> 1 - This topic has been debated on the PKIX mailing list and a
> >>     proposal has been made. The proposed ASN.1 structure is different
> >>     from the one described in draft-ietf-smime-escertid-00.txt.
> >>
> >> The current ASN.1 in RFC 2634 is:
> >>
> >>    ESSCertID ::=  SEQUENCE {
> >>         certHash                 Hash,
> >>         issuerSerial             IssuerSerial OPTIONAL
> >>    }
> >>
> >> The proposal from draft-ietf-smime-escertid-00.txt is:
> >>
> >>       ESSCertIDEx ::=  SEQUENCE {
> >>            certHash                 Hash,
> >>            hashAlg                  AlgorithmIdentifier
> >> DEFAULT {id-sha256},
> >>            issuerSerial             IssuerSerial OPTIONAL
> >>       }
> >>
> >> The proposal made on the PKIX mailing list is:
> >>
> >> ESSCertIDv2 ::= SEQUENCE {
> >>     certHash         OCTET STRING,
> >>     issuerSerial     IssuerSerial,
> >>     hashAlgorithm    AlgorithmIdentifier DEFAULT { sha-1 }
> >>
> >> The advantage of the last proposal is backward compatibility
> >> with the existing structure. The disadvantage is that it is
> >> less "natural" than invented from scratch, but some
> >> explanations can easily overcome this drawback.
> >>
> >> I would propose to adopt the proposal made on the PKIX mailing list.
> >>
> >> In addition, I would take advantage of the rewriting of this
> >> section to correct some past "errors" in section 5.4.1.
> >>
> >> 2 - Proposed rewritting:
> >>
> >> "5.4.1. Certificate Identification
> >>
> >>    The best way to identify certificates is an often-discussed issue.
> >>
> >>    When an issuer/serial number pair is included in the SignedData
> >>    object, that information is not part of the message digest
> >>    calculation process may thus be changed without being detected.
> >>    That information may only be used as an hint and by itself, does
> >>    not allow to make sure that the right certificate is being
> >> accessed.
> >>
> >>    A hash of the entire certificate allows a verifier to verify that
> >>    the certificate that was chosen by the signer is being
> >> used when the
> >>    signature is verified. It permits a detection of certificate
> >>    substitution attacks.
> >>
> >>    Duplication of the issuer/serial number pair within the Signing
> >>    Certificate attribute is not fully necessary, but has the
> >>    advantage to get the whole information from that attribute.
> >>
> >>    Attribute certificates and additional public key certificates
> >>    containing authorization information do not have an issuer/serial
> >>    number pair represented anywhere in a SignerInfo object. When an
> >>    attribute certificate or an additional public key
> >> certificate is not
> >>    included in the SignedData object, it becomes much more
> >> difficult to
> >>    get the correct set of certificates based only on a hash of the
> >>    certificate. For this reason, these certificates SHOULD be
> >> identified
> >>    by the IssuerSerial object."
> >>
> >> 3 - It is a matter of taste, but I would rather prefer:
> >>     SigningCertificatev2 instead of SigningCertificateEx
> >>
> >> 4 - It would be nice to correct the typos from RFC 2634, e.g.
> >> "requred".
> >>     There are other typos like: "certficates", "subsiquent",
> >> "Indentification", ...
> >>     Please use a spell checker.
> >>
> >> Denis
> >>
> >> >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-00.txt
> >> >    Pages           : 18
> >> >    Date            : 2006-3-24
> >> >
> >> >In the original Enhanged Security Services for S/MIME draft, 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 new attributes to deal with
> >> the updating.
> >> >
> >> >
> >> >A URL for this Internet-Draft is:
> >> >http://www.ietf.org/internet-drafts/draft-ietf-smime-escertid-00.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-00.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-00.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.
> >> >
> >> >Content-Type: text/plain
> >> >Content-ID: <[email-masked]>
> >> >
> >> >ENCODING mime
> >> >FILE /internet-drafts/draft-ietf-smime-escertid-00.txt
> >>
>
>Denis Pinkas

Date: Wed, 5 Apr 2006 14:31:50 +0100
From: "Denis Pinkas" <[email-masked]>
To: "[email-masked]" <[email-masked]>, "Jim Schaad" <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-smime-escertid-00.txt
Sender: [email-masked]

Jim,

After more thoughs and exchange of arguments I am inclined to accept 
your position.

I believe that the rule should be: 
if SHA-1 is used, then ESSCertID MUST be used.

So, it would make sense to have SHA-256 as the default algorithm 
for the new structure.

In this thread, some people advocated implicit signaling of the algorithm.
It made me think that we should provide some additional guidance for 
implementors. For example, if SHA-256 with RSA is the signature algorithm, 
then it would make sense, *not* to use ESSCerID :-) but rather to use the 
new structure with SHA-256.

Now, the case where SHA-1 with RSA is the signature algorithm is more 
complicated. ESSCertID should be used. Should we, in addition, recommend 
to use the new structure with SHA-256 ? It would not hurt, but in case 
SHA-1 is broken, does it really provide additional security ? I leave the 
floor open to cryptographers.

Finally, I have a minor naming problem: what is it called  ESSCertIDEx 
and not ESSCertIDv2 ? What means "Ex" ?!?  

I would rather prefer ESSCertIDv2 which is more meaningful 
without any explanation. 

Denis

>Denis,
>
>I am well aware that the issue was debated on the PKIX mailing list, and I
>ignored it because it was not of immediate importance to me at the time. 
>
>I am not sure that I agree that the PKIX proposal is really backwards
>compatable.  What can be said is that if you use it in a specific manner
>then it produces the same bits on the wire, however consider what the
>reality of things is.
>
>In the S/MIME world the new structure is identified by a new OID, thus an
>old client would see that there is an attribute that it does not understand.
>This means that the new structure is really backwards compatable, if an old
>client gets a message from a new client the item is ignored and the old
>client can successfully process the message.  Likewise if an old client
>sends a message and includes this attribute the new client should still
>understand and process the extension correctly.  (This would also be true
>with the timestamp protocol in RFC 3161.) 
>
>Now lets look at what happens with this in RFC 3029 if you simply replace
>ESSCertID with your proposed ESSCertIDEx.  If an old client sends a message
>to the new client, it works since the new client can correctly decode it.
>If a new client sends a message to an old client, it MUST use the SHA-1 hash
>algorithm as any other would cause the old client to have a decode
>algorithm.  But it is not clear that the new client can recognize in advance
>that it is dealing with an old client so it would ALWAYS use SHA-1 just in
>case.  TO me this means that you might as well not change the protocol.
>(Side note - there is not versioning in the low level structures that I
>could see.  If you update the version number then there is no problem with
>changing the structure itself.
>
>There is some logic to the argument that was put forward by Peter that
>having the same effective structure would allow for writing of a single
>decode/encode routine and thus potentially save code space.
>
>I personally think that we should be moving out of SHA-1 and onto SHA-2 in
>the standards as quickly as possible.  If I belive this then I need to take
>the position that either 1) size is not an issue or 2) the defaults should
>be the algorithms that we think should be used in the immediate future.   I
>am a strong supporter of option 2.
>
>I will look at your suggested re-write as part of the up-coming revision of
>the document.
>
>jim   
>
>> -----Original Message-----
>> From: [email-masked] 
>> [mailto:[email-masked]] On Behalf Of Denis Pinkas
>> Sent: Thursday, March 30, 2006 6:59 AM
>> To: [email-masked]
>> Subject: Re: I-D ACTION:draft-ietf-smime-escertid-00.txt
>> 
>> 
>> Jim, and the working group
>> 
>> 
>> 1 - This topic has been debated on the PKIX mailing list and a 
>>     proposal has been made. The proposed ASN.1 structure is different 
>>     from the one described in draft-ietf-smime-escertid-00.txt.
>> 
>> The current ASN.1 in RFC 2634 is:
>> 
>>    ESSCertID ::=  SEQUENCE {
>>         certHash                 Hash,
>>         issuerSerial             IssuerSerial OPTIONAL
>>    }
>> 
>> The proposal from draft-ietf-smime-escertid-00.txt is:
>> 
>>       ESSCertIDEx ::=  SEQUENCE {
>>            certHash                 Hash,
>>            hashAlg                  AlgorithmIdentifier 
>> DEFAULT {id-sha256},
>>            issuerSerial             IssuerSerial OPTIONAL
>>       }
>>  
>> The proposal made on the PKIX mailing list is:
>> 
>> ESSCertIDv2 ::= SEQUENCE {
>>     certHash         OCTET STRING,
>>     issuerSerial     IssuerSerial,
>>     hashAlgorithm    AlgorithmIdentifier DEFAULT { sha-1 } 
>> 
>> The advantage of the last proposal is backward compatibility 
>> with the existing structure. The disadvantage is that it is 
>> less "natural" than invented from scratch, but some 
>> explanations can easily overcome this drawback.
>> 
>> I would propose to adopt the proposal made on the PKIX mailing list.
>> 
>> In addition, I would take advantage of the rewriting of this 
>> section to correct some past "errors" in section 5.4.1.
>> 
>> 2 - Proposed rewritting:
>> 
>> "5.4.1. Certificate Identification
>> 
>>    The best way to identify certificates is an often-discussed issue.
>> 
>>    When an issuer/serial number pair is included in the SignedData 
>>    object, that information is not part of the message digest 
>>    calculation process may thus be changed without being detected.
>>    That information may only be used as an hint and by itself, does 
>>    not allow to make sure that the right certificate is being 
>> accessed.    
>> 
>>    A hash of the entire certificate allows a verifier to verify that 
>>    the certificate that was chosen by the signer is being 
>> used when the 
>>    signature is verified. It permits a detection of certificate 
>>    substitution attacks.
>> 
>>    Duplication of the issuer/serial number pair within the Signing 
>>    Certificate attribute is not fully necessary, but has the 
>>    advantage to get the whole information from that attribute. 
>> 
>>    Attribute certificates and additional public key certificates
>>    containing authorization information do not have an issuer/serial
>>    number pair represented anywhere in a SignerInfo object. When an
>>    attribute certificate or an additional public key 
>> certificate is not
>>    included in the SignedData object, it becomes much more 
>> difficult to
>>    get the correct set of certificates based only on a hash of the
>>    certificate. For this reason, these certificates SHOULD be 
>> identified
>>    by the IssuerSerial object."
>> 
>> 3 - It is a matter of taste, but I would rather prefer: 
>>     SigningCertificatev2 instead of SigningCertificateEx  
>> 
>> 4 - It would be nice to correct the typos from RFC 2634, e.g. 
>> "requred".
>>     There are other typos like: "certficates", "subsiquent", 
>> "Indentification", ... 
>>     Please use a spell checker.
>> 
>> Denis
>> 
>> >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-00.txt
>> >	Pages		: 18
>> >	Date		: 2006-3-24
>> >	
>> >In the original Enhanged Security Services for S/MIME draft, 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 new attributes to deal with 
>> the updating.
>> >
>> >
>> >A URL for this Internet-Draft is:
>> >http://www.ietf.org/internet-drafts/draft-ietf-smime-escertid-00.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-00.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-00.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.
>> >
>> >Content-Type: text/plain
>> >Content-ID:	<[email-masked]>
>> >
>> >ENCODING mime
>> >FILE /internet-drafts/draft-ietf-smime-escertid-00.txt
>> 

Denis Pinkas

From: "Jim Schaad" <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>, <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-smime-escertid-00.txt
Date: Tue, 4 Apr 2006 20:47:09 -0700
Sender: [email-masked]

Denis,

I am well aware that the issue was debated on the PKIX mailing list, and I
ignored it because it was not of immediate importance to me at the time. 

I am not sure that I agree that the PKIX proposal is really backwards
compatable.  What can be said is that if you use it in a specific manner
then it produces the same bits on the wire, however consider what the
reality of things is.

In the S/MIME world the new structure is identified by a new OID, thus an
old client would see that there is an attribute that it does not understand.
This means that the new structure is really backwards compatable, if an old
client gets a message from a new client the item is ignored and the old
client can successfully process the message.  Likewise if an old client
sends a message and includes this attribute the new client should still
understand and process the extension correctly.  (This would also be true
with the timestamp protocol in RFC 3161.) 

Now lets look at what happens with this in RFC 3029 if you simply replace
ESSCertID with your proposed ESSCertIDEx.  If an old client sends a message
to the new client, it works since the new client can correctly decode it.
If a new client sends a message to an old client, it MUST use the SHA-1 hash
algorithm as any other would cause the old client to have a decode
algorithm.  But it is not clear that the new client can recognize in advance
that it is dealing with an old client so it would ALWAYS use SHA-1 just in
case.  TO me this means that you might as well not change the protocol.
(Side note - there is not versioning in the low level structures that I
could see.  If you update the version number then there is no problem with
changing the structure itself.

There is some logic to the argument that was put forward by Peter that
having the same effective structure would allow for writing of a single
decode/encode routine and thus potentially save code space.

I personally think that we should be moving out of SHA-1 and onto SHA-2 in
the standards as quickly as possible.  If I belive this then I need to take
the position that either 1) size is not an issue or 2) the defaults should
be the algorithms that we think should be used in the immediate future.   I
am a strong supporter of option 2.

I will look at your suggested re-write as part of the up-coming revision of
the document.

jim   

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Denis Pinkas
> Sent: Thursday, March 30, 2006 6:59 AM
> To: [email-masked]
> Subject: Re: I-D ACTION:draft-ietf-smime-escertid-00.txt
> 
> 
> Jim, and the working group
> 
> 
> 1 - This topic has been debated on the PKIX mailing list and a 
>     proposal has been made. The proposed ASN.1 structure is different 
>     from the one described in draft-ietf-smime-escertid-00.txt.
> 
> The current ASN.1 in RFC 2634 is:
> 
>    ESSCertID ::=  SEQUENCE {
>         certHash                 Hash,
>         issuerSerial             IssuerSerial OPTIONAL
>    }
> 
> The proposal from draft-ietf-smime-escertid-00.txt is:
> 
>       ESSCertIDEx ::=  SEQUENCE {
>            certHash                 Hash,
>            hashAlg                  AlgorithmIdentifier 
> DEFAULT {id-sha256},
>            issuerSerial             IssuerSerial OPTIONAL
>       }
>  
> The proposal made on the PKIX mailing list is:
> 
> ESSCertIDv2 ::= SEQUENCE {
>     certHash         OCTET STRING,
>     issuerSerial     IssuerSerial,
>     hashAlgorithm    AlgorithmIdentifier DEFAULT { sha-1 } 
> 
> The advantage of the last proposal is backward compatibility 
> with the existing structure. The disadvantage is that it is 
> less "natural" than invented from scratch, but some 
> explanations can easily overcome this drawback.
> 
> I would propose to adopt the proposal made on the PKIX mailing list.
> 
> In addition, I would take advantage of the rewriting of this 
> section to correct some past "errors" in section 5.4.1.
> 
> 2 - Proposed rewritting:
> 
> "5.4.1. Certificate Identification
> 
>    The best way to identify certificates is an often-discussed issue.
> 
>    When an issuer/serial number pair is included in the SignedData 
>    object, that information is not part of the message digest 
>    calculation process may thus be changed without being detected.
>    That information may only be used as an hint and by itself, does 
>    not allow to make sure that the right certificate is being 
> accessed.    
> 
>    A hash of the entire certificate allows a verifier to verify that 
>    the certificate that was chosen by the signer is being 
> used when the 
>    signature is verified. It permits a detection of certificate 
>    substitution attacks.
> 
>    Duplication of the issuer/serial number pair within the Signing 
>    Certificate attribute is not fully necessary, but has the 
>    advantage to get the whole information from that attribute. 
> 
>    Attribute certificates and additional public key certificates
>    containing authorization information do not have an issuer/serial
>    number pair represented anywhere in a SignerInfo object. When an
>    attribute certificate or an additional public key 
> certificate is not
>    included in the SignedData object, it becomes much more 
> difficult to
>    get the correct set of certificates based only on a hash of the
>    certificate. For this reason, these certificates SHOULD be 
> identified
>    by the IssuerSerial object."
> 
> 3 - It is a matter of taste, but I would rather prefer: 
>     SigningCertificatev2 instead of SigningCertificateEx  
> 
> 4 - It would be nice to correct the typos from RFC 2634, e.g. 
> "requred".
>     There are other typos like: "certficates", "subsiquent", 
> "Indentification", ... 
>     Please use a spell checker.
> 
> Denis
> 
> >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-00.txt
> >	Pages		: 18
> >	Date		: 2006-3-24
> >	
> >In the original Enhanged Security Services for S/MIME draft, 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 new attributes to deal with 
> the updating.
> >
> >
> >A URL for this Internet-Draft is:
> >http://www.ietf.org/internet-drafts/draft-ietf-smime-escertid-00.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-00.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-00.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.
> >
> >Content-Type: text/plain
> >Content-ID:	<[email-masked]>
> >
> >ENCODING mime
> >FILE /internet-drafts/draft-ietf-smime-escertid-00.txt
> 
> 
> 
> 

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-smime-escertid-00.txt
Cc: [email-masked]
Date: Tue, 04 Apr 2006 13:30:46 +1200
Sender: [email-masked]

Russ Housley <[email-masked]> writes:
>At 09:35 PM 3/30/2006, Peter Gutmann wrote:
>>ESSCertIDv2 ::= SEQUENCE {
>>     hashAlgorithm    AlgorithmIdentifier DEFAULT { { algorithm
>> sha-1, parameters NULL} }
>>     certHash         Hash,
>>     issuerSerial     IssuerSerial OPTIONAL
>>     }
>
>I do not see a way to use this syntax and say that the parameters are absent.
>I prefer absent to NULL.

Oh, I was just quoting Peter Sylvester's ASN.1, since he's using current ASN.1
which can't be used in IETF RFCs anyway, it shouldn't be an issue, the
parameter info will just disappear once it's back-translated in the obsolete
1988 form.

Peter.

Cc: [email-masked], [email-masked]
From: Blake Ramsdell <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-smime-escertid-00.txt
Date: Mon, 3 Apr 2006 11:52:09 -0700
To: Russ Housley <[email-masked]>
Sender: [email-masked]

On Apr 3, 2006, at 8:30 AM, Russ Housley wrote:
> I do not see a way to use this syntax and say that the parameters  
> are absent.  I prefer absent to NULL.

Now we get back into the "Great Algorithm Identifier Parameters  
Debate of 1997" where we discuss the merits of NULL vs. absent for  
algorithm identifiers. Early implementations looking for SHA-1 as an  
AlgorithmIdentifier expected NULL as parameters also.

So despite the personal preference (which I think influenced some of  
this discussion in CMS and MSG), the old school practice with  
AlgorithmIdentifiers was "NULL for parameters".

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

Date: Mon, 03 Apr 2006 11:30:23 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-smime-escertid-00.txt
Cc: [email-masked]
Sender: [email-masked]

Peter:

I do not see a way to use this syntax and say that the parameters are 
absent.  I prefer absent to NULL.

Russ

At 09:35 PM 3/30/2006, Peter Gutmann wrote:

>ESSCertIDv2 ::= SEQUENCE {
>     hashAlgorithm    AlgorithmIdentifier DEFAULT { { algorithm 
> sha-1, parameters NULL} }
>     certHash         Hash,
>     issuerSerial     IssuerSerial OPTIONAL
>     }

Date: Sun, 02 Apr 2006 18:04:52 +0200
From: Peter Sylvester <[email-masked]>
To: Peter Gutmann <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-smime-escertid-00.txt
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

My comment was related to the syntax.

Another option would be not to use a fixed default but rather make the
hashAlgoritm OPTIONAL and say that it is the same as used in
to create the signature around (or SHA1 if the hash length is less than 
224 bits)

If one still use the same attribute: the implementations that understand
sha256- in a signature and use ESSCertID would be hit.

But as P.G. said, if one uses another attribute...

Peter Gutmann wrote:
> Peter Sylvester <[email-masked]> writes:
>
>   
>> ESSCertIDv2 ::= SEQUENCE {
>>    certHash         Hash,
>>    issuerSerial     IssuerSerial OPTIONAL,
>>    hashAlgorithm    [0] AlgorithmIdentifier DEFAULT { { algorithm sha-1, parameters NULL} }
>>     
>
> It'd be easier to just go with Russ' suggestion of:
>
> ESSCertIDv2 ::= SEQUENCE {
>     hashAlgorithm    AlgorithmIdentifier DEFAULT { { algorithm sha-1, parameters NULL} }
>     certHash         Hash,
>     issuerSerial     IssuerSerial OPTIONAL
>     }
>
> See my earlier message on why this won't present any backwards-compatibility
> problems with the original ESSCertID.
>
> Peter.
>
>
>
>   

-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorité; 
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. 

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

--------------ms010300050209030204060904--