Skip to main content

10. Application Profiling Considerations

  1. Application Profiling Considerations

This document is designed to provide a set of security services but not impose algorithm implementation requirements for specific usage. The interoperability requirements are provided for how each of the individual services are used and how the algorithms are to be used for interoperability. The requirements about which algorithms and which services are needed are deferred to each application.

An example of a profile can be found in [RFC8613], where one was developed for carrying content in combination with CoAP headers.

It is intended that a profile of this document be created that defines the interoperability requirements for that specific application. This section provides a set of guidelines and topics that need to be considered when profiling this document.

  • Applications need to determine the set of messages defined in this document that they will be using. The set of messages corresponds fairly directly to the needed set of security services and security levels.

  • Applications may define new header parameters for a specific purpose. Applications will oftentimes select specific header parameters to use or not to use. For example, an application would normally state a preference for using either the IV or the Partial IV header parameter. If the Partial IV header parameter is specified, then the application also needs to define how the fixed portion of the IV is determined.

  • When applications use externally defined authenticated data, they need to define how that data is encoded. This document assumes that the data will be provided as a byte string. More information can be found in Section 4.3.

  • Applications need to determine the set of security algorithms that is to be used. When selecting the algorithms to be used as the mandatory-to-implement set, consideration should be given to choosing different types of algorithms when two are chosen for a specific purpose. An example of this would be choosing HMAC- SHA512 and AES-CMAC (Cipher-Based Message Authentication Code) as different MAC algorithms; the construction is vastly different between these two algorithms. This means that a weakening of one algorithm would be unlikely to lead to a weakening of the other algorithms. Of course, these algorithms do not provide the same level of security and thus may not be comparable for the desired security functionality. Additional guidance can be found in [BCP201].

  • Applications may need to provide some type of negotiation or discovery method if multiple algorithms or message structures are permitted. The method can range from something as simple as requiring preconfiguration of the set of algorithms to providing a discovery method built into the protocol. S/MIME provided a number of different ways to approach the problem that applications could follow:

    • Advertising in the message (S/MIME capabilities) [RFC8551].

    • Advertising in the certificate (capabilities extension) [RFC4262].

    • Minimum requirements for the S/MIME, which have been updated over time [RFC2633] [RFC3851] [RFC5751] [RFC8551]. (Note that [RFC2633] was obsoleted by [RFC3851], which was obsoleted by [RFC5751], which was obsoleted by [RFC8551].)

Last updated on