rfc2479.txt

RFC 的详细文档！

   environment if the service set provided is unsuitable for the
   caller's use.  The returned mech_type value indicates the specific
   mechanism employed in the environment and will never indicate the
   value for "default".

   The following OBJECT IDs are defined for protection and unprotection
   services (the OBJECT ID iso.org.dod.internet.security.services,
   1.3.6.1.5.7, has been assigned by IANA, and some of the security
   services under that node are assigned as shown below).  It is
   recognized that this list may grow over time.

      PER_CONF = { 1.3.6.1.5.7.1.1 }
         -- perform data confidentiality (i.e., encrypt data)
      PER_CONF_FULL = { 1.3.6.1.5.7.1.3 }
         -- perform full confidentiality (i.e., encrypt data and sig)
         -- (may be used only when PER_DOA is requested simultaneously)
      PER_DOA  = { 1.3.6.1.5.7.3.1 }
         -- perform data origin authentication with data integrity
      PER_DOA_CIPH  = { 1.3.6.1.5.7.3.3 }
         -- perform DOA with DI over ciphertext (rather than plaintext)
         -- (may be used only when PER_CONF is requested simultaneously)
      PER_POO  = { 1.3.6.1.5.7.4.1 }
         -- perform (i.e., create) non-repudiable "proof of origin"
      PER_POD  = { 1.3.6.1.5.7.4.3 }
         -- perform (i.e., create) non-repudiable "proof of delivery"




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


      REC_CONF = { 1.3.6.1.5.7.1.2 }
         -- receive data confidentiality (i.e., decrypt data)
      REC_CONF_FULL = { 1.3.6.1.5.7.1.4 }
         -- receive full confidentiality (i.e., decrypt data and sig)
         -- (may be used only when REC_DOA is received simultaneously)
      REC_DOA  = { 1.3.6.1.5.7.3.2 }
         -- receive / verify DOA with data integrity
      REC_DOA_CIPH  = { 1.3.6.1.5.7.3.4 }
         -- verify DOA with DI over ciphertext (rather than plaintext)
         -- (may be used only when PER_CONF is received simultaneously)
      REC_POO  = { 1.3.6.1.5.7.4.2 }
         -- receive / verify "proof of origin"
      REC_POD  = { 1.3.6.1.5.7.4.4 }
         -- receive / verify "proof of delivery"
      TTIME    = { 1.3.6.1.5.7.7.1 }
         -- trusted time availability
      UTIME    = { 1.3.6.1.5.7.7.2 }
         -- untrusted time availability

   The PER_CONF return value (in the ret_services paramater) indicates
   whether the environment supports confidentiality services, and so
   informs the caller whether or not a request for encryption can be
   honored.  In similar fashion, the PER_DOA return value indicates
   whether DOA services are available in the established environment,
   and the PER_POO and PER_POD return values indicate whether evidence
   generation services are available.  The TTIME and UTIME values
   indicate whether trusted time and untrusted time are available for
   protection / unprotection services.

   Note that, unlike a GSS "context", an IDUP environment does not have
   an explicit lifetime associated with it.  Instead, it relies on the
   lifetime of the calling entity's credential (set by the caller in the
   GSS_Acquire_cred() call).  When the credential expires (or is
   explicitly deleted in any other way), no new operations are allowed
   in the IDUP environment (although operations which have begun, such
   as the Protection set of calls, can be taken to completion).















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


2.2.3. IDUP_Abolish_Env call

   Input:
   o  env_handle ENVIRONMENT HANDLE

   Outputs:
   o  major_status INTEGER,
   o  minor_status INTEGER,

   Return major_status codes:
   o  GSS_S_COMPLETE
      -- the relevant environment-specific information was flushed.
   o  IDUP_S_NO_ENV
   o  GSS_S_FAILURE

   This call is made to flush environment-specific information. (Once an
   environment is established, cached credential and environment-related
   info. is expected to be retained until an IDUP_Abolish_Env() call is
   made or until the cred. lifetime expires.)  Attempts to perform IDU
   processing on a deleted environment will result in error returns.

2.2.4. IDUP_Inquire_Env call

   Input:
   o  env_handle ENVIRONMENT HANDLE,

   Outputs:
   o  major_status INTEGER,
   o  minor_status INTEGER,
   o  mech_type OBJECT IDENTIFIER,
      -- the mechanism supporting this environment
   o  environmentPolicies EnvironmentPolicies,
      -- the environment policies in effect
   o  ret_services SET OF OBJECT IDENTIFIER,

   Return major_status codes:
   o  GSS_S_COMPLETE
      -- referenced environment is valid and mech_type and other return
      -- values describe the characteristics of the environment.
   o  GSS_S_CREDENTIALS_EXPIRED
   o  IDUP_S_NO_ENV
   o  GSS_S_FAILURE

   This routine provides environment-related information to the caller.







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


