CMS and keys

Ok Dave I am not sure what how what I said was inaccurate  ?

I stated SMIME / CMS utilizes a private key.


Can you explain to me if my understanding below is incorrect:
How Does S/MIME Work?

Encrypting, signing, and decrypting S/MIME email messages requires the use of certificates. Certificates are simply public and/or private keys wrapped up in a specific format, so that they can be used together and understood by various programs.


An S/MIME email message can be signed, encrypted, or both. Encrypting a message is done using the public key certificate of the recipient of the message. This ensures that only the recipient can decrypt the message, as the encryption is done so that only the recipient's private key certificate can reverse the encryption. Signing the message is done with the sender's private key certificate, and ensures to the recipient that the sender of the message is who they say they are. A hash of the message is also created by the signing process so that the recipient of the message knows that the message has not been changed since it was written

@becraig: a certificate NEVER contains a private key. that's the main one. but itemized...

Encrypting, signing, and decrypting S/MIME email messages requires the use of certificates.
No. encryption or signature verification requires a public key. decryption or signing requires a private key.

Certificates are simply public and/or private keys wrapped up in a specific format, so that they can be used together and understood by various programs.
no. certificates are a series of data items (usually an asserted identity, usage flags, validity date range and signing entity name, plus a public key) signed by a private key. if the private key matches the public key, then the certificate is "self signed". the private key is never contained in the certificate, and the public key is part of a bundle of data items that together allow you to associate the public key with an identity and validate that assertion.

An S/MIME email message can be signed, encrypted, or both.
Correct :)

Encrypting a message is done using the public key certificate of the recipient of the message.
Encrypting the message is done with a public key, which is usually found in a certificate. Actually, that isn't true either; the message is actually encrypted with a randomly generated key, and THAT key is encrypted with the public key, but the first association is close enough. If there is more than one recipient, the random key is encrypted multiple times (once per recipient) and stored in the same CMS file.

This ensures that only the recipient can decrypt the message, as the encryption is done so that only the recipient's private key certificate can reverse the encryption
Close enough, except that there is no such thing as a "private key certificate". Private keys are just private keys.

Signing the message is done with the sender's private key certificate, and ensures to the recipient that the sender of the message is who they say they are. A hash of the message is also created by the signing process so that the recipient of the message knows that the message has not been changed since it was written
Reasonably close. the message is hashed, and the hash of the message is encrypted with the private key, then that encrypted hash is stored in the CMS along with the certificate that contains the public key. On receipt, a recipient can re-calculate the hash, decrypt (with the public key extracted from the certificate) the original hash, and compare the two. That ensures that only someone with the private key could have encrypted that hash, and that the hash matches (hence, the message has not been altered in transit)

The certificate identifies the asserted identity of the signer, by virtue of the hashes matching (after the public key is used to decrypt the stored hash) and the other info contained in the certificate - in order to know that the signer was in fact who they said they were, the validity of the certificate must then be checked.

I am not sure where I wrote that a PRIVATE KEY was a certificate, I have re-read twenty times what I wrote and CANNOT find it  ?

I am not sure where you got the ASSUMPTION that an assertion was made that a private key was a certificate ??

Reasonably close. the message is hashed, and the hash of the message is encrypted with the private key,

I am not sure how saying the hash of the message is encrypted using the private key (being a bit more granular is different to saying the message is encrypted using the private key ??)

If I read what you wrote correctly you are agreeing with what I wrote, but adding a layer ?
How does that invalidate what I wrote or provide any clarity to the Author's question ?

You also stated

the private key is never sent, nor is it needed

While I acknowledge I never indicated the private key was ever sent, I am not sure how you arrive at the conclusion a private key is not needed in a key-pair  ?

My answer for clarity and simplicity to the author was:
1)  The term certificate can be used to indicate the public key portion or public key + private key indicated in a previous answer to the author RE: pkcs 12 format.

2) As for the second question:
So  if it is used in mail, messages, etc, wouldn't you need a private key, and since CMS does not contain a private key, would that be a problem?

Reasonably close. the message is hashed, and the hash of the message is encrypted with the private key, then that encrypted hash is stored in the CMS along with the certificate that contains the public key. On receipt, a recipient can re-calculate the hash, decrypt (with the public key extracted from the certificate) the original hash, and compare the two. That ensures that only someone with the private key could have encrypted that hash, and that the hash matches (hence, the message has not been altered in transit)

I think we are both in agreement  on the responses provided ?

@becraig:
I am not sure where I wrote that a PRIVATE KEY was a certificate, I have re-read twenty times what I wrote and CANNOT find it  ?
I am not sure where you got the ASSUMPTION that an assertion was made that a private key was a certificate ??

