Re: Draft Report of 7 June TWG Meeting

["Don Johnson" <djohnson@certicom.com>]

Bill,

I only have one comment so I put it here.

Regarding compelling arguments, this seems to be in the eye of the beholder.
Some
will likely insist they want to keep using PKCS signatures until it is broken,
as PKCS encryption was.

X9.31 has the following security assurances that PKCS does not; taken together,
these are compelling for me:
1) X9.31 was developed in an open consensus-based environment, PKCS was not.
This meant that NSA oversaw the development of X9.31, this is not true for PKCS.
In this case, the NSA rep. wears an infosec hat, that is, their purpose is
clearly to ensure that the end result is not a hack job, as financial
transactions are clearly a critical infrastructure.  This assurance is very
important to me and also applies to DSA and ECDSA.
2) X9.31 totally prevents certain (rarely successful) types of attacks that PKCS
does not.  This was due to the possibility of repudiation if a rare weak RSA key
was involved in a dispute.  The consensus decision of X9F1 was to exclude these
rare weak cases in a deterministic fashion (rather than probabilistically) as
the cost was low, less than 5%.

Don Johnson





Bill Burr <william.burr@nist.gov> on 06/22/2000 01:10:43 PM

To:   Don Johnson/Certicom@Certicom
cc:   Multiple recipients of list <pki-twg@nist.gov>

Subject:  Re: Draft Report of 7 June TWG Meeting




Reply in-line

At 11:10 AM 6/22/00 -0400, Don Johnson wrote:
>Bill,
>
>I imbed my responses in your note and prefix with DBJ.
>Don Johnson
>
>
>
>
>
>Bill Burr <william.burr@nist.gov> on 06/22/2000 09:55:51 AM
>
>Please respond to william.burr@nist.gov
>
>To:   Multiple recipients of list <pki-twg@nist.gov>
>cc:    (bcc: Don Johnson/Certicom)
>
>Subject:  Re: Draft Report of 7 June TWG Meeting
>
>
>
>
>
>Dave and Don,
>
>I agree that depending on one method always has its dangers, be it X9.31 or
>PKCS #1.  But as Dave points out: "If the applications support multiple
>algorithms, then the FPKI profile can also meaningfully offer choice.   If
>they don't, it can't."  What I also know is that the mainstream IT industry
>doesn't necessarily jump to the tune of ANSI standards, ISO standards or
FIPS.
>
>DBJ: Of course.  But this also depends on who one listens to.  In Europe and
>Asia, ISO standards are very big.

Bigger than they are here perhaps.  We used to hear that Europe was leading
the way to OSI, and ISDN, as standardized in OSI and ITU standards.  But
the Internet standards blew the ISO OSI standards away nearly as much in
Europe and Asia as here.  And, in the US, NIST, DoD and much of the Federal
Government threw strong support behind OSI, but it still got blown away.
"Adopt ISDN as they are in Europe," we were told, "or the future will pass
you by."  ISDN sort of happened in Europe, and a little bit here, but who
cares, it's not the engine of modern communications, the Internet is.

So ISO standards carry more weight in Europe than here, but are the systems
and software run in Europe very different than here?  Are there browsers
and websites in Europe that use ISO versions of RSA?  Have European CAs
embraced the ISO RSA format in their certificates?

