draft-ietf-pkix-rfc3161bis-00.txt

PKIX的RFC英文文档

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 TSU's time source is not available
   unacceptedPolicy    (15),
     -- the requested TSA policy is not supported by the TSU
   unacceptedExtension (16),
     -- the requested extension is not supported by the TSU
    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])

   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 TSU.  The certificate identifier (ESSCertID) of the
   TSU certificate MUST be included as a signerInfo attribute inside a
   SigningCertificate attribute.



Adams, et al.               Standards Track                     [Page 7

RFC 3161-bis           Time-Stamp Protocol (TSP)              April 2002


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.

   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 TSU to each
   TimeStampToken.  It MUST be unique for each TimeStampToken issued by
   a given TSU (i.e., the TSU 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.


Adams, et al.               Standards Track                     [Page 8

RFC 3161-bis           Time-Stamp Protocol (TSP)              April 2002


   genTime is the time at which the time-stamp token has been created by
   the TSU.  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.

   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.




Adams, et al.               Standards Track                     [Page 9

RFC 3161-bis           Time-Stamp Protocol (TSP)              April 2002


   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 TSU
   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 TSU 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 TSU.  In such a
   case, the ordering of time-stamp tokens issued by the same TSU or
   different TSUs 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.

   If the ordering field is present and set to true, every time-stamp
   token from the same TSU 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 TSU.  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 TSU 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

Adams, et al.               Standards Track                    [Page 10

RFC 3161-bis           Time-Stamp Protocol (TSP)              April 2002


   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.

   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 TSU 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 TSU 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 TSU that can
   accept TSU messages on a well-defined port (IP port number 318).


Adams, et al.               Standards Track                    [Page 11

RFC 3161-bis           Time-Stamp Protocol (TSP)              April 2002


   Typically an initiator binds to this port and submits the initial TSU

   message.  The responder replies with a TSU message and/or with a
   reference number to be used later when polling for the actual TSU
   message response.

   If a number of TSU 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 TSU response message has been picked up by the
   initiator then no new polling reference is supplied.

   The initiator of a transaction sends a "direct TCP-based TSU message"
   to the recipient.  The recipient responds with a similar message.

   A "direct TCP-based TSU 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 TSU message
     -- TSU message
   pollRep        '01'H    polling reference (32 bits),
                           time-to-check-back (32 bits)
     -- poll response where no TSU message response ready; use polling
     -- reference value (and estimated time value) for later polling
   pollReq        '02'H    polling reference (32 bits)
     -- request for a TSU 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 TSU 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 TSU 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.

Adams, et al.               Standards Track                    [Page 12

RFC 3161-bis           Time-Stamp Protocol (TSP)              April 2002