Subject: Get the medication you need delivered to your door in 24 hours.

From: Oswald Arias <[email-masked]>
Date: Wed, 30 Nov 2005 22:41:58 -0500

Strong enough for a men, but made for a women
http://incubation.tissots.net/ph/lib/

ENVY, n. Emulation adapted to the meanest capacity.     
RUM, n. Generically, fiery liquors that produce madness in total abstainers.  
The worst prison would be a closed heart.     
You think that's noise - you ain't heard nuttin' yet!   
Spring makes everything look filthy.        
By constant self-discipline and self-control you can develop greatness of character  

Date: Fri, 18 Nov 2005 11:48:25 -0500
To: "Gregory S. Chudov" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: WG LAST CALL: draft-ietf-smime-gost-05.txt
Cc: <[email-masked]>, <[email-masked]>, "Blake Ramsdell" <[email-masked]>, <[email-masked]>, "Sean Turner" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 3:45 PM +0300 11/18/05, Gregory S. Chudov wrote:
>Greetings.
>
>We are ready for last call on gost-cppk too.
>

I sent a message

From: "Gregory S. Chudov" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: "Blake Ramsdell" <[email-masked]>, <[email-masked]>, "Sean Turner" <[email-masked]>, <[email-masked]>
Subject: Re: WG LAST CALL: draft-ietf-smime-gost-05.txt
Date: Fri, 18 Nov 2005 15:45:26 +0300
Sender: [email-masked]

Greetings.

We are ready for last call on gost-cppk too.

----- Original Message ----- 
From: "Blake Ramsdell" <[email-masked]>
To: <[email-masked]>; "Sean Turner" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, November 18, 2005 2:04 AM
Subject: Re: WG LAST CALL: draft-ietf-smime-gost-05.txt

