From: [email-masked]
Date: Tue, 31 Jan 2006 22:54:55 -0500 (EST)

Date: Thu, 26 Jan 2006 16:17:31 -0500
To: Joël Repiquet <[email-masked]>, [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: About countersignature in RFC 4134
Sender: [email-masked]

Has anyone confirmed this issue.  If it is confirmed, the WG should 
submit an errata to the RFC Editor.

Russ

At 02:36 AM 1/23/2006, Joël Repiquet wrote:

>Hi,
>
>In the "Fancier Signed Content" example of RFC4134, it
>is mentioned that the countersignature is performed by
>Diane (p. 53).
>However, the certificate serial number in the related
>attribute p.66, at offset 2591, is Alice's one:
>
>46 34 6B C7 80 00 56 BC 11 D3 6E 2E
>C4 10 B3 B0
>
>It should be:
>46 34 6B C7 80 00 56 BC 11 D3 6E 2E
>D5 9A 30 90
>
>It should be noticed that Diane's RSA certificate is
>not in the list of this CMS message.
>
>
>Joël
>
>
>
>
>
>
>___________________________________________________________________________
>Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les 
>tarifs exceptionnels pour appeler la France et l'international.
>Téléchargez sur http://fr.messenger.yahoo.com

From: Kenji Urushima <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Re: WG LAST CALL: draft-ietf-smime-cades-00.txt
Date: Tue, 24 Jan 2006 23:11:19 +0900
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C620EF.B9E6E05E
Content-Type: text/plain

Hi all,

I have missed to comment before 
the end of the last call however
I'll rather comment to the draft.

1) Archive Timestamp attribute type OID issue
   (Section 6.4.1 Archive time-stamp attribute definition)

The archive hash calculation method was entirely changed
between RFC 3126 and CAdES I-D. As for archive timestamp attribute
itself we can't find which method was used.
So I think it would be better if other
OID is assigned to the attribute.

> id-aa-ets-archiveTimestamp OBJECT IDENTIFIER ::= { iso(1) member-
> body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 27}

2) Archive Hash Target Issue (6.4.1 Archive time-stamp attribute definition)

I think the archive hash method definition in this I-D and 
ETSI TS 101 733 v1.5.1 or later is ambiguous than RFC 3126.

2-1) encapContentInfo as archive hash target

the I-D definition is below:

> The value of messageImprint field within TimeStampToken shall be a hash 
> of the concatenation of:
> 
>   - The encapContentInfo element of the SignedData sequence;

