RE: This is one for the Pros: cert is not privkey

[Dave Thompson]

 
> From: owner-openssl-us...@openssl.org On Behalf Of Jakob Bohm
> Sent: Thursday, 22 November, 2012 04:07

> (Since you top-posted, I will do so too in this thread)
> 
But I won't, because I answer multiple points from both of you.

> The certificate does not include the private key, only the public key.
> 
> In a real (not test) setup you would use these like this:
> 
> 1. Use the certificate file alone on any computer to encrypt 
> data using
> the"openssl cms" or "openssl pkcs7" command.
> 
> 2. Use the key file AND the certificate file on the recipient computer
> to decrypt data using the "openssl cms" or "openssl pkcs#7" command,
> with different options.
> 
ITYM the 'cms' and 'smime' utilities, both of which handle 
the general cases of PKCS7/CMS (enveloped, signed, etc.) 
with as far as I have found pretty much the same options.
The much older 'pkcs7' utility only handles the special case of 
SignedData-no-data-no-signers used to convey certs and/or CRLs.
The PKCS7 *API* has long been able to handle signed/enveloped/etc, 
only the *utility* could not. When I looked (a while ago) the 
CMS API (used for 'smime' also) appeared a little more flexible, 
but not noticeably more capable.

> To tell the difference between the kinds of PEM files, just look at
> the first line in a text viewer such as Windows Notepad or GNU less,
> it will say so in nice big friendly letters.
> 
> P.S.
> 
> The differences between the OpenSSL CMS and PKCS#7 commands and
> features have little to do with differences between the CMS and
> PKCS#7 standards, it is just that some members of the OpenSSL team
> had different ideas about what they wanted the command to do, and
> then used two names of the standard to tell their work apart.
> 
> On 11/22/2012 12:21 AM, Peter Parker wrote:
> > Dave,
> > Thank you for the quick and thorough response. This is good stuff.
> >
> > Yes, so the files I will be encrypting will be over 100 bytes. I am
> > aware of the key size requirements - 1028 was only used as 
> a placeholder
> > for the example commands I provided. Does this mean that I 
> will be able
> > to use RSA or not?
> >
*Raw* RSA, which is what rsautl does, can only handle data that 
is somewhat smaller than the key size; the exact delta depends 
on the padding used, and I don't have them memorized since 
as I said basically no competently designed sytems use raw RSA, 
but instead RSA-encrypt only a DEK which is never more than 
about 32 bytes, well under the limit for any reasonable RSA key.
A 1024 or 1028 bit RSA key is 128 bytes, and the usual paddings 
take about 20 bytes, so I rounded to "about 100". 

OpenSSL supports RSA up to 16Kbits, but the cost of RSA operations 
is quadratic in key size so on typical hardware where you can do 
1Kbit or even 2Kbit operations at hundreds per second, 16Kbit 
operations will be on the order of one per second. If you are 
using unusually powerful hardware, or unusually limited (such as 
"mobile" devices), adjust up or down accordingly. Other systems 
may not support RSA above some limit, such as 4Kbits, but as I said 
standard systems don't use raw RSA anyway.

> > You lost me with the chaining and AKI stuff. I have no idea 
> what either
> > of those mean. Does the CMS approach that you suggested address this
> > issue? In either case, I like the idea of using CMS.
> >
> > The major reason that I am using the x509 (or originally 
> the ca) utility
> > is that I want to be able to set begin and end valid dates 
> (-startdate,
> > -enddate) for the public and private keys and create 
> certificates as
> > well. I also want to associate some metadata with them like 
> organization
> > and locality, for that I am currently using the -subj command.
> >
X.509 certs are good for associating metadata to a publickey, yes. 
They don't directly apply to the privatekey, but may indirectly:
here you have a keypair&cert intended for encrypting, so if the 
senders stop using this key for encrypting after validity end, 
then there will be no data for the matching privatekey to decrypt 
and it becomes functionally, though not formally, obsolete.

If you are using -subj for the child cert(s) *with a different value* 
than the CA, which you did not mention before, *that* addresses the 
chaining issue. If you run your own private CA, I would expect often 
organization and locality (and country) for the "leaf" entities 
are the same as athe CA -- but maybe not. If you use attribute(s) 
intended to identify specific party or system -- conventionally 
CommonName -- that should be unique.

