On 5/23/2013 6:34 PM, Dr. Stephen Henson wrote:
On Thu, May 23, 2013, Phillip Hellewell wrote:
Attached is a really old (circa 2000) file called ieexcep.cat. Windows
recognizes it as a Security Catalog Information. It is a weird file
because it is like a mix of a cert chain (.p7b) and a signature (.p7s).
The d2i_PKCS7_bio() succeeds on it, but d2i_CMS_bio() does not. This is
the only file I have that PKCS7 will parse but not CMS.
Is there a specific reason why CMS cannot / should not work on this file?
Is it safe to say that although it is valid PKCS7, it is not valid CMS, or
is it not really a valid PKCS7 either?
The reason I bring all this up is I was hoping to refactor all my code to
use CMS instead of PKCS7; I would rather not have to do both (i.e., try
CMS, then try PKCS7 if CMS doesn't work).
This an incompatibility between CMS and PKCS#7 where the encapsulated type is
not data. Under PKCS#7 the type appears in encoded form, under CMS the
encoding is embedded in the content octets of an OCTET STRING.
This is very rarely encountered in practice. The only time I've ever come
across it is in Windows authenticode signatures.
While the CMS documents from IETF no longer considers this non-IETF use
case of the general PKCS#7 structures, it would by really nice if the
OpenSSL API did not duplicate this use case restriction in its APIs
and command line tools. Remember that most IETF documents focus on
the subset of the standards used with the PKIX profile, which never was
the only profile in existence.
While it is nice that the CMS APIs and tools default to the IETF
style contents is always type data, it would be really nice if this
was just a default, thus removing the need to juggle two gratuitously
incompatible APIs.
If there is no place in the current CMS functions to pass/receive the
extra parameters needed for non-IETF uses, it would be nice to define
some extended entrypoints that do take the extra arguments, these could
then form a common backend for the old CMS and PKCS7 APIs and for
anything new added in the future.
Some other arguments that would be nice to add to such generalized
functions:
- As of verification timestamp (not constrained to a 32 bit time_t or
to an integral number of seconds)
- Already computed hashes argument for signatures in streaming
applications that process and discard the signed contents from memory
before loading the signature bytes (like verifying a signed e-mail with
a 200MB attachment while using less than 10MB RAM).
- Contersignature verification as a separate step (allowing the
application to to modify later parameters according to the verified
countersignature).
- Allow data type option bit when verifying either kind of
signature.
- Verifying separate SignerInfos separately.
- Required key usage(s) parameter for both signing and verification.
- Arbitrary authenticated attributes when signing.
- Combining multiple SignerInfos into a single SignedData result.
- Adding and removing certificates and unauthenticated attributes in
an existing SignedData object.
- Arbitrary time stamp when signing (not constrained to a 32 bit time_t
or to an integral number of seconds)
- Anything else permitted by any edition of the PKCS#7 or CMS
specifications, regardless of presence in latest edition.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
