Re: PKCS7_decrypt vs RSA OAEP padding

[Eliot Lear]

Hi Michal,

CMS has limited backward compatibility with PKCS#7.  This is discussed 
in RFC 5652 , and 
includes some suggestions as to how to some issues that might crop up.   
At least the old draft of SCEP very specifically does NOT specify CMS, 
but that might not have stopped someone from using it.  These docs tend 
to be quite sloppy.  For example, I know one that uses both PEM and DER 
encodings on the wire.  Drives me batty.


For enrolment this is particularly embarrassing, considering its 
sensitivity.  As a sysadmin, you might try wrapping this stuff in PHP 
and just trying both the pkcs_decrypt and cms_decrypt calls and seeing 
if either work.


Eliot

On 12.04.21 14:13, Michal Moravec wrote:

Hello,

I am a system administrator trying to integrate two pieces of software 
using the SCEP protocol (more on that later in the More Context section) .
Integration was working but one side (SaaS product) changed the 
algorithms it uses for signing and encryption within the PKCS7 message.
After that I am unable to decrypt the PKCS7 messages on my end and get 
the error: "ERROR 139701710696896:error:06065064:digital envelope 
routines:EVP_DecryptFinal_ex:bad decrypt:../crypto/evp/evp_enc.c:597:

message_static_functions.c:221: decryption failed"

From my current state of investigation it looks highly likely there is 
a problem with PKCS7_decrypt method which might be unable decrypt the 
PKCS7/CMS payload if the RSA is used together with OAEP padding.


1. What is a diffrences between pkcs7 
https://github.com/openssl/openssl/tree/681618cfc18b4f01f2c07e823308d30f6f47504b/crypto/pkcs7 
 and 
CMS 
https://github.com/openssl/openssl/tree/681618cfc18b4f01f2c07e823308d30f6f47504b/crypto/cms 
 implementations?


If I understand correctly CMS is just newer name for PKCS7 adopted by 
newer RFCs?

Do these two implementations overlap?
Or are there some kind of major diffrence like PKCS7 module being 
there for compatibility with older code and CMS is basically 
replacement to use for the future?


2. Is PKCS7_decrypt method in 
https://github.com/openssl/openssl/blob/681618cfc18b4f01f2c07e823308d30f6f47504b/crypto/pkcs7/pk7_smime.c 
 capable 
of decrypting the PKCS7 payload whebf OAEP padding is used together 
with RSA to encrypt it? If it is indeed not capable of doing that 
would it be a bug or desired behavior?


If found a few pointers:

- 
https://stackoverflow.com/questions/56941480/how-to-set-padding-oaep-for-pkcs7-decrypt-function-using-openssl 
 <- 
Developer is unable to use PKCS7_decrypt with RSA OAEP and forced to 
switch to CMS_decrypt method.
- 
https://stackoverflow.com/questions/34304570/how-to-resolve-the-evp-decryptfinal-ex-bad-decrypt-during-file-decryption 
 <- 
Padding being a source problem of EVP_DecryptFinal_ex:bad decrypt 
error message.


3. How to replace PKCS7_decrypt method CMS_decrypt as easily as possible?

I have no hard proof of the PKCS7_decrypt being the culprit here so I 
started working on simple C program to reproduce the issue.
Problem is my C skills are very rusty and I have no experience working 
with OpenSSL C library.


int PKCS7_decrypt(PKCS7 *p7,  EVP_PKEY *pkey, X509 *cert, BIO *data, 
             int flags);
int CMS_decrypt    (CMS_ContentInfo *cms, EVP_PKEY *pkey, X509 *cert, 
BIO *dcont, BIO *out, unsigned int flags);


Methods are very similiar but input data format it different. It there 
an easyway to convert PKCS7 struct into CMS_ContentInfo struct?


Original usage of PKCS7_decrypt here -> 
https://github.com/openxpki/libscep/blob/4067eae283ce0b3025d414e9d3b6af30def8c093/src/message_static_functions.c 
 




# More Context

My goal is to obtain signed client certificate using the SCEP protocol.

SCEP server: OpenXPKI https://github.com/openxpki/openxpki 
 (Perl) with libscep 
https://github.com/openxpki/libscep 
 library (C). libscep used the 
OpenSSL.
SCEP client: VMware Workspace ONE UEM SaaS (WSO). Black box. From the 
error codes client produces I strongly suspect they use OpenSSL within 
.Net code.


Originally WSO SCEP client used these three algorithms for PKCS7 
operation: SHA-1, RSA (PKCS 1.5 padding or no padding <- can't tell 
which) and 3DES-CBC.
They made some sort of change (unannouced) and since 

Re: Goodbye

[Eliot Lear]

