Military Messaging is referenced by various names, including Formal Messaging and High Grade Messaging (HGM). It has been traditionally provided by ACP 127, but SMTP and STANAG 4406 are increasingly used. An example military message displayed by Harrier is shown below.

There are superficial similarities to email, but key service differences can be seen from inspection of the example message.

• Military messages are sent between organizations (not roles or users), reflecting the “command” nature of military messages.
• Military messages have “action” and “information” recipients, which is similar to To:/Cc:, but reflects formal responsibilities.
• Action and Information recipients have independently specified precedence (e.g., “FLASH”), which informs recipients of priority.
• Harrier shows a “due time”, which is based on the precedence of the current recipient, any “reply by” time, and message delivery time. This provides an indication to the recipient of when the message needs to be processed.
• DTG (Date Time Group) shows the formal time that the message takes effect, which can be past or future. Filing time reflects when the message was submitted.  Times are shown in a preferred military format with Zulu time zone.
• Security Label is associated with every message.
• Message Type gives information on the exercise/operation to which the message applies.
• SICs (Subject Information Codes) provide formal information on the nature of the message.
• This message contains an ADatP-3/APP-11 Message Text Format (MTF), which can be downloaded as an attachment for processing in a C2 (Command and Control) system.

Harrier is built using modern email protocols (IMAP, SMTP & S/MIME) and can be used as a general-purpose email interface for communication between roles or users. Harrier provides configuration options to facilitate use for email. It is likely to be of most interest to those needing Harrier features not generally available in email clients, such as security label support, exempted recipient support, and time controls.

While military messaging provides communication between organizations, mailboxes are role-based. Harrier supports role-based mailboxes by authenticating users and then allowing the user to select a role-based mailbox that the user is authorized to access. This selection is illustrated below:

Harrier can switch between role-based mailboxes.

When a message is sent to an organization, it will be distributed to role-based mailboxes based on message content and SICs using a profiler, such as the one provided by M-Switch Profiler. Harrier will recognize messages that have been profiled and make this clear to the Harrier user, including whether the recipient is action or info (which can be controlled by the profiler). Harrier can also show a list of all action and info roles to which a profiled message was delivered.

Military Distribution Lists, which provide another message distribution mechanism, split action and info recipients. Harrier will show when a message has been expanded by a military distribution list, and whether the current mailbox is action or info.

Military messages often make use of a draft and release process to support formal release and approval of messages by an appropriate officer. This linear release process is complemented by a parallel review process, to support drafter-centric review. This is supported by Harrier and described in the Isode whitepaper [Isode’s Draft, Review & Release Solution].

Harrier provides a message compose facility, which looks like a general-purpose email compose with extra fields. Some of the fields in the above screenshot have already been described, and others will be familiar from general-purpose email. Other fields are:

• Releaser. When a message is being drafted, this specifies the releaser, which may be optional or mandatory, based on policy/configuration.
• Reviewers. An optional list of reviewers, who will review the message before it passes to the releaser.
• Exempt. A list of recipients to which the message will not be delivered. This will generally be used in conjunction with distribution lists.
• Expires. A date at which the message is no longer valid. Harrier will display this information on reception.
• Reply By. A date by which a reply is needed. Harrier will flag this information on reception and warn if the time is close.
• Harrier compose may be used for plain text messages or for HTML encoded messages with font and list options.

Harrier provides a scan listing of messages, shown above, sorted by precedence and filing time. Some of this is familiar from email interfaces, but some points are worth noting:

• Military Message precedence for the active mailbox is shown.
• A target processing time is shown for each message, based on arrival time, reply by time, and configurable target processing time for the message precedence.
• A Security Label for each message is shown.
• An icon indicates if the message was received directly, profiled, or through a distribution list. This Icon also indicates draft/review/release processing status.
• An icon indicates if the active mailbox is an action or an info recipient.
• Folders show daily message archives. Messages can be archived, but not deleted, so that messages are always retained for audit.
• The scan listing allows selection of messages. Messages can also be selected by free text search in the choice of body, subject, SIC, action, info, from, and with filter on precedence.

Harrier identifies message recipients from an LDAP Directory (Isode’s M-Vault or Microsoft’s Active Directory can be used). Cobalt provisioning marks directory entries as Users, Roles, or Organizations. The type of some entries is automatic, and is selected for entries that represent redirections or distribution lists.

Harrier presents this information as two distinct address books:

1. Organizations. This is used for Action/Info/Exempt fields.
2. Roles. This is used in the draft and release process and also for local messages between roles.

Harrier can be used to support C2 (Command and Control), which makes use of MTF (Message Text Format) data, such as ADatP-3 and OTH-Gold. Harrier provides an integrated way to use systematic IRIS Forms to create and display MTF. Details for this can be found in the white paper C2 Systems use of MTF and Messaging.

Harrier may be configured in an ACP 127 Mode, which restricts messages to capabilities that an ACP 127 client can provide. When used in ACP127 mode, addresses are presented as ACP 127 RI (Routing Indicator) and PLA (Plain Language Address) with SMTP addressing hidden from the user. Also, lines are limited to 69 characters, the character set is restricted to ITA2 or IA5, and attachments are disabled. This is helpful when Harrier is deployed in a system where ACP 127 is predominantly used.

Security Labels selection is driven by the configured Security Policy, restricting Harrier to selecting a security label that is appropriate for the intended recipient(s). Multiple security policies can be supported, allowing the user to select the appropriate policy for the message/deployment. Two security label families are supported:

