rfc2479.txt

RFC 的详细文档！

Adams                        Informational                     [Page 22]

RFC 2479                      IDUP-GSS-API                 December 1998


2.3.2.3. IDUP_SE major_status codes

   The following major_status return codes are defined for the "SE"
   calls in this section:

   o  GSS_S_COMPLETE
   o  IDUP_S_MORE_OUTBUFFER_NEEDED
      -- returned (by any SE call) to indicate that there is more output
      -- data than can fit into the supplied buffers.  The application
      -- should save the returned data and call again to retrieve the
      -- remaining output.
   o  IDUP_S_MORE_PIDU_NEEDED
      -- indicates that more PIDU data is needed for the StartUnprotect
      -- operation (e.g., so that PIDU_Information or initial_idu_buffer
      -- may be returned).
   o  IDUP_S_INCONSISTENT_PARAMS
   o  GSS_S_CREDENTIALS_EXPIRED
   o  IDUP_S_NO_ENV
   o  GSS_S_BAD_QOP
   o  GSS_S_FAILURE

   If Target_Info is used as an input parameter (e.g., if an encryption
   operation is being performed), the following major_status return code
   is also defined:

   o  IDUP_S_BAD_TARG_INFO

   Note for this return code that if one or more of the targets in
   targ_names cannot be used as a valid recipient of the P-IDU, these
   names will be returned in bad_targ_names (with associated status
   codes in bad_targ_status).  As long as at least one of the targets
   can be used, however, this does not cause this call to fail (i.e.,
   the failure code IDUP_S_BAD_TARG_INFO is not returned); it is the
   caller's choice to discontinue IDU protection if the target set which
   can be used is unsuitable for the caller's purposes.

2.3.2.4. IDUP_SE_SingleBuffer_Protect call

   Inputs:
   o  env_handle ENVIRONMENT HANDLE,
   o  Protect_Options PARAMETER BUNDLE,
   o  Target_Info PARAMETER BUNDLE,
   o  idu_buffer OCTET STRING
   o  additional_protection BOOLEAN
      -- TRUE if idu_buffer is the output of a previous protection
      -- operation (i.e., if this is the second (or higher) in a
      -- series of SE/EV protection calls)




Adams                        Informational                     [Page 23]

RFC 2479                      IDUP-GSS-API                 December 1998


   Outputs:
   o  major_status INTEGER,
   o  minor_status INTEGER,
   o  pidu_buffer OCTET STRING,
   o  sig_token OCTET STRING
      -- used if Protect_Options is clear_sign_only

   Using the security environment referenced by env_handle, encrypt
   and/or sign the supplied IDU.  If "clear signing" is performed, the
   signature will be returned in sig_token and pidu_buffer may be empty
   (depends on underlying mechanism).

2.3.2.5. IDUP_SE_SingleBuffer_Unprotect call

   Inputs:
   o  env_handle ENVIRONMENT HANDLE,
   o  pidu_buffer OCTET STRING,
      -- may contain an IDU if sig_token is non-NULL (i.e., if
      -- clear_sign_only protection was applied)
   o  sig_token OCTET STRING

   Outputs:
   o  major_status INTEGER,
   o  minor_status INTEGER,
   o  idu_buffer OCTET STRING,
      -- may be empty if clear_sign_only protection was applied (depends
      -- on underlying mechanism)
   o  PIDU_Information PARAMETER BUNDLE
   o  additional_unprotection BOOLEAN
      -- TRUE if idu_buffer should be input to another unprotection
      -- operation (i.e., if this should not be the last in a series
      -- of SE/EV unprotection calls)

   Using the security environment referenced by env_handle, decrypt
   and/or verify the supplied PIDU and return the contained IDU along
   with all available PIDU_Information.

2.3.2.6. IDUP_SE_MultiBuffer_StartProtect call

   Inputs:
   o  env_handle ENVIRONMENT HANDLE,
   o  Protect_Options PARAMETER BUNDLE,
   o  Target_Info PARAMETER BUNDLE,
   o  additional_protection BOOLEAN, -- (see Section 2.3.2.4)
   o  idu_size INTEGER               -- (see Section 2.3.4.2)






Adams                        Informational                     [Page 24]

RFC 2479                      IDUP-GSS-API                 December 1998


   Outputs:
   o  major_status INTEGER,
   o  minor_status INTEGER,
   o  initial_pidu_buffer OCTET STRING
      -- may be empty (depends on underlying mechanism)

   Using the security environment referenced by env_handle, initialize
   the data structures required to begin the process of signing and/or
   encrypting the IDU (which will be supplied in multiple buffers to the
   Process_Buffer call).

2.3.2.7. IDUP_SE_MultiBuffer_EndProtect call

   Inputs:
   o  env_handle ENVIRONMENT HANDLE

   Outputs:
   o  major_status INTEGER,
   o  minor_status INTEGER,
   o  final_pidu_buffer OCTET STRING,
   o  sig_token OCTET STRING
      -- used if Protect_Options was clear_sign_only

   Using the security environment referenced by env_handle, complete the
   protection processing on the data and place the computed output in
   final_pidu_buffer and/or sig_token. Successful application of
   IDUP_SE_MultiBuffer_EndProtect() does not guarantee that unprotection
   can necessarily be performed successfully when the P-IDU arrives at
   the target (for example, it may be damaged in transit).

