Subject: Account liquidation service report

From: MensHealth.com <[email-masked]>
Date: Tue, 31 Mar 2009 14:21:15 -0700 (PDT)

To your health,

David Zinczenko

Editor-in-Chief

Unsubscribe | Your Privacy Rights

2008 Rodale Inc., all rights reserved.
Customer Service Dept., 33 East Minor Street,
Emmaus, PA 18098

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2UDqcds075347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Mar 2009 06:52:38 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2UDqcPG075346; Mon, 30 Mar 2009 06:52:38 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp105.biz.mail.re2.yahoo.com (smtp105.biz.mail.re2.yahoo.com [206.190.52.174]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n2UDqRTH075331 for ; Mon, 30 Mar 2009 06:52:37 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 82336 invoked from network); 30 Mar 2009 13:52:27 -0000
Received: from unknown (HELO sean-turners-macbook.local) ([email-masked] with plain) by smtp105.biz.mail.re2.yahoo.com with SMTP; 30 Mar 2009 13:52:26 -0000
X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To-
X-YMail-OSG: 81G74uEVM1nI1_bp3wZUqX3ltC.BM0bzpuExK97plPoj5A9qCYvc.P8cCyyreuFsPNAA.qVg5YkKG7Ii7jcYACpEiF2multn50mVTRm7CKdv82sjEjlw5tsfSS2WeD7Vdxfji6UAgbpfzfQfE_Ph3CQb0__x9TY2J.hIVYtCJyDtZ2kQhjX40apXTuuu
X-Yahoo-Newman-Property: ymail-3
Message-ID: <[email-masked]>
Date: Mon, 30 Mar 2009 09:52:26 -0400
From: Sean Turner
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
To: [email-masked]
Subject: Re: CMS Questionnaire
References: <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

I'd like to thank all that responded to the questionnaire. I have
information for 9 implementations that will be included in the CMS
Interoperability Report that I'm going to give Tim and Russ. I believe
the information contained therein supports moving CMS to draft standard.

spt