1. ESS security labels as specified in RFC 2634 “enhance Security Services for SMIME”, following the NATO AC 322 architecture, and encoded following:
   1. RFC 7444 “Security Labels in Internet Email”.
2. NATO Confidentiality labels:
   1. STANAG 4774 “CONFIDENTIALITY METADATA LABEL SYNTAX”
   2. STANAG 4778 “METADATA BINDING MECHANISM”
   3. NATO SRD 4778.2 Chapter 3 “Simple Mail Transfer Protocol Binding Profile”

Harrier allows drop-down selection of labels taken from the system and mailbox-specific catalogues. Harrier allows the creation of custom security labels.

Harrier also supports security label access control checking against role clearance (so that only matching security labels are offered) and against recipient clearance.

Recipient capabilities may be stored in the directory entry of each recipient. Harrier will ensure that the message is compatible with those capabilities, which can include:

• Support of Attachments
• Maximum Line Length
• Maximum Message Size
• Supported Character Sets
• Checking against Recipient Security Clearance that security label is allowed

Capability checking is particularly important when using Harrier as an interface to older messaging standards, such as ACP127, where recipients may have limited capabilities.

All protocol links with Harrier can be protected with Transport Layer Security (TLS) and it is strongly recommended that this is done.

Harrier’s own private key may be held by Harrier on disk or making use of an HSM (Hardware Security Module) with a PKCS#11 interface.

Harrier supports message signing and encryption following the S/MIME as specified in RFC 5751 “Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1”. Notes:

• S/MIME private keys are stored on an HSM and managed by Cobalt. Note that SoftHSM is supported as an HSM option.
• Signing can be mandated (recommended) and users alerted to messages that are not correctly signed.
• Encryption may enabled or disabled. When enabled it is user choice.
• Encryption may use envelope or triple wrap.
• Header signing is provided as an option. It is strongly recommended, noting that some S/MIME clients do not support it.
• S/MIME messages are decrypted on initial access. The primary S/MIME goal is end to end protection.  This decryption prevents issues with long term key management and message access.

Harrier provides a Web interface for server administrators to configure Harrier.  Key features:

• Full configuration of all Harrier options and capabilities
• Secure bootstrap
• Sensible defaulting of parameters to facilitate startup
• Per domain and global configuration options
• Security features, including TLS, HSM, S/MIME and Security Labels/Security Policy

The Harrier server web user interface also provides a monitoring capability to show server activity and key operational parameters.

Setting up a system with Harrier requires a good deal of supporting configuration of users, roles, lists, and other components. This is done by Isode’s Cobalt product, which is described in the Isode whitepaper [Provisioning for Military Messaging Handling Systems].

The Harrier Military Messaging Client is provided as  server. The UI for Harrier is a JavaScript module that runs in a Web browser. The Harrier MMHS API is the interface between the JavaScript client and the server. So, the Harrier MMHS API is built into Harrier and is not an additional component. The primary purpose of the API is to support the Web UI.

The Harrier MMHS API can also be used by applications other than the Harrier UI, and it is this type of usage described in this product overview. The Harrier API is specified as a JSON interface, primarily using WebSockets, but also using HTTP. It is a specification of how to use the interface, and unlike more traditional APIs, does not require any Isode-provided libraries.

Applications can make use of the Harrier MMHS API to communicate with the Harrier Server. There are two broad approaches to using this API:

1. A JavaScript application, running in a Web browser, that uses the API in a manner analogous to the Harrier UI.
2. A traditional application, using a JSON/WebSocket/HTTP interface (supported in many programming languages) to access Harrier Server.

This provides a simple model for an application to access MMHS services.

The Harrier MMHS API is documented and available to all Harrier MMHS API customers and evaluators. The API makes available all of the functions used by the Harrier UI, although it is expected that many API users will use a select subset of these functions. The key functions of the API are:

• SASL-based authentication of the client.
• Access to MMHS Fields, including
  • Action/Info Recipients
  • From
  • Action/Info Precedence
  • SICs
  • Security Label
• Message attachments of any format
• Support of MTFs, including:
  • Independent attachment
  • Inclusion in the text body part
  • Extraction from the text body part
• Message Submission
• Listing of messages in the inbox
• Message search
• Message retrieval
• Message deletion
• Message archive

The Harrier MMHS API allows an application to connect to Harrier to submit and retrieve messages. Delivered messages are stored in Isode’s M-Box product.  The API allows messages to be searched for, retrieved, and then deleted.

Submitted messages are sent to Isode’s M-Switch product, where they can be distributed using a choice of MMHS Protocols: ACP 127; STANAG 4406, or MMHS over SMTP. M-Vault holds configuration and account information, used by M-Switch, M-Bo,x and Harrier. It provides authentication for the Web Application.

The Harrier MMHS API is included with the Harrier product, and so customers purchasing Harrier get the API and have the right to use Harrier with the UI and any application using the Harrier MMHS API. Support covers the UI and Harrier Server use by applications developed by Isode partners who have purchased the Harrier MMHS API and maintain support for the API with Isode.

Harrier MMHS API Support Package is sold to Isode partners who develop applications using the API. This package includes:

• Rights to develop applications using the API.
• API documentation.
• Example JavaScript applications, with documentation, with a focus on anticipated C2 use of the API.
• Support for the API.
• Information on planned updates to the API. Changes to the API will be avoided where possible, but some are expected as the technology moves forward.