Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 2828

Internet Security Glossary

Pages: 212
Obsoleted by:  4949
Part 7 of 8 – Pages 180 to 197
First   Prev   Next

ToP   noToC   RFC2828 - Page 180   prevText
   $ triple-wrapped
      (I) S/MIME usage: Data that has been signed with a digital
      signature, and 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.

   $ trust
      1. (I) Information system usage: The extent to which someone who
      relies on a system can have confidence that the system meets its
      specifications, i.e., that the system does what it claims to do
      and does not perform unwanted functions. (See: trust level.)

      (C) "trusted vs. trustworthy": In discussing a system or system
      process or object, this Glossary (and industry usage) prefers the
      term "trusted" to describe a system that operates as expected,
      according to design and policy. When the trust can also be
      guaranteed in some convincing way, such as through formal analysis
      or code review, the system is termed "trustworthy"; this differs
      from the ABA Guidelines definition (see: trustworthy system).

      2. (I) PKI usage: 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.

      (O) "Generally, an entity can be said to 'trust' a second entity
      when it (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 and a
      [certification] authority; an entity shall be certain that it can
      trust the certification authority to create only valid and
      reliable certificates." [X509]

   $ trust chain
      (D) ISDs SHOULD NOT use this term as a synonym for "certification
      path" because it mixes concepts in a potentially misleading way.
      (See: trust.)

   $ trust-file PKI
      (I) A non-hierarchical PKI in which each certificate user has a
      local file (which is used by application software) of public-key
      certificates that the user trusts as starting points (i.e., roots)
      for certification paths. (See: hierarchical PKI, mesh PKI, root,
      web of trust.)
ToP   noToC   RFC2828 - Page 181
      (C) For example, popular browsers are distributed with an initial
      file of trusted 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) ISDs SHOULD NOT use this term as a synonym for "certification
      hierarchy" because this term mixes concepts (see: trust) in a
      potentially misleading way and duplicates the meaning of another,
      standardized term. (See: trust, web of trust.)

   $ trust level
      (I) A characterization of a standard of security protection to be
      met by a computer system.

      (C) The TCSEC defines eight trust levels. From the lowest to the
      highest, they are D, C1, C2, B1, B2, B3, and A1. A trust level is
      based not only on the presence of security mechanisms but also on
      the use of systems engineering discipline to properly structure
      the system and implementation analysis to ensure that the system
      provides an appropriate degree of trust.

   $ trusted
      See: (discussion under) trust.

   $ trusted certificate
      (I) A certificate upon which a certificate user relies as being
      valid without the need for validation testing; especially a
      public-key certificate that is used to provide the first public
      key in a certification path. (See: certification path, root
      certificate, validation.)

      (C) 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)
      any certificate accepted by the user in a trust-file PKI.

   $ trusted computer system
      (I) Multilevel security usage: "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: (discussion under) trust.)

   $ Trusted Computer System Evaluation Criteria (TCSEC)
      (N) A standard for evaluating the security provided by operating
      systems [CSC001, DOD1]. Informally called the "Orange Book"
ToP   noToC   RFC2828 - Page 182
      because of the color of its cover; first document in the Rainbow
      Series. (See: Common Criteria, (usage note under) Green Book,
      Orange Book, trust level.)

   $ trusted computing base (TCB)
      (I) "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: (discussion of "trusted" under) trust.)

   $ trusted distribution
      (I) "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]

   $ trusted key
      (I) A public key upon which a user relies; especially a public key
      that can be used as the first public key in a certification path.
      (See: certification path, root key, validation.)

      (C) A trusted public key might 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 path
      (I) COMPUSEC usage: A mechanism by which a computer system user
      can communicate directly and reliably with the trusted computing
      base (TCB) and that can only be activated by the user or the TCB
      and cannot be imitated by untrusted software within the computer.
      [NCS04]

      (I) COMSEC usage: 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 process
      (I) A system process 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, (discussion of "trusted" under)
      trust.)
