RE: SSH non-compliance with FIPS 186

[James Blaisdell <JBlaisdell%mocana.com@localhost>]

Hi Niels,

Sorry for my short reply.  I stumbled across DSA2 while starting new round of FIPS 140-2 testing.  It's not a requirement for FIPS, but simply yet another algorithm which is FIPS-able.  The FIPS documentation refers to it as DSA2, which sounds good to me, although web searches revealed almost nothing, but the documentation did refer to NIST 186-3.  

Your idea on unique name space is great, and I wish this was practiced more especially for drafts.  I might be up for implementing this in a couple of weeks, if you want to do any interop testing.  

Thanks,

James

-----Original Message-----
From: Niels Möller [mailto:nisse%lysator.liu.se@localhost] 
Sent: Monday, September 21, 2009 10:23 AM
To: James Blaisdell
Cc: Peter Gutmann; ietf-ssh%NetBSD.org@localhost
Subject: Re: SSH non-compliance with FIPS 186

James Blaisdell <JBlaisdell%mocana.com@localhost> writes:

> I started looking into this as well.  FIPS 140-2 refers to this as
> "DSA2,"

Where, more precisely? FIPS 140-2 "Security Requirements for
Cryptographic Modules" doesn't seem to mention dsa at all. Is it in one
of the annexes?

> I believe a new draft/RFC is required for ssh-dsa2-*
> (ssh-dsa2-160/224/256/385/512) algorithms.

For me, the first step is to find a *complete* and authoritative
specification for these dsa variants, preferably including test
vectors. I'd like to have the general signature algorithm done
correctly, before worrying too much about how to use it in ssh.

For ssh, initially, I could implement it under a name like
dsa-sha256%lysator.liu.se@localhost, next we'd have to agree on the details, and
then arrange to allocate an official name and document it as an
informational RFC, or something like that.

Are there any other Internet standards that use these updated DSA
variants?

/Niels