Subject: [lamps] Possible inconsistencies or ambiguities in RFC 8551

From: Metin Savignano <[email-masked]>
Date: Fri, 7 Aug 2020 13:01:53 +0200

Dear authors,

First of all, thank you very much for your work to create a new and better version of S/MIME! 

As an author of an S/MIME app, we are working through RFC 8551 to determine the changes we have to implement in order to fully comply to the S/MIME 4.0 specs.

However, I’ve come to a point where I seem unable to understand what the RFC actually recommends with regard to the backward compatibility. I’ve also discussed this with another software developer, but we both weren’t sure how to read it. It would be awesome if you could help me with a clarification.

In the relevant scenario, the sending agent wants to send encrypted email to a recipient with unknown capabilities.

With regard to backward compatibility, RFC 8551 states in section 1.4:

   S/MIME version 4.0 agents ought to attempt to have the greatest
   interoperability possible with agents for prior versions of S/MIME.

Although this is a very general statement, I believe it is contradictory to the description about how to decide which content encryption cipher to use in section 2.7.1.2:

   If the following two conditions are met, the sending agent SHOULD use
   AES-256 GCM, as AES-256 GCM is a stronger algorithm and is required
   by S/MIME v4.0:

   -  The sending agent has no knowledge of the encryption capabilities
      of the recipient.

   -  The sending agent has no knowledge of the version of S/MIME used
      or supported by the recipient.

I don’t understand why we should choose AES-256-GCM if we don’t know about the recipients capabilities and S/MIME version. 

For example, if the recipient uses an S/MIME 3.2 compliant software, as I understand RFC 5751, that software need not know about AES-256-GCM. The GCM block mode is not even mentioned in earlier S/MIME versions. 

As a consequence, doesn’t the selection of AES-256-GCM contradict the "attempt to have the greatest interoperability possible with agents for prior versions of S/MIME“? 

The common capability in both S/MIME versions would be AES-128-CBC, wouldn’t it?

Also, I do not really understand the following sentence:

   If the sending agent chooses not to use AES-256 GCM in this step,
   given the presumption is that a client implementing AES-GCM would do
   both AES-256 and AES-128, it SHOULD use AES-128 CBC.

It appears to me as if this sentence was grammatically either wrong or uses a construct that I don’t understand (I’m not a native speaker). I don’t understand what "given the presumption is that a client implementing AES-GCM would do both AES-256 and AES-128“  is meant to tell me in that context. Also, I’m not sure if the word „client“ is meant to refer to the sending or receiving client. At first, I thought it’s the receiving client, but after re-reading a few times, I’m unsure if it’s the sending agent, because I don’t understand why I should make presumptions about the receiving client implementing AES-GCM when I don’t know anything about it.

I would recommend that this sentence maybe rephrase to make it more understandable for non-native speakers.

What I would have expected in section 2.7.1.2:

To maintain "greatest interoperability possible with agents for prior versions of S/MIME“, the RFC would select AES-128-CBC if the recipient’s capabilities and S/MIME version aren’t known.

Where am I off the track?

Thanks a lot!

Metin Savignano