|
|
 |
|
|
|
register |
bbs |
search |
rss |
faq |
about
|
|
|
meet up |
add to del.icio.us |
digg it
|
|
|
|
FORTEZZA File Protection (National Security Agency
NOTICE: TO ALL CONCERNED Certain text files and messages contained on this site deal with activities and devices which would be in violation of various Federal, State, and local laws if actually carried out or constructed. The webmasters of this site do not advocate the breaking of any law. Our text files and message bases are for informational purposes only. We recommend that you contact your local law enforcement officials before undertaking any project based upon any information obtained from this or any other web site. We do not guarantee that any of the information contained on this system is correct, workable, or factual. We are not responsible for, nor do we assume any liability for, damages resulting from the use of any information on this site.
FORTEZZA
Certification Requirements for
File Protection Applications
Version 1.04
31 January 1996
Prepared By:
Workstation Security Products Division
National Security Agency
(410) 859-4463
1. PURPOSE
This document defines the FORTEZZA certification requirements
for file protection applications which have been modified to utilize
the cryptographic features of the "FORTEZZA Crypto Card". This
document has been written for file protection application
developers and is to be used in conjunction with the specified
references during product design and development. The more
detailed testing requirements, which are based upon the
requirements detailed in this document, are defined in the
"FORTEZZA File Protection Application Test Plan". Government
testing for FORTEZZA compliance and certification will be based
solely upon the mandatory requirements defined in this
specification. This specification does not attempt to fully address
Multilevel Information System Security Initiative (MISSI) system
requirements.
An application designed to secure, or protect, file data can do so
one of three ways:
-- Digitally signing the file data
-- Encrypting the file data
-- Implementation of both methods - digital signatures and
encryption
This document details the mandatory requirements that applications
must satisfy to satisfactorily secure file data (using any one of the
three methods mentioned above). Further, these mandatory
requirements must be met to pass certification testing by the
Government and be permitted to use the National Security Agency's
registered FORTEZZA Certification Mark (i.e. the vendor can
advertise the Government tested and certified product as
"FORTEZZA Compliant"). If the vendor/developer has a
circumstance which may warrant Government consideration of a
mandatory requirement waiver, the vendor/developer may make a
written request to the NSA. The Government will notify all
developers who are actively making FORTEZZA file protection
applications of any changes to these mandatory requirements.
Vendors/developers must ensure that the next release/version of
their product(s) satisfy the updated mandatory requirements or risk
losing their FORTEZZA Certification (and all rights to use the
FORTEZZA Certification Mark).
This document further details a list of recommended requirements
for FORTEZZA File Protection applications. These recommended
requirements represent features that the Government would like to
have in a FORTEZZA File Protection application. Developers
should consider these issues when designing and developing
applications of this nature. This list does not necessarily represent
all of the extra features that users may desire.
2. BACKGROUND
2.1. FORTEZZA Program Background
A general overview of the FORTEZZA Program can be found in the
"FORTEZZA Program Overview" and the "Application Implementor's Guide for
the PCMCIA- based FORTEZZA Cryptologic Card".
2.2. FORTEZZA File Protection Application Background
The need for file protection applications has existed since the need
for maintaining the privacy of data was realized. The FORTEZZA card
(and its associated cryptographic features) lends itself directly to
this type of application.
These cryptographic features include encryption/decryption and
digital signature capabilities, as well as the associated key and certificate
management infrastructure of the MISSI program. Development of "FORTEZZA-enabled" file
protection applications has been a priority within the FORTEZZA program
since its inception in 1990 (then known as the MOSAIC program). Since then, the
FORTEZZA PMO has developed and cultivated strong ties with the commercial
application developers and, currently, has several on-going efforts to develop
commercially available, FORTEZZA-enabled file protection applications.
3. REFERENCES
Application Implementor's Guide for the PCMCIA based
FORTEZZA Cryptologic Card,
Version 1.0.1, April 6, 1995, Unclassified.
FORTEZZA Certificate Cache Schema, Draft, October 1995,
Unclassified.
FORTEZZA Cryptologic Interface Programmer's Guide, Revision
1.52, November 30, 1995, Unclassified.
FORTEZZA Program Overview, Version 4.0, October 1995,
Unclassified.
Interface Control Document for the FORTEZZA Crypto-Card,
Revision P1.5, January
1995, Unclassified.
MISSI Key, Privilege, and Certificate Management Plan, Version
3.0, June 6, 1995, For
Official Use Only.
MOSAIC Certificate Labeling Specification, Version P1.1,
October 10, 1994,
Unclassified.
4. REQUIREMENTS
The requirements are divided into three categories. These categories
consist of those requirements that are mandatory (i.e. requirements
that must be satisfied to achieve FORTEZZA certification), those
that are recommended (i.e. desirable features) and those that will
need to be addressed in the near future.
Each of these three requirement categories are then further
subdivided into two subsections. One of which details the specific
encryption and decryption requirements and the other subsection
details the general operational requirements pertaining to the usage
of the FORTEZZA card.
Finally, the recommended requirements category has two additional
subsections. These subsections consist of general recommendations
that aren't accounted for in the other subsections but should still be
addressed by the developer. These items are, however, not
mandatory and have therefore been placed in the Recommended
Requirements category.
*** Note that Digital Signature requirements are addressed in
Section 5.
4.1. Mandatory
A. Encryption and Decryption
The application shall:
1. Interface to and function with any Government certified
FORTEZZA
Cryptographic Card for encryption and decryption.
2. Not corrupt the integrity of a file's data content.
3. Ensure that the resultant decrypted file retains the original file's
attributes (e.g.
if the original file was read-only, then when that file is decrypted,
after being
encrypted, it shall retain the read-only attribute).
4. Be able to encrypt/decrypt files of all types.
5. Inform the user if the encryption/decryption process succeeded
or failed.
(1) If the encryption/decryption failed, the user shall be notified of
the failure.
6. Clean up all temporary files that it has created and any memory
that it has
allocated.
7. Verify that any certificate which is used is valid based upon the
following
criteria:
(1) The signature on the certificate is valid (based on the public key
from the
issuer's certificate).
(a) If, during encryption, the signature on the user's certificate (or
any
certificate in the Card user's heirarchy is invalid), the user shall be
notified and directed to return the Card to the Certification
Authority
and all processing shall stop.
(b) If the signature on any other certificate is invalid, the user shall
be
notified which certificate is invalid and all processing shall stop.
© If, during decryption, the signature on the user's certificate or
any
certificate in the user's certification path is invalid, for any reason,
the
user shall be notified which certificate(s) signature is invalid and
allow
theuser to proceed with the processing with positive
acknowledgement
from the user (if site security policy permits).
(2) The current date retrieved from the FORTEZZA card (or the
system) falls
within the certificate validity interval.
(a) If the current date is outside of the validity interval, the user
shall be
notified which certificate(s) is outside of the validity interval and
when
the certificate will be/was valid, warned that the certificate may or
may
not have been revoked and allow the user to proceed with the
processing with positive acknowledgement from the user (if site
security
policy permits).
(3) The certificate serial number does not appear on a certificate
issuer's
current and valid Certificate Revocation List (CRL). A CRL is
current if
the current FORTEZZA card date falls within the Last Update date
and the
Next Update date in the CRL.
(a) If a user certificate appears on a CRL, the user shall be notified
which
certificate(s) is on the CRL and given the option to proceed with
the
processing with positive acknowledgement from the user (if site
security
policy permits).
(b) If a Policy Creation Authority (PCA) or Certification Authority
certificate appears on a CRL, then the user shall be notified which
certificate(s) is on the CRL and processing shall stop.
© If a current CRL is unavailable, the user shall be notified when
the
available CRL was valid, recommended to obtain a new CRL from
their
Directory System Agent (DSA) and given the option to proceed
with
processing with the out of date CRL (provided the CRL signature
is still
valid).
(d) If the CRL signature is invalid, all processing shall stop and the
user
shall be notified and instructed to obtain a new CRL from their
DSA.
(i) If a PCA CRL is invalid then all processing shall stop.
(ii) If a valid CA CRL cannot be obtained, then the user shall be
given
the option to proceed without a valid CRL and without using the
invalid CRL.
(4) The Key Material Identifier (KMID) does not appear on the
current and
valid Compromised Key List (CKL). A CKL is current if the
current
FORTEZZA card date falls within the Last Update date and the
Next Update date in the CKL.
(a) If the KMID appears on the CKL, all processing shall stop and
the
user shall be notified which certificate(s) appear on the CKL.
(i) If the compromised KMID is for a certificate on the user's card,
the
user shall be directed to notify their Certification Authority.
(b) If the current CKL is unavailable, the user shall be notified
when the
CKL was last valid, instructed to obtain a CKL from their DSA and
all
processing shall stop.
© If the CKL signature is invalid, all processing shall stop, the
user shall
be notified and instructed to obtain a new CKL from their DSA.
(5) The certificate issuer is a valid certificate authority.
(a) If the issuer is not a valid certificate authority, the user shall be
notified which certificate is not a valid certificate authority and all
processing shall stop.
(6) The subject name in the issuer's certificate matches the issuer's
name in the
user's certificate.
(a) If the names do not match, the user shall be notified which
certificate
does not match and all processing shall stop.
(7) The user's name is subordinate to the issuer's name in the
certificate
hierarchy, as specified in Appendix B of SDN.701,
"DMS/MSP/Mosaic
Requirements," except that name subordination is not required
from the
Policy Approval Authority tothe subordinate Policy Creation
Authority and
from the PCA to the subordinate CA.
(a) If the name subordination check fails, the user shall be notified
which
certificate is not subordinate and all processing shall stop.
(8) The clearance permission bits of the subject certificate are a
subset of the
clearance permission bits of the issuer certificate except that
clearance
subordination is not required from the Policy Approval Authority
to the
subordinate Policy Creation Authority.
(a) If the clearance level check fails, the user shall be notified
which
certificate has invalid clearance permissions and all processing
shall
stop.
8. Upon successful decryption, the application shall:
a. Display the encryptor's authenticated Distinguished Name (DN).
b. Provide the recipient with the option to display the entire
certificate
heirarchy.
c. Display the security classification (per Requirement 4.1, A, 14).
9. Upon the successful verification of a file that was encrypted by
an
organizational personality, notify the user that the encryption was
performed by
an organizational personality.
10. Ensure that if the Ks on the FORTEZZA card is used for
encryption and
decryption purposes then it shall be limited to covering the
Message Encryption
Key (MEK) which was used to encrypt the message (i.e. the
application shall
not use the Ks to encrypt messages; the application shall generate
an MEK
which will be used to encrypt and decrypt the message and then use
the Ks to
cover the MEK).
11. Give the user the option to overwrite and delete the plaintext
file(s) during the
encryption process (i.e. when a file is to be encrypted, the user
shall be given
the option to overwrite and delete the plaintext file).
(1) If the plaintext file is to be deleted during the encryption
process,
the application shall notify the user that the plaintext file will be
deleted,
prior to the actual operation (per Requirement 4.2,C, 5. (3)), and
then
continue with the operation only after positive user
acknowledgement.
(2) If the plaintext file is to be deleted during the encryption
process, the
application shall, at a minimum, set the file length to zero in the
File
Allocation Table (FAT) and then delete the file.
(3) If the plaintext file is to be deleted during the encryption
process, the
application shall also give the user the option to overwrite the
plaintext file
prior to deleting the file. The valid overwrite options shall consist
of no
overwrite, a single overwrite or a triple overwrite.
(a) If no overwrite is selected, then the file length shall be set to
zero in the
FAT and the file shall then be deleted.
(b) If a single overwrite is selected, the file shall be overwritten
with
psuedo-random bits, the file length shall then be set to zero and the
file
shall then be deleted.
© If a triple overwrite is selected, the file shall be first overwritten
with
0xAA ('AA' Hex), then overwritten with 0x55, and finally
overwritten
with pseudo-random bits. The file length shall then be set to zero
and
the file shall then be deleted.
(4) If the user is permitted the option to overwrite and delete the
plaintext file,
but elects not to delete or overwrite the plaintext file, the plaintext
file shall
then not be modified in any way.
12. Inform the user of any file or system attributes or of any other
operation which
affects the overwrite of any file (described in Requirement
4.1,A,11) or
prevents successful file deletion. If possible, the application shall
continue with
the operation after user acknowledgment.
13. Allow the originator to select the type of protection to be
applied to the
message: signed-only, encrypted-only1, or signed and encrypted.
(1) Default to signed and encrypted protection.
14. Allow the originator to select the classification of the protected
file.2
(1) Check the security classification to verify that the originator has
that
clearance authorized in their certificate before encrypting and the
recipients
have that clearance authorized in their certificate prior to
decrypting the
data.
(a) If the clearance is not authorized for a certificate, the user shall
be
notified that the clearance is unauthorized and all processing shall
stop.
15. Establish, manage, and maintain a local cache database for
directory
information such as Distinguished Names (DNs), X.509
certificates, CKLs, and
CRLs. Local can be local network accessible.
(1) Upon receipt of a protected file from an originator whose
certificate is not
in the local cache, either prompt the user with the option to store
the
originator's certificate in the cache or notify the user that it was
done
automatically.
16. Include the entire user to PCA certificate path in the header by
default.
B. FORTEZZA Operational Requirements
The application shall:
1. Prompt the user for the PIN phrase upon application start-up and
at any time
the FORTEZZA card has been reset (e.g. if the FORTEZZA card
has been
removed and re-inserted).
(1) Notify the user of the success or failure of the PIN
authentication.
2. Make every effort to protect Personal Identification Numbers
(PINs) such that
the user (or any other entity) shall not be able to view them or have
any other
type of access to these sensitive items.
3. Ensure that PIN phrases are:
a. not permanently stored in non-volatile memory where
unauthorized
disclosure of the PIN phrase or access to the FORTEZZA card may
occur.
b. wiped from the memory space where they are temporarily stored
as soon as
they are no longer needed.
c. not stored in such a way that the application (or any other
applicationor
process) can gain access to the FORTEZZA card without the user
inputting
the PIN phrase.
4. Not provide the PIN phrase to another application or the user.
5. Allow the user to select any one of the appropriate personalities
retrieved from
the FORTEZZA card or default to a pre-selected personality. An
appropriate
personality is one which has a private 'x' value associated with it.
(1) Provide the user with a list of appropriate personalities from the
FORTEZZA card and allow the user to select their personality from
this
list.
(a) When the list of personalities is displayed to the user, the
application
shall interpret the four byte Usage/Equipment (U/E) Specifier as
follows: "INKS" is Individual, "INKX" is Indiv Read Only,
"ONKS" is
Organizational, and "ORKX" is Org Read-Only.
(b) If an unknown or unrecognizable U/E Specifier is encountered,
the application shall ignore it and it shall not be displayed to the
user.
© When displaying the list of personalities, the application shall,
at a
minimum, display the Certificate Label and the expanded U/E
Specifier
for each personality.
6. Allow the user to change FORTEZZA card personalities during
a session.
7. Only write information in available empty certificate spaces on
the FORTEZZA
card with explicit user permission.
8. Inform the user of the status of any security-related operation.
(1) Inform the user if a security-related operation succeeded (i.e.
completed
securely and correctly) or failed.
(2) If the security-related operation failed, the user shall be
informed of which
operation failed and the cause of the failure.
9. Inform the user of any state change in the FORTEZZA card as
defined in the
FORTEZZA Card ICD.
10. Handle and process all CI-Library defined error codes as non-
fatal errors so
that all expected (typical and atypical) FORTEZZA card and
system situations
can be properly handled.
11. Include a FORTEZZA Compliant Device Driver and implement
a FORTEZZA
Compliant Cryptologic Interface (CI) Library.
4.2. Recommended
A. Encryption and Decryption
The application should:
1. Have the ability to encrypt multiple files within a single directory
or an entire
directory (including all of the files and subdirectories subordinate
to that
directory) into either a single cipher text file or into separate files
(depending
upon the user's discretion).
2. If multiple files were encrypted into a single cipher text file (per
Requirement
4.2,B,1.), then have the ability to decrypt that single cipher text file
into the
original components maintaining the original file structure.
3. Allow the user the capability to selectively decrypt files (or
directories) which
were encrypted as part of a mass encrypt without having to decrypt
every file
or directory that was encrypted during the mass encrypt (e.g. if the
user
encrypts a directory containing multiple files, the application
should allow the
user to decrypt a single file which was encrypted when the
directory was
encrypted, without having to decrypt the entire directory).
4. Allow use of all encryption modes available on the FORTEZZA
card. These
will include:
a. 64-bit Electronic Code Book
b. 64-bit Cipher Block Chaining
c. 64-bit Output Feed Back
d. 32-bit Cipher Feed Back
e. 16-bit Cipher Feed Back
f. 8-bit Cipher Feed Back
5. Provide a means to support the archival of encrypted files with
archive keys or
with a local storage key.3
B. FORTEZZA Operational Requirements
The application should:
1. Allow the user to logout and re-login to the FORTEZZA card
without having to
restart the application.
2. Implement the local certificate cache database using the
"FORTEZZA
Certificate Cache Schema" so that a single user's local cache can be
used by
multiple FORTEZZA applications.
3. Allow the user to optionally purge any certificates found on the
CRL or CKL
from the local certificate cache.
4. Create and maintain an error log of all security related error
conditions.
5. Provide the means for the user to view information in the:
a. X.509 Certificate Structure such as Validity Period, Clearances,
and
Privileges (certificates on the card or in the local cache).
b. CKL, such as the Last Update Date and the Next Update Date.
c. CRL, such as the Last Update Date and the Next Update Date.
6. Indicate to the user when CKLs and CRLs near expiration. This
time period
will be defined by the user.
7. Provide the user with the option to only include the user
certificate in the
header to reduce overhead.
8. Provide the user with the option to set default security options
and
classification levels.
9. Provide the user with a message classification menu.
10. Provide the user with a message compartmentation menu and
allow the user
to modify and add to it.
11. Provide the option for the user of having a list of recipient DNs
displayed
before encrypting a file so that the user can verify or acknowledge
that the
correct recipient certificates are being used.
12. Use certificates retrieved from the following, in the given order
(as available),
when verifying certificates for an encrypted message.
a. encrypted file's header
b. local certificate cache
If a certificate is found to be invalid during processing, the
application should search alternate locations for a valid version of the
certificate.
C. General File Protection Application Recommendations
1. Compression and Decompression Options
The application should:
(1) Offer the capability to compress a file(s) prior to encrypting
and/or digitally
signing the file(s).
(2) Offer the capability to decompress a file(s) if it has been
compressed by the
file protection application (i.e. restore the file to its original state
prior to
the file encryptor application performing any functions on the
file(s)).
(3) Both compression and decompression should only be
implemented when
the user acknowledges such an action.
2. File Location
The application should allow:
(1) Operations to be performed on any file(s) that is accessible by
the File
Management System (i.e. the file can be in any location (i.e.
directory) that
is accessible by the File Management System vs. the file must be in
a
specific location, or directory, for the application to perform
operations on
it).
(2) The user to use "wildcard" characters (e.g. '*') when selecting
files. The
use of wildcards will help the user search for a file(s) or will select
a group
of files (with similar file names) which are to be operated upon at a
single
time.
3. Storage Media
The application should:
(1) Have the ability to utilize all types of storage media, including,
but not
limited to, fixed and removable disk drives, Compact Disc drives,
and tape
drives.
(2) Be able to operate on a file on one type of device and write it to
another
device (e.g. a file on a hard disk drive is encrypted and signed and
then
written to a 3.5" floppy diskette). Application must ensure that if
multiple
devices are to be used, then the application must still adhere to
Requirement 4.1. A,7 and give the option to the user (if site
security policy
permits) to delete the plaintext predecessor from its original
location.
4. Common File Naming Convention
The application should:
(1) Default to using a common file naming convention whenever
possible (i.e.
a file extension that is commonly used for all files processed in a
certain
way by the application). For example, all files that are only
encrypted by a
certain application will use a file name with a common extension
(e.g.
<filename>.enc), all files that are only digitally signed will have a
file name
with a common extension (e.g. <filename>.sig), and all files that
are both
encrypted and signed will have a file name with a common
extension
(e.g.<filename>.exs). The common naming convention should only
be a
default and the application should not restrict the user from using
other
extensions (per Requirement 4.2, C, 4(2)).
(2) Allow the user to name files, which are the result of security
related operations performed by the application, arbitrarily (i.e. the
application should not restrict the user's ability to name these resultant files).
This will give the user the ability to mask the secured state of these resultant
files.
However, the application should define a default naming
convention (per Requirement 4.2, C, 4(1)).
5. Security Features
The application should:
(1) If security features are user selectable, the application should
default to that combination of features, or options, which provide maximum data
protection. For example, if the application offers both encryption
and digital signature features, then the application will default to
provide both encryption and a digital signature over the data. The application
should allow the user the capability to change this default (if site security
policy permits) to enhance its user interface.
(2) Only permit appropriate operations (e.g. application should not
allow the user to decrypt a plaintext file). This requirement implies that the
application should have the ability to analyze the relevant data and
determine whether it appears to be encrypted or not prior to
performing any security-related operation upon it.
(3) Provide a clear indication to the user of what security features
have been selected before any security-related processing occurs.
D. General Recommendations
1. A "User's Guide" which documents the application installation
and operation of the product should be included with the application.
2. Application documentation should include information on the
purpose of using file encryption and digital signatures. Appropriate examples should
be included which clarify the usage of encryption and digital signatures.
3. A security disclaimer statement that indicates the application
vendor is not responsible for the cryptographic processes on the FORTEZZA
card and for data compromise when application software is executed on non-
trusted computers with non-trusted operating systems should be included
in the documentation.
4.3. Future Considerations
A. Encryption and Decryption
1. Application should implement the common encoding format when it is available
from the Workstation Security Applications Division (NSA). This will help to
ensure interoperability among the many different File Protection Applications
which will implement the FORTEZZA card.
B. FORTEZZA Operational Requirements
The application should:
1. Be capable of context switching (enabling one application to
gain and
relinquish control of the Card in an environment where the Card is
shared by
multiple applications) by always relinquishing control of the Card
when it is no
longer needed.
(1) Implement the "Lock/Unlock" protocol when it is available from
the Workstation Security Applications Division (NSA).
(2) Release control of the FORTEZZA card when no FORTEZZA-related
operations are being performed after cleaning up all temporary card
memory, to include all key registers.
2. Record to-be-specified events in a to-be-specified format in an audit file.
3. Be capable of processing Attribute Certificates.
4. Verify certification paths that contain Policy Approval Authority Cross
Certificates.
5. Use Version 3 certificates.
5. Digital Signature Generation and Verification Requirements
The use of digital signatures in File Protection Applications is not mandatory.
However, if the application implements digital signatures in any
way, the following requirements will apply.
The digital signature requirements listed below are divided into two categories,
mandatory and recommended. Those that are mandatory must be satisfied to
achieve FORTEZZA certification. Those that are recommended, as stated in the
previous section, are those items that the Government would like to
have in File Protection Applications which implement digital signatures.
5.1 Mandatory Requirements for Digital Signatures
The application shall:
1. Use the FIPS 180-1 compliant hash algorithm (i.e. the Secure
Hash Algorithm (SHA-1)).
2. Use the FORTEZZA card to generate digital signatures (i.e. this
requirement implies
the use of the Digital Signature Algorithm (DSA)).
3. Use the Digital Signature Algorithm, defined in the FIPS 186
Digital Signature Standard (DSS) as implemented on the FORTEZZA card, to
validate digital signatures. This requirement implies that it is acceptable to validate
a digital signature using a software verification routine, as long as it
complies with this requirement.
4. Inform the user of the signature generation and verification
results.
(1) If the signature generation or verification failed for any reason,
the user shall be informed that the generation/verification failed and the
cause of the failure.
5. Verify that any certificate used is valid based upon the criteria
defined in Requirement 4.1, A,7.
(1) Upon successful signature validation, the application shall:
a. Display the signer's authenticated Distinguished Name (DN).
b. Provide the recipient with the option to display the entire
certificate
heirarchy.
c. Display the security classification (per Requirement 4.1, A,12.).
(2) Upon the successful verification of a file that was signed by an
organizational
personality, the application shall identify to the user that the digital
signature was performed by an organizational personality.
5.2. Recommended Requirements for Digital Signatures
The application should:
1. Allow the user to view the cleartext of a signed-only file (or
data) for which the
signature verification failed after warning the user of that failure
(see Requirements
5.1.4. and 5.1.4.1.) and receiving acknowledgment from the user.
2. Allow the user to view the cleartext of a signed-only file (or
data) when the FORTEZZA card is not logged in after warning the user that
the displayed information is unverified.
3. Allow the user to save a signed-only file without the signature
information after the signature has been verified.
|
|
|
To the best of our knowledge, the text on this page may be freely reproduced and distributed.
If you have any questions about this, please check out our Copyright Policy.
totse.com certificate signatures
|
|
|
About | Advertise | Bad Ideas | Community | Contact Us | Copyright Policy | Drugs | Ego | Erotica
FAQ | Fringe | Link to totse.com | Search | Society | Submissions | Technology
|
|
|
|
|
|
