Subject: [saag] Fwd: NIST releases Draft FIPS 180-4, Secure Hash Standard (SHS)

From: Sean Turner <[email-masked]>
Date: Sun, 13 Feb 2011 10:35:32 -0500

-------- Original Message --------
Subject: 	NIST releases Draft FIPS 180-4, Secure Hash Standard (SHS)
Date: 	Fri, 11 Feb 2011 12:10:20 -0500

NIST announces the release of Draft Federal Information Processing
Standard (FIPS) 180-4, Secure Hash Standard (SHS).
<http://csrc.nist.gov/publications/drafts/fips180-4/Draft-FIPS180-4_Feb2011.pdf>Draft 

FIPS 180-4 is a proposed revision of FIPS 180-3. Draft FIPS 180-4 adds a
general procedure for creating an initialization hash value and two
additional secure hash algorithms: SHA-512/224 and SHA-512/256, and
removes a requirement that padding must be done before hash computation
begins. SHA-512/224 and SHA-512/256 may be more efficient alternatives
to SHA-224 and SHA-256, respectively, on platforms that are optimized
for 64-bit operations. Removing the restriction on the padding operation
in the secure hash algorithms will potentially create more flexibility
and efficiency in implementing the secure hash algorithms in many
computer network applications. The Federal Register Notice (FRN) of this
publication is located _here
<http://csrc.nist.gov/publications/drafts/fips180-4/FRN_Draft-FIPS180-4.pdf>_. 

Examples of the implementation of the secure hash algorithms SHA-1,
SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 and SHA-512/256, can be
found at http://www.nist.gov/CryptoToolkitExamples.

---

From: Dan Brown <[email-masked]>
Date: Sun, 13 Feb 2011 14:14:05 -0500

Would IETF, especially PKIX and CMS, like new OIDs for algorithms that might use the new hashes, such as ECDSA?

----- Original Message -----
From: Sean Turner [mailto:[email-masked]]
Sent: Sunday, February 13, 2011 10:35 AM
To: [email-masked] <[email-masked]>
Subject: [saag] Fwd: NIST releases Draft FIPS 180-4,	Secure Hash Standard (SHS)

-------- Original Message --------
Subject: 	NIST releases Draft FIPS 180-4, Secure Hash Standard (SHS)
Date: 	Fri, 11 Feb 2011 12:10:20 -0500

_______________________________________________
saag mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/saag

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Jon Callas <[email-masked]>
Date: Mon, 14 Feb 2011 12:24:36 -0800

> Would IETF, especially PKIX and CMS, like new OIDs for algorithms that might use the new hashes, such as ECDSA?

Is there a reason that the OIDs supplied here:

<http://csrc.nist.gov/groups/ST/crypto_apps_infra/csor/algorithms.html>

are insufficient? It's what we've been using before, with just a new 5 and 6 for the two new hashes.

	JOn

---

From: Dan Brown <[email-masked]>
Date: Mon, 14 Feb 2011 16:12:22 -0500

> -----Original Message-----
> From: Jon Callas [mailto:[email-masked]]
> Sent: Monday, February 14, 2011 3:25 PM
> 
> > Would IETF, especially PKIX and CMS, like new OIDs for algorithms
> that might use the new hashes, such as ECDSA?
> 

PKIX, RFC 5480, used individual OIDs for ecdsa-with-SHA1, ecdsa-with-SHA256, etc, which are defined under the ANSI X9.62 arc.  

ANSI X9.62 also has an OID ECDSA-with-Specified, allowing the hash to specified in the parameters field of an algorithm identifier, which would allow for the NIST hash OIDs to be used easily, albeit at the expense of two OIDs instead of one.

Also, some RFCs, e.g. 4055 Section 2.1, might need minor updating to allow use of the new NIST OIDs.