Re: PKCS#7 Signing: How to get repeatable output for signing the same data

[Michal Suchánek]

On Mon, Oct 17, 2022 at 10:28:45AM +0200, Tim Meusel wrote:
> Hi!
> I maintain a Ruby script that does PKCS#7 signing and afterwards some
> enryption with AES-128-CFB. A trimmed down version:
> 
> certpath = '/tmp/cert.pem'
> keypath = '/tmp/key/pem'
> data = 'teststring'
> key  = OpenSSL::PKey::RSA.new(File.read(keypath), '1234')
> cert = OpenSSL::X509::Certificate.new(File.read(certpath))
> signed = OpenSSL::PKCS7::sign(cert, key, data, [], OpenSSL::PKCS7::BINARY)
> cipher = OpenSSL::Cipher::new("AES-128-CFB")
> iv_len = cipher.iv_len
> key_len = cipher.key_len
> fqdn_rand = Digest::SHA256.hexdigest([destination,data.length].join(':'))
> iv_seed, key_seed = fqdn_rand.partition(/.{32}/)[1,2]
> iv = iv_seed.unpack('a2'*key_len).map{|x| x.hex}.pack('c'*key_len)
> key = key_seed.unpack('a2'*key_len).map{|x| x.hex}.pack('c'*key_len)
> cipher.encrypt
> cipher.iv=(iv)
> cipher.key=(key)
> OpenSSL::PKCS7::encrypt([target], signed.to_der, cipher,
> OpenSSL::PKCS7::BINARY).to_s
> 
> I pulled the AES encryption into a testscript and that's indeed repeatable
> (script at the end of the email). I did some tests and noticed that the
> initial signing doesn't produce repeatable output:
> 
> signed = OpenSSL::PKCS7::sign(cert, key, data, [], OpenSSL::PKCS7::BINARY)
> 
> I did some googling and that told me the signing date/timestamp is part of
> the output, which would explain why it doesn't produce the same output when
> I run it twice. Now to my actual questions:
> * Is the different output caused by a changing signing time and/or something
> else?
> * Do you know if I can pass the signingtime to manipulate it?
> 
> I know that this isn't a Ruby mailinglist, but the ruby-openssl bindings and
> the documentation are generated from the C code and were not very helpful
> (for people not knowing C/not knowing a lot about OpenSSL/PKCS#7). Maybe
> you've some thoughts.
> 
> Why am I doing this?
> 
> Roughly explained, the script is executed every 30 minutes for a lot of
> content, then the previous PKCS#7 output is pulled from a database,
> compared, and if the new script output is different, the DB is updated. This
> is stupid in many ways, but I cannot change that short-term. As a workarond,
> we would like to update the script to produce repeatable output. I know that
> this weakens the security, but we need to reduce the database load from the
> many reoccurring updates.

Hello,
this is code that creates a PKCS#7 signature from a raw RSA signature
without using openssl (because openssl cannot do that) -> you can put
any data you want in it. YMMV

https://github.com/openSUSE/pesign-obs-integration/blob/master/kernel-sign-file#L457

HTH

Michal

PKCS#7 Signing: How to get repeatable output for signing the same data

[Tim Meusel]

Hi!
I maintain a Ruby script that does PKCS#7 signing and afterwards some 
enryption with AES-128-CFB. A trimmed down version:


certpath = '/tmp/cert.pem'
keypath = '/tmp/key/pem'
data = 'teststring'
key  = OpenSSL::PKey::RSA.new(File.read(keypath), '1234')
cert = OpenSSL::X509::Certificate.new(File.read(certpath))
signed = OpenSSL::PKCS7::sign(cert, key, data, [], OpenSSL::PKCS7::BINARY)
cipher = OpenSSL::Cipher::new("AES-128-CFB")
iv_len = cipher.iv_len
key_len = cipher.key_len
fqdn_rand = Digest::SHA256.hexdigest([destination,data.length].join(':'))
iv_seed, key_seed = fqdn_rand.partition(/.{32}/)[1,2]
iv = iv_seed.unpack('a2'*key_len).map{|x| x.hex}.pack('c'*key_len)
key = key_seed.unpack('a2'*key_len).map{|x| x.hex}.pack('c'*key_len)
cipher.encrypt
cipher.iv=(iv)
cipher.key=(key)
OpenSSL::PKCS7::encrypt([target], signed.to_der, cipher, 
OpenSSL::PKCS7::BINARY).to_s


I pulled the AES encryption into a testscript and that's indeed 
repeatable (script at the end of the email). I did some tests and 
noticed that the initial signing doesn't produce repeatable output:


signed = OpenSSL::PKCS7::sign(cert, key, data, [], OpenSSL::PKCS7::BINARY)

I did some googling and that told me the signing date/timestamp is part 
of the output, which would explain why it doesn't produce the same 
output when I run it twice. Now to my actual questions:
* Is the different output caused by a changing signing time and/or 
something else?

* Do you know if I can pass the signingtime to manipulate it?

I know that this isn't a Ruby mailinglist, but the ruby-openssl bindings 
and the documentation are generated from the C code and were not very 
helpful (for people not knowing C/not knowing a lot about 
OpenSSL/PKCS#7). Maybe you've some thoughts.


Why am I doing this?

Roughly explained, the script is executed every 30 minutes for a lot of 
content, then the previous PKCS#7 output is pulled from a database, 
compared, and if the new script output is different, the DB is updated. 
This is stupid in many ways, but I cannot change that short-term. As a 
workarond, we would like to update the script to produce repeatable 
output. I know that this weakens the security, but we need to reduce the 
database load from the many reoccurring updates.


my AES testing:

root@puppet ~ # ruby openssl.rb
encrypted: ["38b5cefb"]
decrypted: test
encrypted: ["38b5cefb"]
decrypted: test
root@puppet ~ # cat openssl.rb
#!/usr/bin/env ruby

require 'openssl'

def encrypt(content)
  cipher = OpenSSL::Cipher::new("AES-128-CFB")
  cipher.encrypt
  iv ="0001".unpack('a2'*16).map{|x| 
x.hex}.pack('c'*16)

  cipher.iv=(iv)
  key = "7ffb8032dff33aef9aa92e9ac96239d3".unpack('a2'*16).map{|x| 
x.hex}.pack('c'*16)

  cipher.key=(key)
  output = cipher.update(content)
  output << cipher.final
  puts "encrypted: #{output.unpack('H*')}\n"
  puts "decrypted: #{decrypt(output, iv, key)}\n"
end

def decrypt(content, iv, key)
  cipher = OpenSSL::Cipher::new("AES-128-CFB")
  cipher.decrypt
  cipher.iv=(iv)
  cipher.key=(key)
  output = cipher.update(content)
  output << cipher.final
  output
end
encrypt 'test'
encrypt 'test'
root@puppet ~ #

The complete original code:
https://github.com/binford2k/binford2k-node_encrypt/blob/main/lib/puppet_x/binford2k/node_encrypt.rb#L11-L55
My WIP patch: 
https://github.com/binford2k/binford2k-node_encrypt/compare/main...bastelfreak:binford2k-node_encrypt:49675?expand=1


Cheers, Tim


OpenPGP_signature
Description: OpenPGP digital signature

Re: PKCS#7/CMS verify reports bad signature

[Steffen]

Hello,

I have a small update in order to close this issue.

The identity provider that produced the invalid signatures have fixed their
signatures so that we can verify them using the latest LTS version of
OpenSSL. We use Bouncy Castle in some products and it does not catch the
invalid signatures either, or at least not the way we use it.

Anyway, this is a satisfactory outcome.

Thank you for the help, everyone!

Regards,
Steffen

Re: PKCS#7/CMS verify reports bad signature

[Steffen]

Hello,

I think the person I spoke with might have thought about another set of
signatures for an in-house identity provider. If that is the case then
those signatures were probably generated by OpenSSL 1.0.2 and are OK. I
heard from another person today that the bad files were produced by the
other primary identity provider we use, so we must support the existing
format. Now I really do not see any other solution but to either downgrade
or fork OpenSSL.

On Wed, Apr 3, 2019 at 9:59 AM Matt Caswell  wrote:

>
>
> On 02/04/2019 17:34, Steffen wrote:
> > Hello,
> >
> >> What had produced the signatures?
> >
> > I received word from my end that the signatures may have been produced by
> > OpenSSL 1.0.2 (no idea which letter release) in the Cygwin environment
> but I
> > cannot confirm this.
> >
>
> If that's the case, I'd really like to know what specific version and how
> the
> signatures were generated (although it seems a little surprising if 1.0.2
> is
> creating these incorrect signatures that no-one else has encountered this,
> since
> the commit in question went in over 2.5 years ago).
>
> Matt
>

Re: PKCS#7/CMS verify reports bad signature

[Matt Caswell]

On 02/04/2019 17:34, Steffen wrote:
> Hello,
> 
>> What had produced the signatures?
> 
> I received word from my end that the signatures may have been produced by
> OpenSSL 1.0.2 (no idea which letter release) in the Cygwin environment but I
> cannot confirm this.
> 

If that's the case, I'd really like to know what specific version and how the
signatures were generated (although it seems a little surprising if 1.0.2 is
creating these incorrect signatures that no-one else has encountered this, since
the commit in question went in over 2.5 years ago).

Matt

Re: PKCS#7/CMS verify reports bad signature

[Steffen]

Hello,

> What had produced the signatures?

I received word from my end that the signatures may have been produced by
OpenSSL 1.0.2 (no idea which letter release) in the Cygwin environment but
I cannot confirm this.

Re: PKCS#7/CMS verify reports bad signature

[Michael Richardson]

Matt Caswell  wrote:
> Using the cert/data files you provided me off-list (thanks), I was able to
> confirm the above and narrow it down further to the following commit:

What had produced the signatures?

> In some cases, the damage is permanent and the spec deviation and
> security risk becomes a tax all implementors must forever pay, but not
> here. Both BoringSSL and Go successfully implemented and deployed
> RSASSA-PKCS1-v1_5 as specified since their respective beginnings, so
> this change should be compatible enough to pin down in future OpenSSL
> releases.

> So, based on the above description, it appears that older versions of 
OpenSSL
> were unduly lenient in tolerating incorrectly formatted signatures. As a
> security hardening measure that tolerance was removed. If you want to 
know more
> then David Benjamin may be able to expand.

Did openssl ever produce these wrong signatures?





signature.asc
Description: PGP signature

Re: PKCS#7/CMS verify reports bad signature

[Jakob Bohm via openssl-users]

On 02/04/2019 10:44, Matt Caswell wrote:


On 01/04/2019 22:23, Steffen wrote:

Hello,

I believe that I have narrowed the problem down to one specific version of
OpenSSL. Version 1.1.0b works as expected while OpenSSL 1.1.0c does not.

Using the cert/data files you provided me off-list (thanks), I was able to
confirm the above and narrow it down further to the following commit:

commit b71079a375116a8a52ed493afcd8f69cb08c195a
Author: David Benjamin 
Date:   Sat Aug 20 13:35:17 2016 -0400

 Implement RSASSA-PKCS1-v1_5 as specified.

 RFC 3447, section 8.2.2, steps 3 and 4 states that verifiers must encode
 the DigestInfo struct and then compare the result against the public key
 operation result. This implies that one and only one encoding is legal.

 OpenSSL instead parses with crypto/asn1, then checks that the encoding
 round-trips, and allows some variations for the parameter. Sufficient
 laxness in this area can allow signature forgeries, as described in
 https://www.imperialviolet.org/2014/09/26/pkcs1.html

 Although there aren't known attacks against OpenSSL's current scheme,
 this change makes OpenSSL implement the algorithm as specified. This
 avoids the uncertainty and, more importantly, helps grow a healthy
 ecosystem. Laxness beyond the spec, particularly in implementations
 which enjoy wide use, risks harm to the ecosystem for all. A signature
 producer which only tests against OpenSSL may not notice bugs and
 accidentally become widely deployed. Thus implementations have a
 responsibility to honor the specification as tightly as is practical.

 In some cases, the damage is permanent and the spec deviation and
 security risk becomes a tax all implementors must forever pay, but not
 here. Both BoringSSL and Go successfully implemented and deployed
 RSASSA-PKCS1-v1_5 as specified since their respective beginnings, so
 this change should be compatible enough to pin down in future OpenSSL
 releases.

 See also https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00

 As a bonus, by not having to deal with sign/verify differences, this
 version is also somewhat clearer. It also more consistently enforces
 digest lengths in the verify_recover codepath. The NID_md5_sha1 codepath
 wasn't quite doing this right.

 Reviewed-by: Kurt Roeckx 
 Reviewed-by: Rich Salz 

 GH: #1474
 (cherry picked from commit 608a026494c1e7a14f6d6cfcc5e4994fe2728836)

Implemented via this pull request:
https://github.com/openssl/openssl/pull/1474

So, based on the above description, it appears that older versions of OpenSSL
were unduly lenient in tolerating incorrectly formatted signatures. As a
security hardening measure that tolerance was removed. If you want to know more
then David Benjamin may be able to expand.
Please note that CMS countersignatures made using a specific Symantec 
server
(specifically to timestamp the original CMS signature with a long-valid 
signed

timestamp) happened to use a different PKCS#1.x signature format until very
recently.  This signature had a different but similar input to the raw RSA
algorithm, and was only ever done with Sha1RSA.

According to my notes, this format was only ever used with sha1RSA and 
md5RSA,
In this format, the DER encoding and hash OID is skipped, and instead 
the raw

20 or 16 byte hash is placed where the DER encoded tuple should be.  The
surrounding padding was apparently the same is in PKCS#1.5 signatures, 
as was

the OIDs identifying this algorithm.

I don't know if an older PKCS#1 document (before 1.5) actually specified 
this

format, only that is was present in the wild.



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, 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

Re: PKCS#7/CMS verify reports bad signature

[Steffen]

Hello Matt,

Thank you for looking into this!

So it seems like I have to figure out why the signatures are incorrectly
formatted and then fix it at every source if possible, or convert the
structures somehow if it can be done correctly. The only immediate solution
I can see is to downgrade to OpenSSL 1.0.2r or 1.1.0b until I figure out
what to do about it. These seem like pretty bad ideas right now but I am
blocked otherwise.

I do not have any further questions because I guess this is a dead end if I
cannot fix this correctly, but please feel free to share any thoughts.
CC-ing David Benjamin as well.

Thank you!

Regards,
Steffen

Re: PKCS#7/CMS verify reports bad signature

[Matt Caswell]

On 01/04/2019 22:23, Steffen wrote:
> Hello,
> 
> I believe that I have narrowed the problem down to one specific version of
> OpenSSL. Version 1.1.0b works as expected while OpenSSL 1.1.0c does not.

Using the cert/data files you provided me off-list (thanks), I was able to
confirm the above and narrow it down further to the following commit:

commit b71079a375116a8a52ed493afcd8f69cb08c195a
Author: David Benjamin 
Date:   Sat Aug 20 13:35:17 2016 -0400

Implement RSASSA-PKCS1-v1_5 as specified.

RFC 3447, section 8.2.2, steps 3 and 4 states that verifiers must encode
the DigestInfo struct and then compare the result against the public key
operation result. This implies that one and only one encoding is legal.

OpenSSL instead parses with crypto/asn1, then checks that the encoding
round-trips, and allows some variations for the parameter. Sufficient
laxness in this area can allow signature forgeries, as described in
https://www.imperialviolet.org/2014/09/26/pkcs1.html

Although there aren't known attacks against OpenSSL's current scheme,
this change makes OpenSSL implement the algorithm as specified. This
avoids the uncertainty and, more importantly, helps grow a healthy
ecosystem. Laxness beyond the spec, particularly in implementations
which enjoy wide use, risks harm to the ecosystem for all. A signature
producer which only tests against OpenSSL may not notice bugs and
accidentally become widely deployed. Thus implementations have a
responsibility to honor the specification as tightly as is practical.

In some cases, the damage is permanent and the spec deviation and
security risk becomes a tax all implementors must forever pay, but not
here. Both BoringSSL and Go successfully implemented and deployed
RSASSA-PKCS1-v1_5 as specified since their respective beginnings, so
this change should be compatible enough to pin down in future OpenSSL
releases.

See also https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00

As a bonus, by not having to deal with sign/verify differences, this
version is also somewhat clearer. It also more consistently enforces
digest lengths in the verify_recover codepath. The NID_md5_sha1 codepath
wasn't quite doing this right.

Reviewed-by: Kurt Roeckx 
Reviewed-by: Rich Salz 

GH: #1474
(cherry picked from commit 608a026494c1e7a14f6d6cfcc5e4994fe2728836)

Implemented via this pull request:
https://github.com/openssl/openssl/pull/1474

So, based on the above description, it appears that older versions of OpenSSL
were unduly lenient in tolerating incorrectly formatted signatures. As a
security hardening measure that tolerance was removed. If you want to know more
then David Benjamin may be able to expand.

Matt

Re: PKCS#7/CMS verify reports bad signature

[Steffen]

Hello,

I believe that I have narrowed the problem down to one specific version of
OpenSSL. Version 1.1.0b works as expected while OpenSSL 1.1.0c does not.

I have currently only verified this using PKCS7_verify and CMS_verify since
I have no CLI at hand for these versions.

The changelog for 1.1.0c describes the following change for CMS:

  *) CMS Null dereference

 Applications parsing invalid CMS structures can crash with a NULL pointer
 dereference. This is caused by a bug in the handling of the ASN.1 CHOICE
 type in OpenSSL 1.1.0 which can result in a NULL value being passed to the
 structure callback if an attempt is made to free certain invalid encodings.
 Only CHOICE structures using a callback which do not handle NULL value are
 affected.

 This issue was reported to OpenSSL by Tyler Nighswander of ForAllSecure.
 (CVE-2016-7053)
 [Stephen Henson]

Re: PKCS#7/CMS verify reports bad signature

[Steffen]

Hello Matt,

Thank you for your reply!

I am not quite sure if I should do something more but specifying "-binary"
alone does not seem to help:

# 1.0.2r
$ /usr/local/opt/openssl/bin/openssl cms -verify -inform der -in test.der
-content test-data.bin -noverify -binary > /dev/null
Verification successful

# 1.1.1b
$ /usr/local/opt/openssl\@1.1/bin/openssl cms -verify -inform der -in
test.der -content test-data.bin -noverify -binary > /dev/null
Verification failure
4465374656:error:04091068:rsa routines:int_rsa_verify:bad
signature:crypto/rsa/rsa_sign.c:220:
4465374656:error:2E09809E:CMS routines:CMS_SignerInfo_verify:verification
failure:crypto/cms/cms_sd.c:741:

Other ideas are much appreciated!

On Mon, Apr 1, 2019 at 3:58 PM Matt Caswell  wrote:

>
>
> On 01/04/2019 14:46, Steffen wrote:
> > Hello,
> >
> > I am struggling with using OpenSSL 1.1.1 to verify a PKCS #7/CMS
> structure.
> > Verification succeeds when I use OpenSSL 1.0.2, but 1.1.0 and 1.1.1
> fails with
> > "bad signature". I initially had this problem when using the OpenSSL
> library but
> > I see that the problem also applies to the OpenSSL CLI.
>
> Could be this (from CHANGES):
>
>   *) Fixed a text canonicalisation bug in CMS
>
>  Where a CMS detached signature is used with text content the text goes
>  through a canonicalisation process first prior to signing or
> verifying a
>  signature. This process strips trailing space at the end of lines,
> converts
>  line terminators to CRLF and removes additional trailing line
> terminators
>  at the end of a file. A bug in the canonicalisation process meant that
>  some characters, such as form-feed, were incorrectly treated as
> whitespace
>  and removed. This is contrary to the specification (RFC5485). This fix
>  could mean that detached text data signed with an earlier version of
>  OpenSSL 1.1.0 may fail to verify using the fixed version, or text data
>  signed with a fixed OpenSSL may fail to verify with an earlier
> version of
>  OpenSSL 1.1.0. A workaround is to only verify the canonicalised text
> data
>  and use the "-binary" flag (for the "cms" command line application)
> or set
>  the SMIME_BINARY/PKCS7_BINARY/CMS_BINARY flags (if using
> CMS_verify()).
>  [Matt Caswell]
>
> Matt
>
> >
> > I am at loss and need some help with this issue. Please see the commands
> I used
> > below. Thank you for any assistance you can provide!
> >
> > Notes:
> >
> >   * "-noverify" was used because the certificates expired.
> >   * Verification succeeds when specifying "-nosigs".
> >   * "openssl cms -verify [...]" behaves the same way.
> >   * Since the files I am working with (test.der and test-data.bin) are
> part of a
> > private project, I am not ready to share these in public.
> >   * I do not know exactly how the message structure was created but I
> guess
> > either with some OpenSSL 1.0.2, Java with or without BouncyCastle.
> >
> > Commands used:
> >
> > # Environment: macOS 10.14.3 / Homebrew
> >
> > $ /usr/local/opt/openssl/bin/openssl version
> > OpenSSL 1.0.2r  26 Feb 2019
> >
> > $ /usr/local/opt/openssl/bin/openssl smime -verify -inform der -in
> test.der
> > -content test-data.bin -noverify
> > Verification successful
> >
> > $ /usr/local/opt/openssl\@1.1/bin/openssl version
> > OpenSSL 1.1.1b  26 Feb 2019
> >
> > $ /usr/local/opt/openssl\@1.1/bin/openssl smime -verify -inform der -in
> test.der
> > -content test-data.bin -noverify
> > Verification failure
> > 4563408320:error:04091068:rsa routines:int_rsa_verify:bad
> > signature:crypto/rsa/rsa_sign.c:220:
> > 4563408320:error:21071069:PKCS7 routines:PKCS7_signatureVerify:signature
> > failure:crypto/pkcs7/pk7_doit.c:1037:
> > 4563408320:error:21075069:PKCS7 routines:PKCS7_verify:signature
> > failure:crypto/pkcs7/pk7_smime.c:353:
>

