This page documents various logical options for implementing protocol level support for ensuring the identity of sender and receiver that are known to conform to supported message handling policy models.

Option
Pros
Cons
Policy Considerations
TLS with mutual authentication
Relies on standard, well supported infrastructure
Requires single trust circle per IP address
  • Requires strong policy and governance to establish single trust circle
  • Places trust at the HISP level, requires strong policy and governance to ensure trust in HISP is warranted
TLS + DNS support to support discovery of servers that support multiple certificates. Examples include:
  • NAPTR + SRV + CERT DNS RRs
  • Relies on standard, well supported infrastructure for TLS handling
  • DNS options well supported and understood by SIP
  • DNS options not well supported outside of SIP, so support for standard resolver libraries and DNS admin tools lacking
  • Requires either the not universally support SNI extension, discovery of IP + port (through something like NAPTR), or one IP address per health internet domain, which may not be sustainable
  • HISP must hold trust keys so requires delegating verification of trust assertions to the HISP level
Transport level mutual authentication that handles multiple trust circles:
  • Custom cert-based HTTP-Authenticate/Authorize pair
  • Custom cert-based SASL authentication
Allows mutual authentication before message transport, so encryption of message body is not absolutely required (TLS-based transport encryption is still required, of course)
  • No standard mutual auth methods exist, requires new art
  • Implementations must perform cert verification, CRL or OCSP checking, etc., rather than relying on well-tested HTTP/SMTP server implementations
  • HISP must hold trust keys so requires delegating verification of trust assertions to the HISP level
Content-based security and authentication, e.g.:
  • S/MIME
  • WSS x509 or SwA
  • Allows separation between routing/exchange functions and trust functions
  • Allows use of public SMTP infrastructure (SMTP only)
  • S/MIME based on well established art
  • Requires encryption of content in addition to transport encryption because trust can not be established prior to transport
  • Implementations must perform cert verification, CRL or OCSP checking, etc., rather than relying on well-tested HTTP/SMTP server implementations
  • WSS options do not have as much experience and settled art
None, most policy neutral option