catch up latest rfc-index, add 3156 3161 and the ancestor

5 files changed, 2798 insertions, 1 deletions

diff --git a/Documentation/en/rfc/index.html b/Documentation/en/rfc/index.html
index 904bc241..261b594c 100644
--- a/Documentation/en/rfc/index.html
+++ b/Documentation/en/rfc/index.html
@@ -1,5 +1,16 @@
 <UL>
 <LI>
+<A NAME="RFC3161" HREF="rfc3161.txt">RFC3161</A>
+"Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)"
+<BR> Updates:
+none<BR>
+<LI>
+<A NAME="RFC3156" HREF="rfc3156.txt">RFC3156</A>
+"MIME Security with OpenPGP"
+<BR> Updates:
+<A HREF="#RFC2015">RFC2015</A>
+<BR>
+<LI>
 <A NAME="RFC3090" HREF="rfc3090.txt">RFC3090</A>
 "DNS Security Extension Clarification on Zone Status"
 <BR> Updates:
@@ -264,6 +275,11 @@ none<BR>
 <BR> Updates:
 none<BR>
 <LI>
+<A NAME="RFC2015" HREF="rfc2015.txt">RFC2015</A>
+"MIME Security with Pretty Good Privacy (PGP)"
+<BR> Updates:
+none<BR>
+<LI>
 <A NAME="RFC2010" HREF="rfc2010.txt">RFC2010</A>
 "Operational Criteria for Root Name Servers"
 <BR> Updates:
diff --git a/Documentation/en/rfc/rfc-index.txt b/Documentation/en/rfc/rfc-index.txt
index d58d4c01..867059f3 100644
--- a/Documentation/en/rfc/rfc-index.txt
+++ b/Documentation/en/rfc/rfc-index.txt
@@ -5,7 +5,7 @@
                              RFC INDEX
                            -------------
 
-(CREATED ON: 10/04/2001.)
+(CREATED ON: 10/16/2001.)
 
 This file contains citations for all RFCs in numeric order.
 
@@ -11097,6 +11097,20 @@ See the RFC Editor Web page http://www.rfc-editor.org
      Hambridge. April 2001. (Format: TXT=64687 bytes) (Also FYI0038)
      (Status: INFORMATIONAL)
 
+3102 Realm Specific IP: Framework. M. Borella, J. Lo, D. Grabelsky, G.
+     Montenegro. October 2001. (Format: TXT=73856 bytes) (Status:
+     EXPERIMENTAL)
+
+3103 Realm Specific IP: Protocol Specification. M. Borella, D.
+     Grabelsky, J. Lo, K. Taniguchi. October 2001. (Format: TXT=115855
+     bytes) (Status: EXPERIMENTAL)
+
+3104 RSIP Support for End-to-end IPsec. G. Montenegro, M. Borella.
+     October 2001. (Format: TXT=38719 bytes) (Status: EXPERIMENTAL)
+
+3105 Finding an RSIP Server with SLP. J. Kempf, G. Montenegro. October
+     2001. (Format: TXT=21427 bytes) (Status: EXPERIMENTAL)
+
 3106 ECML v1.1: Field Specifications for E-Commerce. D. Eastlake, T.
      Goldstein. April 2001. (Format: TXT=40715 bytes) (Obsoletes RFC2706)
      (Status: INFORMATIONAL)
@@ -11357,6 +11371,20 @@ See the RFC Editor Web page http://www.rfc-editor.org
 3177 IAB/IESG Recommendations on IPv6 Address. IAB, IESG. September
      2001. (Format: TXT=23178 bytes) (Status: INFORMATIONAL)
 
+3178 IPv6 Multihoming Support at Site Exit Routers. J. Hagino, H.
+     Snyder. October 2001. (Format: TXT=24453 bytes) (Status:
+     INFORMATIONAL)
+
+3179 Script MIB Extensibility Protocol Version 1.1. J. Schoenwaelder,
+     J. Quittek. October 2001. (Format: TXT=56311 bytes) (Obsoletes
+     RFC2593) (Status: EXPERIMENTAL)
+
 3180 GLOP Addressing in 233/8. D. Meyer, P. Lothberg. September 2001.
      (Format: TXT=8225 bytes) (Obsoletes RFC2770) (Also BCP0053) (Status:
      BEST CURRENT PRACTICE)