>Dave is probably right, an opportunity is coming with 2048 RSA, SHA-256
>2048 bit DSA, etc.  But, is that also the time to move to the PSS
>signatures?  Does it make any sense to try to force a change to X9.31 until
>these are ready?
>
>I don't understand how anybody made the case, with a straight face or
>otherwise, for the two padding schemes we now have.  If I had to choose
>between consistency with some ISO standard somewhere, and consistency with
>what the industry was actually doing (e.g. PKCS #1), and there were no
>particular security or technical distinctions to the padding schemes, I'd
>go with the industry practice every single time.  A standard that does not
>respect current commercial investment is usually doomed to obscurity.
>
>DBJ: Do not forget that the padding is not the only difference, the key
>generation requirements are also different.

Yes key generation is different, but that itself need not confound
interoperability.  There is, of course a security argument here, where
there isn't apparently one with the padding.

>
>DBJ: This seems to be a chicken and egg argument to seek the lowest common
>denominator.  With most IT solutions, this can be a fine pragmatic approach.
>Witness C language, Relational DB language, Internet protocols, and a host of
>others.  My point is simply that with crypto there is a curve ball.
Besides all
>the normal functional and performance requirements, there is a requirement of
>security, which is a denial of capability for an adversary to exploit.  How
>strong does a safe need to be if there are no safecrackers?  So the
appearance
>of security can lead to a false sense of security.

But overall cryptography is only one element of security, and rarely, even
when  comparatively weak, the weakest element.  You may disparage the IETF
as OK to design protocols but not cryptography, but if the protocols are
bad we won't have security, whatever the cryptography.  The IETF really
doesn't much want to design crypto, they just want to make the best use of
what's out there.

Building a large scale interoperable PKI is hard.  Anything that confounds
or delays building that PKI delays the very real security benefit the PKI
would provide.  It tends to look to me like trying to force a conversion
from PKCS #1 to X9.31 in the near term just makes creating that PKI more
difficult without a compelling security advantage.

>
>In one way or another I've been in the voluntary standards business now for
>more than two decades.  I've chaired some fairly major "ANSI" computer
>industry standards committees.  I don't want to get too much on my soap box
>here, but standards exist to serve users and the industry, we don't exist
>to serve them.  The industry depends on many defacto standards of dubious
>pedigree.  As far as I can tell, PKCS #1 met a genuine industry need pretty
>well, it is an established fact on the ground, so to speak, and no amount
>of talk about consensus processes, proprietary origins, or whatever, make a
>bean's worth of difference to most IT companies or users, who just want to
>get on and use the technology.  Cryptography is mainstream IT technology
>today, and it has to play the same game as other standards.
>
>To be clear, I'm not proposing to outlaw or disallow X9.31 for Federal use.
> I do want to consider continuing to use PKCS #1, which I think people will
>probably do anyhow, until there is a better time and reason to convert to
>something that everybody can accept.  I want figure out what that
>convergence should be.
>
>DBJ: I thought NIST HAD decided that, after much internal discussion.  First
>NIST said to use an ANSI X9 standard, and PKCS users complained.  So NIST
>allowed a crossover grace period.  Now PKCS users seem to be compaining
again.
>My point is that NIST should take the high road instead of the low road.
Yes,
>the EASY thing may be to just roll over and say there was nothing NIST
could do,
>but this is simply not true.  The federal market is a big market.  NIST
should
>be a leader and not just a rubber stamper.

FIPS or not, NIST has a limited practical ability to dictate to government
IT users.  Although a big customer, the government is only a relatively
small part of the overall IT market.  When cryptography was a relatively
specialized area used occasionally by civilian government agencies and
financial institutions NIST had a lot of leverage. In a world where
cryptography is ubiquitous in IT systems, and the government is only 5% to
10% of that market at most, we don't have a huge amount of leverage.  I
want NIST to use its leverage, when we do, where there are compelling
reasons to do so.

NIST was not able to persuade the world, or the government, to adopt DSA
rather than RSA DSA, which was different from, but not markedly better than
RSA.  This despite the royalty advantages of DSA.  NIST has had more luck
with SHA-1, because it is markedly better than earlier hashes.  There
really is a big, quantifiable security advantage.  My impression is that
the world will embrace AES.

The problem with X9.31 is only that it was probably too late and isn't a
big enough improvement.  If X9 had got it out 2 or 3 years earlier, then
perhaps things would be different; there wouldn't be such extensive,
entrenched use of PKCS #1. If there were a huge security advantage, then it
would make sense to change.  But should NIST or the Federal PKI ask people
to change now, when we're soon going to be telling them that, if they're
using AES, they should also be using 2048 bit RSA or DH, or 320 bit EC, and
256-bit hashes, and change again?  Now I think we've really got a
compelling security reason to go a bigger modulus, and a bigger hash. When
we do that, perhaps it's also the time to ask them to change the padding on
their signatures and perhaps demand strong primes.

At any rate, I"M OPEN TO ANY ARGUMENT THAT THERE IS A COMPELLING SECURITY
ADVANTAGE TO X9.31, IF SOMEBODY WANTS TO MAKE ONE, OR ANY EVIDENCE THAT THE
INDUSTRY IS IN FACT EMBRACING X9.31.

>Regards,
>
>Bill Burr
>
>
>
>
>At 05:36 PM 6/21/00 -0400, David P. Kemp wrote:
>>
>>
>>> From: "Don Johnson" <djohnson@certicom.com>
>>>
>>> DBJ: My answer to this is that overdependence on one method is INHERENTLY
>>> dangerous.  The system should be designed from the get-go to allow for
>>multiple
>>> solutions.
>>
>>I agree with this, of course.  The problem is that "the system" used by
>>most of the Federal Govt is not designed by the Govt.  If the applications
>>support multiple algorithms, then the FPKI profile can also meaningfully
>>offer choice.   If they don't, it can't.
>>
>>Pragmatically speaking, an opportunity is coming for X9.31.  There is
>>currently no algorithmID for 2048 bit RSA signatures.  When SHA-2
>>is available, a sha2WithRSASignature can be defined with X9.31 padding,
>>and developers who choose to support the longer key will get the key
>>generation and padding methods along with it.
>>
>>Bill, do you think anyone will make a case (with a straight face) for
>>defining two different padding formats for SHA-2 RSA signatures?
>>
>>
>>
>>
>>
>Regards,
>
>Bill Burr
>
>
>
>
>
>
>
>
>
Regards,

Bill Burr