Juraj Michalak <
juraj.michalak@...> writes:
>Is this correct in CMP Peter? Or is it a mistake in Jurajs code? My
>interpretation of the standard is that the PBMParameters should be there.
The parameter part is actually optional, with absent parameters meaning "same
as last time". This was one of the (many) problems discovered during the
(non-)interop tests, you can in theory use completely different MAC parameters
for every message, which it turned out almost no-one could actually handle
correctly (you could also have fun with the values, for example in one case I
wanted to see what would happen if I sent a very high iteration count and a
large salt. The server stopped responding after that :-).
Anyway, the de facto solution was to omit the parameters to indicate that the
MAC keying and whatnot was unchanged. If you look at writeMacInfo() in
session/cmp_wr.c there's a flag 'parametersSent' that controls this, you can
comment that out and cryptlib will always send the full set of parameters,
although now you have to parse them all in order to find out that nothing's
changed. I'll fix this for the next release.
There's also a large pile of complex logic in readMacInfo() in
session/cmp_rd.c to handle all the different interpretations of the spec for
this. For every unusual-case check in there there'll be at least one
implementation out there that triggers it (or did at the time, I don't know
how many of those implementations are still around).
Incidentally (for Tomas, CC'd in to this reply), one reason why cryptlib sends
out a GenMsg with a cryptlib magic ID in it is that it then knows that the
other side will adopt certain common-sense measures, for example it'll always
send an ESSCertID to identify certs rather than using an X.500 DN, which can't
actually usefully identify a certificate and which lead to some interesting
failures during the (non-)interop. If you're interested I can send you a list
of things that the magic ID ensures, e.g. keep the MAC parameters constant
across messages, send an ESSCertID to identify certs, that sort of thing.
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.cryptlibPosts from non-subscribed addresses are blocked to prevent spam, please
subscribe in order to post messages.