| Document: FSC-0073
  | Version:  001
  | Date:     28th July 1993
  | Author:   John Mudge


                ENCRYPTED MESSAGE IDENTIFICATION FOR FIDONET
                                *DRAFT I* 
                        FIDONET TECHNICAL COMMENT

                           Author :  John Mudge
                           Fido   :  1:352/111
                           Date   :  25FEB1993

ABSTRACT:

The following document proposes a standard for encrypted message 
identification for Fidonet and Fidonet-based electronic mail
systems.

The proposed standard will assist in encrypted-message detection.
The standard consists of mandatory and suggested portions; however 
the term "mandatory" does not mean that any Fidonet product must 
implement this standard; it simply means that those that do claim
to implement this standard must do so in the way described.

STATUS OF THIS DOCUMENT:

This FSC suggests a proposed protocol for the Fidonet(R) 
community, and requests discussion and suggestions for 
improvements.  Distribution of this document is unlimited.

Fido and Fidonet are registered marks of Tom Jennings and Fido 
Software.

BACKGROUND:

Currently, Fidonet encrypted messages are not uniquely identified.  
A variety of schemes are in place to determine whether a message 
received by a Fidonet node has been encrypted, but all of them 
involve encryption method specific tests.  Current Fido Policy 
(Policy4) prohibits routing encrypted material through systems which
have not given specific prior approval.  This FSC proposes a method
of identifying such traffic, but makes no effort to determine what
action should be taken after the identification.

IFNA KLUDGE LINES:

Fidonet supports a general method for sending additional information 
embedded in a message known as the "IFNA kludge line".  This is a 
line of text beginning with the ASCII SOH character (^A).  The 
characters following SOH are a word indicating the type of kludge 
line, and the remainder of the line contains information specific 
to that type.  This standard introduces a new type of kludge line,
the ENC.

FORMAT OF A MESSAGE ID - MANDATORY:

The mandatory portion of the ^AENC line shall consist of the Ascii SOH 
character immediately followed by the uppercase characters ENC and a 
colon and one space.

FORMAT OF A MESSAGE ID - SUGGESTED:

It is suggested, though not required, that the unique part of all 
^AENC lines consist of a unique product identifier following the 
same format as specified in FSC-0046 for ^APID kludge lines and
identifying the program used for encryption.  This product identifier
will allow message editors to invoke the appropriate decryption 
software.

EXAMPLE:

^AENC: PGP2.1
with PGP21 to be replaced with a two digit hex identifier at such
time as a central product registry exists.

IMPLEMENTATIONS:

As of this writing, several products are being written, notably by 
Fredric Rice and GK Pace, to implement this proposal.  Examples of
currently available programs are GENMSG V1.30 and PGP-TOSS.

SUMMARY:

As of this date, no public repository exists for encryption/decryption
product registration, but the FTSC is suggested as is the application 
form presented in FSC-0022.

I am publishing this information as a Fidonet technical comment in hopes
that other Fidonet products will eventually incorporate all or part of 
this standard as well, and that it will eventually form part of a 
Fidonet Technical Standard.

CREDITS:

I would like to thank all of the pioneers of Fidonet for making all of 
this possible.  The ^AENC proposal is the result of the collective 
efforts of many of the participants of the Fido PUBLIC_KEYS echo.  Much
of the wording and structure for this document I stole from authors of
previous FSC authors.  Special thanks go to GK Pace and Fredric Rice for
their ongoing programming efforts in support of public-key encryption 
systems.