Hello.
I have seen references on another IETF list and now here, and
i saw something that i actually do not truly understand.
But my cryptographic knowledge is hm questionable.
Alexey Melnikov wrote in
<cc9f4cb9-8a20-45a0-ab03-752b7c4b0ab7@xxxxxxxxx>:
There is
8.2.1.1. User Certificates for S/MIM
What i have problems with is that the speech reminds me of the
separation of specific keys that OpenPGP knows about, but
user SHOULD have both a signing-capable certificate and an
encryption-capable certificate (and the corresponding secret
keys)
is something that causes a headache for me.
How should this actually be done?
You have a secret key (of which you can derive a public key), and,
here, for S/MIME, a certificate.
You can create a certificate request to get it signed by some CA,
or you self-sign it. For example
openssl req -config email-openssl.cnf \
-noenc -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem
(before -nodes not -noenc; newer algorithms OpenSSL unfortunately
does not feature, maybe someone could speak with them via github).
The config in parts is
[req]
default_md=sha512
#default_days=4200
distinguished_name=req_sect
x509_extensions=ext_sect
prompt=no
..
[req_sect]
..
emailAddress=..
..
[ext_sect]
extendedKeyUsage=emailProtection
nsCertType=email
subjectAltName=email:...
Now you can take create a pair
cat key.pem cert.pem > smime-pair.pem
And that you can use via the usual crypto library:
PEM_read_PrivateKey
rewind
PEM_read_X509
and a bit more to come. You *can* include further certificates,
for example if your certificate is signed by a CA which is not
available in usual CA pools, include that, and anything else up to
"before the CA one", etc etc. (There are partial chains, etc.)
Anyhow, there is no distinction in between a "signing capable" and
an "encryption capable" key. In the end the S/MIME signature
includes the certificate even, and the receive can (after
verification, say) simply take the certificate out of it, store it
locally, and has everything necessary in order to send encrypted
S/MIME messages back.
Ie, i do not understand
8.2.3.1. Shipping Certificates in S/MIME Messages
either, because i would not even know how to avoid including the
certificate that any receiver can then use to send encrypted email
back to me. Having said that, i "grew up" in the mental
environment of OpenSSL (more exact: network security with openssl
i think the book title is), and its programming interface. I do
not want to rule out the possibility that other interfaces exist
which allow otherwise; like i said, i am no ¢ryptographer, and
even though i have read the CMS RFC(s maybe even), it is a long
time, and it is not daily basis.
Btw i have sympathy for full key management and master keys and
dedicated subkeys. However a nice TLS+DNSSEC secure DNS TXT entry
with an ED25519 or so certificate (ie: *impossible* with OpenSSL),
with an identifier (or, in DKIM terms: selector) i can bake into
the certificate in order to be able to rotate, i find even better.
Ie, if compromised, create a new one. No CRLS, no OCSP, simply
a X509-baked-in selector and a DNS record.
Btw i have yet to see ACME for S/MIME in real life. Does this
exist? I was thrilled by your efforts to bake this into a
standard, but now the IETF really kills business models, does it.
That is: i see no dedicated subkeys or anything.
Ciao already here, the rest is a bit off-topic.
I also find the language very challenging. I have spent actual
time to write a manual for the MUA i maintain, and it reads now
(and as can be seen, here is where i have to spend time and work)
Signed and encrypted messages with S/MIME
[Option] S/MIME provides two central mechanisms: message signing and mes‐
sage encryption. Signing allows recipients to verify the message sender,
and message encryption provides end-to-end security that reveals the
clear text of a message only to the sender and the recipient.
A message is signed with a private key. This adds some data to the regu‐
lar content which can be used to verify it was sent using a valid cer‐
tificate, that the sender address is covered by the certificate, and that
the content has not been altered. A signed message is received as clear
text and can be handled without restrictions.
Encryption, in contrast, uses a public encryption key to make the message
text invisible for all people except those who have access to a secret
decryption key. The public encryption key must have been retrieved by
other means, for example from previous communication, from securely vis‐
ited web sites, from public key directories, etc. Because of the public‐
ity messages should be signed before they become encrypted.
A central concept of S/MIME are certification authorities (CAs). These
are trusted institutions which issue certificates that correlate a user’s
private decryption and signing key (and its public variant) with the CA’s
own by means of a certificate request. This makes it cryptographically
possible to verify the key correlation of a CA and a user: verification
will succeed if a CA certificate is found that is a(n in)direct signer of
(a) presented user certificate(s).
A set of CA certificates is usually available from the distributor of the
operating system, or comes shipped with the used cryptographical library:
reasonable security for S/MIME on the Internet is provided if the source
that provides the set is trusted. A certificate cannot be more secure
than the method its CA certificate has been retrieved with. A personal
set of trusted certificates can be specified via smime-ca-file[568]
and/or (with special preparation) smime-ca-dir[567]. Setting
smime-ca-no-defaults[570] disables (additional) usage of the default cer‐
tificate set.
The set of CA certificates is used by the command verify[309] to ensure
the given S/MIME message(s) can be trusted. If so, verified sender cer‐
tificates that were embedded in signed messages can be saved locally with
certsave[160], and henceforth be used to encrypt further communication:
certsave FILENAME
#..
set smime-encrypt-USER@HOST=FILENAME \
smime-cipher-USER@HOST=AES256
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
