hjp: doc: RFC 9216: S/MIME Example Keys and Certificates

Rfc	9216
Title	S/MIME Example Keys and Certificates
Author	D. K
Date	April 2022
Format:	HTML, TXT, PDF, XML
Status:	INFORMATIONAL

Internet Engineering Task Force (IETF)                D. K. Gillmor, Ed.
Request for Comments: 9216                                          ACLU
Category: Informational                                       April 2022
ISSN: 2070-1721

                  S/MIME Example Keys and Certificates

Abstract

   The S/MIME development community benefits from sharing samples of
   signed or encrypted data.  This document facilitates such
   collaboration by defining a small set of X.509v3 certificates and
   keys for use when generating such samples.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are candidates for any level of Internet
   Standard; see Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc9216.

Copyright Notice

   Copyright (c) 2022 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Revised BSD License text as described in Section 4.e of the
   Trust Legal Provisions and are provided without warranty as described
   in the Revised BSD License.

Table of Contents

   1.  Introduction
     1.1.  Terminology
     1.2.  Prior Work
   2.  Background
     2.1.  Certificate Usage
     2.2.  Certificate Expiration
     2.3.  Certificate Revocation
     2.4.  Using the CA in Test Suites
     2.5.  Certificate Chains
     2.6.  Passwords
     2.7.  Secret Key Origins
   3.  Example RSA Certification Authority
     3.1.  RSA Certification Authority Root Certificate
     3.2.  RSA Certification Authority Secret Key
     3.3.  RSA Certification Authority Cross-Signed Certificate
   4.  Alice's Sample Certificates
     4.1.  Alice's Signature Verification End-Entity Certificate
     4.2.  Alice's Signing Private Key Material
     4.3.  Alice's Encryption End-Entity Certificate
     4.4.  Alice's Decryption Private Key Material
     4.5.  PKCS #12 Object for Alice
   5.  Bob's Sample
     5.1.  Bob's Signature Verification End-Entity Certificate
     5.2.  Bob's Signing Private Key Material
     5.3.  Bob's Encryption End-Entity Certificate
     5.4.  Bob's Decryption Private Key Material
     5.5.  PKCS #12 Object for Bob
   6.  Example Ed25519 Certification Authority
     6.1.  Ed25519 Certification Authority Root Certificate
     6.2.  Ed25519 Certification Authority Secret Key
     6.3.  Ed25519 Certification Authority Cross-Signed Certificate
   7.  Carlos's Sample Certificates
     7.1.  Carlos's Signature Verification End-Entity Certificate
     7.2.  Carlos's Signing Private Key Material
     7.3.  Carlos's Encryption End-Entity Certificate
     7.4.  Carlos's Decryption Private Key Material
     7.5.  PKCS #12 Object for Carlos
   8.  Dana's Sample Certificates
     8.1.  Dana's Signature Verification End-Entity Certificate
     8.2.  Dana's Signing Private Key Material
     8.3.  Dana's Encryption End-Entity Certificate
     8.4.  Dana's Decryption Private Key Material
     8.5.  PKCS #12 Object for Dana
   9.  Security Considerations
   10. IANA Considerations
   11. References
     11.1.  Normative References
     11.2.  Informative References
   Acknowledgements
   Author's Address

1.  Introduction

   The S/MIME ([RFC8551]) development community, in particular the email
   development community, benefits from sharing samples of signed and/or
   encrypted data.  Often, the exact key material used does not matter
   because the properties being tested pertain to implementation
   correctness, completeness, or interoperability of the overall system.
   However, without access to the relevant secret key material, a sample
   is useless.

   This document defines a small set of X.509v3 certificates ([RFC5280])
   and secret keys for use when generating or operating on such samples.

   An example RSA Certification Authority is supplied, and sample RSA
   certificates are provided for two "personas", Alice and Bob.

   Additionally, an Ed25519 ([RFC8032]) Certification Authority is
   supplied, along with sample Ed25519 certificates for two more
   "personas", Carlos and Dana.

   This document focuses narrowly on functional, well-formed identity
   and key material.  It is a starting point that other documents can
   use to develop sample signed or encrypted messages, test vectors, or
   other artifacts for improved interoperability.