As for CMS SignedData, a document to be signed may be included
in the 'attached signature' form or excluded in the 'detached signature'
form.
There is no description about those differences in the I-D.
I think a signing document should be add to archive hash targets
in order to archive long term integrity however
to encode attached format encapContentInfo for huge data
will be hard work. Also eContent of encapContentInfo may represented
indefinite length data of ASN.1 BER encoding.
(See `5.2.  EncapsulatedContentInfo Type' of RFC 3852)
It may better to add only signing data itself.

2-2) normalization of ASN.1 BER encoded data

A signedAttrs field of CMS SignedData should be
DER encoded as described in the CMS definition:

> RFC 3852 CMS '5.3.  SignerInfo Type'
>
>      signedAttrs is a collection of attributes that are signed.  The
>      field is optional, but it MUST be present if the content type of
>      the EncapsulatedContentInfo value being signed is not id-data.
>      SignedAttributes MUST be DER encoded, even if the rest of the
>      structure is BER encoded.  Useful attribute types, such as signing
>      time, are defined in Section 11.  If the field is present, it MUST
>      contain, at a minimum, the following two attributes:

I think other fields which are added to archive hash target should be
normalized to DER encoding since hash value results may vary for 
its encoding. I think the way of normalization for archive hash target
should
be described in the I-D.

3) Version 3 SignedData issue (5.4 SignedData type)

> The syntax of the SignedData of the ES is as defined in CMS (RFC 3852 
> [4]).
> 
> The fields of type SignedData have the meanings as defined in CMS (RFC 
> 3852 [4]) except that:
> 
>    - the syntax version number value shall be 3.

I'm afraid that a certificate without subjectKeyIdentifier extension
can not be used for CAdES in many cases.
Since if any attribute certificates will not included in the SignedData and
the signer's certificate has no subjectKeyIdentifier
X.509.v3 extension then it will be version 1 SignedData.
(See the definitions in RFC 3852 section 5.1 and 5.3)

What do you think?

Kenji

--
Kenji URUSHIMA | Entrust Japan | http://japan.entrust.com/

------_=_NextPart_001_01C620EF.B9E6E05E
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2658.34">
<TITLE>Re: WG LAST CALL: draft-ietf-smime-cades-00.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Hi all,</FONT>
</P>

<P><FONT SIZE=2>I have missed to comment before </FONT>
<BR><FONT SIZE=2>the end of the last call however</FONT>
<BR><FONT SIZE=2>I'll rather comment to the draft.</FONT>
</P>

<P><FONT SIZE=2>1) Archive Timestamp attribute type OID issue</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; (Section 6.4.1 Archive time-stamp attribute definition)</FONT>
</P>

<P><FONT SIZE=2>The archive hash calculation method was entirely changed</FONT>
<BR><FONT SIZE=2>between RFC 3126 and CAdES I-D. As for archive timestamp attribute</FONT>
<BR><FONT SIZE=2>itself we can't find which method was used.</FONT>
<BR><FONT SIZE=2>So I think it would be better if other</FONT>
<BR><FONT SIZE=2>OID is assigned to the attribute.</FONT>
</P>

<P><FONT SIZE=2>&gt; id-aa-ets-archiveTimestamp OBJECT IDENTIFIER ::= { iso(1) member-</FONT>
<BR><FONT SIZE=2>&gt; body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 27}</FONT>
</P>

<P><FONT SIZE=2>2) Archive Hash Target Issue (6.4.1 Archive time-stamp attribute definition)</FONT>
</P>

<P><FONT SIZE=2>I think the archive hash method definition in this I-D and </FONT>
<BR><FONT SIZE=2>ETSI TS 101 733 v1.5.1 or later is ambiguous than RFC 3126.</FONT>
</P>

<P><FONT SIZE=2>2-1) encapContentInfo as archive hash target</FONT>
</P>

<P><FONT SIZE=2>the I-D definition is below:</FONT>
</P>

<P><FONT SIZE=2>&gt; The value of messageImprint field within TimeStampToken shall be a hash </FONT>
<BR><FONT SIZE=2>&gt; of the concatenation of:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp; - The encapContentInfo element of the SignedData sequence;</FONT>
</P>

<P><FONT SIZE=2>As for CMS SignedData, a document to be signed may be included</FONT>
<BR><FONT SIZE=2>in the 'attached signature' form or excluded in the 'detached signature' form.</FONT>
<BR><FONT SIZE=2>There is no description about those differences in the I-D.</FONT>
<BR><FONT SIZE=2>I think a signing document should be add to archive hash targets</FONT>
<BR><FONT SIZE=2>in order to archive long term integrity however</FONT>
<BR><FONT SIZE=2>to encode attached format encapContentInfo for huge data</FONT>
<BR><FONT SIZE=2>will be hard work. Also eContent of encapContentInfo may represented</FONT>
<BR><FONT SIZE=2>indefinite length data of ASN.1 BER encoding.</FONT>
<BR><FONT SIZE=2>(See `5.2.&nbsp; EncapsulatedContentInfo Type' of RFC 3852)</FONT>
<BR><FONT SIZE=2>It may better to add only signing data itself.</FONT>
</P>

<P><FONT SIZE=2>2-2) normalization of ASN.1 BER encoded data</FONT>
</P>

<P><FONT SIZE=2>A signedAttrs field of CMS SignedData should be</FONT>
<BR><FONT SIZE=2>DER encoded as described in the CMS definition:</FONT>
</P>

<P><FONT SIZE=2>&gt; RFC 3852 CMS '5.3.&nbsp; SignerInfo Type'</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; signedAttrs is a collection of attributes that are signed.&nbsp; The</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; field is optional, but it MUST be present if the content type of</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the EncapsulatedContentInfo value being signed is not id-data.</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SignedAttributes MUST be DER encoded, even if the rest of the</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; structure is BER encoded.&nbsp; Useful attribute types, such as signing</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; time, are defined in Section 11.&nbsp; If the field is present, it MUST</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; contain, at a minimum, the following two attributes:</FONT>
</P>

<P><FONT SIZE=2>I think other fields which are added to archive hash target should be</FONT>
<BR><FONT SIZE=2>normalized to DER encoding since hash value results may vary for </FONT>
<BR><FONT SIZE=2>its encoding. I think the way of normalization for archive hash target should</FONT>
<BR><FONT SIZE=2>be described in the I-D.</FONT>
</P>

<P><FONT SIZE=2>3) Version 3 SignedData issue (5.4 SignedData type)</FONT>
</P>

