I have two comments related to the discussion of the above mentioned
For the id-cek-maxDecrypts attribute, since it is an unprotected
attribute, there is no protection against anyone modifying its
value. It therefore seems as if it could be an advantage to restrain
possible values already in the specification. At the very least
I suggest it to be specified as INTEGER (1..MAX), so that recipients
won't be confused by negative values. <MAX> could be replaced by
something less, of course.
For the X9.63 KDF, I support using it instead of the PKCS #5 KDF,
since it is intended for cases like this and PKCS #5 really is
intended for something else. But for the algorithm itself, I think it
would be better if the algorithm actually was included in the
document, especially since it is quite short/compact.