In the dim past, only 'ca' could create CA-signed certs, but now 
'x509 -req -CA*' can do so also; the main difference now is 'ca' 
keeps a record for you in index.txt (and can use it to do CRLs), 
while 'x509' doesn't. Keeping track of certs by hand is tedious 
and error-prone, so if you intend to do more than one or two -- 
especially over a long time-frame -- 'ca' is probably better.

PKCS7/CMS/SMIME *uses* X.509 cert

Re: This is one for the Pros: cert is not privkey

[Jeremy Hunt]

  
  
Peter Parker wrote:

Dave,
  Thank you for the quick and thorough response. This is good stuff.
  
  Yes, so the files I will be encrypting will be over 100 bytes. I
  am aware of the key size requirements - 1028 was only used as a
  placeholder for the example commands I provided. Does this mean
  that I will be able to use RSA or not?
  
  You lost me with the chaining and AKI stuff. I have no idea what
  either of those mean. Does the CMS approach that you suggested
  address this issue? In either case, I like the idea of using CMS.
  
  The major reason that I am using the x509 (or originally the ca)
  utility is that I want to be able to set begin and end valid dates
  (-startdate, -enddate) for the
  public and private keys and create certificates as well. I also
  want to associate some metadata with them like organization and
  locality, for that I am currently using the -subj command. 
  
  Am I correct that the large PEM file includes both a public and
  private key? If so I should be able to extract them from the PEM
  and then use something (rsautl, enc or ...) to encrypt and decrypt
  the files. After successfully extracting what I understand to be a
  public key from the PEM, I receive this error from the rsautl
  utility: "unable to load Public Key. Error in rsautl"

Without going into the ins and outs of using the openssl utility,
you can actually infer a lot from the output PEM files themselves.
They are text files with the certificate parts and key parts base64
encoded and bookended by
-BEGIN CERTIFICATE-
...
-END CERTIFICATE-
for certificates in which case you can use 'openssl x509
' to inspect them, run "openssl x509 -help" for the
options in this case.

AND