<P><FONT SIZE=2>&gt; The syntax of the SignedData of the ES is as defined in CMS (RFC 3852 </FONT>
<BR><FONT SIZE=2>&gt; [4]).</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; The fields of type SignedData have the meanings as defined in CMS (RFC </FONT>
<BR><FONT SIZE=2>&gt; 3852 [4]) except that:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; - the syntax version number value shall be 3.</FONT>
</P>

<P><FONT SIZE=2>I'm afraid that a certificate without subjectKeyIdentifier extension</FONT>
<BR><FONT SIZE=2>can not be used for CAdES in many cases.</FONT>
<BR><FONT SIZE=2>Since if any attribute certificates will not included in the SignedData and</FONT>
<BR><FONT SIZE=2>the signer's certificate has no subjectKeyIdentifier</FONT>
<BR><FONT SIZE=2>X.509.v3 extension then it will be version 1 SignedData.</FONT>
<BR><FONT SIZE=2>(See the definitions in RFC 3852 section 5.1 and 5.3)</FONT>
</P>

<P><FONT SIZE=2>What do you think?</FONT>
</P>

<P><FONT SIZE=2>Kenji</FONT>
</P>

<P><FONT SIZE=2>--</FONT>
<BR><FONT SIZE=2>Kenji URUSHIMA | Entrust Japan | <A HREF="http://japan.entrust.com/" TARGET="_blank">http://japan.entrust.com/</A></FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C620EF.B9E6E05E--

Date: Mon, 23 Jan 2006 08:36:00 +0100 (CET)
From: =?iso-8859-1?q?Jo=EBl=20Repiquet?= <[email-masked]>
Subject: About countersignature in RFC 4134
To: [email-masked]
Sender: [email-masked]

Hi,

In the "Fancier Signed Content" example of RFC4134, it
is mentioned that the countersignature is performed by
Diane (p. 53).
However, the certificate serial number in the related
attribute p.66, at offset 2591, is Alice's one:

46 34 6B C7 80 00 56 BC 11 D3 6E 2E
C4 10 B3 B0

It should be:
46 34 6B C7 80 00 56 BC 11 D3 6E 2E
D5 9A 30 90

It should be noticed that Diane's RSA certificate is
not in the list of this CMS message.

Joël

		
___________________________________________________________________________ 
Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international.
Téléchargez sur http://fr.messenger.yahoo.com

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-gost-07.txt 
Date: Thu, 19 Jan 2006 18:50:01 -0500
Sender: [email-masked]

--NextPart

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

	Title		: Using the GOST 28147-89, GOST R 34.11-94, 
                          GOST R 34.10-94 and GOST R 34.10-2001 
                          algorithms with the Cryptographic Message 
                          Syntax (CMS)
	Author(s)	: S. Leontiev, G. Chudov
	Filename	: draft-ietf-smime-gost-07.txt
	Pages		: 27
	Date		: 2006-1-19
	
This document describes the conventions for using cryptographic
   algorithms GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, GOST R
   34.11-94, along with Cryptographic Message Syntax (CMS). The CMS is
   used for digital signature, digest, authentication and encryption of
   arbitrary message contents.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-gost-07.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-gost-07.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-gost-07.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-gost-07.txt

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

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

--OtherAccess--

--NextPart--

From: "Tony Capel" <[email-masked]>
To: "'Alicia da Conceicao'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: SignedAttribute for Mime-Type
Date: Fri, 13 Jan 2006 14:09:47 -0500
Importance: Normal
Sender: [email-masked]

Alicia (sorry for the delay in replying):

I think the contents hints might only need to specify MIME, or
[ASN.1+content encoding rules], ....  The hints would just 
identify the next protocol sublayer to process the content
(service access point). 

So the hints candidates might be:
1. MIME
2. ASN.1 + BER/DER
3. ASN.1 + PER  (?)
+ future and private use OIDs.

