setting eContentType for CMS messages without CMS_PARTIAL

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



A major way in which PKCS7 and CMS signed artifacts differ is that
the CMS artifacts include a content-type.

RFC5652 has a decision tree to decide what version of SignedData
structure to produce.  The presence of a non-"id-data" content-type
is among the decision tree, and so I understand why it can't be set after the
signature (besides, the content-type is within the signature!).

I think it's probably too complex that the only way to set the content-type
is by doing the CMS_PARTIAL work.   I think that CMS_sign() and CMS_encrypt()
ought to take a eContentType OID: but ABI issues would mean a new call.

I had to read the source code to understand the difference between
CMS_get0_type() and CMS_get0_eContentType().

I can see how one refers to the cms->contentType, and the other refers to
the same thing "as received", in the structure (RFC5652's
EncapsulatedContentInfo).   I'm not sure if there is intended to be
functional or API contract differences between the two??

I was also mystified about get0_content(), until I realized that it did not
have the word "type" in it.  I've sent some pull requests, one of which
suggests that you can't call get0_content() until CMS_final() has been called
on outgoing objects.

CMS_get0_content() returns a pointer to a pointer, and it says down at the
bottom that it can be used to modify the content.  It's clear that a
receiver (verifier/decrypter) can mutate this content as part of it's
processing: saves memory for a buffer, a copy, and a potential buffer
overflow, I guess.

It's unclear to me of what use this is for outgoing content. Clearly
one could allocate an ASN1_OCTET_STRING big enough for constructing content,
or point it at a buffer already in use.  Clearly that's nonsense if
CMS_PARTIAL is not used, and I wonder if CMS_get0_content() should return
NULL if the signature is already done.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@xxxxxxxxxxxx  http://www.sandelman.ca/        |   ruby on rails    [





Attachment: signature.asc
Description: PGP signature

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux