[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FW: [OPS-DIR] review of draft-ietf-smime-rfc3287bis-07.txt

Romascanu, Dan (Dan) wrote:
    *From:* ops-dir-bounces@xxxxxxxx [mailto:ops-dir-bounces@xxxxxxxx]
    *On Behalf Of *Bernard Aboba
    *Sent:* Monday, May 25, 2009 12:04 AM
    *To:* ops-dir@xxxxxxxx
    *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


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.