Re: PKCS#7/CMS verify reports bad signature

[Matt Caswell]

On 01/04/2019 14:46, Steffen wrote:
> Hello,
> 
> I am struggling with using OpenSSL 1.1.1 to verify a PKCS #7/CMS structure.
> Verification succeeds when I use OpenSSL 1.0.2, but 1.1.0 and 1.1.1 fails with
> "bad signature". I initially had this problem when using the OpenSSL library 
> but
> I see that the problem also applies to the OpenSSL CLI.

Could be this (from CHANGES):

  *) Fixed a text canonicalisation bug in CMS

 Where a CMS detached signature is used with text content the text goes
 through a canonicalisation process first prior to signing or verifying a
 signature. This process strips trailing space at the end of lines, converts
 line terminators to CRLF and removes additional trailing line terminators
 at the end of a file. A bug in the canonicalisation process meant that
 some characters, such as form-feed, were incorrectly treated as whitespace
 and removed. This is contrary to the specification (RFC5485). This fix
 could mean that detached text data signed with an earlier version of
 OpenSSL 1.1.0 may fail to verify using the fixed version, or text data
 signed with a fixed OpenSSL may fail to verify with an earlier version of
 OpenSSL 1.1.0. A workaround is to only verify the canonicalised text data
 and use the "-binary" flag (for the "cms" command line application) or set
 the SMIME_BINARY/PKCS7_BINARY/CMS_BINARY flags (if using CMS_verify()).
 [Matt Caswell]

Matt

> 
> I am at loss and need some help with this issue. Please see the commands I 
> used
> below. Thank you for any assistance you can provide!
> 
> Notes:
> 
>   * "-noverify" was used because the certificates expired.
>   * Verification succeeds when specifying "-nosigs".
>   * "openssl cms -verify [...]" behaves the same way.
>   * Since the files I am working with (test.der and test-data.bin) are part 
> of a
> private project, I am not ready to share these in public.
>   * I do not know exactly how the message structure was created but I guess
> either with some OpenSSL 1.0.2, Java with or without BouncyCastle.
> 
> Commands used:
> 
> # Environment: macOS 10.14.3 / Homebrew
>  
> $ /usr/local/opt/openssl/bin/openssl version
> OpenSSL 1.0.2r  26 Feb 2019
>  
> $ /usr/local/opt/openssl/bin/openssl smime -verify -inform der -in test.der
> -content test-data.bin -noverify
> Verification successful
>  
> $ /usr/local/opt/openssl\@1.1/bin/openssl version
> OpenSSL 1.1.1b  26 Feb 2019
>  
> $ /usr/local/opt/openssl\@1.1/bin/openssl smime -verify -inform der -in 
> test.der
> -content test-data.bin -noverify
> Verification failure
> 4563408320:error:04091068:rsa routines:int_rsa_verify:bad
> signature:crypto/rsa/rsa_sign.c:220:
> 4563408320:error:21071069:PKCS7 routines:PKCS7_signatureVerify:signature
> failure:crypto/pkcs7/pk7_doit.c:1037:
> 4563408320:error:21075069:PKCS7 routines:PKCS7_verify:signature
> failure:crypto/pkcs7/pk7_smime.c:353:

PKCS#7/CMS verify reports bad signature

[Steffen]

Hello,

I am struggling with using OpenSSL 1.1.1 to verify a PKCS #7/CMS structure.
Verification succeeds when I use OpenSSL 1.0.2, but 1.1.0 and 1.1.1 fails
with "bad signature". I initially had this problem when using the OpenSSL
library but I see that the problem also applies to the OpenSSL CLI.

I am at loss and need some help with this issue. Please see the commands I
used below. Thank you for any assistance you can provide!

Notes:

   - "-noverify" was used because the certificates expired.
   - Verification succeeds when specifying "-nosigs".
   - "openssl cms -verify [...]" behaves the same way.
   - Since the files I am working with (test.der and test-data.bin) are
   part of a private project, I am not ready to share these in public.
   - I do not know exactly how the message structure was created but I
   guess either with some OpenSSL 1.0.2, Java with or without BouncyCastle.

Commands used:

# Environment: macOS 10.14.3 / Homebrew

$ /usr/local/opt/openssl/bin/openssl version
OpenSSL 1.0.2r  26 Feb 2019

$ /usr/local/opt/openssl/bin/openssl smime -verify -inform der -in test.der
-content test-data.bin -noverify
Verification successful

$ /usr/local/opt/openssl\@1.1/bin/openssl version
OpenSSL 1.1.1b  26 Feb 2019

$ /usr/local/opt/openssl\@1.1/bin/openssl smime -verify -inform der -in
test.der -content test-data.bin -noverify
Verification failure
4563408320:error:04091068:rsa routines:int_rsa_verify:bad
signature:crypto/rsa/rsa_sign.c:220:
4563408320:error:21071069:PKCS7 routines:PKCS7_signatureVerify:signature
failure:crypto/pkcs7/pk7_doit.c:1037:
4563408320:error:21075069:PKCS7 routines:PKCS7_verify:signature
failure:crypto/pkcs7/pk7_smime.c:353:

Re: [openssl-users] PKCS#7

[valéry]

Alright, big thanks to both of you for your input!

On Mar 15, 2017 23:01, "Wouter Verhelst"  wrote:

On 15-03-17 05:13, valéry wrote:

> Hi,
>
> thank you very much for your response.
> Say someone would be able to gather several clear text AES keys and
> their respective asymmetrically encrypted RSA blocks. Would it weakens
> the security of the RSA key pair ? I mean could it be easier for someone
> using that information to brute force an RSA key pair ?
>

Think of it this way:

As far as the RSA algorithm is concerned, the AES keys are just data. They
happen to be AES keys, but they might have been a hash value, an image, or
somebody's date of birth.

If getting the cleartext as well as the encrypted text for an RSA message
would allow you to more easily guess the RSA key, then the RSA algorithm
would be seriously flawed.

There is no known attack against RSA for which this is true, however, as
Rich pointed out.

-- 
Wouter Verhelst

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

Re: [openssl-users] PKCS#7

[Wouter Verhelst]

On 15-03-17 05:13, valéry wrote:

Hi,

thank you very much for your response.
Say someone would be able to gather several clear text AES keys and
their respective asymmetrically encrypted RSA blocks. Would it weakens
the security of the RSA key pair ? I mean could it be easier for someone
using that information to brute force an RSA key pair ?


Think of it this way:

As far as the RSA algorithm is concerned, the AES keys are just data. 
They happen to be AES keys, but they might have been a hash value, an 
image, or somebody's date of birth.


If getting the cleartext as well as the encrypted text for an RSA 
message would allow you to more easily guess the RSA key, then the RSA 
algorithm would be seriously flawed.


There is no known attack against RSA for which this is true, however, as 
Rich pointed out.


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

Re: [openssl-users] PKCS#7

[Salz, Rich via openssl-users]

> Say someone would be able to gather several clear text AES keys and their 
> respective asymmetrically encrypted RSA blocks. Would it weakens the security 
> of the RSA key pair ? I mean could it be easier for someone using that 
> information to brute force an RSA key pair ?

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

Re: [openssl-users] PKCS#7

[valéry]

Hi,

thank you very much for your response.
Say someone would be able to gather several clear text AES keys and their
respective asymmetrically encrypted RSA blocks. Would it weakens the
security of the RSA key pair ? I mean could it be easier for someone using
that information to brute force an RSA key pair ?

Thank you



On Tue, Mar 14, 2017 at 3:12 PM, Salz, Rich via openssl-users <
openssl-users@openssl.org> wrote:

> > If so, would it be possible in principle to decrypt an encrypted PKCS#7
> envelope only knowing which AES key was used ?
>
> Yes.  But maybe not with the openssl api's :)
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] PKCS#7

[Salz, Rich via openssl-users]

> If so, would it be possible in principle to decrypt an encrypted PKCS#7 
> envelope only knowing which AES key was used ?

Yes.  But maybe not with the openssl api's :)
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] PKCS#7

[valéry]

Hi,

is the following picture correct ?
when creating an encrypted PKCS#7 envelope, a random AES key is generated
and encrypted with the provided RSA private key. The AES key is used to
encrypt the envelope content. The X509 certificate containing the
associated public key is included in the envelope attributes.

If so, would it be possible in principle to decrypt an encrypted PKCS#7
envelope only knowing which AES key was used ?

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

Re: [openssl-users] How to produce a nested CMS / PKCS#7 structure?

[Dr. Stephen Henson]

On Mon, Nov 28, 2016, Wim Lewis wrote:

> 
> However, I think the other half of my problem remains: if I'm putting
> another CMS object into a SignedData, AuthEnvelopedData, or other kind of
> wrapper, the OCTET STRING should contain the encoding of that object's
> structure (e.g. a BER-encoded AuthEnvelopedData, SignedData,
> ContentWithAttributes, etc. structure), not a ContentInfo *containing* that
> structure, right? How do I get OpenSSL to give me that encoded object
> without an enclosing ContentInfo?
> 

It's my understanding that the content should be a ContentInfo but I can't see
a definitive reference to this.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] How to produce a nested CMS / PKCS#7 structure?

[Wim Lewis]

On Nov 25, 2016, at 12:43 PM, Dr. Stephen Henson <st...@openssl.org> wrote:
> Something like that did happen for PKCS#7 but the  OCTET STRING encapsulation
> is correct for CMS.

Aha, and this difference is called out in RFC5652 [5.2.1]. Thanks, that 
clarifies things for me a little. So typically it's only the outermost 
ContentInfo that directly embeds a CMS object without an intervening OCTET 
STRING, and other structures use EncapsulatedContentInfo instead of ContentInfo.

However, I think the other half of my problem remains: if I'm putting another 
CMS object into a SignedData, AuthEnvelopedData, or other kind of wrapper, the 
OCTET STRING should contain the encoding of that object's structure (e.g. a 
BER-encoded AuthEnvelopedData, SignedData, ContentWithAttributes, etc. 
structure), not a ContentInfo *containing* that structure, right? How do I get 
OpenSSL to give me that encoded object without an enclosing ContentInfo?



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

Re: [openssl-users] How to produce a nested CMS / PKCS#7 structure?

[Dr. Stephen Henson]

On Tue, Nov 22, 2016, Wim Lewis wrote:

> I'm trying to produce nested structures, like signed-enveloped-signed data. 
> This is explicitly described in the various RFCs, but I can't figure out how 
> to get OpenSSL to produce valid output, and I can't find any code examples of 
> doing this.
> 
> What I'm doing (which doesn't quite work) is this: first I create the inner 
> content using (e.g.) CMS_encrypt(), getting a CMS_ContentInfo structure. This 
> works correctly and if I write it out I get what I expect. Then I want to 
> create another CMS_ContentInfo, e.g. using CMS_sign(), which envelops the 
> first one. How do I cause the ContentInfo of the SignedData structure to be 
> the ContentInfo I obtained from CMS_encrypt()? The closest I can come is code 
> like this:
> 
> 
> CMS_ContentInfo *innerCms = ;// Create the inner CMS content.
> BIO *inbetween = BIO_new(BIO_s_mem());   // Write it to a buffer.
> i2d_CMS_bio(inbetween, innerCms);
> CMS_ContentInfo *outerCms = CMS_sign(cert, key, NULL, inbetween, 
> CMS_BINARY|CMS_PARTIAL|CMS_NOSMIMECAP);
> CMS_set1_eContentType(outerCms, OBJ_nid2obj(NID of innerCms));   // Set 
> the content-type
> CMS_final(outerCms, inbetween, NULL, CMS_BINARY|CMS_NOSMIMECAP); // 
> Finalize the CMS structure
> 
> (My actual code checks all the return values, but I left those off for 
> clarity.)
> 
> Unfortunately, this produces output like this:
> 
>ContentInfo {
>   contentType = :pkcs7-signedData;
>   content = SignedData {
>  ... various ...
>  contentInfo = ContentInfo {
> contentType = :pkcs7-envelopedData;
> content = [0] EXPLICIT OctetString{...}
>  }
>   }
> }
>  
> where the inner OCTET STRING contains *another* ContentInfo, which then 
> contains the nested object.
> 
> But from my understanding, the correct syntax for a nested CMS structure is 
> this:
> 
>ContentInfo {
>   contentType = :pkcs7-signedData;
>   content = SignedData {
>  ... various ...
>  contentInfo = ContentInfo {
> contentType = :pkcs7-envelopedData;
> content = [0] EXPLICIT EnvelopedData {
> ...fields of the EnvelopedData structure...
> }
>  }
>   }
> }
> 
> In other words, I have two extra, incorrect levels of encapsulation: the 
> OCTET STRING and the extra ContentInfo.
> 

