TIP: Click on subject to list as thread! ANSI
echo: net_dev
to: Bill Brown
from: andrew clarke
date: 1995-02-24 00:57:28
subject: FSC-0073

BB> There's been some discussion recently about FSC-0073 in an
 BB> echo but no one can shed much light on the subject.  Can
 BB> anyone here explain it, its purpose, or provide a copy of
 BB> it?  Thanks.

  | 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.

--- 
* Origin: Blizzard of Ozz, Melbourne, Australia (3:635/727.4)
SEEN-BY: 50/99 209/720 620/243 632/103 341 348 386 635/503 727 640/201 206
SEEN-BY: 640/217 297 305 820 822 823 690/660 711/409 410 413 430 431 807 808
SEEN-BY: 711/809 816 934 942 712/515 713/888 800/1 7877/2809
@PATH: 635/727 632/348 640/820 711/409 808 809 934

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.