ToP   noToC   RFC2828 - Page 183
   $ 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--e.g.,
      telephone lines, or a LAN--are protected from attack by some
      means.)

   $ trusted system
      See: (discussion under) trust, trusted computer system,
      trustworthy system.

   $ Trusted Systems Interoperability Group (TSIG)
      (N) A forum of computer vendors, system integrators, and users
      devoted to promoting interoperability of trusted computer systems.
      TSIG meetings are open to all persons who are working in the
      INFOSEC area.

   $ trustworthy system
      (O) ABA usage: "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." [ABA] This differs somewhat from other industry
      usage. (See: (discussion of "trusted vs. trustworthy" under)
      trust.)

   $ TSIG
      See: Trusted System Interoperability Group.

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

      (C) Tunneling can involve almost any OSI or TCP/IP protocol
      layers; for example, a TCP connection between two hosts could
      conceivably be tunneled through email messages across the
      Internet. Most often, a tunnel is a logical point-to-point link--
      i.e., an OSI layer 2 connection--created by encapsulating the
      layer 2 protocol in a transport protocol (such as TCP), in a
      network or internetwork layer protocol (such as IP), or in another
      link layer protocol. Often, encapsulation is accomplished with an
      extra, intermediate protocol, i.e., a tunneling protocol (such as
      L2TP) that is layered between the tunneled layer 2 protocol and
      the encapsulating protocol.
ToP   noToC   RFC2828 - Page 184
      (C) Tunneling can 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: virtual private network.)

      (O) SET usage: 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) IPsec usage: See: transport mode vs. tunnel mode.

   $ two-person control
      (I) The close surveillance and control of a system, 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.)

   $ Type I cryptography
      (O) A cryptographic algorithm or device approved by NSA for
      protecting classified information.

   $ Type II cryptography
      (O) A cryptographic algorithm or device approved by NSA for
      protecting sensitive unclassified information (as specified in
      section 2315 of Title 10 United States Code, or section 3502(2) of
      Title 44, United States Code.)

   $ Type III cryptography
      (O) A cryptographic algorithm or device approved as a Federal
      Information Processing Standard.

   $ UDP
      See: User Datagram Protocol.

   $ unclassified
      (I) Not classified.

   $ unencrypted
      (I) Not encrypted.
ToP   noToC   RFC2828 - Page 185
   $ unforgeable
      (I) Cryptographic usage: The property of a cryptographic data
      structure (i.e., a data structure that is defined using one or
      more cryptographic functions) 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. (E.g., see: digital certificate.)

      (C) 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 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. [R1630]

      (C) URIs are used in HTML to identify the target of hyperlinks. In
      common practice, URIs include uniform resource locators [R2368]
      and relative URLs, and may be URNs. [R1808]

   $ uniform resource locator (URL)
      (I) A type of formatted identifier that describes the access
      method and location of an information resource object on the
      Internet. [R1738]

      (C) A URL is a URI that 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.
ToP   noToC   RFC2828 - Page 186
   $ uniform resource name (URN)
      (I) A URI that has an institutional commitment to persistence and
      availability.

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

   $ UORA
      See: user-PIN ORA.

   $ update
      See: certificate update and key update.

   $ URI
      See: uniform resource identifier.

   $ URL
      See: uniform resource locator.

   $ URN
      See: uniform resource name.

   $ user
      (I) A person, organization entity, or automated process that
      accesses a system, whether authorized to do so or not. (See:
      [R2504].)

      (C) Any ISD that uses this term SHOULD provide an explicit
      definition, because this term is used in many ways and can easily
      be misunderstood.

   $ User Datagram Protocol (UDP)
      (I) An Internet Standard protocol [R0768] that provides a datagram
      mode of packet-switched computer communication in an internetwork.

      (C) UDP is a transport layer protocol, and it 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 services that TCP provides.

   $ user identifier
      (I) A character string or symbol that is used in a system to
      uniquely name a specific user or group of users.
ToP   noToC   RFC2828 - Page 187
      (C) Often verified by a password in an authentication process.

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

   $ user-PIN ORA (UORA)
      (O) 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
      See: (secondary definition under) threat consequence.

   $ 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. Note: UTCTime
      has the Year 2000 problem. (See: Coordinated Universal Time,
      GeneralizedTime.)

   $ v1 certificate
      (C) Ambiguously refers to either an X.509 public-key certificate
      in its version 1 format, or an X.509 attribute certificate in its
      version 1 format. However, many people who use this term are not
      aware that X.509 specifies attribute certificates that do not
      contain a public key. Therefore, ISDs MAY use this term as an
      abbreviation for "version 1 X.509 public-key certificate", but
      only after using the full term at the first instance.

      (D) ISDs SHOULD NOT use this term as an abbreviation for "version
      1 X.509 attribute certificate".

   $ v1 CRL
      (I) An abbreviation for "X.509 CRL in version 1 format".

      (C) ISDs should use this abbreviation only after using the full
      term at its first occurrence and defining the abbreviation.

   $ v2 certificate
      (I) An abbreviation for "X.509 public-key certificate in version 2
      format".