1.1.  Terminology

   "Certification Authority" (or "CA"):  a party capable of issuing
      X.509 certificates

   "End Entity" (or "EE"):  a party that is capable of using X.509
      certificates (and their corresponding secret key material)

   "Mail User Agent" (or "MUA"):  a program that generates or handles
      email messages ([RFC5322])

1.2.  Prior Work

   [RFC4134] contains some sample certificates as well as messages of
   various S/MIME formats.  That older work has unacceptably old
   algorithm choices that may introduce failures when testing modern
   systems: in 2019, some tools explicitly marked 1024-bit RSA and
   1024-bit DSS as weak.

   This earlier document also does not use the now widely accepted
   Privacy-Enhanced Mail (PEM) encoding (see [RFC7468]) for the objects
   and instead embeds runnable Perl code to extract them from the
   document.

   It also includes examples of messages and other structures that are
   greater in ambition than this document intends to be.

   [RFC8410] includes an example X25519 certificate that is certified
   with Ed25519, but it appears to be self issued, and it is not
   directly useful in testing an S/MIME-capable MUA.

2.  Background

2.1.  Certificate Usage

   These X.509 certificates ([RFC5280]) are designed for use with S/MIME
   protections ([RFC8551]) for email ([RFC5322]).

   In particular, they should be usable with signed and encrypted
   messages as part of test suites and interoperability frameworks.

   All end-entity and intermediate CA certificates are marked with
   Certificate Policies from [TEST-POLICY] indicating that they are
   intended only for use in testing environments.  End-entity
   certificates are marked with policy 2.16.840.1.101.3.2.1.48.1 and
   intermediate CAs are marked with policy 2.16.840.1.101.3.2.1.48.2.

2.2.  Certificate Expiration

   The certificates included in this document expire in 2052.  This
   should be sufficiently far in the future that they will be useful for
   a few decades.  However, when testing tools in the far future (or
   when playing with clock-skew scenarios), care should be taken to
   consider the certificate validity window.

   Due to this lengthy expiration window, these certificates will not be
   particularly useful to test or evaluate the interaction between
   certificate expiration and protected messages.

2.3.  Certificate Revocation

   Because these are expected to be used in test suites or examples, and
   we do not expect there to be online network services in these use
   cases, we do not expect these certificates to produce any revocation
   artifacts.

   As a result, none of the certificates include either an Online
   Certificate Status Protocol (OCSP) indicator (see id-ad-ocsp as
   defined in the Authority Information Access X.509 extension in
   Section 4.2.2.1 of [RFC5280]) or a Certificate Revocation List (CRL)
   indicator (see the CRL Distribution Points X.509 extension as defined
   in Section 4.2.1.13 of [RFC5280]).

2.4.  Using the CA in Test Suites

   To use these end-entity certificates in a piece of software (for
   example, in a test suite or an interoperability matrix), most tools
   will need to accept either the example RSA CA (Section 3) or the
   example Ed25519 CA (Section 6) as a legitimate root authority.

   Note that some tooling behaves differently for certificates validated
   by "locally installed root CAs" than for pre-installed "system-level"
   root CAs).  For example, many common implementations of HTTP Public
   Key Pinning (HPKP) ([RFC7469]) only applied the designed protections
   when dealing with a certificate issued by a pre-installed "system-
   level" root CA and were disabled when dealing with a certificate
   issued by a "locally installed root CA".

   To test some tooling specifically, it may be necessary to install the
   root CA as a "system-level" root CA.