Odd then. In one reading, I find:


took me significantly less than 20 tries there :)

I am not sure how saying the hash of the message is encrypted using the private key (being a bit more granular is different to saying the message is encrypted using the private key ??)
Hence "reasonably close". However, that the hash of the message (and not the message itself) is encrypted is important; nobody ever encrypts a message directly with a PKI keypair - it isn't done. Instead, you encrypt either a randomly generated key (for encryption) or a hash (for signatures).

While I acknowledge I never indicated the private key was ever sent, I am not sure how you arrive at the conclusion a private key is not needed in a key-pair  ?
The private key of the sender is not only never needed by the recipient, it must never be *sent* to the recipient - the entire system relies on the private key being kept private.

1)  The term certificate can be used to indicate the public key portion or public key + private key indicated in a previous answer to the author RE: pkcs 12 format.
No, it can't. It is very important not to confuse a certificate (which is a distinct entity) with a pkcs#12 or #7 CONTAINER (which can contain many certificates, and in the former case, also a private key) or indeed private/public keys themselves.  Each are distinct entities and concepts, and not understanding which can be nested inside which other(s) can lead to significant confusion.

So  if it is used in mail, messages, etc, wouldn't you need a private key, and since CMS does not contain a private key, would that be a problem?
Essentially, the private key must be kept private by its owner. It will be used appropriately by its owner on construction or consumption of a CMS container, but the private key is not needed to encrypt to a recipient, or verify a signature on receipt.

A CMS message container therefore does not need and should not contain a private key - correspondingly, a pkcs#7 certificate-only container does not and cannot contain a private key, hence can be used only to verify a signature or create an encrypted message, not decrypt or sign.

I think we are both in agreement  on the responses provided ?
Probably. I think you know in general the concepts, even if you seem a bit hazy on the names of things :)

LOL your responses highlight why I gave the answers I did to avoid excess confusion.

You continue here to INSIST I said a private key was a certificate
(I still cannot read anywhere in my initial response where that "assignment" was made.)

As for the quotes on SMIME those were simply provided from a published source simply  for the purpose of providing clarity on the concept of encryption/decryption, where you insisted there was no private key involved in SMIME encryption.

the private key is never sent, nor is it needed

I think I may have taken your comment above out of context in reading that NO private key is ever needed in SMIME encryption.

As for "sending" the private key I know there is no way in the world I could ever make that suggestion :)


I had previously made it clear to the author CMS was a container type pkcs7 as indicated there was no private key contained in CMS hence his statement:
My understanding is that CMS is a form of pkcs#7, and encapsulates a certificate but not a private key.

So at this point there was no thought nor belief by the author based on my previous response that there was a private key in a CMS container.



Thanks for the additional clarification  :)

You continue here to INSIST I said a private key was a certificate
(I still cannot read anywhere in my initial response where that "assignment" was made.)

And in response, I pointed out two instances where you used the exact phrase "private key certificate", and two where you said a certificate could contain a private key.

now, given I never once asserted that you said that a private key WAS a certificate, that was enough to illustrate what I *DID* say, which is this:
a certificate NEVER contains a private key
and
there is no such thing as a "private key certificate". Private keys are just private keys.

Now, if there is some specific statement of mine that isn't addressed by the above four quotes, feel free to point it out and I will clarify :)

I think I may have taken your comment above out of context in reading that NO private key is ever needed in SMIME encryption.
 I was obviously not sufficiently clear - the private key is not sent nor needed to be sent - so for that I apologise - at least this discussion should make that point more clear to the OP.

So at this point there was no thought nor belief by the author based on my previous response that there was a private key in a CMS container.
And yet, your statements, such as
The term certificate can be used to indicate the public key portion or public key + private key indicated in a previous answer to the author RE: pkcs 12 format.
Could have led to erroneous beliefs - which I would rather the OP did not adopt, given he appears to be trying to learn the entire field of PKI, secure transmission, and application proxying one EE question at a time :)

Thanks a lot Dave, as I indicated the SMIME portion was a copy paste from a publication (laziness on my part) so the inclusion of the word "certificate" was not my doing  :(


That being said, having been in the industry for a while a lot of people tend to lump everything together (Where containers are concerned), hence me saying to the OP
"due to the language used from time to time".

I am sure you have had the same experience as myself of having people referring to the container format as the certificate, this was an attempt to disambiguate the OP in the event during his learning he came across that specific instance.

As far as identifying the fact that these were in fact just containers and the the concept is key pairing a private and public key, I think that had already been established.

I do appreciate your input though, I think our discussion on this has provided as clear a picture as one could possibly expect as far as a crash course on key infrastructure  and digital certs...


Gotta love EE :)