Subject: Re: I-D ACTION:draft-ietf-smime-escertid-00.txt

From: "Denis Pinkas" <[email-masked]>
Date: Thu, 30 Mar 2006 15:58:45 +0100

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)
Date: Fri, 31 Mar 2006 02:21:35 +1200

"Denis Pinkas" <[email-masked]> writes:

>The advantage of the last proposal is backward compatibility with the
>existing structure. 

No it isn't, you've lost the 'OPTIONAL' on issuerSerial, making it non-
backwards-compatible.  If you want it to have the properties you claim it has,
you'd need:

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

Peter.

---

From: Russ Housley <[email-masked]>
Date: Thu, 30 Mar 2006 10:00:39 -0500

My preference is:

I would rather see the algorithm identifier before the hash value.

Since a new OID is going to be assigned, it is not really important 
to me whether the default is sha256 or sha1.  If implementors see a 
reason to go with sha1, I can live with it.

Russ

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 31 Mar 2006 03:19:37 +1200

Russ Housley <[email-masked]> writes:

>Since a new OID is going to be assigned, it is not really important to me
>whether the default is sha256 or sha1.  If implementors see a reason to go
>with sha1, I can live with it.

Looking at Denis' backwards-compatibility issue, if you do want backwards-
compatibility you'd have to default to SHA-1 and not SHA-2.  For SHA-1 you'd
then get:

which is identical to the original ESSCertID since the 'DEFAULT sha1'
vanishes.  Since something that doesn't know about the -Ex form isn't going to
be able to handle either the AlgorithmIdentifier or the use of a hash other
than SHA-1, it doesn't really matter where the AlgorithmIdentifier goes,
because it'll choke on the non-SHA1 hash anyway whether the
AlgorithmIdentifier precedes or follows it.

(Of course since you're using a different OID to identify it, it could
probably be argued that you can stick an MPEG-of-cat in there as well without
causing any problems.  However, the backwards-compatible format means that you
don't need to special-case the two versions but can just treat the old one as
one particular instance of the new one, which simplifies implementation).

Peter.

---

From: Dr Stephen Henson <[email-masked]>
Date: Thu, 30 Mar 2006 17:13:13 +0100

>     hashAlgorithm    AlgorithmIdentifier DEFAULT { sha-1 }

Well passing through those structures caught my attention.

Aren't they ambiguous and could possibly be rejected by ASN1 compilers
or parsers?

My reason being that the presence of DEFAULT/OPTIONAL fields is decided
by the tag and both IssuerSerial and AlgorithmIdentifier both have a
SEQUENCE tag.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 30 Mar 2006 18:49:22 +0200

> by the tag and both IssuerSerial and AlgorithmIdentifier both have a
Something like;

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

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

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 31 Mar 2006 13:35:21 +1200

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

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-smime-escertid-00.txt
Cc: [email-masked], [email-masked], [email-masked]
Date: Fri, 31 Mar 2006 13:35:21 +1200
Sender: [email-masked]

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

