https://DevOpsCloud.io -- Cloud Monk Losang Jinpa

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

---

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

---

• v1 certificate

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

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

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

---

• v1 CRL

( N) Abbreviation of “X.509 CRL in version 1 format”.

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

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

---

• v2 certificate

( N) Abbreviation of “X.509 public-key certificate in version 2 format”.

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

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

---

• v2 CRL

( N) Abbreviation of “X.509 CRL in version 2 format”.

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

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

---

• v3 certificate

( N) Abbreviation of “X.509 public-key certificate in version 3 format”.

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

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

---

• valid certificate

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

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

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

---

• valid signature

(D) Synonym for “verified signature”.

Shirey Informational Page 330]

RFC 4949 Internet Security Glossary, Version 2 August 2007

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

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

---

• validate

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

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

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

---

• validate vs. verify

Usage: To ensure consistency and align with ordinary English usage, IDOCs SHOULD comply with the following two rules:

• Rule 1: Use “validate” when referring to a process intended to

establish the soundness or correctness of a construct (e.g., “certificate validation”). (See: validate.)

• Rule 2: Use “verify” when referring to a process intended to

test or prove the truth or accuracy of a fact or value (e.g., “authenticate”). (See: verify.)

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

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

The word “verify” derives from a Latin word that means “true”. Thus, to verify means to check the truth of an assertion by examining evidence or performing tests. For example, to verify an id[[entity, 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

Shirey Informational Page 331]

RFC 4949 Internet Security Glossary, Version 2 August 2007

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

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

---

• validation

(I) See: validate vs. verify.

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

---

• validity period

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

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

---

• value-added network (VAN)

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

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

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

---

• VAN

(I) See: value-added network.

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

---

• verification

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

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

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

---

• verified design

(O) See: TCSEC Class A1.

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

---

• verify

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

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

---

• vet

(I) /verb/ To examine or evaluate thoroughly. (Compare: authenticate, id[[entity proofing, validate, verify.)

Shirey Informational Page 332]

RFC 4949 Internet Security Glossary, Version 2 August 2007

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

---

• violation

See: security violation.

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

---

• virtual private network (VPN)

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

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

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

---

• virus

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

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

---

• Visa Cash

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

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

---

• volatile media

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

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

---

• VPN - (I) See: virtual private network. (Fair Use Source: RFC 4949]) ---- * [[vulnerability

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

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

Shirey Informational Page 333]

RFC 4949 Internet Security Glossary, Version 2 August 2007

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

• RFC 4949 Internet Security Glossary