https://DevOpsCloud.io -- Cloud Monk Losang Jinpa, Ph.D., MCSE/MCT, GitOps DevOps Engineer

Return to RFC 4949 Internet Security Glossary Definitions, RFC 4949 Internet Security Glossary, RFC 4949 Internet Security Glossary Bibliography, Cybersecurity, Awesome Security

---

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• e-cash

(O) Electronic cash; money that is in the form of data and can be used as a payment mechanism on the Internet. (See: IOTP.)

Usage: IDOCs that use this term SHOULD state a definition for it because many different types of electronic cash have been devised with a variety of security mechanisms.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• EAP

(I) See: Extensible Authentication Protocol.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• EAL

(O) See: evaluation assurance level.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• Easter egg

(O) “Hidden functionality within an application program, which becomes activated when an undocumented, and often convoluted, set of commands and keystrokes is entered. Easter eggs are typically used to display the credits for the development team and [are] intended to be non-threatening” [SP28], but Easter eggs have the potential to contain malicious code.

Deprecated Usage: It is likely that other cultures use different metaphors for this concept. Therefore, to avoid international misunderstanding, IDOCs SHOULD NOT use this term. (See: Deprecated Usage under “Green Book”.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• eavesdropping

(I) Passive wiretapping done secretly, i.e., without the knowledge of the originator or the intended recipients of the communication.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• ECB

(N) See: electronic codebook.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• ECDSA

(N) See: Elliptic Curve Digital Signature Algorithm.

Shirey Informational Page 114]

RFC 4949 Internet Security Glossary, Version 2 August 2007

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• economy of alternatives

(I) The principle that a security mechanism should be designed to minimize the number of alternative ways of achieving a service. (Compare: economy of mechanism.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• economy of mechanism

(I) The principle that a security mechanism should be designed to be as simple as possible, so that (a) the mechanism can be correctly implemented and (b) it can be verified that the operation of the mechanism enforces the system's security policy. (Compare: economy of alternatives, least privilege.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• ECU

(N) See: end cryptographic unit.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• EDI

(I) See: electronic data interchange.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• EDIFACT

(N) See: secondary definition under “electronic data interchange”.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• EE

(D) Abbreviation of “end entity” and other terms.

Deprecated Abbreviation: IDOCs SHOULD NOT use this abbreviation; there could be confusion among “end entity”, “end-to-end encryption”, “escrowed encryption standard”, and other terms.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• EES

(O) See: Escrowed Encryption Standard.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• effective key length

(O) “A measure of strength of a cryptographic algorithm, regardless of actual key length.” [IATF] (See: work factor.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• effectiveness

(O) /ITSEC/ A property of a TOE representing how well it provides security in the context of its actual or proposed operational use.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• El Gamal algorithm

(N) An algorithm for asymmetric cryptography, invented in 1985 by Taher El Gamal, that is based on the difficulty of calculating discrete logarithms and can be used for both encryption and digital signatures. [ElGa]

Shirey Informational Page 115]

RFC 4949 Internet Security Glossary, Version 2 August 2007

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• electronic codebook (ECB)

(N) A block cipher mode in which a plaintext block is used directly as input to the encryption algorithm and the resultant output block is used directly as cipher text [FP081]. (See: block cipher, [SP38A].)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• electronic commerce

1. (I) Business conducted through paperless exchanges of information, using electronic data interchange, electronic funds transfer (EFT), electronic mail, computer bulletin boards, facsimile, and other paperless technologies.

2. (O) /SET/ “The exchange of goods and services for payment between the cardholder and merchant when some or all of the transaction is performed via electronic communication.” [SET2]

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• electronic data interchange (EDI)

(I) Computer-to-computer exchange, between trading partners, of business data in standardized document formats.

Tutorial: EDI formats have been standardized primarily by ANSI X12 and by EDIFACT (EDI for Administration, Commerce, and Transportation), which is an international, UN-sponsored standard primarily used in Europe and Asia. X12 and EDIFACT are aligning to create a single, global EDI standard.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• Electronic Key Management System (EKMS)

(O) “Interoperable collection of systems developed by … the U.S. Government to automate the planning, ordering, generating, distributing, storing, filling, using, and destroying of electronic keying material and the management of other types of COMSEC material.” [C4009]

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• electronic signature

(D) Synonym for “digital signature” or “digitized signature”.

Deprecated Term: IDOCs SHOULD NOT use this term; there is no current consensus on its definition. Instead, use “digital signature”, if that is what was intended

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• electronic wallet

(D) A secure container to hold, in digitized form, some sensitive data objects that belong to the owner, such as electronic money, authentication material, and various types of personal information. (See: IOTP.)

Deprecated Term: IDOCs SHOULD NOT use this term. There is no current consensus on its definition; and some uses and definitions

Shirey Informational Page 116]