Something like that did happen for PKCS#7 but the  OCTET STRING encapsulation
is correct for CMS.

If you look in RFC5652:

SignedData ::= SEQUENCE {
version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
signerInfos SignerInfos }

The content is of type Encapsulated ConentInfo:

EncapsulatedContentInfo ::= SEQUENCE {
eContentType ContentType,
eContent [0] EXPLICIT OCTET STRING OPTIONAL }

  ContentType ::= OBJECT IDENTIFIER

Here eContent is always an OCTET STRING if it is present.

It also says:

 eContent is the content itself, carried as an octet string.  The
 eContent need not be DER encoded.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] How to produce a nested CMS / PKCS#7 structure?

[Wim Lewis]

I'm trying to produce nested structures, like signed-enveloped-signed data. 
This is explicitly described in the various RFCs, but I can't figure out how to 
get OpenSSL to produce valid output, and I can't find any code examples of 
doing this.

What I'm doing (which doesn't quite work) is this: first I create the inner 
content using (e.g.) CMS_encrypt(), getting a CMS_ContentInfo structure. This 
works correctly and if I write it out I get what I expect. Then I want to 
create another CMS_ContentInfo, e.g. using CMS_sign(), which envelops the first 
one. How do I cause the ContentInfo of the SignedData structure to be the 
ContentInfo I obtained from CMS_encrypt()? The closest I can come is code like 
this:


CMS_ContentInfo *innerCms = ;// Create the inner CMS content.
BIO *inbetween = BIO_new(BIO_s_mem());   // Write it to a buffer.
i2d_CMS_bio(inbetween, innerCms);
CMS_ContentInfo *outerCms = CMS_sign(cert, key, NULL, inbetween, 
CMS_BINARY|CMS_PARTIAL|CMS_NOSMIMECAP);
CMS_set1_eContentType(outerCms, OBJ_nid2obj(NID of innerCms));   // Set the 
content-type
CMS_final(outerCms, inbetween, NULL, CMS_BINARY|CMS_NOSMIMECAP); // 
Finalize the CMS structure

(My actual code checks all the return values, but I left those off for clarity.)

Unfortunately, this produces output like this:

   ContentInfo {
  contentType = :pkcs7-signedData;
  content = SignedData {
 ... various ...
 contentInfo = ContentInfo {
contentType = :pkcs7-envelopedData;
content = [0] EXPLICIT OctetString{...}
 }
  }
}
 
where the inner OCTET STRING contains *another* ContentInfo, which then 
contains the nested object.

But from my understanding, the correct syntax for a nested CMS structure is 
this:

   ContentInfo {
  contentType = :pkcs7-signedData;
  content = SignedData {
 ... various ...
 contentInfo = ContentInfo {
contentType = :pkcs7-envelopedData;
content = [0] EXPLICIT EnvelopedData {
...fields of the EnvelopedData structure...
}
 }
  }
}

In other words, I have two extra, incorrect levels of encapsulation: the OCTET 
STRING and the extra ContentInfo.

In order to get the right output, I think I would need both a way to tell the 
CMS structure to use the correct data type *and* the correct contentType OID, 
and also a way to get to the EnvelopedData structure inside of the innerCms 
structure. But neither of those things seems to be accessible using the OpenSSL 
API.

Any hints? Surely someone has used OpenSSL to create nested structures in the 
past?


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

Re: [openssl-users] using openssl to create PKCS#7/CMS on windows

[Jakob Bohm]

On 05/02/2015 14:30, Srinivas Rao wrote:

Hi All,

Is there a way to use openssl to sign data using a private key (on USB
token) and produce PKCS7 output on win32, if:

a) the data to be signed message is not touched yet and goes as input
to the solution to the answer to this problem, OR

b) signature is already generated, i.e message is hashed and signed
and only needs to be encoded in PKCS7,

If yes, for which of the above case and how (please give some pointers
on how to go about it).

Thanks
Srinivas


Are you trying to get us to help with a school assignment?
This looks a lot like how a teacher would ask a question to
his students to find out how much they have understood
themselves.

That said, the main pointers I can give you are these:

Verylittlein OpenSSL differs between Win32 and other
systems.  Howeverthere is one part in the question that
will usually be slightly different onWin32.If you
understand the question and OpenSSL general features, you
should be able to recognize which part that is.

One of the alternatives is going to be more difficult than
the other because it is a less common task, but it may still
be doable with some ingenuity.

The task (either one if both are doable) can be performed
using almost no APIs and interfaces other than those
provided by OpenSSL and ANSI C.  If you are tempted to use
other tools, look closer at the OpenSSL feature lists and
available options.

In your code below you forgot to use two of the items your
teacher gave you, which is probably the problem.


On 1/30/15, Srinivas Rao srir...@gmail.com wrote:

All,

Please let me know if my below mentioned usage of PKCS7_sign()+adding
signer info is wrong and how.

Really appreciate your response.

cheers and regards
Srinivas

On 1/29/15, Srinivas Rao srir...@gmail.com wrote:

OpenSSL experts,

Here the intention is to get the signed data (raw signature obtained
by PKCS11 APIs like C_Sign) to be packed in PKCS7 format (attached -
with certificate, content and signer info) using openssl.

I am using USB token (smart card) for signing.

Here's the code snippet.

PKCS7* p7 = PKCS7_new();
PKCS7_set_type(p7, NID_pkcs7_signed);
//PKCS7_SIGNER_INFO* pSI = PKCS7_SIGNER_INFO_new();
//PKCS7_SIGNER_INFO_set(pSI, pX509, pX509-cert_info-key-pkey,
EVP_sha256());
//PKCS7_add_signer(p7, pSI);
PKCS7_SIGNER_INFO* pSI = PKCS7_add_signature(p7, pX509,
pX509-cert_info-key-pkey, EVP_sha256());  // == core dumps here
 :
 :
where pX509 is correctly obtained X509* node using d2i_X509() from the
value obtained from PKCS11 funcstions like C_GetAttributeValue() etc.

I believe the set of the commented lines is the alternate way for this
add signature function - that also dumps core at
PKCS7_SIGNER_INFO_set() function.

I have no clue as to what am I doing wrong here.

Appreciate your help.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 Søborg, 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-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] using openssl to create PKCS#7/CMS on windows

[Srinivas Rao]

Hi All,

Is there a way to use openssl to sign data using a private key (on USB
token) and produce PKCS7 output on win32, if:

a) the data to be signed message is not touched yet and goes as input
to the solution to the answer to this problem, OR

b) signature is already generated, i.e message is hashed and signed
and only needs to be encoded in PKCS7,

If yes, for which of the above case and how (please give some pointers
on how to go about it).

Thanks
Srinivas


On 1/30/15, Srinivas Rao srir...@gmail.com wrote:
 All,

 Please let me know if my below mentioned usage of PKCS7_sign()+adding
 signer info is wrong and how.

 Really appreciate your response.

 cheers and regards
 Srinivas

 On 1/29/15, Srinivas Rao srir...@gmail.com wrote:
 OpenSSL experts,

 Here the intention is to get the signed data (raw signature obtained
 by PKCS11 APIs like C_Sign) to be packed in PKCS7 format (attached -
 with certificate, content and signer info) using openssl.

 I am using USB token (smart card) for signing.

 Here's the code snippet.

  PKCS7* p7 = PKCS7_new();
  PKCS7_set_type(p7, NID_pkcs7_signed);
  //PKCS7_SIGNER_INFO* pSI = PKCS7_SIGNER_INFO_new();
  //PKCS7_SIGNER_INFO_set(pSI, pX509, pX509-cert_info-key-pkey,
 EVP_sha256());
  //PKCS7_add_signer(p7, pSI);
  PKCS7_SIGNER_INFO* pSI = PKCS7_add_signature(p7, pX509,
 pX509-cert_info-key-pkey, EVP_sha256());  // == core dumps here
 :
 :
 where pX509 is correctly obtained X509* node using d2i_X509() from the
 value obtained from PKCS11 funcstions like C_GetAttributeValue() etc.

 I believe the set of the commented lines is the alternate way for this
 add signature function - that also dumps core at
 PKCS7_SIGNER_INFO_set() function.

 I have no clue as to what am I doing wrong here.

 Appreciate your help.

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

Failure of CMS = PKCS#7 compatibility tests

[Johnson, Wayne]

I have been attempting to compile OpenSSL 1.0.1h on about 14 different 
platforms/architectures for our product.  I ran into an issue with one of the 
unit tests on our HP-UX 11i v2 Itanium system in 64 bit mode.

