$ token restore
      (I) A token management operation that loads a security token with
      data for the purpose of recreating (duplicating) the contents
      previously held by that or another token. (See: recovery.)

   $ token storage key
      (I) A cryptographic key used to protect data that is stored on a
      security token.

   $ top CA
      (I) Synonym for "root" in a certification hierarchy. (See: apex
      trust anchor.)

   $ top-level specification
      (I) "A non-procedural description of system behavior at the most
      abstract level; typically a functional specification that omits
      all implementation details." [NCS04] (See: formal top-level
      specification, Tutorial under "security policy".)

      Tutorial: A top-level specification is at a level of abstraction
      below "security model" and above "security architecture" (see:
      Tutorial under "security policy").

      A top-level specification may be descriptive or formal:
      -  "Descriptive top-level specification": One that is written in a
         natural language like English or an informal design notation.
      -  "Formal top-level specification": One that is written in a
         formal mathematical language to enable theorems to be proven
         that show that the specification correctly implements a set of
         formal requirements or a formal security model. (See:
         correctness proof.)

   $ TPM
      (N) See: Trusted Platform Module.

   $ traceback
      (I) Identification of the source of a data packet. (See:
      masquerade, network weaving.)

   $ tracker
      (N) An attack technique for achieving unauthorized disclosure from
      a statistical database. [Denns] (See: Tutorial under "inference
      control".)

   $ traffic analysis
      1. (I) Gaining knowledge of information by inference from
      observable characteristics of a data flow, even if the information
      is not directly available (e.g., when the data is encrypted).

      These characteristics include the identities and locations of the
      source(s) and destination(s) of the flow, and the flow's presence,
      amount, frequency, and duration of occurrence. The object of the
      analysis might be information in SDUs, information in the PCI, or
      both. (See: inference, traffic-flow confidentiality, wiretapping.
      Compare: signal analysis.)

      2. (O) "The inference of information from observation of traffic
      flows (presence, absence, amount, direction, and frequency)."
      [I7498-2]

   $ traffic-flow analysis
      (I) Synonym for "traffic analysis".

   $ traffic-flow confidentiality (TFC)
      1. (I) A data confidentiality service to protect against traffic
      analysis. (See: communications cover.)

      2. (O) "A confidentiality service to protect against traffic
      analysis." [I7498-2]

      Tutorial: Confidentiality concerns involve both direct and
      indirect disclosure of data, and the latter includes traffic
      analysis. However, operational considerations can make TFC
      difficult to achieve. For example, if Alice sends a product idea
      to Bob in an email message, she wants data confidentiality for the
      message's content, and she might also want to conceal the
      destination of the message to hide Bob's identity from her
      competitors. However, the identity of the intended recipient, or
      at least a network address for that recipient, needs to be made
      available to the mail system. Thus, complex forwarding schemes may
      be needed to conceal the ultimate destination as the message
      travels through the open Internet (see: onion routing).

      Later, if Alice uses an ATM during a clandestine visit to
      negotiate with Bob, she might prefer that her bank conceal the
      origin of her transaction, because knowledge of the ATM's location
      might allow a competitor to infer Bob's identity. The bank, on the
      other hand, might prefer to protect only Alice's PIN (see:
      selective-field confidentiality).

      A TFC service can be either full or partial:
      -  "Full TFC": This type of service conceals all traffic
         characteristics.
      -  "Partial TFC": This type of service either (a) conceals some
         but not all of the characteristics or (b) does not completely
         conceal some characteristic.

      On point-to-point data links, full TFC can be provided by
      enciphering all PDUs and also generating a continuous, random data
      stream to seamlessly fill all gaps between PDUs. To a wiretapper,
      the link then appears to be carrying an unbroken stream of
      enciphered data. In other cases -- including on a shared or
      broadcast medium, or end-to-end in a network -- only partial TFC
      is possible, and that may require a combination of techniques. For
      example, a LAN that uses "carrier sense multiple access with
      collision detection" (CSMA/CD; a.k.a. "listen while talk") to
      control access to the medium, relies on detecting intervals of
      silence, which prevents using full TFC. Partial TFC can be
      provided on that LAN by measures such as adding spurious PDUs,
      padding PDUs to a constant size, or enciphering addresses just
      above the Physical Layer; but these measures reduce the efficiency
      with which the LAN can carry traffic. At higher protocol layers,
      SDUs can be protected, but addresses and other items of PCI must
      be visible at the layers below.

   $ traffic key
      (I) A cryptographic key used by a device for protecting
      information that is being transmitted between devices, as opposed
      to protecting information that being is maintained in the device.
      (Compare: storage key.)

   $ traffic padding
      (I) "The generation of spurious instances of communication,
      spurious data units, and/or spurious data within data units."
      [I7498-2]

   $ tranquility property
      (N) /formal model/ Property of a system whereby the security level
      of an object cannot change while the object is being processed by
      the system. (See: Bell-LaPadula model.)

   $ transaction
      1. (I) A unit of interaction between an external entity and a
      system, or between components within a system, that involves a
      series of system actions or events.

      2. (O) "A discrete event between user and systems that supports a
      business or programmatic purpose." [M0404]

      Tutorial: To maintain secure state, transactions need to be
      processed coherently and reliably. Usually, they need to be
      designed to be atomic, consistent, isolated, and durable [Gray]:
      -  "Atomic": All actions and events that comprise the transaction
         are guaranteed to be completed successfully, or else the result
         is as if none at all were executed.

      -  "Consistent": The transaction satisfies correctness constraints
         defined for the data that is being processed.
      -  "Isolated": If two transactions are performed concurrently,
         they do not interfere with each other, and it appears as though
         the system performs one at a time.
      -  "Durable": System state and transaction semantics survive
         system failures.

   $ TRANSEC
      (I) See: transmission security.

   $ Transmission Control Code field (TCC field)
      (I) A data field that provides a means to segregate traffic and
      define controlled communities of interest in the security option
      (option type = 130) of IPv4's datagram header format. The TCC
      values are alphanumeric trigraphs assigned by the U.S. Government
      as specified in RFC 791.

   $ Transmission Control Protocol (TCP)
      (I) An Internet Standard, Transport-Layer protocol (RFC 793) that
      reliably delivers a sequence of datagrams from one computer to
      another in a computer network. (See: TCP/IP.)

      Tutorial: TCP is designed to fit into a layered suite of protocols
      that support internetwork applications. TCP assumes it can obtain
      a simple but potentially unreliable end-to-end datagram service
      (such as IP) from the lower-layer protocols.

   $ transmission security (TRANSEC)
      (I) COMSEC measures that protect communications from interception
      and exploitation by means other than cryptanalysis. Example:
      frequency hopping. (Compare: anti-jam, traffic flow
      confidentiality.)

   $ Transport Layer
      See: Internet Protocol Suite, OSIRM.

   $ Transport Layer Security (TLS)
      (I) TLS is an Internet protocol [R4346] that is based on, and very
      similar to, SSL Version 3.0. (Compare: TLSP.)

      Tutorial: The TLS protocol is misnamed. The name misleadingly
      suggests that TLS is situated in the IPS Transport Layer, but TLS
      is always layered above a reliable Transport-Layer protocol
      (usually TCP) and either layered immediately below or integrated
      with an Application-Layer protocol (often HTTP).

   $ Transport Layer Security Protocol (TLSP)
      (N) An end-to-end encryption protocol (ISO 10736) that provides
      security services at the bottom of OSIRM Layer 4, i.e., directly
      above Layer 3. (Compare: TLS.)

      Tutorial: TLSP evolved directly from SP4.

   $ transport mode
      (I) One of two ways to apply AH or ESP to protect data packets; in
      this mode, the IPsec protocol encapsulates (i.e., the protection
      applies to) the packets of an IPS Transport-Layer protocol (e.g.,
      TCP, UDP), which normally is carried directly above IP in an IPS
      protocol stack. (Compare: tunnel mode.)

      Tutorial: An IPsec transport-mode security association is always
      between two hosts; neither end has the role of a security gateway.
      Whenever either end of an IPsec security association is a security
      gateway, the association is required to be in tunnel mode.

   $ transposition
      (I) /cryptography/ A method of encryption in which elements of the
      plain text retain their original form but undergo some change in
      their sequential position. (Compare: substitution.)

   $ trap door
      (I) Synonym for "back door".

   $ trespass
      (I) /threat action/ See: secondary definition under "intrusion".

   $ Triple Data Encryption Algorithm
      (I) A block cipher that transforms each 64-bit plaintext block by
      applying the DEA three successive times, using either two or three
      different keys for an effective key length of 112 or 168 bits.
      [A9052, SP67]

      Example: A variation proposed for IPsec's ESP uses a 168-bit key,
      consisting of three independent 56-bit values used by the DEA, and
      a 64-bit initialization vector. Each datagram contains an IV to
      ensure that each received datagram can be decrypted even when
      other datagrams are dropped or a sequence of datagrams is
      reordered in transit. [R1851]

   $ triple-wrapped
      (I) /S-MIME/ Data that has been signed with a digital signature,
      then encrypted, and then signed again. [R2634]

   $ Trojan horse
      (I) A computer program that appears to have a useful function, but
      also has a hidden and potentially malicious function that evades
      security mechanisms, sometimes by exploiting legitimate
      authorizations of a system entity that invokes the program. (See:
      malware, spyware. Compare: logic bomb, virus, worm.)

   $ trust
      1. (I) /information system/ A feeling of certainty (sometimes
      based on inconclusive evidence) either (a) that the system will
      not fail or (b) that the system meets its specifications (i.e.,
      the system does what it claims to do and does not perform unwanted
      functions). (See: trust level, trusted system, trustworthy system.
      Compare: assurance.)

      Tutorial: Components of a system can be grouped into three classes
      of trust [Gass]:
      -  "Trusted": The component is responsible for enforcing security
         policy on other components; the system's security depends on
         flawless operation of the component. (See: trusted process.)
      -  "Benign": The component is not responsible for enforcing
         security policy, but it has sensitive authorizations. It must
         be trusted not to intentionally violate security policy, but
         security violations are assumed to be accidental and not likely
         to affect overall system security.
      -  "Untrusted": The component is of unknown or suspicious
         provenance and must be treated as deliberately malicious. (See:
         malicious logic.)

      2. (I) /PKI/ A relationship between a certificate user and a CA in
      which the user acts according to the assumption that the CA
      creates only valid digital certificates.

      Tutorial: "Generally, an entity is said to 'trust' a second entity
      when the first entity makes the assumption that the second entity
      will behave exactly as the first entity expects. This trust may
      apply only for some specific function. The key role of trust in
      [X.509] is to describe the relationship between an entity [i.e., a
      certificate user] and a [CA]; an entity shall be certain that it
      can trust the CA to create only valid and reliable certificates."
      [X509]

   $ trust anchor
      (I) /PKI/ An established point of trust (usually based on the
      authority of some person, office, or organization) from which a
      certificate user begins the validation of a certification path.
      (See: apex trust anchor, path validation, trust anchor CA, trust
      anchor certificate, trust anchor key.)

      Usage: IDOCs that use this term SHOULD state a definition for it
      because it is used in various ways in existing IDOCs and other PKI
      literature. The literature almost always uses this term in a sense
      that is equivalent to this definition, but usage often differs
      with regard to what constitutes the point of trust.

      Tutorial: A trust anchor may be defined as being based on a public
      key, a CA, a public-key certificate, or some combination or
      variation of those:

      -  1. A public key as a point of trust: Although a certification
         path is defined as beginning with a "sequence of public-key
         certificates", an implementation of a path validation process
         might not explicitly handle a root certificate as part of the
         path, but instead begin the process by using a trusted root key
         to verify the signature on a certificate that was issued by the
         root.

         Therefore, "trust anchor" is sometimes defined as just a public
         key. (See: root key, trust anchor key, trusted key.)

      -  2. A CA as a point of trust: A trusted public key is just one
         of the data elements needed for path validation; the IPS path
         validation algorithm [R3280] also needs the name of the CA to
         which that key belongs, i.e., the DN of the issuer of the first
         X.509 certificate to be validated on the path. (See: issue.)

         Therefore, "trust anchor" is sometimes defined as either just a
         CA (where some public key is implied) or as a CA together with
         a specified public key belonging to that CA. (See: root, trust
         anchor CA, trusted CA.)

         Example: "A public key and the name of a [CA] that is used to
         validate the first certificate in a sequence of certificates.
         The trust anchor public key is used to verify the signature on
         a certificate issued by a trust anchor [CA]." [SP57]

      -  3. A public-key certificate as a point of trust: Besides the
         trusted CA's public key and name, the path validation algorithm
         needs to know the digital signature algorithm and any
         associated parameters with which the public key is used, and
         also any constraints that have been placed on the set of paths
         that may be validated using the key. All of this information is
         available from a CA's public-key certificate.

         Therefore, "trust anchor" is sometimes defined as a public-key
         certificate of a CA. (See: root certificate, trust anchor
         certificate, trusted certificate.)

      -  4. Combinations: Combinations and variations of the first three
         definitions are also used in the PKI literature.

         Example: "trust anchor information". The IPS standard for path
         validation [R3280] specifies the information that describes "a
         CA that serves as a trust anchor for the certification path.
         The trust anchor information includes: (a) the trusted issuer
         name, (b) the trusted public key algorithm, (c) the trusted
         public key, and (d) optionally, the trusted public key
         parameters associated with the public key. The trust anchor
         information may be provided to the path processing procedure in
         the form of a self-signed certificate. The trusted anchor
         information is trusted because it was delivered to the path
         processing procedure by some trustworthy out-of-band procedure.
         If the trusted public key algorithm requires parameters, then
         the parameters are provided along with the trusted public key."

   $ trust anchor CA
      (I) A CA that is the subject of a trust anchor certificate or
      otherwise establishes a trust anchor key. (See: root, trusted CA.)

      Tutorial: The selection of a CA to be a trust anchor is a matter
      of policy. Some of the possible choices include (a) the top CA in
      a hierarchical PKI, (b) the CA that issued the verifier's own
      certificate, or (c) any other CA in a network PKI. Different
      applications may rely on different trust anchors, or may accept
      paths that begin with any of a set of trust anchors. The IPS path
      validation algorithm is the same, regardless of the choice.

   $ trust anchor certificate
      (I) A public-key certificate that is used to provide the first
      public key in a certification path. (See: root certificate, trust
      anchor, trusted certificate.)

   $ trust anchor key
      (I) A public key that is used as the first public key in a
      certification path. (See: root key, trust anchor, trusted public
      key.)

   $ trust anchor information
      (I) See: secondary definition under "trust anchor".

   $ trust chain
      (D) Synonym for "certification path". (See: trust anchor, trusted
      certificate.)

      Deprecated Term: IDOCs SHOULD NOT use this term, because it
      unnecessarily duplicates the meaning of the internationally
      standardized term.

      Also, the term mixes concepts in a potentially misleading way.
      Having "trust" involves factors unrelated to simply verifying
      signatures and performing other tests as specified by a standard
      algorithm for path validation (e.g., RFC 3280). Thus, even if a
      user is able to validate a certification path algorithmically, the
      user still might distrust one of the CAs that issued certificates
      in that path or distrust some other aspects of the PKI.

   $ trust-file PKI
      (I) A non-hierarchical PKI in which each certificate user has its
      own local file (which is used by application software) of trust
      anchors, i.e., either public keys or public-key certificates that
      the user trusts as starting points for certification paths. (See:
      trust anchor, web of trust. Compare: hierarchical PKI, mesh PKI.)

      Example: Popular browsers are distributed with an initial file of
      trust anchor certificates, which often are self-signed
      certificates. Users can add certificates to the file or delete
      from it. The file may be directly managed by the user, or the
      user's organization may manage it from a centralized server.

   $ trust hierarchy
      (D) Synonym for "certification hierarchy".

      Deprecated Usage: IDOCs SHOULD NOT use this term because it mixes
      concepts in a potentially misleading way, and because a trust
      hierarchy could be implemented in other ways. (See: trust, trust
      chain, web of trust.)

   $ trust level
      (N) A characterization of a standard of security protection to be
      met by an information system. (See: Common Criteria, TCSEC.)

      Tutorial: A trust level is based not only on (a) the presence of
      security mechanisms, but also on the use of (b) systems
      engineering discipline to properly structure the system and (c)
      implementation analysis to ensure that the system provides an
      appropriate degree of trust.

   $ trusted
      (I) See: secondary definition under "trust".

   $ trusted CA
      (I) A CA upon which a certificate user relies as issuing valid
      certificates; especially a CA that is used as a trust anchor CA.
      (See: certification path, root, trust anchor CA, validation.)

      Tutorial. This trust is transitive to the extent that the X.509
      certificate extensions permit; that is, if a trusted CA issues a
      certificate to another CA, a user that trusts the first CA also
      trusts the second CA if the user succeeds in validating the
      certificate path (see: path validation).

   $ trusted certificate
      (I) A digital certificate that a certificate user accepts as being
      valid "a priori", i.e., without testing the certificate to
      validate it as the final certificate on a certification path;
      especially a certificate that is used as a trust anchor
      certificate. (See: certification path, root certificate, trust
      anchor certificate, trust-file PKI, validation.)

      Tutorial: The acceptance of a certificate as trusted is a matter
      of policy and choice. Usually, a certificate is accepted as
      trusted because the user obtained it by reliable, out-of-band
      means that cause the user to believe the certificate accurately
      binds its subject's name to the subject's public key or other
      attribute values. Many choices are possible; e.g., a trusted
      public-key certificate might be (a) the root certificate in a
      hierarchical PKI, (b) the certificate of the CA that issued the
      user's own certificate in a mesh PKI, or (c) a certificate
      provided with an application that uses a trust-file PKI.

   $ Trusted Computer System Evaluation Criteria (TCSEC)
      (N) A standard for evaluating the security provided by operating
      systems [CSC1, DoD1]. Known as the "Orange Book" because of the
      color of its cover; first document in the Rainbow Series. (See:
      Common Criteria, Deprecated Usage under "Green Book", Orange Book,
      trust level, trusted system. Compare: TSEC.)

      Tutorial: The TCSEC defines classes of hierarchically ordered
      assurance levels for rating computer systems. From highest to
      lowest, the classes are as follows:
      -  Division A:  Verified protection.
           Beyond A1    Beyond current technology. (See: beyond A1.)
           Class  A1    Verified design. (See: SCOMP.)
      -  Division B:  Mandatory protection.
           Class  B3    Security domains.
           Class  B2    Structured protection. (See: Multics.)
           Class  B1    Labeled security protection.

      -  Division C:  Discretionary protection.
           Class  C2    Controlled access protection.
           Class  C1    Discretionary security protection.
      -  Division D:  Minimal protection, i.e., has been evaluated but
         does not meet the requirements for a higher evaluation class.

   $ trusted computing base (TCB)
      (N) "The totality of protection mechanisms within a computer
      system, including hardware, firmware, and software, the
      combination of which is responsible for enforcing a security
      policy." [NCS04] (See: "trusted" under "trust". Compare: TPM.)

   $ Trusted Computing Group (TCG)
      (N) A not-for-profit, industry standards organization formed to
      develop, define, and promote open standards for hardware-enabled
      trusted computing and security technologies, including hardware
      building blocks and software interfaces, across multiple
      platforms, peripherals, and devices. (See: TPM, trusted system.
      Compare: TSIG.)

   $ trusted distribution
      (I) /COMPUSEC/ "A trusted method for distributing the TCB
      hardware, software, and firmware components, both originals and
      updates, that provides methods for protecting the TCB from
      modification during distribution and for detection of any changes
      to the TCB that may occur." [NCS04] (See: code signing,
      configuration control.)

   $ trusted key
      (D) Abbreviation for "trusted public key" and also for other types
      of keys. (See: root key, trust anchor key.)

      Deprecated Usage: IDOCs SHOULD either (a) state a definition for
      this term or (b) use a different, less ambiguous term. This term
      is ambiguous when it stands alone; e.g., it could refer to a
      trusted public key or to a private key or symmetric key that is
      believed to be secure (i.e., not compromised).

   $ trusted path
      1a. (I) /COMPUSEC/ A mechanism by which a computer system user can
      communicate directly and reliably with the TCB and that can only
      be activated by the user or the TCB and cannot be imitated by
      untrusted software within the computer. [NCS04]

      1b. (I) /COMSEC/ A mechanism by which a person or process can
      communicate directly with a cryptographic module and that can only
      be activated by the person, process, or module, and cannot be
      imitated by untrusted software within the module. [FP140]

   $ Trusted Platform Module (TPM)
      (N) The name of a specification, published by the TCG, for a
      microcontroller that can store secured information; and also the
      general name of implementations of that specification. (Compare:
      TCB.)

   $ trusted process
      (I) A system component that has privileges that enable it to
      affect the state of system security and that can, therefore,
      through incorrect or malicious execution, violate the system's
      security policy. (See: privileged process, trusted system.)

   $ trusted public key
      (I) A public key upon which a user relies; especially a public key
      that is used as a trust anchor key. (See: certification path, root
      key, trust anchor key, validation.)

      Tutorial: A trusted public key could be (a) the root key in a
      hierarchical PKI, (b) the key of the CA that issued the user's own
      certificate in a mesh PKI, or (c) any key accepted by the user in
      a trust-file PKI.

   $ trusted recovery
      (I) A process that, after a system has experienced a failure or an
      attack, restores the system to normal operation (or to a secure
      state) without causing a security compromise. (See: recovery.)

   $ trusted subnetwork
      (I) A subnetwork containing hosts and routers that trust each
      other not to engage in active or passive attacks. (There also is
      an assumption that the underlying communication channels, such as
      telephone lines or a LAN, are protected from attack.)

   $ trusted system
      1. (I) /information system/ A system that operates as expected,
      according to design and policy, doing what is required -- despite
      environmental disruption, human user and operator errors, and
      attacks by hostile parties -- and not doing other things [NRC98].
      (See: trust level, trusted process. Compare: trustworthy.)

      2. (N) /multilevel secure/ "A [trusted system is a] system that
      employs sufficient hardware and software assurance measures to
      allow its use for simultaneous processing of a range of sensitive
      or classified information." [NCS04] (See: multilevel security
      mode.)

   $ Trusted Systems Interoperability Group (TSIG)
      (N) A forum of computer vendors, system integrators, and users
      devoted to promoting interoperability of trusted computer systems.
      (See: trusted system. Compare: TCG.)

   $ trustworthy system
      1. (I) A system that not only is trusted, but also warrants that
      trust because the system's behavior can be validated in some
      convincing way, such as through formal analysis or code review.
      (See: trust. Compare: trusted.)

      2. (O) /Digital Signature Guidelines/ "Computer hardware,
      software, and procedures that: (a) are reasonably secure from
      intrusion and misuse; (b) provide a reasonably reliable level of
      availability, reliability, and correct operation; (c) are
      reasonably suited to performing their intended functions; and (d)
      adhere to generally accepted security principles." [DSG]

   $ TSEC
      (O) See: Telecommunications Security Nomenclature System.
      (Compare: TCSEC.)

   $ TSIG
      1. (N) See: Trusted System Interoperability Group.

      2. (I) A mnemonic (presumed to be derived from "Transaction
      SIGnature") referring to an Internet protocol (RFC 2845) for data
      origin authentication and data integrity for certain DNS
      operations. (See: TKEY.)

   $ tunnel
      1. (I) A communication channel created in a computer network by
      encapsulating (i.e., layering) a communication protocol's data
      packets in (i.e., above) a second protocol that normally would be
      carried above, or at the same layer as, the first one. (See: L2TP,
      tunnel mode, VPN. Compare: covert channel.)

      Tutorial: Tunneling can involve almost any two IPS protocol
      layers. For example, a TCP connection between two hosts could
      conceivably be carried above SMTP (i.e., in SMTP messages) as a
      covert channel to evade access controls that a security gateway
      applies to the normal TCP layer that is below SMTP.

      Usually, however, a tunnel is a logical point-to-point link --
      i.e., an OSIRM Layer 2 connection -- created by encapsulating the
      Layer 2 protocol in one of the following three types of IPS
      protocols: (a) an IPS Transport-Layer protocol (such as TCP), (b)
      an IPS Network-Layer or Internet-Layer protocol (such as IP), or

      (c) another Layer 2 protocol. In many cases, the encapsulation is
      accomplished with an extra, intermediate protocol (i.e., a
      "tunneling protocol"; e.g., L2TP) that is layered below the
      tunneled Layer 2 protocol and above the encapsulating protocol.

      Tunneling can be used to move data between computers that use a
      protocol not supported by the network connecting them. Tunneling
      also can enable a computer network to use the services of a second
      network as though the second network were a set of point-to-point
      links between the first network's nodes. (See: VPN.)

      2. (O) /SET/ The name of a SET private extension that indicates
      whether the CA or the payment gateway supports passing encrypted
      messages to the cardholder through the merchant. If so, the
      extension lists OIDs of symmetric encryption algorithms that are
      supported.

   $ tunnel mode
      (I) One of two ways to apply the IPsec protocols (AH and ESP) to
      protect data packets; in this mode, the IPsec protocol
      encapsulates (i.e., the protection applies to) IP packets, rather
      than the packets of higher-layer protocols. (See: tunnel. Compare:
      transport mode.)

      Tutorial: Each end of a tunnel-mode security association may be
      either a host or a security gateway. Whenever either end of an
      IPsec security association is a security gateway, the association
      is required to be in tunnel mode.

   $ two-person control
      (I) The close surveillance and control of a system, a process, or
      materials (especially with regard to cryptography) at all times by
      a minimum of two appropriately authorized persons, each capable of
      detecting incorrect and unauthorized procedures with respect to
      the tasks to be performed and each familiar with established
      security requirements. (See: dual control, no-lone zone.)

   $ Twofish
      (O) A symmetric, 128-bit block cipher with variable key length
      (128, 192, or 256 bits), developed by Counterpane Labs as a
      candidate for the AES. (See: Blowfish.)

   $ type 0 product
      (O) /cryptography, U.S. Government/ Classified cryptographic
      equipment endorsed by NSA for use (when appropriately keyed) in
      electronically distributing bulk keying material.

   $ type 1 key
      (O) /cryptography, U.S. Government/ "Generated and distributed
      under the auspices of NSA for use in a cryptographic device for
      the protection of classified and sensitive national security
      information." [C4009]

   $ type 1 product
      (O) /cryptography, U.S. Government/ "Cryptographic equipment,
      assembly or component classified or certified by NSA for
      encrypting and decrypting classified and sensitive national
      security information when appropriately keyed. Developed using
      established NSA business processes and containing NSA approved
      algorithms. Used to protect systems requiring the most stringent
      protection mechanisms." [C4009]

      Tutorial: The current definition of this term is less specific
      than an earlier version: "Classified or controlled cryptographic
      item endorsed by the NSA for securing classified and sensitive
      U.S. Government information, when appropriately keyed. The term
      refers only to products, and not to information, key, services, or
      controls. Type 1 products contain classified NSA algorithms. They
      are available to U.S. Government users, their contractors, and
      federally sponsored non-U.S. Government activities subject to
      export restrictions in accordance with International Traffic in
      Arms Regulation." [from an earlier version of C4009] (See: ITAR.)

   $ type 2 key
      (O) /cryptography, U.S. Government/ "Generated and distributed
      under the auspices of NSA for use in a cryptographic device for
      the protection of unclassified national security information."
      [C4009]

   $ type 2 product
      (O) /cryptography, U.S. Government/ "Cryptographic equipment,
      assembly, or component certified by NSA for encrypting or
      decrypting sensitive national security information when
      appropriately keyed. Developed using established NSA business
      processes and containing NSA approved algorithms. Used to protect
      systems requiring protection mechanisms exceeding best commercial
      practices including systems used for the protection of
      unclassified national security information." [C4009]

      Tutorial: The current definition of this term is less specific
      than an earlier version: "Unclassified cryptographic equipment,
      assembly, or component, endorsed by the NSA, for use in national
      security systems as defined in Title 40 U.S.C. Section 1452."
      [from an earlier version of C4009] (See: national security system.
      Compare: EUCI.)

   $ type 3 key
      (O) /cryptography, U.S. Government/ "Used in a cryptographic
      device for the protection of unclassified sensitive information,
      even if used in a Type 1 or Type 2 product." [C4009]

   $ type 3 product
      (O) /cryptography, U.S. Government/ "Unclassified cryptographic
      equipment, assembly, or component used, when appropriately keyed,
      for encrypting or decrypting unclassified sensitive U.S.
      Government or commercial information, and to protect systems
      requiring protection mechanisms consistent with standard
      commercial practices. Developed using established commercial
      standards and containing NIST approved cryptographic
      algorithms/modules or successfully evaluated by the National
      Information Assurance Partnership (NIAP)." [C4009]

   $ type 4 key
      (O) /cryptography, U.S. Government/ "Used by a cryptographic
      device in support of its Type 4 functionality; i.e., any provision
      of key that lacks U.S. Government endorsement or oversight."
      [C4009]

   $ type 4 product
      (O) /cryptography, U.S. Government/ "Unevaluated commercial
      cryptographic equipment, assemblies, or components that neither
      NSA nor NIST certify for any Government usage. These products are
      typically delivered as part of commercial offerings and are
      commensurate with the vendor's commercial practices. These
      products may contain either vendor proprietary algorithms,
      algorithms registered by NIST, or algorithms registered by NIST
      and published in a FIPS." [C4009]

   $ UDP
      (I) See: User Datagram Protocol.

   $ UDP flood
      (I) A denial-of-service attack that takes advantage of (a) one
      system's UDP test function that generates a series of characters
      for each packet it receives and (b) another system's UPD test
      function that echoes any character it receives; the attack
      connects (a) to (b) to cause a nonstop flow of data between the
      two systems. (See: flooding.)

   $ unauthorized disclosure
      (I) A circumstance or event whereby an entity gains access to
      information for which the entity is not authorized.

      Tutorial: This type of threat consequence can be caused by the
      following types of threat actions: exposure, interception,
      inference, and intrusion. Some methods of protecting against this
      consequence include access control, flow control, and inference
      control. (See: data confidentiality.)

   $ unauthorized user
      (I) /access control/ A system entity that accesses a system
      resource for which the entity has not received an authorization.
      (See: user. Compare: authorized user, insider, outsider.)

      Usage: IDOCs that use this term SHOULD state a definition for it
      because the term is used in many ways and could easily be
      misunderstood.

   $ uncertainty
      (N) An information-theoretic measure (usually stated as a number
      of bits) of the minimum amount of plaintext information that needs
      to be recovered from cipher text to learn the entire plain text
      that was encrypted. [SP63] (See: entropy.)

   $ unclassified
      (I) Not classified. (Compare: FOUO.)

   $ unencrypted
      (I) Not encrypted.

   $ unforgeable
      (I) /cryptography/ The property of a cryptographic data structure
      (i.e., a data structure that is defined using one or more
      cryptographic functions, e.g., "digital certificate") that makes
      it computationally infeasible to construct (i.e., compute) an
      unauthorized but correct value of the structure without having
      knowledge of one of more keys.

      Tutorial: This definition is narrower than general English usage,
      where "unforgeable" means unable to be fraudulently created or
      duplicated. In that broader sense, anyone can forge a digital
      certificate containing any set of data items whatsoever by
      generating the to-be-signed certificate and signing it with any
      private key whatsoever. But for PKI purposes, the forged data
      structure is invalid if it is not signed with the true private key
      of the claimed issuer; thus, the forgery will be detected when a
      certificate user uses the true public key of the claimed issuer to
      verify the signature.

   $ uniform resource identifier (URI)
      (I) A type of formatted identifier (RFC 3986) that encapsulates
      the name of an Internet object, and labels it with an
      identification of the name space, thus producing a member of the
      universal set of names in registered name spaces and of addresses
      referring to registered protocols or name spaces.

      Example: HTML uses URIs to identify the target of hyperlinks.

      Usage: "A URI can be classified as a locator (see: URL), a name
      (see: URN), or both. ... Instances of URIs from any given scheme
      may have the characteristics of names or locators or both, often
      depending on the persistence and care in the assignment of
      identifiers by the naming authority, rather than on any quality of
      the scheme." IDOCs SHOULD "use the general term 'URI' rather than
      the more restrictive terms 'URL' and 'URN'." (RFC 3986)

   $ uniform resource locator (URL)
      (I) A URI that describes the access method and location of an
      information resource object on the Internet. (See: Usage under
      "URI". Compare: URN.)

      Tutorial: The term URL "refers to the subset of URIs that, besides
      identifying a resource, provide a means of locating the resource
      by describing its primary access mechanism (e.g., its network
      'location')." (RFC 3986)

      A URL provides explicit instructions on how to access the named
      object. For example,
      "ftp://bbnarchive.bbn.com/foo/bar/picture/cambridge.zip" is a URL.
      The part before the colon specifies the access scheme or protocol,
      and the part after the colon is interpreted according to that
      access method. Usually, two slashes after the colon indicate the
      host name of a server (written as a domain name). In an FTP or
      HTTP URL, the host name is followed by the path name of a file on
      the server. The last (optional) part of a URL may be either a
      fragment identifier that indicates a position in the file, or a
      query string.

   $ uniform resource name (URN)
      (I) A URI with the properties of a name. (See: Usage under "URI".
      Compare: URL.)

      Tutorial: The term URN "has been used historically to refer to
      both URIs under the "urn" scheme (RFC 2141), which are required to
      remain globally unique and persistent even when the resource
      ceases to exist or becomes unavailable, and to any other URI with
      the properties of a name." (RFC 3986)

   $ untrusted
      (I) See: secondary definition under "trust".

   $ untrusted process
      1. (I) A system component that is not able to affect the state of
      system security through incorrect or malicious operation. Example:
      A component that has its operations confined by a security kernel.
      (See: trusted process.)

      2. (I) A system component that (a) has not been evaluated or
      examined for adherence to a specified security policy and,
      therefore, (b) must be assumed to contain logic that might attempt
      to circumvent system security.

   $ UORA
      (O) See: user-PIN ORA.

   $ update
      See: "certificate update" and "key update".

   $ upgrade
      (I) /data security/ Increase the classification level of data
      without changing the information content of the data. (See:
      classify, downgrade, regrade.)

   $ URI
      (I) See: uniform resource identifier.

   $ URL
      (I) See: uniform resource locator.

   $ URN
      (I) See: uniform resource name.

   $ user
      See: system user.

      Usage: IDOCs that use this term SHOULD state a definition for it
      because the term is used in many ways and could easily be
      misunderstood.

   $ user authentication service
      (I) A security service that verifies the identity claimed by an
      entity that attempts to access the system. (See: authentication,
      user.)

   $ User Datagram Protocol (UDP)
      (I) An Internet Standard, Transport-Layer protocol (RFC 768) that
      delivers a sequence of datagrams from one computer to another in a
      computer network. (See: UPD flood.)

      Tutorial: UDP assumes that IP is the underlying protocol. UDP
      enables application programs to send transaction-oriented data to
      other programs with minimal protocol mechanism. UDP does not
      provide reliable delivery, flow control, sequencing, or other end-
      to-end service guarantees that TCP does.

   $ user identifier
      (I) See: identifier.

   $ user identity
      (I) See: identity.

   $ user PIN
      (O) /MISSI/ One of two PINs that control access to the functions
      and stored data of a FORTEZZA PC card. Knowledge of the user PIN
      enables a card user to perform the FORTEZZA functions that are
      intended for use by an end user. (See: PIN. Compare: SSO PIN.)

   $ user-PIN ORA (UORA)
      (O) /MISSI/ A MISSI organizational RA that operates in a mode in
      which the ORA performs only the subset of card management
      functions that are possible with knowledge of the user PIN for a
      FORTEZZA PC card. (See: no-PIN ORA, SSO-PIN ORA.)

   $ usurpation
      (I) A circumstance or event that results in control of system
      services or functions by an unauthorized entity. This type of
      threat consequence can be caused by the following types of threat
      actions: misappropriation, misuse. (See: access control.)

   $ UTCTime
      (N) The ASN.1 data type "UTCTime" contains a calendar date
      (YYMMDD) and a time to a precision of either one minute (HHMM) or
      one second (HHMMSS), where the time is either (a) Coordinated
      Universal Time or (b) the local time followed by an offset that
      enables Coordinated Universal Time to be calculated. (See:
      Coordinated Universal Time. Compare: GeneralizedTime.)

      Usage: If you care about centuries or millennia, you probably need
      to use the GeneralizedTime data type instead of UTCTime.

   $ v1 certificate
      (N) An abbreviation that ambiguously refers to either an "X.509
      public-key certificate in version 1 format" or an "X.509 attribute
      certificate in version 1 format".

      Deprecated Usage: IDOCs MAY use this term as an abbreviation of
      "version 1 X.509 public-key certificate", but only after using the
      full term at the first instance. Otherwise, the term is ambiguous,
      because X.509 specifies both v1 public-key certificates and v1
      attribute certificates. (See: X.509 attribute certificate, X.509
      public-key certificate.)

   $ v1 CRL
      (N) Abbreviation of "X.509 CRL in version 1 format".

      Usage: IDOCs MAY use this abbreviation, but SHOULD use the full
      term at its first occurrence and define the abbreviation there.

   $ v2 certificate
      (N) Abbreviation of "X.509 public-key certificate in version 2
      format".

      Usage: IDOCs MAY use this abbreviation, but SHOULD use the full
      term at its first occurrence and define the abbreviation there.

   $ v2 CRL
      (N) Abbreviation of "X.509 CRL in version 2 format".

      Usage: IDOCs MAY use this abbreviation, but SHOULD use the full
      term at its first occurrence and define the abbreviation there.

   $ v3 certificate
      (N) Abbreviation of "X.509 public-key certificate in version 3
      format".

      Usage: IDOCs MAY use this abbreviation, but SHOULD use the full
      term at its first occurrence and define the abbreviation there.

   $ valid certificate
      1. (I) A digital certificate that can be validated successfully.
      (See: validate, verify.)

      2. (I) A digital certificate for which the binding of the data
      items can be trusted.

   $ valid signature
      (D) Synonym for "verified signature".

      Deprecated Term: IDOCs SHOULD NOT use this synonym. This Glossary
      recommends saying "validate the certificate" and "verify the
      signature"; therefore, it would be inconsistent to say that a
      signature is "valid". (See: validate, verify.)

   $ validate
      1. (I) Establish the soundness or correctness of a construct.
      Example: certificate validation. (See: validate vs. verify.)

      2. (I) To officially approve something, sometimes in relation to a
      standard. Example: NIST validates cryptographic modules for
      conformance with [FP140].

   $ validate vs. verify
      Usage: To ensure consistency and align with ordinary English
      usage, IDOCs SHOULD comply with the following two rules:
      -  Rule 1: Use "validate" when referring to a process intended to
         establish the soundness or correctness of a construct (e.g.,
         "certificate validation"). (See: validate.)
      -  Rule 2: Use "verify" when referring to a process intended to
         test or prove the truth or accuracy of a fact or value (e.g.,
         "authenticate"). (See: verify.)

      Tutorial: The Internet security community sometimes uses these two
      terms inconsistently, especially in a PKI context. Most often,
      however, we say "verify the signature" but say "validate the
      certificate". That is, we "verify" atomic truths but "validate"
      data structures, relationships, and systems that are composed of
      or depend on verified items. This usage has a basis in Latin:

      The word "valid" derives from a Latin word that means "strong".
      Thus, to validate means to check that a construct is sound. For
      example, a certificate user validates a public-key certificate to
      establish trust in the binding that the certificate asserts
      between an identity and a key. This can include checking various
      aspects of the certificate's construction, such as verifying the
      digital signature on the certificate by performing calculations,
      verifying that the current time is within the certificate's
      validity period, and validating a certification path involving
      additional certificates.

      The word "verify" derives from a Latin word that means "true".
      Thus, to verify means to check the truth of an assertion by
      examining evidence or performing tests. For example, to verify an
      identity, an authentication process examines identification
      information that is presented or generated. To validate a
      certificate, a certificate user verifies the digital signature on
      the certificate by performing calculations, verifies that the

      current time is within the certificate's validity period, and may
      need to validate a certification path involving additional
      certificates.

   $ validation
      (I) See: validate vs. verify.

   $ validity period
      (I) /PKI/ A data item in a digital certificate that specifies the
      time period for which the binding between data items (especially
      between the subject name and the public key value in a public-key
      certificate) is valid, except if the certificate appears on a CRL
      or the key appears on a CKL. (See: cryptoperiod, key lifetime.)

   $ value-added network (VAN)
      (I) A computer network or subnetwork (usually a commercial
      enterprise) that transmits, receives, and stores EDI transactions
      on behalf of its users.

      Tutorial: A VAN may also provide additional services, ranging from
      EDI format translation, to EDI-to-FAX conversion, to integrated
      business systems.

   $ VAN
      (I) See: value-added network.

   $ verification
      1. (I) /authentication/ The process of examining information to
      establish the truth of a claimed fact or value. (See: validate vs.
      verify, verify. Compare: authentication.)

      2. (N) /COMPUSEC/ The process of comparing two levels of system
      specification for proper correspondence, such as comparing a
      security model with a top-level specification, a top-level
      specification with source code, or source code with object code.
      [NCS04]

   $ verified design
      (O) See: TCSEC Class A1.

   $ verify
      (I) To test or prove the truth or accuracy of a fact or value.
      (See: validate vs. verify, verification. Compare: authenticate.)

   $ vet
      (I) /verb/ To examine or evaluate thoroughly. (Compare:
      authenticate, identity proofing, validate, verify.)

   $ violation
      See: security violation.

   $ virtual private network (VPN)
      (I) A restricted-use, logical (i.e., artificial or simulated)
      computer network that is constructed from the system resources of
      a relatively public, physical (i.e., real) network (e.g., the
      Internet), often by using encryption (located at hosts or
      gateways), and often by tunneling links of the virtual network
      across the real network. (See: tunnel.)

      Tutorial: A VPN is generally less expensive to build and operate
      than a dedicated real network, because the virtual network shares
      the cost of system resources with other users of the underlying
      real network. For example, if a corporation has LANs at several
      different sites, each connected to the Internet by a firewall, the
      corporation could create a VPN by using encrypted tunnels to
      connect from firewall to firewall across the Internet.

   $ virus
      (I) A self-replicating (and usually hidden) section of computer
      software (usually malicious logic) that propagates by infecting --
      i.e., inserting a copy of itself into and becoming part of --
      another program. A virus cannot run by itself; it requires that
      its host program be run to make the virus active.

   $ Visa Cash
      (O) A smartcard-based electronic money system that incorporates
      cryptography and can be used to make payments via the Internet.
      (See: IOTP.)

   $ volatile media
      (I) Storage media that require an external power supply to
      maintain stored information. (Compare: non-volatile media,
      permanent storage.)

   $ VPN
      (I) See: virtual private network.

   $ vulnerability
      (I) A flaw or weakness in a system's design, implementation, or
      operation and management that could be exploited to violate the
      system's security policy. (See: harden.)

      Tutorial: A system can have three types of vulnerabilities: (a)
      vulnerabilities in design or specification; (b) vulnerabilities in
      implementation; and (c) vulnerabilities in operation and
      management. Most systems have one or more vulnerabilities, but

      this does not mean that the systems are too flawed to use. Not
      every threat results in an attack, and not every attack succeeds.
      Success depends on the degree of vulnerability, the strength of
      attacks, and the effectiveness of any countermeasures in use. If
      the attacks needed to exploit a vulnerability are very difficult
      to carry out, then the vulnerability may be tolerable. If the
      perceived benefit to an attacker is small, then even an easily
      exploited vulnerability may be tolerable. However, if the attacks
      are well understood and easily made, and if the vulnerable system
      is employed by a wide range of users, then it is likely that there
      will be enough motivation for someone to launch an attack.

   $ W3
      (D) Synonym for WWW.

      Deprecated Abbreviation: This abbreviation could be confused with
      W3C; use "WWW" instead.

   $ W3C
      (N) See: World Wide Web Consortium.

   $ war dialer
      (I) /slang/ A computer program that automatically dials a series
      of telephone numbers to find lines connected to computer systems,
      and catalogs those numbers so that a cracker can try to break the
      systems.

      Deprecated Usage: IDOCs that use this term SHOULD state a
      definition for it because the term could confuse international
      readers.

   $ Wassenaar Arrangement
      (N) The Wassenaar Arrangement on Export Controls for Conventional
      Arms and Dual-Use Goods and Technologies is a global, multilateral
      agreement approved by 33 countries in July 1996 to contribute to
      regional and international security and stability, by promoting
      information exchange concerning, and greater responsibility in,
      transfers of arms and dual-use items, thus preventing
      destabilizing accumulations. (See: International Traffic in Arms
      Regulations.)

      Tutorial: The Arrangement began operations in September 1996 with
      headquarters in Vienna. The participating countries were
      Argentina, Australia, Austria, Belgium, Bulgaria, Canada, Czech
      Republic, Denmark, Finland, France, Germany, Greece, Hungary,
      Ireland, Italy, Japan, Luxembourg, Netherlands, New Zealand,
      Norway, Poland, Portugal, Republic of Korea, Romania, Russian

      Federation, Slovak Republic, Spain, Sweden, Switzerland, Turkey,
      Ukraine, United Kingdom, and United States.

      Participating countries seek through their national policies to
      ensure that transfers do not contribute to the development or
      enhancement of military capabilities that undermine the goals of
      the arrangement, and are not diverted to support such
      capabilities. The countries maintain effective export controls for
      items on the agreed lists, which are reviewed periodically to
      account for technological developments and experience gained.
      Through transparency and exchange of views and information,
      suppliers of arms and dual-use items can develop common
      understandings of the risks associated with their transfer and
      assess the scope for coordinating national control policies to
      combat these risks. Members provide semi-annual notification of
      arms transfers, covering seven categories derived from the UN
      Register of Conventional Arms. Members also report transfers or
      denials of transfers of certain controlled dual-use items.
      However, the decision to transfer or deny transfer of any item is
      the sole responsibility of each participating country. All
      measures undertaken with respect to the arrangement are in
      accordance with national legislation and policies and are
      implemented on the basis of national discretion.

   $ watermarking
      See: digital watermarking.

   $ weak key
      (I) In the context of a particular cryptographic algorithm, a key
      value that provides poor security. (See: strong.)

      Example: The DEA has four "weak keys" [Schn] for which encryption
      produces the same result as decryption. It also has ten pairs of
      "semi-weak keys" [Schn] (a.k.a. "dual keys" [FP074]) for which
      encryption with one key in the pair produces the same result as
      decryption with the other key.

   $ web, Web
      1. (I) /not capitalized/ IDOCs SHOULD NOT capitalize "web" when
      using the term (usually as an adjective) to refer generically to
      technology -- such as web browsers, web servers, HTTP, and HTML --
      that is used in the Web or similar networks.

      2. (I) /capitalized/ IDOCs SHOULD capitalize "Web" when using the
      term (as either a noun or an adjective) to refer specifically to
      the World Wide Web. (Similarly, see: internet.)

      Usage: IDOCs SHOULD NOT use "web" or "Web" in a way that might
      confuse these definitions with the PGP "web of trust". When using
      Web as an abbreviation for "World Wide Web", IDOCs SHOULD fully
      spell out the term at the first instance of usage.

   $ web of trust
      (D) /PGP/ A PKI architecture in which each certificate user
      defines their own trust anchor(s) by depending on personal
      relationships. (See: trust anchor. Compare: hierarchical PKI, mesh
      PKI.)

      Deprecated Usage: IDOCs SHOULD NOT use this term except with
      reference to PGP. This term mixes concepts in potentially
      misleading ways; e.g., this architecture does not depend on World
      Wide Web technology. Instead of this term, IDOCs MAY use "trust-
      file PKI". (See: web, Web).

      Tutorial: This type of architecture does not usually include
      public repositories of certificates. Instead, each certificate
      user builds their own, private repository of trusted public keys
      by making personal judgments about being able to trust certain
      people to be holding properly certified keys of other people. It
      is this set of person-to-person relationships from which the
      architecture gets its name.

   $ web server
      (I) A software process that runs on a host computer connected to a
      network and responds to HTTP requests made by client web browsers.

   $ WEP
      (N) See: Wired Equivalency Protocol.

   $ Wired Equivalent Privacy (WEP)
      (N) A cryptographic protocol that is defined in the IEEE 802.11
      standard and encapsulates the packets on wireless LANs. Usage:
      a.k.a. "Wired Equivalency Protocol".

      Tutorial: The WEP design, which uses RC4 to encrypt both the plain
      text and a CRC, has been shown to be flawed in multiple ways; and
      it also has often suffered from flawed implementation and
      management.

   $ wiretapping
      (I) An attack that intercepts and accesses information contained
      in a data flow in a communication system. (See: active
      wiretapping, end-to-end encryption, passive wiretapping, secondary
      definition under "interception".)

      Usage: Although the term originally referred to making a
      mechanical connection to an electrical conductor that links two
      nodes, it is now used to refer to accessing information from any
      sort of medium used for a link or even from a node, such as a
      gateway or subnetwork switch.

      Tutorial: Wiretapping can be characterized according to intent:
      -  "Active wiretapping" attempts to alter the data or otherwise
         affect the flow.
      -  "Passive wiretapping" only attempts to observe the data flow
         and gain knowledge of information contained in it.

   $ work factor
      1a. (I) /COMPUSEC/ The estimated amount of effort or time that can
      be expected to be expended by a potential intruder to penetrate a
      system, or defeat a particular countermeasure, when using
      specified amounts of expertise and resources. (See: brute force,
      impossible, strength.)

      1b. (I) /cryptography/ The estimated amount of computing power and
      time needed to break a cryptographic system. (See: brute force,
      impossible, strength.)

   $ World Wide Web ("the Web", WWW)
      (N) The global, hypermedia-based collection of information and
      services that is available on Internet servers and is accessed by
      browsers using Hypertext Transfer Protocol and other information
      retrieval mechanisms. (See: web vs. Web, [R2084].)

   $ World Wide Web Consortium (W3C)
      (N) Created in October 1994 to develop and standardize protocols
      to promote the evolution and interoperability of the Web, and now
      consisting of hundreds of member organizations (commercial firms,
      governmental agencies, schools, and others).

      Tutorial: W3C Recommendations are developed through a process
      similar to that of the standards published by other organizations,
      such as the IETF. The W3 Recommendation Track (i.e., standards
      track) has four levels of increasing maturity: Working, Candidate
      Recommendation, Proposed Recommendation, and W3C Recommendation.
      W3C Recommendations are similar to the standards published by
      other organizations. (Compare: Internet Standard, ISO.)

   $ worm
      (I) A computer program that can run independently, can propagate a
      complete working version of itself onto other hosts on a network,
      and may consume system resources destructively. (See: mobile code,
      Morris Worm, virus.)

   $ wrap
      1. (N) To use cryptography to provide data confidentiality service
      for keying material. (See: encrypt, wrapping algorithm, wrapping
      key. Compare: seal, shroud.)

      2. (D) To use cryptography to provide data confidentiality service
      for data in general.

      Deprecated Usage: IDOCs SHOULD NOT use this term with definition 2
      because that duplicates the meaning of the more widely understood
      "encrypt".

   $ wrapping algorithm
      (N) An encryption algorithm that is specifically intended for use
      in encrypting keys. (See: KEK, wrap.)

   $ wrapping key
      (N) Synonym for "KEK". (See: encrypt. Compare: seal, shroud.)

   $ write
      (I) /security model/ A system operation that causes a flow of
      information from a subject to an object. (See: access mode.
      Compare: read.)

   $ WWW
      (I) See: World Wide Web.

   $ X.400
      (N) An ITU-T Recommendation [X400] that is one part of a joint
      ITU-T/ISO multi-part standard (X.400-X.421) that defines the
      Message Handling Systems. (The ISO equivalent is IS 10021, parts
      1-7.) (See: Message Handling Systems.)

   $ X.500
      (N) An ITU-T Recommendation [X500] that is one part of a joint
      ITU-T/ISO multi-part standard (X.500-X.525) that defines the X.500
      Directory, a conceptual collection of systems that provide
      distributed directory capabilities for OSI entities, processes,
      applications, and services. (The ISO equivalent is IS 9594-1 and
      related standards, IS 9594-x.) (See: directory vs. Directory,
      X.509.)

      Tutorial: The X.500 Directory is structured as a tree (the
      Directory Information Tree), and information is stored in
      directory entries. Each entry is a collection of information about
      one object, and each object has a DN. A directory entry is
      composed of attributes, each with a type and one or more values.
      For example, if a PKI uses the Directory to distribute

      certificates, then the X.509 public-key certificate of an end user
      is normally stored as a value of an attribute of type
      "userCertificate" in the Directory entry that has the DN that is
      the subject of the certificate.

   $ X.509
      (N) An ITU-T Recommendation [X509] that defines a framework to
      provide and support data origin authentication and peer entity
      authentication, including formats for X.509 public-key
      certificates, X.509 attribute certificates, and X.509 CRLs. (The
      ISO equivalent is IS 9498-4.) (See: X.500.)

      Tutorial: X.509 describes two "levels" of authentication: "simple
      authentication" and "strong authentication". It recommends, "While
      simple authentication offers some limited protection against
      unauthorized access, only strong authentication should be used as
      the basis for providing secure services."

   $ X.509 attribute certificate
      (N) An attribute certificate in the version 1 (v1) format defined
      by X.509. (The v1 designation for an X.509 attribute certificate
      is disjoint from the v1 designation for an X.509 public-key
      certificate, and from the v1 designation for an X.509 CRL.)

      Tutorial: An X.509 attribute certificate has a "subject" field,
      but the attribute certificate is a separate data structure from
      that subject's public-key certificate. A subject may have multiple
      attribute certificates associated with each of its public-key
      certificates, and an attribute certificate may be issued by a
      different CA than the one that issued the associated public-key
      certificate.

      An X.509 attribute certificate contains a sequence of data items
      and has a digital signature that is computed from that sequence.
      Besides the signature, an attribute certificate contains items 1
      through 9 listed below:

      1. version                 Identifies v1.
      2. subject                 Is one of the following:
         2a. baseCertificateID   Issuer and serial number of an
                                 X.509 public-key certificate.
         2b. subjectName         DN of the subject.
      3. issuer                  DN of the issuer (the CA who signed).
      4. signature               OID of algorithm that signed the cert.
      5. serialNumber            Certificate serial number;
                                 an integer assigned by the issuer.
      6. attCertValidityPeriod   Validity period; a pair of UTCTime
                                 values: "not before" and "not after".

      7. attributes              Sequence of attributes describing the
                                 subject.
      8. issuerUniqueId          Optional, when a DN is not sufficient.
      9. extensions              Optional.

   $ X.509 certificate
      (N) Synonym for "X.509 public-key certificate".

      Usage: IDOCs MAY use this term as an abbreviation of "X.509
      public-key certificate", but only after using the full term at the
      first instance. Otherwise, the term is ambiguous, because X.509
      specifies both public-key certificates and attribute certificates.
      (See: X.509 attribute certificate, X.509 public-key certificate.)

      Deprecated Usage: IDOCs SHOULD NOT use this term as an
      abbreviation of "X.509 attribute certificate", because the term is
      much more commonly used to mean "X.509 public-key certificate"
      and, therefore, is likely to be misunderstood.

   $ X.509 certificate revocation list (CRL)
      (N) A CRL in one of the formats defined by X.509 -- version 1 (v1)
      or version 2 (v2). (The v1 and v2 designations for an X.509 CRL
      are disjoint from the v1 and v2 designations for an X.509 public-
      key certificate, and from the v1 designation for an X.509
      attribute certificate.) (See: certificate revocation.)

      Usage: IDOCs SHOULD NOT refer to an X.509 CRL as a digital
      certificate; however, note that an X.509 CRL does meet this
      Glossary's definition of "digital certificate". That is, like a
      digital certificate, an X.509 CRL makes an assertion and is signed
      by a CA. But instead of binding a key or other attributes to a
      subject, an X.509 CRL asserts that certain previously issued,
      X.509 certificates have been revoked.

      Tutorial: An X.509 CRL contains a sequence of data items and has a
      digital signature computed on that sequence. Besides the
      signature, both v1 and v2 contain items 2 through 6b listed below.
      Version 2 contains item 1 and may optionally contain 6c and 7.

      1. version                 Optional. If present, identifies v2.
      2. signature               OID of the algorithm that signed CRL.
      3. issuer                  DN of the issuer (the CA who signed).
      4. thisUpdate              A UTCTime value.
      5. nextUpdate              A UTCTime value.
      6. revokedCertificates     3-tuples of 6a, 6b, and (optional) 6c:
         6a. userCertificate     A certificate's serial number.
         6b. revocationDate      UTCTime value for the revocation date.
         6c. crlEntryExtensions  Optional.

      7. crlExtensions           Optional.

   $ X.509 public-key certificate
      (N) A public-key certificate in one of the formats defined by
      X.509 -- version 1 (v1), version 2 (v2), or version 3 (v3). (The
      v1 and v2 designations for an X.509 public-key certificate are
      disjoint from the v1 and v2 designations for an X.509 CRL, and
      from the v1 designation for an X.509 attribute certificate.)

      Tutorial: An X.509 public-key certificate contains a sequence of
      data items and has a digital signature computed on that sequence.
      Besides the signature, all three versions contain items 1 through
      7 listed below. Only v2 and v3 certificates may also contain items
      8 and 9, and only v3 may contain item 10.

      1. version                 Identifies v1, v2, or v3.
      2. serialNumber            Certificate serial number;
                                 an integer assigned by the issuer.
      3. signature               OID of algorithm that was used to
                                 sign the certificate.
      4. issuer                  DN of the issuer (the CA who signed).
      5. validity                Validity period; a pair of UTCTime
                                 values: "not before" and "not after".
      6. subject                 DN of entity who owns the public key.
      7. subjectPublicKeyInfo    Public key value and algorithm OID.
      8. issuerUniqueIdentifier  Defined for v2, v3; optional.
      9. subjectUniqueIdentifier Defined for v2, v2; optional.
      10. extensions             Defined only for v3; optional.

   $ X9
      (N) See: "Accredited Standards Committee X9" under "ANSI".

   $ XML
      (N) See: Extensible Markup Language.

   $ XML-Signature.
      (N) A W3C Recommendation (i.e., approved standard) that specifies
      XML syntax and processing rules for creating and representing
      digital signatures (based on asymmetric cryptography) that can be
      applied to any digital content (i.e., any data object) including
      other XML material.

   $ Yellow Book
      (D) /slang/ Synonym for "Computer Security Requirements: Guidance
      for Applying the [U.S.] Department of Defense Trusted Computer
      System Evaluation Criteria in Specific Environments" [CSC3] (See:
      "first law" under "Courtney's laws".)

      Deprecated Term: IDOCs SHOULD NOT use this term as a synonym for
      that or any other document. Instead, use the full proper name of
      the document or, in subsequent references, a conventional
      abbreviation. (See: Deprecated Usage under "Green Book", Rainbow
      Series.)

   $ zero-knowledge proof
      (I) /cryptography/ A proof-of-possession protocol whereby a system
      entity can prove possession of some information to another entity,
      without revealing any of that information. (See: proof-of-
      possession protocol.)

   $ zeroize
      1. (I) Synonym for "erase". (See: sanitize.) Usage: Particularly
      with regard to erasing keys that are stored in a cryptographic
      module.

      2. (O) Erase electronically stored data by altering the contents
      of the data storage so as to prevent the recovery of the data.
      [FP140]

      3. (O) "To remove or eliminate the key from a cryptoequipment or
      fill device." [C4009]

      Usage: The phrase "zeroize the device" normally is used to mean
      erasing all keys stored in the device, but sometimes means erasing
      all keying material in the device, or all cryptographic
      information in the device, or even all sensitive information in
      the device.

   $ zombie
      (I) /slang/ An Internet host computer that has been
      surreptitiously penetrated by an intruder that installed malicious
      daemon software to cause the host to operate as an accomplice in
      attacking other hosts, particularly in distributed attacks that
      attempt denial of service through flooding.

      Deprecated Usage: Other cultures likely use different metaphorical
      terms (such as "robot") for this concept, and some use this term
      for different concepts. Therefore, to avoid international
      misunderstanding, IDOCs SHOULD NOT use this term. Instead, use
      "compromised, coopted computer" or other explicitly descriptive
      terminology. (See: Deprecated Usage under "Green Book".)

   $ zone of control
      (O) /EMSEC/ Synonym for "inspectable space". [C4009] (See:
      TEMPEST.)