Romascanu, Dan (Dan) wrote:
------------------------------------------------------------------------
*From:* ops-dir-bounces(_at_)ietf(_dot_)org
[mailto:ops-dir-bounces(_at_)ietf(_dot_)org]
*On Behalf Of *Bernard Aboba
*Sent:* Monday, May 25, 2009 12:04 AM
*To:* ops-dir(_at_)ietf(_dot_)org
*Subject:* [OPS-DIR] review of draft-ietf-smime-rfc3287bis-07.txt
This is a review of "Use of Elliptic Curve Cryptography (ECC) Algorithms
in Cryptographic Message Syntax (CMS)" draft-ietf-smime-3278bis-07.txt for
operations and management considerations.
draft-ietf-smime-3278bis represents an update to RFC 3278. Details of the changes
from RFC 3278 are provided within Appendix B.
Aside from clarifications to RFC 3278 and an updated and enhanced
Security Considerations section, which are likely to enhance
interoperability and operational security, the most important
changes include:
- Abstract: The basis of the document was changed to refer to NIST
FIPS 186-3 and SP800-56A. However, to maintain backwards
compatibility the Key Derivation Function from ANSI/SEC1 is
retained.
- Section 2.1.1: The permitted digest algorithms were expanded from
SHA-1 to SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512.
- Section 9: Replaced text, which was a summary paragraph, with an
updated security considerations section. Paragraph referring to
definitions of SHA-224, SHA-256, SHA-384, and SHA-512 is
deleted. ms,
In terms of support for new algorithms, the document attempts to bring
RFC 3278 up to date. From an operational perspective, introducing new
algorithms is challenging, due to the potential for decreased performance
and interoperability issues, but RFC 3278bis takes care to preserve
backward compatibility.
From an operational perspective, my major concern would be whether
specification of additional digest algorithms could be expected once
the new NIST digest algorithm is chosen in the not-too-distant future.
While it's hard to fault the authors for not providing guidance relating to
a not-yet-chosen algorithm, much of motivation for deployment of
algorithms such as SHA-256 relates to a desire to address weaknesses
found in SHA-1. Given that it is possible that NIST will choose
algorithm(s)
from another family, one wonders whether the additional digest algorithms
specified in this document will end up being more than a temporary
measure.
Dan,
I tend to agree with what Paul wrote. I'd only add that the time line
supplied by NIST (http://csrc.nist.gov/groups/ST/hash/timeline.html)
suggests that NIST won't actually pick a "winner" until 4th quarter of
2012. I'd like to have something at least standardized prior to that.
spt