Sean Turner wrote:
> Russ and Tim have challenged me to try to advance CMS to Draft Standard
> using the process in BCP 97 to deal with the dependencies that have not
> yet advanced (or aren't advancing). To that end, I've drawn up the
> following questionnaire that I'd like implementers to complete and
> return to me. What we're shooting for is to find two implementations
> that generate messages for each feature, and two implementations that
> process each feature. We don't think it should matter if the same two
> implementations are used in both stages.
>
> Thanks in advance,
>
> spt

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2QN2hQR012596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Mar 2009 16:02:44 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2QN2h4b012594; Thu, 26 Mar 2009 16:02:43 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2QN2gBi012580 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL); Thu, 26 Mar 2009 16:02:42 -0700 (MST) (envelope-from [email-masked])
X-IronPort-AV: E=Sophos;i="4.38,428,1233532800"; d="scan'208";a="274948011"
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 26 Mar 2009 23:02:41 +0000
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2QN2cGS005876; Thu, 26 Mar 2009 16:02:38 -0700
Received: from [10.32.241.22] ([10.32.241.22]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n2QN2b8G017592; Thu, 26 Mar 2009 23:02:38 GMT
Cc: Carl Wallace , [email-masked], [email-masked]
Message-Id: <[email-masked]>
From: Jan Vilhuber
To: Sean Turner
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: Nitpicking between CMS and CMC
Date: Thu, 26 Mar 2009 17:02:36 -0600
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
X-Mailer: Apple Mail (2.930.3)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4532; t=1238108558; x=1238972558; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[email-masked]; z=From:=20Jan=20Vilhuber=20 |Subject:=20Re=3A=20Nitpicking=20between=20CMS=20and=20CMC |Sender:=20; bh=uNDYgqacPtAymImotLGgPZD3KExPcr0ZYiVNSxAOXmM=; b=esqYo7CmcCvNJHpPFXzfJ+KOo4vrhN7XtgtOy1pZDLJMzulZTHmM0YhM+1 MOWdhxHyYyTGc0lkCH0jjDtPm908TB9OnBwwnsv81jdBws0hJkA0EbAR023I 8FJY2F0UCNufjm71eucoz/jPO9J8iXWP2JRuSV1Wumxni3lY+TY8E=;
Authentication-Results: sj-dkim-1; header.From=[email-masked]; dkim=pass ( sig from cisco.com/sjdkim1004 verified; );
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Sounds good then.

Thanks!
jan

On Mar 26, 2009, at 4:59 PM, Sean Turner wrote:

> I agree an errata is better/quicker.
>
> spt
>
> Carl Wallace wrote:
>> This can be addressed with an errata report:
>> http://www.rfc-editor.org/errata.php. -----Original Message-----
>> From: Jan Vilhuber [mailto:[email-masked]] Sent: Thursday,
>> March 26, 2009 3:43 PM
>> To: Carl Wallace
>> Cc: Sean Turner; [email-masked]
>> Subject: Re: Nitpicking between CMS and CMC
>> Hi Carl!
>> Works for me. Is this something that needs fixed in a new CMS
>> revision? How does this work?
>> jan
>> On Mar 26, 2009, at 4:12 PM, Carl Wallace wrote:
>>> The "uniquely identifies" clause really only applies to the
>>> issDN/serialNum bit. Moving it gives:
>>>
>>> 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
>>> that uniquely identifies the certificate containing the public
>>> key or by
>>> a subject key identifier.
>>>
>>> -----Original Message-----
>>> From: [email-masked]
>> [mailto:[email-masked]
>>> ]
>>> On Behalf Of Sean Turner
>>> Sent: Thursday, March 26, 2009 2:58 PM
>>> To: Jan Vilhuber
>>> Cc: [email-masked]
>>> Subject: Re: Nitpicking between CMS and CMC
>>>
>>>
>>> I think mandating a self-signed certificates is not the way to go.
>>>
>>> spt
>>>
>>> Jan Vilhuber wrote:
>>>> I noticed the following discrepancy between CMC and CMS, which
>>>> could
>>>> very accurately be described as nitpicking (but them isn't that
>>>> what
>>>> standards are about?):
>>>>
>>>> CMS RFC, section 5. Signed-data Content Type:
>>>>
>>>>
>>>> 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.
>>>>
>>>>
>>>>
>>>> Specifically: "... or by a subject key identifier that uniquely
>>> identifies the certificate containing the public key".
>>>> CMC RFC, Section 3.2. Full PKI Request
>>>>
>>>>
>>>> If SignedData is used, the signature can be generated using
>>>> either the
>>>> private key material of an embedded signature certification request
>>>> (i.e., included in the TaggedRequest tcr or crm fields) or a
>>> previously
>>>> certified signature key. If the private key of a signature
>>> certification
>>>> request is used, then:
>>>>
>>>> a. The certification request containing the corresponding public
>>>> key
>>>> MUST include a Subject Key Identifier extension
>>>>
>>>> b. The subjectKeyIdentifier form of the signerIdentifier in
>>>> SignerInfo MUST be used.
>>>>
>>>> c. The value of the subjectKeyIdentifier form of SignerInfo MUST
>>>> be
>>>> the Subject Key Identifier specified in the corresponding
>>>> certification request. (The subjectKeyIdentifier form of
>>>> SignerInfo is used here because no certificates have yet been
>>>> issued for the signing key.) If the request key is used for
>>>> signing, there MUST be only one SignerInfo in the SignedData.
>>>>
>>>>
>>>>
>>>> So CMC allows the SignedData to use the SubjectKeyIdentifier, but
>>> pointing to the certificate request it is encapsulating. While I
>>> don't
>>> mind this usage, the CMS rfc specifically mentions that the
>>> SubjectKeyIdentifier "uniquely identifies the certificate
>>> containing the
>>> public key".
>>>> So if we want to be nitpicky about it, then the CMC rfc is asking
>>>> for
>>> something which is illegal as per the CMS RFC. This can be
>>> cleaned up in
>>> either place, i.e. either mandating in CMC that a self-signed
>>> certificate be included when no previous certificate has been issued
>>> (thus making it conform to CMS), or modify CMS to allow a more
>>> liberal
>>> application of where to find the public key in question.
>>>> Thoughts?
>>>>
>>>> jan
>>>>
>>>>
>>>>

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2QMx4Vm012282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Mar 2009 15:59:04 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2QMx4Qv012280; Thu, 26 Mar 2009 15:59:04 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp108.biz.mail.mud.yahoo.com (smtp108.biz.mail.mud.yahoo.com [68.142.201.177]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n2QMx2pY012266 for ; Thu, 26 Mar 2009 15:59:03 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 76534 invoked from network); 26 Mar 2009 22:59:02 -0000
Received: from unknown (HELO dhcp-179d.meeting.ietf.org) ([email-masked] with plain) by smtp108.biz.mail.mud.yahoo.com with SMTP; 26 Mar 2009 22:59:02 -0000
X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To-
X-YMail-OSG: Vp9q.yUVM1k0QPm4AfA7pWGPBMuZEFSVIeul7gQxObkCfteoDZbpTtYwnpmYCglFor4DOB1uDmF3zs2byv_mBwgKAWKEfJmQz0dBz_52yqc1D6P7txK558C2okjXbWHuqIB2YnVyP57OpFxhnVsj3Tq6.V9VQNKw98cDkmpxmQgjokrJp5q_CrA752Xk1PJhTXB7UjAIv9dfGI4K3h1Hc0luig--
X-Yahoo-Newman-Property: ymail-3
Message-ID: <[email-masked]>
Date: Thu, 26 Mar 2009 15:59:00 -0700
From: Sean Turner
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
To: Carl Wallace
CC: Jan Vilhuber , [email-masked], [email-masked]
Subject: Re: Nitpicking between CMS and CMC
References: <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

I agree an errata is better/quicker.

spt

Carl Wallace wrote:
> This can be addressed with an errata report:
> http://www.rfc-editor.org/errata.php.
>
> -----Original Message-----
> From: Jan Vilhuber [mailto:[email-masked]]
> Sent: Thursday, March 26, 2009 3:43 PM
> To: Carl Wallace
> Cc: Sean Turner; [email-masked]
> Subject: Re: Nitpicking between CMS and CMC
>
> Hi Carl!
>
> Works for me. Is this something that needs fixed in a new CMS
> revision? How does this work?
>
> jan
>
> On Mar 26, 2009, at 4:12 PM, Carl Wallace wrote:
>
>> The "uniquely identifies" clause really only applies to the
>> issDN/serialNum bit. Moving it gives:
>>
>> 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
>> that uniquely identifies the certificate containing the public key
>> or by
>> a subject key identifier.
>>
>> -----Original Message-----
>> From: [email-masked]
> [mailto:[email-masked]
>> ]
>> On Behalf Of Sean Turner
>> Sent: Thursday, March 26, 2009 2:58 PM
>> To: Jan Vilhuber
>> Cc: [email-masked]
>> Subject: Re: Nitpicking between CMS and CMC
>>
>>
>> I think mandating a self-signed certificates is not the way to go.
>>
>> spt
>>
>> Jan Vilhuber wrote:
>>> I noticed the following discrepancy between CMC and CMS, which could
>>> very accurately be described as nitpicking (but them isn't that what
>>> standards are about?):
>>>
>>> CMS RFC, section 5. Signed-data Content Type:
>>>
>>>
>>> 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.
>>>
>>>
>>>
>>> Specifically: "... or by a subject key identifier that uniquely
>> identifies the certificate containing the public key".
>>> CMC RFC, Section 3.2. Full PKI Request
>>>
>>>
>>> If SignedData is used, the signature can be generated using either
>>> the
>>> private key material of an embedded signature certification request
>>> (i.e., included in the TaggedRequest tcr or crm fields) or a
>> previously
>>> certified signature key. If the private key of a signature
>> certification
>>> request is used, then:
>>>
>>> a. The certification request containing the corresponding public key
>>> MUST include a Subject Key Identifier extension
>>>
>>> b. The subjectKeyIdentifier form of the signerIdentifier in
>>> SignerInfo MUST be used.
>>>
>>> c. The value of the subjectKeyIdentifier form of SignerInfo MUST be
>>> the Subject Key Identifier specified in the corresponding
>>> certification request. (The subjectKeyIdentifier form of
>>> SignerInfo is used here because no certificates have yet been
>>> issued for the signing key.) If the request key is used for
>>> signing, there MUST be only one SignerInfo in the SignedData.
>>>
>>>
>>>
>>> So CMC allows the SignedData to use the SubjectKeyIdentifier, but
>> pointing to the certificate request it is encapsulating. While I don't
>> mind this usage, the CMS rfc specifically mentions that the
>> SubjectKeyIdentifier "uniquely identifies the certificate containing
>> the
>> public key".
>>> So if we want to be nitpicky about it, then the CMC rfc is asking for
>> something which is illegal as per the CMS RFC. This can be cleaned
>> up in
>> either place, i.e. either mandating in CMC that a self-signed
>> certificate be included when no previous certificate has been issued
>> (thus making it conform to CMS), or modify CMS to allow a more liberal
>> application of where to find the public key in question.
>>> Thoughts?
>>>
>>> jan
>>>
>>>
>>>
>
>

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2QGDTUh084638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Mar 2009 09:13:29 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2QGDTFg084637; Thu, 26 Mar 2009 09:13:29 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp107.biz.mail.mud.yahoo.com (smtp107.biz.mail.mud.yahoo.com [68.142.200.255]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n2QGDIYa084618 for ; Thu, 26 Mar 2009 09:13:28 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 2030 invoked from network); 26 Mar 2009 16:13:18 -0000
Received: from unknown (HELO sean-turners-macbook.local) ([email-masked] with plain) by smtp107.biz.mail.mud.yahoo.com with SMTP; 26 Mar 2009 16:13:17 -0000
X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To-
X-YMail-OSG: fQmqwMQVM1kz9k7.Hpb0jwjSvsYRxf1v0SDKs9LTD_UeA9dpx74m7hXFUaKFxZmB3bx7citDdVz92gxTD6uEgyFDD09FlzVQcrRj72pQud5sI.c1E6wasJvoq3GD.RCKWEdqdb1Q5o87M2zg9HZS_N68ZOxTwE93TMxwRog_0COMjpdBrSH0O6hi0gFLYCjPdiMXc4HYQpGz9P9TZ3P2FRtgN_I-
X-Yahoo-Newman-Property: ymail-3
Message-ID: <[email-masked]>
Date: Thu, 26 Mar 2009 09:13:17 -0700
From: Sean Turner
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
To: [email-masked]
Subject: Re: SMIME WG Summary
References: <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

I should add the following name to the list of people I need to contact:

Jeff Thompson
Jeff Weinstein
Anil Gangolli
Piers Chivers

spt

Sean Turner wrote:
>
> The following is similar to the report I sent to the saag list:
>
> The SMIME WG did not meet (again) but we haven't closed (yet) so here's
> a summary of what happened since last time:
>
> - draft-ietf-smime-sha2: entered the RFC editor's queue
> - draft-ietf-smime-3850bis: addressing IESG DISCUSSES (all resolved,
> in the eyes of the author, awaiting submission of new ID with
> get-out-of-jail boiler plate text*)**
> - draft-ietf-smime-3851bis: addressing IESG DISCUSSES (all resolved
> awaiting author submission of new ID, awaiting submission of new ID
> with get-out-of-jail boiler plate text*)***
> - draft-ietf-smime-3278bis: WGLC issued/passed, RFC 4858 write-up
> provided to AD, awaiting AD review and inclusion on IESG agenda
> - draft-ietf-smime-new-asn1: WGLC issued, new version posted addressing
> WGLC comments, awaiting RFC 4858 write-up (will be completed by the
> end of the week), and passed to Tim
> - draft-ietf-smime-cms-rsa-kem: STALLED!?! Text to address Steve Kent's
> SECDIR review provided to authors, and we're awaiting a response.
>
> I have been approached about three new IDs. The proposed plan is for
> each author to initially submit their ID as individual ID and then the
> WG will consider adoption.
>
> Cheers,
>
> spt
>
> * If I can reach Steve Dusse, Laurence Lundblade, Lisa Repka, Bill
> Flanigan, and Elliot Ginsberg then I won't have to include the text. If
> somebody has contact info for any of these people please let me know.
> ** Proposed changes to the ID based on IESG DISCUSSES can be found at:
> https://datatracker.ietf.org/idtracker/ballot/2906/
> *** Proposed changes to the ID based on IESG DISCUSSES can be found at:
> https://datatracker.ietf.org/idtracker/ballot/2906/
> I will be publishing new ID that incorporate the IESG DISCUSSES next week.
>
>

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2QF1rij079792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Mar 2009 08:01:53 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2QF1qCN079788; Thu, 26 Mar 2009 08:01:52 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp109.biz.mail.mud.yahoo.com (smtp109.biz.mail.mud.yahoo.com [68.142.201.178]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n2QF1f1p079768 for ; Thu, 26 Mar 2009 08:01:51 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 41823 invoked from network); 26 Mar 2009 15:01:41 -0000
Received: from unknown (HELO dhcp-4196.meeting.ietf.org) ([email-masked] with plain) by smtp109.biz.mail.mud.yahoo.com with SMTP; 26 Mar 2009 15:01:40 -0000
X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To-
X-YMail-OSG: yomT5M0VM1mCdCQW9lodiy7x2KEJwTUAzzeGd5p0cHfpDOuwM1kXvOXtsvAmcTp6TXAgCqD_YhCdJXMzgolspOGFeEGiGn3dC7y14mQInzkRjNn1zdRc3X7Qk4U7JRXVNr.7nul9Rismq_xvdREmD3HPkSWxitIFS5kxYEcZ7eRGhQh_e6lp7yYo9mvczSKcb4VpPl25wJ5Toplv6V4arJjaQhg-
X-Yahoo-Newman-Property: ymail-3
Message-ID: <[email-masked]>
Date: Thu, 26 Mar 2009 08:01:40 -0700
From: Sean Turner
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
To: [email-masked]
Subject: SMIME WG Summary
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

The following is similar to the report I sent to the saag list:

The SMIME WG did not meet (again) but we haven't closed (yet) so here's
a summary of what happened since last time:

- draft-ietf-smime-sha2: entered the RFC editor's queue
- draft-ietf-smime-3850bis: addressing IESG DISCUSSES (all resolved,
in the eyes of the author, awaiting submission of new ID with
get-out-of-jail boiler plate text*)**
- draft-ietf-smime-3851bis: addressing IESG DISCUSSES (all resolved
awaiting author submission of new ID, awaiting submission of new ID
with get-out-of-jail boiler plate text*)***
- draft-ietf-smime-3278bis: WGLC issued/passed, RFC 4858 write-up
provided to AD, awaiting AD review and inclusion on IESG agenda
- draft-ietf-smime-new-asn1: WGLC issued, new version posted addressing
WGLC comments, awaiting RFC 4858 write-up (will be completed by the
end of the week), and passed to Tim
- draft-ietf-smime-cms-rsa-kem: STALLED!?! Text to address Steve Kent's
SECDIR review provided to authors, and we're awaiting a response.

I have been approached about three new IDs. The proposed plan is for
each author to initially submit their ID as individual ID and then the
WG will consider adoption.

Cheers,

spt

* If I can reach Steve Dusse, Laurence Lundblade, Lisa Repka, Bill
Flanigan, and Elliot Ginsberg then I won't have to include the text. If
somebody has contact info for any of these people please let me know.
** Proposed changes to the ID based on IESG DISCUSSES can be found at:
https://datatracker.ietf.org/idtracker/ballot/2906/
*** Proposed changes to the ID based on IESG DISCUSSES can be found at:
https://datatracker.ietf.org/idtracker/ballot/2906/
I will be publishing new ID that incorporate the IESG DISCUSSES next week.

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2JK5PCt051158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Mar 2009 13:05:25 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2JK5PrM051157; Thu, 19 Mar 2009 13:05:25 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2JK5EPl051140 for ; Thu, 19 Mar 2009 13:05:24 -0700 (MST) (envelope-from [email-masked])
Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id CDB109A474B; Thu, 19 Mar 2009 16:05:33 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id riciSyx+QdPC; Thu, 19 Mar 2009 16:05:12 -0400 (EDT)
Received: from THINKPADR52.vigilsec.com (pool-96-255-144-212.washdc.fios.verizon.net [96.255.144.212]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 9D7B99A473A; Thu, 19 Mar 2009 16:05:32 -0400 (EDT)
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 19 Mar 2009 16:02:07 -0400
To: Julien Stern
From: Russ Housley
Subject: Re: CMS attributes question
Cc: [email-masked]
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
Message-Id: <[email-masked]>
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Some specification that make use of CMS mandate support for
additional attributes. These attributes are vital in the application
environment. I know that S/MIME requires support for some, and
recommends support for a few others. I think that time stamps are in
a similar situation.

Russ

At 04:31 AM 3/19/2009, Julien Stern wrote:
>Russ,
>
>thank you for your answer.
>
>Isn't it dangerous to ignore a _signed_ attribute ?
>In the case of an attribute such as ESSCertID or ESSCertIDV2 (RFC
>2634 ou RFC 5035), an implementation ignoring the attribute can give
>inconsistent results versus a implementation not ignoring the result
>(e.g. the signature is valid vs the signature has been forged).
>
>Also, when you are writing the these attributes are ignored, do you
>mean that they MUST be ignored or that they MAY be ignored? E.g. if
>my implementation fails upon receiving a signature with an unknown
>signed attribute, would you consider this non-standard? Or is this
>behavior up to the implementor?
>
>Regards,
>
>--
>Julien
>
>
>Russ Housley a écrit :
>>
>>Unrecognized attributes are ignored. RFC 3852 requires support for
>>the content type and message digest attributes, but all others can
>>be ignored if they are not recognized.
>>
>>Russ
>>
>>At 01:40 PM 3/18/2009, Julien Stern wrote:
>>
>>>Hi list,
>>>
>>>We have a question related to CMS that was raised during an ETSI
>>>session around the CAdES standard:
>>>
>>>we were wondering whether the behavior of an implementation
>>>encountering an unknown attribute was defined. One line of
>>>thinking is that an _unsigned_ attribute can be ignored by an
>>>implementation, but that the signature validation should fail if
>>>an unknown _signed_ attribute is encountered.
>>>
>>>Is this behavior somehow defined in CMS (I did not see it, but I
>>>might have missed it)?
>>>Otherwise, what do you think? What does your implementation do
>>>when it encounters an unknown signed attribute?
>>>
>>>Regards,
>>>
>>>--
>>>Julien

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2JFTH5Z035499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Mar 2009 08:29:17 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2JFTHLL035495; Thu, 19 Mar 2009 08:29:17 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from maiev.nerim.net (smtp-118-thursday.nerim.net [62.4.16.118]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2JFT5NJ035472; Thu, 19 Mar 2009 08:29:16 -0700 (MST) (envelope-from [email-masked])
Received: from uranus.cry.pto (cryptolog2.pck.nerim.net [213.41.184.9]) by maiev.nerim.net (Postfix) with ESMTP id 7BCEEB864A; Thu, 19 Mar 2009 16:29:02 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 7C217440F5; Thu, 19 Mar 2009 16:29:02 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at cryptolog.com
Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus.cry.pto [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORqPo6NwGePZ; Thu, 19 Mar 2009 16:28:59 +0100 (CET)
Received: from [IPv6???1] (vpn.cry.pto [10.0.6.100]) by uranus.cry.pto (Postfix) with ESMTP id C5F4C440AF; Thu, 19 Mar 2009 16:28:58 +0100 (CET)
Message-ID: <[email-masked]>
Date: Thu, 19 Mar 2009 16:29:01 +0100
From: Julien Stern
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Paul Hoffman
Cc: Russ Housley , [email-masked]
Subject: Re: CMS attributes question
References: <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Paul Hoffman a écrit :
> At 9:31 AM +0100 3/19/09, Julien Stern wrote:
>
>> Isn't it dangerous to ignore a _signed_ attribute ?
>>
>
> No. The fact that the signer wanted the data to be protected in transport doesn't mean that it is inherently important to the recipient. The decision to sign an attribute is usually made by the software developer (and could come down to "well, why not?"), not the sender.
>
Paul,

The problem is that for some specific attributes (such as some in RFC
2634, RFC 5035 or CAdES) begin capable of processing the attribute or
not will influence the actual result of signature validation.
>> Also, when you are writing the these attributes are ignored, do you mean that they MUST be ignored or that they MAY be ignored? E.g. if my implementation fails upon receiving a signature with an unknown signed attribute, would you consider this non-standard? Or is this behavior up to the implementor?
>>
>
> The latter. Remember, we can't say what it really means to "understand" an attribute.
>
OK. Thanks. One (hopefully) last question:
if in CAdES (which extends CMS as you surely know), we mandated
signature validation to stop if a signed attribute is not supported by
the verifying implementation, would you consider this inconsistent with
CMS or not?

Best regards,

--
Julien

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2JEwI7t032742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Mar 2009 07:58:18 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2JEwIrU032741; Thu, 19 Mar 2009 07:58:18 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2JEvr1l032712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Mar 2009 07:57:54 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Date: Thu, 19 Mar 2009 07:56:39 -0700
To: Julien Stern , Russ Housley
From: Paul Hoffman
Subject: Re: CMS attributes question
Cc: [email-masked]
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At 9:31 AM +0100 3/19/09, Julien Stern wrote:
>Isn't it dangerous to ignore a _signed_ attribute ?

No. The fact that the signer wanted the data to be protected in transport doesn't mean that it is inherently important to the recipient. The decision to sign an attribute is usually made by the software developer (and could come down to "well, why not?"), not the sender.

>Also, when you are writing the these attributes are ignored, do you mean that they MUST be ignored or that they MAY be ignored? E.g. if my implementation fails upon receiving a signature with an unknown signed attribute, would you consider this non-standard? Or is this behavior up to the implementor?

The latter. Remember, we can't say what it really means to "understand" an attribute.

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2J8Ve9N005590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Mar 2009 01:31:40 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2J8VejJ005589; Thu, 19 Mar 2009 01:31:40 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mallaury.nerim.net (smtp-104-thursday.noc.nerim.net [62.4.17.104]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2J8VTnb005573 for ; Thu, 19 Mar 2009 01:31:39 -0700 (MST) (envelope-from [email-masked])
Received: from uranus.cry.pto (cryptolog2.pck.nerim.net [213.41.184.9]) by mallaury.nerim.net (Postfix) with ESMTP id 7FDACA1082; Thu, 19 Mar 2009 09:31:27 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id BB7F8440F5; Thu, 19 Mar 2009 09:31:27 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at cryptolog.com
Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus.cry.pto [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VrEB2lYcCOmL; Thu, 19 Mar 2009 09:31:23 +0100 (CET)
Received: from [IPv6???1] (vpn.cry.pto [10.0.6.100]) by uranus.cry.pto (Postfix) with ESMTP id 08316440AF; Thu, 19 Mar 2009 09:31:22 +0100 (CET)
Message-ID: <[email-masked]>
Date: Thu, 19 Mar 2009 09:31:26 +0100
From: Julien Stern
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Russ Housley
Cc: [email-masked]
Subject: Re: CMS attributes question
References: <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Russ,

thank you for your answer.

Isn't it dangerous to ignore a _signed_ attribute ?
In the case of an attribute such as ESSCertID or ESSCertIDV2 (RFC 2634
ou RFC 5035), an implementation ignoring the attribute can give
inconsistent results versus a implementation not ignoring the result
(e.g. the signature is valid vs the signature has been forged).

Also, when you are writing the these attributes are ignored, do you mean
that they MUST be ignored or that they MAY be ignored? E.g. if my
implementation fails upon receiving a signature with an unknown signed
attribute, would you consider this non-standard? Or is this behavior up
to the implementor?

Regards,

--
Julien

Russ Housley a écrit :
>
> Unrecognized attributes are ignored. RFC 3852 requires support for
> the content type and message digest attributes, but all others can be
> ignored if they are not recognized.
>
> Russ
>
> At 01:40 PM 3/18/2009, Julien Stern wrote:
>
>> Hi list,
>>
>> We have a question related to CMS that was raised during an ETSI
>> session around the CAdES standard:
>>
>> we were wondering whether the behavior of an implementation
>> encountering an unknown attribute was defined. One line of thinking
>> is that an _unsigned_ attribute can be ignored by an implementation,
>> but that the signature validation should fail if an unknown _signed_
>> attribute is encountered.
>>
>> Is this behavior somehow defined in CMS (I did not see it, but I
>> might have missed it)?
>> Otherwise, what do you think? What does your implementation do when
>> it encounters an unknown signed attribute?
>>
>> Regards,
>>
>> --
>> Julien
>>
>

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2J5irWi098190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Mar 2009 22:44:53 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2J5irxT098189; Wed, 18 Mar 2009 22:44:53 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2J5ieBa098169 for ; Wed, 18 Mar 2009 22:44:51 -0700 (MST) (envelope-from [email-masked])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 1C6AE9DE2C; Thu, 19 Mar 2009 18:44:39 +1300 (NZDT)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggKfJEVBgLvV; Thu, 19 Mar 2009 18:44:38 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id F38909DDB2; Thu, 19 Mar 2009 18:44:37 +1300 (NZDT)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 21EA01DE4002; Thu, 19 Mar 2009 18:44:36 +1300 (NZDT)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1LkB3T-0001w1-Vy; Thu, 19 Mar 2009 18:44:36 +1300
From: Peter Gutmann
To: [email-masked], [email-masked]
Subject: Re: CMS attributes question
Cc: [email-masked]
In-Reply-To: <[email-masked]>
Message-Id:
Date: Thu, 19 Mar 2009 18:44:35 +1300
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Russ Housley writes:

>Unrecognized attributes are ignored. RFC 3852 requires support for the
>content type and message digest attributes, but all others can be ignored if
>they are not recognized.

In addition handling of content-type seems to be pretty hit-and-miss, I've
seen messages created by different implementations that have no content-type
and nothing seems to mind (well, my code did which is why I noticed it :-) but
there don't seem to have been sufficient problems caused by other
implementations complaining that the developers felt the need to fix things.

Peter.

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2IJ6JnJ067254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Mar 2009 12:06:20 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2IJ6JsI067253; Wed, 18 Mar 2009 12:06:19 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2IJ68Hn067239 for ; Wed, 18 Mar 2009 12:06:19 -0700 (MST) (envelope-from [email-masked])
Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id D05B79A47AE; Wed, 18 Mar 2009 15:06:28 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id 09AI-t2Osa+p; Wed, 18 Mar 2009 15:06:07 -0400 (EDT)
Received: from THINKPADR52.vigilsec.com (pool-96-255-144-212.washdc.fios.verizon.net [96.255.144.212]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id EF1C09A478A; Wed, 18 Mar 2009 15:06:27 -0400 (EDT)
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 18 Mar 2009 14:56:49 -0400
To: Julien Stern
From: Russ Housley
Subject: Re: CMS attributes question
Cc: [email-masked]
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-Id: <[email-masked]>
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Unrecognized attributes are ignored. RFC 3852 requires support for
the content type and message digest attributes, but all others can be
ignored if they are not recognized.

Russ

At 01:40 PM 3/18/2009, Julien Stern wrote:

>Hi list,
>
>We have a question related to CMS that was raised during an ETSI
>session around the CAdES standard:
>
>we were wondering whether the behavior of an implementation
>encountering an unknown attribute was defined. One line of thinking
>is that an _unsigned_ attribute can be ignored by an implementation,
>but that the signature validation should fail if an unknown _signed_
>attribute is encountered.
>
>Is this behavior somehow defined in CMS (I did not see it, but I
>might have missed it)?
>Otherwise, what do you think? What does your implementation do when
>it encounters an unknown signed attribute?
>
>Regards,
>
>--
>Julien
>

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2IHeZmv061402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Mar 2009 10:40:35 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2IHeZGD061401; Wed, 18 Mar 2009 10:40:35 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from maiev.nerim.net (smtp-117-wednesday.nerim.net [62.4.16.117]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2IHeOXP061384 for ; Wed, 18 Mar 2009 10:40:34 -0700 (MST) (envelope-from [email-masked])
Received: from uranus.cry.pto (cryptolog2.pck.nerim.net [213.41.184.9]) by maiev.nerim.net (Postfix) with ESMTP id C9F03B8B5F for ; Wed, 18 Mar 2009 18:40:22 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id C3833440F5 for ; Wed, 18 Mar 2009 18:40:22 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at cryptolog.com
Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus.cry.pto [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrxLT1VEqkar for ; Wed, 18 Mar 2009 18:40:19 +0100 (CET)
Received: from [IPv6???1] (vpn.cry.pto [10.0.6.100]) by uranus.cry.pto (Postfix) with ESMTP id 73A33440ED for ; Wed, 18 Mar 2009 18:40:19 +0100 (CET)
Message-ID: <[email-masked]>
Date: Wed, 18 Mar 2009 18:40:22 +0100
From: Julien Stern
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: [email-masked]
Subject: CMS attributes question
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Hi list,

We have a question related to CMS that was raised during an ETSI session
around the CAdES standard:

we were wondering whether the behavior of an implementation encountering
an unknown attribute was defined. One line of thinking is that an
_unsigned_ attribute can be ignored by an implementation, but that the
signature validation should fail if an unknown _signed_ attribute is
encountered.

Is this behavior somehow defined in CMS (I did not see it, but I might
have missed it)?
Otherwise, what do you think? What does your implementation do when it
encounters an unknown signed attribute?

Regards,

--
Julien

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2GGP8XO074485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Mar 2009 09:25:08 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2GGP8N2074484; Mon, 16 Mar 2009 09:25:08 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from alfa.ritlabs.com (alfa.ritlabs.com [212.56.194.252]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2GGOuN5074454; Mon, 16 Mar 2009 09:25:07 -0700 (MST) (envelope-from [email-masked])
Received: from Maxim-PC1 (maxim.alfa.ritlabs.com [212.56.194.246]) by alfa.ritlabs.com (8.14.2/8.14.2) with ESMTP id n2GGOkju019416; Mon, 16 Mar 2009 18:24:47 +0200
CC: [email-masked], [email-masked]
Date: Mon, 16 Mar 2009 18:24:54 +0200
From: "Maxim Masiutin"
In-Reply-To: <[email-masked]>
MIME-Version: 1.0
Message-ID: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Reply-To: "Maxim Masiutin"
Subject: Re[2]: A contradiction between RFC3852 and RFC3278
To: "Sean Turner"
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on alfa.ritlabs.com
X-Virus-Status: Clean
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Hello Sean,

Thank you, your suggestion to add a paragraph is fine!

--
Best regards,
Maxim Masiutin mailto:[email-masked]

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2GGA861073454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Mar 2009 09:10:08 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2GGA8RD073452; Mon, 16 Mar 2009 09:10:08 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp108.biz.mail.re2.yahoo.com (smtp108.biz.mail.re2.yahoo.com [206.190.52.47]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n2GG9rpN073403 for ; Mon, 16 Mar 2009 09:10:03 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 88129 invoked from network); 16 Mar 2009 16:09:53 -0000
Received: from unknown (HELO sean-turners-macbook.local) ([email-masked] with plain) by smtp108.biz.mail.re2.yahoo.com with SMTP; 16 Mar 2009 16:09:52 -0000
X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To-
X-YMail-OSG: .tA2C4AVM1khOuSnOXHA8QLZ0ZW.yFM6J5PJcAw_wnvyGvP6nG2FzruNwbgb1vJOol4f2LhDmJWtHqtdDRKpQ61gcbUihNQgut_XdpSywiSrBgqjZ9bJ0.CW9.6iqr04fH46FQf_RIaHyJfLacEXoXyf6S9PG50i7zC1tqife0vLT2pn1bMCFNKPpz4Y
X-Yahoo-Newman-Property: ymail-3
Message-ID: <[email-masked]>
Date: Mon, 16 Mar 2009 12:10:04 -0400
From: Sean Turner
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: Maxim Masiutin
CC: [email-masked], [email-masked]
Subject: Re: A contradiction between RFC3852 and RFC3278
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Maxim,

The paragraph now says:

signatureAlgorithm contains the signature algorithm identifier (see
Section 7.1.3): ecdsa-with-SHA1, ecdsa-with-SHA224, ecdsa-with-SHA256,
ecdsa-with-SHA384, or ecdsa-with-SHA512.

How about we add the following to the end of it:

The hash algorithm identified in the name of the signature algorithm
MUST be the same as the digestAlgorithm (e.g., digestAlgorithm is
id-sha256 therefore signatureAlgorithm is ecdsa-with-SHA256).

spt

Maxim Masiutin wrote:
> Hello Sean,
>
> Maybe we should alter the description of signatureAlgorithm in section 2.1.1 of draft-smime-3278bis, to the following:
>
> - signatureAlgorithm contains the signature algorithm identifier
> (see Section 7.1.3) where the public key part of it
> is ECDSA and the hash part MUST refer to the same algorithm as
> specified in the digestAlgorithm field. signatureAlgorithm MUST
> be one of the following ecdsa-with-SHA1,
> ecdsa-with-SHA224, ecdsa-with-SHA256,
> ecdsa-with-SHA384, or ecdsa-with-SHA512.
>
>

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2FC8BLi081170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Mar 2009 05:08:11 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2FC8Bmp081169; Sun, 15 Mar 2009 05:08:11 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2FC7wMq081151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Mar 2009 05:08:09 -0700 (MST) (envelope-from [email-masked])
Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n2FC7H6h018692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 15 Mar 2009 05:07:18 -0700 (PDT)
Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id n2FC7GiT018690; Sun, 15 Mar 2009 05:07:16 -0700 (PDT)
Date: Sun, 15 Mar 2009 05:07:16 -0700 (PDT)
Message-Id: <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [Technical Errata Reported] RFC4134 (1716)
From: RFC Errata System
Cc: [email-masked], [email-masked], [email-masked]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [email-masked]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

The following errata report has been submitted for RFC4134,
"Examples of S/MIME Messages".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4134&eid=1716

--------------------------------------
Type: Technical
Reported by: Maxim Masiutin

Section: 4.8 & 4.9

Original Text
-------------
[email-masked]

Corrected Text
--------------
[email-masked]

Notes
-----
"From" line of the RFC-822 message is [email-masked], while the certificate’s SubjectAlternativeName contains Rfc822Name = [email-masked]

So the two emails are different in the host part:

[email-masked]
[email-masked]

The wrong email ([email-masked]) is given in both cleartext examples and encoded examples.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC4134 (draft-ietf-smime-examples-15)
--------------------------------------
Title : Examples of S/MIME Messages
Publication Date : July 2005
Author(s) : P. Hoffman, Ed.
Category : INFORMATIONAL
Source : S/MIME Mail Security
Area : Security
Stream : IETF
Verifying Party : IESG

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2ELhgvU049937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Mar 2009 14:43:42 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2ELhgjX049935; Sat, 14 Mar 2009 14:43:42 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from argus.ritlabs.com (argus.ritlabs.com [91.198.236.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2ELheA3049921; Sat, 14 Mar 2009 14:43:41 -0700 (MST) (envelope-from [email-masked])
Received: from localhost (89-28-100-245.starnet.md [89.28.100.245]) (authenticated bits=0) by argus.ritlabs.com (8.14.2/8.14.2) with ESMTP id n2ELha3f026105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 14 Mar 2009 23:43:36 +0200
CC: [email-masked], [email-masked]
Date: Sat, 14 Mar 2009 23:43:18 +0200
From: "Maxim Masiutin"
In-Reply-To: <[email-masked]>
MIME-Version: 1.0
Message-ID: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Reply-To: "Maxim Masiutin"
Subject: Re[2]: A contradiction between RFC3852 and RFC3278
To: "Sean Turner"
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on argus.ritlabs.com
X-Virus-Status: Clean
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Hello Sean,

Maybe we should alter the description of signatureAlgorithm in section 2.1.1 of draft-smime-3278bis, to the following:

- signatureAlgorithm contains the signature algorithm identifier
(see Section 7.1.3) where the public key part of it
is ECDSA and the hash part MUST refer to the same algorithm as
specified in the digestAlgorithm field. signatureAlgorithm MUST
be one of the following ecdsa-with-SHA1,
ecdsa-with-SHA224, ecdsa-with-SHA256,
ecdsa-with-SHA384, or ecdsa-with-SHA512.

--
Best regards,
Maxim Masiutin
Ritlabs SRL
http://www.ritlabs.com/

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2DNuU57092269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Mar 2009 16:56:30 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2DNuU0i092267; Fri, 13 Mar 2009 16:56:30 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp101.biz.mail.re2.yahoo.com (smtp101.biz.mail.re2.yahoo.com [68.142.229.215]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n2DNuISv092245 for ; Fri, 13 Mar 2009 16:56:28 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 2666 invoked from network); 13 Mar 2009 23:56:17 -0000
Received: from unknown (HELO sean-turners-macbook.local) ([email-masked] with plain) by smtp101.biz.mail.re2.yahoo.com with SMTP; 13 Mar 2009 23:56:17 -0000
X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To-
X-YMail-OSG: heay3_sVM1ltRNlCCbsjc1cH1Pd02qxstxgbC7s7UFBwiNdl4sIi2TTGDz5p0dyazhVzOELEJGQBHpHcoe6sBYRTliw5TiuW4kyAazdTsblsZ.G7J6vtU.VXQXXYPLp62reHdjDUKyGa4sUWcKpAuoVInVuFosf07M7Yrk_qTPTnVG9FcMJpy4Pueyhp
X-Yahoo-Newman-Property: ymail-3
Message-ID: <[email-masked]>
Date: Fri, 13 Mar 2009 19:56:24 -0400
From: Sean Turner
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: Maxim Masiutin
CC: [email-masked], [email-masked]
Subject: Re: A contradiction between RFC3852 and RFC3278
References: <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=windows-1250; format=flowed
Content-Transfer-Encoding: 8bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Maxim,

I don't have any objection to adding the note to draft-smime-3278bis.

spt

Maxim Masiutin wrote:
> Hello Sean,
>
> In all CMS messages that I’ve seen, when RSA algorithm is used, SignatureAlgorithm in the SignerInfo is rsaEncryption, not md5WithRSAEncryption. That’s why it made confusion when I was implementing elliptic curves.
> Maybe, if an update of RFC3852 is planned, we will add a clarification for this?
> Also, while RFC3278-bis is in the draft status, what about adding a clarification that hash in SignatureAlgorithm and DigestAlgorithm must match?
>
>

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n29LFcND081720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Mar 2009 14:15:38 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n29LFciM081718; Mon, 9 Mar 2009 14:15:38 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n29LFc73081706 for ; Mon, 9 Mar 2009 14:15:38 -0700 (MST) (envelope-from [email-masked])
Received: by core3.amsl.com (Postfix, from userid 0) id BE5753A69DE; Mon, 9 Mar 2009 14:15:02 -0700 (PDT)
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-smime-new-asn1-03.txt
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[email-masked]>
Date: Mon, 9 Mar 2009 14:15:02 -0700 (PDT)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

--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 : New ASN.1 Modules for CMS and S/MIME
Author(s) : P. Hoffman, J. Schaad
Filename : draft-ietf-smime-new-asn1-03.txt
Pages : 62
Date : 2009-03-09

The Cryptographic Message Syntax (CMS) format, and many associated
formats, are expressed using ASN.1. The current ASN.1 modules
conform to the 1988 version of ASN.1. This document updates those
ASN.1 modules to conform to the 2002 version of ASN.1. There are no
bits-on-the-wire changes to any of the formats; this is simply a
change to the syntax.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
name="draft-ietf-smime-new-asn1-03.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"

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

--NextPart--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n25LA9ZA039004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Mar 2009 14:10:09 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n25LA9KV039003; Thu, 5 Mar 2009 14:10:09 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from argus.ritlabs.com (argus.ritlabs.com [91.198.236.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n25L9vEi038964 for ; Thu, 5 Mar 2009 14:10:08 -0700 (MST) (envelope-from [email-masked])
Received: from 127.0.0.1 (89-28-100-245.starnet.md [89.28.100.245]) (authenticated bits=0) by argus.ritlabs.com (8.14.2/8.14.2) with ESMTP id n25L9slU027734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Mar 2009 23:09:55 +0200
CC: [email-masked]
Date: Thu, 5 Mar 2009 23:09:37 +0200
From: "Maxim Masiutin"
In-Reply-To: <[email-masked]>
MIME-Version: 1.0
Message-ID: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Reply-To: "Maxim Masiutin"
Subject: Re[2]: Maximum length in octets of messages that can be hashed
To: "Russ Housley"
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on argus.ritlabs.com
X-Virus-Status: Clean
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Hello Russ,

Thank you very much FIP 180-2 gives a clarification: "When a message of any length < 2^64 bits (for SHA-1 and SHA-256) or < 2^128 bits (for SHA-384 and SHA-512) is input to an algorithm, the result is an output called a message digest.

--
Best regards,
Maxim Masiutin
Ritlabs SRL
http://www.ritlabs.com/

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n25Htd3u029876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Mar 2009 10:55:39 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n25HtdBU029875; Thu, 5 Mar 2009 10:55:39 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n25HtaIb029868 for ; Thu, 5 Mar 2009 10:55:37 -0700 (MST) (envelope-from [email-masked])
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA240725621; Thu, 5 Mar 2009 18:53:41 +0100
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id SAA26395; Thu, 5 Mar 2009 18:53:40 +0100 (MEZ)
From: Alfred =?hp-roman8?B?SM5uZXM=?=
Message-Id: <[email-masked]>
Subject: Re: Implementation of ANSI-X9.63-KDF
To: [email-masked]
Date: Thu, 5 Mar 2009 18:53:40 +0100 (MEZ)
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset=hp-roman8
Content-Transfer-Encoding: 8bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

In the message archived at
http://www.IMC.ORG/ietf-smime/mail-archive/msg03318.html,
Maxim Masiutin wrote:

> Where can I find implementation of key derivation function
> ANSI-X9.63-KDF to use with ECDH (RFC 3278)?
> I didn't find it in OpenSSL or CryptLib.

The designated successor of RFC 3278, draft-ietf-smime-3278bis,
available e.g. at:
http://tools.ietf.org/html/draft-ietf-smime-3278bis-05
gives you (in Section 7.1.8) a pointer to the description of the
method now considered authoritative by the SMIME WG, because of
its barrier-free availablility: Section 3.6.1 of SEC-1 (pp.29/30).

The algorithm is trivial to implement once you have an
implementation of the hash function available; besides that,
it only makes use of octet string concatenation and basic
32-bit integer (index) arithmetics. Typical hash function
APIs will allow optimizations to avoid the interior string
concatenations, replacing them by incremental (partial) hash
function calls, and the hash output concatenation will also
not be performed explicitely, but by pointer addressing;
intermediate state saving techniques might be applied for further
optimization, but that will go far beyond the typical needs in
EC context, with much shorter shared secrets than in RSA cases.

Kind regards,
Alfred HÎnes.

--

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. |
| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 |
| D-71254 Ditzingen | E-Mail: [email-masked] |
+------------------------+--------------------------------------------+

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n25HMj4M027604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Mar 2009 10:22:46 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n25HMj52027603; Thu, 5 Mar 2009 10:22:45 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n25HMWDU027585 for ; Thu, 5 Mar 2009 10:22:44 -0700 (MST) (envelope-from [email-masked])
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA240493638; Thu, 5 Mar 2009 18:20:38 +0100
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id SAA26340; Thu, 5 Mar 2009 18:20:36 +0100 (MEZ)
From: Alfred =?hp-roman8?B?SM5uZXM=?=
Message-Id: <[email-masked]>
Subject: Re: Maximum length in octets of messages that can be hashed
To: [email-masked]
Date: Thu, 5 Mar 2009 18:20:36 +0100 (MEZ)
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset=hp-roman8
Content-Transfer-Encoding: 8bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Hello,

In the message archived at
http://www.IMC.ORG/ietf-smime/mail-archive/msg03319.html,
Maxim Masiutin wrote:

> Section 3.6.1 of "SEC 1: Elliptic Curve Cryptography"
> http://www.secg.org/download/aid-385/sec1_final.pdf defines
> "hashmaxlen" as "the maximum length in octets of messages
> that can be hashed using Hash".
>
> Where can I find the maximum length of message for SHA-1,
> SHA-224(etc). I've searched through fip180-1 and didn't
> find any limitation. ANSI-X9.63 also imposes the limitation.
> Why then the authors ANSI-X9.63 did define the hashmaxlen
> limitation if there is no such limitation practically?

Hmmm. What version of FIPS 180 did you skim over? (See note below.)

In the current version, FIPS 180-3, published in October 2008,
the Introduction (Section 1), at the bottom of the first text
page, contains a table labelled "Figure 1" which I guess can
legitimately be translated into ASCII text. It says:

Algorithm | Message Size | Block Size | Word Size | Message Digest Size
| (bits) | (bits) | (bits) | (bits)
----------+--------------+------------+-----------+--------------------
SHA-1 | < 2**64 | 512 | 32 | 160
SHA-224 | < 2**64 | 512 | 32 | 224
SHA-256 | < 2**64 | 512 | 32 | 256
SHA-384 | < 2**128 | 1024 | 64 | 384
SHA-512 | < 2**128 | 1024 | 64 | 512

Figure 1: Secure Hash Algorithm Properties

Apparently, the second column essentially contains what you
are looking for; conversion to {number of octets} (or bytes --
whichever term you prefer) should be straightforward.

The limits for SHA-384 and SHA-512 might indeed be considered
practically irrelevant, but the lower value for the other
algorithms might indeed be relevant in specific environments.

Note:

This table already was in the June 2007 Draft FIPS 180-3.
Its predecessor version (without the line for SHA-224) was
in the June 2002 FIPS 180-2; the line for SHA-224 had been
supplied on the first text page of the February 2005
"Change Notice 1" to FIPS 180-2 initially specifying SHA-224.

FIPS 180-1 (1993) was for SHA-1 only, so nobody would espect it to
have contained data points for the more recent algorithms, however
its INTRODUCTION contained the said limit for SHA-1 in the prose.

Kind regards,
Alfred HÎnes.

--

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. |
| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 |
| D-71254 Ditzingen | E-Mail: [email-masked] |
+------------------------+--------------------------------------------+

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n25Fv7lY021320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Mar 2009 08:57:07 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n25Fv7dq021319; Thu, 5 Mar 2009 08:57:07 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n25Fv6Cr021313 for ; Thu, 5 Mar 2009 08:57:07 -0700 (MST) (envelope-from [email-masked])
Message-Id: <[email-masked]>
Received: (qmail 24488 invoked by uid 0); 5 Mar 2009 15:57:03 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.144.212) by woodstock.binhost.com with SMTP; 5 Mar 2009 15:57:03 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 05 Mar 2009 10:52:49 -0500
To: "Maxim Masiutin"
From: Russ Housley
Subject: Re: Maximum length in octets of messages that can be hashed
Cc: [email-masked]
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Look at the message padding section of the SHA-1 algorithm
specification. The length of the "original message" is encoded in
the padding. The technique places an upper bound on the number of
bits that can be hashed.

Russ

At 08:14 AM 3/5/2009, Maxim Masiutin wrote:

>Hello Ietf-Smime,
>
> Secion 3.6.1 of "SEC 1: Elliptic Curve Cryptography"
> http://www.secg.org/download/aid-385/sec1_final.pdf defines
>
>"hashmaxlen" as "the maximum length in octets of messages that can
>be hashed using Hash".
>
> Where can I find the maximum lenght of message for SHA-1,
> SHA-224(etc). I've searched through fip180-1 and didn't find any
> limitation. ANSI-X9.63 also imposes the limitation. Why then the
> authors ANSI-X9.63 did define the hashmaxlen limitation if there is
> no such limitation practically?
>
>--
>Best regards,
>Maxim Masiutin mailto:[email-masked]

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n25DDnjC011051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Mar 2009 06:13:49 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n25DDn47011050; Thu, 5 Mar 2009 06:13:49 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from alfa.ritlabs.com (alfa.ritlabs.com [212.56.194.252]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n25DDlCr011041 for ; Thu, 5 Mar 2009 06:13:48 -0700 (MST) (envelope-from [email-masked])
Received: from Maxim-PC1 (maxim.alfa.ritlabs.com [212.56.194.246]) by alfa.ritlabs.com (8.14.2/8.14.2) with ESMTP id n25DDkim010884 for ; Thu, 5 Mar 2009 15:13:46 +0200
Date: Thu, 5 Mar 2009 15:14:02 +0200
From: "Maxim Masiutin"
MIME-Version: 1.0
Message-ID: <[email-masked]>
Reply-To: "Maxim Masiutin"
Subject: Maximum length in octets of messages that can be hashed
To: [email-masked]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on alfa.ritlabs.com
X-Virus-Status: Clean
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Hello Ietf-Smime,

Secion 3.6.1 of "SEC 1: Elliptic Curve Cryptography" http://www.secg.org/download/aid-385/sec1_final.pdf defines

"hashmaxlen" as "the maximum length in octets of messages that can be hashed using Hash".

Where can I find the maximum lenght of message for SHA-1, SHA-224(etc). I've searched through fip180-1 and didn't find any limitation. ANSI-X9.63 also imposes the limitation. Why then the authors ANSI-X9.63 did define the hashmaxlen limitation if there is no such limitation practically?

--
Best regards,
Maxim Masiutin mailto:[email-masked]

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n25D38rZ010098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Mar 2009 06:03:08 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n25D381X010097; Thu, 5 Mar 2009 06:03:08 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from alfa.ritlabs.com (alfa.ritlabs.com [212.56.194.252]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n25D2usH010078 for ; Thu, 5 Mar 2009 06:03:07 -0700 (MST) (envelope-from [email-masked])
Received: from Maxim-PC1 (maxim.alfa.ritlabs.com [212.56.194.246]) by alfa.ritlabs.com (8.14.2/8.14.2) with ESMTP id n25D2r5O008164 for ; Thu, 5 Mar 2009 15:02:54 +0200
Date: Thu, 5 Mar 2009 15:03:09 +0200
From: "Maxim Masiutin"
MIME-Version: 1.0
Message-ID: <[email-masked]>
Reply-To: "Maxim Masiutin"
Subject: Implementation of ANSI-X9.63-KDF
To: [email-masked]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on alfa.ritlabs.com
X-Virus-Status: Clean
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Hello ALl,

Where can I find implementation of key derivation function ANSI-X9.63-KDF to use with ECDH (RFC 3278)? I didn't find it in OpenSSL or CryptLib.

--
Best regards,
Maxim Masiutin mailto:[email-masked]