+
+3183 Domain Security Services using S/MIME. T. Dean, W. Ottaway.
+     October 2001. (Format: TXT=57129 bytes) (Status: EXPERIMENTAL)
+
+3185 Reuse of CMS Content Encryption Keys. S. Farrell, S. Turner.
+     October 2001. (Format: TXT=20404 bytes) (Status: PROPOSED STANDARD)
diff --git a/Documentation/en/rfc/rfc2015.txt b/Documentation/en/rfc/rfc2015.txt
new file mode 100644
index 00000000..747335d6
--- /dev/null
+++ b/Documentation/en/rfc/rfc2015.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                          M. Elkins
+Request for Comments: 2015                     The Aerospace Corporation
+Category: Standards Track                                   October 1996
+
+
+              MIME Security with Pretty Good Privacy (PGP)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   This document describes how Pretty Good Privacy (PGP) can be used to
+   provide privacy and authentication using the Multipurpose Internet
+   Mail Extensions (MIME) security content types described in RFC1847.
+
+1.  Introduction
+
+   Previous work on integrating PGP with MIME (including the since
+   withdrawn application/pgp content type) has suffered from a number of
+   problems, the most significant of which is the inability to recover
+   signed message bodies without parsing data structures specific to
+   PGP.  This work makes use of the elegant solution proposed in
+   RFC1847, which defines security multipart formats for MIME. The
+   security multiparts clearly separate the signed message body from the
+   signature, and have a number of other desirable properties. This
+   document is styled after RFC 1848, which defines MIME Object Security
+   Services (MOSS) for providing security and authentication.
+
+   This document defines three new content types for implementing
+   security and privacy with PGP: application/pgp-encrypted,
+   application/pgp-signature and application/pgp-keys.
+
+1.1  Compliance
+
+   In order for an implementation to be compliant with this
+   specification, is it absolutely necessary for it to obey all items
+   labeled as MUST or REQUIRED.
+
+
+
+
+
+
+
+
+Elkins                      Standards Track                     [Page 1]
+
+RFC 2015                 MIME Security with PGP             October 1996
+
+
+2.  PGP data formats
+
+   PGP can generate either ASCII armor (described in [3]) or 8-bit
+   binary output when encrypting data, generating a digital signature,
+   or extracting public key data.  The ASCII armor output is the
+   REQUIRED method for data transfer.  This allows those users who do
+   not have the means to interpret the formats described in this
+   document to be able extract and use the PGP information in the
+   message.
+
+   When the amount of data to be transmitted requires that it be sent in
+   many parts, the MIME message/partial mechanism should be used rather
+   than the multipart ASCII armor PGP format.
+
+3.  Content-Transfer-Encoding restrictions
+
+   Multipart/signed and multipart/encrypted are to be treated by agents
+   as opaque, meaning that the data is not to be altered in any way [1].
+   However, many existing mail gateways will detect if the next hop does
+   not support MIME or 8-bit data and perform conversion to either
+   Quoted-Printable or Base64.  This presents serious problems for
+   multipart/signed, in particular, where the signature is invalidated
+   when such an operation occurs.  For this reason all data signed
+   according to this protocol MUST be constrained to 7 bits (8- bit data
+   should be encoded using either Quoted-Printable or Base64).  Note
+   that this also includes the case where a signed object is also
+   encrypted (see section 6).  This restriction will increase the
+   likelihood that the signature will be valid upon receipt.
+
+   Data that is ONLY to be encrypted is allowed to contain 8-bit
+   characters and therefore need not be converted to a 7-bit format.
+
+     Implementor's note: It cannot be stressed enough that applications
+     using this standard should follow MIME's suggestion that you "be
+     conservative in what you generate, and liberal in what you accept."
+     In this particular case it means it would be wise for an
+     implementation to accept messages with any content-transfer-
+     encoding, but restrict generation to the 7-bit format required by
+     this memo.  This will allow future compatibility in the event the
+     Internet SMTP framework becomes 8-bit friendly.
+
+4.  PGP encrypted data
+
+   Before encryption with PGP, the data should be written in MIME
+   canonical format (body and headers).
+
+   PGP encrypted data is denoted by the "multipart/encrypted" content
+   type, described in [1], and MUST have a "protocol" parameter value of
+
+
+
+Elkins                      Standards Track                     [Page 2]
+
+RFC 2015                 MIME Security with PGP             October 1996
+
+
+   "application/pgp-encrypted".  Note that the value of the parameter
+   MUST be enclosed in quotes.
+
+   The multipart/encrypted MUST consist of exactly two parts.  The first
+   MIME body part must have a content type of "application/pgp-
+   encrypted".  This body contains the control information.  A message
+   complying with this standard MUST contain a "Version: 1" field in
+   this body.  Since the PGP packet format contains all other
+   information necessary for decrypting, no other information is
+   required here.
+
+   The second MIME body part MUST contain the actual encrypted data.  It
+   must be labeled with a content type of "application/octet- stream".
+
+   Example message:
+
+     From: Michael Elkins <elkins@aero.org>
+     To: Michael Elkins <elkins@aero.org>
+     Mime-Version: 1.0
+     Content-Type: multipart/encrypted; boundary=foo;
+        protocol="application/pgp-encrypted"
+
+     --foo
+     Content-Type: application/pgp-encrypted
+
+     Version: 1
+
+     --foo
+     Content-Type: application/octet-stream
+
+     -----BEGIN PGP MESSAGE-----
+     Version: 2.6.2
+
+     hIwDY32hYGCE8MkBA/wOu7d45aUxF4Q0RKJprD3v5Z9K1YcRJ2fve87lMlDlx4Oj
+     eW4GDdBfLbJE7VUpp13N19GL8e/AqbyyjHH4aS0YoTk10QQ9nnRvjY8nZL3MPXSZ
+     g9VGQxFeGqzykzmykU6A26MSMexR4ApeeON6xzZWfo+0yOqAq6lb46wsvldZ96YA
+     AABH78hyX7YX4uT1tNCWEIIBoqqvCeIMpp7UQ2IzBrXg6GtukS8NxbukLeamqVW3
+     1yt21DYOjuLzcMNe/JNsD9vDVCvOOG3OCi8=
+     =zzaA
+     -----END PGP MESSAGE-----
+
+     --foo--
+
+5.  PGP signed data
+
+   PGP signed messages are denoted by the "multipart/signed" content
+   type, described in [1], with a "protocol" parameter which MUST have a
+   value of "application/pgp-signature" (MUST be quoted).  The "micalg"
+
+
+
+Elkins                      Standards Track                     [Page 3]
+
+RFC 2015                 MIME Security with PGP             October 1996
+
+
+   parameter MUST have a value of "pgp-<hash-symbol>", where <hash-
+   symbol> identifies the message integrity check (MIC) used to generate
+   the signature.  The currently defined values for <hash-symbol> are
+   "md5" for the MD5 checksum, and "sha1" for the SHA.1 algorithm.
+
+   The multipart/signed body MUST consist of exactly two parts.  The
+   first part contains the signed data in MIME canonical format,
+   including a set of appropriate content headers describing the data.
+
+   The second body MUST contain the PGP digital signature.  It MUST be
+   labeled with a content type of "application/pgp-signature".
+
+   When the PGP digital signature is generated:
+
+   (1)  The data to be signed must first be converted to its
+        type/subtype specific canonical form.  For text/plain, this
+        means conversion to an appropriate character set and conversion
+        of line endings to the canonical <CR><LF> sequence.
+
+   (2)  An appropriate Content-Transfer-Encoding is then applied. Each
+        line of the encoded data MUST end with the canonical <CR><LF>
+        sequence.
+
+   (3)  MIME content headers are then added to the body, each ending
+        with the canonical <CR><LF> sequence.
+
+   (4)  As described in [1], the digital signature MUST be calculated
+        over both the data to be signed and its set of content headers.
+
+   (5)  The signature MUST be generated detached from the signed data
+        so that the process does not alter the signed data in any way.
+
+   Example message:
+
+     From: Michael Elkins <elkins@aero.org>
+     To: Michael Elkins <elkins@aero.org>
+     Mime-Version: 1.0
+     Content-Type: multipart/signed; boundary=bar; micalg=pgp-md5;
+     protocol="application/pgp-signature"
+
+     --bar
+     & Content-Type: text/plain; charset=iso-8859-1
+     & Content-Transfer-Encoding: quoted-printable
+     &
+     & =A1Hola!
+     &
+     & Did you know that talking to yourself is a sign of senility?
+     &
+
+
+
+Elkins                      Standards Track                     [Page 4]
+
+RFC 2015                 MIME Security with PGP             October 1996
+
+
+     & It's generally a good idea to encode lines that begin with
+     & From=20because some mail transport agents will insert a greater-
+     & than (>) sign, thus invalidating the signature.
+     &
+     & Also, in some cases it might be desirable to encode any   =20
+     &railing whitespace that occurs on lines in order to ensure  =20
+     & that the message signature is not invalidated when passing =20
+     & a gateway that modifies such whitespace (like BITNET). =20
+     &
+     & me
+
+     --bar
+     Content-Type: application/pgp-signature
+
+    -----BEGIN PGP MESSAGE-----
+   Version: 2.6.2
+
+   iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//
+   jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq
+   uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn
+   HOxEa44b+EI=
+   =ndaj
+   -----END PGP MESSAGE-----
+
+   --bar--
+
+   The "&"s in the previous example indicate the portion of the data
+   over which the signature was calculated.
+
+   Though not required, it is generally a good idea to use Quoted-
+   Printable encoding in the first step (writing out the data to be
+   signed in MIME canonical format) if any of the lines in the data
+   begin with "From ", and encode the "F".  This will avoid an MTA
+   inserting a ">" in front of the line, thus invalidating the
+   signature!
+
+   Upon receipt of a signed message, an application MUST:
+
+   (1)  Convert line endings to the canonical <CR><LF> sequence before
+        the signature can be verified.  This is necessary since the
+        local MTA may have converted to a local end of line convention.
+
+   (2)  Pass both the signed data and its associated content headers
+        along with the PGP signature to the signature verification
+        service.
+
+
+
+
+
+
+Elkins                      Standards Track                     [Page 5]
+
+RFC 2015                 MIME Security with PGP             October 1996
+
+
+6.  Encrypted and Signed Data
+
+   Sometimes it is desirable to both digitally sign and then encrypt a
+   message to be sent.  This protocol allows for two methods of
+   accomplishing this task.
+
+6.1  RFC1847 Encapsulation
+
+   [1], it is stated that the data should first be signed as a
+   multipart/signature body, and then encrypted to form the final
+   multipart/encrypted body, i.e.,
+
+    Content-Type: multipart/encrypted;
+       protocol="application/pgp-encrypted"; boundary=foo
+
+    --foo
+    Content-Type: application/pgp-encrypted
+
+    Version: 1
+
+    --foo
+    Content-Type: application/octet-stream
+
+    -----BEGIN PGP MESSAGE-----
+    & Content-Type: multipart/signed; micalg=pgp-md5
+    &     protocol="application/pgp-signature"; boundary=bar
+    &
+    & --bar
+    & Content-Type: text/plain; charset=us-ascii
+    &
+    & This message was first signed, and then encrypted.
+    &
+    & --bar
+    & Content-Type: application/pgp-signature
+    &
+    & -----BEGIN PGP MESSAGE-----
+    & Version: 2.6.2
+    &
+    & iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//
+    & jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq
+    & uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn
+    & HOxEa44b+EI=
+    & =ndaj
+    & -----END PGP MESSAGE-----
+    &
+    & --bar--
+    -----END PGP MESSAGE-----
+
+
+
+
+Elkins                      Standards Track                     [Page 6]
+
+RFC 2015                 MIME Security with PGP             October 1996
+
+
+    --foo--
+
+    (The text preceded by '&' indicates that it is really
+    encrypted, but presented as text for clarity.)
+
+6.2  Combined method
+
+   Versions 2.x of PGP also allow data to be signed and encrypted in one
+   operation.  This method is an acceptable shortcut, and has the
+   benefit of less overhead.  The resulting data should be formed as a
+   "multipart/encrypted" object as described above.
+
+   Messages which are encrypted and signed in this combined fashion are
+   REQUIRED to follow the same canonicalization rules as for
+   multipart/signed objects.
+
+   It is explicitly allowed for an agent to decrypt a combined message
+   and rewrite it as a multipart/signed object using the signature data
+   embedded in the encrypted version.
+
+7.  Distribution of PGP public keys
+
+   Content-Type: application/pgp-keys
+   Required parameters: none
+   Optional parameters: none
+
+   This is the content type which should be used for relaying public key
+   blocks.
+
+8.  Notes
+
+   PGP and Pretty Good Privacy are trademarks of Philip Zimmermann.
+
+9.  Security Considerations
+
+   Use of this protocol has the same security considerations as PGP, and
+   is not known to either increase or decrease the security of messages
+   using it; see [3] for more information.
+
+10.  Author's Address
+
+        Michael Elkins
+        P.O. Box 92957 - M1/102
+        Los Angeles, CA 90009-2957
+
+        Phone: +1 310 336 8040
+        Fax: +1 310 336 4402
+
+
+
+
+Elkins                      Standards Track                     [Page 7]
+
+RFC 2015                 MIME Security with PGP             October 1996
+
+
+References
+
+   [1]  Galvin, J., Murphy, G., Crocker, S., and N. Freed, "Security
+        Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
+        RFC 1847, October 1995.
+
+   [2]  Galvin, J., Murphy, G., Crocker, S., and N. Freed, "MIME Object
+        Security Services", RFC 1848, October 1995.
+
+   [3]  Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message
+        Exchange Formats", RFC 1991, August 1996.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Elkins                      Standards Track                     [Page 8]
+
diff --git a/Documentation/en/rfc/rfc3156.txt b/Documentation/en/rfc/rfc3156.txt
new file mode 100644
index 00000000..070c27ce
--- /dev/null
+++ b/Documentation/en/rfc/rfc3156.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Network Working Group                                          M. Elkins
+Request for Comments: 3156                      Network Associates, Inc.
+Updates: 2015                                               D. Del Torto
+Category: Standards Track                        CryptoRights Foundation
+                                                               R. Levien
+                                    University of California at Berkeley
+                                                             T. Roessler
+                                                             August 2001
+
+
+                       MIME Security with OpenPGP
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+Abstract
+
+   This document describes how the OpenPGP Message Format can be used to
+   provide privacy and authentication using the Multipurpose Internet
+   Mail Extensions (MIME) security content types described in RFC 1847.
+
+1.  Introduction
+
+   Work on integrating PGP (Pretty Good Privacy) with MIME [3]
+   (including the since withdrawn "application/pgp" content type) prior
+   to RFC 2015 suffered from a number of problems, the most significant
+   of which is the inability to recover signed message bodies without
+   parsing data structures specific to PGP.  RFC 2015 makes use of the
+   elegant solution proposed in RFC 1847, which defines security
+   multipart formats for MIME.  The security multiparts clearly separate
+   the signed message body from the signature, and have a number of
+   other desirable properties.  This document revises RFC 2015 to adopt
+   the integration of PGP and MIME to the needs which emerged during the
+   work on the OpenPGP specification.
+
+   This document defines three content types for implementing security
+   and privacy with OpenPGP: "application/pgp-encrypted",
+   "application/pgp-signature" and "application/pgp-keys".
+
+
+
+
+Elkins, et al.              Standards Track                     [Page 1]
+
+RFC 3156               MIME Security with OpenPGP            August 2001
+
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119.
+
+2.  OpenPGP data formats
+
+   OpenPGP implementations can generate either ASCII armor (described in
+   [1]) or 8-bit binary output when encrypting data, generating a
+   digital signature, or extracting public key data.  The ASCII armor
+   output is the REQUIRED method for data transfer.  This allows those
+   users who do not have the means to interpret the formats described in
+   this document to be able to extract and use the OpenPGP information
+   in the message.
+
+   When the amount of data to be transmitted requires that it be sent in
+   many parts, the MIME message/partial mechanism SHOULD be used rather
+   than the multi-part ASCII armor OpenPGP format.
+
+3.  Content-Transfer-Encoding restrictions
+
+   Multipart/signed and multipart/encrypted are to be treated by agents
+   as opaque, meaning that the data is not to be altered in any way [2],
+   [7].  However, many existing mail gateways will detect if the next
+   hop does not support MIME or 8-bit data and perform conversion to
+   either Quoted-Printable or Base64.  This presents serious problems
+   for multipart/signed, in particular, where the signature is
+   invalidated when such an operation occurs.  For this reason all data
+   signed according to this protocol MUST be constrained to 7 bits (8-
+   bit data MUST be encoded using either Quoted-Printable or Base64).
+   Note that this also includes the case where a signed object is also
+   encrypted (see section 6).  This restriction will increase the
+   likelihood that the signature will be valid upon receipt.
+
+   Additionally, implementations MUST make sure that no trailing
+   whitespace is present after the MIME encoding has been applied.
+
+      Note: In most cases, trailing whitespace can either be removed, or
+      protected by applying an appropriate content-transfer-encoding.
+      However, special care must be taken when any header lines - either
+      in MIME entity headers, or in embedded RFC 822 headers - are
+      present which only consist of whitespace: Such lines must be
+      removed entirely, since replacing them by empty lines would turn
+      them into header delimiters, and change the semantics of the
+      message.  The restrictions on whitespace are necessary in order to
+      make the hash calculated invariant under the text and binary mode
+      signature mechanisms provided by OpenPGP [1].  Also, they help to
+      avoid compatibility problems with PGP implementations which
+      predate the OpenPGP specification.
+
+
+
+Elkins, et al.              Standards Track                     [Page 2]
+
+RFC 3156               MIME Security with OpenPGP            August 2001
+
+
+      Note: If any line begins with the string "From ", it is strongly
+      suggested that either the Quoted-Printable or Base64 MIME encoding
+      be applied.  If Quoted-Printable is used, at least one of the
+      characters in the string should be encoded using the hexadecimal
+      coding rule.  This is because many mail transfer and delivery
+      agents treat "From " (the word "from" followed immediately by a
+      space character) as the start of a new message and thus insert a
+      right angle-bracket (>) in front of any line beginning with
+      "From " to distinguish this case, invalidating the signature.
+
+   Data that is ONLY to be encrypted is allowed to contain 8-bit
+   characters and trailing whitespace and therefore need not undergo the
+   conversion to a 7bit format, and the stripping of whitespace.
+
+      Implementor's note: It cannot be stressed enough that applications
+      using this standard follow MIME's suggestion that you "be
+      conservative in what you generate, and liberal in what you
+      accept."  In this particular case it means it would be wise for an
+      implementation to accept messages with any content-transfer-
+      encoding, but restrict generation to the 7-bit format required by
+      this memo.  This will allow future compatibility in the event the
+      Internet SMTP framework becomes 8-bit friendly.
+
+4.  OpenPGP encrypted data
+
+   Before OpenPGP encryption, the data is written in MIME canonical
+   format (body and headers).
+
+   OpenPGP encrypted data is denoted by the "multipart/encrypted"
+   content type, described in [2], and MUST have a "protocol" parameter
+   value of "application/pgp-encrypted".  Note that the value of the
+   parameter MUST be enclosed in quotes.
+
+   The multipart/encrypted MIME body MUST consist of exactly two body
+   parts, the first with content type "application/pgp-encrypted".  This
+   body contains the control information.  A message complying with this
+   standard MUST contain a "Version: 1" field in this body.  Since the
+   OpenPGP packet format contains all other information necessary for
+   decrypting, no other information is required here.
+
+   The second MIME body part MUST contain the actual encrypted data.  It
+   MUST be labeled with a content type of "application/octet-stream".
+
+   Example message:
+
+      From: Michael Elkins <elkins@aero.org>
+      To: Michael Elkins <elkins@aero.org>
+      Mime-Version: 1.0
+
+
+
+Elkins, et al.              Standards Track                     [Page 3]
+
+RFC 3156               MIME Security with OpenPGP            August 2001
+
+
+      Content-Type: multipart/encrypted; boundary=foo;
+         protocol="application/pgp-encrypted"
+
+      --foo
+      Content-Type: application/pgp-encrypted
+
+      Version: 1
+
+      --foo
+      Content-Type: application/octet-stream
+
+      -----BEGIN PGP MESSAGE-----
+      Version: 2.6.2
+
+      hIwDY32hYGCE8MkBA/wOu7d45aUxF4Q0RKJprD3v5Z9K1YcRJ2fve87lMlDlx4Oj
+      eW4GDdBfLbJE7VUpp13N19GL8e/AqbyyjHH4aS0YoTk10QQ9nnRvjY8nZL3MPXSZ
+      g9VGQxFeGqzykzmykU6A26MSMexR4ApeeON6xzZWfo+0yOqAq6lb46wsvldZ96YA
+      AABH78hyX7YX4uT1tNCWEIIBoqqvCeIMpp7UQ2IzBrXg6GtukS8NxbukLeamqVW3
+      1yt21DYOjuLzcMNe/JNsD9vDVCvOOG3OCi8=
+      =zzaA
+      -----END PGP MESSAGE-----
+
+      --foo--
+
+5.  OpenPGP signed data
+
+   OpenPGP signed messages are denoted by the "multipart/signed" content
+   type, described in [2], with a "protocol" parameter which MUST have a
+   value of "application/pgp-signature" (MUST be quoted).
+
+   The "micalg" parameter for the "application/pgp-signature" protocol
+   MUST contain exactly one hash-symbol of the format "pgp-<hash-
+   identifier>", where <hash-identifier> identifies the Message
+   Integrity Check (MIC) algorithm used to generate the signature.
+   Hash-symbols are constructed from the text names registered in [1] or
+   according to the mechanism defined in that document by converting the
+   text name to lower case and prefixing it with the four characters
+   "pgp-".
+
+   Currently defined values are "pgp-md5", "pgp-sha1", "pgp-ripemd160",
+   "pgp-md2", "pgp-tiger192", and "pgp-haval-5-160".
+
+   The multipart/signed body MUST consist of exactly two parts.  The
+   first part contains the signed data in MIME canonical format,
+   including a set of appropriate content headers describing the data.
+
+   The second body MUST contain the OpenPGP digital signature.  It MUST
+   be labeled with a content type of "application/pgp-signature".
+
+
+
+Elkins, et al.              Standards Track                     [Page 4]
+
+RFC 3156               MIME Security with OpenPGP            August 2001
+
+
+      Note: Implementations can either generate "signatures of a
+      canonical text document" or "signatures of a binary document", as
+      defined in [1].  The restrictions on the signed material put forth
+      in section 3 and in this section will make sure that the various
+      MIC algorithm variants specified in [1] and [5] will all produce
+      the same result.
+
+   When the OpenPGP digital signature is generated:
+
+   (1)   The data to be signed MUST first be converted to its content-
+         type specific canonical form.  For text/plain, this means
+         conversion to an appropriate character set and conversion of
+         line endings to the canonical <CR><LF> sequence.
+
+   (2)   An appropriate Content-Transfer-Encoding is then applied; see
+         section 3.  In particular, line endings in the encoded data
+         MUST use the canonical <CR><LF> sequence where appropriate
+         (note that the canonical line ending may or may not be present
+         on the last line of encoded data and MUST NOT be included in
+         the signature if absent).
+
+   (3)   MIME content headers are then added to the body, each ending
+         with the canonical <CR><LF> sequence.
+
+   (4)   As described in section 3 of this document, any trailing
+         whitespace MUST then be removed from the signed material.
+
+   (5)   As described in [2], the digital signature MUST be calculated
+         over both the data to be signed and its set of content headers.
+
+   (6)   The signature MUST be generated detached from the signed data
+         so that the process does not alter the signed data in any way.
+
+      Note: The accepted OpenPGP convention is for signed data to end
+      with a <CR><LF> sequence.  Note that the <CR><LF> sequence
+      immediately preceding a MIME boundary delimiter line is considered
+      to be part of the delimiter in [3], 5.1.  Thus, it is not part of
+      the signed data preceding the delimiter line.  An implementation
+      which elects to adhere to the OpenPGP convention has to make sure
+      it inserts a <CR><LF> pair on the last line of the data to be
+      signed and transmitted (signed message and transmitted message
+      MUST be identical).
+
+   Example message:
+
+         From: Michael Elkins <elkins@aero.org>
+         To: Michael Elkins <elkins@aero.org>
+         Mime-Version: 1.0
+
+
+
+Elkins, et al.              Standards Track                     [Page 5]
+
+RFC 3156               MIME Security with OpenPGP            August 2001
+
+
+         Content-Type: multipart/signed; boundary=bar; micalg=pgp-md5;
+           protocol="application/pgp-signature"
+
+         --bar
+      & Content-Type: text/plain; charset=iso-8859-1
+      & Content-Transfer-Encoding: quoted-printable
+      &
+      & =A1Hola!
+      &
+      & Did you know that talking to yourself is a sign of senility?
+      &
+      & It's generally a good idea to encode lines that begin with
+      & From=20because some mail transport agents will insert a greater-
+      & than (>) sign, thus invalidating the signature.
+      &
+      & Also, in some cases it might be desirable to encode any   =20
+      & trailing whitespace that occurs on lines in order to ensure  =20
+      & that the message signature is not invalidated when passing =20
+      & a gateway that modifies such whitespace (like BITNET). =20
+      &
+      & me
+
+      --bar
+
+      Content-Type: application/pgp-signature
+
+      -----BEGIN PGP MESSAGE-----
+      Version: 2.6.2
+
+      iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//
+      jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq
+      uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn
+      HOxEa44b+EI=
+      =ndaj
+      -----END PGP MESSAGE-----
+
+      --bar--
+
+   The "&"s in the previous example indicate the portion of the data
+   over which the signature was calculated.
+
+   Upon receipt of a signed message, an application MUST:
+
+   (1)   Convert line endings to the canonical <CR><LF> sequence before
+         the signature can be verified.  This is necessary since the
+         local MTA may have converted to a local end of line convention.
+
+
+
+
+
+Elkins, et al.              Standards Track                     [Page 6]
+
+RFC 3156               MIME Security with OpenPGP            August 2001
+
+
+   (2)   Pass both the signed data and its associated content headers
+         along with the OpenPGP signature to the signature verification
+         service.
+
+6.  Encrypted and Signed Data
+
+   Sometimes it is desirable to both digitally sign and then encrypt a
+   message to be sent.  This protocol allows for two methods of
+   accomplishing this task.
+
+6.1.  RFC 1847 Encapsulation
+
+   In [2], it is stated that the data is first signed as a
+   multipart/signature body, and then encrypted to form the final
+   multipart/encrypted body.  This is most useful for standard MIME-
+   compliant message forwarding.
+
+   Example:
+
+         Content-Type: multipart/encrypted;
+            protocol="application/pgp-encrypted"; boundary=foo
+
+         --foo
+         Content-Type: application/pgp-encrypted
+
+         Version: 1
+
+         --foo
+         Content-Type: application/octet-stream
+
+         -----BEGIN PGP MESSAGE-----
+      & Content-Type: multipart/signed; micalg=pgp-md5
+      &     protocol="application/pgp-signature"; boundary=bar
+      &
+      & --bar
+      & Content-Type: text/plain; charset=us-ascii
+      &
+      & This message was first signed, and then encrypted.
+      &
+      & --bar
+      & Content-Type: application/pgp-signature
+      &
+      & -----BEGIN PGP MESSAGE-----
+      & Version: 2.6.2
+      &
+      & iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//
+      & jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq
+      & uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn
+
+
+
+Elkins, et al.              Standards Track                     [Page 7]
+
+RFC 3156               MIME Security with OpenPGP            August 2001
+
+
+      & HOxEa44b+EI=
+      & =ndaj
+      & -----END PGP MESSAGE-----
+      &
+      & --bar--
+        -----END PGP MESSAGE-----
+
+        --foo--
+
+   (The text preceded by '&' indicates that it is really encrypted, but
+   presented as text for clarity.)
+
+6.2.  Combined method
+
+   The OpenPGP packet format [1] describes a method for signing and
+   encrypting data in a single OpenPGP message.  This method is allowed
+   in order to reduce processing overhead and increase compatibility
+   with non-MIME implementations of OpenPGP.  The resulting data is
+   formatted as a "multipart/encrypted" object as described in Section
+   4.
+
+   Messages which are encrypted and signed in this combined fashion are
+   REQUIRED to follow the same canonicalization rules as
+   multipart/signed objects.
+
+   It is explicitly allowed for an agent to decrypt a combined message
+   and rewrite it as a multipart/signed object using the signature data
+   embedded in the encrypted version.
+
+7.  Distribution of OpenPGP public keys
+
+   Content-Type: application/pgp-keys
+   Required parameters: none
+   Optional parameters: none
+
+   A MIME body part of the content type "application/pgp-keys" contains
+   ASCII-armored transferable Public Key Packets as defined in [1],
+   section 10.1.
+
+8.  Security Considerations
+
+   Signatures of a canonical text document as defined in [1] ignore
+   trailing white space in signed material.  Implementations which
+   choose to use signatures of canonical text documents will not be able
+   to detect the addition of whitespace in transit.
+
+   See [3], [4] for more information on the security considerations
+   concerning the underlying protocols.
+
+
+
+Elkins, et al.              Standards Track                     [Page 8]
+
+RFC 3156               MIME Security with OpenPGP            August 2001
+
+
+9.  IANA Considerations
+
+   This document defines three media types: "application/pgp-encrypted",
+   "application/pgp-signature" and "application/pgp-keys".  The
+   following sections specify the IANA registrations for these types.
+
+9.1.  Registration of the application/pgp-encrypted media type
+
+   MIME media type name: application
+   MIME subtype name: pgp-encrypted
+   Required parameters: none
+   Optional parameters: none
+
+   Encoding considerations:
+
+      Currently this media type always consists of a single 7bit text
+      string.
+
+   Security considerations:
+
+      See Section 8 and RFC 2440 Section 13.
+
+   Interoperability considerations: none
+
+   Published specification:
+
+      This document.
+
+   Additional information:
+
+      Magic number(s): none
+      File extension(s): none
+      Macintosh File Type Code(s): none
+
+   Person & email address to contact for further information:
+
+      Michael Elkins
+      Email: me@cs.hmc.edu
+
+   Intended usage: common
+
+   Author/Change controller:
+
+      Michael Elkins
+      Email: me@cs.hmc.edu
+
+
+
+
+
+
+Elkins, et al.              Standards Track                     [Page 9]
+
+RFC 3156               MIME Security with OpenPGP            August 2001
+
+
+9.2.  Registration of the application/pgp-signature media type
+
+   MIME media type name: application
+   MIME subtype name: pgp-signature
+   Required parameters: none
+   Optional parameters: none
+
+   Encoding considerations:
+
+      The content of this media type always consists of 7bit text.
+
+   Security considerations:
+
+      See Section 8 and RFC 2440 Section 13.
+
+   Interoperability considerations: none
+
+   Published specification:
+
+      RFC 2440 and this document.
+
+   Additional information:
+
+      Magic number(s): none
+      File extension(s): asc, sig
+      Macintosh File Type Code(s): pgDS
+
+   Person & email address to contact for further information:
+
+      Michael Elkins
+      Email: me@cs.hmc.edu
+
+   Intended usage: common
+
+   Author/Change controller:
+
+      Michael Elkins
+      Email: me@cs.hmc.edu
+
+9.3.  Registration of the application/pgp-keys media type
+
+   MIME media type name: application
+   MIME subtype name: pgp-keys
+   Required parameters: none
+   Optional parameters: none
+
+
+
+
+
+
+Elkins, et al.              Standards Track                    [Page 10]
+
+RFC 3156               MIME Security with OpenPGP            August 2001
+
+
+   Encoding considerations:
+
+      The content of this media type always consists of 7bit text.
+
+   Security considerations:
+
+      See Section 8 and RFC 2440 Section 13.
+
+   Interoperability considerations: none
+
+   Published specification:
+
+      RFC 2440 and this document.
+
+   Additional information:
+
+      Magic number(s): none
+      File extension(s): asc
+      Macintosh File Type Code(s): none
+
+   Person & email address to contact for further information:
+
+      Michael Elkins
+      Email: me@cs.hmc.edu
+
+   Intended usage: common
+
+   Author/Change controller:
+
+      Michael Elkins
+      Email: me@cs.hmc.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Elkins, et al.              Standards Track                    [Page 11]
+
+RFC 3156               MIME Security with OpenPGP            August 2001
+
+
+10.  Notes
+
+   "PGP" and "Pretty Good Privacy" are registered trademarks of Network
+   Associates, Inc.
+
+11.  Acknowledgements
+
+   This document relies on the work of the IETF's OpenPGP Working
+   Group's definitions of the OpenPGP Message Format.  The OpenPGP
+   message format is currently described in RFC 2440 [1].
+
+   Special thanks are due: to Philip Zimmermann for his original and
+   ongoing work on PGP; to Charles Breed, Jon Callas and Dave Del Torto
+   for originally proposing the formation of the OpenPGP Working Group;
+   and to Steve Schoenfeld for helpful feedback during the draft
+   process.  The authors would also like to thank the engineers at
+   Pretty Good Privacy, Inc (now Network Associates, Inc), including
+   Colin Plumb, Hal Finney, Jon Callas, Mark Elrod, Mark Weaver and
+   Lloyd Chambers, for their technical commentary.
+
+   Additional thanks are due to Jeff Schiller and Derek Atkins for their
+   continuing support of strong cryptography and PGP freeware at MIT; to
+   Rodney Thayer of Sable Technology; to John Noerenberg, Steve Dorner
+   and Laurence Lundblade of the Eudora team at QUALCOMM, Inc; to Bodo
+   Moeller for proposing the approach followed with respect to trailing
+   whitespace; to John Gilmore, Hugh Daniel and Fred Ringel (at
+   Rivertown) and Ian Bell (at Turnpike) for their timely critical
+   commentary; and to the international members of the IETF's OpenPGP
+   mailing list, including William Geiger, Lutz Donnerhacke and Kazu
+   Yamamoto.  The idea to use multipart/mixed with multipart/signed has
+   been attributed to James Galvin.  Finally, our gratitude is due to
+   the many members of the "Cypherpunks," "Coderpunks" and "pgp-users"
+   <http://cryptorights.org/pgp-users> mailing lists and the many users
+   of PGP worldwide for helping keep the path to privacy open.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Elkins, et al.              Standards Track                    [Page 12]
+
+RFC 3156               MIME Security with OpenPGP            August 2001
+
+
+12.  Addresses of the Authors and OpenPGP Working Group Chair
+
+   The OpenPGP working group can be contacted via the current chair:
+
+   John W. Noerenberg II
+   Qualcomm, Inc.
+   5775 Morehouse Dr.
+   San Diego, CA 92121 USA
+
+   Phone: +1 619 658 3510
+   EMail: jwn2@qualcomm.com
+
+   The principal authors of this document are:
+
+   Dave Del Torto
+   CryptoRights Foundation
+   80 Alviso Street, Mailstop: CRF
+   San Francisco, CA 94127 USA
+
+   Phone: +1.415.334.5533, vm: #2
+   EMail: ddt@cryptorights.org, ddt@openpgp.net
+
+
+   Michael Elkins
+   Network Associates, Inc.
+   3415 S. Sepulveda Blvd Suite 700
+   Los Angeles, CA 90034 USA
+
+   Phone: +1.310.737.1663
+   Fax:   +1.310.737.1755
+   Email: me@cs.hmc.edu, Michael_Elkins@NAI.com
+
+
+   Raph Levien
+   University of California at Berkeley
+   579 Soda Hall
+   Berkeley, CA 94720 USA
+
+   Phone: +1.510.642.6509
+   EMail: raph@acm.org
+
+
+   Thomas Roessler
+   Nordstrasse 99
+   D-53111 Bonn, Germany
+
+   Phone: +49-228-638007
+   EMail: roessler@does-not-exist.org
+
+
+
+Elkins, et al.              Standards Track                    [Page 13]
+
+RFC 3156               MIME Security with OpenPGP            August 2001
+
+
+References
+
+   [1]   Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP
+         Message Format", RFC 2440, November 1998.
+
+   [2]   Galvin, J., Murphy, G., Crocker, S. and N. Freed, "Security
+         Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
+         RFC 1847, October 1995.
+
+   [3]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+         Extensions (MIME) Part Two: Media Types", RFC 2046, November
+         1996.
+
+   [4]   Galvin, J., Murphy, G., Crocker, S. and N. Freed, "MIME Object
+         Security Services", RFC 1848, October 1995.
+
+   [5]   Atkins, D., Stallings, W. and P. Zimmermann, "PGP Message
+         Exchange Formats", RFC 1991, August 1996.
+
+   [6]   Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RFC
+         2015, October 1996.
+
+   [7]   Freed, N., "Gateways and MIME Security Multiparts", RFC 2480,
+         January 1999.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Elkins, et al.              Standards Track                    [Page 14]
+
+RFC 3156               MIME Security with OpenPGP            August 2001
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Elkins, et al.              Standards Track                    [Page 15]
+
diff --git a/Documentation/en/rfc/rfc3161.txt b/Documentation/en/rfc/rfc3161.txt
new file mode 100644
index 00000000..628f300a
--- /dev/null
+++ b/Documentation/en/rfc/rfc3161.txt
@@ -0,0 +1,1459 @@
+
+
+
+
+
+
+Network Working Group                                           C. Adams
+Request for Comments: 3161                                       Entrust
+Category: Standards Track                                        P. Cain
+                                                                     BBN
+                                                               D. Pinkas
+                                                                Integris
+                                                           R. Zuccherato
+                                                                 Entrust
+                                                             August 2001
+
+
+                Internet X.509 Public Key Infrastructure
+                       Time-Stamp Protocol (TSP)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+Abstract
+
+   This document describes the format of a request sent to a Time
+   Stamping Authority (TSA) and of the response that is returned.  It
+   also establishes several security-relevant requirements for TSA
+   operation, with regards to processing requests to generate responses.
+
+1.  Introduction
+
+   A time-stamping service supports assertions of proof that a datum
+   existed before a particular time.  A TSA may be operated as a Trusted
+   Third Party (TTP) service, though other operational models may be
+   appropriate, e.g., an organization might require a TSA for internal
+   time-stamping purposes.
+
+   Non-repudiation services [ISONR] require the ability to establish the
+   existence of data before specified times.  This protocol may be used
+   as a building block to support such services.  An example of how to
+   prove that a digital signature was generated during the validity
+   period of a public key certificate is given in an annex.
+
+
+
+
+
+Adams, et al.               Standards Track                     [Page 1]
+
+RFC 3161               Time-Stamp Protocol (TSP)             August 2001
+
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
+   "SHALL", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in
+   uppercase, as shown) are to be interpreted as described in [RFC2119].
+
+   In order to associate a datum with a particular point in time, a Time
+   Stamp Authority (TSA) may need to be used.  This Trusted Third Party
+   provides a "proof-of-existence" for this particular datum at an
+   instant in time.
+
+   The TSA's role is to time-stamp a datum to establish evidence
+   indicating that a datum existed before a particular time.  This can
+   then be used, for example, to verify that a digital signature was
+   applied to a message before the corresponding certificate was revoked
+   thus allowing a revoked public key certificate to be used for
+   verifying signatures created prior to the time of revocation.  This
+   is an important public key infrastructure operation.  The TSA can
+   also be used to indicate the time of submission when a deadline is
+   critical, or to indicate the time of transaction for entries in a
+   log.  An exhaustive list of possible uses of a TSA is beyond the
+   scope of this document.
+
+   This standard does not establish overall security requirements for
+   TSA operation, just like other PKIX standards do not establish such
+   requirements for CA operation.  Rather, it is anticipated that a TSA
+   will make known to prospective clients the policies it implements to
+   ensure accurate time-stamp generation, and clients will make use of
+   the services of a TSA only if they are satisfied that these policies
+   meet their needs.
+
+2. The TSA
+
+   The TSA is a TTP that creates time-stamp tokens in order to indicate
+   that a datum existed at a particular point in time.
+
+   For the remainder of this document a "valid request" shall mean one
+   that can be decoded correctly, is of the form specified in Section
+   2.4, and is from a supported TSA subscriber.
+
+2.1. Requirements of the TSA
+
+   The TSA is REQUIRED:
+
+   1.    to use a trustworthy source of time.
+
+   2.    to include a trustworthy time value for each time-stamp token.
+
+   3.    to include a unique integer for each newly generated time-stamp
+         token.
+
+
+
+Adams, et al.               Standards Track                     [Page 2]
+
+RFC 3161               Time-Stamp Protocol (TSP)             August 2001
+
+
+   4.    to produce a time-stamp token upon receiving a valid request
+         from the requester, when it is possible.
+
+   5.    to include within each time-stamp token an identifier to
+         uniquely indicate the security policy under which the token was
+         created.
+
+   6.    to only time-stamp a hash representation of the datum, i.e., a
+         data imprint associated with a one-way collision resistant
+         hash-function uniquely identified by an OID.
+
+   7.    to examine the OID of the one-way collision resistant hash-
+         function and to verify that the hash value length is consistent
+         with the hash algorithm.
+
+   8.    not to examine the imprint being time-stamped in any way (other
+         than to check its length, as specified in the previous bullet).
+
+   9.    not to include any identification of the requesting entity in
+         the time-stamp tokens.
+
+   10.   to sign each time-stamp token using a key generated exclusively
+         for this purpose and have this property of the key indicated on
+         the corresponding certificate.
+
+   11.   to include additional information in the time-stamp token, if
+         asked by the requester using the extensions field, only for the
+         extensions that are supported by the TSA.  If this is not
+         possible, the TSA SHALL respond with an error message.
+
+2.2. TSA Transactions
+
+   As the first message of this mechanism, the requesting entity
+   requests a time-stamp token by sending a request (which is or
+   includes a TimeStampReq, as defined below) to the Time Stamping
+   Authority.  As the second message, the Time Stamping Authority
+   responds by sending a response (which is or includes a TimeStampResp,
+   as defined below) to the requesting entity.
+
+   Upon receiving the response (which is or includes a TimeStampResp
+   that normally contains a TimeStampToken (TST), as defined below), the
+   requesting entity SHALL verify the status error returned in the
+   response and if no error is present it SHALL verify the various
+   fields contained in the TimeStampToken and the validity of the
+   digital signature of the TimeStampToken.  In particular, it SHALL
+   verify that what was time-stamped corresponds to what was requested
+   to be time-stamped.  The requester SHALL verify that the
+   TimeStampToken contains the correct certificate identifier of the
+
+
+
+Adams, et al.               Standards Track                     [Page 3]
+
+RFC 3161               Time-Stamp Protocol (TSP)             August 2001
+
+
+   TSA, the correct data imprint and the correct hash algorithm OID.  It
+   SHALL then verify the timeliness of the response by verifying either
+   the time included in the response against a local trusted time
+   reference, if one is available, or the value of the nonce (large
+   random number with a high probability that it is generated by the
+   client only once) included in the response against the value included
+   in the request.  For more details about replay attack detection, see
+   the security considerations section (item 6).  If any of the
+   verifications above fails, the TimeStampToken SHALL be rejected.
+
+   Then, since the TSA's certificate may have been revoked, the status
+   of the certificate SHOULD be checked (e.g., by checking the
+   appropriate CRL) to verify that the certificate is still valid.
+
+   Then, the client application SHOULD check the policy field to
+   determine whether or not the policy under which the token was issued
+   is acceptable for the application.
+
+2.3. Identification of the TSA
+
+   The TSA MUST sign each time-stamp message with a key reserved
+   specifically for that purpose.  A TSA MAY have distinct private keys,
+   e.g., to accommodate different policies, different algorithms,
+   different private key sizes or to increase the performance.  The
+   corresponding certificate MUST contain only one instance of the
+   extended key usage field extension as defined in [RFC2459] Section
+   4.2.1.13 with KeyPurposeID having value:
+
+   id-kp-timeStamping.  This extension MUST be critical.
+
+   The following object identifier identifies the KeyPurposeID having
+   value id-kp-timeStamping.
+
+   id-kp-timeStamping OBJECT IDENTIFIER ::= {iso(1)
+                   identified-organization(3) dod(6)
+                   internet(1) security(5) mechanisms(5) pkix(7)
+                   kp (3) timestamping (8)}
+
+2.4. Request and Response Formats
+
+2.4.1. Request Format
+
+   A time-stamping request is as follows:
+
+TimeStampReq ::= SEQUENCE  {
+   version                      INTEGER  { v1(1) },
+   messageImprint               MessageImprint,
+     --a hash algorithm OID and the hash value of the data to be
+
+
+
+Adams, et al.               Standards Track                     [Page 4]
+
+RFC 3161               Time-Stamp Protocol (TSP)             August 2001
+
+
+     --time-stamped
+   reqPolicy             TSAPolicyId              OPTIONAL,
+   nonce                 INTEGER                  OPTIONAL,
+   certReq               BOOLEAN                  DEFAULT FALSE,
+   extensions            [0] IMPLICIT Extensions  OPTIONAL  }
+
+   The version field (currently v1) describes the version of the Time-
+   Stamp request.
+
+   The messageImprint field SHOULD contain the hash of the datum to be
+   time-stamped.  The hash is represented as an OCTET STRING.  Its
+   length MUST match the length of the hash value for that algorithm
+   (e.g., 20 bytes for SHA-1 or 16 bytes for MD5).
+
+   MessageImprint ::= SEQUENCE  {
+        hashAlgorithm                AlgorithmIdentifier,
+        hashedMessage                OCTET STRING  }
+
+   The hash algorithm indicated in the hashAlgorithm field SHOULD be a
+   known hash algorithm (one-way and collision resistant).  That means
+   that it SHOULD be one-way and collision resistant.  The Time Stamp
+   Authority SHOULD check whether or not the given hash algorithm is
+   known to be "sufficient" (based on the current state of knowledge in
+   cryptanalysis and the current state of the art in computational
+   resources, for example).  If the TSA does not recognize the hash
+   algorithm or knows that the hash algorithm is weak (a decision left
+   to the discretion of each individual TSA), then the TSA SHOULD refuse
+   to provide the time-stamp token by returning a pkiStatusInfo of
+   'bad_alg'.
+
+   The reqPolicy field, if included, indicates the TSA policy under
+   which the TimeStampToken SHOULD be provided.  TSAPolicyId is defined
+   as follows:
+
+      TSAPolicyId ::= OBJECT IDENTIFIER
+
+   The nonce, if included, allows the client to verify the timeliness of
+   the response when no local clock is available.  The nonce is a large
+   random number with a high probability that the client generates it
+   only once (e.g., a 64 bit integer).  In such a case the same nonce
+   value MUST be included in the response, otherwise the response shall
+   be rejected.
+
+   If the certReq field is present and set to true, the TSA's public key
+   certificate that is referenced by the ESSCertID identifier inside a
+   SigningCertificate attribute in the response MUST be provided by the
+   TSA in the certificates field from the SignedData structure in that
+   response.  That field may also contain other certificates.
+
+
+
+Adams, et al.               Standards Track                     [Page 5]
+
+RFC 3161               Time-Stamp Protocol (TSP)             August 2001
+
+
+   If the certReq field is missing or if the certReq field is present
+   and set to false then the certificates field from the SignedData
+   structure MUST not be present in the response.
+
+   The extensions field is a generic way to add additional information
+   to the request in the future.  Extensions is defined in [RFC 2459].
+   If an extension, whether it is marked critical or not critical, is
+   used by a requester but is not recognized by a time-stamping server,
+   the server SHALL not issue a token and SHALL return a failure
+   (unacceptedExtension).
+
+   The time-stamp request does not identify the requester, as this
+   information is not validated by the TSA (See Section 2.1).  In
+   situations where the TSA requires the identity of the requesting
+   entity, alternate identification /authentication means have to be
+   used (e.g., CMS encapsulation [CMS] or TLS authentication [RFC2246]).
+
+2.4.2. Response Format
+
+   A time-stamping response is as follows:
+
+   TimeStampResp ::= SEQUENCE  {
+      status                  PKIStatusInfo,
+      timeStampToken          TimeStampToken     OPTIONAL  }
+
+   The status is based on the definition of status in section 3.2.3
+   of [RFC2510] as follows:
+
+   PKIStatusInfo ::= SEQUENCE {
+      status        PKIStatus,
+      statusString  PKIFreeText     OPTIONAL,
+      failInfo      PKIFailureInfo  OPTIONAL  }
+
+   When the status contains the value zero or one, a TimeStampToken MUST
+   be present.  When status contains a value other than zero or one, a
+   TimeStampToken MUST NOT be present.  One of the following values MUST
+   be contained in status:
+
+   PKIStatus ::= INTEGER {
+      granted                (0),
+      -- when the PKIStatus contains the value zero a TimeStampToken, as
+         requested, is present.
+      grantedWithMods        (1),
+       -- when the PKIStatus contains the value one a TimeStampToken,
+         with modifications, is present.
+      rejection              (2),
+      waiting                (3),
+      revocationWarning      (4),
+
+
+
+Adams, et al.               Standards Track                     [Page 6]
+
+RFC 3161               Time-Stamp Protocol (TSP)             August 2001
+
+
+       -- this message contains a warning that a revocation is
+       -- imminent
+      revocationNotification (5)
+       -- notification that a revocation has occurred  }
+
+   Compliant servers SHOULD NOT produce any other values. Compliant
+   clients MUST generate an error if values it does not understand are
+   present.
+
+   When the TimeStampToken is not present, the failInfo indicates the
+   reason why the time-stamp request was rejected and may be one of the
+   following values.
+
+PKIFailureInfo ::= BIT STRING {
+   badAlg               (0),
+     -- unrecognized or unsupported Algorithm Identifier
+   badRequest           (2),
+     -- transaction not permitted or supported
+   badDataFormat        (5),
+     -- the data submitted has the wrong format
+   timeNotAvailable    (14),
+     -- the TSA's time source is not available
+   unacceptedPolicy    (15),
+     -- the requested TSA policy is not supported by the TSA
+   unacceptedExtension (16),
+     -- the requested extension is not supported by the TSA
+    addInfoNotAvailable (17)
+      -- the additional information requested could not be understood
+      -- or is not available
+    systemFailure       (25)
+      -- the request cannot be handled due to system failure  }
+
+   These are the only values of PKIFailureInfo that SHALL be supported.
+
+   Compliant servers SHOULD NOT produce any other values. Compliant
+   clients MUST generate an error if values it does not understand are
+   present.
+
+   The statusString field of PKIStatusInfo MAY be used to include reason
+   text such as "messageImprint field is not correctly formatted".
+
+   A TimeStampToken is as follows.  It is defined as a ContentInfo
+   ([CMS]) and SHALL encapsulate a signed data content type.
+
+   TimeStampToken ::= ContentInfo
+     -- contentType is id-signedData ([CMS])
+     -- content is SignedData ([CMS])
+
+
+
+
+Adams, et al.               Standards Track                     [Page 7]
+
+RFC 3161               Time-Stamp Protocol (TSP)             August 2001
+
+
+   The fields of type EncapsulatedContentInfo of the SignedData
+   construct have the following meanings:
+
+   eContentType is an object identifier that uniquely specifies the
+   content type.  For a time-stamp token it is defined as:
+
+   id-ct-TSTInfo  OBJECT IDENTIFIER ::= { iso(1) member-body(2)
+   us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 4}
+
+   eContent is the content itself, carried as an octet string.
+   The eContent SHALL be the DER-encoded value of TSTInfo.
+
+   The time-stamp token MUST NOT contain any signatures other than the
+   signature of the TSA.  The certificate identifier (ESSCertID) of the
+   TSA certificate MUST be included as a signerInfo attribute inside a
+   SigningCertificate attribute.
+
+TSTInfo ::= SEQUENCE  {
+   version                      INTEGER  { v1(1) },
+   policy                       TSAPolicyId,
+   messageImprint               MessageImprint,
+     -- MUST have the same value as the similar field in
+     -- TimeStampReq
+   serialNumber                 INTEGER,
+    -- Time-Stamping users MUST be ready to accommodate integers
+    -- up to 160 bits.
+   genTime                      GeneralizedTime,
+   accuracy                     Accuracy                 OPTIONAL,
+   ordering                     BOOLEAN             DEFAULT FALSE,
+   nonce                        INTEGER                  OPTIONAL,
+     -- MUST be present if the similar field was present
+     -- in TimeStampReq.  In that case it MUST have the same value.
+   tsa                          [0] GeneralName          OPTIONAL,
+   extensions                   [1] IMPLICIT Extensions   OPTIONAL  }
+
+   The version field (currently v1) describes the version of the time-
+   stamp token.
+
+   Conforming time-stamping servers MUST be able to provide version 1
+   time-stamp tokens.
+
+   Among the optional fields, only the nonce field MUST be supported.
+
+   Conforming time-stamping requesters MUST be able to recognize version
+   1 time-stamp tokens with all the optional fields present, but are not
+   mandated to understand the semantics of any extension, if present.
+
+
+
+
+
+Adams, et al.               Standards Track                     [Page 8]
+
+RFC 3161               Time-Stamp Protocol (TSP)             August 2001
+
+
+   The policy field MUST indicate the TSA's policy under which the
+   response was produced.  If a similar field was present in the
+   TimeStampReq, then it MUST have the same value, otherwise an error
+   (unacceptedPolicy) MUST be returned.  This policy MAY include the
+   following types of information (although this list is certainly not
+   exhaustive):
+
+   *  The conditions under which the time-stamp token may be used.
+
+   *  The availability of a time-stamp token log, to allow later
+      verification that a time-stamp token is authentic.
+
+   The messageImprint MUST have the same value as the similar field in
+   TimeStampReq, provided that the size of the hash value matches the
+   expected size of the hash algorithm identified in hashAlgorithm.
+
+   The serialNumber field is an integer assigned by the TSA to each
+   TimeStampToken.  It MUST be unique for each TimeStampToken issued by
+   a given TSA (i.e., the TSA name and serial number identify a unique
+   TimeStampToken).  It should be noticed that the property MUST be
+   preserved even after a possible interruption (e.g., crash) of the
+   service.
+
+   genTime is the time at which the time-stamp token has been created by
+   the TSA.  It is expressed as UTC time (Coordinated Universal Time) to
+   reduce confusion with the local time zone use.  UTC is a time scale,
+   based on the second (SI), as defined and recommended by the CCIR, and
+   maintained by the Bureau International des Poids et Mesures (BIPM). A
+   synonym is "Zulu" time which is used by the civil aviation and
+   represented by the letter "Z" (phonetically "Zulu").
+
+   The ASN.1 GeneralizedTime syntax can include fraction-of-second
+   details.  Such syntax, without the restrictions from [RFC 2459]
+   Section 4.1.2.5.2, where GeneralizedTime is limited to represent the
+   time with a granularity of one second, may be used here.
+
+   GeneralizedTime values MUST include seconds.  However, when there is
+   no need to have a precision better than the second, then
+   GeneralizedTime with a precision limited to one second SHOULD be used
+   (as in [RFC 2459]).
+
+   The syntax is: YYYYMMDDhhmmss[.s...]Z
+   Example: 19990609001326.34352Z
+
+   X.690 | ISO/IEC 8825-1 provides the following restrictions for a
+   DER-encoding.
+
+
+
+
+
+Adams, et al.               Standards Track                     [Page 9]
+
+RFC 3161               Time-Stamp Protocol (TSP)             August 2001
+
+
+   The encoding MUST terminate with a "Z" (which means "Zulu" time). The
+   decimal point element, if present, MUST be the point option ".". The
+   fractional-seconds elements, if present, MUST omit all trailing 0's;
+   if the elements correspond to 0, they MUST be wholly omitted, and the
+   decimal point element also MUST be omitted.
+
+   Midnight (GMT) shall be represented in the form: "YYYYMMDD000000Z"
+   where "YYYYMMDD" represents the day following the midnight in
+   question.
+
+   Here are a few examples of valid representations:
+
+      "19920521000000Z"
+      "19920622123421Z"
+      "19920722132100.3Z"
+
+   accuracy represents the time deviation around the UTC time contained
+   in GeneralizedTime.
+
+   Accuracy ::= SEQUENCE {
+         seconds        INTEGER              OPTIONAL,
+         millis     [0] INTEGER  (1..999)    OPTIONAL,
+         micros     [1] INTEGER  (1..999)    OPTIONAL  }
+
+   If either seconds, millis or micros is missing, then a value of zero
+   MUST be taken for the missing field.
+
+   By adding the accuracy value to the GeneralizedTime, an upper limit
+   of the time at which the time-stamp token has been created by the TSA
+   can be obtained.  In the same way, by subtracting the accuracy to the
+   GeneralizedTime, a lower limit of the time at which the time-stamp
+   token has been created by the TSA can be obtained.
+
+   accuracy can be decomposed in seconds, milliseconds (between 1-999)
+   and microseconds (1-999), all expressed as integer.
+
+   When the accuracy optional field is not present, then the accuracy
+   may be available through other means, e.g., the TSAPolicyId.
+
+   If the ordering field is missing, or if the ordering field is present
+   and set to false, then the genTime field only indicates the time at
+   which the time-stamp token has been created by the TSA.  In such a
+   case, the ordering of time-stamp tokens issued by the same TSA or
+   different TSAs is only possible when the difference between the
+   genTime of the first time-stamp token and the genTime of the second
+   time-stamp token is greater than the sum of the accuracies of the
+   genTime for each time-stamp token.
+
+
+
+
+Adams, et al.               Standards Track                    [Page 10]
+
+RFC 3161               Time-Stamp Protocol (TSP)             August 2001
+
+
+   If the ordering field is present and set to true, every time-stamp
+   token from the same TSA can always be ordered based on the genTime
+   field, regardless of the genTime accuracy.
+
+   The nonce field MUST be present if it was present in the
+   TimeStampReq. In such a case it MUST equal the value provided in the
+   TimeStampReq structure.
+
+   The purpose of the tsa field is to give a hint in identifying the
+   name of the TSA.  If present, it MUST correspond to one of the
+   subject names included in the certificate that is to be used to
+   verify the token.  However, the actual identification of the entity
+   that signed the response will always occur through the use of the
+   certificate identifier (ESSCertID Attribute) inside a
+   SigningCertificate attribute which is part of the signerInfo (See
+   Section 5 of [ESS]).
+
+   extensions is a generic way to add additional information in the
+   future.  Extensions is defined in [RFC 2459].
+
+   Particular extension field types may be specified in standards or may
+   be defined and registered by any organization or community.
+
+3. Transports
+
+   There is no mandatory transport mechanism for TSA messages in this
+   document.  The mechanisms described below are optional; additional
+   optional mechanisms may be defined in the future.
+
+3.1. Time-Stamp Protocol Using E-mail
+
+   This section specifies a means for conveying ASN.1-encoded messages
+   for the protocol exchanges described in Section 2 and Appendix D via
+   Internet mail.
+
+   Two MIME objects are specified as follows:
+
+   Content-Type: application/timestamp-query
+   Content-Transfer-Encoding: base64
+   <<the ASN.1 DER-encoded Time-Stamp message, base64-encoded>>
+
+   Content-Type: application/timestamp-reply
+   Content-Transfer-Encoding: base64
+   <<the ASN.1 DER-encoded Time-Stamp message, base64-encoded>>
+
+   These MIME objects can be respectively sent and received using common
+   MIME processing engines and provides a simple Internet mail transport
+   for Time-Stamp messages.
+
+
+
+Adams, et al.               Standards Track                    [Page 11]
+
+RFC 3161               Time-Stamp Protocol (TSP)             August 2001
+
+
+   For the application/timestamp-query and application/timestamp-reply
+   MIME types, implementations SHOULD include the optional "name" and
+   "filename" parameters.  Including a file name helps preserve type
+   information when time-stamp queries and replies are saved as files.
+   When these parameters are included, a file name with the appropriate
+   extension SHOULD be selected:
+
+           MIME Type                     File Extension
+      application/timestamp-query            .TSQ
+      application/timestamp-reply            .TSR
+
+   In addition, the file name SHOULD be limited to eight characters
+   followed by a three letter extension.  The eight character filename
+   base can be any distinct name.
+
+3.2. File Based Protocol
+
+   A file containing a time-stamp message MUST contain only the DER
+   encoding of one TSA message, i.e., there MUST be no extraneous header
+   or trailer information in the file.  Such files can be used to
+   transport time stamp messages using for example, FTP.
+
+   A Time-Stamp Request SHOULD be contained in a file with file
+   extension .tsq (like Time-Stamp Query).  A Time-Stamp Response
+   SHOULD be contained in a file with file extension .tsr (like
+   Time-Stamp Reply).
+
+3.3. Socket Based Protocol
+
+   The following simple TCP-based protocol is to be used for transport
+   of TSA messages.  This protocol is suitable for cases where an entity
+   initiates a transaction and can poll to pick up the results.
+
+   The protocol basically assumes a listener process on a TSA that can
+   accept TSA messages on a well-defined port (IP port number 318).
+
+   Typically an initiator binds to this port and submits the initial TSA
+   message.  The responder replies with a TSA message and/or with a
+   reference number to be used later when polling for the actual TSA
+   message response.
+
+   If a number of TSA response messages are to be produced for a given
+   request (say if a receipt must be sent before the actual token can be
+   produced) then a new polling reference is also returned.
+
+   When the final TSA response message has been picked up by the
+   initiator then no new polling reference is supplied.
+
+
+
+
+Adams, et al.               Standards Track                    [Page 12]
+
+RFC 3161               Time-Stamp Protocol (TSP)             August 2001
+
+
+   The initiator of a transaction sends a "direct TCP-based TSA message"
+   to the recipient.  The recipient responds with a similar message.
+
+   A "direct TCP-based TSA message" consists of:
+         length (32-bits), flag (8-bits), value (defined below)
+
+   The length field contains the number of octets of the remainder of
+   the message (i.e., number of octets of "value" plus one).  All 32-bit
+   values in this protocol are specified to be in network byte order.
+
+   Message name   flag     value
+   tsaMsg         '00'H    DER-encoded TSA message
+     -- TSA message
+   pollRep        '01'H    polling reference (32 bits),
+                           time-to-check-back (32 bits)
+     -- poll response where no TSA message response ready; use polling
+     -- reference value (and estimated time value) for later polling
+   pollReq        '02'H    polling reference (32 bits)
+     -- request for a TSA message response to initial message
+   negPollRep     '03'H    '00'H
+     -- no further polling responses (i.e., transaction complete)
+   partialMsgRep  '04'H    next polling reference (32 bits),
+                           time-to-check-back (32 bits),
+                           DER-encoded TSA message
+     -- partial response (receipt) to initial message plus new polling
+     -- reference (and estimated time value) to use to get next part of
+     -- response
+   finalMsgRep    '05'H    DER-encoded TSA message
+     -- final (and possibly sole) response to initial message
+   errorMsgRep    '06'H    human readable error message
+     -- produced when an error is detected (e.g., a polling reference
+     -- is received which doesn't exist or is finished with)
+
+   The sequence of messages that can occur is:
+
+      a) entity sends tsaMsg and receives one of pollRep, negPollRep,
+         partialMsgRep, or finalMsgRep in response.
+
+      b) end entity sends pollReq message and receives one of
+         negPollRep, partialMsgRep, finalMsgRep, or errorMsgRep in
+         response.
+
+   The "time-to-check-back" parameter is an unsigned 32-bit integer. It
+   is the time in seconds indicating the minimum interval after which
+   the client SHOULD check the status again.
+
+   It provides an estimate of the time that the end entity should send
+   its next pollReq.
+
+
+
+Adams, et al.               Standards Track                    [Page 13]
+
+RFC 3161               Time-Stamp Protocol (TSP)             August 2001
+
+
+3.4. Time-Stamp Protocol via HTTP
+
+   This subsection specifies a means for conveying ASN.1-encoded
+   messages for the protocol exchanges described in Section 2 and
+   Appendix D via the HyperText Transfer Protocol.
+
+   Two MIME objects are specified as follows.
+
+   Content-Type: application/timestamp-query
+
+      <<the ASN.1 DER-encoded Time-Stamp Request message>>
+
+   Content-Type: application/timestamp-reply
+
+      <<the ASN.1 DER-encoded Time-Stamp Response message>>
+
+   These MIME objects can be sent and received using common HTTP
+   processing engines over WWW links and provides a simple browser-
+   server transport for Time-Stamp messages.
+
+   Upon receiving a valid request, the server MUST respond with either a
+   valid response with content type application/timestamp-response or
+   with an HTTP error.
+
+4. Security Considerations
+
+   This entire document concerns security considerations.  When
+   designing a TSA service, the following considerations have been
+   identified that have an impact upon the validity or "trust" in the
+   time-stamp token.
+
+   1. When a TSA shall not be used anymore, but the TSA private key has
+      not been compromised, the authority's certificate SHALL be
+      revoked.  When the reasonCode extension relative to the revoked
+      certificate from the TSA is present in the CRL entry extensions,
+      it SHALL be set either to unspecified (0), affiliationChanged (3),
+      superseded (4) or cessationOfOperation (5).  In that case, at any
+      future time, the tokens signed with the corresponding key will be
+      considered as invalid, but tokens generated before the revocation
+      time will remain valid.  When the reasonCode extension relative to
+      the revoked certificate from the TSA is not present in the CRL
+      entry extensions, then all the tokens that have been signed with
+      the corresponding key SHALL be considered as invalid.  For that
+      reason, it is recommended to use the reasonCode extension.
+
+
+
+
+
+
+
+Adams, et al.               Standards Track                    [Page 14]
+
+RFC 3161               Time-Stamp Protocol (TSP)             August 2001
+
+
+   2. When the TSA private key has been compromised, then the
+      corresponding certificate SHALL be revoked.  In that case, the
+      reasonCode extension relative to the revoked certificate from the
+      TSA may or may not be present in the CRL entry extensions.  When
+      it is present then it SHALL be set to keyCompromise (1).  Any
+      token signed by the TSA using that private key cannot be trusted
+      anymore.  For this reason, it is imperative that the TSA's private
+      key be guarded with proper security and controls in order to
+      minimize the possibility of compromise.  In case the private key
+      does become compromised, an audit trail of all tokens generated by
+      the TSA MAY provide a means to discriminate between genuine and
+      false backdated tokens.  Two time-stamp tokens from two different
+      TSAs is another way to address this issue.
+
+   3. The TSA signing key MUST be of a sufficient length to allow for a
+      sufficiently long lifetime.  Even if this is done, the key will
+      have a finite lifetime.  Thus, any token signed by the TSA SHOULD
+      be time-stamped again (if authentic copies of old CRLs are
+      available) or notarized (if they aren't) at a later date to renew
+      the trust that exists in the TSA's signature. time-stamp tokens
+      could also be kept with an Evidence Recording Authority to
+      maintain this trust.
+
+   4. A client application using only a nonce and no local clock SHOULD
+      be concerned about the amount of time it is willing to wait for a
+      response.  A `man-in-the-middle' attack can introduce delays.
+      Thus, any TimeStampResp that takes more than an acceptable period
+      of time SHOULD be considered suspect.  Since each transport method
+      specified in this document has different delay characteristics,
+      the period of time that is considered acceptable will depend upon
+      the particular transport method used, as well as other environment
+      factors.
+
+   5. If different entities obtain time-stamp tokens on the same data
+      object using the same hash algorithm, or a single entity obtains
+      multiple time-stamp tokens on the same object, the generated
+      time-stamp tokens will include identical message imprints; as a
+      result, an observer with access to those time-stamp tokens could
+      infer that the time-stamps may refer to the same underlying data.
+
+
+
+
+
+
+
+
+
+
+
+
+Adams, et al.               Standards Track                    [Page 15]
+
+RFC 3161               Time-Stamp Protocol (TSP)             August 2001
+
+
+   6. Inadvertent or deliberate replays for requests incorporating the
+      same hash algorithm and value may happen.  Inadvertent replays
+      occur when more than one copy of the same request message gets
+      sent to the TSA because of problems in the intervening network
+      elements.  Deliberate replays occur when a middleman is replaying
+      legitimate TS responses.  In order to detect these situations,
+      several techniques may be used.  Using a nonce always allows to
+      detect replays, and hence its use is RECOMMENDED.  Another
+      possibility is to use both a local clock and a moving time window
+      during which the requester remembers all the hashes sent during
+      that time window.  When receiving a response, the requester
+      ensures both that the time of the response is within the time
+      window and that there is only one occurrence of the hash value in
+      that time window.  If the same hash value is present more than
+      once within a time window, the requester may either use a nonce,
+      or wait until the time window has moved to come back to the case
+      where the same hash value appears only once during that time
+      window.
+
+5. Intellectual Property Rights
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to per-
+   tain to the implementation or use of the technology described in this
+   document or the extent to which any license under such rights might
+   or might not be available; neither does it represent that it has made
+   any effort to identify any such rights.  Information on the IETF's
+   procedures with respect to rights in standards-track and standards-
+   related documentation can be found in BCP-11.  Copies of claims of
+   rights made available for publication and any assurances of licenses
+   to be made available, or the result of an attempt made to obtain a
+   general license or permission for the use of such proprietary rights
+   by implementors or users of this specification can be obtained from
+   the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+   The following eight (8) United States Patents related to time
+   stamping, listed in chronological order, are known by the authors to
+   exist at this time.  This may not be an exhaustive list.  Other
+   patents MAY exist or be issued at any time.  This list is provided
+   for informational purposes; to date, the IETF has not been notified
+   of intellectual property rights claimed in regard to any of the
+
+
+
+
+Adams, et al.               Standards Track                    [Page 16]
+
+RFC 3161               Time-Stamp Protocol (TSP)             August 2001
+
+
+   specification contained in this document.  Should this situation
+   change, the current status may be found at the online list of claimed
+   rights (IETF Page of Intellectual Property Rights Notices).
+
+   Implementers of this protocol SHOULD perform their own patent search
+   and determine whether or not any encumbrances exist on their
+   implementation.
+
+   Users of this protocol SHOULD perform their own patent search and
+   determine whether or not any encumbrances exist on the use of this
+   standard.
+
+# 5,001,752 Public/Key Date-Time Notary Facility
+Filing date: October 13, 1989
+Issued: March 19, 1991
+Inventor: Addison M. Fischer
+
+# 5,022,080 Electronic Notary
+Filing date: April 16, 1989
+Issued: June 4, 1991
+Inventors: Robert T. Durst, Kevin D. Hunter
+
+# 5,136,643 Public/Key Date-Time Notary Facility
+Filing date: December 20, 1990
+Issued: August 4, 1992
+Inventor:  Addison M. Fischer
+Note: This is a continuation of patent # 5,001,752.)
+
+# 5,136,646 Digital Document Time-Stamping with Catenate Certificate
+Filing date: August 2, 1990
+Issued: August 4, 1992
+Inventors: Stuart A. Haber, Wakefield S. Stornetta Jr.
+(assignee) Bell Communications Research, Inc.,
+
+# 5,136,647 Method for Secure Time-Stamping of Digital Documents
+Filing date: August 2, 1990
+Issued: August 4, 1992
+Inventors: Stuart A. Haber, Wakefield S. Stornetta Jr.
+(assignee) Bell Communications Research, Inc.,
+
+# 5,373,561 Method of Extending the Validity of a Cryptographic
+Certificate
+Filing date: December 21, 1992
+Issued: December 13, 1994
+Inventors: Stuart A. Haber, Wakefield S. Stornetta Jr.
+(assignee) Bell Communications Research, Inc.,
+
+
+
+
+
+Adams, et al.               Standards Track                    [Page 17]
+
+RFC 3161               Time-Stamp Protocol (TSP)             August 2001
+
+
+# 5,422,953  Personal Date/Time Notary Device
+Filing date: May 5, 1993
+Issued: June 6, 1995
+Inventor: Addison M. Fischer
+
+# 5,781,629 Digital Document Authentication System
+Filing date: February 21, 1997
+Issued: July 14, 1998
+Inventor: Stuart A. Haber, Wakefield S. Stornetta Jr.
+(assignee) Surety Technologies, Inc.,
+
+6. References
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2246]   Dierks, T. and C. Allen, "The TLS Protocol, Version 1.0",
+               RFC 2246, January 1999.
+
+   [RFC2510]   Adams, C. and S. Farrell, "Internet X.509 Public Key
+               Infrastructure, Certificate Management Protocols", RFC
+               2510, March 1999.
+
+   [RFC2459]   Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
+               X.509 Public Key Infrastructure, Certificate and CRL
+               Profile", RFC 2459, January 1999.
+
+   [CMS]       Housley, R., "Cryptographic Message Syntax", RFC 2630,
+               June 1999.
+
+   [DSS]       Digital Signature Standard. FIPS Pub 186. National
+               Institute of Standards and Technology. 19 May 1994.
+
+   [ESS]       Hoffman, P., "Enhanced Security Services for S/MIME", RFC
+               2634, June 1999.
+
+   [ISONR]     ISO/IEC 10181-5:  Security Frameworks in Open Systems.
+               Non-Repudiation Framework. April 1997.
+
+   [MD5]       Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
+               April 1992.
+
+   [SHA1]      Secure Hash Standard. FIPS Pub 180-1. National Institute
+               of Standards and Technology. 17 April 1995.
+
+
+
+
+
+
+
+Adams, et al.               Standards Track                    [Page 18]
+
+RFC 3161               Time-Stamp Protocol (TSP)             August 2001
+
+
+7. Authors' Addresses
+
+   Carlisle Adams
+   Entrust, Inc.
+   1000 Innovation Drive
+   Ottawa, Ontario
+   K2K 3E7
+   CANADA
+
+   EMail: cadams@entrust.com
+
+
+   Pat Cain
+   BBN
+   70 Fawcett Street
+   Cambridge, MA 02138
+   U.S.A.
+
+   EMail: pcain@bbn.com
+
+
+   Denis Pinkas
+   Integris
+   68 route de Versailles
+   B.P. 434
+   78430 Louveciennes
+   FRANCE
+
+   EMail: Denis.Pinkas@bull.net
+
+
+   Robert Zuccherato
+   Entrust, Inc.
+   1000 Innovation Drive
+   Ottawa, Ontario
+   K2K 3E7
+   CANADA
+
+   EMail: robert.zuccherato@entrust.com
+
+
+
+
+
+
+
+
+
+
+
+
+Adams, et al.               Standards Track                    [Page 19]
+
+RFC 3161               Time-Stamp Protocol (TSP)             August 2001
+
+
+APPENDIX A - Signature Time-stamp attribute using CMS
+
+   One of the major uses of time-stamping is to time-stamp a digital
+   signature to prove that the digital signature was created before a
+   given time.  Should the corresponding public key certificate be
+   revoked this allows a verifier to know whether the signature was
+   created before or after the revocation date.
+
+   A sensible place to store a time-stamp is in a [CMS] structure as an
+   unsigned attribute.
+
+   This appendix defines a Signature Time-stamp attribute that may be
+   used to time-stamp a digital signature.
+
+   The following object identifier identifies the Signature Time-stamp
+   attribute:
+
+   id-aa-timeStampToken OBJECT IDENTIFIER ::= { iso(1) member-body(2)
+   us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) aa(2) 14 }
+
+   The Signature time-stamp attribute value has ASN.1 type
+   SignatureTimeStampToken:
+
+   SignatureTimeStampToken ::= TimeStampToken
+
+   The value of messageImprint field within TimeStampToken shall be a
+   hash of the value of signature field within SignerInfo for the
+   signedData being time-stamped.
+
+APPENDIX B - Placing a Signature At a Particular Point in Time
+
+   We present an example of a possible use of this general time-stamping
+   service.  It places a signature at a particular point in time, from
+   which the appropriate certificate status information (e.g., CRLs)
+   MUST be checked.  This application is intended to be used in
+   conjunction with evidence generated using a digital signature
+   mechanism.
+
+   Signatures can only be verified according to a non-repudiation
+   policy. This policy MAY be implicit or explicit (i.e., indicated in
+   the evidence provided by the signer).  The non-repudiation policy can
+   specify, among other things, the time period allowed by a signer to
+   declare the compromise of a signature key used for the generation of
+   digital signatures.  Thus a signature may not be guaranteed to be
+   valid until the termination of this time period.
+
+   To verify a digital signature, the following basic technique may be
+   used:
+
+
+
+Adams, et al.               Standards Track                    [Page 20]
+
+RFC 3161               Time-Stamp Protocol (TSP)             August 2001
+
+
+   A) Time-stamping information needs to be obtained soon after the
+      signature has been produced (e.g., within a few minutes or hours).
+
+      1)    The signature is presented to the Time Stamping Authority
+            (TSA).  The TSA then returns a TimeStampToken (TST) upon
+            that signature.
+
+      2)    The invoker of the service MUST then verify that the
+            TimeStampToken is correct.
+
+   B) The validity of the digital signature may then be verified in the
+      following way:
+
+      1)    The time-stamp token itself MUST be verified and it MUST be
+            verified that it applies to the signature of the signer.
+
+      2)    The date/time indicated by the TSA in the TimeStampToken
+            MUST be retrieved.
+
+      3)    The certificate used by the signer MUST be identified and
+            retrieved.
+
+      4)    The date/time indicated by the TSA MUST be within the
+            validity period of the signer's certificate.
+
+      5)    The revocation information about that certificate, at the
+            date/time of the Time-Stamping operation, MUST be retrieved.
+
+      6)    Should the certificate be revoked, then the date/time of
+            revocation shall be later than the date/time indicated by
+            the TSA.
+
+   If all these conditions are successful, then the digital signature
+   shall be declared as valid.
+
+APPENDIX C: ASN.1 Module using 1988 Syntax
+
+PKIXTSP {iso(1) identified-organization(3) dod(6) internet(1)
+   security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-tsp(13)}
+
+DEFINITIONS IMPLICIT TAGS ::=
+
+BEGIN
+
+-- EXPORTS ALL --
+
+IMPORTS
+
+
+
+
+Adams, et al.               Standards Track                    [Page 21]
+
+RFC 3161               Time-Stamp Protocol (TSP)             August 2001
+
+
+     Extensions, AlgorithmIdentifier
+     FROM PKIX1Explicit88 {iso(1) identified-organization(3)
+     dod(6) internet(1) security(5) mechanisms(5) pkix(7)
+     id-mod(0) id-pkix1-explicit-88(1)}
+
+     GeneralName FROM PKIX1Implicit88 {iso(1)
+     identified-organization(3) dod(6) internet(1) security(5)
+     mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit-88(2)}
+
+     ContentInfo FROM CryptographicMessageSyntax {iso(1)
+     member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
+     smime(16) modules(0) cms(1)}
+
+     PKIFreeText FROM PKIXCMP {iso(1) identified-organization(3)
+     dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
+     id-mod-cmp(9)} ;
+
+                     --  Locally defined OIDs  --
+
+-- eContentType for a time-stamp token
+
+id-ct-TSTInfo  OBJECT IDENTIFIER ::= { iso(1) member-body(2)
+us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 4}
+
+-- 2.4.1
+
+TimeStampReq ::= SEQUENCE  {
+   version                  INTEGER  { v1(1) },
+   messageImprint           MessageImprint,
+     --a hash algorithm OID and the hash value of the data to be
+     --time-stamped
+   reqPolicy                TSAPolicyId                OPTIONAL,
+   nonce                    INTEGER                    OPTIONAL,
+   certReq                  BOOLEAN                    DEFAULT FALSE,
+   extensions               [0] IMPLICIT Extensions    OPTIONAL  }
+
+MessageImprint ::= SEQUENCE  {
+     hashAlgorithm                AlgorithmIdentifier,
+     hashedMessage                OCTET STRING  }
+
+TSAPolicyId ::= OBJECT IDENTIFIER
+
+
+-- 2.4.2
+
+TimeStampResp ::= SEQUENCE  {
+     status                  PKIStatusInfo,
+     timeStampToken          TimeStampToken     OPTIONAL  }
+
+
+
+Adams, et al.               Standards Track                    [Page 22]
+
+RFC 3161               Time-Stamp Protocol (TSP)             August 2001
+
+
+-- The status is based on the definition of status
+-- in section 3.2.3 of [RFC2510]
+
+PKIStatusInfo ::= SEQUENCE {
+    status        PKIStatus,
+    statusString  PKIFreeText     OPTIONAL,
+    failInfo      PKIFailureInfo  OPTIONAL  }
+
+PKIStatus ::= INTEGER {
+    granted                (0),
+    -- when the PKIStatus contains the value zero a TimeStampToken, as
+       requested, is present.
+    grantedWithMods        (1),
+     -- when the PKIStatus contains the value one a TimeStampToken,
+       with modifications, is present.
+    rejection              (2),
+    waiting                (3),
+    revocationWarning      (4),
+     -- this message contains a warning that a revocation is
+     -- imminent
+    revocationNotification (5)
+     -- notification that a revocation has occurred   }
+
+    -- When the TimeStampToken is not present
+    -- failInfo indicates the reason why the
+    -- time-stamp request was rejected and
+    -- may be one of the following values.
+
+PKIFailureInfo ::= BIT STRING {
+    badAlg               (0),
+      -- unrecognized or unsupported Algorithm Identifier
+    badRequest           (2),
+      -- transaction not permitted or supported
+    badDataFormat        (5),
+      -- the data submitted has the wrong format
+    timeNotAvailable    (14),
+      -- the TSA's time source is not available
+    unacceptedPolicy    (15),
+      -- the requested TSA policy is not supported by the TSA.
+    unacceptedExtension (16),
+      -- the requested extension is not supported by the TSA.
+    addInfoNotAvailable (17)
+      -- the additional information requested could not be understood
+      -- or is not available
+    systemFailure       (25)
+      -- the request cannot be handled due to system failure  }
+
+TimeStampToken ::= ContentInfo
+
+
+
+Adams, et al.               Standards Track                    [Page 23]
+
+RFC 3161               Time-Stamp Protocol (TSP)             August 2001
+
+
+     -- contentType is id-signedData as defined in [CMS]
+     -- content is SignedData as defined in([CMS])
+     -- eContentType within SignedData is id-ct-TSTInfo
+     -- eContent within SignedData is TSTInfo
+
+TSTInfo ::= SEQUENCE  {
+    version                      INTEGER  { v1(1) },
+    policy                       TSAPolicyId,
+    messageImprint               MessageImprint,
+      -- MUST have the same value as the similar field in
+      -- TimeStampReq
+    serialNumber                 INTEGER,
+     -- Time-Stamping users MUST be ready to accommodate integers
+     -- up to 160 bits.
+    genTime                      GeneralizedTime,
+    accuracy                     Accuracy                 OPTIONAL,
+    ordering                     BOOLEAN             DEFAULT FALSE,
+    nonce                        INTEGER                  OPTIONAL,
+      -- MUST be present if the similar field was present
+      -- in TimeStampReq.  In that case it MUST have the same value.
+    tsa                          [0] GeneralName          OPTIONAL,
+    extensions                   [1] IMPLICIT Extensions  OPTIONAL   }
+
+Accuracy ::= SEQUENCE {
+                seconds        INTEGER           OPTIONAL,
+                millis     [0] INTEGER  (1..999) OPTIONAL,
+                micros     [1] INTEGER  (1..999) OPTIONAL  }
+
+END
+
+APPENDIX D: Access descriptors for Time-Stamping.
+
+   [This annex describes an extension based on the SIA extension that
+   will be defined in the "son-of-RFC2459".  Since at the time of
+   publication of this document, "son-of-RFC2459" is not yet available,
+   its description is placed in an informative annex.  The contents of
+   this annex will eventually become incorporated into the son-of-
+   RFC2459 document, at which time this annex will no longer be needed.
+   A future version of this document will likely omit this annex and
+   refer to son-of-RFC2459 directly.]
+
+   A TSA's certificate MAY contain a Subject Information Access (SIA)
+   extension (son of RFC2459) in order to convey the method of
+   contacting the TSA.  The accessMethod field in this extension MUST
+   contain the OID id-ad-timestamping:
+
+   The following object identifier identifies the access descriptors for
+   time-Stamping.
+
+
+
+Adams, et al.               Standards Track                    [Page 24]
+
+RFC 3161               Time-Stamp Protocol (TSP)             August 2001
+
+
+   id-ad-timeStamping OBJECT IDENTIFIER ::= {iso(1)
+                         identified-organization(3) dod(6)
+                         internet(1) security(5) mechanisms(5) pkix(7)
+                         ad (48) timestamping (3)}
+
+   The value of the accessLocation field defines the transport (e.g.,
+   HTTP) used to access the TSA and may contain other transport
+   dependent information (e.g., a URL).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Adams, et al.               Standards Track                    [Page 25]
+
+RFC 3161               Time-Stamp Protocol (TSP)             August 2001
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Adams, et al.               Standards Track                    [Page 26]
+