CMS = PKCS#7 compatibility tests
signed content DER format, RSA key: OK
signed detached content DER format, RSA key: OK
signed content test streaming BER format, RSA: verify error
make[1]: *** [test_cms] Error 1
make[1]: Leaving directory `/tmp/buildOpenSSL101.26859/openssl-1.0.1h/test'
make: *** [tests] Error 2

I don't think this will affect our product, but thought I might be able to 
supply some information in case someone would be interested in fixing it.  
Anyone interested?




Wayne D. T. Johnson
Staff Specialist Product Developer
BMC Software

phone: 952.345.8628
BMC 5 digit: 58628
fax: 952.345.8721

1600 Tower, Suite 450
1600 Utica Av. So.
St. Louis Park, MN 55416


[BMC Software]http://www.bmc.com/

OCSP result embedded in PKCS #7

[Laurent Debacker]

Hi,

I try to embed an OCSP basic response in a PKCS #7 SignedData object.

When I run openssl pkcs7 -inform DER -text -in file.p7c, I get:

unable to load PKCS7 object
5024:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag:.\crypto\as
n1\tasn_dec.c:1319:
5024:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:.\
crypto\asn1\tasn_dec.c:381:Type=X509_CRL
5024:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 e
rror:.\crypto\asn1\tasn_dec.c:711:Field=crl, Type=PKCS7_SIGNED
5024:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 e
rror:.\crypto\asn1\tasn_dec.c:751:
5024:error:0D08403A:asn1 encoding routines:ASN1_TEMPLATE_EX_D2I:nested asn1 erro
r:.\crypto\asn1\tasn_dec.c:579:Field=d.sign, Type=PKCS7

An asn1parse of the file give this (truncated to relevant area):

 2976:d=3  hl=4 l=1454 cons: cont [ 1 ]
 2980:d=4  hl=4 l=1450 cons: cont [ 1 ]
 2984:d=5  hl=2 l=   8 prim: OBJECT:1.3.6.1.5.5.7.16.2
 2994:d=5  hl=4 l=1436 cons: SEQUENCE
 2998:d=6  hl=2 l=   1 prim: ENUMERATED:00
 3001:d=6  hl=4 l=1429 cons: cont [ 0 ]
 3005:d=7  hl=4 l=1425 cons: SEQUENCE
 3009:d=8  hl=2 l=   9 prim: OBJECT:Basic OCSP Response
 3020:d=8  hl=4 l=1410 prim: OCTET STRING  [HEX
DUMP]:3082057E30820117A1819F...

And here is the ASN.1 tree as parsed by another program, with
non-relevant nodes folded:

SEQUENCE (2 elem)
-OBJECT IDENTIFIER 1.2.840.113549.1.7.2
-[0] (1 elem)
--SEQUENCE (6 elem)
---INTEGER 5
---SET (1 elem) folded
---SEQUENCE (2 elem) folded
---[0] (3 elem) folded
---[1] (1 elem)
[1] (2 elem)
-OBJECT IDENTIFIER 1.3.6.1.5.5.7.16.2
-SEQUENCE (2 elem)
--ENUMERATED
--[0] (1 elem)
---SEQUENCE (2 elem)
OBJECT IDENTIFIER 1.3.6.1.5.5.7.48.1.1
OCTECT STRING (1 elem)
-SEQUENCE (4 elem) folded
---SET (1 elem) folded

I only get the error when the OCSP response is embedded. All I could
find on the internet about this, is another post to this list but I
don't see what's wrong in my file.

Has anyone an idea why OpenSSL is rejecting this file?

Thank you

Laurent
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Sometimes openssl won't validate a well signed PKCS#7 data

[Dave Thompson]

 From: owner-openssl-us...@openssl.org On Behalf Of Dr. Stephen Henson
 Sent: Wednesday, 20 February, 2013 19:06
 
 On Tue, Feb 19, 2013, Ulises S. wrote:
 
  There is this odd behavior in which one in many signed 
 files with PKCS#7 on JAVA won't
  pass the validation with Openssl, all Openssl signed data 
 is correctly verified in JAVA though.
  
  Currently I have not a test case but according to certain 
 ppl that claim
  that there is this remain in some situations in which for 
 example JAVA
  fill with random bytes according to the RSA Labs Standard 
 Specification of

Either you or certain ppl is confused. 
SignedData as defined by PKCS#7 did not have anything that 
could reasonably be described as remain and randomized.
RSA-PSS signatures, which didnm't exist in the timeframe 
PKCS#7 was written and mostly implemented, are randomized 
but that random is (1) always required and present and 
(2) opaque in the resulting signature. Ditto for DSA and 
ECDSA, the latter of which also didn't exist then; but 
most people who don't know multiple publickey algorithms 
exist are using RSA, just as most people who don't know 
multiple operating systems exist are using MSWindows.

I suggest you (OP) cnofirm whether they really want the 
very-old RSA Labs spec (see below) or the functionally 
very similar but newer and maintained IETF spec CMS.

  the structure and that Openssl don't do this, I'm wondering 
 if this has
  something to do with the openssl.org entry:
  
  This PKCS#7 routines only understand PKCS#7 v 1.5 as 
 specified in RFC2315
  they cannot currently parse, for example, the new CMS as 
 described in
  RFC2630
  
  If this is true, can someone explain with more details why 
 openssl don't
  follow the standard or explain the behavior so we can build a more
  accurate validator?
  
 
 PKCS#7 and CMS are two similar standards but with a few 
 subtle differences.

Beg to differ. The *first version* of CMS was almost the same 
as PKCS#7. But after that no further work was done on PKCS#7 
while numerous new features and extensions were added to CMS, 
so today CMS is maybe twice as big as fossilized PKCS#7.

This is like the way TLS 1.0 was almost the same as SSL 3, 
but TLS 1.1 and 1.2 -- and DTLS -- have increasing differences 
while still sharing the basic concepts and architecture.
And AFAICT both of these progressed for similar reasons.

 If you want to process CMS then use the CMS routines instead. 
 The interface
 is almost identical at the application level except the APIs 
 begin CMS_
 instead of PKCS7_.
 
And similarly the CMS_ (and SMIME_) API is quite a bit more 
capable than PKCS7_ -- although the part of CMS_ that implements 
the original PKCS7_ functionality is similar.


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Sometimes openssl won't validate a well signed PKCS#7 data

[Dr. Stephen Henson]

On Thu, Feb 21, 2013, Dave Thompson wrote:

  From: owner-openssl-us...@openssl.org On Behalf Of Dr. Stephen Henson
  Sent: Wednesday, 20 February, 2013 19:06
  
  
  PKCS#7 and CMS are two similar standards but with a few 
  subtle differences.
 
 Beg to differ. The *first version* of CMS was almost the same 
 as PKCS#7. But after that no further work was done on PKCS#7 
 while numerous new features and extensions were added to CMS, 
 so today CMS is maybe twice as big as fossilized PKCS#7.
 

Yes sorry should've been clearer. What I meant was that (with the exception of
a few very rarely used weird cases) PKCS#7 signatures are compatible with CMS.

The reverse is not true: CMS offers many new features that are not in PKCS#7.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Sometimes openssl won't validate a well signed PKCS#7 data

[Dr. Stephen Henson]

On Tue, Feb 19, 2013, Ulises S. wrote:

 There is this odd behavior in which one in many signed files with PKCS#7 on
 JAVA won't
 pass the validation with Openssl, all Openssl signed data is correctly
 verified in JAVA though.
 
 Currently I have not a test case but according to certain ppl that claim
 that there is this remain in some situations in which for example JAVA
 fill with random bytes according to the RSA Labs Standard Specification of
 the structure and that Openssl don't do this, I'm wondering if this has
 something to do with the openssl.org entry:
 
 This PKCS#7 routines only understand PKCS#7 v 1.5 as specified in RFC2315
 they cannot currently parse, for example, the new CMS as described in
 RFC2630
 
 If this is true, can someone explain with more details why openssl don't
 follow the standard or explain the behavior so we can build a more
 accurate validator?
 

PKCS#7 and CMS are two similar standards but with a few subtle differences.
If you want to process CMS then use the CMS routines instead. The interface
is almost identical at the application level except the APIs begin CMS_
instead of PKCS7_.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

CAPI engine PKCS#7 decrypt error

[Florian Rüchel]

Hello,

I have an application that decrypts an encrypted PKCS#7 structure.
When I run it with keys loaded from disk, it runs perfectly, but as 
soon as I use engine keys from CAPI it fails with:
8244:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad 
decrypt:.\crypto\evp\evp_enc.c:539:


Note that I am able to sign another package with the key which the 
server accepts. But the response from the server can't be decrypted with 
CAPI keys.
I looked through the functions of most of the files but I cannot find 
any possible error for this.

The call is
PKCS7_decrypt(p7enc, recipientkey, recipientcert, outbio, 0)

Which works just fine if recipientkey is not inside the engine.

Any suggestions on debugging this? Could there even be an error in the 
engine or do I just miss something simple like a padding setting?


Regards,
Florian
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

pkcs#7 sign with OpenSSL

[Pietro Romanazzi]

Hi,
afraid this question has been already issued but I did not find any solution 
surfing the web.
I need to sign data with a RSA private key and obtain a pkcs#7 envelope with 
data, signature 
and certificate.
In the past I remember I found the solution with OpenSSL command line. 
Unfortunately I've 
lost the note.
Could you help me.
Thanks

Pietro Romanazzi
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: pkcs#7 sign with OpenSSL

[Dr. Stephen Henson]

On Thu, Dec 15, 2011, Pietro Romanazzi wrote:

 Hi,
 afraid this question has been already issued but I did not find any solution 
 surfing the web.
 I need to sign data with a RSA private key and obtain a pkcs#7 envelope with 
 data, signature 
 and certificate.
 In the past I remember I found the solution with OpenSSL command line. 
 Unfortunately I've 
 lost the note.
 Could you help me.
 Thanks
 

The smime or the cms command should do what you want.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: How to do generate PKCS#7 to embedded system

[Dave Thompson]

Correcting myself for the record: 

 From: owner-openssl-us...@openssl.org On Behalf Of Dave Thompson
 Sent: Thursday, 17 November, 2011 18:53

 snip As I said, I don't believe any openssl commandline 
 function will create a 'degenerate' (cert-only) PKCS#7, which 
 is a signeddata with zero signerinfos (and zero digestalgs), 
 omitted or dummy content, and your cert(s). You could:
 
Looking for something else, I discovered that commandline 
'crl2pkcs7 -nocrl -certfile' (obviously :-?) does do this. 

 - (probably) write a tiny program using the PKCS7_* API; 
 on a quick scan it looks like you can just create a 
 (inner) PKCS7 and _set0_other(data,empty octet string), then a 
 (outer) PKCS7 and _set_type(,signed) and _set_content(,thatdata)
 and _add_cert and write it out, but I haven't tested.
 
and I was off some here. outer PKCS7 needs to have type signed 
and also version, and *point to* PKCS7_SIGNED whose 'contents' 
are the inner data, but are apparently preallocated and only 
need to be set to omitted data (although I bet empty would work).
And it's _add_certificate, or inline which crl2p7.c does instead.

snip other options, still correct but less important 

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: How to do generate PKCS#7 to embedded system

[Dave Thompson]

   From: owner-openssl-us...@openssl.org On Behalf Of Laerte Junior
   Sent: Wednesday, 16 November, 2011 06:23

   First, thanks for your answer.
   But I using crypt processor to generate key pair (rsa 1024), 
 and the structure of certificate I implement the ASN.1 manually 
 (I don't have memory enough to use openssl lib), because I using 
 MSP430F5438A processor.

Okay.

   Probably, I not explain correctly and attached file explain 
 the procedures in my project, and I need follow these steps below:

Aside: your figure says Certificate encrypted by hardware key.
The certificate contains the key for your device, which is hardware 
(apparently); and is signed by the CA's key, which may be hardware 
or not (for openssl usually not). Certificates generally are 
NOT encrypted, and certificates in PKCS#7 definitely are not.
Also the picture shows RA on the 'create' (issue) box and the 
related text although terse is probably backward; if RA and CA 
are separate (and often they aren't), it is really RA issues 
through CA or CA issues from or as a result of RA.

   1 - My project generate CSR in PKCS#10 format (Implemented 
 using my crypt processor to generate keys and sign the structure);
   2 - The CA receive my CSR in PKCS#10 format, generate the
Certificate 
 and send me in PKCS#7 format; (This step that I not understand to do);
   3 - Store the Certificate in Flash memory (Not Implemented yet, 
 but is not difficult)

   The step 2 I try to use openssl, but I not understand, because 
 there aren't examples how to implement Certificate.

So you want to be the CA and issue a cert for the CSR 
(thus publickey) from your device, for your device to use.

OpenSSL commandline 'ca' provides the technical part of a CA: 
issue certs, record them (in a file), optionally revoke them.
It does not implement the business side of a real CA/RA 
such as verifying identities and establishing policies; 
it sounds like in your situation these aren't needed.

OpenSSL commandline 'x509' with option '-req' provides 
the minimal function of simply issuing a cert from a CSR, 
which may be all you need.

The man pages on your system (if Unixy and fully installed) 
or on the website describe these capabilities in detail.
Basically you create a CA keypair and selfsigned (root) cert, 
a file to specify the serialnumber, and for 'ca' a 'database' 
file that is initially empty and depending on your options 
and config possibly some directories. Then you run 'ca' or 
'x509 -req' with options to read the CSR and issue the cert.

Note in both methods OpenSSL can include extensions in the 
issued cert, but the method of doing so is slightly different.
If your device will use this cert for purposes (like SSL) 
that need or want certain extensions, find out which 
extensions/values before you do the cert-issue operation(s). 
And decide and specify how long a validity period you want.
In both methods also you can set up multi-level CA hierarchy 
if you want, but for a private CA this is usually unneeded.

Either method creates the cert by itself as a file (PEM or 
DER). As I said, I don't believe any openssl commandline 
function will create a 'degenerate' (cert-only) PKCS#7, which 
is a signeddata with zero signerinfos (and zero digestalgs), 
omitted or dummy content, and your cert(s). You could:

- (probably) write a tiny program using the PKCS7_* API; 
on a quick scan it looks like you can just create a 
(inner) PKCS7 and _set0_other(data,empty octet string), then a 
(outer) PKCS7 and _set_type(,signed) and _set_content(,thatdata)
and _add_cert and write it out, but I haven't tested.

- write a small program to take a cert and build a degenerate 
signeddata. If you understand DER enough to build a PKCS#10, 
a PKCS#7 is no harder.

- use commandline 'smime' with '-pk7out' to create signeddata 
WITH a signerinfo, PLUS the 'additional' cert(s) you want, 
and have your device ignore the signature and just extract the 
cert(s). The underlying data is omitted unless you specify 
'-nodetach' or you can just use minimal dummy data.

- if on Windows, or you have a Windows machine available, 
use InternetOptions (under ControlPanel, or from IE) to 
import the cert to any convenient store, such as OtherPeople, 
then export as PKCS#7. And clean up afterwards.


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: How to do generate PKCS#7 to embedded system

[Laerte Junior]

 Hi, First, thanks for your answer.  But I using crypt processor to generate 
key pair (rsa 1024), and the structure of certificate I implement the ASN.1 
manually (I don't have memory enough to use openssl lib), because I using 
MSP430F5438A processor.Probably, I not explain correctly and attached file 
explain the procedures in my project, and  I need follow these steps below:1 - 
My project generate CSR in PKCS#10 format (Implemented using my crypt processor 
to generate keys and sign the structure);2 - The CA receive my CSR in PKCS#10 
format, generate the Certificate and send me in PKCS#7 format; (This step that 
I not understand to do);3 - Store the Certificate in Flash memory (Not 
Implemented yet, but is not difficult) The step 2 I try to use openssl, but I 
not understand, because there aren't examples how to implement Certificate. 
Thanks for helpLaerte Junior
  From: dthomp...@prinpay.com
 To: openssl-users@openssl.org
 Subject: RE: How to do generate PKCS#7 to embedded system
 Date: Mon, 14 Nov 2011 17:36:25 -0500
 
  From: owner-openssl-us...@openssl.org On Behalf Of Laerte Junior
  Sent: Saturday, 12 November, 2011 14:22
 
   I'm working with embedded system project and I need to receive
 PKCS7 
  and store the fields(DN, signature, public key, etc.). Before, I generate 
  a CSR to test (attached file), but now I need to generate PKCS7 to test. 
  How to do it? I need to generate a small PKCS7 as possible.
 
 PKCS7 actually is (was designed as) a general format for 
 lots of things, including signed and/or encrypted data.
 However, it is commonly used 'merely' to transfer one or more 
 certificate(s) and/or one or more CRL(s) -- nominally for use 
 to verify a related signeddata, but actually for any purpose.
 
 The fields you name are in a cert; do you want to receive a cert?
 If so, you must first get a cert, corresponding to your CSR.
 
 Is this CSR from the 'embedded' system, or an outside one?
 If the former, presumably what you want is to give the embedded 
 system a cert for its keypair; what kind of cert? If the latter, 
 why do you need to pre-transfer the cert rather than presenting 
 it when referenced? How it is used for trust decisions will 
 influence exactly which cert(s) (i.e. chain(s)) you need.
 
 If you want a selfsigned cert and have or can get its private 
 key, openssl can do that. Of course a selfsigned cert doesn't 
 generally deserve trust so this might not gain you much.
 If you want a cert issued (signed) under your own CA (key)(s), 
 openssl can do that. If you want a cert issued under a public 
 or other outside CA, you need to interact with that CA.
 Alternatively, if you just want a selfsigned cert for a 
 private key you have, openssl can do that directly.
 
 If this will be a cert for the system's own keypair to be 
 presented to others, storing only fields may be problematic.
 You will need to reconstruct (at least) exactly the same DER 
 cert-info (aka TBS) as was in the issued or selfsigned cert.
 If not selfsigned, you may need to have (and present) part of 
 the CA chain, up to (but not necessarily including) the trusted 
 CA root or other (subroot) cert already on (all) the relier(s).
 
 If you get the cert from a real CA, it might provide you a 
 'degenerate' PKCS7 with your cert and any needed chain certs.
 AFAIK openssl commandline cannot create this; 'pkcs7' *reads* 
 it (but doesn't write), and 'smime' optionally creates a real 
 pkcs7: at minimum this would be a detached signature (which your 
 receiver needn't and shouldn't verify) for data you discard.
 You could write about a 10-line program using openssl library 
 to create a degenerate PKCS7 for a cert, or chain. 
 
 
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org
  attachment: Certificate_procedures.jpg

RE: How to do generate PKCS#7 to embedded system

[Dave Thompson]

   From: owner-openssl-us...@openssl.org On Behalf Of Laerte Junior
   Sent: Saturday, 12 November, 2011 14:22

I'm working with embedded system project and I need to receive
PKCS7 
 and store the fields(DN, signature, public key, etc.). Before, I generate 
 a CSR to test (attached file), but now I need to generate PKCS7 to test. 
 How to do it? I need to generate a small PKCS7 as possible.

PKCS7 actually is (was designed as) a general format for 
lots of things, including signed and/or encrypted data.
However, it is commonly used 'merely' to transfer one or more 
certificate(s) and/or one or more CRL(s) -- nominally for use 
to verify a related signeddata, but actually for any purpose.

The fields you name are in a cert; do you want to receive a cert?
If so, you must first get a cert, corresponding to your CSR.

Is this CSR from the 'embedded' system, or an outside one?
If the former, presumably what you want is to give the embedded 
system a cert for its keypair; what kind of cert? If the latter, 
why do you need to pre-transfer the cert rather than presenting 
it when referenced? How it is used for trust decisions will 
influence exactly which cert(s) (i.e. chain(s)) you need.

If you want a selfsigned cert and have or can get its private 
key, openssl can do that. Of course a selfsigned cert doesn't 
generally deserve trust so this might not gain you much.
If you want a cert issued (signed) under your own CA (key)(s), 
openssl can do that. If you want a cert issued under a public 
or other outside CA, you need to interact with that CA.
Alternatively, if you just want a selfsigned cert for a 
private key you have, openssl can do that directly.

If this will be a cert for the system's own keypair to be 
presented to others, storing only fields may be problematic.
You will need to reconstruct (at least) exactly the same DER 
cert-info (aka TBS) as was in the issued or selfsigned cert.
If not selfsigned, you may need to have (and present) part of 
the CA chain, up to (but not necessarily including) the trusted 
CA root or other (subroot) cert already on (all) the relier(s).

If you get the cert from a real CA, it might provide you a 
'degenerate' PKCS7 with your cert and any needed chain certs.
AFAIK openssl commandline cannot create this; 'pkcs7' *reads* 
it (but doesn't write), and 'smime' optionally creates a real 
pkcs7: at minimum this would be a detached signature (which your 
receiver needn't and shouldn't verify) for data you discard.
You could write about a 10-line program using openssl library 
to create a degenerate PKCS7 for a cert, or chain. 


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

How to do generate PKCS#7 to embedded system

[Laerte Junior]

Hi,
 I'm working with embedded system project and I need to receive PKCS7 and store 
the fields(DN, signature, public key, etc.). Before, I generate a CSR to test 
(attached file), but now I need to generate PKCS7 to test. How to do it? I need 
to generate a small PKCS7 as possible. Thanks and Regards Laerte Junior
  

requisicao.csr
Description: Binary data

Creating a PKCS#7 file using OpenSSL from the command line - is this possible?

[richard.folwell]

I'm fairly comfortable now using OpenSSL from the command line for basic
operations: certificate management, encryption, decryption, signing and
verification.  However I need to create encrypted and signed files to
meet PKCS#7, and cannot find any documentation online that explains how
to do this.  openssl pkcs7 appears to be for manipulating existing
PKCS#7 files, not for creating them in the first place.

I did find a PHP example that looked like a good starting point:

http://www.phpf1.com/manual/openssl-pkcs7-encrypt.html

but right now I don't have a development environment of any kind
available.  Is it possible to do this kind of thing just using command
line openssl?


TIA,
Richard



This e-mail and any attachments are confidential and intended solely for the 
addressee and may also be privileged or exempt from disclosure under applicable 
law. If you are not the addressee, or have received this e-mail in error, 
please notify the sender immediately, delete it from your system and do not 
copy, disclose or otherwise act upon any part of this e-mail or its attachments.

Internet communications are not guaranteed to be secure or virus-free.
The Barclays Group does not accept responsibility for any loss arising from 
unauthorised access to, or interference with, any Internet communications by 
any third party, or from the transmission of any viruses. Replies to this 
e-mail may be monitored by the Barclays Group for operational or business 
reasons.

Any opinion or other information in this e-mail or its attachments that does 
not relate to the business of the Barclays Group is personal to the sender and 
is not given or endorsed by the Barclays Group.

Barclays Bank PLC.Registered in England and Wales (registered no. 1026167).
Registered Office: 1 Churchill Place, London, E14 5HP, United Kingdom.

Barclays Bank PLC is authorised and regulated by the Financial Services 
Authority.

Re: Creating a PKCS#7 file using OpenSSL from the command line - is this possible?

[Dr. Stephen Henson]

On Tue, Nov 23, 2010, richard.folw...@barclays.com wrote:

 I'm fairly comfortable now using OpenSSL from the command line for basic
 operations: certificate management, encryption, decryption, signing and
 verification.  However I need to create encrypted and signed files to
 meet PKCS#7, and cannot find any documentation online that explains how
 to do this.  openssl pkcs7 appears to be for manipulating existing
 PKCS#7 files, not for creating them in the first place.
 

It depends on what you mean by encrypted and signed files. The smime utility
can create signed or encrypted PKCS#7 structures but not the rarely used
signedAndEncrypte PKCS#7 type. If you have a choice on the format then the
(largely compatible with PKCS#7) Cryptographic Message Syntax (CMS) is
preferable over PKCS#7: the cms utility supports that.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Error inspecting PKCS#7 DER

[Giacomo Boccardo]

 I had to re-compile openssl using the flag enable-cms in order to use 
the cms command. Why is it disabled by default?


Thanks,
   J.


 Messaggio Originale  
Oggetto: Re: Error inspecting PKCS#7 DER
Da: Dr. Stephen Henson st...@openssl.org
A: openssl-users@openssl.org
Data: 04/08/2010 16:30:54


The smime command uses PKCS#7 which doesn't include the SKID option. Use the
cms command instead.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Error inspecting PKCS#7 DER

[Dr. Stephen Henson]

On Thu, Aug 05, 2010, Giacomo Boccardo wrote:

  I had to re-compile openssl using the flag enable-cms in order to use the 
 cms command. Why is it disabled by default?


It was a new feature in a stable branch of OpenSSL and due to the policy at
the time new features were disabled by default. In OpenSSL 1.0.0x it is
enabled by default.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Error inspecting PKCS#7 DER

[Giacomo Boccardo]

 When I try to inspect the file in the attachment (PKCS#7, DER format) 
I have the following error:


$ openssl pkcs7 -inform DER -in cadesBES_singleCounterSignatureWithDate.p7m
unable to load PKCS7 object
2491:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong 
tag:tasn_dec.c:1316:
2491:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 
error:tasn_dec.c:380:Type=PKCS7_ISSUER_AND_SERIAL
2491:error:0D08303A:asn1 encoding 
routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 
error:tasn_dec.c:748:Field=issuer_and_serial, Type=PKCS7_SIGNER_INFO
2491:error:0D08303A:asn1 encoding 
routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 
error:tasn_dec.c:709:Field=signer_info, Type=PKCS7_SIGNED
2491:error:0D08303A:asn1 encoding 
routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:748:
2491:error:0D08403A:asn1 encoding routines:ASN1_TEMPLATE_EX_D2I:nested 
asn1 error:tasn_dec.c:578:Field=d.sign, Type=PKCS7


Is it possible that it's trying to look for an IssuerAndSerialNumber 
structure, even if I'm using a SubjectKeyIdentifier one?



Thanks,
   Giacomo Boccardo.


cadesBES_singleCounterSignatureWithDate.p7m
Description: Binary data

Re: Error inspecting PKCS#7 DER

[Dr. Stephen Henson]

On Wed, Aug 04, 2010, Giacomo Boccardo wrote:

  When I try to inspect the file in the attachment (PKCS#7, DER format) I 
 have the following error:

 $ openssl pkcs7 -inform DER -in cadesBES_singleCounterSignatureWithDate.p7m
 unable to load PKCS7 object
 2491:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong 
 tag:tasn_dec.c:1316:
 2491:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 
 error:tasn_dec.c:380:Type=PKCS7_ISSUER_AND_SERIAL
 2491:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested 
 asn1 error:tasn_dec.c:748:Field=issuer_and_serial, Type=PKCS7_SIGNER_INFO
 2491:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested 
 asn1 error:tasn_dec.c:709:Field=signer_info, Type=PKCS7_SIGNED
 2491:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested 
 asn1 error:tasn_dec.c:748:
 2491:error:0D08403A:asn1 encoding routines:ASN1_TEMPLATE_EX_D2I:nested asn1 
 error:tasn_dec.c:578:Field=d.sign, Type=PKCS7

 Is it possible that it's trying to look for an IssuerAndSerialNumber 
 structure, even if I'm using a SubjectKeyIdentifier one?


The smime command uses PKCS#7 which doesn't include the SKID option. Use the
cms command instead.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

PKCS#7 and CMS Signed-And-Enveloped-Data command line

[Federico Berton]

Hi guys,

I have to create a program following the PKCS#7 standard with 
Signed-And-Enveloped-Data datatype:


SignedAndEnvelopedData ::= SEQUENCE {
version Version,
recipientInfos RecipientInfos,
digestAlgorithms DigestAlgorithmIdentifiers,
encryptedContentInfo EncryptedContentInfo,
certificates
[0] IMPLICIT ExtendedCertificatesAndCertificates OPTIONAL,
crls
[1] IMPLICIT CertificateRevocationLists OPTIONAL,
signerInfos SignerInfos
}
DigestAlgorithmIdentifiers ::=SET OF DigestAlgorithmIdentifier
SignerInfos ::= SET OF SignerInfo


and I have to use CMS for enveloping.

Can I do this with a command-line like

openssl cms -sign -in myfile.xml -signer sender.crt -inkey sender.key -binary \
| openssl cms -compress \
| openssl cms -encrypt -des3 -out signed-and-enveloped.data 
recipient.crt


Thanks in advance.


FEDERICO BERTON
AREA SVILUPPO

Via Europa, 20
35015 Galliera Veneta (PD)
TEL. 049.9988200 FAX 049.9471337
http://www.trivenet.it
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Save a pkcs#7 structure to a file

[Federico Berton]

Hi guys, I am trying to save a pkcs#7 structure with sign-and-enveloped data to 
a file but I can't find the appropriate function. I know that i should use 
somewhat kind of BIO. Can somebody help me?

Thanks in advance and sorry for my bad english.

Berton Federico
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Save a pkcs#7 structure to a file

[Dr. Stephen Henson]

On Wed, Jun 23, 2010, Federico Berton wrote:

 Hi guys, I am trying to save a pkcs#7 structure with sign-and-enveloped data
 to a file but I can't find the appropriate function. I know that i should
 use somewhat kind of BIO. Can somebody help me?
 

i2d_PKCS7_bio() will work but you don't have to use a BIO. You can use
i2d_PKCS7_fp() too. Make sure the fp is in binary mode.

Stev.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Verifying PKCS#7

[Niels Stevens]

Hey I'm using this code to verify my PKCS#7 signed object and extract it from 
the S/MIME
This code works perfectly if I test it with boost and send a mock SMIME to it. 
This mock up is generated with OpenSSL.

But I'm trying to verify a S/MIME with the same structure that has been 
generated by Bouncy Castle in Java.
Every time I try this I get a error that is thrown by the verify_callback 
function saying the certifcates can't be verified ! But I'm using the same 
certifcates as with OpenSSL !
Any body any advise on how to fix this ?
Thanks a lot !

Regards,

Niels Stevens

//X509_STORE setup. 
int verify_callback(int ok, X509_STORE_CTX *stor)
{
//userfriendly error handlin = 
X509_verify_cert_error_string(stor-error)
if (!ok) 
cout  
X509_verify_cert_error_string(stor-error)  endl;
//throw CCToolsException(QObject::tr(Error 
with certificate store !).toLatin1(), SC_ERROR_UNKNOWN );

return ok;
}

X509_STORE * create_store() 
{
X509_STORE *store   = NULL; 
X509 *caCert= NULL;
BIO *cc = NULL;

/* create the cert store and set the verify callback */ 
if (!(store = X509_STORE_new()))
{
KILL_STORE(store);
throw CCToolsException(QObject::tr(Error creating 
X509_STORE_CTX object!).toLatin1(), SC_ERROR_UNKNOWN);
}

X509_STORE_set_verify_cb_func(store, verify_callback);

if(!(cc = BIO_new(BIO_s_mem())) || 
   !(BIO_puts(cc, ZETES_CA)) || 
   !(caCert = PEM_read_bio_X509(cc, NULL, NULL, NULL)) || 
   !(X509_STORE_add_cert(store,caCert)))
{
KILL_BIO(cc);
throw CCToolsException(QObject::tr(Error adding cert 
to X509_STORE_CTX object!).toLatin1(), SC_ERROR_UNKNOWN);  
  
}

X509_free(caCert);
KILL_BIO(cc);

if (X509_STORE_set_default_paths(store) != 1)
{
KILL_STORE(store);
throw CCToolsException(QObject::tr(Error loading the 
system-wide CA certificates!).toLatin1(), SC_ERROR_UNKNOWN);
}

return store; 
}

const bool CCToolsLocal::validateChallengeSignature(const std::string 
message)
{
X509_STORE *rootStore   = NULL;
BIO *in = NULL;
BIO *pkcs7_bio  = NULL;
PKCS7 *pkcs7= NULL;
BUF_MEM *bptr   = NULL;

std:string json_domain;

authenticationFlag = false;

cout  message  endl;

if (!(rootStore = create_store()))
{
KILL_STORE(rootStore);
return false;
}
cout  store created succes  endl;

if (!(in = BIO_new(BIO_s_mem())) || 
!(BIO_puts(in, message.c_str(
{
KILL_BIO(in);
KILL_STORE(rootStore);
return false;
}
cout  bio's created succes  endl;
//used to set mem bio react like file bio
BIO_set_mem_eof_return(in, 0);

if (!(pkcs7 = SMIME_read_PKCS7(in, pkcs7_bio))) 
{
//char buf[200];
//ERR_error_string(ERR_peek_last_error(),buf);
//cout  buf  endl;
KILL_BIO(in);
KILL_BIO(pkcs7_bio);
KILL_STORE(rootStore);
return false;
}
cout  Smime_read_pkcs7 succes  endl;

BIO *json_bio = BIO_new(BIO_s_mem());

if (PKCS7_verify(pkcs7, NULL, rootStore, pkcs7_bio, json_bio, 
0) != 1)
{
char buf[200];
ERR_error_string(ERR_peek_last_error(),buf);
cout  buf  endl;
KILL_BIO(in);
KILL_BIO(pkcs7_bio);
KILL_BIO(json_bio);
KILL_STORE(rootStore

Re: PKCS#7 extract and verify certificate?

[Steffen DETTMER]

* Eisenacher, Patrick wrote on Tue, Feb 23, 2010 at 12:30 +0100:
 [...] 
 The selection of a trust anchor is a matter of policy: it
could be the top CA in a hierarchical PKI, the CA that
issued the verifier's own certificate(s), or any other CA in
a network PKI.
 
 And no, I don't need a separate truststore for subordinate-CAs.
 I have one truststore into which I put those certs that I
 trust. I only have to build up and verify a path up to a cert
 in my truststore. After all, a trust anchor is just that: an
 anchor of trust. I don't need to verify further, when I trust
 that entity.

I think using a sub-CA as trust anchor might even seem stronger,
because base-security is bound to cryptographic keys instead on
some subject's string content. When relying on some subject's
string content, let's say evaluating whether O=MyOrg, legally
ascertained contracts with all(!) super-CA's might be required to
ensure that none else never ever will also get O=MyOrg - even if
in some special closed group in a country on the other side of
the globe has a special sub-CA, this must never ever issue
O=MyOrg. I think this comes close to requiring that all sub-CAs
must be trusted. Knowing that there are sometimes
lower-security-level sub-CAs for personal mail certificates or
alike, this might seem weak. Writing complex string matching
rules seem to be complex and thus error prone.

Am I wrong? Corrections appreciated!

In practice someone might not use the sub-CAs `ordinary'
certificate but might want to use a `root' certificate
(self-signed by the sub-CA). For the use case that only
certificates by this sub-CA shall be accepted, I think it is OK
to make this to be the `local root CA'.

 Things get differently of course, if you do revocation
 checking, in which case you always have to build up the whole
 path from ee to root-ca. But I stated that before and we both
 agree on that.