2.5.  Certificate Chains

   In most real-world examples, X.509 certificates are deployed with a
   chain of more than one X.509 certificate.  In particular, there is
   typically a long-lived root CA that users' software knows about upon
   installation, and the end-entity certificate is issued by an
   intermediate CA, which is in turn issued by the root CA.

   The example end-entity certificates in this document can be used
   either with a simple two-link certificate chain (they are directly
   certified by their corresponding root CA) or in a three-link chain.

   For example, Alice's encryption certificate (alice.encrypt.crt; see
   Section 4.3) can be validated by a peer that directly trusts the
   example RSA CA's root cert (ca.rsa.crt; see Section 3.1):

   +==============+   +-------------------+
   || ca.rsa.crt ||-->| alice.encrypt.crt |
   +==============+   +-------------------+

     Figure 1: Validating Alice's encryption certificate directly when
                      the issuing CA is a trust anchor

   And it can also be validated by a peer that only directly trusts the
   example Ed25519 CA's root cert (ca.25519.crt; see Section 6.1) via an
   intermediate cross-signed CA cert (ca.rsa.cross.crt; see
   Section 3.3):

   +================+   +------------------+   +-------------------+
   || ca.25519.crt ||-->| ca.rsa.cross.crt |-->| alice.encrypt.crt |
   +================+   +------------------+   +-------------------+

      Figure 2: Validating Alice's cert from a different trust anchor
              via an intermediate cross-signed CA certificate

   By omitting the cross-signed CA certs, it should be possible to test
   a "transvalid" certificate (an end-entity certificate that is
   supplied without its intermediate certificate) in some
   configurations.

2.6.  Passwords

   Each secret key presented in this document is represented as a PEM-
   encoded PKCS #8 ([RFC5958]) object in cleartext form (it has no
   password).

   As such, the secret key objects are not suitable for verifying
   interoperable password protection schemes.

   However, the PKCS #12 ([RFC7292]) objects do have simple textual
   passwords, because tooling for dealing with passwordless PKCS #12
   objects is underdeveloped at the time of this document.

2.7.  Secret Key Origins

   The secret RSA keys in this document are all deterministically
   derived using provable prime generation as found in [FIPS186-4] based
   on known seeds derived via SHA-256 ([SHA]) from simple strings.  The
   validation parameters for these derivations are stored in the objects
   themselves as specified in [RFC8479].

   The secret Ed25519 and X25519 keys in this document are all derived
   by hashing a simple string.  The seeds and their derivation are
   included in the document for informational purposes and to allow
   recreation of the objects from appropriate tooling.

   All RSA seeds used are 224 bits long (the first 224 bits of the
   SHA-256 digest of the origin string) and are represented in
   hexadecimal.

3.  Example RSA Certification Authority

   The example RSA Certification Authority has the following
   information:

   Name:  Sample LAMPS RSA Certification Authority

3.1.  RSA Certification Authority Root Certificate

   This certificate is used to verify certificates issued by the example
   RSA Certification Authority.

3.2.  RSA Certification Authority Secret Key

   This secret key material is used by the example RSA Certification
   Authority to issue new certificates.

   This secret key was generated using provable prime generation found
   in [FIPS186-4] using the seed
   a5c1b7847614ed661a6b0522351428b4b7f09d8ccca2d99302dd62e9.  This seed
   is the first 224 bits of the SHA-256 ([SHA]) digest of the string
   draft-lamps-sample-certs-keygen.ca.rsa.seed.

3.3.  RSA Certification Authority Cross-Signed Certificate

   If an email client only trusts the Ed25519 Certification Authority
   Root Certificate found in Section 6.1, they can use this intermediate
   CA certificate to verify any end-entity certificate issued by the
   example RSA Certification Authority.

4.  Alice's Sample Certificates

   Alice has the following information:

   Name:  Alice Lovelace

   Email Address:  alice@smime.example

4.1.  Alice's Signature Verification End-Entity Certificate

   This certificate is used for verification of signatures made by
   Alice.

4.2.  Alice's Signing Private Key Material

   This private key material is used by Alice to create signatures.

   This secret key was generated using provable prime generation found
   in [FIPS186-4] using the seed
   92c89d4330d3d8e31d4fde9b9d0fe6e9fc142141dd65a45e5b436f05.  This seed
   is the first 224 bits of the SHA-256 ([SHA]) digest of the string
   draft-lamps-sample-certs-keygen.alice.sign.seed.

4.3.  Alice's Encryption End-Entity Certificate

   This certificate is used to encrypt messages to Alice.

