As per Relevance of the word originator, we have this rfc below:
Network Working Group J.
Request for Comments: 2876 WGSI, A Getronics
Category: Informational July 2000
Use of the KEA and SKIPJACK Algorithms in
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document describes the conventions for using the Key
Algorithm (KEA) and SKIPJACK encryption algorithm in conjunction
the Cryptographic Message Syntax [CMS] enveloped-data and encrypted
data content types
1.
Throughout this document, the terms MUST, MUST NOT, SHOULD and
are used in capital letters. This conforms to the definitions
[MUSTSHOULD]. [MUSTSHOULD] defines the use of these key words to
make the intent of standards track documents as clear as possible
The same key words are used in this document to help
achieve interoperability. Software that claims compliance with
document MUST provide the capabilities as indicated by the MUST,
NOT, SHOULD and MAY terms. The KEA and SKIPJACK
algorithms are described in [SJ-KEA].
2. Content Encryption
This section applies to the construction of both the enveloped-
and encrypted-data content types. Compliant software MUST meet
requirements stated in [CMS] Section 6.3, "Content-
Process". The input to the encryption process MUST be padded to
multiple of eight octets using the padding rules described in [CMS
Section 6.3. The content MUST be encrypted as a single string
the SKIPJACK algorithm in 64-bit Cipher Block Chaining (CBC)
using randomly-generated 8-byte Initialization Vector (IV) and 80-
SKIPJACK content-encryption key (CEK) values
Pawling Informational [Page 1]
RFC 2876 KEA and SKIPJACK Algorithms in CMS July 2000
3. Content Decryption
This section applies to the processing of both the enveloped-data
encrypted-data content types. The encryptedContent MUST be
as a single string using the SKIPJACK algorithm in 64-bit CBC mode
The 80-bit SKIPJACK CEK and the 8-byte IV MUST be used as inputs
the SKIPJACK decryption process. Following decryption, the
MUST be removed from the decrypted data. The padding rules
described in [CMS] Section 6.3, "Content-encryption Process".
4. Enveloped-data
The CMS enveloped-data content type consists of an encrypted
and wrapped CEKs for one or more recipients. Compliant software
meet the requirements for constructing an enveloped-data content
stated in [CMS] Section 6, "Enveloped-data Content Type". [CMS
Section 6 should be studied before reading this section, because
section does not repeat the [CMS] text
An 8-byte IV and 80-bit CEK MUST be randomly generated for
instance of an enveloped-data content type as inputs to the
algorithm for use to encrypt the content. The SKIPJACK CEK MUST
be used for encrypting the content of a single instance of
enveloped-data content type
KEA and SKIPJACK can be used with the enveloped-data content
using either of the following key management techniques defined
[CMS] Section 6:
1) Key Agreement: The SKIPJACK CEK is uniquely wrapped for
recipient using a pairwise symmetric key-encryption key (KEK
generated using KEA using the originator's private KEA key
recipient's public KEA key and other values. Section 4.2
additional details
2) "Previously Distributed" Symmetric KEK: The SKIPJACK CEK
wrapped using a "previously distributed" symmetric KEK (such as
Mail List Key). The methods by which the symmetric KEK
generated and distributed are beyond the scope of this document
Section 4.3 provides more details
[CMS] Section 6 also defines the concept of the key transport
management technique. The key transport technique MUST NOT be
with KEA
Pawling Informational [Page 2]
RFC 2876 KEA and SKIPJACK Algorithms in CMS July 2000
4.1. EnvelopedData
The enveloped-data content type is Abstract Syntax Notation.1 (ASN.1)
encoded using the EnvelopedData syntax. The fields of
EnvelopedData syntax must be populated as follows
The EnvelopedData version MUST be 2.
If key agreement is being used, then the EnvelopedData
field SHOULD be present and SHOULD include the originator's KEA X.509
v3 certificate containing the KEA public key associated with the
private key used to form each pairwise symmetric KEK used to
each copy of the SKIPJACK CEK. The issuers' X.509 v3
required to form the complete certification path for the originator'
KEA X.509 v3 certificate MAY be included in the
originatorInfo field. Self-signed certificates SHOULD NOT be
in the EnvelopedData originatorInfo field
The EnvelopedData RecipientInfo CHOICE is dependent on the
management technique used. Sections 4.2 and 4.3 provide
information
The EnvelopedData encryptedContentInfo
algorithm field MUST be the id-
object identifier (OID). The EnvelopedData
contentEncryptionAlgorithm parameters field MUST include the
8-byte IV used as the input to the content encryption process
The EnvelopedData unprotectedAttrs MAY be present
4.2. Key
This section describes the conventions for using KEA and
with the CMS enveloped-data content type to support key agreement
When key agreement is used, then the
keyAgreeRecipientInfo CHOICE MUST be used
If the EnvelopedData originatorInfo field does not include
originator's KEA X.509 v3 certificate, then each
KeyAgreementRecipientInfo originator field MUST include
issuerAndSerialNumber CHOICE identifying the originator's KEA X.509
v3 certificate. If the EnvelopedData originatorInfo field
the originator's KEA X.509 v3 certificate, then each
KeyAgreementRecipientInfo originator field MUST include either
subjectKeyIdentifier CHOICE containing the value from
subjectKeyIdentifier extension of the originator's KEA X.509 v
certificate or the issuerAndSerialNumber CHOICE identifying
Pawling Informational [Page 3]
RFC 2876 KEA and SKIPJACK Algorithms in CMS July 2000
originator's KEA X.509 v3 certificate. To minimize the size of
EnvelopedData, it is recommended that the subjectKeyIdentifier
be used
In some environments, the KeyAgreementRecipientInfo originator
MAY include the originatorKey CHOICE. The originatorKey
SHOULD NOT be used with KEA for e-mail transactions. Within
controlled security architecture, a module may produce KEA key
for use in conjunction with internal/local storage of encrypted data
In this case, there may not be an X.509 certificate associated with
(possibly) short term or one time use public KEA key.
originatorKey is used, then the KEA public key MUST be conveyed
the publicKey BIT STRING as specified in [KEA] Section 3.1.2.
originatorKey algorithm identifier MUST be the id
keyExchangeAlgorithm OID. The originatorKey algorithm
field MUST contain the KEA "domain identifier" (ASN.1 encoded as
OCTET STRING) identifying the KEA algorithm parameters (i.e., p/q/
values) associated with the KEA public key. [KEA] Section 3.1.1
describes the method for computing the KEA domain identifier value
4.2.1. SKIPJACK CEK Wrap
The SKIPJACK CEK is uniquely wrapped for each recipient of
EnvelopedData using a pairwise KEK generated using the KEA
of the originator and the recipient along with the originator's
Keying Material (UKM) (i.e. Ra). The CMS EnvelopedData
provides two options for wrapping the SKIPJACK CEK for each
using a KEA-generated KEK. The "shared Originator UKM" option
be used when constructing EnvelopedData objects. The "
originator UKM" option MAY be used when constructing
objects. Compliant software MUST be capable of
EnvelopedData objects constructed using both options
1) Shared Originator UKM Option: CMS provides the ability for
single, shared originator's UKM to be used to generate each
KEK used to wrap the SKIPJACK CEK for each recipient. When using
shared originator UKM option, a single
KeyAgreeRecipientInfo structure MUST be constructed to contain
wrapped SKIPJACK CEKs for all of the KEA recipients sharing the
KEA parameters. The KeyAgreeRecipientInfo structure
multiple RecipientEncryptedKey fields that each contain the
CEK wrapped for a specific recipient
Pawling Informational [Page 4]
RFC 2876 KEA and SKIPJACK Algorithms in CMS July 2000
2) Unique Originator UKM Option: CMS also provides the ability for
unique originator UKM to be used to generate each pairwise KEK
to wrap the SKIPJACK CEK for each recipient. When using the
originator UKM option, a separate RecipientInfo
structure MUST be constructed for each recipient.
KeyAgreeRecipientInfo structure includes a
RecipientEncryptedKey field containing the SKIPJACK CEK wrapped
the recipient. This option requires more overhead than the
UKM option because the KeyAgreeRecipientInfo fields (i.e. version
originator, ukm, keyEncryptionAlgorithm) must be repeated for
recipient
The next two paragraphs apply to both options
The KeyAgreeRecipientInfo keyEncryptionAlgorithm algorithm field
include the id-kEAKeyEncryptionAlgorithm OID.
KeyAgreeRecipientInfo keyEncryptionAlgorithm parameters field
contain a KeyWrapAlgorithm as specified in [CMS] Appendix A, "ASN.1
Module". The algorithm field of KeyWrapAlgorithm MUST be the id
fortezzaWrap80 OID indicating that the FORTEZZA 80-bit wrap
is used to wrap the 80-bit SKIPJACK CEK. Since the FORTEZZA 80-
wrap function includes an integrity check value, the wrapped
key is 96 bits long. The parameters field of KeyWrapAlgorithm
be absent
If the originator is not already an explicit recipient, then a
of the SKIPJACK CEK SHOULD be wrapped for the originator and
in the EnvelopedData. This allows the originator to decrypt
contents of the EnvelopedData
4.2.1.1. SKIPJACK CEK Wrap Process Using A Shared Originator UKM
This section describes how a shared originator UKM value is used
an input to KEA to generate each pairwise KEK used to wrap
SKIPJACK CEK for each recipient
When using the shared originator UKM option, a single
KeyAgreeRecipientInfo structure MUST be constructed to contain
wrapped SKIPJACK CEKs for all of the KEA recipients using the
set of KEA parameters. If all recipients' KEA public keys
generated using the same set of KEA parameters, then there MUST
be a single RecipientInfo KeyAgreeRecipientInfo structure for all
the KEA recipients. If the recipients' KEA public keys
generated using different sets of KEA parameters, then
RecipientInfo KeyAgreeRecipientInfo fields MUST be
because the originatorIdentifierOrKey will be different for
distinct set of recipients' KEA parameters
Pawling Informational [Page 5]
RFC 2876 KEA and SKIPJACK Algorithms in CMS July 2000
A unique 128-byte originator's UKM MUST be generated for
distinct set of recipients' KEA parameters. The originator's
MUST be placed in each KeyAgreeRecipientInfo ukm OCTET STRING
The originator's and recipient's KEA parameters MUST be identical
use KEA to successfully generate a pairwise KEK. [KEA] describes
a KEA public key is conveyed in an X.509 v3 certificate. [KEA
states that the KEA parameters are not included in KEA certificates
instead, a "domain identifier" is supplied in
subjectPublicKeyInfo algorithm parameters field of every
certificate. The values of the KEA domain identifiers in
originator's and recipient's KEA X.509 v3 certificates can
compared to determine if the originator's and recipient's
parameters are identical
The following steps MUST be repeated for each recipient
1) KEA MUST be used to generate the pairwise KEK based on
originator's UKM, originator's private KEA key, recipient's 128
byte public KEA key (obtained from the recipient's KEA X.509 v
certificate) and the recipient's 128-byte public KEA key used
the Rb value
2) The SKIPJACK CEK MUST be wrapped using the KEA-generated
KEK as input to the FORTEZZA 80-bit wrap function. The
80-bit wrap function takes the 80-bit SKIPJACK CEK along with
16-bit integrity checkvalue and produces a 96-bit result using
KEA-generated pairwise KEK
3) A new RecipientEncryptedKey SEQUENCE MUST be constructed for
recipient
4) The value of the subjectKeyIdentifier extension from
recipient's KEA X.509 v3 certificate MUST be placed in
recipient's RecipientEncryptedKey rid rKeyId
field. The KeyAgreeRecipientIdentifier CHOICE MUST be rKeyId
The date and other fields MUST be absent from
recipientEncryptedKey rid rKeyId SEQUENCE
5) The wrapped SKIPJACK CEK MUST be placed in the recipient'
RecipientEncryptedKey encryptedKey OCTET STRING
6) The recipient's RecipientEncryptedKey MUST be included in
KeyAgreeRecipientInfo recipientEncryptedKeys SEQUENCE
RecipientEncryptedKey
Pawling Informational [Page 6]
RFC 2876 KEA and SKIPJACK Algorithms in CMS July 2000
4.2.1.2. SKIPJACK CEK Wrap Process Using Unique Originator UKM
This section describes how a unique originator UKM value is
for each recipient to be used as an input to KEA to generate
recipient's pairwise KEK
The following steps MUST be repeated for each recipient
1) A new RecipientInfo KeyAgreeRecipientInfo structure MUST
constructed
2) A unique 128-byte originator's UKM MUST be generated.
originator's UKM MUST be placed in the KeyAgreeRecipientInfo
OCTET STRING
3) KEA MUST be used to generate the pairwise KEK based on
originator's UKM, originator's private KEA key, recipient's 128-
byte public KEA key and recipient's 128-byte public KEA key
as the Rb value
4) The SKIPJACK CEK MUST be wrapped using the KEA-generated
KEK as input to the FORTEZZA 80-bit wrap function. The
80-bit wrap function takes the 80-bit SKIPJACK CEK along with
16-bit integrity check value and produces a 96-bit result
the KEA-generated pairwise KEK
5) A new RecipientEncryptedKey SEQUENCE MUST be constructed
6) The value of the subjectKeyIdentifier extension from
recipient's KEA X.509 v3 certificate MUST be placed in
RecipientEncryptedKey rid rKeyId subjectKeyIdentifier field.
KeyAgreeRecipientIdentifier CHOICE MUST be rKeyId. The date
other fields MUST be absent from the RecipientEncryptedKey
rKeyId SEQUENCE
7) The wrapped SKIPJACK CEK MUST be placed in
RecipientEncryptedKey encryptedKey OCTET STRING
8) The recipient's RecipientEncryptedKey MUST be the
RecipientEncryptedKey present in the
recipientEncryptedKeys SEQUENCE OF RecipientEncryptedKey
9) The RecipientInfo containing the recipient's
MUST be included in the EnvelopedData RecipientInfos SET
RecipientInfo
Pawling Informational [Page 7]
RFC 2876 KEA and SKIPJACK Algorithms in CMS July 2000
4.2.2. SKIPJACK CEK Unwrap
This section describes the recipient processing using KEA to
the SKIPJACK KEK and the subsequent decryption of the SKIPJACK CEK
1) Compliant software MUST be capable of processing
objects constructed using both the shared and the
originator UKM options. To support the shared UKM option,
receiving software MUST be capable of searching for
recipient's RecipientEncryptedKey in a
recipientEncryptedKeys SEQUENCE OF RecipientEncryptedKey.
support the unique UKM option, the receiving software MUST
capable of searching for the recipient's RecipientEncryptedKey
the EnvelopedData recipientInfos SET OF RecipientInfo, with
RecipientInfo containing exactly one RecipientEncryptedKey.
each RecipientEncryptedKey, if the rid rkeyId CHOICE is present
then the receiving software MUST attempt to match the value of
subjectKeyIdentifier extension from the recipient's KEA X.509 v
certificate with the RecipientEncryptedKey rid
subjectKeyIdentifier field. If the rid
CHOICE is present, then the receiving software MUST attempt
match the values of the issuer name and serial number from
recipient's KEA X.509 v3 certificate with
RecipientEncryptedKey rid issuerAndSerialNumber field
2) The receiving software MUST extract the originator's UKM from
ukm OCTET STRING contained in the same KeyAgreeRecipientInfo
includes the recipient's RecipientEncryptedKey
3) The receiving software MUST locate the originator's KEA X.509 v
certificate identified by the originator field contained in
same KeyAgreeRecipientInfo that includes the recipient'
RecipientEncryptedKey
4) KEA MUST be used to generate the pairwise KEK based on
originator's UKM, originator's 128-byte public KEA key (
from originator's KEA X.509 v3 certificate), recipient's
KEA key (associated with recipient's KEA X.509 v3
identified by the RecipientEncryptedKey rid field) and
originator's 128-byte public KEA key used as the Rb value
5) The SKIPJACK CEK MUST be unwrapped using the KEA-
pairwise KEK as input to the FORTEZZA 80-bit unwrap function
Pawling Informational [Page 8]
RFC 2876 KEA and SKIPJACK Algorithms in CMS July 2000
6) The unwrapped 80-bit SKIPJACK CEK resulting from the SKIPJACK
unwrap process and the 8-byte IV obtained from the
encryptedContentInfo contentEncryptionAlgorithm parameters
are used as inputs to the SKIPJACK content decryption process
decrypt the EnvelopedData encryptedContent
4.3. "Previously Distributed" Symmetric
This section describes the conventions for using SKIPJACK with
CMS enveloped-data content type to support "previously distributed
symmetric KEKs. When a "previously distributed" symmetric KEK
used to wrap the SKIPJACK CEK, then the
KEKRecipientInfo CHOICE MUST be used. The methods used to
and distribute the symmetric KEK are beyond the scope of
document
The KEKRecipientInfo fields MUST be populated as specified in [CMS
Section 6.2.3, "KEKRecipientInfo Type". The
keyEncryptionAlgorithm algorithm field MUST be the id-fortezzaWrap80
OID indicating that the FORTEZZA 80-bit wrap function is used to
the 80-bit SKIPJACK CEK. The KEKRecipientInfo
parameters field MUST be absent. The KEKRecipientInfo
field MUST include the SKIPJACK CEK wrapped using the "
distributed" symmetric KEK as input to the FORTEZZA 80-bit
function
5. Encrypted-data
The CMS encrypted-data content type consists of an encrypted content
but no recipient information. The method for conveying the
CEK required to decrypt the encrypted-data encrypted content
beyond the scope of this document. Compliant software MUST meet
requirements for constructing an encrypted-data content type
[CMS] Section 8, "Encrypted-data Content Type". [CMS] Section 8
should be studied before reading this section, because this
does not repeat the [CMS] text
The encrypted-data content type is ASN.1 encoded using
EncryptedData syntax. The fields of the EncryptedData syntax must
populated as follows
The EncryptedData version MUST be set according to [CMS] Section 8.
The EncryptedData encryptedContentInfo
algorithm field MUST be the id-fortezzaConfidentialityAlgorithm OID
The EncryptedData encryptedContentInfo
parameters field MUST include the random 8-byte IV used as the
to the content encryption process
Pawling Informational [Page 9]
RFC 2876 KEA and SKIPJACK Algorithms in CMS July 2000
The EncryptedData unprotectedAttrs MAY be present
6. FORTEZZA 80-bit Wrap
The United States Government has not published the description of
FORTEZZA 80-bit wrap function
7. SMIMECapabilities Attribute
RFC 2633 [MSG], Section 2.5.2 defines the SMIMECapabilities
attribute (defined as a SEQUENCE of SMIMECapability SEQUNCEs) to
used to specify a partial list of algorithms that the
announcing the SMIMECapabilities can support. When constructing
signedData object, compliant software MAY include
SMIMECapabilities signed attribute announcing that it supports
KEA and SKIPJACK algorithms
The SMIMECapability SEQUENCE representing KEA MUST include the id
kEAKeyEncryptionAlgorithm OID in the capabilityID field and
include a KeyWrapAlgorithm SEQUENCE in the parameters field.
algorithm field of KeyWrapAlgorithm MUST be the id-fortezzaWrap80
OID. The parameters field of KeyWrapAlgorithm MUST be absent.
SMIMECapability SEQUENCE for KEA SHOULD be included in the
management algorithms portion of the SMIMECapabilities list.
SMIMECapability SEQUENCE representing KEA MUST be DER-encoded as
following hexadecimal string
3018 0609 6086 4801 6502 0101 1830 0b06 0960 8648 0165 0201 0117
The SMIMECapability SEQUENCE representing SKIPJACK MUST include
id-fortezzaConfidentialityAlgorithm OID in the capabilityID field
the parameters field MUST be absent. The SMIMECapability
for SKIPJACK SHOULD be included in the symmetric
algorithms portion of the SMIMECapabilities list.
SMIMECapability SEQUENCE representing SKIPJACK MUST be DER-encoded
the following hexadecimal string
300b 0609 6086 4801 6502 0101 0400
8. Object Identifier
The following OIDs are specified in [INFO], but are repeated here
the reader's convenience
id-keyExchangeAlgorithm OBJECT IDENTIFIER ::= {joint-iso-ccitt(2)
country(16) us(840) organization(1) gov(101) dod(2) infosec(1)
algorithms(1) keyExchangeAlgorithm (22)}
Pawling Informational [Page 10]
RFC 2876 KEA and SKIPJACK Algorithms in CMS July 2000
id-fortezzaWrap80 OBJECT IDENTIFIER ::= {joint-iso-ccitt(2)
country(16) us(840) organization(1) gov(101) dod(2) infosec(1)
algorithms(1) fortezzaWrap80Algorithm (23)}
id-kEAKeyEncryptionAlgorithm OBJECT IDENTIFIER ::= {joint-iso
ccitt(2) country(16) us(840) organization(1) gov(101) dod(2)
infosec(1) algorithms(1) kEAKeyEncryptionAlgorithm (24)}
id-fortezzaConfidentialityAlgorithm OBJECT IDENTIFIER ::= {joint
iso-ccitt(2) country(16) us(840) organization(1) gov(101) dod(2)
infosec(1) algorithms(1) fortezzaConfidentialityAlgorithm (4)}
As specified in [USSUP1], when the id
fortezzaConfidentialityAlgorithm OID is present in
AlgorithmIdentifier algorithm field, then the
parameters field MUST be present and MUST include the SKIPJACK
ASN.1 encoded using the following syntax
Skipjack-Parm ::= SEQUENCE { initialization-vector OCTET STRING }
Note: [CMS] Section 2, "General Overview" describes the ASN.1
encoding conventions for the CMS content types including
enveloped-data and encrypted-data content types in which the id
fortezzaConfidentialityAlgorithm OID and parameters will be present
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630,
June 1999.
[KEA] Housley, R. and W. Polk, "Representation of Key
Algorithm (KEA) Keys in Internet X.509 Public
Infrastructure Certificates", RFC 2528, March 1999.
[INFO] Registry of INFOSEC Technical Objects, 22 July 1999.
[MSG] Ramsdell, B., "S/MIME Version 3 Message Specification",
RFC 2633, June 1999.
[MUSTSHOULD] Bradner, S., "Key words for use in RFCs to
Requirement Levels", BCP 14, RFC 2119, March 1997.
[SJ-KEA] SKIPJACK and KEA Algorithm Specifications, Version 2.0,
http://csrc.nist.gov/encryption/skipjack-kea.htm
Pawling Informational [Page 11]
RFC 2876 KEA and SKIPJACK Algorithms in CMS July 2000
[USSUP1] Allied Communication Publication 120 (ACP120)
Security Protocol (CSP) United States (US)
No. 1, June 1998;
http://www.armadillo.huntsville.al.us/Fortezza_docs/missi2.html#specs
The following people have made significant contributions to
memo: David Dalkowski, Phillip Griffin, Russ Housley,
Leonberger, Rich Nicholas, Bob Relyea and Jim Schaad
Author's
John
Wang Government Services, Inc. (WGSI),
A Getronics
141 National Business Pkwy, Suite 210
Annapolis Junction, MD 20701
Phone: (301) 939-2739
(410) 880-6095
EMail: john.pawling@wang.
Pawling Informational [Page 12]
RFC 2876 KEA and SKIPJACK Algorithms in CMS July 2000
Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Pawling Informational [Page 13]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
