Re: CMP and SCEP problem

Juraj Michalak <juraj.michalak@...> writes:

>My CMP error with extended error info is:
>error: crytSetAttribute(CRYPT_SESSINFO_ACTIVE) = -20
>INFO: Can't confirm certificate issue using algorithm 205
>
>205 is SHA256 (according to cryptlib.h). So I switched to new CA in EJBCA
>with: ca.signaturealgorithm=SHA1WithRSA

CMP hard-codes various assumptions into the protocol in bizarre ways... in
fact this particular one is so complicated that it's not even easy to explain
(the RFC authors must have come up with this one as the result of losing a
bet), but the end result is that if you don't use MD5 or SHA-1 then odd things
happen (or at least if you use it with two different implementations then odd
things happen).

>I have also tcpdump "cmp_dump.cap" of that communication and in last response
>(confirm) from my cryptlib client (generate_cmp.c) is some BER encoding Error
>- in PBM. Could it cause that EJBCA above failure?

Could you send me the DER-encoded object?  Or alternatively the dumpasn1
output for it?

>Why SHA256 is problem? Is it bed to provide stronger security (SHA1 has also
>some possible weakness...)?

See above, with two different implementations both sides can make different
guesses at what the standard is expecting.  For this reason cryptlib
explicitly checks for the two algorithms that were in use at the time, MD5 and
SHA-1, because for those at least the different implementers could agree on
what to do.  I can add an attempt at SHA-256 support, but it's not guaranteed
that it'll interoperate.

>When I was implementing my S/MIME enveloping I made notice to ask you, how to
>use SHA384 or SHA512?

These aren't enabled because they require a 64-bit CPU (although in theory you
can do it on a 32-bit system where the compiler has long long support), and
that's too much of a portability nightmare to enable.

>So I decided to try SCEP. I have created new CA (router) in EJBCA with "Key
>encipherment" key usage - according to EJBCA docs. Cryptlib's client is
>written in "generate_scep.c". This time there is no communication because
>cryptlib encounters error earlier:
>
>error: crytSetAttribute(CRYPT_SESSINFO_ACTIVE) = -15 (what is CRYPT_ERROR_FAILED)
>
>session/scep_cli.c:168 "Couldn't create SCEP request signing attributes"

Hmm, it looks like you used SHA-256 here as well, SCEP had an even worse
problem in that it hardcoded MD5 as the only allowed algorithm.  There is a
way to kludge in other algorithms (by sending an HTTP request containing an
argument other than a standard SCEP request, which is supposed to return a
text page containing information about what new algorithms are supported) but
the last time I tried it it wasn't supported very well (there are lots of old,
mininal SCEP implementations built into routers and the like) and lead to
strange failures if you use it.  In general it seems safe to assume SHA-1
(which is what cryptlib does), but trying to push it beyond that is kind of
risky.

Peter.

_______________________________________________
Cryptlib mailing list
Cryptlib@... via Mail: cryptlib-request@...
Archive: ftp://ftp.franken.de/pub/crypt/cryptlib/archives/
http://news.gmane.org/gmane.comp.encryption.cryptlib
Posts from non-subscribed addresses are blocked to prevent spam, please
subscribe in order to post messages.