U <- 4. Definitions -> W
V
RFC 4949 Internet Security Glossary, Version 2 August 2007
$ v1 certificate
(N) An abbreviation that ambiguously refers to either an "X.509
public-key certificate in version 1 format" or an "X.509 attribute
certificate in version 1 format".
Deprecated Usage: IDOCs MAY use this term as an abbreviation of
"version 1 X.509 public-key certificate", but only after using the
full term at the first instance. Otherwise, the term is ambiguous,
because X.509 specifies both v1 public-key certificates and v1
attribute certificates. (See: X.509 attribute certificate, X.509
public-key certificate.)
$ v1 CRL
(N) Abbreviation of "X.509 CRL in version 1 format".
Usage: IDOCs MAY use this abbreviation, but SHOULD use the full
term at its first occurrence and define the abbreviation there.
$ v2 certificate
(N) Abbreviation of "X.509 public-key certificate in version 2
format".
Usage: IDOCs MAY use this abbreviation, but SHOULD use the full
term at its first occurrence and define the abbreviation there.
$ v2 CRL
(N) Abbreviation of "X.509 CRL in version 2 format".
Usage: IDOCs MAY use this abbreviation, but SHOULD use the full
term at its first occurrence and define the abbreviation there.
$ v3 certificate
(N) Abbreviation of "X.509 public-key certificate in version 3
format".
Usage: IDOCs MAY use this abbreviation, but SHOULD use the full
term at its first occurrence and define the abbreviation there.
$ valid certificate
1. (I) A digital certificate that can be validated successfully.
(See: validate, verify.)
2. (I) A digital certificate for which the binding of the data
items can be trusted.
$ valid signature
(D) Synonym for "verified signature".
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.)
$ validate
1. (I) Establish the soundness or correctness of a construct.
Example: certificate validation. (See: validate vs. verify.)
2. (I) To officially approve something, sometimes in relation to a
standard. Example: NIST validates cryptographic modules for
conformance with [FP140].
$ validate vs. verify
Usage: To ensure consistency and align with ordinary English
usage, IDOCs SHOULD comply with the following two rules:
- Rule 1: Use "validate" when referring to a process intended to
establish the soundness or correctness of a construct (e.g.,
"certificate validation"). (See: validate.)
- Rule 2: Use "verify" when referring to a process intended to
test or prove the truth or accuracy of a fact or value (e.g.,
"authenticate"). (See: verify.)
Tutorial: The Internet security community sometimes uses these two
terms inconsistently, especially in a PKI context. Most often,
however, we say "verify the signature" but say "validate the
certificate". That is, we "verify" atomic truths but "validate"
data structures, relationships, and systems that are composed of
or depend on verified items. This usage has a basis in Latin:
The word "valid" derives from a Latin word that means "strong".
Thus, to validate means to check that a construct is sound. For
example, a certificate user validates a public-key certificate to
establish trust in the binding that the certificate asserts
between an identity and a key. This can include checking various
aspects of the certificate's construction, such as verifying the
digital signature on the certificate by performing calculations,
verifying that the current time is within the certificate's
validity period, and validating a certification path involving
additional certificates.
The word "verify" derives from a Latin word that means "true".
Thus, to verify means to check the truth of an assertion by
examining evidence or performing tests. For example, to verify an
identity, an authentication process examines identification
information that is presented or generated. To validate a
certificate, a certificate user verifies the digital signature on
the certificate by performing calculations, verifies that the
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.
$ validation
(I) See: validate vs. verify.
$ validity period
(I) /PKI/ A data item in a digital certificate that specifies the
time period for which the binding between data items (especially
between the subject name and the public key value in a public-key
certificate) is valid, except if the certificate appears on a CRL
or the key appears on a CKL. (See: cryptoperiod, key lifetime.)
$ value-added network (VAN)
(I) A computer network or subnetwork (usually a commercial
enterprise) that transmits, receives, and stores EDI transactions
on behalf of its users.
Tutorial: A VAN may also provide additional services, ranging from
EDI format translation, to EDI-to-FAX conversion, to integrated
business systems.
$ VAN
(I) See: value-added network.
$ verification
1. (I) /authentication/ The process of examining information to
establish the truth of a claimed fact or value. (See: validate vs.
verify, verify. Compare: authentication.)
2. (N) /COMPUSEC/ The process of comparing two levels of system
specification for proper correspondence, such as comparing a
security model with a top-level specification, a top-level
specification with source code, or source code with object code.
[NCS04]
$ verified design
(O) See: TCSEC Class A1.
$ verify
(I) To test or prove the truth or accuracy of a fact or value.
(See: validate vs. verify, verification. Compare: authenticate.)
$ vet
(I) /verb/ To examine or evaluate thoroughly. (Compare:
authenticate, identity proofing, validate, verify.)
Shirey Informational [Page 332]
RFC 4949 Internet Security Glossary, Version 2 August 2007
$ violation
See: security violation.
$ virtual private network (VPN)
(I) A restricted-use, logical (i.e., artificial or simulated)
computer network that is constructed from the system resources of
a relatively public, physical (i.e., real) network (e.g., the
Internet), often by using encryption (located at hosts or
gateways), and often by tunneling links of the virtual network
across the real network. (See: tunnel.)
Tutorial: A VPN is generally less expensive to build and operate
than a dedicated real network, because the virtual network shares
the cost of system resources with other users of the underlying
real network. For example, if a corporation has LANs at several
different sites, each connected to the Internet by a firewall, the
corporation could create a VPN by using encrypted tunnels to
connect from firewall to firewall across the Internet.
$ virus
(I) A self-replicating (and usually hidden) section of computer
software (usually malicious logic) that propagates by infecting --
i.e., inserting a copy of itself into and becoming part of --
another program. A virus cannot run by itself; it requires that
its host program be run to make the virus active.
$ Visa Cash
(O) A smartcard-based electronic money system that incorporates
cryptography and can be used to make payments via the Internet.
(See: IOTP.)
$ volatile media
(I) Storage media that require an external power supply to
maintain stored information. (Compare: non-volatile media,
permanent storage.)
$ VPN
(I) See: virtual private network.
$ vulnerability
(I) A flaw or weakness in a system's design, implementation, or
operation and management that could be exploited to violate the
system's security policy. (See: harden.)
Tutorial: A system can have three types of vulnerabilities: (a)
vulnerabilities in design or specification; (b) vulnerabilities in
implementation; and (c) vulnerabilities in operation and
management. Most systems have one or more vulnerabilities, but
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.
U <- 4. Definitions -> W