Subject: Re: [smime] [Technical Errata Reported] RFC4490 (1884)

From: Sean Turner <[email-masked]>
Date: Mon, 19 Apr 2010 18:43:15 -0400

What are your recommendations for the other errata:

http://www.rfc-editor.org/verify_errata_select.php?eid=1885

Should it also be rejected?

spt

Леонтьев Сергей Ефимович wrote:
> Hi,
> 
> REJECT
> 
> This is a request (Errata Note for RFC 4490, EID=1884) to change the protocol, not an errata. Changes like this need to go through a new RFC.
> 
> 
> --
> Sorry for my bests English.
> Serguei E. Leontiev w:+7(495)780-4820 USSR,Moscow,127018,Sushchevskij val 16-5
> Crypto-Pro, Ltd.    m:+7(916)686-1081 SMS: <http://sms.mts.ru/>
> <http://CryptoPro.ru>
> 
> 
> 
> -----Original Message-----
> From: Gregory Chudov [mailto:[email-masked]] 
> Sent: Wednesday, September 23, 2009 6:57 PM
> To: RFC Errata System
> Cc: Леонтьев Сергей Ефимович; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Technical Errata Reported] RFC4490 (1884)
> 
> Greetings.
> 
> 1) The Message Digest within the context of CMS is treated not as an
> integer, but as a sequence of bytes. Ideally, we shouldn't have
> mentioned any byte order here at all.
> 2) Unfortunately, GOST R 34.11-94 doesn't specify the byte order for
> the resulting digest, so we did have to specify it here.
> 3) The samples from GOST R 34.11-94
> (http://tools.ietf.org/html/draft-dolmatov-cryptocom-gost341194-02#section-7.3.1)
> use little-endian byte order for the source messages, so little-endian
> representation was a de-facto standard for applications using GOST R
> 34.11-94 digest, long before RFC4490 was published.
> 4) Reversing the byte order for Message Digest would require at least
> a new digest OID, otherwise it would break numerous existing
> implementations, and would be inconsistent with the samples provided
> in RFC4490.
> 5) As an alternative errata, the following sample can be added,
> clarifying the byte order for Message Digest, using example from GOST
> R 34.11-94:
> 
> Message from [GOSTR341194] Appendix 3.1
> ([draft-dolmatov-cryptocom-gost341194-02], section 7.3.1):
> M = "This is message, length=32 bytes"
> MessageDigest:
> 0   32:         OCTET STRING
>      :          b1 c4 66 d3 75 19 b8 2e 83 19 81 9f f3 25 95 e0
>      :          47 a2 8c b6 f8 3e ff 1c 69 16 a8 15 a6 37 ff fa
> 
> 
> Regards,
> Gregory Chudov & Serguei Leontiev
> 
> 2009/9/17 RFC Errata System <[email-masked]>:
>> The following errata report has been submitted for RFC4490,
>> "Using the GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 Algorithms with Cryptographic Message Syntax (CMS)".
>>
>> --------------------------------------
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata_search.php?rfc=4490&eid=1884
>>
>> --------------------------------------
>> Type: Technical
>> Reported by: Alfred Hoenes <[email-masked]>
>>
>> Section: 2.1, pg. 4
>>
>> Original Text
>> -------------
>>   When the Message Digest authenticated attribute is present, the
>> |  DigestedData digest contains a 32-byte digest in little-endian
>>   representation:
>>
>>
>> Corrected Text
>> --------------
>>   When the Message Digest authenticated attribute is present, the
>> |  DigestedData digest contains a 32-byte digest in big-endian
>>   representation:
>>
>>
>> Notes
>> -----
>> Rationale:
>> - Contradiction to other parts of the document,
>>  which use "big-endian" == 'network byte order'
>>  as established in the Internet architecture.
>> - Please also note that the ASN.1 BER/DER encoding is
>>  based on the 'natural' byte order for left-to-right
>>  scripts -- otherwise the intrinsically variable-length
>>  representation used would be very complicated to deal
>>  with in processing.
>> - Intrduction of varying endian-ness is a likely source
>>  of implementation issues and, consequentially,
>>  interoperability problems.
>>
>> 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.
>>
>> --------------------------------------
>> RFC4490 (draft-ietf-smime-gost-07)
>> --------------------------------------
>> Title               : Using the GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 Algorithms with Cryptographic Message Syntax (CMS)
>> Publication Date    : May 2006
>> Author(s)           : S. Leontiev, Ed., G. Chudov, Ed.
>> Category            : PROPOSED STANDARD
>> Source              : S/MIME Mail Security
>> Area                : Security
>> Stream              : IETF
>> Verifying Party     : IESG
>>
> 
>

---

From: Sean Turner <[email-masked]>
Date: Mon, 19 Apr 2010 19:15:31 -0400

Sorry wrong link:

http://www.rfc-editor.org/errata_search.php?eid=1885

Sean Turner wrote:
>> This is a request (Errata Note for RFC 4490, EID=1884) to change the 
>> protocol, not an errata. Changes like this need to go through a new RFC.
>>
>>
>> -- 
>> From: Gregory Chudov [mailto:[email-masked]] Sent: Wednesday, 
>> September 23, 2009 6:57 PM
>> To: RFC Errata System
>> Cc: Леонтьев Сергей Ефимович; [email-masked]; 
>> [email-masked]; [email-masked]; [email-masked]; 
>> [email-masked]; [email-masked]
>>> "Using the GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94, and GOST 
>>> R 34.10-2001 Algorithms with Cryptographic Message Syntax (CMS)".
>>>
>>> Title               : Using the GOST 28147-89, GOST R 34.11-94, GOST 
>>> R 34.10-94, and GOST R 34.10-2001 Algorithms with Cryptographic 
>>> Message Syntax (CMS)