-BEGIN RSA PRIVATE KEY-
...
-END RSA PRIVATE KEY-
for a key (but notice this key is actually an RSA key, you can have
other types of keys so this text may be something like 'BEGIN
 PRIVATE KEY'). The RSA keyword gives you the clue
to use 'openssl rsa ' to inspect this one, try 'openssl
rsa -help' to see what is available. You should also know the
password for the private key or you will be told zip by 'openssl
rsa'. The private key should be passworded, but you can strip the
password from them, which is not recommended but procedurally easier
in some circumstances beyond this discussion.

Also note that some certificates may or may not include a key in the
output file, if they don't you will have a separate key file. But
just looking at the certificate or key file and the bookends of the
base64 encoded part will tell you which file contains what.


  Could you give me some examples of how you would use CMS or, just
  use these utilities properly, to achieve what I'm trying to do.
  
  I really appreciate your help. 
  
  Thanks,
  Peter
  
  
On Tue, Nov 20, 2012 at 10:17 PM, Dave Thompson  wrote:

  >From: owner-openssl-us...@openssl.org
  On Behalf Of Peter Parker
  >Sent: Tuesday, 20 November, 2012 20:59
  
  >Subject: This is one for the Pros
  
  Not really. This is pretty basic.
  
  >I've been trying to generate a public/private key pair
  after
  >generating the certificates, but OpenSSL keeps giving me
  an error.
  >The commands and the error are below. Thanks.
  
  No you're not; you're generating a CA keypair and cert
  (directly),
  then an application keypair, then an application cert (via
  CSR).
  Which is the (well, a) correct sequence, for one entity.
  
  >Commands
  >#openssl req -new -x509 -extensions v3_ca -days 365
  -keyout caKey.pem
  >-passout pass:test -out caCert.crt -batch
  >#openssl genrsa -out application.pem -passout pass:test
  -des3 1028
  
  1028 is an unusual size for an RSA key; most folks use
  power-of-2
  based values like 1024 1536 2048. 1024 is presently rather
  marginal
  for security; for example, NIST has it deprecated since the
  end of
  2010, and prohibited after the end of 2013, for US government
  use.
  
  >#openssl req -new -key application.pem -passin pass:test
  -out
  application.csr -batch
  
  A second req -new -batch generates a CSR with the same DN ...
  
  >#openssl x509 -req -days 365 -in application.csr -CA
  caCert.crt
  -CAcreateserial
  >-CAkey caKey.pem -passin:test -out test-key.pem
  -extensions ssl_cert
  
  ... thus this creates 

Re: This is one for the Pros: cert is not privkey

[Jakob Bohm]

(Since you top-posted, I will do so too in this thread)

The certificate does not include the private key, only the public key.

In a real (not test) setup you would use these like this:

1. Use the certificate file alone on any computer to encrypt data using
the"openssl cms" or "openssl pkcs7" command.

2. Use the key file AND the certificate file on the recipient computer
to decrypt data using the "openssl cms" or "openssl pkcs#7" command,
with different options.

To tell the difference between the kinds of PEM files, just look at
the first line in a text viewer such as Windows Notepad or GNU less,
it will say so in nice big friendly letters.

P.S.

The differences between the OpenSSL CMS and PKCS#7 commands and
features have little to do with differences between the CMS and
PKCS#7 standards, it is just that some members of the OpenSSL team
had different ideas about what they wanted the command to do, and
then used two names of the standard to tell their work apart.

On 11/22/2012 12:21 AM, Peter Parker wrote:

Dave,
Thank you for the quick and thorough response. This is good stuff.

Yes, so the files I will be encrypting will be over 100 bytes. I am
aware of the key size requirements - 1028 was only used as a placeholder
for the example commands I provided. Does this mean that I will be able
to use RSA or not?

You lost me with the chaining and AKI stuff. I have no idea what either
of those mean. Does the CMS approach that you suggested address this
issue? In either case, I like the idea of using CMS.

The major reason that I am using the x509 (or originally the ca) utility
is that I want to be able to set begin and end valid dates (-startdate,
-enddate) for the public and private keys and create certificates as
well. I also want to associate some metadata with them like organization
and locality, for that I am currently using the -subj command.

Am I correct that the large PEM file includes both a public and private
key? If so I should be able to extract them from the PEM and then use
something (rsautl, enc or ...) to encrypt and decrypt the files. After
successfully extracting what I understand to be a public key from the
PEM, I receive this error from the rsautl utility: "unable to load
Public Key. Error in rsautl"

Could you give me some examples of how you would use CMS or, just use
these utilities properly, to achieve what I'm trying to do.

I really appreciate your help.

Thanks,
Peter

On Tue, Nov 20, 2012 at 10:17 PM, Dave Thompson mailto:dthomp...@prinpay.com>> wrote:

 >From: owner-openssl-us...@openssl.org
 On Behalf Of Peter Parker
 >Sent: Tuesday, 20 November, 2012 20:59

 >Subject: This is one for the Pros

Not really. This is pretty basic.

 >I've been trying to generate a public/private key pair after
 >generating the certificates, but OpenSSL keeps giving me an error.
 >The commands and the error are below. Thanks.

No you're not; you're generating a CA keypair and cert (directly),
then an application keypair, then an application cert (via CSR).
Which is the (well, a) correct sequence, for one entity.

 >Commands
 >#openssl req -new -x509 -extensions v3_ca -days 365 -keyout 
caKey.pem

 >-passout pass:test -out caCert.crt -batch
 >#openssl genrsa -out application.pem -passout pass:test -des3 1028

1028 is an unusual size for an RSA key; most folks use power-of-2
based values like 1024 1536 2048. 1024 is presently rather marginal
for security; for example, NIST has it deprecated since the end of
2010, and prohibited after the end of 2013, for US government use.

 >#openssl req -new -key application.pem -passin pass:test -out
application.csr -batch

A second req -new -batch generates a CSR with the same DN ...

 >#openssl x509 -req -days 365 -in application.csr -CA caCert.crt
-CAcreateserial
 >-CAkey caKey.pem -passin:test -out test-key.pem -extensions ssl_cert

... thus this creates a CA-signed cert which appears to be 
self-signed,

and will not chain correctly with OpenSSL. If the ssl_cert section
of your
config file (which doesn't exist in the distro file) includes AKI, 
other

software that chains primarily by AKI may work, but this is still
incorrect.

This puts the cert in a file named test-key.pem, which is a
misleading name.

 >#openssl rsa -in test-key.pem -passin pass:test -out pub-key.pem
-outform
PEM -pubout

And therefore this command, which is not the last one, fails because
you told it to read the privatekey from a file which is a certificate.
application.pem is your privatekey.

 >#openssl rsautl -encrypt -inkey pub-key.pem -pubin -in
testfile.txt -out
eFile.ssl

 >Error
 >"unable to load Private Key" (I receive this after the last command)

Not last.

 >The key thing that I am trying to do is to encrypt some files with
the key
 >that I g

Re: This is one for the Pros: cert is not privkey

[Peter Parker]

Dave,
Thank you for the quick and thorough response. This is good stuff.

Yes, so the files I will be encrypting will be over 100 bytes. I am aware
of the key size requirements - 1028 was only used as a placeholder for the
example commands I provided. Does this mean that I will be able to use RSA
or not?

You lost me with the chaining and AKI stuff. I have no idea what either of
those mean. Does the CMS approach that you suggested address this issue? In
either case, I like the idea of using CMS.

The major reason that I am using the x509 (or originally the ca) utility is
that I want to be able to set begin and end valid dates (-startdate,
-enddate**) for the public and private keys and create certificates as
well. I also want to associate some metadata with them like organization
and locality, for that I am currently using the -subj command.

Am I correct that the large PEM file includes both a public and private
key? If so I should be able to extract them from the PEM and then use
something (rsautl, enc or ...) to encrypt and decrypt the files. After
successfully extracting what I understand to be a public key from the PEM,
I receive this error from the rsautl utility: "unable to load Public Key.
Error in rsautl"

Could you give me some examples of how you would use CMS or, just use these
utilities properly, to achieve what I'm trying to do.

I really appreciate your help.

Thanks,
Peter

On Tue, Nov 20, 2012 at 10:17 PM, Dave Thompson wrote:

> >From: owner-openssl-us...@openssl.org On Behalf Of Peter Parker
> >Sent: Tuesday, 20 November, 2012 20:59
>
> >Subject: This is one for the Pros
>
> Not really. This is pretty basic.
>
> >I've been trying to generate a public/private key pair after
> >generating the certificates, but OpenSSL keeps giving me an error.
> >The commands and the error are below. Thanks.
>
> No you're not; you're generating a CA keypair and cert (directly),
> then an application keypair, then an application cert (via CSR).
> Which is the (well, a) correct sequence, for one entity.
>
> >Commands
> >#openssl req -new -x509 -extensions v3_ca -days 365 -keyout caKey.pem
> >-passout pass:test -out caCert.crt -batch
> >#openssl genrsa -out application.pem -passout pass:test -des3 1028
>
> 1028 is an unusual size for an RSA key; most folks use power-of-2
> based values like 1024 1536 2048. 1024 is presently rather marginal
> for security; for example, NIST has it deprecated since the end of
> 2010, and prohibited after the end of 2013, for US government use.
>
> >#openssl req -new -key application.pem -passin pass:test -out
> application.csr -batch
>
> A second req -new -batch generates a CSR with the same DN ...
>
> >#openssl x509 -req -days 365 -in application.csr -CA caCert.crt
> -CAcreateserial
> >-CAkey caKey.pem -passin:test -out test-key.pem -extensions ssl_cert
>
> ... thus this creates a CA-signed cert which appears to be self-signed,
> and will not chain correctly with OpenSSL. If the ssl_cert section of your
> config file (which doesn't exist in the distro file) includes AKI, other
> software that chains primarily by AKI may work, but this is still
> incorrect.
>
> This puts the cert in a file named test-key.pem, which is a misleading
> name.
>
> >#openssl rsa -in test-key.pem -passin pass:test -out pub-key.pem -outform
> PEM -pubout
>
> And therefore this command, which is not the last one, fails because
> you told it to read the privatekey from a file which is a certificate.
> application.pem is your privatekey.
>
> >#openssl rsautl -encrypt -inkey pub-key.pem -pubin -in testfile.txt -out
> eFile.ssl
>
> >Error
> >"unable to load Private Key" (I receive this after the last command)
>
> Not last.
>
> >The key thing that I am trying to do is to encrypt some files with the key
> >that I generate. I do however want to use the public and private keys that
> >I get out of the PEM file using the x509 (or the ca utilities).
>
> If (any of) your files are larger than about 100 bytes (for 1024-bit RSA)
> you can't use raw RSA; even if they aren't, you can't interoperate with
> properly designed software that doesn't use raw RSA. The conventional
> approach is to encrypt the "bulk" data symmetrically with a nonce key (DEK)
> and PK (RSA) encrypt that DEK; there are numerous schemes that do this,
> but the one that OpenSSL supports directly is PKCS7/CMS/SMIME. (CMS is an
> updated Internet version of PKCS7, and SMIME is a simple wrapping of CMS.)
>
> You can generate and use RSA keys without using certificates (and without
> using the req x509 ca utilities) IF you have a way to "distribute" them
> correctly -- that is, to make sure the "enveloper" always uses a correct
> publickey for the recipient and not a forged, tampered, or obsolete one.
> (And similarly the verifier for a signer.) Most standard schemes do use
> X.509 certs for this purpose, because they are also standard.
>
>
> __
> OpenSSL Project 

RE: This is one for the Pros: cert is not privkey

[Dave Thompson]

>From: owner-openssl-us...@openssl.org On Behalf Of Peter Parker
>Sent: Tuesday, 20 November, 2012 20:59

>Subject: This is one for the Pros

Not really. This is pretty basic. 

>I've been trying to generate a public/private key pair after 
>generating the certificates, but OpenSSL keeps giving me an error. 
>The commands and the error are below. Thanks.

No you're not; you're generating a CA keypair and cert (directly),  
then an application keypair, then an application cert (via CSR).
Which is the (well, a) correct sequence, for one entity.

>Commands
>#openssl req -new -x509 -extensions v3_ca -days 365 -keyout caKey.pem 
>-passout pass:test -out caCert.crt -batch
>#openssl genrsa -out application.pem -passout pass:test -des3 1028

1028 is an unusual size for an RSA key; most folks use power-of-2 
based values like 1024 1536 2048. 1024 is presently rather marginal 
for security; for example, NIST has it deprecated since the end of 
2010, and prohibited after the end of 2013, for US government use.

>#openssl req -new -key application.pem -passin pass:test -out
application.csr -batch

A second req -new -batch generates a CSR with the same DN ...

>#openssl x509 -req -days 365 -in application.csr -CA caCert.crt
-CAcreateserial 
>-CAkey caKey.pem -passin:test -out test-key.pem -extensions ssl_cert

... thus this creates a CA-signed cert which appears to be self-signed, 
and will not chain correctly with OpenSSL. If the ssl_cert section of your 
config file (which doesn't exist in the distro file) includes AKI, other 
software that chains primarily by AKI may work, but this is still incorrect.

This puts the cert in a file named test-key.pem, which is a misleading name.

>#openssl rsa -in test-key.pem -passin pass:test -out pub-key.pem -outform
PEM -pubout

And therefore this command, which is not the last one, fails because 
you told it to read the privatekey from a file which is a certificate.
application.pem is your privatekey.

>#openssl rsautl -encrypt -inkey pub-key.pem -pubin -in testfile.txt -out
eFile.ssl

>Error
>"unable to load Private Key" (I receive this after the last command)

Not last.

>The key thing that I am trying to do is to encrypt some files with the key 
>that I generate. I do however want to use the public and private keys that 
>I get out of the PEM file using the x509 (or the ca utilities).

If (any of) your files are larger than about 100 bytes (for 1024-bit RSA) 
you can't use raw RSA; even if they aren't, you can't interoperate with 
properly designed software that doesn't use raw RSA. The conventional 
approach is to encrypt the "bulk" data symmetrically with a nonce key (DEK) 
and PK (RSA) encrypt that DEK; there are numerous schemes that do this, 
but the one that OpenSSL supports directly is PKCS7/CMS/SMIME. (CMS is an 
updated Internet version of PKCS7, and SMIME is a simple wrapping of CMS.)

You can generate and use RSA keys without using certificates (and without 
using the req x509 ca utilities) IF you have a way to "distribute" them 
correctly -- that is, to make sure the "enveloper" always uses a correct 
publickey for the recipient and not a forged, tampered, or obsolete one.
(And similarly the verifier for a signer.) Most standard schemes do use 
X.509 certs for this purpose, because they are also standard.


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