RE: [pkcs11] Proposal: CKM_DSA_FIPS_186_4

["Burns, Robert" <Robert.Burns@thalesesec.com>]

Oscar,

Having looked at this in a bit more detail, I think I have a way forward.  Basically, if you "squint at it" and ignore the issue surrounding supported key sizes (which I'll argue below), we could just update the text to indicate that DSA is FIPS 186 compatible and leave out the version information.

The reason being that the implementation of DSA is consistent between all the documents (even if the nomenclature has evolved somewhat).  And generally speaking, the later versions provide additional options (for prime generation), along with mandating certain key size restrictions, but do not "break" compatibility, (e.g. a FIPS 186-2 DSA implementation is compatible with a FIPS 186-4 standard in every way except supported key sizes below 1024 bits).  But given that PKCS #11 is really just an interface, I feel it is probably ok to describe functionality with respect to a standard without having to take on the key size restrictions of that standard.  It should be relatively easy to come up with language which indicates how the mechanism operates versus asserting compliance to a specific standard.

What do you think -- does anyone else have any strong opinions (heck, even weak ones?) either way?

Thanks,

Bob

P.S. Here are some 'back of the napkin' notes about DSA in the standards:

In 186-2, -3, and -4 -- the DSA algorithms are all compatible (as you'd expect).

If we concern ourselves about supported key sizes, then we have to worry about the following:

In 186-2, the supported bit lengths of the various attributes are:

    L >= 512 and <= 1024 in 64 bit increments, N = 160

In 186-3/4, the supported bit lengths of the various attributes are:

    L = 1024, N = 160
    L = 2048, N = 224
    L = 2048, N = 256
    L = 3072, N = 256

For Keygen, they are compatible with the 186-2 standard only describing probabilistic prime identification, and requiring >= 50 rounds of M-R, whereas 186-3/4 only requires 40, or alternatively, less when combined with a Lucas test for primality.  Furthermore, there are additional options for prime generation (e.g. provably prime), etc.  So realistically, the 186-2 standard is more rigorous than the later ones with respect to required rounds of M-R.

> -----Original Message-----
> From: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org] On
> Behalf Of Burns, Robert
> Sent: Thursday, August 01, 2013 10:49 AM
> To: oscar.so@oracle.com; pkcs11@lists.oasis-open.org
> Subject: RE: [pkcs11] Proposal: CKM_DSA_FIPS_186_4
> 
> Oscar,
> 
> Thanks for picking up the FIPS 186-4 update.  Definitely worth while
> considering this for the most recent update, as it appears that 186-3 has
> come and gone since PKCS #11 2.20 without any P11 doc updates.
> 
> The previous versions of P11 referred to FIPS 186-2 throughout the
> document.  It was the definition of DSA (Section 4 of v2.20 spec), the basis
> for CKM_DSA, (Section 12.2.7), and CKM_DSA_SHA1 (Section 12.2.8).  So, we
> are in the current situation where the proposed OASIS spec references 186-2
> for DSA mechanisms (only), and has no updated references for 186-3, or now
> 186-4.
> 
> So it seems that the FIPS 186-4 release needs a bit more careful
> consideration for specification update rather than adding a new mechanisms.
> Specifically, how DSA itself is defined, whether or not the previous
> CKM_DSA*** mechanisms are compatible with 186-4, and how to handle it if
> they are not.
> 
> My recommendation is as follows:
> 
> 1) Update the DSA definition/reference to correspond to FIPS 186-4
> 2) Investigate the difference between how 186-2 and 186-4 defines and
> describes the DSA mechanisms.
> 3) For those mechanisms which are compatible, update the
> mechanism/parameter descriptions to indicate the versions of specification
> compatibility, (e.g. "based on the Digital Signature Algorithm defined in FIPS
> PUB 186-2 through FIPS PUB 186-4." -- or similar).
> 4) For those mechanisms which are NOT compatible, then we have to
> consider defining the legacy mechanisms as compatible with a specific
> version only, and then introduce new mechanism enumerations which match
> the latest specification.
> 
> By the by, FIPS 186-4 consists of primarily editorial and clarification updates so
> is largely (e.g. functionally) compatible with FIPS 186-3, for what it's worth.
> 
> I will respond with my analysis corresponding to #2 above, but would still like
> a second set of eyes on it to corroborate.
> 
> Thanks,
> 
> Bob
> 
> P.S. Your recommendation limits the magnitude of 'p' to 1024 bits, but FIPS
> 186-3/4 allow 'p' to be 1024, 2048, or 3072 -- it might also be important to note
> that the magnitude of 'N' (magnitude of q, x, and k -- the length of the input
> hash) can be 160, 224, or 256 -- so if we're thinking of having any sort of
> profile describing FIPS 186 compatibility, we should consider both the
> magnitude of 'p', as well as 'N'.
> 
> P.P.S. I happened to notice we're in the same situation for the SHA standard,
> FIPS 180-4 which replaced FIPS 180-3 -- and sometime in the near future will
> be replaced with FIPS 180-5 to cover SHA3 mechanisms.  Although, I suspect
> these should be easier to handle given they are directly compatible.
> 
> > -----Original Message-----
> > From: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org]
> > On Behalf Of Oscar K So Jr.
> > Sent: Wednesday, July 31, 2013 5:14 PM
> > To: pkcs11@lists.oasis-open.org
> > Subject: [pkcs11] Proposal: CKM_DSA_FIPS_186_4
> >
> > Proposal: CKM_DSA_FIPS_186_4
> >
> > FIPS-186-4 algorithms:
> > http://www.ofr.gov/OFRUpload/OFRData/2013-17396_PI.pdf
> >
> > This mechanism is equivalent to: CKM_DSA
> >
> > --
> >
> > Best,
> > Oscar
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-
> open.org/apps/org/workgroup/portal/my_workgroups.php