I think this also might depend on policy. If I would buy a sub CA
certificate MyOrg from ACME-CA and later have a special context
where I have reject all non-MyOrg certified chains and having
MyOrg as trust anchor, I might not be allowed according to the
policy to give ACME-CA the theoretic possibility to revoke the
MyOrg trust anchor (because it is the anchor and by definition
the root of any [all] trust).

Is this correct or fails it elsewhere?

Also I could imagine that MyOrg is (cross-) certified by many
super-CAs, maybe because it also issues web server certificates
and a root CA known by default in major browsers might be
desired.

I would not trust any ordinary end-user CA enough that they never
ever will generate a MyOrg certificate if for example a valid
business company has the correct valid official name MyOrg.

Also, when having multiple root-CAs as trust anchors, how to
ensure that none of the root-CAs never ever certifies MyOrg for
someone else...

So best here probably is to use a self-signed MyOrg certificate,
but I think when doing this confusing and trouble could occure
when in one chain MyOrg is self-signed but in the peer chain it
is not or other conditions?

  Yes, it is probably a limitation to OpenSSL that it doesn't
  really have a
  Trust Anchor only store, but if you take a look at most major
  implementations (US DoD, FBCA, CertiPath, SAFE, etc.) then
  they pretty much
  always use self signed root certs as the trust anchor.
 
 openssl has a truststore. It just doesn't allow to trust
 subordinate-cas that I intentionally put in there to be
 trusted. And that's what I consider a limitation. 

Yes, even if sub-CAs are locally avialable (trusted), they are
not trusted. I felt this confusing.

 So suppose, verisign has 2 subordinate-cas, one for securely
 registered ees, and one for not so securely registered ees,
 both subordinate-cas have a common verisign root-ca, and both
 have the same policy identifier or none at all in their certs.

I guess you cannot get a written contract (without paying heaps
of money at least :)) from verisign guaranteeing that they never
ever will make a third sub-CA with some property clashing with
the implemented path-verification/policy algorithm.

 How would I achieve my goal to only accept ees certified by the
 secure registration ca? This should be a common scenario after
 all.

I've read a few specifications requiring that an official public
CA shall be used to obtain certificates but not requiring to
perform any subject content checking, which, if really someone
would implement it this way, would allow anyone to obtain a
certificate by this public CA. By this, he is authenticated but
not neccesarily authorized, but often it seems both are not
separated strongly enough (in terms of high security, i.e. as
secured as the certificate itself is).

oki,

Steffen

-- 






















































--[ end of message ]---8===


 
About Ingenico: Ingenico is a leading provider of payment solutions, with over 
15 

Re: PKCS#7 extract and verify certificate?

[Patrick Patterson]

On February 22, 2010 09:18:25 am Eisenacher, Patrick wrote:
  -Original Message-
  From: Patrick Patterson
 
  On 12/02/10 8:51 AM, skillz...@gmail.com wrote:
   Is there a way (via the API rather than the tool) to tell
 
  OpenSSL that
 
   the sub-CA certificate is trusted and it doesn't need to
 
  walk further
 
   up the chain? For my case, I embed the sub-CA certificate in my code
   and I'm space constrained so I'd prefer to not include the entire
   certificate chain.
 
  According to RFC5280 this is not allowed (See section 6).
  Given that if
  the Root revokes the Sub-CA, the EE cert is invalid, you have to check
  the entire chain to ensure that all parts are still valid. As a rule,
  you can only use self-signed certificates as trust anchors.

 This is not true. You only have to do path validation up to your trust
 anchor, whatever that is, be it a root-ca, an subordinate-ca or even an ee.
 Only if you check for revocation you have to walk up the whole chain from
 ee to root-ca.

According to RFC5280 (Section 6.1) - the following is the basic requirement 
for Path Validation:

The primary goal of path validation is to verify the binding between
   a subject distinguished name or a subject alternative name and
   subject public key, as represented in the target certificate, based
   on the public key of the trust anchor.  In most cases, the target
   certificate will be an end entity certificate, but the target
   certificate may be a CA certificate as long as the subject public key
   is to be used for a purpose other than verifying the signature on a
   public key certificate.  Verifying the binding between the name and
   subject public key requires obtaining a sequence of certificates that
   support that binding.  The procedure performed to obtain this
   sequence of certificates is outside the scope of this specification.

To meet this goal, the path validation process verifies, among other
   things, that a prospective certification path (a sequence of n
   certificates) satisfies the following conditions:

  (a)  for all x in {1, ..., n-1}, the subject of certificate x is
   the issuer of certificate x+1;

  (b)  certificate 1 is issued by the trust anchor;

  (c)  certificate n is the certificate to be validated (i.e., the
   target certificate); and

  (d)  for all x in {1, ..., n}, the certificate was valid at the
   time in question.


If you DON'T use a self signed trust anchor, then you have to have special 
processing instructions, and/or have a certificate store that is able to 
absolutely treat a certificate differently when it is part of a chain, or when 
it is a trust anchor (for, and the reason why most Root CA profiles don't have 
CRL DP or OCSP info in them, a trust anchor is NOT checked for validity - it 
is assumed by its continued presence as a Trust Anchor to be valid).

Yes, it is probably a limitation to OpenSSL that it doesn't really have a 
Trust Anchor only store, but if you take a look at most major 
implementations (US DoD, FBCA, CertiPath, SAFE, etc.) then they pretty much 
always use self signed root certs as the trust anchor.

 Unfortunately, the perceived verification algorithm is a limitation in
 openssl, which always wants to do path validation up to a self signed cert,
 even if no revocation checking is requested. And no, there's no way to
 modify its verification algorithm besides from changing the code.

 This also has consequences for applications using openssl for ssl support
 like apache, where you can not easily configure to authenticate only those
 clients presenting a cert that was issued by a specific subordinate-ca.

From a design point of view - why not use a self signed Root CA as the trust 
anchor, but policy or name constrain the sub CA, and then issue EE certs with 
the appropriate Policy or Name space? This accomplishes the same thing as what 
you want to do, is probably better PKI (why do you only trust that one CA - 
probably because of the policy it is issuing the certs under), and is fully 
supportable today.

as an example:

Root CA --- SubCA1  (Policy 1.2.3.4,- EE (Policy 1.2.3.4)
 |  Namespace email = foo.com)  (email 
b...@foo.com)
 \
   \ -- SubCA2 (Policy 2.3.4.5, - EE (policy 2.3.4.5)
 Namespace bar.com)  (email 
c...@bar.com)   


Then, you could configure Apache to accept the Root CA, and, either using your 
application on that server, or some tool (like Pathfinder), to constrain on 
Policy.

To do otherwise is probably against the Relying Party provisions of the PKI 
provider policy (who, at the end of the day, is the one who says which of its 
certificates can be used as a Trust Anchor) - most policies that I know of 
basically say that if the PKI has revoked any certificate in that PKI, and the 
Relying Party doesn't check for that,  then any use of 

RE: PKCS#7 extract and verify certificate?

[Eisenacher, Patrick]

Hi Patrick,

sorry for the bad line-breaking, but I'm stuck here with a poor msa.

 -Original Message-
 From: Patrick Patterson

 On February 22, 2010 09:18:25 am Eisenacher, Patrick wrote:
   -Original Message-
   From: Patrick Patterson
  
   On 12/02/10 8:51 AM, skillz...@gmail.com wrote:
Is there a way (via the API rather than the tool) to tell
  
   OpenSSL that
  
the sub-CA certificate is trusted and it doesn't need to
  
   walk further
  
up the chain? For my case, I embed the sub-CA
 certificate in my code
and I'm space constrained so I'd prefer to not include
 the entire
certificate chain.
  
   According to RFC5280 this is not allowed (See section 6).
   Given that if
   the Root revokes the Sub-CA, the EE cert is invalid, you
 have to check
   the entire chain to ensure that all parts are still
 valid. As a rule,
   you can only use self-signed certificates as trust anchors.
 
  This is not true. You only have to do path validation up to
 your trust
  anchor, whatever that is, be it a root-ca, an
 subordinate-ca or even an ee.
  Only if you check for revocation you have to walk up the
 whole chain from
  ee to root-ca.
 
 According to RFC5280 (Section 6.1) - the following is the
 basic requirement
 for Path Validation:

 The primary goal of path validation is to verify the binding between
