$ 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.)
(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"
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.)
$ 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.
(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.
$ 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.
$ 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.
(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".
(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.)
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]
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
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
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.
(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
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:
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,
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.
$ 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]