Both MIME and ASN.1 BER have the ability to identify content so I expect that
"future and private use" would only be for applications which are NOT using
these encodings (since they provide their own extension mechanisms).  This would
minimize the impact on CMS (we don't need OIDs matching MIME types for example).

On your second point about the clarity of the current text, I agree some added
words might be useful to cover the case where no content hints are provided (and
no a priori agreement exists).  The use of MIME within "e-mail applications"
might be considered as implying an a priori agreement - so I am not convinced
there is a serious problem.  It is tempting to point out that long and
indefinite BER encodings of ASN.1 will have the msb of the first octet set while
"common" 7-bit MIME will not.  However I am not sure that the BER short form is
never used, or that we can guarantee all 7-bit MIME has the msb clear.  Maybe
others would comment whether such text would help (and not break existing
implementations).

Russ has just reminded us of another issue raised by Bellovin and Rescorla
(multi-level signature) potentially impacting CMS, so perhaps this should be
discussed some more if that is the direction of the WG.

Tony

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Alicia da Conceicao
Sent: December 13, 2005 6:12 PM
To: Tony Capel
Cc: [email-masked]
Subject: Re: SignedAttribute for Mime-Type

Hi Tony:

Sorry that I did properly clarify all of my points in my first post. I can
appreciate why you prefer to use S/MIME headers with binary transfer encoding in
the data of CMS-SignedData structures.  To be honest, I planned to do the same
as well, especially since it is able to interop with countless existing S/MIME
applications and opensource libraries such as OpenSSL that have S/MIME support.
But as you mentioned, we both have different requirements for our CMS
applications, and for me I need to support detached signatures.

But Chris Bonatti's suggestion of specifing the MIME-type in the
contentDescription of a ContentHints signedAtrribute in a CMS structure would be
benifical to both of us, and everyone else as well.  It is a win-win for all!

For your CMS signedData structures with S/MIME headers and binary transfer
encoding, you could specify in the ContentHints attribute a specific a MIME-type
such as:

	Content-Type: multipart/mixed
or	Content-Type: application/pkcs7-mime

that would instruct the CMS software that it needs to parse the S/MIME text
headers in the core data being signed.  My CMS signedData structures could
specify a different MIME-type in the ContentHints, so the CMS software would
handle it as well.  Everybody wins!

    (BTW I am not sure what the correct MIME-type is for your
     case, I only selected the above MIME-types as an example.)

It looks like the contributers to the S/MIME standard had this in mind when they
conceived of the ContentHints attribute.  Still, do to the vaugeness of the
contentDescription, I would love to see any sample contentDescription text that
people are current using.

Alicia.

From: "Tony Capel" <[email-masked]>
To: "'Alicia da Conceicao'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: SignedAttribute for Mime-Type
Date: Fri, 13 Jan 2006 14:09:47 -0500
Importance: Normal
Sender: [email-masked]

Alicia (sorry for the delay in replying):

I think the contents hints might only need to specify MIME, or
[ASN.1+content encoding rules], ....  The hints would just 
identify the next protocol sublayer to process the content
(service access point). 

So the hints candidates might be:
1. MIME
2. ASN.1 + BER/DER
3. ASN.1 + PER  (?)
+ future and private use OIDs.

Both MIME and ASN.1 BER have the ability to identify content so I expect that
"future and private use" would only be for applications which are NOT using
these encodings (since they provide their own extension mechanisms).  This would
minimize the impact on CMS (we don't need OIDs matching MIME types for example).

On your second point about the clarity of the current text, I agree some added
words might be useful to cover the case where no content hints are provided (and
no a priori agreement exists).  The use of MIME within "e-mail applications"
might be considered as implying an a priori agreement - so I am not convinced
there is a serious problem.  It is tempting to point out that long and
indefinite BER encodings of ASN.1 will have the msb of the first octet set while
"common" 7-bit MIME will not.  However I am not sure that the BER short form is
never used, or that we can guarantee all 7-bit MIME has the msb clear.  Maybe
others would comment whether such text would help (and not break existing
implementations).

Russ has just reminded us of another issue raised by Bellovin and Rescorla
(multi-level signature) potentially impacting CMS, so perhaps this should be
discussed some more if that is the direction of the WG.

Tony

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Alicia da Conceicao
Sent: December 13, 2005 6:12 PM
To: Tony Capel
Cc: [email-masked]
Subject: Re: SignedAttribute for Mime-Type

Hi Tony:

Sorry that I did properly clarify all of my points in my first post. I can
appreciate why you prefer to use S/MIME headers with binary transfer encoding in
the data of CMS-SignedData structures.  To be honest, I planned to do the same
as well, especially since it is able to interop with countless existing S/MIME
applications and opensource libraries such as OpenSSL that have S/MIME support.
But as you mentioned, we both have different requirements for our CMS
applications, and for me I need to support detached signatures.

But Chris Bonatti's suggestion of specifing the MIME-type in the
contentDescription of a ContentHints signedAtrribute in a CMS structure would be
benifical to both of us, and everyone else as well.  It is a win-win for all!

For your CMS signedData structures with S/MIME headers and binary transfer
encoding, you could specify in the ContentHints attribute a specific a MIME-type
such as:

	Content-Type: multipart/mixed
or	Content-Type: application/pkcs7-mime

that would instruct the CMS software that it needs to parse the S/MIME text
headers in the core data being signed.  My CMS signedData structures could
specify a different MIME-type in the ContentHints, so the CMS software would
handle it as well.  Everybody wins!

    (BTW I am not sure what the correct MIME-type is for your
     case, I only selected the above MIME-types as an example.)

It looks like the contributers to the S/MIME standard had this in mind when they
conceived of the ContentHints attribute.  Still, do to the vaugeness of the
contentDescription, I would love to see any sample contentDescription text that
people are current using.

Alicia.

Date: Fri, 13 Jan 2006 11:52:10 -0500
To: <[email-masked]>, <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Multi-level CMS Signature evaluation Rules: Document Location
Sender: [email-masked]

This has lead to very little discussion.  I am pleased to propose the 
text for CMS if that is the direction that the S/MIME WG wants to 
pursue.  Please pick a direction.  We need to get moving.

Russ

At 05:09 PM 12/4/2005, Jim Schaad wrote:

>After having read the document by Bellovin and Rescorla, I agree with its
>conclusion that the working group needs to provide guidence on how
>evaluation of signatures needs to be done in the cases of 1) multiple
>signatures at a single layer and 2) multiple signature layers.
>
>I can think of four different documents that this can go into:
>
>1) CMS Base specification
>         Pro:
>                 - This is core functionality and it would be seen by all
>implementers of CMS
>                 - It would deal with ALL CMS objects
>
>         Con:
>                 - The document is not currently open for changes
>                 - Depending on how it is written, it might be more open to
>changes in the future
>
>
>2) New CMS document on multiple layers
>         Pro:
>                 - Does not change any current documents
>                 - Could be written as a BCP and thus have the ablity to make
>additional statements
>                 - Would deal with all CMS objects
>                 - Allows for discussion of different policies for
>evalutation
>
>         Con:
>                 - It's a new document and would need to be referenced
>everywhere
>
>
>3) S/MIME Message Specification
>         Pro:
>                 - This is the draft that S/MIME implementers use and this is
>currently the main place that needs help
>
>         Con:
>                 - It does not currently discuss any type of wrapping
>                 - It would not deal with AuthenticatedData wrapping
>
>
>4) ESS
>         Pro:
>                 - It already discusses the concepts of multiple layer
>wrapping
>                 - The document needs to be openned for dealing with
>ESSCertID
>
>         Con:
>                 - It usings Mime layers in the current wrapping text
>                 - It would not deal with AuthenticatedData wrapping
>
>
>
>My personal preference is to not tie the new evaluation logic to S/MIME but
>to CMS.
>
>Jim