a subject distinguished name or a subject alternative name and
subject public key, as represented in the target certificate, based
on the public key of the trust anchor.  In most cases, the target
certificate will be an end entity certificate, but the target
certificate may be a CA certificate as long as the subject
 public key
is to be used for a purpose other than verifying the signature on a
public key certificate.  Verifying the binding between the name and
subject public key requires obtaining a sequence of
 certificates that
support that binding.  The procedure performed to obtain this
sequence of certificates is outside the scope of this
 specification.

 To meet this goal, the path validation process verifies, among other
things, that a prospective certification path (a sequence of n
certificates) satisfies the following conditions:

   (a)  for all x in {1, ..., n-1}, the subject of certificate x is
the issuer of certificate x+1;

   (b)  certificate 1 is issued by the trust anchor;

   (c)  certificate n is the certificate to be validated (i.e., the
target certificate); and

   (d)  for all x in {1, ..., n}, the certificate was valid at the
time in question.
 

 If you DON'T use a self signed trust anchor, then you have to
 have special
 processing instructions, and/or have a certificate store that
 is able to
 absolutely treat a certificate differently when it is part of
 a chain, or when
 it is a trust anchor (for, and the reason why most Root CA
 profiles don't have
 CRL DP or OCSP info in them, a trust anchor is NOT checked
 for validity - it
 is assumed by its continued presence as a Trust Anchor to be valid).

The section you quote says absolutely nothing about self signed trust anchors. 
This seems to be your own interpretation. Where did you get it from? If you 
scroll just a few paragraphs further up you will see that a trust anchor can be 
any entitiy in your PKI:

The selection of a trust anchor is a matter of policy: it could be
the top CA in a hierarchical PKI, the CA that issued the verifier's
own certificate(s), or any other CA in a network PKI.

And no, I don't need a separate truststore for subordinate-CAs. I have one 
truststore into which I put those certs that I trust. I only have to build up 
and verify a path up to a cert in my truststore. After all, a trust anchor is 
just that: an anchor of trust. I don't need to verify further, when I trust 
that entity.

Things get differently of course, if you do revocation checking, in which case 
you always have to build up the whole path from ee to root-ca. But I stated 
that before and we both agree on that.

 Yes, it is probably a limitation to OpenSSL that it doesn't
 really have a
 Trust Anchor only store, but if you take a look at most major
 implementations (US DoD, FBCA, CertiPath, SAFE, etc.) then
 they pretty much
 always use self signed root certs as the trust anchor.

openssl has a truststore. It just doesn't allow to trust subordinate-cas that I 
intentionally put in there to be trusted. And that's what I consider a 
limitation. And I don't understand what Eric's intention was when he originally 
coded that algorithm. Of course, path construction and verification is a beast 
to code and there are many pitfalls to fall into.

There are other sdks around that do not have this limitation. I worked for one 
of their manufacturers long time ago.

  Unfortunately, the perceived verification algorithm is a
 limitation in
  openssl, which always wants to do path validation up to a
 self signed 

Re: PKCS#7 extract and verify certificate?

[Dr. Stephen Henson]

On Mon, Feb 22, 2010, Eisenacher, Patrick wrote:

 
 Unfortunately, the perceived verification algorithm is a limitation in
 openssl, which always wants to do path validation up to a self signed cert,
 even if no revocation checking is requested. And no, there's no way to
 modify its verification algorithm besides from changing the code.
 

While it does technically need a modification of the verification algorithm it
is possible to customise its behaviour using the verify callback.

If a chain contains no trusted certificates you get the error:

X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY

if it contains at least one trusted certificate you instead get:

X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT

if you ignore the latter error that should work.

[I've just noticed the documentation says the opposite of the above, arg!]

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: PKCS#7 extract and verify certificate?

[Eisenacher, Patrick]

 -Original Message-
 From: Patrick Patterson

 On 12/02/10 8:51 AM, skillz...@gmail.com wrote:
  Is there a way (via the API rather than the tool) to tell
 OpenSSL that
  the sub-CA certificate is trusted and it doesn't need to
 walk further
  up the chain? For my case, I embed the sub-CA certificate in my code
  and I'm space constrained so I'd prefer to not include the entire
  certificate chain.

 According to RFC5280 this is not allowed (See section 6).
 Given that if
 the Root revokes the Sub-CA, the EE cert is invalid, you have to check
 the entire chain to ensure that all parts are still valid. As a rule,
 you can only use self-signed certificates as trust anchors.

This is not true. You only have to do path validation up to your trust anchor, 
whatever that is, be it a root-ca, an subordinate-ca or even an ee. Only if you 
check for revocation you have to walk up the whole chain from ee to root-ca.

Unfortunately, the perceived verification algorithm is a limitation in openssl, 
which always wants to do path validation up to a self signed cert, even if no 
revocation checking is requested. And no, there's no way to modify its 
verification algorithm besides from changing the code.

This also has consequences for applications using openssl for ssl support like 
apache, where you can not easily configure to authenticate only those clients 
presenting a cert that was issued by a specific subordinate-ca.


Patrick Eisenacher


Besuchen Sie die Bundesdruckerei auf der CeBIT 2010 vom 2.-6.3.2010, Halle 9, 
Stand D80
Visit Bundesdruckerei at CeBIT, exhibition centre, hall 9 / stand D80

weitere Informationen unter: 
http://www.bundesdruckerei.de/de/unternehmen/untern_cebit2010/index.html
find more information here 
http://www.bundesdruckerei.de/en/company/comp_cebit2010/index.html
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: PKCS#7 extract and verify certificate?

[skillzero]

On Thu, Feb 11, 2010 at 1:31 PM,  skillz...@gmail.com wrote:
 I have a DER-encoded PKCS#7 file that I'd like to extract the
 certificate from, verify that certificate against a specific sub-CA
 certificate, then use the certificate's public key to verify a
 signature.

 I looked at the code for the pkcs7 tool and it looks directly inside
 the PKCS7 object to check the type and extract the X509 certificates.
 Is that the best way to do it? Is there a way that doesn't require
 relying on the internal structure of the PKCS7 object?

 When I try to verify the certificate, it fails with unable to get
 local issuer certificate. However, I've added my sub-CA certificate
 to the X509_STORE object and if I look inside the certificate I'm
 verifying, its X509v3 Authority Key Identifier matches the sub-CA's
 X509v3 Subject Key Identifier. I've verified using another tool
 (Keychain on a Mac, which may use OpenSSL underneath) that the
 certificate chain is valid. I'm able to use OpenSSL programmatically
 verify that the sub-CA certificate is valid against the root, but not
 the leaf certificate against the sub-CA certificate. Is there
 something I'm missing?

I figured out that if I use 'openssl verify -CAfile root.pem
-untrusted subCA.pem cert.pem' then it works and returns OK. So it
seems that even if I specify the sub-CA certificate as the -CAfile, it
needs the full chain.

Is there a way (via the API rather than the tool) to tell OpenSSL that
the sub-CA certificate is trusted and it doesn't need to walk further
up the chain? For my case, I embed the sub-CA certificate in my code
and I'm space constrained so I'd prefer to not include the entire
certificate chain.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: PKCS#7 extract and verify certificate?

[Patrick Patterson]

On 12/02/10 8:51 AM, skillz...@gmail.com wrote:
 Is there a way (via the API rather than the tool) to tell OpenSSL that
 the sub-CA certificate is trusted and it doesn't need to walk further
 up the chain? For my case, I embed the sub-CA certificate in my code
 and I'm space constrained so I'd prefer to not include the entire
 certificate chain.

According to RFC5280 this is not allowed (See section 6). Given that if
the Root revokes the Sub-CA, the EE cert is invalid, you have to check
the entire chain to ensure that all parts are still valid. As a rule,
you can only use self-signed certificates as trust anchors.



Have fun.

Patrick.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

PKCS#7 extract and verify certificate?

[skillzero]

I have a DER-encoded PKCS#7 file that I'd like to extract the
certificate from, verify that certificate against a specific sub-CA
certificate, then use the certificate's public key to verify a
signature.

I looked at the code for the pkcs7 tool and it looks directly inside
the PKCS7 object to check the type and extract the X509 certificates.
Is that the best way to do it? Is there a way that doesn't require
relying on the internal structure of the PKCS7 object?

When I try to verify the certificate, it fails with unable to get
local issuer certificate. However, I've added my sub-CA certificate
to the X509_STORE object and if I look inside the certificate I'm
verifying, its X509v3 Authority Key Identifier matches the sub-CA's
X509v3 Subject Key Identifier. I've verified using another tool
(Keychain on a Mac, which may use OpenSSL underneath) that the
certificate chain is valid. I'm able to use OpenSSL programmatically
verify that the sub-CA certificate is valid against the root, but not
the leaf certificate against the sub-CA certificate. Is there
something I'm missing?
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

sign digest and build pkcs#7

[Jaraba Nieto, Fernando]

 

I would know if it's possible with openssl to sign a digest message,
without using the original document. If it's then I can send hash digest
to the client and receive signed hash to build pkcs#7 structure.
 
Thanks a lot

 

 

Fernando.

 

Re: sign digest and build pkcs#7

[Dr. Stephen Henson]

On Thu, Jan 28, 2010, Jaraba Nieto, Fernando wrote:

  
 
 I would know if it's possible with openssl to sign a digest message,
 without using the original document. If it's then I can send hash digest
 to the client and receive signed hash to build pkcs#7 structure.
  

It is possible using the CMS routines which can be compatible with PKCS#7.
There aren't any examples of this but in outline you'd:

Create CMS SignedData structure using CMS_sign().
Add a signer using CMS_add1_signer().
Add message digest using CMS_signed_add1_attr_by_NID().
Sign structure using CMS_SignerInfo_sign().

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

PKCS#7 enveloped message

[Douglas Gemignani]

Hello,

I need to generate a pkcs#7 certificate with a enveloped message
inside it. As far as I understand this message (X509) will be
encrypted with a random generated TDES key.
This is my snippet, but it is still incomplete and some comments
regarding my doubts, I hope someone could help me!!

//Load rsa key above
data=BIO_new_file(file.txt,r);
recipient=PEM_read_bio_X509(data,NULL,NULL,NULL);
PKCS7_set_type(p7, NID_pkcs7_enveloped);
PKCS7_add_recipient(p7, recipient);
EVP_PKEY_assign_RSA(pkey, rsa); //how will this RSA key be used??
pkey = EVP_PKEY_new();
EVP_PKEY_assign_RSA(pkey, rsa);
PKCS7_set_cipher(p7, EVP_des_ede3_cbc()); //TDES generated here

/*
BIO_puts(data, Hello World!); //so here is my data?
if ((p7bio = PKCS7_dataInit (p7,NULL)) == NULL) goto err;
for (;;){
i=BIO_read(data,buf,sizeof(buf));
if (i = 0) break;
BIO_write(p7bio,buf,i);
}
BIO_flush(p7bio);

PKCS7_dataFinal(p7, p7bio);*/
PEM_write_PKCS7(stdout,p7);

Thanks,

[]s
Douglas Gemignani
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: PKCS#7 enveloped message

[Dr. Stephen Henson]

On Tue, Jan 12, 2010, Douglas Gemignani wrote:

 Hello,
 
 I need to generate a pkcs#7 certificate with a enveloped message
 inside it. As far as I understand this message (X509) will be
 encrypted with a random generated TDES key.
 This is my snippet, but it is still incomplete and some comments
 regarding my doubts, I hope someone could help me!!
 
 //Load rsa key above
 data=BIO_new_file(file.txt,r);
 recipient=PEM_read_bio_X509(data,NULL,NULL,NULL);
 PKCS7_set_type(p7, NID_pkcs7_enveloped);
 PKCS7_add_recipient(p7, recipient);
 EVP_PKEY_assign_RSA(pkey, rsa); //how will this RSA key be used??
 pkey = EVP_PKEY_new();
 EVP_PKEY_assign_RSA(pkey, rsa);
 PKCS7_set_cipher(p7, EVP_des_ede3_cbc()); //TDES generated here
 
 /*
 BIO_puts(data, Hello World!); //so here is my data?
 if ((p7bio = PKCS7_dataInit (p7,NULL)) == NULL) goto err;
 for (;;){
 i=BIO_read(data,buf,sizeof(buf));
 if (i = 0) break;
 BIO_write(p7bio,buf,i);
 }
 BIO_flush(p7bio);
 
 PKCS7_dataFinal(p7, p7bio);*/
 PEM_write_PKCS7(stdout,p7);
 
 

Look at the PKCS7_encrypt() manual page and demos/smime/smenc.c

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: PKCS#7 enveloped message

[Douglas Gemignani]

This looks like a recent change in the v1.0.0 beta
  *) Update PKCS#7 enveloped data routines to use new API. This is now
 supported by any public key method supporting the encrypt operation. A
 ctrl is added to allow the public key algorithm to examine or modify
 the PKCS#7 RecipientInfo structure if it needs to: for RSA this is
 a no op.
 [Steve Henson]

I'm still using version 0.9.8k. I rather not use beta editions!

I noticed the magic in the API is encapsulated here now:

in = BIO_new_file(encr.txt, r);
if (!in)goto err;

/* encrypt content */
p7 = PKCS7_encrypt(recips, in, EVP_des_ede3_cbc(), flags);

It probably setups the p7 struct and calls PKCS7_dataInit and PKCS7_dataFinal

[]s
Douglas Gemignani



On Tue, Jan 12, 2010 at 2:59 PM, Dr. Stephen Henson st...@openssl.org wrote:
 On Tue, Jan 12, 2010, Douglas Gemignani wrote:

 Hello,

 I need to generate a pkcs#7 certificate with a enveloped message
 inside it. As far as I understand this message (X509) will be
 encrypted with a random generated TDES key.
 This is my snippet, but it is still incomplete and some comments
 regarding my doubts, I hope someone could help me!!

 //Load rsa key above
 data=BIO_new_file(file.txt,r);
 recipient=PEM_read_bio_X509(data,NULL,NULL,NULL);
 PKCS7_set_type(p7, NID_pkcs7_enveloped);
 PKCS7_add_recipient(p7, recipient);
 EVP_PKEY_assign_RSA(pkey, rsa); //how will this RSA key be used??
 pkey = EVP_PKEY_new();
 EVP_PKEY_assign_RSA(pkey, rsa);
 PKCS7_set_cipher(p7, EVP_des_ede3_cbc()); //TDES generated here

 /*
 BIO_puts(data, Hello World!); //so here is my data?
 if ((p7bio = PKCS7_dataInit (p7,NULL)) == NULL) goto err;
 for (;;){
 i=BIO_read(data,buf,sizeof(buf));
 if (i = 0) break;
 BIO_write(p7bio,buf,i);
 }
 BIO_flush(p7bio);

 PKCS7_dataFinal(p7, p7bio);*/
 PEM_write_PKCS7(stdout,p7);



 Look at the PKCS7_encrypt() manual page and demos/smime/smenc.c

 Steve.
 --
 Dr Stephen N. Henson. OpenSSL project core developer.
 Commercial tech support now available see: http://www.openssl.org
 __
 OpenSSL Project                                 http://www.openssl.org
 User Support Mailing List                    openssl-us...@openssl.org
 Automated List Manager                           majord...@openssl.org

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: PKCS#7 enveloped message

[Dr. Stephen Henson]

On Tue, Jan 12, 2010, Douglas Gemignani wrote:

 This looks like a recent change in the v1.0.0 beta
   *) Update PKCS#7 enveloped data routines to use new API. This is now
  supported by any public key method supporting the encrypt operation. A
  ctrl is added to allow the public key algorithm to examine or modify
  the PKCS#7 RecipientInfo structure if it needs to: for RSA this is
  a no op.
  [Steve Henson]
 
 I'm still using version 0.9.8k. I rather not use beta editions!


That's an enhancement to the PKCS7 API which you wont need for your purposes.
The support in OpenSSL 0.9.8k and earlier should suffice.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: S/MIME pkcs#7 read from membuf problem

[Anton D Kachalov]

Ger Hobbelt wrote:

What may have impact here is that a memory s/s BIO does not act like a
file BIO by default.
To get the same behaviour (at end-of-data == End of File), you should
add the call

BIO_set_mem_eof_return(pio, 0);

after the line

  

pio = BIO_new(BIO_s_mem())



to ensure you'll get a regular EOF signal when the memory buffer has
been read in its entirety.
  


Thank you very much, Ger!!!
It works!

Rgds,
Anton
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

S/MIME pkcs#7 read from membuf problem

[Anton D Kachalov]

Good day!

I have problem with reading S/MIME PKCS#7 container from membuf. I've 
got not enough data error in ASN parsing routine (asn1_d2i_read_bio).
I have sign  crypt zip file (430kb) with S/MIME PKCS#7 within PHP. Then 
I wrote a small application to decrypt  verify:

/* Decrypt */
in = BIO_new_file(sign_n_enc.file, rb)
pio = BIO_new(BIO_s_mem())
p7 = SMIME_read_PKCS7(in)
PKCS7_decrypt(p7, key, recip, pio, 0)
/* Verify */
p7 = SMIME_read_PKCS7(pio, datain)
PKCS7_verify(p7, NULL, store, datain, out, 0)

