Table of Contents
RFC 4949 Internet Security Glossary Definitions C
Return to RFC 4949 Internet Security Glossary Definitions, RFC 4949 Internet Security Glossary, RFC 4949 Internet Security Glossary Bibliography, Cybersecurity, Awesome Security
RFC 4949: #, A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z (navbar_rfc4949)
([[Fair Use]] [[Source]]: [[RFC 4949])
- C field
(D) See: Compartments field.
([[Fair Use]] [[Source]]: [[RFC 4949])
(O) /TCSEC/ See: Tutorial under “Trusted Computer System Evaluation Criteria”.
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) See: certification authority.
RFC 4949 Internet Security Glossary, Version 2 August 2007
([[Fair Use]] [[Source]]: [[RFC 4949])
(D) “A digital certificate for one CA issued by another CA.” [X509]
Deprecated Definition: IDOCs SHOULD NOT use the term with this definition; the definition is ambiguous with regard to how the certificate is constructed and how it is intended to be used. IDOCs that use this term SHOULD provide a technical definition for it. (See: certificate profile.)
Tutorial: There is no single, obvious choice for a technical definition of this term. Different PKIs can use different certificate profiles, and X.509 provides several choices of how to issue certificates to CAs. For example, one possible definition is the following: A v3 X.509 public-key certificate that has a “basicConstraints” extension containing a “cA” value of “TRUE”. That would specifically indicate that “the certified public key may be used to verify certificate signatures”, i.e., that the private key may be used by a CA.
However, there also are other ways to indicate such usage. The certificate may have a “key Usage” extension that indicates the purposes for which the public key may be used, and one of the values that X.509 defines for that extension is “keyCertSign”, to indicate that the certificate may be used for verifying a CA's signature on certificates. If “keyCertSign” is present in a certificate that also has a “basicConstraints” extension, then “cA” is set to “TRUE” in that extension. Alternatively, a CA could be issued a certificate in which “keyCertSign” is asserted without “basicConstraints” being present; and an entity that acts as a CA could be issued a certificate with “keyUsage” set to other values, either with or without “keyCertSign”.
([[Fair Use]] [[Source]]: [[RFC 4949])
(N) /PKI/ A security policy domain that “consists of a CA and its subjects [i.e., the entities named in the certificates issued by the CA. Sometimes referred to as a PKI domain.” [PAG] (See: domain.)
([[Fair Use]] [[Source]]: [[RFC 4949])
- Caesar cipher
(I) A cipher that is defined for an alphabet of N characters, A(1), A(2), …, A(N), and creates cipher text by replacing each plaintext character A(i) by A(i+K, mod N) for some 0<K<N+1. [Schn]
Examples: (a) During the Gallic wars, Julius Caesar used a cipher with K=3. In a Caesar cipher with K=3 for the English alphabet, A is replaced by D, B by E, C by F, …, W by Z, X by A, Y by B, Z
RFC 4949 Internet Security Glossary, Version 2 August 2007
by C. (b) UNIX systems sometimes include “ROT13” software that implements a Caesar cipher with K=13 (i.e., ROTate by 13).
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) An authentication technique for terminals that remotely access a computer via telephone lines; the host system disconnects the caller and then reconnects on a telephone number that was previously authorized for that terminal.
([[Fair Use]] [[Source]]: [[RFC 4949])
- CAM
(O) See: Certificate Arbitrator Module.
([[Fair Use]] [[Source]]: [[RFC 4949])
- CANEWARE
(O) An end-to-end encryption system for computer data networks that was developed by the U.S. DoD in the 1980s to provide host- to-host data confidentiality service for datagrams in OSIRM Layer 3. [Roge] (Compare: BLACKER, IPsec.)
Tutorial: Each user host connects to its own bump-in-the-wire encryption device called a CANEWARE Front End (CFE), through which the host connects to the subnetwork. CANEWARE uses symmetric encryption for CFE-to-CFE traffic, but also uses FIREFLY to establish those session keys. The public-key certificates issued by the FIREFLY system include credentials for mandatory access control. For discretionary access control, the system also includes one or more centralized CANEWARE Control Processors (CCPs) that connect to the subnetwork, maintain a database for discretionary access control authorizations, and communicate those authorizations to assigned sets of CFEs.
The CANEWARE system is MLS in only two of the three ways that BLACKER is MLS: (a) Like BLACKER BFEs, CFEs form a security perimeter around a subnetwork, separating user hosts from the subnetwork, so that the subnetwork can operate at a different security level than the hosts. (b) Like BLACKER, the CANEWARE components are trusted to separate datagrams of different security levels, so that each datagram of a given security level can be received only by a host that is authorized for that security level; and thus CANEWARE can separate host communities that operate at different security levels. © Unlike a BFE, the host side of a CFE is not MLS, and treats all packets received from a user host as being at the same mandatory security level.
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) /information system/ A mechanism that implements access control for a system entity by enumerating the system resources that the entity is permitted to access and, either implicitly or explicitly, the access modes granted for each resource. (Compare:
RFC 4949 Internet Security Glossary, Version 2 August 2007
access control list, access control matrix, access profile, capability token.)
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) A token (usually an unforgeable data object) that gives the bearer or holder the right to access a system resource. Possession of the token is accepted by a system as proof that the holder has been authorized to access the resource indicated by the token. (See: attribute certificate, capability list, credential, digital certificate, ticket, token.)
([[Fair Use]] [[Source]]: [[RFC 4949])
- Capability Maturity Model (CMM)
(N) Method for judging the maturity of software processes in an organization and for identifying crucial practices needed to increase process maturity. [Chris] (Compare: Common Criteria.)
Tutorial: The CMM does not specify security evaluation criteria (see: assurance level), but its use may improve security assurance. The CMM describes principles and practices that can improve software processes in terms of evolving from ad hoc processes to disciplined processes. The CMM has five levels: - Initial: Software processes are ad hoc or chaotic, and few are well-defined. Success depends on individual effort and heroics. - Repeatable: Basic project management processes are established to track cost, schedule, and functionality. Necessary process discipline is in place to repeat earlier successes on projects with similar applications. - Defined: Software process for both management and engineering activities is documented, standardized, and integrated into a standard software process for the organization. Each project uses an approved, tailored version of the organization's standard process for developing and maintaining software. - Managed: Detailed measures of software process and product quality are collected. Both software process and products are quantitatively understood and controlled. - Optimizing: Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies.
([[Fair Use]] [[Source]]: [[RFC 4949])
- CAPI
(I) See: cryptographic application programming interface.
([[Fair Use]] [[Source]]: [[RFC 4949])
- CAPSTONE
(N) An integrated microcircuit (in MYK-8x series manufactured by Mykotronx, Inc.) that implements SKIPJACK, KEA, DSA, SHA, and basic mathematical functions needed to support asymmetric cryptography; has a non-deterministic random number generator; and supports key escrow. (See: FORTEZZA. Compare: CLIPPER.)
RFC 4949 Internet Security Glossary, Version 2 August 2007
([[Fair Use]] [[Source]]: [[RFC 4949])
See: cryptographic card, FORTEZZA, payment card, PC card, smart card, token.
([[Fair Use]] [[Source]]: [[RFC 4949])
([[Fair Use]] [[Source]]: [[RFC 4949])
([[Fair Use]] [[Source]]: [[RFC 4949])
- card restore
See: token restore.
([[Fair Use]] [[Source]]: [[RFC 4949])
- cardholder
1. (I) An entity to whom or to which a card has been issued.
Usage: Usually refers to a living human being, but might refer (a) to a position (see: billet, role) in an organization or (b) to an automated process. (Compare: user.)
2. (O) /SET/ “The holder of a valid payment card account and user of software supporting electronic commerce.” [SET2] A cardholder is issued a payment card by an issuer. SET ensures that in the cardholder's interactions with merchants, the payment card account information remains confidential. [SET1]
([[Fair Use]] [[Source]]: [[RFC 4949])
- cardholder certificate
(O) /SET/ A digital certificate that is issued to a cardholder upon approval of the cardholder's issuing financial institution and that is transmitted to merchants with purchase requests and encrypted payment instructions, carrying assurance that the account number has been validated by the issuing financial institution and cannot be altered by a third party. [SET1]
([[Fair Use]] [[Source]]: [[RFC 4949])
- cardholder certification authority (CCA)
(O) /SET/ A CA responsible for issuing digital certificates to cardholders and operated on behalf of a payment card brand, an issuer, or another party according to brand rules. A CCA maintains relationships with card issuers to allow for the verification of cardholder accounts. A CCA does not issue a CRL but does distribute CRLs issued by root CAs, brand CAs, geopolitical CAs, and payment gateway CAs. [SET2]
([[Fair Use]] [[Source]]: [[RFC 4949])
- CAST
(N) A design procedure for symmetric encryption algorithms, and a resulting family of algorithms, invented by Carlisle Adams (C.A.) and Stafford Tavares (S.T.). [R2144, R2612]
RFC 4949 Internet Security Glossary, Version 2 August 2007
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) A grouping of sensitive information items to which a non- hierarchical restrictive security label is applied to increase protection of the data. (See: formal access approval. Compare: compartment, classification.)
([[Fair Use]] [[Source]]: [[RFC 4949])
- CAW
(N) See: certification authority workstation.
([[Fair Use]] [[Source]]: [[RFC 4949])
- CBC
(N) See: cipher block chaining.
([[Fair Use]] [[Source]]: [[RFC 4949])
- CCA
(O) See: cardholder certification authority.
([[Fair Use]] [[Source]]: [[RFC 4949])
- CCEP
(O) See: Commercial COMSEC Endorsement Program.
([[Fair Use]] [[Source]]: [[RFC 4949])
- CCI
(O) See: Controlled Cryptographic Item.
([[Fair Use]] [[Source]]: [[RFC 4949])
(N) Acronym for French translation of International Telephone and Telegraph Consultative Committee. Now renamed ITU-T.
([[Fair Use]] [[Source]]: [[RFC 4949])
- CCM
(N) See: Counter with Cipher Block Chaining-Message Authentication Code.
([[Fair Use]] [[Source]]: [[RFC 4949])
- CERIAS
(O) Purdue University's Center for Education and Research in Information Assurance and Security, which includes faculty from multiple schools and departments and takes a multidisciplinary approach to security problems ranging from technical to ethical, legal, educational, communicational, linguistic, and economic.
([[Fair Use]] [[Source]]: [[RFC 4949])
- CERT
(I) See: computer emergency response team.
([[Fair Use]] [[Source]]: [[RFC 4949])
1. (I) /general English/ A document that attests to the truth of something or the ownership of something.
2. (I) /general security/ See: capability token, digital certificate.
3. (I) /PKI/ See: attribute certificate, public-key certificate.
RFC 4949 Internet Security Glossary, Version 2 August 2007
([[Fair Use]] [[Source]]: [[RFC 4949])
- Certificate Arbitrator Module (CAM)
(O) An open-source software module that is designed to be integrated with an application for routing, replying to, and otherwise managing and meditating certificate validation requests between that application and the CAs in the ACES PKI.
([[Fair Use]] [[Source]]: [[RFC 4949])
(D) Synonym for “certification authority”.
Deprecated Term: IDOCs SHOULD NOT use this term; it suggests careless use of the term “certification authority”, which is preferred in PKI standards (e.g., [X509, R3280]).
([[Fair Use]] [[Source]]: [[RFC 4949])
(D) Synonym for “certification path”. (See: trust chain.)
Deprecated Term: IDOCs SHOULD NOT use this term; it duplicates the meaning of a standardized term. Instead, use “certification path”.
([[Fair Use]] [[Source]]: [[RFC 4949])
(D) Synonym for “certificate validation” or “path validation”.
Deprecated Term: IDOCs SHOULD NOT use this term; it duplicates the meaning of standardized terms and mixes concepts in a potentially misleading way. Instead, use “certificate validation” or “path validation”, depending on what is meant. (See: validate vs. verify.)
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) The act or process by which a CA sets the values of a digital certificate's data fields and signs it. (See: issue.)
([[Fair Use]] [[Source]]: [[RFC 4949])
- certificate expiration
(I) The event that occurs when a certificate ceases to be valid because its assigned lifetime has been exceeded. (See: certificate revocation, expire.)
Tutorial: The assigned lifetime of an X.509 certificate is stated in the certificate itself. (See: validity period.)
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) See: extension.
([[Fair Use]] [[Source]]: [[RFC 4949])
- certificate holder
(D) Synonym for the “subject” of a digital certificate. (Compare: certificate owner, certificate user.)
RFC 4949 Internet Security Glossary, Version 2 August 2007
Deprecated Definition: IDOCs SHOULD NOT use this term as a synonym for the subject of a digital certificate; the term is potentially ambiguous. For example, the term could be misunderstood as referring to a system entity or component, such as a repository, that simply has possession of a copy of the certificate.
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) The functions that a CA may perform during the lifecycle of a digital certificate, including the following: - Acquire and verify data items to bind into the certificate. - Encode and sign the certificate. - Store the certificate in a directory or repository. - Renew, rekey, and update the certificate. - Revoke the certificate and issue a CRL. (See: archive management, certificate management, key management, security architecture, token management.)
([[Fair Use]] [[Source]]: [[RFC 4949])
(D) /U.S. DoD/ Used to mean either a CA or an RA. DoD7, SP32]
Deprecated Term: IDOCs SHOULD NOT use this term because it is potentially ambiguous, such as in a context involving ICRLs. Instead, use CA, RA, or both, depending on what is meant.
([[Fair Use]] [[Source]]: [[RFC 4949])
(D) Synonym for the “subject” of a digital certificate. (Compare: certificate holder, certificate user.)
Deprecated Definition: IDOCs SHOULD NOT use this term as a synonym for the subject of a digital certificate; the term is potentially ambiguous. For example, the term could refer to a system entity, such as a corporation, that has purchased a certificate to operate equipment, such as a Web server.
([[Fair Use]] [[Source]]: [[RFC 4949])
(D) Synonym for “certification path”.
Deprecated Term: IDOCs SHOULD NOT use this term; it suggests careless use of “certification path”, which is preferred in PKI standards (e.g., [X509, R3280]).
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) “A named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements.” [X509] (Compare: CPS, security policy.)
RFC 4949 Internet Security Glossary, Version 2 August 2007
Example: U.S. DoD's certificate policy DoD7] defined four classes (i.e., assurance levels) for X.509 public-key certificates and defines the applicability of those classes. (See: class 2.)
Tutorial: A certificate policy can help a certificate user to decide whether a certificate should be trusted in a particular application. “For example, a particular certificate policy might indicate applicability of a type of certificate for the authentication of electronic data interchange transactions for the trading of goods within a given price range.” [R3647]
A v3 X.509 public-key certificate may have a “certificatePolicies” extension that lists certificate policies, recognized by the issuing CA, that apply to the certificate and govern its use. Each policy is denoted by an object identifier and may optionally have certificate policy qualifiers. (See: certificate profile.)
Each SET certificate specifies at least one certificate policy, that of the SET root CA. SET uses certificate policy qualifiers to point to the actual policy statement and to add qualifying policies to the root policy. (See: SET qualifier.)
([[Fair Use]] [[Source]]: [[RFC 4949])
- certificate policy qualifier
(I) Information that pertains to a certificate policy and is included in a “certificatePolicies” extension in a v3 X.509 public-key certificate.
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) A specification (e.g., DoD7, R3280]) of the format and semantic]s of [[public-key certificates or attribute certificates, constructed for use in a specific application context by selecting from among options offered by a broader standard. (Compare: protection profile.)
([[Fair Use]] [[Source]]: [[RFC 4949])
- certificate reactivation
(I) The act or process by which a digital certificate, that a CA has designated for revocation but not yet listed on a CRL, is returned to the valid state.
([[Fair Use]] [[Source]]: [[RFC 4949])
1. (I) The act or process by which an existing public-key certificate has its key value changed by issuing a new certificate with a different (usually new) public key. (See: certificate renewal, certificate update, rekey.)
Tutorial: For an X.509 public-key certificate, the essence of rekey is that the subject stays the same and a new public key is bound to that subject. Other changes are made, and the old
RFC 4949 Internet Security Glossary, Version 2 August 2007
certificate is revoked, only as required by the PKI and CPS in support of the rekey. If changes go beyond that, the process is a “certificate update”.
2. (O) /MISSI/ The act or process by which a MISSI CA creates a new X.509 public-key certificate that is identical to the old one, except the new one has (a) a new, different KEA key or (b) a new, different DSS key or © new, different KEA and DSS keys. The new certificate also has a different serial number and may have a different validity period. A new key creation date and maximum key lifetime period are assigned to each newly generated key. If a new KEA key is generated, that key is assigned a new KMID. The old certificate remains valid until it expires, but may not be further renewed, rekeyed, or updated.
([[Fair Use]] [[Source]]: [[RFC 4949])
- certificate renewal
(I) The act or process by which the validity of the binding asserted by an existing public-key certificate is extended in time by issuing a new certificate. (See: certificate rekey, certificate update.)
Tutorial: For an X.509 public-key certificate, this term means that the validity period is extended (and, of course, a new serial number is assigned) but the binding of the public key to the subject and to other data items stays the same. The other data items are changed, and the old certificate is revoked, only as required by the PKI and CPS to support the renewal. If changes go beyond that, the process is a “certificate rekey” or “certificate update”.
([[Fair Use]] [[Source]]: [[RFC 4949])
(D) Synonym for “certification request”.
Deprecated Term: IDOCs SHOULD NOT use this term; it suggests careless use of the term “certification request”, which is preferred in PKI standards (e.g., see PKCS #10).
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) The event that occurs when a CA declares that a previously valid digital certificate issued by that CA has become invalid; usually stated with an effective date.
Tutorial: In X.509, a revocation is announced to potential certificate users by issuing a CRL that mentions the certificate. Revocation and listing on a CRL is only necessary prior to the certificate's scheduled expiration.
RFC 4949 Internet Security Glossary, Version 2 August 2007
([[Fair Use]] [[Source]]: [[RFC 4949])
1. (I) A data structure that enumerates digital certificates that have been invalidated by their issuer prior to when they were scheduled to expire. (See: certificate expiration, delta CRL, X.509 certificate revocation list.)
2. (O) “A signed list indicating a set of certificates that are no longer considered valid by the certificate issuer. In addition to the generic term CRL, some specific CRL types are defined for CRLs that cover particular scopes.” [X509]
([[Fair Use]] [[Source]]: [[RFC 4949])
(N) A mechanism for distributing notices of certificate revocations; uses a tree of hash results that is signed by the tree's issuer. Offers an alternative to issuing a CRL, but is not supported in X.509. (See: certificate status responder.)
([[Fair Use]] [[Source]]: [[RFC 4949])
1. (I) An integer value that (a) is associated with, and may be carried in, a digital certificate; (b) is assigned to the certificate by the certificate's issuer; and © is unique among all the certificates produced by that issuer.
2. (O) “An integer value, unique within the issuing CA, [that] is unambiguously associated with a certificate issued by that CA.” [X509]
([[Fair Use]] [[Source]]: [[RFC 4949])
(D) /U.S. DoD/ “A trusted entity that provides on-line verification to a Relying Party of a subject certificate's trustworthiness [should instead say 'validity'], and may also provide additional attribute information for the subject certificate.” DoD7]
Deprecated Term: IDOCs SHOULD NOT use this term because it is not widely accepted; instead, use “certificate status responder” or “OCSP server”, or otherwise explain what is meant.
([[Fair Use]] [[Source]]: [[RFC 4949])
- certificate status responder
(N) /FPKI/ A trusted online server that acts for a CA to provide authenticated certificate status information to certificate users [FPKI]. Offers an alternative to issuing a CR. (See: certificate revocation tree, OCSP.)
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) The act or process by which non-key data items bound in an existing public-key certificate, especially authorizations granted
RFC 4949 Internet Security Glossary, Version 2 August 2007
to the subject, are changed by issuing a new certificate. (See: certificate rekey, certificate renewal.)
Usage: For an X.509 public-key certificate, the essence of this process is that fundamental changes are made in the data that is bound to the public key, such that it is necessary to revoke the old certificate. (Otherwise, the process is only a “certificate rekey” or “certificate renewal”.)
([[Fair Use]] [[Source]]: [[RFC 4949])
1. (I) A system entity that depends on the validity of information (such as another entity's public key value) provided by a digital certificate. (See: relying party. Compare: /digital certificate/ subject.)
Usage: The depending entity may be a human being or an organization, or a device or process controlled by a human or organization. (See: user.)
2. (O) “An entity that needs to know, with certainty, the public key of another entity.” [X509]
3. (D) Synonym for “subject” of a digital certificate.
Deprecated Definition: IDOCs SHOULD NOT use this term with definition 3; the term could be confused with one of the other two definitions given above.
([[Fair Use]] [[Source]]: [[RFC 4949])
1. (I) An act or process by which a certificate user establishes that the assertions made by a digital certificate can be trusted. (See: valid certificate, validate vs. verify.)
2. (O) “The process of ensuring that a certificate was valid at a given time, including possibly the construction and processing of a certification path [R4158], and ensuring that all certificates in that path were valid (i.e. were not expired or revoked) at that given time.” [X509]
Tutorial: To validate a certificate, a certificate user checks that the certificate is properly formed and signed and is currently in force: - Checks the syntax and [[Parses the certificate's syntax and interprets its semantic]s, [[applying rules specified for and by its data fields, such as for critical extensions in an X.509 certificate.
RFC 4949 Internet Security Glossary, Version 2 August 2007
- Checks the signature: Uses the issuer's public key to verify the digital signature of the CA who issued the certificate in question. If the verifier obtains the issuer's public key from the issuer's own public-key certificate, that certificate should be validated, too. That validation may lead to yet another certificate to be validated, and so on. Thus, in general, certificate validation involves discovering and validating a certification path. - Checks currency and revocation: Verifies that the certificate is currently in force by checking that the current date and time are within the validity period (if that is specified in the certificate) and that the certificate is not listed on a CRL or otherwise announced as invalid. (The CRLs also must be checked by a similar validation process.)
([[Fair Use]] [[Source]]: [[RFC 4949])
- certification
1. (I) /information system/ Comprehensive evaluation (usually made in support of an accreditation action) of an information system's technical security features and other safeguards to establish the extent to which the system's design and implementation meet a set of specified security requirements. [C4009, FP102, SP37] (See: accreditation. Compare: evaluation.)
2. (I) /digital certificate/ The act or process of vouching for the truth and accuracy of the binding between data items in a certificate. (See: certify.)
3. (I) /PKI/ The act or process of vouching for the ownership of a public key by issuing a public-key certificate that binds the key to the name of the entity that possesses the matching private key. Besides binding a key with a name, a public-key certificate may bind those items with other restrictive or explanatory data items. (See: X.509 public-key certificate.)
4. (O) /SET/ “The process of ascertaining that a set of requirements or criteria has been fulfilled and attesting to that fact to others, usually with some written instrument. A system that has been inspected and evaluated as fully compliant with the SET protocol by duly authorized parties and process would be said to have been certified compliant.” [SET2]
([[Fair Use]] [[Source]]: [[RFC 4949])
1. (I) An entity that issues digital certificates (especially X.509 certificates) and vouches for the binding between the data items in a certificate.
RFC 4949 Internet Security Glossary, Version 2 August 2007
2. (O) “An authority trusted by one or more users to create and assign certificates. Optionally the certification authority may create the user's keys.” [X509]
Tutorial: Certificate users depend on the validity of information provided by a certificate. Thus, a CA should be someone that certificate users trust and that usually holds an official position created and granted power by a government, a corporation, or some other organization. A CA is responsible for managing the life cycle of certificates (see: certificate management) and, depending on the type of certificate and the CPS that applies, may be responsible for the lifecycle of key pairs associated with the certificates (see: key management).
([[Fair Use]] [[Source]]: [[RFC 4949])
(N) A computer system that enables a CA to issue digital certificates and supports other certificate management functions as required.
([[Fair Use]] [[Source]]: [[RFC 4949])
- certification hierarchy
1. (I) A tree-structured (loop-free) topology of relationships between CAs and the entities to whom the CAs issue public-key certificates. (See: hierarchical PKI, hierarchy management.)
Tutorial: In this structure, one CA is the top CA, the highest level of the hierarchy. (See: root, top CA.) The top CA may issue public-key certificates to one or more additional CAs that form the second-highest level. Each of these CAs may issue certificates to more CAs at the third-highest level, and so on. The CAs at the second-lowest level issue certificates only to non-CA entities that form the lowest level (see: end entity). Thus, all certification paths begin at the top CA and descend through zero or more levels of other CAs. All certificate users base path validations on the top CA's public key.
2. (I) /PEM/ A certification hierarchy for PEM has three levels of CAs [R1422]: - The highest level is the “Internet Policy Registration Authority”. - A CA at the second-highest level is a “policy certification authority”. - A CA at the third-highest level is a “certification authority”.
3. (O) /MISSI/ A certification hierarchy for MISSI has three or four levels of CAs: - A CA at the highest level, the top CA, is a “policy approving authority”.
RFC 4949 Internet Security Glossary, Version 2 August 2007
- A CA at the second-highest level is a “policy creation authority”. - A CA at the third-highest level is a local authority called a “certification authority”. - A CA at the fourth-highest (optional) level is a “subordinate certification authority”.
4. (O) /SET/ A certification hierarchy for SET has three or four levels of CAs: - The highest level is a “SET root CA”. - A CA at the second-highest level is a “brand certification authority”. - A CA at the third-highest (optional) level is a “geopolitical certification authority”. - A CA at the fourth-highest level is a “cardholder CA”, a “merchant CA”, or a “payment gateway CA”.
([[Fair Use]] [[Source]]: [[RFC 4949])
- certification path
1. (I) A linked sequence of one or more public-key certificates, or one or more public-key certificates and one attribute certificate, that enables a certificate user to verify the signature on the last certificate in the path, and thus enables the user to obtain (from that last certificate) a certified public key, or certified attributes, of the system entity that is the subject of that last certificate. (See: trust anchor, certificate validation, valid certificate.)
2. (O) “An ordered sequence of certificates of objects in the X.500 Directory Information Tree which, together with the public key of the initial object in the path, can be processed to obtain that of the final object in the path.” [R3647, X509]
Tutorial: The list is “linked” in the sense that the digital signature of each certificate (except possibly the first) is verified by the public key contained in the preceding certificate; i.e., the private key used to sign a certificate and the public key contained in the preceding certificate form a key pair that has previously been bound to the authority that signed.
The path is the “list of certificates needed to enable a particular user to obtain the public key [or attributes] of another user.” [X509] Here, the word “particular” points out that a certification path that can be validated by one certificate user might not be able to be validated by another. That is because either the first certificate needs to be a trusted certificate or the signature on the first certificate needs to be verifiable by a trusted key (e.g., a root key), but such trust is established only
RFC 4949 Internet Security Glossary, Version 2 August 2007
relative to a “particular” (i.e., specific) user, not absolutely for all users.
([[Fair Use]] [[Source]]: [[RFC 4949])
- certification policy
(D) Synonym for either “certificate policy” or “certification practice statement”.
Deprecated Term: IDOCs SHOULD NOT use this term as a synonym for either of those terms; that would be duplicative and would mix concepts in a potentially misleading way. Instead, use either “certificate policy” or “certification practice statement”, depending on what is meant.
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) “A statement of the practices which a certification authority employs in issuing certificates.” [DSG, R3647] (See: certificate policy.)
Tutorial: A CPS is a published security policy that can help a certificate user to decide whether a certificate issued by a particular CA can be trusted enough to use in a particular application. A CPS may be (a) a declaration by a CA of the details of the system and practices it uses in its certificate management operations, (b) part of a contract between the CA and an entity to whom a certificate is issued, © a statute or regulation applicable to the CA, or (d) a combination of these types involving multiple documents. [DSG]
A CPS is usually more detailed and procedurally oriented than a certificate policy. A CPS applies to a particular CA or CA community, while a certificate policy applies across CAs or communities. A CA with its single CPS may support multiple certificate policies, which may be used for different application purposes or by different user communities. On the other hand, multiple CAs, each with a different CPS, may support the same certificate policy. [R3647]
([[Fair Use]] [[Source]]: [[RFC 4949])
- certification request
(I) An algorithm-independent transaction format (e.g., PKCS #10, RFC 4211) that contains a DN, and a public key or, optionally, a set of attributes, collectively signed by the entity requesting certification, and sent to a CA, which transforms the request to an X.509 public-key certificate or another type of certificate.
([[Fair Use]] [[Source]]: [[RFC 4949])
- certify
1. (I) Issue a digital certificate and thus vouch for the truth, accuracy, and binding between data items in the certificate (e.g., “X.509 public-key certificate”), such as the id[[entity of the
RFC 4949 Internet Security Glossary, Version 2 August 2007
certificate's subject and the ownership of a public key. (See: certification.)
Usage: To “certify a public key” means to issue a public-key certificate that vouches for the binding between the certificate's subject and the key.
2. (I) The act by which a CA uses measures to verify the truth, accuracy, and binding between data items in a digital certificate.
Tutorial: A description of the measures used for verification should be included in the CA's CPS.
([[Fair Use]] [[Source]]: [[RFC 4949])
- CFB
([[Fair Use]] [[Source]]: [[RFC 4949])
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) A peer entity authentication method (employed by PPP and other protocols, e.g., RFC 3720) that uses a randomly generated challenge and requires a matching response that depends on a cryptographic hash of some combination of the challenge and a secret key. [R1994 (See: challenge-response, PAP.)
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) An authentication process that verifies an id[[entity by requiring correct authentication information to be provided in response to a challenge. In a computer system, the authentication information is usually a value that is required to be computed in response to an unpredictable challenge value, but it might be just a password.
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) /IMAP4/ A mechanism [R2195], intended for use with IMAP4 AUTHENTICATE, by which an IMAP4 client uses a keyed hash [R2104] to authenticate itself to an IMAP4 server. (See: POP3 APOP.)
Tutorial: The server includes a unique time stamp in its ready response to the client. The client replies with the client's name and the hash result of applying MD5 to a string formed from concatenating the time stamp with a shared secret that is known only to the client and the server.
([[Fair Use]] [[Source]]: [[RFC 4949])
1. (I) An information transfer path within a system. (See: covert channel.)
RFC 4949 Internet Security Glossary, Version 2 August 2007
2. (O) “A subdivision of the physical medium allowing possibly shared independent uses of the medium.” (RFC 3753)
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) The total capacity of a link to carry information; usually expressed in bits per second. (RFC 3753) (Compare: bandwidth.)
Tutorial: Within a given bandwidth, the theoretical maximum channel capacity is given by Shannon's Law. The actual channel capacity is determined by the bandwidth, the coding system used, and the signal-to-noise ratio.
([[Fair Use]] [[Source]]: [[RFC 4949])
- CHAP
(I) See: Challenge Handshake Authentication Protocol.
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) A value that (a) is computed by a function that is dependent on the contents of a data object and (b) is stored or transmitted together with the object, for detecting changes in the data. (See: cyclic redundancy check, data integrity service, error detection code, hash, keyed hash, parity bit, protected checksum.)
Tutorial: To gain confidence that a data object has not been changed, an entity that later uses the data can independently recompute the checksum value and compare the result with the value that was stored or transmitted with the object.
Computer systems and networks use checksums (and other mechanisms) to detect accidental changes in data. However, active wiretapping that changes data could also change an accompanying checksum to match the changed data. Thus, some checksum functions by themselves are not good countermeasures for active attacks. To protect against active attacks, the checksum function needs to be well-chosen (see: cryptographic hash), and the checksum result needs to be cryptographically protected (see: digital signature, keyed hash).
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) A security policy to prevent conflict of interest caused by an entity (e.g., a consultant) interacting with competing firms. (See: Brewer-Nash model.)
Tutorial: All information is categorized into mutually exclusive conflict-of-interest classes I(1), I(2), …, I(M), and each firm F(1), F(2), …, F(N) belongs to exactly one class. The policy states that if a consultant has access to class I(i) information from a firm in that class, then the consultant may not access information from another firm in that same class, but may access
RFC 4949 Internet Security Glossary, Version 2 August 2007
information from another firm that is in a different class. Thus, the policy creates a barrier to communication between firms that are in the same conflict-of-interest class. Brewer and Nash modeled enforcement of this policy [BN89], including dealing with policy violations that could occur because two or more consultants work for the same firm.
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) A cryptanalysis technique in which the analyst tries to determine the key from knowledge of plain text that corresponds to cipher text selected (i.e., dictated) by the analyst.
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) A cryptanalysis technique in which the analyst tries to determine the key from knowledge of cipher text that corresponds to plain text selected (i.e., dictated) by the analyst.
([[Fair Use]] [[Source]]: [[RFC 4949])
- CIAC
(O) See: Computer Incident Advisory Capability.
([[Fair Use]] [[Source]]: [[RFC 4949])
- CIK
(N) See: cryptographic ignition key.
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) A cryptographic algorithm for encryption and decryption.
([[Fair Use]] [[Source]]: [[RFC 4949])
(N) A block cipher mode that enhances ECB mode by chaining together blocks of cipher text it produces. [FP081] (See: block cipher, [R1829], [R2405], [R2451], [SP38A].)
Tutorial: This mode operates by combining (exclusive OR-ing) the algorithm's ciphertext output block with the next plaintext block to form the next input block for the algorithm.
([[Fair Use]] [[Source]]: [[RFC 4949])
(N) A block cipher mode that enhances ECB mode by chaining together the blocks of cipher text it produces and operating on plaintext segments of variable length less than or equal to the block length. [FP081] (See: block cipher, [SP38A].)
Tutorial: This mode operates by using the previously generated ciphertext segment as the algorithm's input (i.e., by “feeding back” the cipher text) to generate an output block, and then combining (exclusive OR-ing) that output block with the next plaintext segment (block length or less) to form the next ciphertext segment.
RFC 4949 Internet Security Glossary, Version 2 August 2007
$ cipher text 1. (I) /noun/ Data that has been transformed by encryption so that its semantic] [[information content (i.e., its meaning) is no longer intelligible or directly available. (See: ciphertext. Compare: clear text, plain text.)
2. (O) “Data produced through the use of encipherment. The semantic] [[content of the resulting data is not available.” [I7498-2]
([[Fair Use]] [[Source]]: [[RFC 4949])
1. (O) /noun/ Synonym for “cipher text” [I7498-2].
2. (I) /adjective/ Referring to cipher text. Usage: Commonly used instead of “cipher-text”. (Compare: cleartext, plaintext.)
([[Fair Use]] [[Source]]: [[RFC 4949])
(D) “Cryptographic logic that uses previous cipher text to generate a key stream.” [C4009, A1523] (See: KAK.)
Deprecated Term: IDOCs SHOULD NOT use this term; it is neither well-known nor precisely defined. Instead, use terms associated with modes that are defined in standards, such as CBC, CFB, and OFB.
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) A cryptanalysis technique in which the analyst tries to determine the key solely from knowledge of intercepted cipher text (although the analyst may also know other clues, such as the cryptographic algorithm, the language in which the plain text was written, the subject matter of the plain text, and some probable plaintext words.)
([[Fair Use]] [[Source]]: [[RFC 4949])
- ciphony
(O) The process of encrypting audio information.
([[Fair Use]] [[Source]]: [[RFC 4949])
- CIPSO
(I) See: Common IP Security Option.
([[Fair Use]] [[Source]]: [[RFC 4949])
- CKL
(I) See: compromised key list.
([[Fair Use]] [[Source]]: [[RFC 4949])
- Clark-Wilson model
(N) A security model [Clark] to maintain data integrity in the commercial world. (Compare: Bell-LaPadula model.)
RFC 4949 Internet Security Glossary, Version 2 August 2007
([[Fair Use]] [[Source]]: [[RFC 4949])
- class 2, 3, 4, 5
(O) /U.S. DoD/ Assurance levels for PKIs, and for X.509 public-key certificates issued by a PKI. DoD7] (See: “first law” under “Courtney's laws”.) - “Class 2”: Intended for applications handling unclassified, low-value data in minimally or moderately protected environments. - “Class 3”: Intended for applications handling unclassified, medium-value data in moderately protected environments, or handling unclassified or high-value data in highly protected environments, and for discretionary access control of classified data in highly protected environments. - “Class 4”: Intended for applications handling unclassified, high-value data in minimally protected environments. - “Class 5”: Intended for applications handling classified data in minimally protected environments, and for authentication of material that would affect the security of classified systems.
The environments are defined as follows: - “Highly protected environment”: Networks that are protected either with encryption devices approved by NSA for protection of classified data or via physical isolation, and that are certified for processing system-high classified data, where exposure of unencrypted data is limited to U.S. citizens holding appropriate security clearances. - “Moderately protected environment”: – Physically isolated unclassified, unencrypted networks in which access is restricted based on legitimate need. – Networks protected by NSA-approved, type 1 encryption, accessible by U.S.-authorized foreign nationals. - “Minimally protected environments”: Unencrypted networks connected to either the Internet or NIPRNET, either directly or via a firewall.
([[Fair Use]] [[Source]]: [[RFC 4949])
(O) /TCSEC/ See: Tutorial under “Trusted Computer System Evaluation Criteria”.
([[Fair Use]] [[Source]]: [[RFC 4949])
- classification
1. (I) A grouping of classified information to which a hierarchical, restrictive security label is applied to increase protection of the data from unauthorized disclosure. (See: aggregation, classified, data confidentiality service. Compare: category, compartment.)
2. (I) An authorized process by which information is determined to be classified and assigned to a security level. (Compare: declassification.)
RFC 4949 Internet Security Glossary, Version 2 August 2007
Usage: Usually understood to involve data confidentiality, but IDOCs SHOULD make this clear when data also is sensitive in other ways and SHOULD use other terms for those other sensitivity concepts. (See: sensitive information, data integrity.)
([[Fair Use]] [[Source]]: [[RFC 4949])
- classification label
(I) A security label that tells the degree of harm that will result from unauthorized disclosure of the labeled data, and may also tell what countermeasures are required to be applied to protect the data from unauthorized disclosure. Example: IPSO. (See: classified, data confidentiality service. Compare: integrity label.)
Usage: Usually understood to involve data confidentiality, but IDOCs SHOULD make this clear when data also is sensitive in other ways and SHOULD use other terms for those other sensitivity concepts. (See: sensitive information, data integrity.)
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) A hierarchical level of protection (against unauthorized disclosure) that is required to be applied to certain classified data. (See: classified. Compare: security level.)
Usage: Usually understood to involve data confidentiality, but IDOCs SHOULD make this clear when data also is sensitive in other ways and SHOULD use other terms for those other sensitivity concepts. (See: sensitive information, data integrity.)
([[Fair Use]] [[Source]]: [[RFC 4949])
- classified
1. (I) Refers to information (stored or conveyed, in any form) that is formally required by a security policy to receive data confidentiality service and to be marked with a security label (which, in some cases, might be implicit) to indicate its protected status. (See: classify, collateral information, SAP, security level. Compare: unclassified.)
Usage: Usually understood to involve data confidentiality, but IDOCs SHOULD make this clear when data also is sensitive in other ways and SHOULD use other terms for those other sensitivity concepts. (See: sensitive information, data integrity.)
Mainly used by national governments, especially by the military, but the underlying concept also applies outside of governments.
2. (O) /U.S. Government/ “Information that has been determined pursuant to Executive Order 12958 or any predecessor Order, or by the Atomic Energy Act of 1954, as amended, to require protection
RFC 4949 Internet Security Glossary, Version 2 August 2007
against unauthorized disclosure and is marked to indicate its classified status.” [C4009]
([[Fair Use]] [[Source]]: [[RFC 4949])
- classify
(I) To officially designate an information item or type of information as being classified and assigned to a specific security level. (See: classified, declassify, security level.)
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) A computer system in which the operating system and application system software and files have been freshly installed from trusted software distribution media. (Compare: secure state.)
([[Fair Use]] [[Source]]: [[RFC 4949])
- clear
(D) /verb/ Synonym for “erase”. [C4009]
Deprecated Definition: IDOCs SHOULD NOT use the term with this definition; that could be confused with “clear text” in which information is directly recoverable.
([[Fair Use]] [[Source]]: [[RFC 4949])
- clear text
1. (I) /noun/ Data in which the semantic] [[information content (i.e., the meaning) is intelligible or is directly available, i.e., not encrypted. (See: cleartext, in the clear. Compare: cipher text, plain text.)
2. (O) /noun/ “Intelligible data, the semantic] [[content of which is available.” [I7498-2]
3. (D) /noun/ Synonym for “plain text”.
Deprecated Definition: IDOCs SHOULD NOT use this term as a synonym for “plain text”, because the plain text that is input to an encryption operation may itself be cipher text that was output from a previous encryption operation. (See: superencryption.)
([[Fair Use]] [[Source]]: [[RFC 4949])
- clearance
See: security clearance.
([[Fair Use]] [[Source]]: [[RFC 4949])
- clearance level
(I) The security level of information to which a security clearance authorizes a person to have access.
([[Fair Use]] [[Source]]: [[RFC 4949])
- cleartext
1. (O) /noun/ Synonym for “clear text” [I7498-2].
2. (I) /adjective/ Referring to clear text. Usage: Commonly used instead of “clear-text”. (Compare: ciphertext, plaintext.)
RFC 4949 Internet Security Glossary, Version 2 August 2007
3. (D) /adjective/ Synonym for “plaintext”.
Deprecated Definition: IDOCs SHOULD NOT use this term as a synonym for “plaintext”, because the plaintext data that is input to an encryption operation may itself be ciphertext data that was output from a previous encryption operation. (See: superencryption.)
([[Fair Use]] [[Source]]: [[RFC 4949])
- CLEF
(N) See: commercially licensed evaluation facility.
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) A system entity that requests and uses a service provided by another system entity, called a “server”. (See: server.)
Tutorial: Usually, it is understood that the client and server are automated components of the system, and the client makes the request on behalf of a human user. In some cases, the server may itself be a client of some other server.
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) A distributed system in which one or more entities, called clients, request a specific service from one or more other entities, called servers, that provide the service to the clients.
Example: The Word Wide Web, in which component servers provide information that is requested by component clients called “browsers”.
([[Fair Use]] [[Source]]: [[RFC 4949])
- CLIPPER
(N) An integrated microcircuit (in MYK-7x series manufactured by Mykotronx, Inc.) that implements SKIPJACK, has a non-deterministic random number generator, and supports key escrow. (See: Escrowed Encryption Standard. Compare: CLIPPER.)
Tutorial: The chip was mainly intended for protecting telecommunications over the public switched network. The key escrow scheme for the chip involves a SKIPJACK key that is common to all chips and that protects the unique serial number of the chip, and a second SKIPJACK key unique to the chip that protects all data encrypted by the chip. The second key is escrowed as split key components held by NIST and the U.S. Treasury Department.
([[Fair Use]] [[Source]]: [[RFC 4949])
(O) /U.S. DoD/ A system environment that meets both of the following conditions: (a) Application developers (including maintainers) have sufficient clearances and authorizations to provide an acceptable presumption that they have not introduced
RFC 4949 Internet Security Glossary, Version 2 August 2007
malicious logic. (b) Configuration control provides sufficient assurance that system applications and the equipment they run on are protected against the introduction of malicious logic prior to and during the operation of applications. [NCS04] (See: “first law” under “Courtney's laws”. Compare: open security environment.)
([[Fair Use]] [[Source]]: [[RFC 4949])
- CMA
(D) See: certificate management authority.
([[Fair Use]] [[Source]]: [[RFC 4949])
- CMAC
(N) A message authentication code [SP38B] that is based on a symmetric block cipher. (See: block cipher.)
Derivation: Cipher-based MAC. (Compare: HMAC.)
Tutorial: Because CMAC is based on approved, symmetric-key block ciphers, such as AES, CMAC can be considered a mode of operation for those block ciphers. (See: mode of operation.)
([[Fair Use]] [[Source]]: [[RFC 4949])
- CMCS
(O) See: COMSEC Material Control System.
([[Fair Use]] [[Source]]: [[RFC 4949])
- CMM
(N) See: Capability Maturity Model.
([[Fair Use]] [[Source]]: [[RFC 4949])
- CMS
(I) See: Cryptographic Message Syntax.
([[Fair Use]] [[Source]]: [[RFC 4949])
1. (I) A system of symbols used to represent information, which might originally have some other representation. Examples: ASCII, BER, country code, Morse code. (See: encode, object code, source code.)
Deprecated Abbreviation: To avoid confusion with definition 1, IDOCs SHOULD NOT use “code” as an abbreviation of “country code”, “cyclic redundancy code”, “Data Authentication Code”, “error detection code”, or “Message Authentication Code”. To avoid misunderstanding, use the fully qualified term in these other cases, at least at the point of first usage.
2. (I) /cryptography/ An encryption algorithm based on substitution; i.e., a system for providing data confidentiality by using arbitrary groups (called “code groups”) of letters, numbers, or symbols to represent units of plain text of varying length. (See: codebook, cryptography.)
RFC 4949 Internet Security Glossary, Version 2 August 2007
Deprecated Usage: To avoid confusion with definition 1, IDOCs SHOULD NOT use “code” as a synonym for any of the following terms: (a) “cipher”, “hash”, or other words that mean “a cryptographic algorithm”; (b) “cipher text”; or © “encrypt”, “hash”, or other words that refer to applying a cryptographic algorithm.
3. (I) An algorithm based on substitution, but used to shorten messages rather than to conceal their content.
4. (I) /computer programming/ To write computer software. (See: object code, source code.)
Deprecated Abbreviation: To avoid confusion with definition 1, IDOCs SHOULD NOT use “code” as an abbreviation of “object code” or “source code”. To avoid misunderstanding, use the fully qualified term in these other cases, at least at the point of first usage.
([[Fair Use]] [[Source]]: [[RFC 4949])
1. (I) Document containing a systematically arranged list of plaintext units and their ciphertext equivalents. [C4009]
2. (I) An encryption algorithm that uses a word substitution technique. [C4009] (See: code, ECB.)
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) A security mechanism that uses a digital signature to provide data integrity and data origin authentication for software that is being distributed for use. (See: mobile code, trusted distribution.)
Tutorial: In some cases, the signature on a software module may imply some assertion that the signer makes about the software. For example, a signature may imply that the software has been designed, developed, or tested according to some criterion.
([[Fair Use]] [[Source]]: [[RFC 4949])
(O) /U.S. Government/ A single word that is used as a security label (usually applied to classified information) but which itself has a classified meaning. (See: classified, /U.S. Government/ security label.)
([[Fair Use]] [[Source]]: [[RFC 4949])
- COI
(I) See: community of interest.
([[Fair Use]] [[Source]]: [[RFC 4949])
(N) /cryptographic module/ A procedure for initially keying cryptographic equipment. [C4009]
RFC 4949 Internet Security Glossary, Version 2 August 2007
([[Fair Use]] [[Source]]: [[RFC 4949])
- collateral information
(O) /U.S. Government/ Information that is classified but is not required to be protected by an SAP. (See: /U.S. Government/ classified.)
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) In a system being operated in periods-processing mode, the act of purging all information from one processing period and then changing over to the next processing period. (See: BLACK, RED.)
([[Fair Use]] [[Source]]: [[RFC 4949])
(O) “Relationship between NSA and industry in which NSA provides the COMSEC expertise (i.e., standards, algorithms, evaluations, and guidance) and industry provides design, development, and production capabilities to produce a type 1 or type 2 product.” [C4009]
([[Fair Use]] [[Source]]: [[RFC 4949])
(N) An organization that has official approval to evaluate the security of products and systems under the Common Criteria, ITSEC, or some other standard. (Compare: KLIF.)
([[Fair Use]] [[Source]]: [[RFC 4949])
(O) /U.S. Government/ A Government, interagency, standing committee of the President's Critical Infrastructure Protection Board. The CNSS is chaired by the Secretary of Defense and provides a forum for the discussion of policy issues, sets national policy, and promulgates direction, operational procedures, and guidance for the security of national security systems. The Secretary of Defense and the Director of Central Intelligence are responsible for developing and overseeing the implementation of Government-wide policies, principles, standards, and guidelines for the security of systems that handle national security information.
([[Fair Use]] [[Source]]: [[RFC 4949])
(N) A standard for evaluating information technology (IT) products and systems. It states requirements for security functions and for assurance measures. [CCIB] (See: CLEF, EAL, packages, protection profile, security target, TOE. Compare: CMM.)
Tutorial: Canada, France, Germany, the Netherlands, the United Kingdom, and the United States (NIST and NSA) began developing this standard in 1993, based on the European ITSEC, the Canadian Trusted Computer Product Evaluation Criteria (CTCPEC), and the U.S. “Federal Criteria for Information Technology Security” and its precursor, the TCSEC. Work was done in cooperation with ISO/IEC Joint Technical Committee 1 (Information Technology),
RFC 4949 Internet Security Glossary, Version 2 August 2007
Subcommittee 27 (Security Techniques), Working Group 3 (Security Criteria). Version 2.0 of the Criteria has been issued as ISO's International Standard 15408. The U.S. Government intends this standard to supersede both the TCSEC and FIPS PUB 140. (See: NIAP.)
The standard addresses data confidentiality, data integrity, and availability and may apply to other aspects of security. It focuses on threats to information arising from human activities, malicious or otherwise, but may apply to non-human threats. It applies to security measures implemented in hardware, firmware, or software. It does not apply to (a) administrative security not related directly to technical security, (b) technical physical aspects of security such as electromagnetic emanation control, © evaluation methodology or administrative and legal framework under which the criteria may be applied, (d) procedures for use of evaluation results, or (e) assessment of inherent qualities of cryptographic algorithms.
Part 1, Introduction and General Model, defines general concepts and principles of IT security evaluation; presents a general model of evaluation; and defines constructs for expressing IT security objectives, for selecting and defining IT security requirements, and for writing high-level specifications for products and systems.
Part 2, Security Functional Requirements, contains a catalog of well-defined and well-understood functional requirement statements that are intended to be used as a standard way of expressing the security requirements for IT products and systems.
Part 3, Security Assurance Requirements, contains a catalog of assurance components for use as a standard way of expressing such requirements for IT products and systems, and defines evaluation criteria for protection profiles and security targets.
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) See: secondary definition under “IPSO”.
([[Fair Use]] [[Source]]: [[RFC 4949])
(N) A character string that (a) may be a part of the X.500 DN of a Directory object (“commonName” attribute), (b) is a (possibly ambiguous) name by which the object is commonly known in some limited scope (such as an organization), and © conforms to the naming conventions of the country or culture with which it is associated. [X520] (See: “subject” and “issuer” under “X.509 public-key certificate”.)
RFC 4949 Internet Security Glossary, Version 2 August 2007
Examples: “Dr. Albert Einstein”, “The United Nations”, and “12-th Floor Laser Printer”.
([[Fair Use]] [[Source]]: [[RFC 4949])
(N) “Concealing or altering of characteristic communications patterns to hide information that could be of value to an adversary.” [C4009] (See: operations security, traffic-flow confidentiality, TRANSEC.)
([[Fair Use]] [[Source]]: [[RFC 4949])
- communication security (COMSEC)
(I) Measures that implement and assure security services in a communication system, particularly those that provide data confidentiality and data integrity and that authenticate communicating entities.
Usage: COMSEC is usually understood to include (a) cryptography and its related algorithms and key management methods and processes, devices that implement those algorithms and processes, and the lifecycle management of the devices and keying material. Also, COMSEC is sometimes more broadly understood as further including (b) traffic-flow confidentiality, © TRANSEC, and (d) steganography [Kahn]. (See: cryptology, signal security.)
([[Fair Use]] [[Source]]: [[RFC 4949])
1. (I) A set of entities that operate under a common security policy. (Compare: domain.)
2. (I) A set of entities that exchange information collaboratively for some purpose.
([[Fair Use]] [[Source]]: [[RFC 4949])
- community risk
(N) Probability that a particular vulnerability will be exploited within an interacting population and adversely affect some members of that population. [C4009] (See: Morris worm, risk.)
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) A community name in the form of an octet string that serves as a cleartext password in SNMP version 1 (RFC 1157) and version 2 (RFC 1901). (See: password, Simple Network Management Protocol.)
Tutorial: The SNMPv1 and SNMPv2 protocols have been declared “historic” and have been replaced by the more secure SNMPv3 standard (RFCs 3410-3418), which does not use cleartext passwords.
RFC 4949 Internet Security Glossary, Version 2 August 2007
([[Fair Use]] [[Source]]: [[RFC 4949])
- compartment
1. (I) A grouping of sensitive information items that require special access controls beyond those normally provided for the basic classification level of the information. (See: compartmented security mode. Compare: category, classification.)
Usage: The term is usually understood to include the special handling procedures to be used for the information.
2. (I) Synonym for “category”.
Deprecated Usage: This Glossary defines “category” with a slightly narrower meaning than “compartment”. That is, a security label is assigned to a category because the data owner needs to handle the data as a compartment. However, a compartment could receive special protection in a system without being assigned a category label.
([[Fair Use]] [[Source]]: [[RFC 4949])
(N) A mode of system operation wherein all users having access to the system have the necessary security clearance for the single, hierarchical classification level of all data handled by the system, but some users do not have the clearance for a non- hierarchical category of some data handled by the system. (See: category, /system operation/ under “mode”, protection level, security clearance.)
Usage: Usually abbreviated as “compartmented mode”. This term was defined in U.S. Government policy on system accreditation. In this mode, a system may handle (a) a single hierarchical classification level and (b) multiple non-hierarchical categories within that level.
([[Fair Use]] [[Source]]: [[RFC 4949])
- Compartments field
(I) A 16-bit field (the “C field”) that specifies compartment values in the security option (option type 130) of version 4 IP's datagram header format. The valid field values are assigned by the U.S. Government, as specified in RFC 791.
Deprecated Abbreviation: IDOCs SHOULD NOT use the abbreviation “C field”; the abbreviation is potentially ambiguous. Instead, use “Compartments field”.
([[Fair Use]] [[Source]]: [[RFC 4949])
RFC 4949 Internet Security Glossary, Version 2 August 2007
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) A process that encodes information in a way that minimizes the number of resulting code symbols and thus reduces storage space or transmission time.
Tutorial: A data compression algorithm may be “lossless”, i.e., retain all information that was encoded in the data, so that decompression can recover all the information; or an algorithm may be “lossy”. Text usually needs to be compressed losslessly, but images are often compressed with lossy schemes.
Not all schemes that encode information losslessly for machine processing are efficient in terms of minimizing the number of output bits. For example, ASCII encoding is lossless, but ASCII data can often be losslessly reencoded in fewer bits with other schemes. These more efficient schemes take advantage of some sort of inherent imbalance, redundancy, or repetition in the data, such as by replacing a character string in which all characters are the same by a shorter string consisting of only the single character and a character count.
Lossless compression schemes cannot effectively reduce the number of bits in cipher text produced by a strong encryption algorithm, because the cipher text is essentially a pseudorandom bit string that does not contain patterns susceptible to reencoding. Therefore, protocols that offer both encryption and compression services (e.g., SSL) need to perform the compression operation before the encryption operation.
([[Fair Use]] [[Source]]: [[RFC 4949])
- compromise
See: data compromise, security compromise.
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) The process of regaining a secure state for a system after detecting that the system has experienced a security compromise.
([[Fair Use]] [[Source]]: [[RFC 4949])
(N) /MISSI/ A list that identifies keys for which unauthorized disclosure or alteration may have occurred. (See: compromise.)
Tutorial: A CKL is issued by a CA, like a CRL is issued. But a CKL lists only KMIDs, not subjects that hold the keys, and not certificates in which the keys are bound.
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) See: computer security.
RFC 4949 Internet Security Glossary, Version 2 August 2007
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) An organization that studies computer and network INFOSEC in order to provide incident response services to victims of attacks, publish alerts concerning vulnerabilities and threats, and offer other information to help improve computer and network security. (See: CSIRT, security incident.)
Examples: CERT Coordination Center at Carnegie Mellon University (sometimes called “the” CERT); CIAC.
([[Fair Use]] [[Source]]: [[RFC 4949])
(O) The centralized CSIRT of the U.S. Department of Energy; a member of FIRST.
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) A collection of host computers together with the subnetwork or internetwork through which they can exchange data.
Usage: This definition is intended to cover systems of all sizes and types, ranging from the complex Internet to a simple system composed of a personal computer dialing in as a remote terminal of another computer.
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) A combination of computer hardware and an operating system (which may consist of software, firmware, or both) for that hardware. (Compare: computer system.)
([[Fair Use]] [[Source]]: [[RFC 4949])
1. (I) Measures to implement and assure security services in a computer system, particularly those that assure access control service.
Usage: Usually refers to internal controls (functions, features, and technical characteristics) that are implemented in software (especially in operating systems); sometimes refers to internal controls implemented in hardware; rarely used to refer to external controls.
2. (O) “The protection afforded to an automated information system in order to attain the applicable objectives of preserving the integrity, availability and confidentiality of information system resources (includes hardware, software, firmware, information/data, and telecommunications).” [SP12]
RFC 4949 Internet Security Glossary, Version 2 August 2007
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) An organization “that coordinates and supports the response to security incidents that involve sites within a defined constituency.” [R2350] (See: CERT, FIRST, security incident.)
Tutorial: To be considered a CSIRT, an organization must do as follows: (a) Provide a (secure) channel for receiving reports about suspected security incidents. (b) Provide assistance to members of its constituency in handling the incidents. © Disseminate incident-related information to its constituency and other involved parties.
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) The definition or representation of a resource, tool, or mechanism used to maintain a condition of security in computerized environments. Includes many items referred to in standards that are either selected or defined by separate user communities. [CSOR] (See: object identifier, Computer Security Objects Register.)
([[Fair Use]] [[Source]]: [[RFC 4949])
(N) A service operated by NIST is establishing a catalog for computer security objects to provide stable object definitions identified by unique names. The use of this register will enable the unambiguous specification of security parameters and algorithms to be used in secure data exchanges. (See: object identifier.)
Tutorial: The CSOR follows registration guidelines established by the international standards community and ANSI. Those guidelines establish minimum responsibilities for registration authorities and assign the top branches of an international registration hierarchy. Under that international registration hierarchy, the CSOR is responsible for the allocation of unique identifiers under the branch: {joint-iso-ccitt(2) country(16) us(840) organization(1) gov(101) csor(3)}.
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) Synonym for “information system”, or a component thereof. (Compare: computer platform.)
([[Fair Use]] [[Source]]: [[RFC 4949])
- Computers At Risk
(O) The 1991 report [NRC91] of the System Security Study Committee, sponsored by the U.S. National Academy of Sciences and supported by the Defense Advanced Research Projects Agency of the U.S. DoD. It made many recommendations for industry and governments to improve computer security and trustworthiness. Some of the most important recommendations (e.g., establishing an
RFC 4949 Internet Security Glossary, Version 2 August 2007
Information Security Foundation chartered by the U.S. Government) have not been implemented at all, and others (e.g., codifying Generally Accepted System Security Principles similar to accounting principles) have been implemented but not widely adopted [SP14, SP27].
([[Fair Use]] [[Source]]: [[RFC 4949])
- COMSEC
(I) See: communication security.
([[Fair Use]] [[Source]]: [[RFC 4949])
- COMSEC account
(O) /U.S. Government/ “Administrative entity, identified by an account number, used to maintain accountability, custody, and control of COMSEC material.” [C4009] (See: COMSEC custodian.)
([[Fair Use]] [[Source]]: [[RFC 4949])
- COMSEC accounting
(O) /U.S. Government/ The process of creating, collecting, and maintaining data records that describe the status and custody of designated items of COMSEC material. (See: accounting legend code.)
Tutorial: Almost any secure information system needs to record a security audit trail, but a system that manages COMSEC material needs to record additional data about the status and custody of COMSEC items. - COMSEC tracking: The process of automatically collecting, recording, and managing information that describes the status of designated items of COMSEC material at all times during each product's lifecycle. - COMSEC controlling: The process of supplementing tracking data with custody data, which consists of explicit acknowledgements of system entities that they (a) have received specific COMSEC items and (b) are responsible for preventing exposure of those items.
For example, a key management system that serves a large customer base needs to record tracking data for the same reasons that a national parcel delivery system does, i.e., to answer the question “Where is that thing now?”. If keys are encrypted immediately upon generation and handled only in BLACK form between the point of generation and the point of use, then tracking may be all that is needed. However, in cases where keys are handled at least partly in RED form and are potentially subject to exposure, then tracking needs to be supplemented by controlling.
Data that is used purely for tracking need be retained only temporarily, until an item's status changes. Data that is used for controlling is retained indefinitely to ensure accountability and support compromise recovery.
RFC 4949 Internet Security Glossary, Version 2 August 2007
([[Fair Use]] [[Source]]: [[RFC 4949])
- COMSEC boundary
(N) “Definable perimeter encompassing all hardware, firmware, and software components performing critical COMSEC functions, such as key generation and key handling and storage.” [C4009] (Compare: cryptographic boundary.)
([[Fair Use]] [[Source]]: [[RFC 4949])
- COMSEC custodian
(O) /U.S. Government/ “Individual designated by proper authority to be responsible for the receipt, transfer, accounting, safeguarding, and destruction of COMSEC material assigned to a COMSEC account.” [C4009]
([[Fair Use]] [[Source]]: [[RFC 4949])
- COMSEC material
(N) /U.S. Government/ Items designed to secure or authenticate communications or information in general; these items include (but are not limited to) keys; equipment, devices, documents, firmware, and software that embodies or describes cryptographic logic; and other items that perform COMSEC functions. [C4009] (Compare: keying material.)
([[Fair Use]] [[Source]]: [[RFC 4949])
(O) /U.S. Government/ “Logistics and accounting system through which COMSEC material marked 'CRYPTO' is distributed, controlled, and safeguarded.” [C4009] (See: COMSEC account, COMSEC custodian.)
([[Fair Use]] [[Source]]: [[RFC 4949])
- confidentiality
See: data confidentiality.
([[Fair Use]] [[Source]]: [[RFC 4949])
- concealment system
(O) “A method of achieving confidentiality in which sensitive information is hidden by embedding it in irrelevant data.” [NCS04] (Compare: steganography.)
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) The process of regulating changes to hardware, firmware, software, and documentation throughout the development and operational life of a system. (See: administrative security, harden, trusted distribution.)
Tutorial: Configuration control helps protect against unauthorized or malicious alteration of a system and thus provides assurance of system integrity. (See: malicious logic.)
([[Fair Use]] [[Source]]: [[RFC 4949])
- confinement property
(N) /formal model/ Property of a system whereby a subject has write access to an object only if the classification of the object dominates the clearance of the subject. (See: *-property, Bell- LaPadula model.)
RFC 4949 Internet Security Glossary, Version 2 August 2007
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) /access control/ A limitation on the function of an id[[entity, role, or privilege. (See: rule-based access control.)
Tutorial: In effect, a constraint is a form of security policy and may be either static or dynamic: - “Static constraint”: A constraint that must be satisfied at the time the policy is defined, and then continues to be satisfied until the constraint is removed. - “Dynamic constraint”: A constraint that may be defined to apply at various times that the id[[entity, role, or other object of the constraint is active in the system.
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) /World Wide Web/ Application software used to prevent access to certain Web servers, such as by parents who do not want their children to access pornography. (See: filter, guard.)
Tutorial: The filter is usually browser-based, but could be part of an intermediate cache server. The two basic content filtering techniques are (a) to block a specified list of URLs and (b) to block material that contains specified words and phrases.
([[Fair Use]] [[Source]]: [[RFC 4949])
- contingency plan
(I) A plan for emergency response, backup operations, and post- disaster recovery in a system as part of a security program to ensure availability of critical system resources and facilitate continuity of operations in a crisis. [NCS04] (See: availability.)
([[Fair Use]] [[Source]]: [[RFC 4949])
- control zone
(O) “The space, expressed in feet of radius, surrounding equipment processing sensitive information, that is under sufficient physical and technical control to preclude an unauthorized entry or compromise.” [NCSSG] (Compare: inspectable space, TEMPEST zone.)
([[Fair Use]] [[Source]]: [[RFC 4949])
(O) /TCSEC/ The level of evaluation criteria for a C2 computer system.
Tutorial: The major features of the C2 level are individual accountability, audit, access control, and object reuse.
([[Fair Use]] [[Source]]: [[RFC 4949])
(O) /U.S. Government/ “Secure telecommunications or information handling equipment, or associated cryptographic component, that is unclassified but governed by a special set of control requirements.” [C4009] (Compare: EUCI.)
RFC 4949 Internet Security Glossary, Version 2 August 2007
Tutorial: This category of equipment was established in 1985 to promote broad use of secure equipment for protecting both classified and unclassified information in the national interest. CCI equipment uses a classified cryptographic logic, but the hardware or firmware embodiment of that logic is unclassified. Drawings, software implementations, and other descriptions of that logic remain classified. [N4001]
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) A mechanism that facilitates the adjudication of the different security policies of interconnected systems. (See: domain, guard.)
([[Fair Use]] [[Source]]: [[RFC 4949])
(D) /U.S. DoD/ A mode of system operation wherein (a) two or more security levels of information are allowed to be handled concurrently within the same system when some users having access to the system have neither a security clearance nor need-to-know for some of the data handled by the system, but (b) separation of the users and the classified material on the basis, respectively, of clearance and classification level are not dependent only on operating system control (like they are in multilevel security mode). (See: /system operation/ under “mode”, protection level.)
Deprecated Term: IDOCs SHOULD NOT use this term. It was defined in a U.S. Government policy regarding system accreditation and was subsumed by “partitioned security mode” in a later policy. Both terms were dropped in still later policies.
Tutorial: Controlled mode was intended to encourage ingenuity in meeting data confidentiality requirements in ways less restrictive than “dedicated security mode” and “system-high security mode”, but at a level of risk lower than that generally associated with true “multilevel security mode”. This was intended to be accomplished by implementation of explicit augmenting measures to reduce or remove a substantial measure of system software vulnerability together with specific limitation of the security clearance levels of users having concurrent access to the system.
([[Fair Use]] [[Source]]: [[RFC 4949])
(O) /U.S. Government/ “Official responsible for directing the operation of a cryptonet and for managing the operational use and control of keying material assigned to the cryptonet.” [C4009, N4006]
([[Fair Use]] [[Source]]: [[RFC 4949])
1. (I) /HTTP/ Data exchanged between an HTTP server and a browser (a client of the server) to store state information on the client side and retrieve it later for server use.
RFC 4949 Internet Security Glossary, Version 2 August 2007
Tutorial: An HTTP server, when sending data to a client, may send along a cookie, which the client retains after the HTTP connection closes. A server can use this mechanism to maintain persistent client-side state information for HTTP-based applications, retrieving the state information in later connections. A cookie may include a description of the range of URLs for which the state is valid. Future requests made by the client in that range will also send the current value of the cookie to the server. Cookies can be used to generate profiles of web usage habits, and thus may infringe on personal privacy.
2. (I) /IPsec/ Data objects exchanged by ISAKMP to prevent certain denial-of-service attacks during the establishment of a security association.
3. (D) /access control/ Synonym for “capability token” or “ticket”.
Deprecated Definition: IDOCs SHOULD NOT use this term with definition 3; that would duplicate the meaning of better- established terms and mix concepts in a potentially misleading way.
([[Fair Use]] [[Source]]: [[RFC 4949])
(N) UTC is derived from International Atomic Time (TAI) by adding a number of leap seconds. The International Bureau of Weights and Measures computes TAI once each month by averaging data from many laboratories. (See: GeneralizedTime, UTCTime.)
([[Fair Use]] [[Source]]: [[RFC 4949])
- correction
(I) /security/ A system change made to eliminate or reduce the risk of reoccurrence of a security violation or threat consequence. (See: secondary definition under “security”.)
([[Fair Use]] [[Source]]: [[RFC 4949])
- correctness
(I) “The property of a system that is guaranteed as the result of formal verification activities.” [Huff] (See: correctness proof, verification.)
([[Fair Use]] [[Source]]: [[RFC 4949])
- correctness integrity
(I) The property that the information represented by data is accurate and consistent. (Compare: data integrity, source integrity.)
Tutorial: IDOCs SHOULD NOT use this term without providing a definition; the term is neither well-known nor precisely defined. Data integrity refers to the constancy of data values, and source integrity refers to confidence in data values. However,
RFC 4949 Internet Security Glossary, Version 2 August 2007
correctness integrity refers to confidence in the underlying information that data values represent, and this property is closely related to issues of accountability and error handling.
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) A mathematical proof of consistency between a specification for system security and the implementation of that specification. (See: correctness, formal specification.)
([[Fair Use]] [[Source]]: [[RFC 4949])
- corruption
(I) A type of threat action that undesirably alters system operation by adversely modifying system functions or data. (See: disruption.)
Usage: This type of threat action includes the following subtypes: - “Tampering”: /corruption/ Deliberately altering a system's logic, data, or control information to interrupt or prevent correct operation of system functions. (See: misuse, main entry for “tampering”.) - “Malicious logic”: /corruption/ Any hardware, firmware, or software (e.g., a computer virus) intentionally introduced into a system to modify system functions or data. (See: incapacitation, main entry for “malicious logic”, masquerade, misuse.) - “Human error”: /corruption/ Human action or inaction that unintentionally results in the alteration of system functions or data. - “Hardware or software error”: /corruption/ Error that results in the alteration of system functions or data. - “Natural disaster”: /corruption/ Any “act of God” (e.g., power surge caused by lightning) that alters system functions or data. [FP031 Section 2]
([[Fair Use]] [[Source]]: [[RFC 4949])
1. (N) /noun/ See: counter mode.
2. (I) /verb/ See: countermeasure.
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) An action, device, procedure, or technique used by an attacker to offset a defensive countermeasure.
Tutorial: For every countermeasure devised to protect computers and networks, some cracker probably will be able to devise a counter-countermeasure. Thus, systems must use “defense in depth”.
RFC 4949 Internet Security Glossary, Version 2 August 2007
([[Fair Use]] [[Source]]: [[RFC 4949])
(N) A block cipher mode that enhances ECB mode by ensuring that each encrypted block is different from every other block encrypted under the same key. [SP38A] (See: block cipher.)
Tutorial: This mode operates by first encrypting a generated sequence of blocks, called “counters”, that are separate from the input sequence of plaintext blocks which the mode is intended to protect. The resulting sequence of encrypted counters is exclusive-ORed with the sequence of plaintext blocks to produce the final ciphertext output blocks. The sequence of counters must have the property that each counter is different from every other counter for all of the plain text that is encrypted under the same key.
([[Fair Use]] [[Source]]: [[RFC 4949])
(CCM) (N) A block cipher mode [SP38C] that provides both data confidentiality and data origin authentication, by combining the techniques of CTR and a CBC-based message authentication code. (See: block cipher.)
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) An action, device, procedure, or technique that meets or opposes (i.e., counters) a threat, a vulnerability, or an attack by eliminating or preventing it, by minimizing the harm it can cause, or by discovering and reporting it so that corrective action can be taken.
Tutorial: In an Internet protocol, a countermeasure may take the form of a protocol feature, a component function, or a usage constraint.
([[Fair Use]] [[Source]]: [[RFC 4949])
- country code
(I) An identifier that is defined for a nation by ISO. [I3166]
Tutorial: For each nation, ISO Standard 3166 defines a unique two- character alphabetic code, a unique three-character alphabetic code, and a three-digit code. Among many uses of these codes, the two-character codes are used as top-level domain names.
([[Fair Use]] [[Source]]: [[RFC 4949])
- Courtney's laws
(N) Principles for managing system security that were stated by Robert H. Courtney, Jr.
RFC 4949 Internet Security Glossary, Version 2 August 2007
Tutorial: Bill Murray codified Courtney's laws as follows: [Murr] - Courtney's first law: You cannot say anything interesting (i.e., significant) about the security of a system except in the context of a particular application and environment. - Courtney's second law: Never spend more money eliminating a security exposure than tolerating it will cost you. (See: acceptable risk, risk analysis.) – First corollary: Perfect security has infinite cost. – Second corollary: There is no such thing as zero risk. - Courtney's third law: There are no technical solutions to management problems, but there are management solutions to technical problems.
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) An operation that is planned and executed in a way that conceals the id[[entity of the operator.
([[Fair Use]] [[Source]]: [[RFC 4949])
1. (I) An unintended or unauthorized intra-system channel that enables two cooperating entities to transfer information in a way that violates the system's security policy but does not exceed the entities' access authorizations. (See: covert storage channel, covert timing channel, out-of-band, tunnel.)
2. (O) “A communications channel that allows two cooperating processes to transfer information in a manner that violates the system's security policy.” [NCS04]
Tutorial: The cooperating entities can be either two insiders or an insider and an outsider. Of course, an outsider has no access authorization at all. A covert channel is a system feature that the system architects neither designed nor intended for information transfer.
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) A system feature that enables one system entity to signal information to another entity by directly or indirectly writing a storage location that is later directly or indirectly read by the second entity. (See: covert channel.)
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) A system feature that enables one system entity to signal information to another by modulating its own use of a system resource in such a way as to affect system response time observed by the second entity. (See: covert channel.)
([[Fair Use]] [[Source]]: [[RFC 4949])
- CPS
(I) See: certification practice statement.
RFC 4949 Internet Security Glossary, Version 2 August 2007
([[Fair Use]] [[Source]]: [[RFC 4949])
- cracker
(I) Someone who tries to break the security of, and gain unauthorized access to, someone else's system, often with malicious intent. (See: adversary, intruder, packet monkey, script kiddy. Compare: hacker.)
Usage: Was sometimes spelled “kracker”. [NCSSG]
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) See: Challenge-Response Authentication Mechanism.
([[Fair Use]] [[Source]]: [[RFC 4949])
- CRC
(I) See: cyclic redundancy check.
([[Fair Use]] [[Source]]: [[RFC 4949])
- credential
1. (I) /authentication/ “identifier credential”: A data object that is a portable representation of the association between an identifier and a unit of authentication information, and that can be presented for use in verifying an id[[entity claimed by an entity that attempts to access a system. Example: X.509 public-key certificate. (See: anonymous credential.)
2. (I) /access control/ “authorization credential”: A data object that is a portable representation of the association between an identifier and one or more access authorizations, and that can be presented for use in verifying those authorizations for an entity that attempts such access. Example: X.509 attribute certificate. (See: capability token, ticket.)
3. (D) /OSIRM/ “Data that is transferred to establish the claimed id[[entity of an entity.” [I7498-2]
Deprecated Definition: IDOCs SHOULD NOT use the term with definition 3. As explained in the tutorial below, an authentication process can involve the transfer of multiple data objects, and not all of those are credentials.
4. (D) /U.S. Government/ “An object that is verified when presented to the verifier in an authentication transaction.” [M0404]
Deprecated Definition: IDOCs SHOULD NOT use the term with definition 4; it mixes concepts in a potentially misleading way. For example, in an authentication process, it is the id[[entity that is “verified”, not the credential; the credential is “validated”. (See: validate vs. verify.)
RFC 4949 Internet Security Glossary, Version 2 August 2007
Tutorial: In general English, “credentials” are evidence or testimonials that (a) support a claim of id[[entity or authorization and (b) usually are intended to be used more than once (i.e., a credential's life is long compared to the time needed for one use). Some examples are a policeman's badge, an automobile driver's license, and a national passport. An authentication or access control process that uses a badge, license, or passport is outwardly simple: the holder just shows the thing.
The problem with adopting this term in Internet security is that an automated process for authentication or access control usually requires multiple steps using multiple data objects, and it might not be immediately obvious which of those objects should get the name “credential”.
For example, if the verification step in a user authentication process employs public-key technology, then the process involves at least three data items: (a) the user's private key, (b) a signed value – signed with that private key and passed to the system, perhaps in response to a challenge from the system – and © the user's public-key certificate, which is validated by the system and provides the public key needed to verify the signature. - Private key: The private key is *not* a credential, because it is never transferred or presented. Instead, the private key is “authentication information”, which is associated with the user's identifier for a specified period of time and can be used in multiple authentications during that time. - Signed value: The signed value is *not* a credential; the signed value is only ephemeral, not long lasting. The OSIRM definition could be interpreted to call the signed value a credential, but that would conflict with general English. - Certificate: The user's certificate
- is* a credential. It can
be “transferred” or “presented” to any person or process that needs it at any time. A public-key certificate may be used as an “id[[entity credential”, and an attribute certificate may be used as an “authorization credential”.
([[Fair Use]] [[Source]]: [[RFC 4949])
- critical
1. (I) /system resource/ A condition of a system resource such that denial of access to, or lack of availability of, that resource would jeopardize a system user's ability to perform a primary function or would result in other serious consequences, such as human injury or loss of life. (See: availability, precedence. Compare: sensitive.)
2. (N) /extension/ An indication that an application is not permitted to ignore an extension. [X509]
RFC 4949 Internet Security Glossary, Version 2 August 2007
Tutorial: Each extension of an X.509 certificate or CRL is flagged as either “critical” or “non-critical”. In a certificate, if a computer program does not recognize an extension's type (i.e., does not implement its semantic]s), then if the [[extension is critical, the program is required to treat the certificate as invalid; but if the extension is non-critical, the program is permitted to ignore the extension.
In a CRL, if a program does not recognize a critical extension that is associated with a specific certificate, the program is required to assume that the listed certificate has been revoked and is no longer valid, and then take whatever action is required by local policy.
When a program does not recognize a critical extension that is associated with the CRL as a whole, the program is required to assume that all listed certificates have been revoked and are no longer valid. However, since failing to process the extension may mean that the list has not been completed, the program cannot assume that other certificates are valid, and the program needs to take whatever action is therefore required by local policy.
([[Fair Use]] [[Source]]: [[RFC 4949])
- critical information infrastructure
(I) Those systems that are so vital to a nation that their incapacity or destruction would have a debilitating effect on national security, the economy, or public health and safety.
([[Fair Use]] [[Source]]: [[RFC 4949])
- CRL
(I) See: certificate revocation list.
([[Fair Use]] [[Source]]: [[RFC 4949])
- CRL distribution point
(I) See: distribution point.
([[Fair Use]] [[Source]]: [[RFC 4949])
- CRL extension
(I) See: extension.
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) A public-key certificate issued by a CA in one PKI to a CA in another PKI. (See: cross-certification.)
([[Fair Use]] [[Source]]: [[RFC 4949])
- cross-certification
(I) The act or process by which a CA in one PKI issues a public- key certificate to a CA in another PKI. [X509] (See: bridge CA.)
Tutorial: X.509 says that a CA (say, CA1) may issue a “cross- certificate” in which the subject is another CA (say, CA2). X.509 calls CA2 the “subject CA” and calls CA1 an “intermediate CA”, but
RFC 4949 Internet Security Glossary, Version 2 August 2007
this Glossary deprecates those terms. (See: intermediate CA, subject CA).
Cross-certification of CA2 by CA1 appears similar to certification of a subordinate CA by a superior CA, but cross-certification involves a different concept. The “subordinate CA” concept applies when both CAs are in the same PKI, i.e., when either (a) CA1 and CA2 are under the same root or (b) CA1 is itself a root. The “cross-certification” concept applies in other cases:
First, cross-certification applies when two CAs are in different PKIs, i.e., when CA1 and CA2 are under different roots, or perhaps are both roots themselves. Issuing the cross-certificate enables end entities certified under CA1 in PK1 to construct the certification paths needed to validate the certificates of end entities certified under CA2 in PKI2. Sometimes, a pair of cross- certificates is issued – by CA1 to CA2, and by CA2 to CA1 – so that an end entity in either PKI can validate certificates issued in the other PKI.
Second, X.509 says that two CAs in some complex, multi-CA PKI can cross-certify one another to shorten the certification paths constructed by end entities. Whether or not a CA may perform this or any other form of cross-certification, and how such certificates may be used by end entities, should be addressed by the local certificate policy and CPS.
([[Fair Use]] [[Source]]: [[RFC 4949])
1. (D) Synonym for “guard”.
Deprecated Term: IDOCs SHOULD NOT use this term as a synonym for “guard”; this term unnecessarily (and verbosely) duplicates the meaning of the long-established “guard”.
2. (O) /U.S. Government/ A process or subsystem that provides a capability (which could be either manual or automated) to access two or more differing security domains in a system, or to transfer information between such domains. (See: domain, guard.)
([[Fair Use]] [[Source]]: [[RFC 4949])
1. (I) The mathematical science that deals with analysis of a cryptographic system to gain knowledge needed to break or circumvent the protection that the system is designed to provide. (See: cryptology, secondary definition under “intrusion”.)
2. (O) “The analysis of a cryptographic system and/or its inputs and outputs to derive confidential variables and/or sensitive data including cleartext.” [I7498-2]
RFC 4949 Internet Security Glossary, Version 2 August 2007
Tutorial: Definition 2 states the traditional goal of cryptanalysis, i.e., convert cipher text to plain text (which usually is clear text) without knowing the key; but that definition applies only to encryption systems. Today, the term is used with reference to all kinds of cryptographic algorithms and key management, and definition 1 reflects that. In all cases, however, a cryptanalyst tries to uncover or reproduce someone else's sensitive data, such as clear text, a key, or an algorithm. The basic cryptanalytic attacks on encryption systems are ciphertext-only, known-plaintext, chosen-plaintext, and chosen- ciphertext; and these generalize to the other kinds of cryptography.
([[Fair Use]] [[Source]]: [[RFC 4949])
- crypto, CRYPTO
1. (N) A prefix (“crypto-”) that means “cryptographic”.
Usage: IDOCs MAY use this prefix when it is part of a term listed in this Glossary. Otherwise, IDOCs SHOULD NOT use this prefix; instead, use the unabbreviated adjective, “cryptographic”.
2. (D) In lower case, “crypto” is an abbreviation for the adjective “cryptographic”, or for the nouns “cryptography” or “cryptographic component”.
Deprecated Abbreviation: IDOCs SHOULD NOT use this abbreviation because it could easily be misunderstood in some technical sense.
3. (O) /U.S. Government/ In upper case, “CRYPTO” is a marking or designator that identifies “COMSEC keying material used to secure or authenticate telecommunications carrying classified or sensitive U.S. Government or U.S. Government-derived information.” [C4009] (See: security label, security marking.)
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) An adjective that refers to cryptography.
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) An algorithm that uses the science of cryptography, including (a) encryption algorithms, (b) cryptographic hash algorithms, © digital signature algorithms, and (d) key-agreement algorithms.
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) The source code formats and procedures through which an application program accesses cryptographic services, which are defined abstractly compared to their actual implementation. Example, see: PKCS #11, [R2628].
RFC 4949 Internet Security Glossary, Version 2 August 2007
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) A security association that involves the use of cryptography to provide security services for data exchanged by the associated entities. (See: ISAKMP.)
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) See: secondary definition under “cryptographic module”.
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) A cryptographic token in the form of a smart card or a PC card.
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) A generic term for any system component that involves cryptography. (See: cryptographic module.)
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) See: secondary definition under “hash function”.
([[Fair Use]] [[Source]]: [[RFC 4949])
- cryptographic ignition key (CIK)
1. (N) A physical (usually electronic) token used to store, transport, and protect cryptographic keys and activation data. (Compare: dongle, fill device.)
Tutorial: A key-encrypting key could be divided (see: split key) between a CIK and a cryptographic module, so that it would be necessary to combine the two to regenerate the key, use it to decrypt other keys and data contained in the module, and thus activate the module.
2. (O) “Device or electronic key used to unlock the secure mode of cryptographic equipment.” [C4009] Usage: Abbreviated as “crypto- ignition key”.
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) See: key. Usage: Usually shortened to just “key”.
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) An encapsulation syntax (RFC 3852) for digital signatures, hashes, and encryption of arbitrary messages.
Tutorial: CMS derives from PKCS #7. CMS values are specified with ASN.1 and use BER encoding. The syntax permits multiple encapsulation with nesting, permits arbitrary attributes to be signed along with message content, and supports a variety of architectures for digital certificate-based key management.
RFC 4949 Internet Security Glossary, Version 2 August 2007
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) A set of hardware, software, firmware, or some combination thereof that implements cryptographic logic or processes, including cryptographic algorithms, and is contained within the module's “cryptographic boundary”, which is an explicitly defined contiguous perimeter that establishes the physical bounds of the module. [FP140]
([[Fair Use]] [[Source]]: [[RFC 4949])
1. (I) A set of cryptographic algorithms together with the key management processes that support use of the algorithms in some application context.
Usage: IDOCs SHOULD use definition 1 because it covers a wider range of algorithms than definition 2.
2. (O) “A collection of transformations from plain text into cipher text and vice versa [which would exclude digital signature, cryptographic hash, and key-agreement algorithms], the particular transformation(s) to be used being selected by keys. The transformations are normally defined by a mathematical algorithm.” [X509]
([[Fair Use]] [[Source]]: [[RFC 4949])
1. (I) A portable, user-controlled, physical device (e.g., smart card or PCMCIA card) used to store cryptographic information and possibly also perform cryptographic functions. (See: cryptographic card, token.)
Tutorial: A smart token might implement some set of cryptographic algorithms and might incorporate related key management functions, such as a random number generator. A smart cryptographic token may contain a cryptographic module or may not be explicitly designed that way.
([[Fair Use]] [[Source]]: [[RFC 4949])
1. (I) The mathematical science that deals with transforming data to render its meaning unintelligible (i.e., to hide its semantic] [[content), prevent its undetected alteration, or prevent its unauthorized use. If the transformation is reversible, cryptography also deals with restoring encrypted data to intelligible form. (See: cryptology, steganography.)
2. (O) “The discipline which embodies principles, means, and methods for the transformation of data in order to hide its information content, prevent its undetected modification and/or prevent its unauthorized use…. Cryptography determines the methods used in encipherment and decipherment.” [I7498-2]
RFC 4949 Internet Security Glossary, Version 2 August 2007
Tutorial: Comprehensive coverage of applied cryptographic protocols and algorithms is provided by Schneier [Schn]. Businesses and governments use cryptography to make data incomprehensible to outsiders; to make data incomprehensible to both outsiders and insiders, the data is sent to lawyers for a rewrite.
([[Fair Use]] [[Source]]: [[RFC 4949])
- Cryptoki
(N) A CAPI defined in PKCS #11. Pronunciation: “CRYPTO-key”. Derivation: Abbreviation of “cryptographic token interface”.
([[Fair Use]] [[Source]]: [[RFC 4949])
- cryptology
(I) The science of secret communication, which includes both cryptography and cryptanalysis.
Tutorial: Sometimes the term is used more broadly to denote activity that includes both rendering signals secure (see: signal security) and extracting information from signals (see: signal intelligence) [Kahn].
([[Fair Use]] [[Source]]: [[RFC 4949])
- cryptonet
(I) A network (i.e., a communicating set) of system entities that share a secret cryptographic key for a symmetric algorithm. (See: controlling authority.)
(O) “Stations holding a common key.” [C4009]
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) The time span during which a particular key value is authorized to be used in a cryptographic system. (See: key management.)
Usage: This term is long-established in COMPUSEC usage. In the context of certificates and public keys, “key lifetime” and “validity period” are often used instead.
Tutorial: A cryptoperiod is usually stated in terms of calendar or clock time, but sometimes is stated in terms of the maximum amount of data permitted to be processed by a cryptographic algorithm using the key. Specifying a cryptoperiod involves a tradeoff between the cost of rekeying and the risk of successful cryptoanalysis.
([[Fair Use]] [[Source]]: [[RFC 4949])
(I) Contraction of “cryptographic system”.
([[Fair Use]] [[Source]]: [[RFC 4949])
- cryptovariable
(D) Synonym for “key”.
RFC 4949 Internet Security Glossary, Version 2 August 2007
Deprecated Usage: In contemporary COMSEC usage, the term “key” has replaced the term “cryptovariable”.
([[Fair Use]] [[Source]]: [[RFC 4949])
- CSIRT
(I) See: computer security incident response team.
([[Fair Use]] [[Source]]: [[RFC 4949])
- CSOR
(N) See: Computer Security Objects Register.
([[Fair Use]] [[Source]]: [[RFC 4949])
- CTAK
([[Fair Use]] [[Source]]: [[RFC 4949])
- CTR
([[Fair Use]] [[Source]]: [[RFC 4949])
- cut-and-paste attack
(I) An active attack on the data integrity of cipher text, effected by replacing sections of cipher text with other cipher text, such that the result appears to decrypt correctly but actually decrypts to plain text that is forged to the satisfaction of the attacker.
([[Fair Use]] [[Source]]: [[RFC 4949])
- cyclic redundancy check (CRC)
(I) A type of checksum algorithm that is not a cryptographic hash but is used to implement data integrity service where accidental changes to data are expected. Sometimes called “cyclic redundancy code”.
Fair Use Sources
Cybersecurity: DevSecOps - Security Automation, Cloud Security - Cloud Native Security (AWS Security - Azure Security - GCP Security - IBM Cloud Security - Oracle Cloud Security, Container Security, Docker Security, Podman Security, Kubernetes Security, Google Anthos Security, Red Hat OpenShift Security); CIA Triad (Confidentiality - Integrity - Availability, Authorization - OAuth, Identity and Access Management (IAM), JVM Security (Java Security, Spring Security, Micronaut Security, Quarkus Security, Helidon Security, MicroProfile Security, Dropwizard Security, Vert.x Security, Play Framework Security, Akka Security, Ratpack Security, Netty Security, Spark Framework Security, Kotlin Security - Ktor Security, Scala Security, Clojure Security, Groovy Security;
, JavaScript Security, HTML Security, HTTP Security - HTTPS Security - SSL Security - TLS Security, CSS Security - Bootstrap Security - Tailwind Security, Web Storage API Security (localStorage Security, sessionStorage Security), Cookie Security, IndexedDB Security, TypeScript Security, Node.js Security, NPM Security, Deno Security, Express.js Security, React Security, Angular Security, Vue.js Security, Next.js Security, Remix.js Security, PWA Security, SPA Security, Svelts.js Security, Ionic Security, Web Components Security, Nuxt.js Security, Z Security, htmx Security
Python Security - Django Security - Flask Security - Pandas Security,
Database Security (Database Security on Kubernetes, Database Security on Containers / Database Security on Docker, Cloud Database Security - DBaaS Security, Concurrent Programming and Database Security, Functional Concurrent Programming and Database Security, Async Programming and Databases Security, MySQL Security, Oracle Database Security, Microsoft SQL Server Security, MongoDB Security, PostgreSQL Security, SQLite Security, Amazon RDS Security, IBM Db2 Security, MariaDB Security, Redis Security (Valkey Security), Cassandra Security, Amazon Aurora Security, Microsoft Azure SQL Database Security, Neo4j Security, Google Cloud SQL Security, Firebase Realtime Database Security, Apache HBase Security, Amazon DynamoDB Security, Couchbase Server Security, Elasticsearch Security, Teradata Database Security, Memcached Security, Infinispan Security, Amazon Redshift Security, SQLite Security, CouchDB Security, Apache Kafka Security, IBM Informix Security, SAP HANA Security, RethinkDB Security, InfluxDB Security, MarkLogic Security, ArangoDB Security, RavenDB Security, VoltDB Security, Apache Derby Security, Cosmos DB Security, Hive Security, Apache Flink Security, Google Bigtable Security, Hadoop Security, HP Vertica Security, Alibaba Cloud Table Store Security, InterSystems Caché Security, Greenplum Security, Apache Ignite Security, FoundationDB Security, Amazon Neptune Security, FaunaDB Security, QuestDB Security, Presto Security, TiDB Security, NuoDB Security, ScyllaDB Security, Percona Server for MySQL Security, Apache Phoenix Security, EventStoreDB Security, SingleStore Security, Aerospike Security, MonetDB Security, Google Cloud Spanner Security, SQream Security, GridDB Security, MaxDB Security, RocksDB Security, TiKV Security, Oracle NoSQL Database Security, Google Firestore Security, Druid Security, SAP IQ Security, Yellowbrick Data Security, InterSystems IRIS Security, InterBase Security, Kudu Security, eXtremeDB Security, OmniSci Security, Altibase Security, Google Cloud Bigtable Security, Amazon QLDB Security, Hypertable Security, ApsaraDB for Redis Security, Pivotal Greenplum Security, MapR Database Security, Informatica Security, Microsoft Access Security, Tarantool Security, Blazegraph Security, NeoDatis Security, FileMaker Security, ArangoDB Security, RavenDB Security, AllegroGraph Security, Alibaba Cloud ApsaraDB for PolarDB Security, DuckDB Security, Starcounter Security, EventStore Security, ObjectDB Security, Alibaba Cloud AnalyticDB for PostgreSQL Security, Akumuli Security, Google Cloud Datastore Security, Skytable Security, NCache Security, FaunaDB Security, OpenEdge Security, Amazon DocumentDB Security, HyperGraphDB Security, Citus Data Security, Objectivity/DB). Database drivers (JDBC Security, ODBC), ORM (Hibernate Security, Microsoft Entity Framework), SQL Operators and Functions Security, Database IDEs (JetBrains DataSpell Security, SQL Server Management Studio Security, MySQL Workbench Security, Oracle SQL Developer Security, SQLiteStudio),
Programming Language Security ((1. Python Security, 2. JavaScript Security, 3. Java Security, 4. C# Security, 5. C++ Security, 6. PHP Security, 7. TypeScript Security, 8. Ruby Security, 9. C Security, 10. Swift Security, 11. R Security, 12. Objective-C Security, 13. Scala Security, 14. Golang Security, 15. Kotlin Security, 16. Rust Security, 17. Dart Security, 18. Lua Security, 19. Perl Security, 20. Haskell Security, 21. Julia Security, 22. Clojure Security, 23. Elixir Security, 24. F# Security, 25. Assembly Language Security, 26. Shell Script Security / bash Security, 27. SQL Security, 28. Groovy Security, 29. PowerShell Security, 30. MATLAB Security, 31. VBA Security, 32. Racket Security, 33. Scheme Security, 34. Prolog Security, 35. Erlang Security, 36. Ada Security, 37. Fortran Security, 38. COBOL Security, 39. Lua Security, 40. VB.NET Security, 41. Lisp Security, 42. SAS Security, 43. D Security, 44. LabVIEW Security, 45. PL/SQL Security, 46. Delphi/Object Pascal Security, 47. ColdFusion Security, 49. CLIST Security, 50. REXX);
OS Security, Mobile Security: Android Security - Kotlin Security - Java Security, iOS Security - Swift Security; Windows Security - Windows Server Security, Linux Security (Ubuntu Security, Debian Security, RHEL Security, Fedora Security), UNIX Security (FreeBSD Security), IBM z Mainframe Security (RACF Security), Passwords (Windows Passwords, Linux Passwords, FreeBSD Passwords, Android Passwords, iOS Passwords, macOS Passwords, IBM z/OS Passwords), Passkeys, Hacking (Ethical Hacking, White Hat, Black Hat, Grey Hat), Pentesting (Red Team - Blue Team - Purple Team), Cybersecurity Certifications (CEH, GIAC, CISM, CompTIA Security Plus, CISSP), Mitre Framework, Common Vulnerabilities and Exposures (CVE), Cybersecurity Bibliography, Cybersecurity Courses, Firewalls, CI/CD Security (GitHub Actions Security, Azure DevOps Security, Jenkins Security, Circle CI Security), Functional Programming and Cybersecurity, Cybersecurity and Concurrency, Cybersecurity and Data Science - Cybersecurity and Databases, Cybersecurity and Machine Learning, Cybersecurity Glossary (RFC 4949 Internet Security Glossary), Awesome Cybersecurity, Cybersecurity GitHub, Cybersecurity Topics (navbar_security - see also navbar_aws_security, navbar_azure_security, navbar_gcp_security, navbar_k8s_security, navbar_docker_security, navbar_podman_security, navbar_mainframe_security, navbar_ibm_cloud_security, navbar_oracle_cloud_security, navbar_database_security, navbar_windows_security, navbar_linux_security, navbar_macos_security, navbar_android_security, navbar_ios_security, navbar_os_security, navbar_firewalls, navbar_encryption, navbar_passwords, navbar_iam, navbar_pentesting, navbar_privacy)
Request for Comments (RFC): List of RFCs, GitHub RFCs, Awesome RFCs, (navbar_rfc)
© 1994 - 2024 Cloud Monk Losang Jinpa or Fair Use. Disclaimers
SYI LU SENG E MU CHYWE YE. NAN. WEI LA YE. WEI LA YE. SA WA HE.