This is the registry of codes used for Signature Flags in ARPA2 Identities, especially for encodings in the local part before the @ character.

Signature Flags

Signature Flags give hints about the data included into the signature. The flags are attached directly before the signature.

These flags occur in groups of five, each represented in a BASE32 character. The meaning of flags 0 to 3 in each character depends on the tables below.

The meaning of flag 4 is the same in each character; it indicates that the next character is also part of the signature flags. This is a more compact notation than with an explicit separator character, which is an advantage in the 64 characters available for local parts.

Flags' BASE32 characters are numbered from 0 for the first or left-most. The bits within each character are the usual bit positions in the integer value for the BASE32 character, valued as 2-to-the-power of the bit position.

In an integer notation, char 0 maps to the lowest-valued nibble, and extra chars map to the next, so the integer bit addressed would be numbered "(char# * 4 + bit#)".

All flags are critical, meaning: when they are not recognised by software, they lead to rejection.

There must always be at least one character in the BASE32 flags field. With the exception of this first character, the last character must not be zero (this defines a canonical form).

 Char | Bit | Meaning
------+-----+----------------------------------------------------------------------------------
   0  |  0  | Include expiration time: integer, days since key creation.
   0  |  1  | Include remote domain: string, canonicalised as lowercase, no trailing dot.
   0  |  2  | Include remote local part: text before the last @ symbol, may be case sensitive.
   0  |  3  | Include freetext after local base identity, but excluding parameters.
   0  |  4  | Next character is signature flags char 1.
------+-----+----------------------------------------------------------------------------------
   1  |  0  | Include machine-generated session identifier (protocol specific).
   1  |  1  | Include human-entered subject (protocol-specific canonical form).
   1  |  2  | Include automation-friendly topic in subject, [bracketed].
   1  |  3  | Encrypted local part.
   1  |  4  | Next character is signature flags char 2.
------+-----+----------------------------------------------------------------------------------

The local base identity must always be included, otherwise one user might setup another for spam. (We will arrange access control to other user identities, so groups in which one is involved are different.)

FWIW: Ik vind "freetext" lastig lezen, is er een andere term te vinden die even helder werkt als "alias" maar die het niet nodig maakt rare uitleg te geven bij services? Die uitleg zou me liever zijn dan deze term aan users te moeten communiceren. Wat denk jij?

Use in constraints: All these flags add restrictions. As a result, the following is possible:

• Policies can strengthen privacy by setting minimum flags. For instance, a sender may include flags (but no signature) in a sender address, and/or a sender's alias or even an entire domain could define minimal flags. Such flags can be composed wit bit-wise OR.

TODO: Only the expiration time is currently a parameter. It might be an idea to include the expiration date in a similar attachment to the signature, so not +expparam+flags-signature+ but +flagsexpparamsignature+ where bit 4 continues the format. The point where this gets less compact is beyond 20 data bits, or in a million days.

The encryption of the local-part leads to a number of constraints, specifically to end the chain of signed parts with the local base identity and local freetext. In general, the order of inclusions would be in the order of the characters and, within that, the order of the bits.