If I create pio as:
  pio = BIO_new_file(_tmpfile_, w+)
p7 = SMIME_read_PKCS7(in)
PKCS7_decrypt(p7, key, recip, pio, 0)
  BIO_seek(pio, 0)
p7 = SMIME_read_PKCS7(pio,...)
PKCS7_verify(p7, NULL, store, datain, out, 0)

Then I would be success in verify.
My OpenSSL version is 0.9.8j.

Rgds,
Anton
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: S/MIME pkcs#7 read from membuf problem

[Ger Hobbelt]

What may have impact here is that a memory s/s BIO does not act like a
file BIO by default.
To get the same behaviour (at end-of-data == End of File), you should
add the call

BIO_set_mem_eof_return(pio, 0);

after the line

 pio = BIO_new(BIO_s_mem())

to ensure you'll get a regular EOF signal when the memory buffer has
been read in its entirety.



On Thu, Apr 9, 2009 at 12:59 PM, Anton D Kachalov mo...@altlinux.org wrote:
 Good day!

 I have problem with reading S/MIME PKCS#7 container from membuf. I've got
 not enough data error in ASN parsing routine (asn1_d2i_read_bio).
 I have sign  crypt zip file (430kb) with S/MIME PKCS#7 within PHP. Then I
 wrote a small application to decrypt  verify:
 /* Decrypt */
 in = BIO_new_file(sign_n_enc.file, rb)
 pio = BIO_new(BIO_s_mem())
 p7 = SMIME_read_PKCS7(in)
 PKCS7_decrypt(p7, key, recip, pio, 0)
 /* Verify */
 p7 = SMIME_read_PKCS7(pio, datain)
 PKCS7_verify(p7, NULL, store, datain, out, 0)

 If I create pio as:
  pio = BIO_new_file(_tmpfile_, w+)
 p7 = SMIME_read_PKCS7(in)
 PKCS7_decrypt(p7, key, recip, pio, 0)
  BIO_seek(pio, 0)
 p7 = SMIME_read_PKCS7(pio,...)
 PKCS7_verify(p7, NULL, store, datain, out, 0)

 Then I would be success in verify.
 My OpenSSL version is 0.9.8j.

 Rgds,
 Anton
 __
 OpenSSL Project                                 http://www.openssl.org
 User Support Mailing List                    openssl-us...@openssl.org
 Automated List Manager                           majord...@openssl.org




-- 
Met vriendelijke groeten / Best regards,

Ger Hobbelt

--
web:http://www.hobbelt.com/
http://www.hebbut.net/
mail:   g...@hobbelt.com
mobile: +31-6-11 120 978
--
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

PKCS#7 SignedData and multiple digest algorithms

[John Firebaugh]

Hi,

I'm investigating upgrading the applications I'm responsible for from
SHA1 as the default PKCS#7 SignedData digest algorithm to stronger
digests such as SHA256, in ways that preserve backwards compatibility
for signature verifiers which do not support digest algorithms other
than SHA1. I want to check my understanding of the PKCS#7 format and
available options.

What think I want to do is digest message content with both SHA1 and
SHA256 (or more generally, a set of digest algorithms) such that older
applications can continue to verify via the SHA1, and upgraded
applications can begin verifying via the SHA256 (more generally, the
strongest digest provided), ignoring the weaker algorithm(s). [If there
is a better approach, please let me know.]

It appears that within the PKCS#7 standard, the only way to provide
multiple digests is to provide multiple SignerInfos, one for each digest
algorithm. Unfortunately, this would seem to lead to a net *decrease* in
security, as an attacker is able to strip all but the the SignerInfo
with the weakest digest algorithm, which alone will still form a valid
signature. Is this understanding correct?

If so, my idea was to use custom attributes within the
authenticatedAttributes field of SignerInfo to provide additional
message-digests for the additional digest algorithms (leaving SHA1 as
the default algorithm for backwards compatibility). Since this field
is authenticated as a single block, this would prevent the above attack.
Does this seem like a viable approach? Is there a way to accomplish this
or something similar without going outside of the PKCS standard?

Thanks,
John
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

PKCS#7 symmetric keys

[Carl Young]

Hi all,

With OpenSSL, can I create PKCS#7 CMS messages just using a pre-shared 
symmetric key?


I just need to package the secret with its encryption algorithm identifier, 
and the PKCS#7 envelope looks ideal for this.


The only additional data that I may wish to add to the message may be the 
symmetric key identity, which would be a proprietary identifer. Is there any 
standard compliant way within PKCS#7 to add application specific extensions 
such as this?


Thanks for any assistance,

Carl

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Newbie certificate problem (using PKCS#7 in Apache)

[Jeffrey Lyon]

All,

I have what is probably going to be an extremely newbie
issue/question. I have a customer moving to us who uses Apache Tomcat
with a PKCS#7 certificate and an accompanying .key file which looks
rather foreign to me. Personally, i've never dealt with anything
outside of the plain vanilla SSL certificates used in normal
Apache.

Is there a way to convert these files for use with normal Apache?

Thanks,
-- 
Jeffrey Lyon, President
Level III Information Systems Technician
[EMAIL PROTECTED] | http://www.blacklotus.net
Black Lotus Communications of The IRC Company, Inc.

Talk for 4h 45m from the U.S. to Latin America for $10.00:
http://www.defensecalling.com
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Can OpenSSL parse SHA-2 within PKCS#7 objects?

[Travis]

I've been trying to get OpenSSL to parse PKCS#7 objects made with
BouncyCastle, which uses SHA-2 hashes in it.

However, I haven't had much luck.  I know that OpenSSL has support for
SHA-2 directly, but I think the ASN.1 parser is blowing up on the
particular NID/OID for SHA-2 hashes.

Does anyone here know that it does work?
Because all my work has suggested that it does not.
-- 
Crypto ergo sum.  https://www.subspacefield.org/~travis/
Truth does not fear scrutiny or competition, only lies do.
If you are a spammer, please email [EMAIL PROTECTED] to get blacklisted.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Can OpenSSL parse SHA-2 within PKCS#7 objects?

[Dr. Stephen Henson]

On Mon, Aug 04, 2008, Travis wrote:

 I've been trying to get OpenSSL to parse PKCS#7 objects made with
 BouncyCastle, which uses SHA-2 hashes in it.
 
 However, I haven't had much luck.  I know that OpenSSL has support for
 SHA-2 directly, but I think the ASN.1 parser is blowing up on the
 particular NID/OID for SHA-2 hashes.
 
 Does anyone here know that it does work?
 Because all my work has suggested that it does not.

What error are you getting from the command line tool?

If it is an ASN1 parsing error then this isn't down to OIDs more the format.
If BouncyCastle is using some CMS features you need to use the OpenSSL CMS
support and not PKCS#7.

If you still have problems please post a sample message OpenSSL has problems
with, mailed privately if you prefer.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

PKCS#7

[earthworm]

Hello,

Anybody know how I can extract the certificates from a chained PKCS#7
file? I can't seem to find the part of the API that deals with this,
although I can find lots of references to the command line program that
does it.

Thanks,

Gaz
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

No NID for SHA2 (was Re: unable to verify PKCS#7 objects signed with BC(CMS))

[travis+ml-users]

On Tue, May 27, 2008 at 03:23:27PM -0500, [EMAIL PROTECTED] wrote:
 So a developer at my company is having a problem.
 
 When our business partner signs a data object using Bouncy Castle
 (PKCS#7 CMS), outputs PEM, and we use OpenSSL and read it in, that
 works fine, but when we try to get the data out of it, we're getting a
 null string.
 
 My hunch is that PKCS7_dataDecode(p7, NULL, NULL, NULL) is returning
 null, but our library code is not throwing an exception.
 
 Does anyone have any experience with OpenSSL being unable to parse
 PKCS#7 objects created by BouncyCastle?

Problem is that remote peer is using DIGEST::SHA256.

EVP_get_digestbynid() is failing, apparently lacking support for SHA256.

I examined the latest OpenSSL distro and can't find any reference to
SHA256 in object.h; does anyone know if this is supported?

-- 
Crypto ergo sum.  https://www.subspacefield.org/~travis/
Truth does not fear scrutiny or competition, only lies do.
If you are a spammer, please email [EMAIL PROTECTED] to get blacklisted.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: No NID for SHA2 (was Re: unable to verify PKCS#7 objects signed with BC(CMS))

[Victor Duchovni]

On Wed, May 28, 2008 at 02:23:44PM -0500, [EMAIL PROTECTED] wrote:

 On Tue, May 27, 2008 at 03:23:27PM -0500, [EMAIL PROTECTED] wrote:
  So a developer at my company is having a problem.
  
  When our business partner signs a data object using Bouncy Castle
  (PKCS#7 CMS), outputs PEM, and we use OpenSSL and read it in, that
  works fine, but when we try to get the data out of it, we're getting a
  null string.
  
  My hunch is that PKCS7_dataDecode(p7, NULL, NULL, NULL) is returning
  null, but our library code is not throwing an exception.
  
  Does anyone have any experience with OpenSSL being unable to parse
  PKCS#7 objects created by BouncyCastle?
 
 Problem is that remote peer is using DIGEST::SHA256.
 
 EVP_get_digestbynid() is failing, apparently lacking support for SHA256.
 
 I examined the latest OpenSSL distro and can't find any reference to
 SHA256 in object.h; does anyone know if this is supported?

You need 0.9.8 and SSL_library_init() is not sufficient, this adds only
the SSL algorithms, you need to also call:

void OpenSSL_add_all_algorithms(void);
OR
void OpenSSL_add_all_digests(void);

-- 
Viktor.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

unable to verify PKCS#7 objects signed with BC(CMS)

[travis+ml-users]

So a developer at my company is having a problem.

When our business partner signs a data object using Bouncy Castle
(PKCS#7 CMS), outputs PEM, and we use OpenSSL and read it in, that
works fine, but when we try to get the data out of it, we're getting a
null string.

My hunch is that PKCS7_dataDecode(p7, NULL, NULL, NULL) is returning
null, but our library code is not throwing an exception.

Does anyone have any experience with OpenSSL being unable to parse
PKCS#7 objects created by BouncyCastle?
-- 
Crypto ergo sum.  https://www.subspacefield.org/~travis/
Truth does not fear scrutiny or competition, only lies do.
If you are a spammer, please email [EMAIL PROTECTED] to get blacklisted.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: PKCS#7 Api's help (Plz help me)

[Patrick Patterson]

Hi Shankar:

The functions in pkcs7.h look rather straightforward - I think the hint
you need is to not sign the data outside of the PKCS7 functions (don't
use RSA_sign), but instead, try using just the functions in pkcs7.h to
do what you want.

(I've never done what you're trying to do, so don't ask me for more
help, however, the above is how I'd go about tackling your problem).

Have fun.

Patrick.

shankar ks wrote:
 Hi Every body,
 
 Please help me for the following information . I am working on securtiy
 issues ,I have to   sign, compress, encrypty the file as CMS package. In
 order to fullfill conditions I have to use pkcs7 API's ( in C - Program).
 
 Let me give you some brief on my work :
 I have a file , I need to sign that file ( I signed the file using RSA_sign)
 funtion. ). once the file is signed I need to envelope the file as a CMS
 package.
 
 So Could any one who has prior knowledege on usage of pkcs function , please
 help me how to do this signing and verification  .
 If possible please give me the links where I can get data on these PKCS#7
 funtions ..
 
 please help me ,
 

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: PKCS#7 Api's help (Plz help me)

[shankar ks]

Hi Patrick ,
ThanQ for your information , my intention also to use pkcs funtions only ,
but the problem is I am not understanding how to use them.
for that only i am asking for any application program that will do the
signing and verification . and there is no clearity in those funtions which
algorithems they are using for signing and verification .

for suppose i gave some digested data (sha1) for signing , then i do not
know which algorightms or cipher suits it is using internally.

Best Regards
--Shankar


On 4/9/08, Patrick Patterson [EMAIL PROTECTED] wrote:

 Hi Shankar:

 The functions in pkcs7.h look rather straightforward - I think the hint
 you need is to not sign the data outside of the PKCS7 functions (don't
 use RSA_sign), but instead, try using just the functions in pkcs7.h to
 do what you want.

 (I've never done what you're trying to do, so don't ask me for more
 help, however, the above is how I'd go about tackling your problem).

 Have fun.

 Patrick.

 shankar ks wrote:
  Hi Every body,
 
  Please help me for the following information . I am working on securtiy
  issues ,I have to   sign, compress, encrypty the file as CMS package. In
  order to fullfill conditions I have to use pkcs7 API's ( in C -
 Program).
 
  Let me give you some brief on my work :
  I have a file , I need to sign that file ( I signed the file using
 RSA_sign)
  funtion. ). once the file is signed I need to envelope the file as a CMS
  package.
 
  So Could any one who has prior knowledege on usage of pkcs function ,
 please
  help me how to do this signing and verification  .
  If possible please give me the links where I can get data on these
 PKCS#7
  funtions ..
 
  please help me ,
 

 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   [EMAIL PROTECTED]




-- 
--Best Regards
Shankar

PKCS#7 Api's help (Plz help me)

[shankar ks]

Hi Every body,

Please help me for the following information . I am working on securtiy
issues ,I have to   sign, compress, encrypty the file as CMS package. In
order to fullfill conditions I have to use pkcs7 API's ( in C - Program).

Let me give you some brief on my work :
I have a file , I need to sign that file ( I signed the file using RSA_sign)
funtion. ). once the file is signed I need to envelope the file as a CMS
package.

So Could any one who has prior knowledege on usage of pkcs function , please
help me how to do this signing and verification  .
If possible please give me the links where I can get data on these PKCS#7
funtions ..

please help me ,

-- 
--Best Regards
Shankar

pkcs#7 Api's in openssl

[shankar ks]

Hi Every body,
I am working on securtiy issues , my job is sign, compress, encrypty the
file as CMS package. In order to fullfill conditions I have to use pkcs7
API's . but I did not understand how they will envelope the signed ,
compressed , encrypted data , and how they will be usefull for receiver .
 I am getting some example programs for the signing and encryption , but I
did not get any examples for the envelope of compression using pkcs
functions
If any body knows please give me information of these compression using pkcs
funtions and data regarding the implementation of the pkcs funtions (any
document or pdf or examples of signin, encryption , compression.) ..

and source which explains the usage of PKCS#7 API's in openssl...



-- 
--Best Regards
Shankar

PKCS#1 and PKCS#7

[Jaraba Nieto, Fernando]

We have singed a digest with RSA_sing and we have an PKCS#1. We need to 
transform from the PKCS#1 to a PKCS#7.

 

¿Do you know how to transform the PKCS#1 to a PKCS#7?

 

Thank you.

 

Fernando.

interop between OpenSSL PKCS#7 (v1.5) and BC (CMS)

[travis+ml-openssl]

So I've got to interchange data with a Java-based environment.  I
believe their choice of libraries is with Bouncy Castle, which IIUC
implements a newer version of PKCS#7 called CMS.  We only have OpenSSL,
which uses PKCS#7 v1.5..

Does anyone have experience with these kinds of situations?  It has
been very time-consuming, and the parsing issues are a real PITA.
Right now we've got BC to read signed v1.5 objects but it barfs on
encrypted objects with a padding error.
-- 
https://www.subspacefield.org/~travis/
I need a better strategy for being less analytical.
For a good time on my email blacklist, email [EMAIL PROTECTED]


pgpoku8IXJD9f.pgp
Description: PGP signature

PKCS#7 streaming in smime utility

[Harald Latzko]

Hello,

I've read the following in the latest CHANGES file of the openSSL  
0.9.9 snapshot 20071220:


  *) Add option -stream to use PKCS#7 streaming in smime utility. New
 function i2d_PKCS7_bio_stream() and PEM_write_PKCS7_bio_stream()
 to output in BER and PEM format.

Does this work for all smime functions now? (-encrypt, -decrypt, - 
sign and -verify)?


Regards,
Harald

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

PKCS#7 without certificates??

[lidia . fernandez]

Hello all!!

I've a problem. I need to cypher a buffer of bytes with pkcs7 format  
but I can't use certificates,i need encrypt using only a key or  
password.


I have searched but I do not find anything to do it.

I work with c, and the function PKCS7_encrypt() needs  
certificates...There is some another function that generates pkcs7  
format without need of certificates?


If this isn't possible..., there is another PKCS format that allows to  
cipher any type of data only with a password? (PKCS5,PKCS11,PKCS12...)


Someone can help me?

Thank!




__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: PKCS#7 without certificates??

[Jorge Fernandez]

2007/10/17, [EMAIL PROTECTED] [EMAIL PROTECTED]
:

 Hello all!!

 I've a problem. I need to cypher a buffer of bytes with pkcs7 format
 but I can't use certificates,i need encrypt using only a key or
 password.

 I have searched but I do not find anything to do it.

 I work with c, and the function PKCS7_encrypt() needs
 certificates...There is some another function that generates pkcs7
 format without need of certificates?

 If this isn't possible..., there is another PKCS format that allows to
 cipher any type of data only with a password? (PKCS5,PKCS11,PKCS12...)

 Someone can help me?

 Thank!


I think you are misunderstanding something. PKCS stands for Public Key
Cryptography Standards. So, these are standards for using with public (or
asymmetric) criptography, which are based on the existance of two keys (one
public and one private) ... Certificates are used to bind the public key and
its holder. Public Key Cryptography is rarely used to cipher data (is slow),
but to distribute the symmetric key used for cipher/decipher.

More info: http://en.wikipedia.org/wiki/Public_key_certificate

So, if you just want to encrypt some data, i guess you need symmetric
criptography. Then, you could posibly need asymmetric cryptography to
distribute the key used, and for that you'll need certificates if you want
to do it securely.

Saludos,

-- 
Jorge Fernandez

Re: PKCS#7 without certificates??

[Goetz Babin-Ebell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[EMAIL PROTECTED] schrieb:
 Hello all!!
Hello Lidia,

 I've a problem. I need to cypher a buffer of bytes with pkcs7 format but
 I can't use certificates,i need encrypt using only a key or password.

Are you really sure PKCS#7 supports encrypting of data without a
certificate ?

I know it was designed as a successor for PEM, which supports
encrypting with symetric keys, but if PKCS#7 supports it,
I don't know.

But I'm almost sure that if you use PKCS#7 with public keys,
you need a certificate.

 I have searched but I do not find anything to do it.
It may be possible that PKCS#7 does not support encrypting
without a certificate.
It also may be possible that OpenSSL does only support PKCS#7
with certificates.

 I work with c, and the function PKCS7_encrypt() needs
 certificates...There is some another function that generates pkcs7
 format without need of certificates?
 
 If this isn't possible..., there is another PKCS format that allows to
 cipher any type of data only with a password? (PKCS5,PKCS11,PKCS12...)

PKCS#11 defines the interface to hardware modules but
not a file format.
PKCS#12 is used to store private keys and their certificates
in a file.
It may be possible to use it to encrypt other data.
But there is no (higher level) interface to do it.

You could use other encryption formats.
OpenPGP comes to mind.

Bye

Goetz

- --
DMCA: The greed of the few outweights the freedom of the many
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHFoDO2iGqZUF3qPYRAsVLAJ4315wN9cupdVbJScJlSwZ4HQag8ACfZ3gl
qSwBSgGKBFtLlBphsUOLYY0=
=coEP
-END PGP SIGNATURE-
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: PKCS#7 without certificates??

[Michael Sierchio]

[EMAIL PROTECTED] wrote:

I've a problem. I need to cypher a buffer of bytes with pkcs7 format but 
I can't use certificates,i need encrypt using only a key or password.


I have searched but I do not find anything to do it.


Read the syntax for PKCS#7:

ftp://ftp.rsasecurity.com/pub/pkcs/ascii/pkcs-7.asc

For enveloped data:

EnvelopedData ::= SEQUENCE {
  version Version,
  recipientInfos RecipientInfos,
  encryptedContentInfo EncryptedContentInfo }

where

RecipientInfos ::= SET OF RecipientInfo

and

RecipientInfo ::= SEQUENCE {
  version Version,
  issuerAndSerialNumber IssuerAndSerialNumber,
  keyEncryptionAlgorithm

KeyEncryptionAlgorithmIdentifier,
  encryptedKey EncryptedKey }


Obviously for signed and enveloped data the sender needs a
cert, too.



__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

pkcs#7 structure with existing signature value

[Christian Wiesbauer]

Hello,

 

I hope someone can help. I have an existing signature which was made with a
smartcard. So, how can I create a valid pkcs#7 structure

which contains this signature value. I appreciate any thoughts, references,
samples or other help!

 

Thanks and best regards

 

Christian Wiesbauer

Sign with RSA/SHA1 and get PKCS#7/CMS

[estante23-openssl]

Hello,

I wasn't able to get a PKCS #7 file using the dgst and
rsautl command.
So now I'm trying with the smime command. However, I´m
doing something wrong since I get Error reading
S/MIME message because the file I want to sign is not
in SMIME format (I suppose).
Is there any way use the smime command to sign any
type of file?
The command I´m using is:

openssl smime -sign -pk7out -in 1.xml -outform DER
-signer britanico1.cer -inkey britanico1.pem -out
1.xml.cms

Thanks in advance,

Antonio Robirosa.


  __ 
Preguntá. Respondé. Descubrí. 
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta). 
¡Probalo ya! 
http://www.yahoo.com.ar/respuestas 

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Sign with RSA/SHA1 and get PKCS#7/CMS

[estante23-openssl]

Hello,

I need to sign a file using a RSA Key and get a
PKCS#7/CMS file.
I´ve tried the following command but Openssl complains
that the data is too large for the key size. 

openssl rsautl -in 1.xml -out 1.xml.cms.base64 -inkey
britanico1.pem -sign 

I´ve read the documentation of rsautl and its tells
its expects a hash. On the other hand, the pkcs7 can't
be used for signing.

Is there any way I can get the PKCS #7/CMS file with
the signature?

Best regards,

Antonio Robirosa.


  __ 
Preguntá. Respondé. Descubrí. 
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta). 
¡Probalo ya! 
http://www.yahoo.com.ar/respuestas 

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Filling a PKCS#7 structure

[Wockenfuß , Frank]

Hi there,

I have a problem to fill a PKCS#7 (or CMS) structure and I can't find any hints 
on the web so I hope someone in this group can help.
How to read or write a PKCS7 file programatically I have managed, but I have 
the following problem:

I have a digital signature of a document done by a smartcard and I have the 
modulus and the exponent of the smartcards public key. Additional there is 
alist of attributes token from the smartcard that should be saved too.
I want to store all this informations into an PKCS#7 structure. How to do this.

My approach looks like this:

PKCS7* pPKCS = PKCS7_new();
PKCS7_set_type( pPKCS, NID_pkcs7_enveloped );
PKCS7_content_new( pPKCS, NID_pkcs7_data );

// create Public Key object
EVP_PKEY* pPublicKey = EVP_PKEY_new();

// create RSA-key
RSA* pRSA = RSA_new();
pRSA-n = BN_bin2bn( pPublicModulus, nPublicModulusLength, NULL );
pRSA-e = BN_bin2bn( pPublicExponent, nPublicExponentLength, NULL );

// assign RSA to public key
EVP_PKEY_assign_RSA( pPublicKey, pRSA );

// set hashalgrotihm from extern by name
const EVP_MD* pMD = EVP_get_digestbyname( hashAlgorithmName );
PKCS7_set_digest( pPKCS, pMD );

This works fine but isn't very much. The reulsting file (done with 
i2d_PKCS7_bio( pOutFile, pPKCS ) ) is only 40 bytes long!
I have found the following commands that seem to be useful:

PKCS7_add_signature - maybe I could add the digital signature text from the 
smartcard
PKCS7_set_certs - X509?
PKCS7_set_detached - don't know

How to fill in the attributes from the smartcard (signaturecard)?
How do I add the created digital signature (and without verifying anything)?
What else do I need to add for a complete CMS file?

Hope someone can help me or send me some sample code.


Thanks in advance,

Frank Wockenfuß
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

How to extract message digest from PKCS #7 signature

[Grant Mills]

All,
   Is there a way to simply extract the message digest from a PKCS #7
signature?  Here is a little back ground to hopefully explain the
context.
   We have separate data and signature.  In order to reduce memory
requirements, we'd like to generate our digest while we decompress the
image.  After the image is decompressed, we'll extract the digest from
the signature and compare.  If they compare, we'd continue starting
up.  If the comparison failed, we'd scrub the uncompressed image from
memory.
   The exact order might differ, since padding the generated digest
might depend on the digest in the signature.  However, I don't
perceive those details as being insurmountable.
   Any help and thoughts on pitfalls to watch for will be
appreciated. Thanks in advance.

--
Grant Mills
[EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

converting PKCS #7 data from BER to DER

[Benjamin Sergeant]

Hi,

I'd like to know how to proceed (is it doable) to convert a PKCS #7
data (made with PKCS7_sign, flag = PKCS7_BINARY | PKCS7_DETACHED;)
with several cert (the one from the signer) and a chain of cert, from
BER to DER encoding.

I have another one PKCS #7 data which was made with the same
credential, but openssl pkcs7 print the embeded certificates in a
different order. Doing a wc -c on the different certificates, what I
understand is that with DER the certificates are sorted (lexicographic
?, the smaller one the first, and so on), while with BER (openssl)
they are in another order, the signing certificate is always coming
first when printing with openssl pkcs7.

Is there a way to build a filter to post process my BER to convert it
to DER (extracting the ASN.1 datas and sorting them) ? Digging in the
code I don't see such hidden features in crypto/pkc7 code ?
Or any other method ?

Thanks a lot for any help,
Benjamin.

I am working with version 0.9.8b (latest I think).
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: converting PKCS #7 data from BER to DER

[Michael Sierchio]

Benjamin Sergeant wrote:


I'd like to know how to proceed (is it doable) to convert a PKCS #7
data (made with PKCS7_sign, flag = PKCS7_BINARY | PKCS7_DETACHED;)
with several cert (the one from the signer) and a chain of cert, from
BER to DER encoding.


Is the decryption key present to sign the contents again after they
are rearranged by canonical encoding?  If not, then many of us are
counting on this not being remotely feasible. ;-)

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: converting PKCS #7 data from BER to DER

[Benjamin Sergeant]

The post process would be done by the signer (on his machine with all
the credential availables), with the key present. If this can be done
inside PKCS_sign, or during the same session.
I don't want this re-encoding to be particulary a post-process, just
want it to be done anytime, of course ...

If I can modify the PKCS7 code to output directly DER it's even
better. (but I don't know if it is feasible).
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: PKCS#7

[Bernhard Froehlich]

[EMAIL PROTECTED] wrote:



Hi!

I need to convert PKCS#7 attached signatures to PKCS#7 detached 
signatures.


Is it possibly? Is there any example?

Thanks anyway! 


Since noone else answered I'll thay the little I believe to know about 
the subject... ;)


I don't think doing this is possible using the openssl utilitoies, but 
it might be done using the ASN1 APIs. Maybe you should have a look at 
the asn1parse utility (apps/asn1pars.c) as a staring point.


And tell me if you find out more.
Ted
;)