Can we please put the knives a way?  Rich has given a lot to this
community.  As an openssl user, I'd rather the conversation moved along.





signature.asc
Description: OpenPGP digital signature

PHP interface and CMS_STREAM flag for cms_encrypt()/cms_sign()

[Eliot Lear]

Hi there,

I am now just tidying up the PHP interface for CMS, which is an analog
to the PKCS#7 interface.  As all the inputs are file names, one wonders
if there is any possibility of the CMS_STREAM flag ever being a
reasonable option.  If it is not, it will simplify the code.

Eliot




signature.asc
Description: OpenPGP digital signature

some testers needed for PHP CMS calls

[Eliot Lear]

Hi everyone,

If anyone is interested, I have attempted to port the OpenSSL CMS
routines into PHP.  The code is available in a PR at
https://github.com/php/php-src/pull/5251.  Comments/reviews most welcome.

Eliot





signature.asc
Description: OpenPGP digital signature

Re: [openssl-users] in the department of "ain't no perfect"

[Eliot Lear]

On 17.01.19 21:20, Hubert Kario wrote:
> then I'd say that showing the date from within the signature will be more 
> confusing than helpful to the administrator

Nevermind the date, you can't even get the expiration error
programmatically.




signature.asc
Description: OpenPGP digital signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] in the department of "ain't no perfect"

[Eliot Lear]

On 17.01.19 17:29, Hubert Kario wrote:
>
> alternatively, you can save all the certificates and revocation data, bind it 
> to the original signature using a timestamp from a TSA and store that (that's 
> necessary if you want to be able to prove to some 3rd party that you received 
> a correctly signed document/message at that time)
>
> but that is very close to reimplementing CAdES, or related standards, and is 
> far from simple (for one, requires adding, regularly, new timestamps to 
> extend 
> validity of the original signature and subsequent timestamps)
>

Right.  There are a lot of trust challenges around the timestamp. 
Because there are multiple non-cooperating entities involved, the signer
is not in a position to predict who the recipients will trust, and the
recipients may be retrieving the information later.  This is not a
simple matter.

What's more, we're not in a position to provide meaningful programmatic
diagnostic info in this case because CMS is calling X.509 codes, and so
ERR_get_err has a little issue when multiple libraries are in play.  And
while nobody likes to hear, “I'll just bypass this one thing”, as a
matter of practicality we want to provide the application user (in this
case an administrator) a choice of what to do with as much information
as possible.

Eliot






signature.asc
Description: OpenPGP digital signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] in the department of "ain't no perfect"

[Eliot Lear]

Hi Hubert

On 16.01.19 12:27, Hubert Kario wrote:
> For maintaining signatures that need to be valid long into the future 
> standards like CAdES should be used. They keep time of signing in timestamps 
> signed by trusted time-stamping authorities, along with the rest of 
> revocation 
> data necessary to verify the original signature.


Understood.  At this point in the maturity cycle of the technology,
we're just not there yet.  My choices are, have people ignore invalid
signatures in their entirety or provide something more nuanced for now.

Eliot




signature.asc
Description: OpenPGP digital signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] in the department of "ain't no perfect"

[Eliot Lear]

Hi Rich and thanks for your response.  Please see below.

On 15.01.19 21:12, Salz, Rich via openssl-users wrote:
>> like a way to extract the signature date from a CMS structure.  With all the 
>> opaque structs that have been introduced in the last few releases, it's not 
>> clear to me how to do that.  Any examples or guidance (other than don't do 
>> that)?
>
> Can you list which fields you need and open an issue on github?  Yes, this 
> would be a bug-fix because "going opaque" made some things not possible.


Wilco.  For the benefit of others, I'm the verifier, and at least at the
moment, no externally signed timestamp is available.  So what I want
access to is the id-signingTime attribute from the CMS structure,
preferably parsed neatly into a time_t akin to
X509_VERIFY_PARAM_get_time, but presumably coming  from CMS_ContentInfo.

I don't know if this was was ever externalized, Rich, but I'll open the
Github issue.  I recognize that examining this value is not without
risks in the general case.

Eliot

ps: sorry for the artsy subject line.






signature.asc
Description: OpenPGP digital signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] in the department of "ain't no perfect"

[Eliot Lear]

I realize things haven't been made easy to do this on purpose, and that
there's even a comment in one of the man pages to that effect, but here
goes...

I have an application that requires long-lived signatures, perhaps long
past the point where the signer's cert has expired.  I'd like a way to
extract the signature date from a CMS structure.  With all the opaque
structs that have been introduced in the last few releases, it's not
clear to me how to do that.  Any examples or guidance (other than don't
do that)?

TIA

Eliot




signature.asc
Description: OpenPGP digital signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users