4.4.  Alice's Decryption Private Key Material

   This private key material is used by Alice to decrypt messages.

   This secret key was generated using provable prime generation found
   in [FIPS186-4] using the seed
   1cf74849f7445f466c4272251f5f96b77fa0698b3e98b3f1ee8207bf.  This seed
   is the first 224 bits of the SHA-256 ([SHA]) digest of the string
   draft-lamps-sample-certs-keygen.alice.encrypt.seed.

4.5.  PKCS #12 Object for Alice

   This PKCS #12 ([RFC7292]) object contains the same information as
   presented in Sections 3.3, 4.1, 4.2, 4.3, and 4.4.

   It is locked with the simple five-letter password alice.

5.  Bob's Sample

   Bob has the following information:

   Name:  Bob Babbage

   Email Address:  bob@smime.example

5.1.  Bob's Signature Verification End-Entity Certificate

   This certificate is used for verification of signatures made by Bob.

5.2.  Bob's Signing Private Key Material

   This private key material is used by Bob to create signatures.

   This secret key was generated using provable prime generation found
   in [FIPS186-4] using the seed
   f4afaacbb5473f360e06ac32e00188fe4173ae15c99bcf043a8b8f6e.  This seed
   is the first 224 bits of the SHA-256 ([SHA]) digest of the string
   draft-lamps-sample-certs-keygen.bob.sign.seed.

5.3.  Bob's Encryption End-Entity Certificate

   This certificate is used to encrypt messages to Bob.

5.4.  Bob's Decryption Private Key Material

   This private key material is used by Bob to decrypt messages.

   This secret key was generated using provable prime generation found
   in [FIPS186-4] using the seed
   98c8998652958929e889e3419f3bfd0edfe0aca15da3060dedf8a1e8.  This seed
   is the first 224 bits of the SHA-256 ([SHA]) digest of the string
   draft-lamps-sample-certs-keygen.bob.encrypt.seed.

5.5.  PKCS #12 Object for Bob

   This PKCS #12 ([RFC7292]) object contains the same information as
   presented in Sections 3.3, 5.1, 5.2, 5.3, and 5.4.

   It is locked with the simple three-letter password bob.

6.  Example Ed25519 Certification Authority

   The example Ed25519 Certification Authority has the following
   information:

   Name:  Sample LAMPS Ed25519 Certification Authority

6.1.  Ed25519 Certification Authority Root Certificate

   This certificate is used to verify certificates issued by the example
   Ed25519 Certification Authority.

6.2.  Ed25519 Certification Authority Secret Key

   This secret key material is used by the example Ed25519 Certification
   Authority to issue new certificates.

   -----BEGIN PRIVATE KEY-----
   MC4CAQAwBQYDK2VwBCIEIAt889xRDvxNT8ak53T7tzKuSn6CQDe8fIdjrCiSFRcp
   -----END PRIVATE KEY-----

   This secret key is the SHA-256 ([SHA]) digest of the ASCII string
   draft-lamps-sample-certs-keygen.ca.25519.seed.

6.3.  Ed25519 Certification Authority Cross-Signed Certificate

   If an email client only trusts the RSA Certification Authority Root
   Certificate found in Section 3.1, they can use this intermediate CA
   certificate to verify any end-entity certificate issued by the
   example Ed25519 Certification Authority.

7.  Carlos's Sample Certificates

   Carlos has the following information:

   Name:  Carlos Turing

   Email Address:  carlos@smime.example

7.1.  Carlos's Signature Verification End-Entity Certificate

   This certificate is used for verification of signatures made by
   Carlos.

7.2.  Carlos's Signing Private Key Material

   This private key material is used by Carlos to create signatures.

   -----BEGIN PRIVATE KEY-----
   MC4CAQAwBQYDK2VwBCIEILvvxL741LfX+Ep3Iyye3Cjr4JmONIVYhZPM4M9N1IHY
   -----END PRIVATE KEY-----

   This secret key is the SHA-256 ([SHA]) digest of the ASCII string
   draft-lamps-sample-certs-keygen.carlos.sign.25519.seed.