--
PGP Public Key Information
Download complete Key from http://www.convey.de/ted/tedkey_convey.asc
Key fingerprint = 31B0 E029 BCF9 6605 DAC1  B2E1 0CC8 70F4 7AFB 8D26



smime.p7s
Description: S/MIME Cryptographic Signature

Re: PKCS#7

[Dr. Stephen Henson]

On Tue, Jan 17, 2006, Bernhard Froehlich wrote:

 [EMAIL PROTECTED] wrote:
 
 
 Hi!
 
 I need to convert PKCS#7 attached signatures to PKCS#7 detached 
 signatures.
 
 Is it possibly? Is there any example?
 
 Thanks anyway! 
 
 I don't think doing this is possible using the openssl utilitoies, but 
 it might be done using the ASN1 APIs. Maybe you should have a look at 
 the asn1parse utility (apps/asn1pars.c) as a staring point.
 
 

It is possible with some caveats.

Basically you have to poke around the PKCS7 structure, get get hold of the
content ASN1_OCTET_STRING struture, create a BIO out of it and then zero out
the field so the PKCS7 structure no longer includes the content.

The caveats are that the format of the included content may not be appropriate
for the detached content for (MIME multipart/signed format). In particular
that MIME type requires valid MIME headers and canonical format for the
first (to be signed) part. If the embedded content isn't of that form it can't
be translated without breaking the signature.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: PKCS#7

[Rabellino Sergio]

Bernhard Froehlich wrote:


[EMAIL PROTECTED] wrote:



Hi!

I need to convert PKCS#7 attached signatures to PKCS#7 detached 
signatures.


Is it possibly? Is there any example?

Thanks anyway! 



Since noone else answered I'll thay the little I believe to know about 
the subject... ;)


I don't think doing this is possible using the openssl utilitoies, but 
it might be done using the ASN1 APIs. Maybe you should have a look at 
the asn1parse utility (apps/asn1pars.c) as a staring point.


And tell me if you find out more.
Ted
;)


You can give a chance to openssl, viewing around the smime option.
You must convert your pkcs#7 back to smime, then take a look at the 
-nodetach implementation in the smime, maybe you can find the exact way 
to do the detach

conversion.

Hope this helps.

--
Dott. Mag. Sergio Rabellino 


Technical Staff
Department of Computer Science
University of Torino (Italy)

http://www.di.unito.it/~rabser
Tel. +39-0116706701
Fax. +39-011751603

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

PKCS#7

[milivoj . fradelic]

Hi!

I need to convert PKCS#7 attached signatures
to PKCS#7 detached signatures. 

Is it possibly?
Is there any example?

Thanks anyway!

Re: attribute certificate in PKCS#7 (CMS)

[Nikolay Elenkov]

Nikolay Elenkov wrote:

 I am trying to patch the PKCS#7 code to (partially) handle CMS ver 3.
 What I need is to parse a CMS structure that has an attribute
 certificate in the certificates field of SignedData.
 
...
 
 typedef struct certificate_choices_st {
 int type;
 union {
 X509* certificate;
 X509AC* attrCert;
 } value;
 } CERTIFICATE_CHOICES;
 
 DECLARE_ASN1_FUNCTIONS(CERTIFICATE_CHOICES)
 
 typedef struct pkcs7_signed_st
 {
 ASN1_INTEGER*version;   /* version 1 */
 STACK_OF(X509_ALGOR)*md_algs;   /* md used */
 STACK_OF(CERTIFICATE_CHOICES)   *cert;  /* [ 0 ] */
 STACK_OF(X509_CRL)  *crl;   /* [ 1 ] */
 STACK_OF(PKCS7_SIGNER_INFO) *signer_info;
 
 struct pkcs7_st *contents;
 } PKCS7_SIGNED;
 

To answer my own question, changing

ASN1_NDEF_SEQUENCE(PKCS7_SIGNED) = {
   ...
ASN1_IMP_SEQUENCE_OF_OPT(PKCS7_SIGNED, cert, X509, 0),
...
} ASN1_NDEF_SEQUENCE_END(PKCS7_SIGNED)

to

ASN1_NDEF_SEQUENCE(PKCS7_SIGNED) = {
   ...
ASN1_IMP_SEQUENCE_OF_OPT(PKCS7_SIGNED, cert, CERTIFICATE_CHOICES, 0),
...
} ASN1_NDEF_SEQUENCE_END(PKCS7_SIGNED)

and adding

ASN1_CHOICE(CERTIFICATE_CHOICES) = {
ASN1_SIMPLE(CERTIFICATE_CHOICES, value.certificate, X509),
ASN1_IMP(CERTIFICATE_CHOICES, value.attrCert, X509AC, 1)
} ASN1_CHOICE_END(CERTIFICATE_CHOICES)

IMPLEMENT_ASN1_FUNCTIONS(CERTIFICATE_CHOICES)

to pk7_asn1.c did the trick.

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

attribute certificate in PKCS#7 (CMS)

[Nikolay Elenkov]

Hello,

I am trying to patch the PKCS#7 code to (partially) handle CMS ver 3.
What I need is to parse a CMS structure that has an attribute
certificate in the certificates field of SignedData.

The relevant defintions from RFC 2630 are:

SignedData ::= SEQUENCE {
version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT CertificateRevocationLists OPTIONAL,
signerInfos SignerInfos }

CertificateSet ::= SET OF CertificateChoices

CertificateChoices ::= CHOICE {
 certificate Certificate, -- See X.509
 extendedCertificate [0] IMPLICIT ExtendedCertificate,
  -- Obsolete
 attrCert [1] IMPLICIT AttributeCertificate }
  -- See X.509 and X9.57

Following those I have this in pkcs7.h: (X509AC is from
openssl-play/steve/x509ac)

typedef struct certificate_choices_st {
int type;
union {
X509* certificate;
X509AC* attrCert;
} value;
} CERTIFICATE_CHOICES;

DECLARE_ASN1_FUNCTIONS(CERTIFICATE_CHOICES)

typedef struct pkcs7_signed_st
{
ASN1_INTEGER*version;   /* version 1 */
STACK_OF(X509_ALGOR)*md_algs;   /* md used */
STACK_OF(CERTIFICATE_CHOICES)   *cert;  /* [ 0 ] */
STACK_OF(X509_CRL)  *crl;   /* [ 1 ] */
STACK_OF(PKCS7_SIGNER_INFO) *signer_info;

struct pkcs7_st *contents;
} PKCS7_SIGNED;

However, when I try to parse the CMS file d2i_PKSC7 fails. Here is the
error trace:

1396:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong
tag:.\crypto\asn1\tasn_dec.c:1282:
1396:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1
error:.\crypto\asn1\tasn_dec.c:374:Type=X509
1396:error:0D08303A:asn1 encoding
routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1
error:.\crypto\asn1\tasn_dec.c:704:Field=cert, Type=PKCS7_SIGNED
1396:error:0D08303A:asn1 encoding
routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1
error:.\crypto\asn1\tasn_dec.c:743:
1396:error:0D08403A:asn1 encoding routines:ASN1_TEMPLATE_EX_D2I:nested
asn1 error:.\crypto\asn1\tasn_dec.c:572:Field=d.sign, Type=PKCS7

Any ideas as to what I am doing wrong?

TIA

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]