> 
> On Nov 17, 2005, at 2:13 PM, Turner, Sean P. wrote:
>> PS there is a companion GOST documents in PKIX
>> (http://ietf.org/internet-drafts/draft-ietf-pkix-gost-cppk-03.txt)  
>> and in
>> RFC editor's queue
>> (ftp://ftp.isi.edu/internet-drafts/draft-popov-cryptopro- 
>> cpalgs-04.txt).
> 
> Are we going to run into another CMC / symkeydist situation here?  
> That is, is gost-cppk going to get stuck for any reason in PKIX? I  
> note that the last draft revision is 9/9/05 and I did not see  
> anything to indicate that there is active discussion about this draft  
> on the PKIX list.
> 
> Just firing a warning shot that cppk is a normative reference that  
> will need to progress through PKIX before gost-05 can complete.  
> Authors -- can you give a quick status update about this?
> 
> cpalgs looks pretty frictionless -- no missing normative references,  
> and in the editor's queue.
> 
> Blake
> --
> Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com
> 
>

Cc: <[email-masked]>
From: Blake Ramsdell <[email-masked]>
Subject: Re: WG LAST CALL: draft-ietf-smime-gost-05.txt
Date: Thu, 17 Nov 2005 15:04:08 -0800
To: [email-masked], Sean Turner <[email-masked]>, [email-masked]
X-ok-sendmail.com: Yes
Sender: [email-masked]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[email-masked]?body=unsubscribe>

On Nov 17, 2005, at 2:13 PM, Turner, Sean P. wrote:
> PS there is a companion GOST documents in PKIX
> (http://ietf.org/internet-drafts/draft-ietf-pkix-gost-cppk-03.txt)  
> and in
> RFC editor's queue
> (ftp://ftp.isi.edu/internet-drafts/draft-popov-cryptopro- 
> cpalgs-04.txt).

Are we going to run into another CMC / symkeydist situation here?  
That is, is gost-cppk going to get stuck for any reason in PKIX? I  
note that the last draft revision is 9/9/05 and I did not see  
anything to indicate that there is active discussion about this draft  
on the PKIX list.

Just firing a warning shot that cppk is a normative reference that  
will need to progress through PKIX before gost-05 can complete.  
Authors -- can you give a quick status update about this?

cpalgs looks pretty frictionless -- no missing normative references,  
and in the editor's queue.

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

Reply-To: <[email-masked]>
From: "Turner, Sean P." <[email-masked]>
To: <[email-masked]>
Subject: WG LAST CALL: draft-ietf-smime-gost-05.txt
Date: Thu, 17 Nov 2005 17:13:22 -0500
Organization: IECA, Inc.
Sender: [email-masked]

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

	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-05.txt
	Pages		: 25
	Date		: 2005-9-13

A URL for this Internet-Draft is:
http://ietf.org/internet-drafts/draft-ietf-smime-gost-05.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 a
Proposed Standard.

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 Friday, December 2, 2005.

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 a Standard Track 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!

Spt

PS there is a companion GOST documents in PKIX
(http://ietf.org/internet-drafts/draft-ietf-pkix-gost-cppk-03.txt) and in
RFC editor's queue
(ftp://ftp.isi.edu/internet-drafts/draft-popov-cryptopro-cpalgs-04.txt).

Date: Wed, 16 Nov 2005 11:40:17 -0500
To: [email-masked] (Peter Gutmann), [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Naming keys in EncryptedData
Sender: [email-masked]

Peter:

It is an OCTET STRING.  It identifies the content-encryption key that 
was previously distributed to the sender and one or more recipients.

Russ

At 11:01 PM 11/15/2005, Peter Gutmann wrote:
>Russ Housley <[email-masked]> writes:
>
> >X9.73 defines an additional CMS content type.  It is:
> >
> >   NamedKeyEncryptedData ::= SEQUENCE {
> >       version Version,
> >       keyName KeyName OPTIONAL,
> >       encryptedContentInfo EncryptedContentInfo }
> >
> >Does anyone see a reason to fold the keyName into EncryptedData?
>
>What is the KeyName, and what is one suppossed to do with it?
>
>Peter.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Naming keys in EncryptedData
Date: Wed, 16 Nov 2005 17:01:32 +1300
Sender: [email-masked]

Russ Housley <[email-masked]> writes:

>X9.73 defines an additional CMS content type.  It is:
>
>   NamedKeyEncryptedData ::= SEQUENCE {
>       version Version,
>       keyName KeyName OPTIONAL,
>       encryptedContentInfo EncryptedContentInfo }
>
>Does anyone see a reason to fold the keyName into EncryptedData?

What is the KeyName, and what is one suppossed to do with it?

Peter.

Date: Tue, 15 Nov 2005 19:54:38 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Naming keys in EncryptedData
Sender: [email-masked]

X9.73 defines an additional CMS content type.  It is:

    NamedKeyEncryptedData ::= SEQUENCE {
       version Version,
       keyName KeyName OPTIONAL,
       encryptedContentInfo EncryptedContentInfo }

Does anyone see a reason to fold the keyName into EncryptedData?

The alternative is to assign an attribute that can be used to 
identify the key that is needed to decrypt the content.  That 
alternative would look like this:

    id-aa-contentDecryptKeyID OBJECT IDENTIFIER ::= { <TBD> }

    ContentDecryptKeyID::= OCTET STRING

I anticipate an update to RFC 3852 to address the ambiguity in 
handling of multiple SignerInfo, so it would not be difficult to add 
either the keyName to EncryptedData (with the appropriate version 
updates) or the ContentDecryptKeyID attribute.

Russ

Date: Thu, 10 Nov 2005 14:32:55 -0800
From: Blake Ramsdell <[email-masked]>
To: [email-masked]
Subject: -examples change for SHA-256 also
Sender: [email-masked]

I just realized that the SHA-256 transition will have an impact on the 
examples document also (if we intend to maintain it).

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

Date: Thu, 10 Nov 2005 14:20:55 +0100
From: Peter Sylvester <[email-masked]>
To: Russ Housley <[email-masked]>
CC: [email-masked]
Subject: Re: flexibility of the ESSCertID field
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms030908050201020503050003
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Russ Housley wrote:

> Peter:
>
> Not really. To change the syntax, a new OID for the attribute will be 
> assigned, so there will be no decode errors.

Ok, for any new attribute you are free to choose whatever you want.
Where a new attribute is a good choice is another question.

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

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

--------------ms030908050201020503050003--

Date: Wed, 09 Nov 2005 16:35:37 -0500
To: Peter Sylvester <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: flexibility of the ESSCertID field
Cc: [email-masked]
Sender: [email-masked]

Peter:

Not really.  To change the syntax, a new OID for the attribute will 
be assigned, so there will be no decode errors.

Russ

At 01:33 PM 11/9/2005, Peter Sylvester wrote:
>>Thanks for correcting my syntax.  I should have used 
>>"id-sha1-identifier" as the default, which is already defined for 
>>RSA-PSS and RSA-OAEP.
>
>Depends on the module with the definition.
>
>>
>>I prefer identifiers before the associated value, but that is just style.
>>
>No, we are talking about an extension to an existing syntax.
>
>Some decoders ignore unknown elements after the end of normal elements.
>I don't remember whether this was an asn1 feature of BER.
>
>Adding new fields into an existing syntax should be done at the end IMO.

Date: Wed, 09 Nov 2005 19:33:40 +0100
From: Peter Sylvester <[email-masked]>
To: Russ Housley <[email-masked]>
CC: [email-masked], "'Denis Pinkas'" <[email-masked]>, [email-masked]
Subject: Re: flexibility of the ESSCertID field
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

Russ Housley wrote:

>
> Peter:
>
> Thanks for correcting my syntax.  I should have used 
> "id-sha1-identifier" as the default, which is already defined for 
> RSA-PSS and RSA-OAEP.

Depends on the module with the definition.

>
> I prefer identifiers before the associated value, but that is just style.
>
>
No, we are talking about an extension to an existing syntax.

Some decoders ignore unknown elements after the end of normal elements.
I don't remember whether this was an asn1 feature of BER.

Adding new fields into an existing syntax should be done at the end IMO.

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

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

--------------ms010201050008050402060307--

Date: Wed, 09 Nov 2005 12:01:04 -0500
To: Peter Sylvester <[email-masked]>, [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: flexibility of the ESSCertID field
Cc: "'Denis Pinkas'" <[email-masked]>, [email-masked]
Sender: [email-masked]

Peter:

Thanks for correcting my syntax.  I should have used 
"id-sha1-identifier" as the default, which is already defined for 
RSA-PSS and RSA-OAEP.

I prefer identifiers before the associated value, but that is just style.

Russ

>>    ESSCertIDv2 ::=  SEQUENCE {
>>         hashAlgorithm AlgorithmIdentifier DEFAULT id-sha1,
>>         certHash Hash,
>>         issuerSerial  IssuerSerial OPTIONAL
>>    }
>>
>>I prefer this approach because it is always fewer octets, and it generates
>>the same ESSCertID output when SHA-1 is used.
>>
>
>Adding new field at the end may be better for ASN.1 parsing
>
>ESSCertIDv2 ::=  SEQUENCE {
>         certHash Hash,
>         issuerSerial  IssuerSerial OPTIONAL,         hashAlgorithm 
> [0] AlgorithmIdentifier DEFAULT { algorithm id-sha1 }
>}

Date: Wed, 09 Nov 2005 16:38:57 +0100
From: Peter Sylvester <[email-masked]>
To: [email-masked]
CC: "'Russ Housley'" <[email-masked]>, "'Denis Pinkas'" <[email-masked]>, [email-masked]
Subject: Re: flexibility of the ESSCertID field
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

>
>    ESSCertIDv2 ::=  SEQUENCE {
>         hashAlgorithm AlgorithmIdentifier DEFAULT id-sha1,
>         certHash Hash,
>         issuerSerial  IssuerSerial OPTIONAL
>    }
>
>I prefer this approach because it is always fewer octets, and it generates
>the same ESSCertID output when SHA-1 is used.
>  
>

Adding new field at the end may be better for ASN.1 parsing

ESSCertIDv2 ::=  SEQUENCE {
         certHash Hash,
         issuerSerial  IssuerSerial OPTIONAL, 
         hashAlgorithm [0] AlgorithmIdentifier DEFAULT { algorithm id-sha1 }   
}

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

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

--------------ms090405060202070405000208--

Reply-To: <[email-masked]>
From: "Turner, Sean P." <[email-masked]>
To: "'Russ Housley'" <[email-masked]>, "'Denis Pinkas'" <[email-masked]>, <[email-masked]>
Subject: RE: flexibility of the ESSCertID field
Date: Tue, 8 Nov 2005 16:04:41 -0500
Organization: IECA, Inc.
Sender: [email-masked]

I like the "simpler" approach.

spt 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Russ Housley
Sent: Tuesday, November 08, 2005 1:02 PM
To: Denis Pinkas; [email-masked]
Subject: Re: flexibility of the ESSCertID field

Denis:

The syntax from RFC 2634 is:

    ESSCertID ::=  SEQUENCE {
         certHash                 Hash,
         issuerSerial             IssuerSerial OPTIONAL
    }

    Hash ::= OCTET STRING -- SHA1 hash of entire certificate

    IssuerSerial ::= SEQUENCE {
         issuer                   GeneralNames,
         serialNumber             CertificateSerialNumber
    }

The "improved" syntax that you reference from RFC 3126 is:

    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
    }

This seems more complicated than necessary to me.

Why not use:

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

I prefer this approach because it is always fewer octets, and it generates
the same ESSCertID output when SHA-1 is used.

Russ

At 08:43 AM 11/8/2005, Denis Pinkas wrote:

> >Jim Schaad presented a concern about the algorithm flexibility of the 
> >ESSCertID field. Right now this field is limited to the use of the 
> >SHA-1 algorithm, and Jim proposed the addition of an 
> >AlgorithmIdentifier to indicate the digest algorithm used to prepare the
digest.
>
>OtherSigningCertificate, as defined in RFC 3126, could be used for that 
>purpose
>
>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 }
>
>RFC 3126 was anticipating the need to use other algorithms.
>
>Denis
>

Date: Tue, 08 Nov 2005 13:02:02 -0500
To: "Denis Pinkas" <[email-masked]>, "[email-masked]" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: flexibility of the ESSCertID field
Sender: [email-masked]

Denis:

The syntax from RFC 2634 is:

    ESSCertID ::=  SEQUENCE {
         certHash                 Hash,
         issuerSerial             IssuerSerial OPTIONAL
    }

    Hash ::= OCTET STRING -- SHA1 hash of entire certificate

    IssuerSerial ::= SEQUENCE {
         issuer                   GeneralNames,
         serialNumber             CertificateSerialNumber
    }

The "improved" syntax that you reference from RFC 3126 is:

    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
    }

This seems more complicated than necessary to me.

Why not use:

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

I prefer this approach because it is always fewer octets, and it 
generates the same ESSCertID output when SHA-1 is used.

Russ

At 08:43 AM 11/8/2005, Denis Pinkas wrote:

> >Jim Schaad presented a concern about the algorithm flexibility of the
> >ESSCertID field. Right now this field is limited to the use of the SHA-1
> >algorithm, and Jim proposed the addition of an AlgorithmIdentifier to
> >indicate the digest algorithm used to prepare the digest.
>
>OtherSigningCertificate, as defined in RFC 3126, could be used for 
>that purpose
>
>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 }
>
>RFC 3126 was anticipating the need to use other algorithms.
>
>Denis
>

Date: Tue, 8 Nov 2005 14:43:50 +0100
From: "Denis Pinkas" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: flexibility of the ESSCertID field
Sender: [email-masked]

>Jim Schaad presented a concern about the algorithm flexibility of the 
>ESSCertID field. Right now this field is limited to the use of the SHA-1 
>algorithm, and Jim proposed the addition of an AlgorithmIdentifier to 
>indicate the digest algorithm used to prepare the digest. 

OtherSigningCertificate, as defined in RFC 3126, could be used for that purpose 

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 }

RFC 3126 was anticipating the need to use other algorithms.

Denis 

Date: Tue, 08 Nov 2005 03:21:42 -0800
From: Blake Ramsdell <[email-masked]>
To: Russ Housley <[email-masked]>, [email-masked], [email-masked]
Subject: Re: WG and BoF Session Summary
Sender: [email-masked]

Russ Housley wrote:
> We want a fairly short (no more than one-half page of text) summary that 
> focuses on important decisions made during the meeting, and what is 
> expected to happen in the few months. The summary would be sent to the 
> WG or BoF mail list as well as the ADs ([email-masked] and 
> [email-masked]).

Working group status. There are four drafts that are currently in the 
working group that have not become RFCs yet. symkeydist is still in the 
RFC editor's queue with a missing reference, waiting for the CMC draft 
to be released from PKIX. certcapa is in the RFC editor's queue and 
requires no further action. gost has a new release that was made 
recently, and is going to immediately progress to working group last 
call. KEM is waiting on work to complete in X9.44.

The open milestones for the working group fall into two categories. One 
category is progressing the CMS and S/MIME RFCs to draft standard 
status. The first step towards this is the completion of an 
interoperability report, which is waiting for interoperability work to 
be published from the PKIX working group. The other category surrounds 
the KEM algorithm draft, which is waiting for the X9.44 work to be 
completed (as noted above).

John Biccum from Microsoft announced that they will be S/MIME digitally 
signing security bulletins starting in February 2006. The root 
certificate is the software signing authority certificate that has been 
distributed with Windows essentially forever, and will be made available 
from Microsoft for non-Windows clients.

Mark Schertler from Voltage Security discussed their Identity Based 
Encryption (IBE) public key system, and proposed an integration with CMS 
using the OtherRecipientInfo field. The underlying algorithms are being 
discussed in the IEEE 1363.3 working group, and I expect that Voltage 
will be releasing individual internet-drafts in the short term, and we 
can further discuss the relevance to the S/MIME working group.

Russ Housley gave an overview of the algorithm transition we are 
undertaking, and the "walk, don't run" attitude that we have towards 
moving away from SHA-1 as a digest algorithm.

Jim Schaad presented a concern about the algorithm flexibility of the 
ESSCertID field. Right now this field is limited to the use of the SHA-1 
algorithm, and Jim proposed the addition of an AlgorithmIdentifier to 
indicate the digest algorithm used to prepare the digest. Jim also 
proposed an idea for handling signature algorithm transitions in CMS. 
Basically, in each SignerInfo the signer would indicate the other 
SignerInfos that were added by the signer. Jim's theory was that this 
might help mitigate a downgrade attack where the signer applies both a 
SHA-256 signature and a SHA-1 signature, and the attacker removes the 
SHA-256 signature to force the receiver to use the SHA-1 signature.

Blake Ramsdell discussed a strawman for SHA-256 support in S/MIME. The 
draft as it stands right now needs more work to discuss both the reasons 
for the transition to SHA-256, as well as the considerations for 
handling the transition and processing multiple signature values, as 
well as using existing capabilities constructs for expressing support 
for SHA-256.

ACTION ITEMS:

* gost to WG last call

* Continued pressure to get CMC released to get symkeydist moving again

* Continue discussion about SHA-256 transition

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