7.3.  Carlos's Encryption End-Entity Certificate

   This certificate is used to encrypt messages to Carlos.  It contains
   an SMIMECapabilities extension to indicate that Carlos's MUA expects
   Elliptic Curve Diffie-Hellman (ECDH) with the HMAC-based Key
   Derivation Function (HKDF) using SHA-256, and that it uses the
   AES-128 key wrap algorithm, as indicated in [RFC8418].

7.4.  Carlos's Decryption Private Key Material

   This private key material is used by Carlos to decrypt messages.

   -----BEGIN PRIVATE KEY-----
   MC4CAQAwBQYDK2VuBCIEIIH5782H/otrhLy9Dtvzt79ffsvpcVXgdUczTdUvSQsK
   -----END PRIVATE KEY-----

   This secret key is the SHA-256 ([SHA]) digest of the ASCII string
   draft-lamps-sample-certs-keygen.carlos.encrypt.25519.seed.

7.5.  PKCS #12 Object for Carlos

   This PKCS #12 ([RFC7292]) object contains the same information as
   presented in Sections 6.3, 7.1, 7.2, 7.3, and 7.4.

   It is locked with the simple five-letter password carlos.

8.  Dana's Sample Certificates

   Dana has the following information:

   Name:  Dana Hopper

   Email Address:  dna@smime.example

8.1.  Dana's Signature Verification End-Entity Certificate

   This certificate is used for verification of signatures made by Dana.

8.2.  Dana's Signing Private Key Material

   This private key material is used by Dana to create signatures.

   -----BEGIN PRIVATE KEY-----
   MC4CAQAwBQYDK2VwBCIEINZ8GPfmQh2AMp+uNIsZMbzvyTOltwvEt13usjnUaW4N
   -----END PRIVATE KEY-----

   This secret key is the SHA-256 ([SHA]) digest of the ASCII string
   draft-lamps-sample-certs-keygen.dana.sign.25519.seed.

8.3.  Dana's Encryption End-Entity Certificate

   This certificate is used to encrypt messages to Dana.  It contains an
   SMIMECapabilities extension to indicate that Dana's MUA expects ECDH
   with HKDF using SHA-256, and that it uses the AES-128 key wrap
   algorithm, as indicated in [RFC8418].

8.4.  Dana's Decryption Private Key Material

   This private key material is used by Dana to decrypt messages.

   -----BEGIN PRIVATE KEY-----
   MC4CAQAwBQYDK2VuBCIEIGxZt8L7lY48OEq4gs/smQ4weDhRNMlYHG21StivPfz3
   -----END PRIVATE KEY-----

   This seed is the SHA-256 ([SHA]) digest of the ASCII string draft-
   lamps-sample-certs-keygen.dana.encrypt.25519.seed.

8.5.  PKCS #12 Object for Dana

   This PKCS #12 ([RFC7292]) object contains the same information as
   presented in Sections 6.3, 8.1, 8.2, 8.3, and 8.4.

   It is locked with the simple four-letter password dana.

9.  Security Considerations

   The keys presented in this document should be considered compromised
   and insecure, because the secret key material is published and
   therefore not secret.

   Any application that maintains a deny list of invalid key material
   should include these keys in its list.

10.  IANA Considerations

   This document has no IANA actions.

11.  References