2.3.2.8. IDUP_SE_MultiBuffer_StartUnprotect call

   Inputs:
   o  env_handle ENVIRONMENT HANDLE,
   o  initial_pidu_buffer OCTET STRING,
   o  sign_qop_alg_in UNSIGNED INTEGER,
      -- used if Protect_Options was clear_sign_only (and calling
      -- application has prior knowledge of signing alg. applied);
      -- if NULL, then sig_token must be supplied
   o  sig_token OCTET STRING
      -- used if Protect_Options was clear_sign_only;
      -- if NULL, then sign_qop_alg_in must be supplied

   Outputs:
   o  major_status INTEGER,
   o  minor_status INTEGER,
   o  PIDU_Information PARAMETER BUNDLE,
      -- returns all available information



Adams                        Informational                     [Page 25]

RFC 2479                      IDUP-GSS-API                 December 1998


   o  initial_idu_buffer OCTET STRING
      -- may be empty

   Using the security environment referenced by env_handle, initialize
   the data structures required to begin the process of decrypting
   and/or verifying the PIDU (which will be supplied in multiple buffers
   to the Process_Buffer call).

   The parameters sign_qop_alg_in and sig_token should not both be
   supplied (i.e., they should not both be non-NULL).  If they are both
   non-NULL, however, sig_token is taken to be authoritative since this
   is the token created at protection time and therefore is guaranteed
   to carry the information needed to unprotect.

2.3.2.9. IDUP_SE_MultiBuffer_EndUnprotect call

   Inputs:
   o  env_handle ENVIRONMENT HANDLE,
   o  sig_token OCTET STRING  OPTIONAL
      -- used if Protect_Options was clear_sign_only and sig_token was
      -- not available when StartUnprotect was called

   Outputs:
   o  major_status INTEGER,
   o  minor_status INTEGER,
   o  PIDU_Information PARAMETER BUNDLE,
      -- returns all available information
   o  final_idu_buffer OCTET STRING   -- may be empty
   o  additional_unprotection BOOLEAN -- (see Section 2.3.2.5)

   Using the security environment referenced by env_handle, complete the
   decryption and/or verification processing on the data and place any
   residual output in final_idu_buffer.

2.3.2.10. IDUP_SE_Process_Buffer call

   Inputs:
   o  env_handle ENVIRONMENT HANDLE,
   o  input_buffer OCTET STRING,

   Outputs:
   o  major_status INTEGER,
   o  minor_status INTEGER,
   o  output_buffer OCTET STRING
      -- may be zero length (depends on underlying mechanism and
      -- corresponding Start() call and Protect_Options value)





Adams                        Informational                     [Page 26]

RFC 2479                      IDUP-GSS-API                 December 1998


   Using the security environment referenced by env_handle, continue the
   processing on the data in input_buffer and, if it is available, put
   any resulting output data in output_buffer.  The application calls
   this routine over and over again with new buffers of data until it
   has processed all the data buffers of the IDU/PIDU. It then calls the
   appropriate End() call to complete the processing.

2.3.3.  The "EV" Calls

2.3.3.1. IDUP_EV Purpose

   The "EV" group of calls provides a simple, high-level interface to
   underlying IDUP mechanisms when application developers need to deal
   only with evidence but not with encryption or integrity services. It
   includes both the single-buffer and multiple-buffer IDU cases and can
   be used for the generation and verification of evidence tokens
   embodying several different types of evidences.

   The following list of evidence types is supported. This list is by no
   means exhaustive and it is anticipated that it may be extended in
   future versions of this specification.

      "Non-repudiation of Origin" prevents a message creator's false
      denial of creating and sending a message.

      "Non-repudiation of Creation" prevents a message creator's false
      denial of creating a message.

      "Non-repudiation of Sender" prevents a message creator's false
      denial of sending a message (that was not necessarily created by
      the sender).

      "Non-repudiation of Delivery" prevents a message recipient's false
      denial of having received and looked at the content of a message.

      "Non-repudiation of Receipt" prevents a message recipient's false
      denial of having received a message (whose content was not
      necessarily looked at by the recipient).

      "Non-repudiation of Approval" prevents a message recipient's false
      denial of having approved the content of a received message.

   An evidence is provided in the form of a evidence token. Two forms of
   evidence tokens are supported:

      o  Tokens including the associated data,





Adams                        Informational                     [Page 27]

RFC 2479                      IDUP-GSS-API                 December 1998


      o  Tokens without included data (but with a unique reference to
         the associated data).

   Evidence tokens may be freely distributed. Any possessor of an
   evidence token (and of the associated data, if not included in the
   token) can verify the evidence if it has the appropriate credentials
   which include the definition of security policies (i.e., keys alone
   do not permit the verification of evidence tokens). Any holder of an
   evidence token may store it (along with the associated data, if not
   included in the token) for later verification.

   Calls that are specific to the support of evidence include:

   * Generate_token, which generates a non-repudiation token using the
     current environment. The generated token may consist of:

      1 - an evidence token
      2 - a token containing a request for an evidence, which carries
          information describing which evidence type should be generated
          by the recipient(s) and sent back to