ToP   noToC   RFC2828 - Page 188
      (C) ISDs should use this abbreviation only after using the full
      term at its first occurrence and defining the abbreviation.

   $ v2 CRL
      (I) An abbreviation for "X.509 CRL in version 2 format".

      (C) ISDs should use this abbreviation only after using the full
      term at its first occurrence and defining the abbreviation.

   $ v3 certificate
      (I) An abbreviation for "X.509 public-key certificate in version 3
      format".

      (C) ISDs should use this abbreviation only after using the full
      term at its first occurrence and defining the abbreviation.

   $ valid certificate
      (I) A digital certificate for which the binding of the data items
      can be trusted; one that can be validated successfully. (See:
      validate vs. verify.)

   $ valid signature
      (D) ISDs SHOULD NOT use this term; instead, use "authentic
      signature". 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
      vs. verify.)

   $ validate vs. verify
      (C) The PKI community uses words inconsistently when describing
      what a certificate user does to make certain that a digital
      certificate can be trusted. Usually, we say "verify the signature"
      but say "validate the certificate"; i.e., we "verify" atomic
      truths but "validate" data structures, relationships, and systems
      that are composed of or depend on verified items. Too often,
      however, verify and validate are used interchangeably.

      ISDs SHOULD comply with the following two rules to ensure
      consistency and to align Internet security terminology with
      ordinary English:

       - Rule 1: Use "validate" when referring to a process intended to
         establish the soundness or correctness of a construct. (E.g.,
         see: certificate validation.)

       - 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.,
         see: authenticate.)
ToP   noToC   RFC2828 - Page 189
      The rationale for Rule 1 is that "valid" derives from a word that
      means "strong" in Latin. Thus, to validate means to make sure that
      a construction is sound. A certificate user validates a public-key
      certificate to establish trust in the binding that the certificate
      asserts between an identity and a key. (To validate can also mean
      to officially approve something; e.g., NIST validates
      cryptographic modules for conformance with FIPS PUB 140-1.)

      The rationale for Rule 2 is that "verify" derives from a word that
      means "true" in Latin. Thus, to verify means to prove the truth of
      an assertion by examining evidence or performing tests. 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
      See: validate vs. verify.

   $ validity period
      (I) 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.

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

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

   $ VAN
      See: value-added network.

   $ verification
      1. System verification: The process of comparing two levels of
      system specification for proper correspondence, such as comparing
      a security policy with a top-level specification, a top-level
      specification with source code, or source code with object code.
      [NCS04]
ToP   noToC   RFC2828 - Page 190
      2. Identification verification: Presenting information to
      establish the truth of a claimed identity.

   $ verify
      See: validate vs. 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 (such as the
      Internet), often by using encryption (located at hosts or
      gateways), and often by tunneling links of the virtual network
      across the real network.

      (C) 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 (a) using encrypted tunnels to
      connect from firewall to firewall across the Internet and (b) not
      allowing any other traffic through the firewalls. 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 real network.

   $ virus
      (I) A hidden, self-replicating 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.

   $ VPN
      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.

      (C) Most systems have vulnerabilities of some sort, 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
ToP   noToC   RFC2828 - Page 191
      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 benefit for someone to make an attack.

   $ W3
      See: World Wide Web.

   $ war dialer
      (I) 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 into the
      systems.

   $ 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.)

      (C) The Arrangement began operations in September 1996. The
      participating countries are 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. Participants meet on a regular basis in Vienna,
      where the Arrangement has its headquarters.

      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