11.1.  Normative References

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <https://www.rfc-editor.org/info/rfc5280>.

   [RFC5958]  Turner, S., "Asymmetric Key Packages", RFC 5958,
              DOI 10.17487/RFC5958, August 2010,
              <https://www.rfc-editor.org/info/rfc5958>.

   [RFC7292]  Moriarty, K., Ed., Nystrom, M., Parkinson, S., Rusch, A.,
              and M. Scott, "PKCS #12: Personal Information Exchange
              Syntax v1.1", RFC 7292, DOI 10.17487/RFC7292, July 2014,
              <https://www.rfc-editor.org/info/rfc7292>.

   [RFC7468]  Josefsson, S. and S. Leonard, "Textual Encodings of PKIX,
              PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468,
              April 2015, <https://www.rfc-editor.org/info/rfc7468>.

   [RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
              Signature Algorithm (EdDSA)", RFC 8032,
              DOI 10.17487/RFC8032, January 2017,
              <https://www.rfc-editor.org/info/rfc8032>.

   [RFC8479]  Mavrogiannopoulos, N., "Storing Validation Parameters in
              PKCS#8", RFC 8479, DOI 10.17487/RFC8479, September 2018,
              <https://www.rfc-editor.org/info/rfc8479>.

   [RFC8551]  Schaad, J., Ramsdell, B., and S. Turner, "Secure/
              Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
              Message Specification", RFC 8551, DOI 10.17487/RFC8551,
              April 2019, <https://www.rfc-editor.org/info/rfc8551>.

11.2.  Informative References

   [FIPS186-4]
              National Institute of Standards and Technology (NIST),
              "Digital Signature Standard (DSS)", FIPS PUB 186-4,
              DOI 10.6028/NIST.FIPS.186-4, July 2013,
              <https://doi.org/10.6028/NIST.FIPS.186-4>.

   [OPENPGP-SAMPLES]
              Einarsson, B. R., juga, and D. K. Gillmor, "OpenPGP
              Example Keys and Certificates", Work in Progress,
              Internet-Draft, draft-bre-openpgp-samples-01, 20 December
              2019, <https://datatracker.ietf.org/doc/html/draft-bre-
              openpgp-samples-01>.

   [RFC4134]  Hoffman, P., Ed., "Examples of S/MIME Messages", RFC 4134,
              DOI 10.17487/RFC4134, July 2005,
              <https://www.rfc-editor.org/info/rfc4134>.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              DOI 10.17487/RFC5322, October 2008,
              <https://www.rfc-editor.org/info/rfc5322>.

   [RFC7469]  Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
              Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April
              2015, <https://www.rfc-editor.org/info/rfc7469>.

   [RFC8410]  Josefsson, S. and J. Schaad, "Algorithm Identifiers for
              Ed25519, Ed448, X25519, and X448 for Use in the Internet
              X.509 Public Key Infrastructure", RFC 8410,
              DOI 10.17487/RFC8410, August 2018,
              <https://www.rfc-editor.org/info/rfc8410>.

   [RFC8418]  Housley, R., "Use of the Elliptic Curve Diffie-Hellman Key
              Agreement Algorithm with X25519 and X448 in the
              Cryptographic Message Syntax (CMS)", RFC 8418,
              DOI 10.17487/RFC8418, August 2018,
              <https://www.rfc-editor.org/info/rfc8418>.

   [SHA]      National Institute of Standards and Technology (NIST),
              "Secure Hash Standard (SHS)", FIPS PUB 180-4,
              DOI 10.6028/NIST.FIPS.180-4, August 2015,
              <https://doi.org/10.6028/NIST.FIPS.180-4>.

   [TEST-POLICY]
              National Institute of Standards and Technology (NIST),
              "Test Certificate Policy to Support PKI Pilots and
              Testing", Computer Security Resource Center, May 2012,
              <https://csrc.nist.gov/CSRC/media/Projects/Computer-
              Security-Objects-Register/documents/test_policy.pdf>.

Acknowledgements

   This document was inspired by similar work in the OpenPGP space by
   Bjarni Rúnar Einarsson and juga; see [OPENPGP-SAMPLES].

   Eric Rescorla helped spot issues with certificate formats.

   Sean Turner pointed to [RFC4134] as prior work.

   Deb Cooley suggested that Alice and Bob should have separate
   certificates for signing and encryption.

   Wolfgang Hommel helped to build reproducible encrypted PKCS #12
   objects.

   Carsten Bormann got the XML sourcecode markup working for this
   document.

   David A. Cooper identified problems with the certificates and
   suggested corrections.

   Lijun Liao helped get the terminology right.

   Stewart Bryant and Roman Danyliw provided editorial suggestions.

Author's Address

   Daniel Kahn Gillmor (editor)
   American Civil Liberties Union
   125 Broad St.
   New York, NY 10004
   United States of America
   Email: dkg@fifthhorseman.net