ietf-smime
[Top] [All Lists]

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

2010-04-19 18:15:40
Sorry wrong link:

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

Sean Turner wrote:
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:gchudov(_at_)gmail(_dot_)com] Sent: Wednesday, September 23, 2009 6:57 PM
To: RFC Errata System
Cc: Леонтьев Сергей Ефимович; tim(_dot_)polk(_at_)nist(_dot_)gov; pasi(_dot_)eronen(_at_)nokia(_dot_)com; turners(_at_)ieca(_dot_)com; blaker(_at_)gmail(_dot_)com; ah(_at_)tr-sys(_dot_)de; smime(_at_)ietf(_dot_)org
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 <rfc-editor(_at_)rfc-editor(_dot_)org>:
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 <ah(_at_)TR-Sys(_dot_)de>

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




_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime

<Prev in Thread] Current Thread [Next in Thread>