RFC 4949 Internet Security Glossary, Version 2 August 2007

may be proprietary. Meanings range from virtual wallets implemented by data structures to physical wallets implemented by cryptographic tokens. (See: Deprecated Usage under “Green Book”.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• elliptic curve cryptography (ECC)

(I) A type of asymmetric cryptography based on mathematics of groups that are defined by the points on a curve, where the curve is defined by a quadratic equation in a finite field. [Schn]

Tutorial: ECC is based on mathematics different than that originally used to define the Diffie-Hellman-Merkle algorithm and the DSA, but ECC can be used to define an algorithm for key agreement that is an analog of Diffie-Hellman-Merkle [A9063] and an algorithm for digital signature that is an analog of DSA [A9062]. The mathematical problem upon which ECC is based is believed to be more difficult than the problem upon which Diffie- Hellman-Merkle is based and, therefore, that keys for ECC can be shorter for a comparable level of security. (See: ECDSA.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• Elliptic Curve Digital Signature Algorithm (ECDSA)

(N) A standard [A9062] that is the analog, in elliptic curve cryptography, of the Digital Signature Algorithm.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• emanation

(I) A signal (e.g., electromagnetic or acoustic) that is emitted by a system (e.g., through radiation or conductance) as a consequence (i.e., byproduct) of the system's operation, and that may contain information. (See: emanations security.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• emanations analysis

(I) /threat action/ See: secondary definition under “interception”.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• emanations security (EMSEC)

(I) Physical security measures to protect against data compromise that could occur because of emanations that might be received and read by an unauthorized party. (See: emanation, TEMPEST.)

Usage: Refers either to preventing or limiting emanations from a system and to preventing or limiting the ability of unauthorized parties to receive the emissions.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• embedded cryptography

(N) “Cryptography engineered into an equipment or system whose basic function is not cryptographic.” [C4009]

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• emergency plan

(D) Synonym for “contingency plan”.

Shirey Informational Page 117]

RFC 4949 Internet Security Glossary, Version 2 August 2007

Deprecated Term: IDOCs SHOULD NOT use this term. Instead, for neutrality and consistency of language, use “contingency plan”.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• emergency response

(O) An urgent response to a fire, flood, civil commotion, natural disaster, bomb threat, or other serious situation, with the intent of protecting lives, limiting damage to property, and minimizing disruption of system operations. [FP087] (See: availability, CERT, emergency plan.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• EMSEC

(I) See: emanations security.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• EMV

(N) Abbreviation of “Europay, MasterCard, Visa”. Refers to a specification for smart cards that are used as payment cards, and for related terminals and applications. [EMV1, EMV2, EMV3]

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• Encapsulating Security Payload (ESP)

(I) An Internet protocol [R2406, R4303] designed to provide data confidentiality service and other security services for IP datagrams. (See: IPsec. Compare: AH.)

Tutorial: ESP may be used alone, or in combination with AH, or in a nested fashion with tunneling. Security services can be provided between a pair of communicating hosts, between a pair of communicating security gateways, or between a host and a gateway. The ESP header is encapsulated by the IP header, and the ESP header encapsulates either the upper-layer protocol header (transport mode) or an IP header (tunnel mode). ESP can provide data confidentiality service, data origin authentication service, connectionless data integrity service, an anti-replay service, and limited traffic-flow confidentiality. The set of services depends on the placement of the implementation and on options selected when the security association is established.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• encipher

(D) Synonym for “encrypt”.

Deprecated Definition: IDOCs SHOULD NOT use this term as a synonym for “encrypt”. However, see Usage note under “encryption”.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• encipherment

(D) Synonym for “encryption”.

Deprecated Definition: IDOCs SHOULD NOT use this term as a synonym for “encryption”. However, see Usage note under “encryption”.

Shirey Informational Page 118]

RFC 4949 Internet Security Glossary, Version 2 August 2007

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• enclave

1. (I) A set of system resources that operate in the same security domain and that share the protection of a single, common, continuous security perimeter. (Compare: domain.)

2. (D) /U.S. Government/ “Collection of computing environments connected by one or more internal networks under the control of a single authority and security policy, including personnel and physical security.” [C4009]

Deprecated Definition: IDOCs SHOULD NOT use this term with definition 2 because the definition applies to what is usually called a “security domain”. That is, a security domain is a set of one or more security enclaves.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• encode

1. (I) Use a system of symbols to represent information, which might originally have some other representation. Example: Morse code. (See: ASCII, BER.) (See: code, decode.)

2. (D) Synonym for “encrypt”.

Deprecated Definition: IDOCs SHOULD NOT use this term as a synonym for “encrypt”; encoding is not always meant to conceal meaning.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• encrypt

(I) Cryptographically transform data to produce cipher text. (See: encryption. Compare: seal.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• encryption

1. (I) Cryptographic transformation of data (called “plain text”) into a different form (called “cipher text”) that conceals the data's original meaning and prevents the original form from being used. The corresponding reverse process is “decryption”, a transformation that restores encrypted data to its original form. (See: cryptography.)

2. (O) “The cryptographic transformation of data to produce ciphertext.” [I7498-2]

Usage: For this concept, IDOCs SHOULD use the verb “to encrypt” (and related variations: encryption, decrypt, and decryption). However, because of cultural biases involving human burial, some international documents (particularly ISO and CCITT standards) avoid “to encrypt” and instead use the verb “to encipher” (and related variations: encipherment, decipher, decipherment).

Shirey Informational Page 119]

RFC 4949 Internet Security Glossary, Version 2 August 2007

Tutorial: Usually, the plaintext input to an encryption operation is clear text. But in some cases, the plain text may be cipher text that was output from another encryption operation. (See: superencryption.)

Encryption and decryption involve a mathematical algorithm for transforming data. Besides the data to be transformed, the algorithm has one or more inputs that are control parameters: (a) a key that varies the transformation and, in some cases, (b) an IV that establishes the starting state of the algorithm.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• encryption certificate

(I) A public-key certificate that contains a public key that is intended to be used for encrypting data, rather than for verifying digital signatures or performing other cryptographic functions.

Tutorial: A v3 X.509 public-key certificate may have a “keyUsage” extension that indicates the purpose for which the certified public key is intended. (See: certificate profile.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• end cryptographic unit (ECU)

1. (N) Final destination device into which a key is loaded for operational use.

2. (N) A device that (a) performs cryptographic functions, (b) typically is part of a larger system for which the device provides security services, and ©, from the viewpoint of a supporting security infrastructure such as a key management system, is the lowest level of identifiable component with which a management transaction can be conducted

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• end entity

1. (I) A system entity that is the subject of a public-key certificate and that is using, or is permitted and able to use, the matching private key only for purposes other than signing a digital certificate; i.e., an entity that is not a CA.

2. (O) “A certificate subject [that] uses its public [sic] key for purposes other than signing certificates.” [X509]

Deprecated Definition: IDOCs SHOULD NOT use definition 2, which is misleading and incomplete. First, that definition should have said “private key” rather than “public key” because certificates are not usefully signed with a public key. Second, the X.509 definition is ambiguous regarding whether an end entity may or may not use the private key to sign a certificate, i.e., whether the subject may be a CA. The intent of X.509's authors was that an end entity certificate is not valid for use in verifying a signature

Shirey Informational Page 120]

RFC 4949 Internet Security Glossary, Version 2 August 2007

on an X.509 certificate or X.509 CRL. Thus, it would have been better for the X.509 definition to have said “only for purposes other than signing certificates”.

Usage: Despite the problems in the X.509 definition, the term itself is useful in describing applications of asymmetric cryptography. The way the term is used in X.509 implies that it was meant to be defined, as we have done here, relative to roles that an entity (which is associated with an OSI end system) is playing or is permitted to play in applications of asymmetric cryptography other than the PKI that supports applications.

Tutorial: Whether a subject can play both CA and non-CA roles, with either the same or different certificates, is a matter of policy. (See: CPS.) A v3 X.509 public-key certificate may have a “basicConstraints” extension containing a “cA” value that specifically “indicates whether or not the public key may be used to verify certificate signatures”. (See: certificate profile.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• end system

(N) /OSIRM/ A computer that implements all seven layers of the OSIRM and may attach to a subnetwork. Usage: In the IPS context, an end system is called a “host”.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• end-to-end encryption

(I) Continuous protection of data that flows between two points in a network, effected by encrypting data when it leaves its source, keeping it encrypted while it passes through any intermediate computers (such as routers), and decrypting it only when it arrives at the intended final destination. (See: wiretapping. Compare: link encryption.)

Examples: A few are BLACKER, CANEWARE, IPLI, IPsec, PLI, SDNS, SILS, SSH, SSL, TLS.

Tutorial: When two points are separated by multiple communication links that are connected by one or more intermediate relays, end- to-end encryption enables the source and destination systems to protect their communications without depending on the intermediate systems to provide the protection.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• end user

1. (I) /information system/ A system entity, usually a human individual, that makes use of system resources, primarily for application purposes as opposed to system management purposes.

2. (D) /PKI/ Synonym for “end entity”.

Shirey Informational Page 121]

RFC 4949 Internet Security Glossary, Version 2 August 2007

Deprecated Definition: IDOCs SHOULD NOT use “end user” as a synonym for “end entity”, because that would mix concepts in a potentially misleading way.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• endorsed-for-unclassified cryptographic item (EUCI)

(O) /U.S. Government/ “Unclassified cryptographic equipment that embodies a U.S. Government classified cryptographic logic and is endorsed by NSA for the protection of national security information.” [C4009] (Compare: CCI, type 2 product.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• entity

See: system entity.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• entrapment

(I) “The deliberate planting of apparent flaws in a system for the purpose of detecting attempted penetrations or confusing an intruder about which flaws to exploit.” [FP039] (See: honey pot.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• entropy

1. (I) An information-theoretic measure (usually stated as a number of bits) of the amount of uncertainty that an attacker faces to determine the value of a secret. [SP63] (See: strength.)

Example: If a password is said to contain at least 20 bits of entropy, that means that it must be as hard to find the password as to guess a 20-bit random number.

2. (I) An information-theoretic measure (usually stated as a number of bits) of the amount of information in a message; i.e., the minimum number of bits needed to encode all possible meanings of that message. [Schn] (See: uncertainty.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• ephemeral

(I) /adjective/ Refers to a cryptographic key or other cryptographic parameter or data object that is short-lived, temporary, or used one time. (See: session key. Compare: static.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• erase

1. (I) Delete stored data. (See: sanitize, zeroize.)

2. (O) /U.S. Government/ Delete magnetically stored data in such a way that the data cannot be recovered by ordinary means, but might be recoverable by laboratory methods. [C4009] (Compare: /U.S. Government/ purge.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• error detection code

(I) A checksum designed to detect, but not correct, accidental (i.e., unintentional) changes in data.

Shirey Informational Page 122]

RFC 4949 Internet Security Glossary, Version 2 August 2007

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• Escrowed Encryption Standard (EES)

(N) A U.S. Government standard [FP185] that specifies how to use a symmetric encryption algorithm (SKIPJACK) and create a Law Enforcement Access Field (LEAF) for implementing part of a key escrow system that enables decryption of telecommunications when interception is lawfully authorized.

Tutorial: Both SKIPJACK and the LEAF are intended for use in equipment used to encrypt and decrypt sensitive, unclassified, telecommunications data.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• ESP

(I) See: Encapsulating Security Payload.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• Estelle

(N) A language (ISO 9074-1989) for formal specification of computer network protocols.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• ETSI

(N) See: European Telecommunication Standards Institute.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• EUCI

(O) See: endorsed-for-unclassified cryptographic item.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• European Telecommunication Standards Institute (ETSI)

(N) An independent, non-profit organization, based in France, that is officially recognized by the European Commission and responsible for standardization of information and communication technologies within Europe.

Tutorial: ETSI maintains the standards for a number of security algorithms, including encryption algorithms for mobile telephone systems in Europe.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• evaluated system

(I) A system that has been evaluated against security criteria (for example, against the TCSEC or against a profile based on the Common Criteria).

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• evaluation

(I) Assessment of an information system against defined security criteria (for example, against the TCSEC or against a profile based on the Common Criteria). (Compare: certification.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• evaluation assurance level (EAL)

(N) A predefined package of assurance components that represents a point on the Common Criteria's scale for rating confidence in the security of information technology products and systems.

Shirey Informational Page 123]

RFC 4949 Internet Security Glossary, Version 2 August 2007

Tutorial: The Common Criteria defines a scale of seven, hierarchically ordered EALs for rating a TOE. From highest to lowest, they are as follows: - EAL7. Formally verified design and tested. - EAL6. Semiformally verified design and tested. - EAL5. Semiformally designed and tested. - EAL4. Methodically designed, tested, and reviewed. - EAL3. Methodically tested and checked. - EAL2. Structurally tested. - EAL1. Functionally tested.

An EAL is a consistent, baseline set of requirements. The increase in assurance from EAL to EAL is accomplished by substituting higher assurance components (i.e., criteria of increasing rigor, scope, or depth) from seven assurance classes: (a) configuration management, (b) delivery and operation, © development, (d) guidance documents, (e) lifecycle support, (f) tests, and (g) vulnerability assessment.

The EALs were developed with the goal of preserving concepts of assurance that were adopted from earlier criteria, so that results of previous evaluations would remain relevant. For example, EALs levels 2-7 are generally equivalent to the assurance portions of the TCSEC C2-A1 scale. However, this equivalency should be used with caution. The levels do not derive assurance in the same manner, and exact mappings do not exist.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• expire

(I) /credential/ Cease to be valid (i.e., change from being valid to being invalid) because its assigned lifetime has been exceeded. (See: certificate expiration.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• exposure

(I) A type of threat action whereby sensitive data is directly released to an unauthorized entity. (See: unauthorized disclosure.)

Usage: This type of threat action includes the following subtypes: - “Deliberate Exposure”: Intentional release of sensitive data to an unauthorized entity. - “Scavenging”: Searching through data residue in a system to gain unauthorized knowledge of sensitive data. - “Human error”: /exposure/ Human action or inaction that unintentionally results in an entity gaining unauthorized knowledge of sensitive data. (Compare: corruption, incapacitation.) - “Hardware or software error”: /exposure/ System failure that unintentionally results in an entity gaining unauthorized

Shirey Informational Page 124]

RFC 4949 Internet Security Glossary, Version 2 August 2007

knowledge of sensitive data. (Compare: corruption, incapacitation.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• Extended Security Option

(I) See: secondary definition under “IPSO”.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• Extensible Authentication Protocol (EAP)

(I) An extension framework for PPP that supports multiple, optional authentication mechanisms, including cleartext passwords, challenge-response, and arbitrary dialog sequences. [R3748] (Compare: GSS-API, SASL.)

Tutorial: EAP typically runs directly over IPS data link protocols or OSIRM Layer 2 protocols, i.e., without requiring IP. Originally, EAP was developed for use in PPP, by a host or router that connects to a network server via switched circuits or dial-up lines. Today, EAP's domain of applicability includes other areas of network access control; it is used in wired and wireless LANs with IEEE 802.1X, and in IPsec with IKEv2. EAP is conceptually related to other authentication mechanism frameworks, such as SASL and GSS-API.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• Extensible Markup Language (XML)

(N) A version of Standard Generalized Markup Language (ISO 8879) that separately represents a document's content and its structure. XML was designed by W3C for use on the World Wide Web.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• extension

(I) /protocol/ A data item or a mechanism that is defined in a protocol to extend the protocol's basic or original functionality.

Tutorial: Many protocols have extension mechanisms, and the use of these extension is usually optional. IP and X.509 are two examples of protocols that have optional extensions. In IP version 4, extensions are called “options”, and some of the options have security purposes (see: IPSO).

In X.509, certificate and CRL formats can be extended to provide methods for associating additional attributes with subjects and public keys and for managing a certification hierarchy: - A “certificate extension”: X.509 defines standard extensions that may be included in v3 certificates to provide additional key and security policy information, subject and issuer attributes, and certification path constraints. - A “CRL extension”: X.509 defines extensions that may be included in v2 CRLs to provide additional issuer key and name information, revocation reasons and constraints, and information about distribution points and delta CRLs.

Shirey Informational Page 125]

RFC 4949 Internet Security Glossary, Version 2 August 2007

- A “private extension”: Additional extensions, each named by an OID, can be locally defined as needed by applications or communities. (See: Authority Information Access extension, SET private extensions.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• external controls

(I) /COMPUSEC/ Refers to administrative security, personnel security, and physical security. (Compare: internal controls.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• extranet

(I) A computer network that an organization uses for application data traffic between the organization and its business partners. (Compare: intranet.)

Tutorial: An extranet can be implemented securely, either on the Internet or using Internet technology, by constructing the extranet as a VPN.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• extraction resistance

(O) Ability of cryptographic equipment to resist efforts to extract keying material directly from the equipment (as opposed to gaining knowledge of keying material by cryptanalysis). [C4009]

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• extrusion detection

(I) Monitoring for unauthorized transfers of sensitive information and other communications that originate inside a system's security perimeter and are directed toward the outside; i.e., roughly the opposite of “intrusion detection”.

---

Fair Use Sources:

• RFC 4949 Internet Security Glossary