ToP   noToC   RFC2828 - Page 192
      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.

   $ web of trust
      (O) PGP usage: A trust-file PKI technique used in PGP for building
      a file of validated public keys by making personal judgments about
      being able to trust certain people to be holding properly
      certified keys of other people. (See: certification hierarchy,
      mesh PKI.)

   $ web server
      (I) A software process that runs on a host computer connected to
      the Internet to respond to HTTP requests for documents from client
      web browsers.

   $ web vs. Web
      1. (I) Capitalized: ISDs 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 vs. Internet.)

      2. (C) Not capitalized: ISDs 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.

      (C) IETF documents SHOULD spell out "World Wide Web" fully at the
      first instance of usage and SHOULD Use "Web" and "web" especially
      carefully where confusion with the PGP "web of trust" is possible.

   $ wiretapping
      (I) An attack that intercepts and accesses data and other
      information contained in a flow in a communication system.

      (C) 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 reading information from any sort of medium
      used for a link or even directly from a node, such as gateway or
      subnetwork switch.
ToP   noToC   RFC2828 - Page 193
      (C) "Active wiretapping" attempts to alter the data or otherwise
      affect the flow; "passive wiretapping" only attempts to observe
      the flow and gain knowledge of information it contains. (See:
      active attack, end-to-end encryption, passive attack.)

   $ work factor
      (I) General security usage: 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.

      (I) Cryptography usage: The estimated amount of computing time and
      power needed to break a cryptographic system.

   $ World Wide Web ("the Web", WWW, W3)
      (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].)

   $ 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 computer resources destructively. (See: Morris
      Worm, virus.)

   $ wrap
      (O) To use cryptography to provide data confidentiality service
      for a data object. (See: encrypt, seal.)

      (D) ISDs SHOULD NOT use this term with this definition because it
      duplicates the meaning of other, standard terms. Instead, use
      "encrypt" or use a term that is specific with regard to the
      mechanism used.

   $ WWW
      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
   $ X.500 Directory
      (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
ToP   noToC   RFC2828 - Page 194
      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.)

      (C) 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 services, 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.)

      (C) X.509 describes two levels of authentication: simple
      authentication based on a password, and strong authentication
      based on a public-key certificate.

   $ 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.)

      (C) 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.

      (C) An X.509 attribute certificate contains a sequence of data
      items and has a digital signature that is computed from that
      sequence. In addition to the signature, an attribute certificate
      contains items 1 through 9 listed below:
ToP   noToC   RFC2828 - Page 195
      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 authority revocation list
      (N) An ARL in one of the formats defined by X.509--version 1 (v1)
      or version 2 (v2). A specialized kind of certificate revocation
      list.

   $ X.509 certificate
      (N) Either an X.509 public-key certificate or an X.509 attribute
      certificate.

      (C) This Glossary uses the term with the precise meaning
      recommended here. However, some who use the term may not be aware
      that X.509 specifies attribute certificates that do not contain a
      public key. Even among those who are aware, this term is commonly
      used as an abbreviation to mean "X.509 public-key certificate".
      ISDs MAY use the term as an abbreviation for "X.509 public-key
      certificate", but only after using the full term at the first
      instance.

      (D) ISDs SHOULD NOT use this term as an abbreviation to mean
      "X.509 attribute certificate".

   $ 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.)

      (C) ISDs SHOULD NOT refer to an X.509 CRL as a digital
      certificate, but note that an X.509 CRL does meet this Glossary's
      definition of "digital certificate". Like a digital certificate,
ToP   noToC   RFC2828 - Page 196
      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.

      (C) An X.509 CRL contains a sequence of data items and has a
      digital signature computed on that sequence. In addition to 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.)

      (C) An X.509 public-key certificate contains a sequence of data
      items and has a digital signature computed on that sequence. In
      addition to 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.
ToP   noToC   RFC2828 - Page 197
   $ XTACACS
      See: (secondary definition under) Terminal Access Controller (TAC)
      Access Control System.

   $ Yellow Book
      (D) ISDs SHOULD NOT use this term as a synonym for "Computer
      Security Requirements: Guidance for Applying the Department of
      Defense Trusted Computer System Evaluation Criteria in Specific
      Environments" [CSC3]. Instead, use the full proper name of the
      document or, in subsequent references, a conventional
      abbreviation. (See: (usage note under) Green Book, Rainbow
      Series.)

   $ zeroize
      (I) Use erasure or other means to render stored data unusable and
      unrecoverable, particularly a key stored in a cryptographic module
      or other device.

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



(page 197 continued on part 8)

Next Section