1=pod
2
3=head1 NAME
4
5cms - CMS utility
6
7=head1 SYNOPSIS
8
9B<openssl> B<cms>
10[B<-encrypt>]
11[B<-decrypt>]
12[B<-sign>]
13[B<-verify>]
14[B<-cmsout>]
15[B<-resign>]
16[B<-data_create>]
17[B<-data_out>]
18[B<-digest_create>]
19[B<-digest_verify>]
20[B<-compress>]
21[B<-uncompress>]
22[B<-EncryptedData_encrypt>]
23[B<-sign_receipt>]
24[B<-verify_receipt receipt>]
25[B<-in filename>]
26[B<-inform SMIME|PEM|DER>]
27[B<-rctform SMIME|PEM|DER>]
28[B<-out filename>]
29[B<-outform SMIME|PEM|DER>]
30[B<-stream -indef -noindef>]
31[B<-noindef>]
32[B<-content filename>]
33[B<-text>]
34[B<-noout>]
35[B<-print>]
36[B<-CAfile file>]
37[B<-CApath dir>]
38[B<-no_alt_chains>]
39[B<-md digest>]
40[B<-[cipher]>]
41[B<-nointern>]
42[B<-no_signer_cert_verify>]
43[B<-nocerts>]
44[B<-noattr>]
45[B<-nosmimecap>]
46[B<-binary>]
47[B<-nodetach>]
48[B<-certfile file>]
49[B<-certsout file>]
50[B<-signer file>]
51[B<-recip file>]
52[B<-keyid>]
53[B<-receipt_request_all -receipt_request_first>]
54[B<-receipt_request_from emailaddress>]
55[B<-receipt_request_to emailaddress>]
56[B<-receipt_request_print>]
57[B<-secretkey key>]
58[B<-secretkeyid id>]
59[B<-econtent_type type>]
60[B<-inkey file>]
61[B<-keyopt name:parameter>]
62[B<-passin arg>]
63[B<-rand file(s)>]
64[B<cert.pem...>]
65[B<-to addr>]
66[B<-from addr>]
67[B<-subject subj>]
68[cert.pem]...
69
70=head1 DESCRIPTION
71
72The B<cms> command handles S/MIME v3.1 mail. It can encrypt, decrypt, sign and
73verify, compress and uncompress S/MIME messages.
74
75=head1 COMMAND OPTIONS
76
77There are fourteen operation options that set the type of operation to be
78performed. The meaning of the other options varies according to the operation
79type.
80
81=over 4
82
83=item B<-encrypt>
84
85encrypt mail for the given recipient certificates. Input file is the message
86to be encrypted. The output file is the encrypted mail in MIME format. The
87actual CMS type is <B>EnvelopedData<B>.
88
89=item B<-decrypt>
90
91decrypt mail using the supplied certificate and private key. Expects an
92encrypted mail message in MIME format for the input file. The decrypted mail
93is written to the output file.
94
95=item B<-debug_decrypt>
96
97this option sets the B<CMS_DEBUG_DECRYPT> flag. This option should be used
98with caution: see the notes section below.
99
100=item B<-sign>
101
102sign mail using the supplied certificate and private key. Input file is
103the message to be signed. The signed message in MIME format is written
104to the output file.
105
106=item B<-verify>
107
108verify signed mail. Expects a signed mail message on input and outputs
109the signed data. Both clear text and opaque signing is supported.
110
111=item B<-cmsout>
112
113takes an input message and writes out a PEM encoded CMS structure.
114
115=item B<-resign>
116
117resign a message: take an existing message and one or more new signers.
118
119=item B<-data_create>
120
121Create a CMS B<Data> type.
122
123=item B<-data_out>
124
125B<Data> type and output the content.
126
127=item B<-digest_create>
128
129Create a CMS B<DigestedData> type.
130
131=item B<-digest_verify>
132
133Verify a CMS B<DigestedData> type and output the content.
134
135=item B<-compress>
136
137Create a CMS B<CompressedData> type. OpenSSL must be compiled with B<zlib>
138support for this option to work, otherwise it will output an error.
139
140=item B<-uncompress>
141
142Uncompress a CMS B<CompressedData> type and output the content. OpenSSL must be
143compiled with B<zlib> support for this option to work, otherwise it will
144output an error.
145
146=item B<-EncryptedData_encrypt>
147
148Encrypt content using supplied symmetric key and algorithm using a CMS
149B<EncrytedData> type and output the content.
150
151=item B<-sign_receipt>
152
153Generate and output a signed receipt for the supplied message. The input 
154message B<must> contain a signed receipt request. Functionality is otherwise
155similar to the B<-sign> operation.
156
157=item B<-verify_receipt receipt>
158
159Verify a signed receipt in filename B<receipt>. The input message B<must> 
160contain the original receipt request. Functionality is otherwise similar
161to the B<-verify> operation.
162
163=item B<-in filename>
164
165the input message to be encrypted or signed or the message to be decrypted
166or verified.
167
168=item B<-inform SMIME|PEM|DER>
169
170this specifies the input format for the CMS structure. The default
171is B<SMIME> which reads an S/MIME format message. B<PEM> and B<DER>
172format change this to expect PEM and DER format CMS structures
173instead. This currently only affects the input format of the CMS
174structure, if no CMS structure is being input (for example with
175B<-encrypt> or B<-sign>) this option has no effect.
176
177=item B<-rctform SMIME|PEM|DER>
178
179specify the format for a signed receipt for use with the B<-receipt_verify>
180operation.
181
182=item B<-out filename>
183
184the message text that has been decrypted or verified or the output MIME
185format message that has been signed or verified.
186
187=item B<-outform SMIME|PEM|DER>
188
189this specifies the output format for the CMS structure. The default
190is B<SMIME> which writes an S/MIME format message. B<PEM> and B<DER>
191format change this to write PEM and DER format CMS structures
192instead. This currently only affects the output format of the CMS
193structure, if no CMS structure is being output (for example with
194B<-verify> or B<-decrypt>) this option has no effect.
195
196=item B<-stream -indef -noindef>
197
198the B<-stream> and B<-indef> options are equivalent and enable streaming I/O
199for encoding operations. This permits single pass processing of data without
200the need to hold the entire contents in memory, potentially supporting very
201large files. Streaming is automatically set for S/MIME signing with detached
202data if the output format is B<SMIME> it is currently off by default for all
203other operations.
204
205=item B<-noindef>
206
207disable streaming I/O where it would produce and indefinite length constructed
208encoding. This option currently has no effect. In future streaming will be
209enabled by default on all relevant operations and this option will disable it.
210
211=item B<-content filename>
212
213This specifies a file containing the detached content, this is only
214useful with the B<-verify> command. This is only usable if the CMS
215structure is using the detached signature form where the content is
216not included. This option will override any content if the input format
217is S/MIME and it uses the multipart/signed MIME content type.
218
219=item B<-text>
220
221this option adds plain text (text/plain) MIME headers to the supplied
222message if encrypting or signing. If decrypting or verifying it strips
223off text headers: if the decrypted or verified message is not of MIME 
224type text/plain then an error occurs.
225
226=item B<-noout>
227
228for the B<-cmsout> operation do not output the parsed CMS structure. This
229is useful when combined with the B<-print> option or if the syntax of the CMS
230structure is being checked.
231
232=item B<-print>
233
234for the B<-cmsout> operation print out all fields of the CMS structure. This
235is mainly useful for testing purposes.
236
237=item B<-CAfile file>
238
239a file containing trusted CA certificates, only used with B<-verify>.
240
241=item B<-CApath dir>
242
243a directory containing trusted CA certificates, only used with
244B<-verify>. This directory must be a standard certificate directory: that
245is a hash of each subject name (using B<x509 -hash>) should be linked
246to each certificate.
247
248=item B<-md digest>
249
250digest algorithm to use when signing or resigning. If not present then the
251default digest algorithm for the signing key will be used (usually SHA1).
252
253=item B<-[cipher]>
254
255the encryption algorithm to use. For example triple DES (168 bits) - B<-des3>
256or 256 bit AES - B<-aes256>. Any standard algorithm name (as used by the
257EVP_get_cipherbyname() function) can also be used preceded by a dash, for 
258example B<-aes_128_cbc>. See L<B<enc>|enc(1)> for a list of ciphers
259supported by your version of OpenSSL.
260
261If not specified triple DES is used. Only used with B<-encrypt> and 
262B<-EncryptedData_create> commands.
263
264=item B<-nointern>
265
266when verifying a message normally certificates (if any) included in
267the message are searched for the signing certificate. With this option
268only the certificates specified in the B<-certfile> option are used.
269The supplied certificates can still be used as untrusted CAs however.
270
271=item B<-no_signer_cert_verify>
272
273do not verify the signers certificate of a signed message.
274
275=item B<-nocerts>
276
277when signing a message the signer's certificate is normally included
278with this option it is excluded. This will reduce the size of the
279signed message but the verifier must have a copy of the signers certificate
280available locally (passed using the B<-certfile> option for example).
281
282=item B<-noattr>
283
284normally when a message is signed a set of attributes are included which
285include the signing time and supported symmetric algorithms. With this
286option they are not included.
287
288=item B<-nosmimecap>
289
290exclude the list of supported algorithms from signed attributes, other options
291such as signing time and content type are still included.
292
293=item B<-binary>
294
295normally the input message is converted to "canonical" format which is
296effectively using CR and LF as end of line: as required by the S/MIME
297specification. When this option is present no translation occurs. This
298is useful when handling binary data which may not be in MIME format.
299
300=item B<-nodetach>
301
302when signing a message use opaque signing: this form is more resistant
303to translation by mail relays but it cannot be read by mail agents that
304do not support S/MIME.  Without this option cleartext signing with
305the MIME type multipart/signed is used.
306
307=item B<-certfile file>
308
309allows additional certificates to be specified. When signing these will
310be included with the message. When verifying these will be searched for
311the signers certificates. The certificates should be in PEM format.
312
313=item B<-certsout file>
314
315any certificates contained in the message are written to B<file>.
316
317=item B<-signer file>
318
319a signing certificate when signing or resigning a message, this option can be
320used multiple times if more than one signer is required. If a message is being
321verified then the signers certificates will be written to this file if the
322verification was successful.
323
324=item B<-recip file>
325
326when decrypting a message this specifies the recipients certificate. The
327certificate must match one of the recipients of the message or an error
328occurs.
329
330When encrypting a message this option may be used multiple times to specify
331each recipient. This form B<must> be used if customised parameters are
332required (for example to specify RSA-OAEP).
333
334=item B<-keyid>
335
336use subject key identifier to identify certificates instead of issuer name and
337serial number. The supplied certificate B<must> include a subject key
338identifier extension. Supported by B<-sign> and B<-encrypt> options.
339
340=item B<-receipt_request_all -receipt_request_first>
341
342for B<-sign> option include a signed receipt request. Indicate requests should
343be provided by all receipient or first tier recipients (those mailed directly
344and not from a mailing list). Ignored it B<-receipt_request_from> is included.
345
346=item B<-receipt_request_from emailaddress>
347
348for B<-sign> option include a signed receipt request. Add an explicit email
349address where receipts should be supplied.
350
351=item B<-receipt_request_to emailaddress>
352
353Add an explicit email address where signed receipts should be sent to. This 
354option B<must> but supplied if a signed receipt it requested.
355
356=item B<-receipt_request_print>
357
358For the B<-verify> operation print out the contents of any signed receipt
359requests.
360
361=item B<-secretkey key>
362
363specify symmetric key to use. The key must be supplied in hex format and be
364consistent with the algorithm used. Supported by the B<-EncryptedData_encrypt>
365B<-EncrryptedData_decrypt>, B<-encrypt> and B<-decrypt> options. When used
366with B<-encrypt> or B<-decrypt> the supplied key is used to wrap or unwrap the
367content encryption key using an AES key in the B<KEKRecipientInfo> type.
368
369=item B<-secretkeyid id>
370
371the key identifier for the supplied symmetric key for B<KEKRecipientInfo> type.
372This option B<must> be present if the B<-secretkey> option is used with
373B<-encrypt>. With B<-decrypt> operations the B<id> is used to locate the
374relevant key if it is not supplied then an attempt is used to decrypt any
375B<KEKRecipientInfo> structures.
376
377=item B<-econtent_type type>
378
379set the encapsulated content type to B<type> if not supplied the B<Data> type
380is used. The B<type> argument can be any valid OID name in either text or
381numerical format. 
382
383=item B<-inkey file>
384
385the private key to use when signing or decrypting. This must match the
386corresponding certificate. If this option is not specified then the
387private key must be included in the certificate file specified with
388the B<-recip> or B<-signer> file. When signing this option can be used
389multiple times to specify successive keys.
390
391=item B<-keyopt name:opt>
392
393for signing and encryption this option can be used multiple times to
394set customised parameters for the preceding key or certificate. It can
395currently be used to set RSA-PSS for signing, RSA-OAEP for encryption
396or to modify default parameters for ECDH.
397
398=item B<-passin arg>
399
400the private key password source. For more information about the format of B<arg>
401see the B<PASS PHRASE ARGUMENTS> section in L<openssl(1)|openssl(1)>.
402
403=item B<-rand file(s)>
404
405a file or files containing random data used to seed the random number
406generator, or an EGD socket (see L<RAND_egd(3)|RAND_egd(3)>).
407Multiple files can be specified separated by a OS-dependent character.
408The separator is B<;> for MS-Windows, B<,> for OpenVMS, and B<:> for
409all others.
410
411=item B<cert.pem...>
412
413one or more certificates of message recipients: used when encrypting
414a message. 
415
416=item B<-to, -from, -subject>
417
418the relevant mail headers. These are included outside the signed
419portion of a message so they may be included manually. If signing
420then many S/MIME mail clients check the signers certificate's email
421address matches that specified in the From: address.
422
423=item B<-purpose, -ignore_critical, -issuer_checks, -crl_check, -crl_check_all, -policy_check, -extended_crl, -x509_strict, -policy -check_ss_sig -no_alt_chains>
424
425Set various certificate chain valiadition option. See the
426L<B<verify>|verify(1)> manual page for details.
427
428=back
429
430=head1 NOTES
431
432The MIME message must be sent without any blank lines between the
433headers and the output. Some mail programs will automatically add
434a blank line. Piping the mail directly to sendmail is one way to
435achieve the correct format.
436
437The supplied message to be signed or encrypted must include the
438necessary MIME headers or many S/MIME clients wont display it
439properly (if at all). You can use the B<-text> option to automatically
440add plain text headers.
441
442A "signed and encrypted" message is one where a signed message is
443then encrypted. This can be produced by encrypting an already signed
444message: see the examples section.
445
446This version of the program only allows one signer per message but it
447will verify multiple signers on received messages. Some S/MIME clients
448choke if a message contains multiple signers. It is possible to sign
449messages "in parallel" by signing an already signed message.
450
451The options B<-encrypt> and B<-decrypt> reflect common usage in S/MIME
452clients. Strictly speaking these process CMS enveloped data: CMS
453encrypted data is used for other purposes.
454
455The B<-resign> option uses an existing message digest when adding a new
456signer. This means that attributes must be present in at least one existing
457signer using the same message digest or this operation will fail.
458
459The B<-stream> and B<-indef> options enable experimental streaming I/O support.
460As a result the encoding is BER using indefinite length constructed encoding
461and no longer DER. Streaming is supported for the B<-encrypt> operation and the
462B<-sign> operation if the content is not detached.
463
464Streaming is always used for the B<-sign> operation with detached data but
465since the content is no longer part of the CMS structure the encoding
466remains DER.
467
468If the B<-decrypt> option is used without a recipient certificate then an
469attempt is made to locate the recipient by trying each potential recipient
470in turn using the supplied private key. To thwart the MMA attack
471(Bleichenbacher's attack on PKCS #1 v1.5 RSA padding) all recipients are
472tried whether they succeed or not and if no recipients match the message
473is "decrypted" using a random key which will typically output garbage. 
474The B<-debug_decrypt> option can be used to disable the MMA attack protection
475and return an error if no recipient can be found: this option should be used
476with caution. For a fuller description see L<CMS_decrypt(3)|CMS_decrypt(3)>).
477
478=head1 EXIT CODES
479
480=over 4
481
482=item Z<>0
483
484the operation was completely successfully.
485
486=item Z<>1
487
488an error occurred parsing the command options.
489
490=item Z<>2
491
492one of the input files could not be read.
493
494=item Z<>3
495
496an error occurred creating the CMS file or when reading the MIME
497message.
498
499=item Z<>4
500
501an error occurred decrypting or verifying the message.
502
503=item Z<>5
504
505the message was verified correctly but an error occurred writing out
506the signers certificates.
507
508=back
509
510=head1 COMPATIBILITY WITH PKCS#7 format.
511
512The B<smime> utility can only process the older B<PKCS#7> format. The B<cms>
513utility supports Cryptographic Message Syntax format. Use of some features
514will result in messages which cannot be processed by applications which only
515support the older format. These are detailed below.
516
517The use of the B<-keyid> option with B<-sign> or B<-encrypt>.
518
519The B<-outform PEM> option uses different headers.
520
521The B<-compress> option.
522
523The B<-secretkey> option when used with B<-encrypt>.
524
525The use of PSS with B<-sign>.
526
527The use of OAEP or non-RSA keys with B<-encrypt>.
528
529Additionally the B<-EncryptedData_create> and B<-data_create> type cannot
530be processed by the older B<smime> command.
531
532=head1 EXAMPLES
533
534Create a cleartext signed message:
535
536 openssl cms -sign -in message.txt -text -out mail.msg \
537	-signer mycert.pem
538
539Create an opaque signed message
540
541 openssl cms -sign -in message.txt -text -out mail.msg -nodetach \
542	-signer mycert.pem
543
544Create a signed message, include some additional certificates and
545read the private key from another file:
546
547 openssl cms -sign -in in.txt -text -out mail.msg \
548	-signer mycert.pem -inkey mykey.pem -certfile mycerts.pem
549
550Create a signed message with two signers, use key identifier:
551
552 openssl cms -sign -in message.txt -text -out mail.msg \
553	-signer mycert.pem -signer othercert.pem -keyid
554
555Send a signed message under Unix directly to sendmail, including headers:
556
557 openssl cms -sign -in in.txt -text -signer mycert.pem \
558	-from steve@openssl.org -to someone@somewhere \
559	-subject "Signed message" | sendmail someone@somewhere
560
561Verify a message and extract the signer's certificate if successful:
562
563 openssl cms -verify -in mail.msg -signer user.pem -out signedtext.txt
564
565Send encrypted mail using triple DES:
566
567 openssl cms -encrypt -in in.txt -from steve@openssl.org \
568	-to someone@somewhere -subject "Encrypted message" \
569	-des3 user.pem -out mail.msg
570
571Sign and encrypt mail:
572
573 openssl cms -sign -in ml.txt -signer my.pem -text \
574	| openssl cms -encrypt -out mail.msg \
575	-from steve@openssl.org -to someone@somewhere \
576	-subject "Signed and Encrypted message" -des3 user.pem
577
578Note: the encryption command does not include the B<-text> option because the
579message being encrypted already has MIME headers.
580
581Decrypt mail:
582
583 openssl cms -decrypt -in mail.msg -recip mycert.pem -inkey key.pem
584
585The output from Netscape form signing is a PKCS#7 structure with the
586detached signature format. You can use this program to verify the
587signature by line wrapping the base64 encoded structure and surrounding
588it with:
589
590 -----BEGIN PKCS7-----
591 -----END PKCS7-----
592
593and using the command, 
594
595 openssl cms -verify -inform PEM -in signature.pem -content content.txt
596
597alternatively you can base64 decode the signature and use
598
599 openssl cms -verify -inform DER -in signature.der -content content.txt
600
601Create an encrypted message using 128 bit Camellia:
602
603 openssl cms -encrypt -in plain.txt -camellia128 -out mail.msg cert.pem
604
605Add a signer to an existing message:
606
607 openssl cms -resign -in mail.msg -signer newsign.pem -out mail2.msg
608
609Sign mail using RSA-PSS:
610
611 openssl cms -sign -in message.txt -text -out mail.msg \
612	-signer mycert.pem -keyopt rsa_padding_mode:pss
613
614Create encrypted mail using RSA-OAEP:
615
616 openssl cms -encrypt -in plain.txt -out mail.msg \
617	-recip cert.pem -keyopt rsa_padding_mode:oaep
618
619Use SHA256 KDF with an ECDH certificate:
620
621 openssl cms -encrypt -in plain.txt -out mail.msg \
622	-recip ecdhcert.pem -keyopt ecdh_kdf_md:sha256
623
624=head1 BUGS
625
626The MIME parser isn't very clever: it seems to handle most messages that I've
627thrown at it but it may choke on others.
628
629The code currently will only write out the signer's certificate to a file: if
630the signer has a separate encryption certificate this must be manually
631extracted. There should be some heuristic that determines the correct
632encryption certificate.
633
634Ideally a database should be maintained of a certificates for each email
635address.
636
637The code doesn't currently take note of the permitted symmetric encryption
638algorithms as supplied in the SMIMECapabilities signed attribute. this means the
639user has to manually include the correct encryption algorithm. It should store
640the list of permitted ciphers in a database and only use those.
641
642No revocation checking is done on the signer's certificate.
643
644=head1 HISTORY
645
646The use of multiple B<-signer> options and the B<-resign> command were first
647added in OpenSSL 1.0.0
648
649The B<keyopt> option was first added in OpenSSL 1.1.0
650
651The use of B<-recip> to specify the recipient when encrypting mail was first
652added to OpenSSL 1.1.0
653
654Support for RSA-OAEP and RSA-PSS was first added to OpenSSL 1.1.0. 
655
656The use of non-RSA keys with B<-encrypt> and B<-decrypt> was first added
657to OpenSSL 1.1.0.
658
659The -no_alt_chains options was first added to OpenSSL 1.0.2b.
660
661=cut
662