Importance: Normal
Subject: Re: WG LAST CALL: draft-ietf-smime-cades-00.txt :flexibility of the ESSCertID field
From: [email-masked]
To: [email-masked]
Date: Tue, 10 Jan 2006 10:37:19 +0100
Sender: [email-masked]

To: [email-masked]
From: Blake Ramsdell <[email-masked]>
Subject: WG LAST CALL: draft-ietf-smime-cades-00.txt
Date: Mon, 9 Jan 2006 02:39:05 -0800
Sender: [email-masked]

This message initiates an SMIME Working Group Last Call on the document:

	Title		: CMS Advanced Electronic Signatures (CAdES)
	Author(s)	: J. Ross, et al.
	Filename	: draft-ietf-smime-cades-00.txt
	Pages		: 132
	Date		: 2005-12-2
	
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-cades-00.txt

The purpose of this WG Last Call is to ensure that the Working Group  
has achieved consensus that the document is suitable for publication  
as an Informational RFC.

Please review the document for both technical and editorial problems.  
Technical issues should be discussed on this list. Editorial issues  
may be sent to the document editor.

The Last Call period will end on Monday, January 16, 2006.

Upon completion of the last call, the WG chairs will take action  
based upon the consensus of the WG. Possible actions include:

    1) recommending to the IETF Security Area Directors
       that the document, after possible editorial or
       other minor changes, be considered by the IESG
       for publication as an Informational RFC
       (which generally involves an IETF-wide Last Call); or

    2) requiring that outstanding issues be adequately
       addressed prior to further action (including,
       possibly, another WG Last Call).

Remember that it is our responsibility as Working Group members to
ensure the quality of our documents and of the Internet Standards
process.  So, please read and comment!

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