Date: Thu, 30 Mar 2006 18:49:22 +0200
From: Peter Sylvester <[email-masked]>
To: Dr Stephen Henson <[email-masked]>
CC: Peter Gutmann <[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.

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

Something like;

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

--------------ms010700040805080903050507--

Date: Thu, 30 Mar 2006 17:13:13 +0100
From: Dr Stephen Henson <[email-masked]>
To: Peter Gutmann <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-smime-escertid-00.txt
Sender: [email-masked]

Steve.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-smime-escertid-00.txt
Date: Fri, 31 Mar 2006 03:19:37 +1200
Sender: [email-masked]

Peter.

Date: Thu, 30 Mar 2006 10:00:39 -0500
To: "Denis Pinkas" <[email-masked]>, [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-smime-escertid-00.txt
Sender: [email-masked]

My preference is:

Russ

>     Please use a spell checker.

Date: Thu, 30 Mar 2006 16:31:30 +0100
From: "Denis Pinkas" <[email-masked]>
To: "pgut001" <[email-masked]>
Cc: "S-MIME / IETF" <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-smime-escertid-00.txt
Sender: [email-masked]

Peter,

You are perfectly right.

My mistake.

Denis

>    hashAlgorithm    AlgorithmIdentifier DEFAULT { sha-1 }

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-smime-escertid-00.txt
Date: Fri, 31 Mar 2006 02:21:35 +1200
Sender: [email-masked]

Peter.

Date: Thu, 30 Mar 2006 15:58:45 +0100
From: "Denis Pinkas" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-smime-escertid-00.txt
Sender: [email-masked]

   ESSCertID ::=  SEQUENCE {
        certHash                 Hash,

 

2 - Proposed rewritting:

Denis

>FILE /internet-drafts/draft-ietf-smime-escertid-00.txt

Reply-To: <[email-masked]>
From: "Turner, Sean P." <[email-masked]>
To: <[email-masked]>
Subject: Comments: draft-ietf-smime-escertid-00.txt
Date: Tue, 28 Mar 2006 14:40:48 -0500
Organization: IECA, Inc.
Sender: [email-masked]

Jim,

Minor nits:

In para 2, 2nd para:
Replace "... while SigningCertificateEx" with "...while SigningCertificate"
- I believe you meant to refer to the earlier attribute.

In para 2, 3rd para:
Should we say SigningCertificateEx is RECOMMENDED vice preferred?

In Para 3:
I think "policies" is missing from the beginning of the 3rd para after the
SigningCertificateEx ASN.1.

In Para 3:
In the last paragraph 3rd sentence and 2nd to last sentence and replace
SigningCertificate with SigningCertificateEx.

In Annex A:
ASN.1 for CertificateSigningEx is missing.

spt
 
-----Original Message-----
From: Blake Ramsdell [mailto:[email-masked]] 
Sent: Thursday, March 23, 2006 4:04 PM
To: [email-masked]
Cc: [email-masked]; Jim Schaad
Subject: draft-ietf-smime-esscertid-00.txt is approved

Jim Schaad's draft "Draft-ietf-smime-esscertid-00.txt" is approved for
inclusion in the S/MIME working group.

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

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-escertid-00.txt 
Date: Fri, 24 Mar 2006 18:50:01 -0500
Sender: [email-masked]

--NextPart

	

Send a message to:
	[email-masked].
In the body type:

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

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

Content-Type: text/plain

ENCODING mime

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

Content-Type: text/plain

--OtherAccess--

--NextPart--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-cms-rsa-kem-02.txt 
Date: Thu, 23 Mar 2006 18:50:01 -0500
Sender: [email-masked]

--NextPart

	Title		: Use of the RSA-KEM Key Transport Algorithm in CMS
	Author(s)	: B. Kaliski
	Filename	: draft-ietf-smime-cms-rsa-kem-02.txt
	Pages		: 23
	Date		: 2006-3-23
	
The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward) 
mechanism for transporting keying data to a recipient using the 
recipient's RSA public key. This document specifies the conventions 
for using the RSA-KEM Key Transport Algorithm with the Cryptographic 
Message Syntax (CMS). This version (-02) updates the ASN.1 syntax to 
align with the latest draft of ANS X9.44 and ISO/IEC 18033-2, and 
adds material on Camillia algorirthm.

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

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-rsa-kem-02.txt".

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-cms-rsa-kem-02.txt".

--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-rsa-kem-02.txt

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

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

--OtherAccess--

--NextPart--

Date: Tue, 21 Mar 2006 14:45:25 -0800
From: Blake Ramsdell <[email-masked]>
To: [email-masked]
Subject: CALL FOR DISSENT -- Identity Based Encryption in the S/MIME Working Group
Sender: [email-masked]

We had a discussion at the working group meeting about whether to bring 
the Identity Based Encryption (IBE) system into the S/MIME working 
group. As it stands right now, I have not heard any strong opposition to 
discussing this work and publishing any related drafts as RFCs of the 
working group.

If anyone is OPPOSED to doing this, make a noise now. I'll say that all 
dissenting opinion should be registered by Tuesday 3/28.

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

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: -02 of KEM draft on the IMC website
Cc: [email-masked]
Date: Mon, 13 Mar 2006 22:05:36 +1300
Sender: [email-masked]

Blake Ramsdell <[email-masked]> writes:

>James Randall has created a new -02 version of the KEM draft. It got kicked
>due to nits during the ID submission, but Paul Hoffman has made it available
>from the IMC website:

I assume you're requesting comments on the draft... unfortunately it's pretty
much impossible to assess because much of the content is contained via
references to non-obtainable ANSI and ISO standards documents.  Is there any
way that the missing material could be made available as IETF documents (or
just made available, period, I'm not really fussed over the exact form)?

Peter.

Cc: James Randall <[email-masked]>
From: Blake Ramsdell <[email-masked]>
Subject: -02 of KEM draft on the IMC website
Date: Fri, 10 Mar 2006 14:25:25 -0800
To: [email-masked]
Sender: [email-masked]

James Randall has created a new -02 version of the KEM draft. It got  
kicked due to nits during the ID submission, but Paul Hoffman has  
made it available from the IMC website:

http://www.imc.org/ietf-smime/draft-ietf-smime-cms-rsa-kem-02.txt

There will be a status update at the WG meeting in Dallas about this.  
The bottom line is that X9.44 is still working on it, and this is an  
update that mirrors the current X9.44 status.

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

Date: Fri, 10 Mar 2006 17:43:10 +0100
From: "Denis Pinkas" <[email-masked]>
To: "S-MIME / IETF" <[email-masked]>
Subject: Algorithm agility for ESSCertID
Sender: [email-masked]

ESSCertID mandates the use of SHA-1. An attribute with the same properties is needed 
to allow the use of alternative hash functions.

While being in the process to issue an update of RFC 3126 (draft-ietf-smime-cades),
it appears that the currently defined signed attribute could be simplified. 

In RFC 3126, an object identifier identifies the other-signing-certificate attribute 
which is a correct, but is a rather complicated structure to specify another 
hash algorithm.

>From discussions on the PKIX mailing list, it appears that the structure of 
otherSigCert could be simplified.

Since the other-signing-certificate attribute was defined for the provision of 
algorithm agility and since no one has mentioned that it has already been used, 
it is proposed to deprecate its use in the revised RFC and to recommend 
the use of a new attribute that would be called general-Signing-certificate.

Below is a proposal for its definition: 

====================================================================

The following object identifier identifies the general-signing-certificate
attribute:

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

The general-signing-certificate attribute value has the ASN.1 syntax:

GeneralSigningCertificate ::=  SEQUENCE {
    certs        SEQUENCE OF GeneralCertID,
    policies     SEQUENCE OF PolicyInformation OPTIONAL
                 -- NOT USED IN THE PRESENT DOCUMENT
    }

GeneralCertID ::= SEQUENCE {
    certHash         OCTET STRING,
    issuerSerial     IssuerSerial,
    hashAlgorithm    AlgorithmIdentifier DEFAULT { sha-1 } }

====================================================================

For that purpose there would be the need to obtain an OID for that 
attribute.

Denis

====================================================================

For information the current structure is as follows:

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

The other-signing-certificate attribute value has the ASN.1 syntax 
OtherSigningCertificate:

OtherSigningCertificate ::=  SEQUENCE {
    certs        SEQUENCE OF OtherCertID,
    policies     SEQUENCE OF PolicyInformation OPTIONAL
                 -- NOT USED IN THE PRESENT DOCUMENT }

OtherCertID ::= SEQUENCE {
    otherCertHash            OtherHash,
    issuerSerial             IssuerSerial OPTIONAL }

OtherHash ::= CHOICE {
    sha1Hash OtherHashValue,  -- This contains a SHA-1 hash
    otherHash OtherHashAlgAndValue}

OtherHashValue ::= OCTET STRING

OtherHashAlgAndValue ::= SEQUENCE {
    hashAlgorithm     AlgorithmIdentifier,
    hashValue         OtherHashValue }

======================================================================

Cc: [email-masked]
From: Blake Ramsdell <[email-masked]>
Subject: Re: About countersignature in RFC 4134
Date: Fri, 10 Mar 2006 01:08:30 -0800
To: Russ Housley <[email-masked]>, =?ISO-8859-1?Q?Jo=EBl_Repiquet?= <[email-masked]>
Sender: [email-masked]

On Jan 26, 2006, at 1:17 PM, Russ Housley wrote:
> Has anyone confirmed this issue.  If it is confirmed, the WG should  
> submit an errata to the RFC Editor.

It looks like there is a discrepancy here -- the text says:

(Countersignature by Diane)

and the signature is indeed the serial number for Alice.

Joël, in your testing did the countersignature verify with Alice's  
certificate?

I'm trying to figure out if the error here is the text  
"(Countersignature by Diane)"  or the serial number of the  
certificate needs to be changed to Diane's. I'm presuming that it's  
just the text.

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

To: [email-masked], Mark Schertler <[email-masked]>
From: Blake Ramsdell <[email-masked]>
Subject: Voltage IBE draft
Date: Thu, 9 Mar 2006 23:39:06 -0800
Sender: [email-masked]

Mark Schertler has let me know that there is a draft regarding the  
integration of the Voltage IBE technology with CMS. The draft is an  
individual submission:

http://www.ietf.org/internet-drafts/draft-martin-bfibecms-00.txt

This basically defines a new OtherRecipientInfo to indicate an IBE  
recipient.

Any comments or concerns about this? I think at this point is  
basically going to be "picking at the ASN.1 scab" type commentary.

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

Cc: <[email-masked]>, <[email-masked]>
From: Blake Ramsdell <[email-masked]>
Subject: Re: Multi-level CMS Signature evaluation Rules: Document Location
Date: Thu, 2 Mar 2006 11:44:09 -0800
To: Russ Housley <[email-masked]>
Sender: [email-masked]

On Mar 2, 2006, at 11:02 AM, Russ Housley wrote:
> I will propose text.  However, I am not in favor of opening CMS.  I  
> think we can generate a one or two paragraph update.

OK, I was overly specific about the mechanism. I think the sprit here  
is that this is going to be a CMS-level change so that any consumer  
of CMS will benefit from it. The actual form of that change is indeed  
whatever makes the "most sense".

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

Date: Thu, 02 Mar 2006 14:02:39 -0500
To: Blake Ramsdell <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Multi-level CMS Signature evaluation Rules: Document Location
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Blake:

I will propose text.  However, I am not in favor of opening CMS.  I 
think we can generate a one or two paragraph update.

Russ

At 04:44 AM 3/2/2006, Blake Ramsdell wrote:
>On Jan 13, 2006, at 8:52 AM, Russ Housley wrote:
>>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.
>
>OK, well I guess I'm picking it. Russ, please propose some text for
>this in CMS, per Jim's option 1 below. The path here seems to be
>reopening CMS for the purpose of adding this clarification.
>
>Multiple signatures will be on the agenda for IETF 65.
>
>>At 05:09 PM 12/4/2005, Jim Schaad wrote:
>>>
>>>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
>
>Blake
>--
>Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com
>

Cc: <[email-masked]>, <[email-masked]>
From: Blake Ramsdell <[email-masked]>
Subject: Re: Multi-level CMS Signature evaluation Rules: Document Location
Date: Thu, 2 Mar 2006 01:44:35 -0800
To: Russ Housley <[email-masked]>
Sender: [email-masked]

On Jan 13, 2006, at 8:52 AM, Russ Housley wrote:
> 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.

OK, well I guess I'm picking it. Russ, please propose some text for  
this in CMS, per Jim's option 1 below. The path here seems to be  
reopening CMS for the purpose of adding this clarification.

Multiple signatures will be on the agenda for IETF 65.

> At 05:09 PM 12/4/2005, Jim Schaad wrote:
>>
>> 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

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