2.3.  Per-IDU calls

   This group of calls is used to perform IDU protection and
   unprotection processing on an established IDUP environment. Some of
   these calls may block pending network interactions (depending on the
   underlying mechanism in use).  These calls may be invoked by an IDU's
   protector or by the P-IDU's recipient.  Members of this group form
   pairs; the output from the protection types of calls is typically
   meant to be input to the unprotection types of calls.

   The per-IDU calls can support caller-requested data origin
   authentication with data integrity, confidentiality with data
   integrity, evidence, and evidence-requested-from-target services.

   The protection operations output a token which encapsulates all the
   information required to unprotect the IDU.  The token is passed to
   the target (possibly separate from the M-IDU) and is processed by the
   unprotection calls at that system.  Unprotection performs
   decipherment, DOA verification, evidence verification, or
   notification of evidence requested, as required.

   Each of the two main operations (protection and unprotection) may be
   separated into three parts:  "Start_Operation"; "Operation" (which
   may be called once for each buffer of input data); and
   "End_Operation".  This separation is available for the case where the
   IDU or P-IDU is to be processed one buffer at a time.
   "Start_Operation" allows the caller to specify or retrieve the
   appropriate "Quality" used during the processing.  "Operation" is
   concerned with the processing itself, receiving a buffer of input
   data and potentially returning a buffer of output data.
   "End_Operation" performs any required clean-up and creates the
   appropriate token or states whether the input token was verified.

   If the IDU or P-IDU is wholly contained in a single buffer, the
   three-part protection/unprotection processing need not be done.
   Instead, protection or unprotection can be accomplished using only a
   single call, simplifying application code.

2.3.1.  Relationship to GSS-API

   The set of calls described in this section is used in place of the
   calls GSS_GetMIC(), GSS_VerifyMIC, GSS_Wrap(), and GSS_Unwrap() which
   are specified in [RFC-2078], since those calls are specific to a
   session-oriented environment.







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


2.3.2.  The "SE" Calls

2.3.2.1. IDUP_SE Purpose

   The "SE" group of calls provides a very simple, high-level interface
   to underlying IDUP mechanisms when application developers need access
   only to signature and encryption protection/unprotection services.
   It includes both the single-buffer and multiple-buffer IDU cases and
   can be used for signing only, encrypting only, signing and encrypting
   (in either order, and with or without visibility of the resulting
   signature), and "clear signing" (where the data is not modified in
   any way and the signature itself is returned as a separate item).
   [Note that encapsulation occurs in all cases except for clear
   signing, so that these calls provide functionality similar to the
   GSS_Wrap call.]

   Note that the term "signing" is used in its most generic sense, not
   necessarily implying the use of public-key techniques.  This concept
   has also been called "sealing" in other contexts (e.g., in other
   standardization efforts).

   The SE calls may be viewed by mechanism implementors as an "API" to
   the more powerful GP calls defined later and so may be implemented as
   simple mapping functions to those calls (when those optional calls
   are supported).  Application callers, on the other hand, may find
   that the SE calls are all they currently need for many environments.
   At some time in the future when they have need of non-repudiation or
   "directed receipts" types of services, they may consider using the EV
   calls (or the GP calls -- when these are supported -- if complex and
   sophisticated combinations of services are required).  To assist in
   this migration path, mechanism implementors are encouraged to support
   the full set of IDUP calls (i.e., the SE, EV, and GP calls) even
   though some calling applications will only use the SE calls in the
   short term.

2.3.2.2. IDUP_SE Parameter Bundles

   The concept of "parameter bundles" is used in the calls presented in
   the following subsections in order to simplify their presentation and
   clarify their intended purpose and use.  See Section 2.3.4.1 for a
   more complete description of parameter bundles.

   The following parameter bundles are used in the "SE" protection and
   unprotection sets of calls.







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


   o  Protect_Options PARAMETER BUNDLE
      o  protect_operation  INTEGER {
            sign_only              (0),
            encrypt_only           (1),
            sign_and_encrypt       (2),
            -- let mechanism choose order (and readability of signature)
            sign_then_encrypt_data (3),
            -- sign, then encrypt plaintext (leaving signature in clear)
            sign_then_encrypt_full (4),
            -- sign, then encrypt everything (including signature)
            encrypt_then_sign      (5),
            -- encrypt, then sign the ciphertext
            clear_sign_only        (6)
         } OPTIONAL,
      o  protect_oper_oid   OBJECT IDENTIFIER OPTIONAL,
         -- may be used in place of above parameter if OID is known
      o  sign_qop_alg      UNSIGNED INTEGER,
      o  sign_qop_algID    AlgorithmIdentifier, --overrides sign_qop_alg
      o  enc_qop_alg       UNSIGNED INTEGER,
      o  enc_qop_algID     AlgorithmIdentifier, --overrides enc_qop_alg
      o  idu_type_string    OCTET STRING,
         -- type of the IDU ("data", "e-mail doc", MIME type, etc.)
      o  pidu_type_string   OCTET STRING,
      o  mech_indep_encap_req BOOLEAN -- (see Appendix A)

   o  PIDU_Information PARAMETER BUNDLE
      o  protect_options    Protect_Options,
      o  originator_name    INTERNAL NAME,
      o  originator_role    Originator_Role, -- (see Section 2.3.4.1)
      o  protection_time    INTEGER,
   o  Bad_Target_Name PARAMETER BUNDLE,  -- same as in Section 2.3.3.2
      o  bad_targ_name     INTERNAL NAME,
      o  bad_targ_status   INTEGER,
         -- a status flag giving the reason for rejection of the name
         -- in bad_targ_name.  Specified reasons include:
         --  SYNTAX_INVALID        (0) the syntax of the name is invalid;
         --  NAME_UNRECOGNIZED     (1) the name is not recognized;
         --  NAME_AMBIGUOUS        (2) the name cannot be resolved;
         --  ACCESS_DENIED         (3) access to this target is denied;
         --  CERTIFICATE_NOT_FOUND (4) the encryption certificate of the
                                      target could not be found.

   o  Target_Info PARAMETER BUNDLE,      -- same as in Section 2.3.3.2
      o  targ_names        SET OF INTERNAL NAME,
      o  bad_targ_count    INTEGER,
      o  bad_target_names  SET OF Bad_Target_Name,