1

If you examine an S/MIME-signed file with

$ openssl cms -in file.sgn -noout -cmsout -print

you see that S/MIME capabilities are also included in the signature:

... 
object: S/MIME Capabilities (1.2.840.113549.1.9.15)
        value.set:
          SEQUENCE:
 0:d=0  hl=2 l= 106 cons: SEQUENCE          
 2:d=1  hl=2 l=  11 cons:  SEQUENCE          
 4:d=2  hl=2 l=   9 prim:   OBJECT            :aes-256-cbc
15:d=1  hl=2 l=  11 cons:  SEQUENCE          
17:d=2  hl=2 l=   9 prim:   OBJECT            :aes-192-cbc
28:d=1  hl=2 l=  11 cons:  SEQUENCE          
30:d=2  hl=2 l=   9 prim:   OBJECT            :aes-128-cbc
41:d=1  hl=2 l=  10 cons:  SEQUENCE          
43:d=2  hl=2 l=   8 prim:   OBJECT            :des-ede3-cbc
...

In rfc2633 section 2.5.2 it is stated that these capabilities are included to show

... what the client announcing the SMIMECapabilites can support. A client does not have to list every capability it supports, and probably should not list all its capabilities so that the
capabilities list doesn't get too long.

This may explain, why for example sha1WithRSAEncryption is not in my list here. (Although it's quite important.)

But what use has this list then? Is it just there to have more attributes within a signature to design it in a more inimitably way?

Community
  • 1
user1511417
  • 617
  • 5
  • 20
  • It may make sense that capabilities that MUST be supported are not explicitly listed. I believe SHA-1 is not required, while SHA-256 is a MUST according to [S/MIME v3.2 as defined in RFC 5751](https://tools.ietf.org/html/rfc5751), so it could make sense if both of them were not included. Note that RFC 2633 is quite old and obsoleted. – not2savvy Feb 20 '18 at 21:32
  • Good point. I've compared this section to the new version. There are not really any updates for that part. – user1511417 Feb 21 '18 at 11:41

1 Answers1

1

The client usually supports more ciphers than it announces because there is a difference between both.

One thing is the capabilities - maybe a better name would be preferences - being a list of those ciphers that the clients wants the other client to use when sending messages.

The other thing is the list of actually supported ciphers, which is usually longer because the client needs to be able to process additional ciphers in incoming messages.

For example, sha1WithRSAEncryption is known to be weak, so while the client is capable of processing an incoming message with sha1WithRSAEncryption, it does not list it in its capabilities because it prefers to use a better algorithm.

Half OT:

However, the S/MIME Capabilities attribute is not written by many email clients. I assume that this is because nowadays, with IMAP mail servers and mobile devices, emails may be written and read using multiple different clients, so sending one client's S/MIME capabilities may not make as much sense as it used ro in earlier days.

not2savvy
  • 710
  • 5
  • 12