$ brain-damaged
      (D) /slang/ "Obviously wrong: extremely poorly designed. Calling
      something brain-damaged is very extreme. The word implies that the
      thing is completely unusable, and that its failure to work is due
      to poor design, not accident." [NCSSG] (See: flaw.)

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

   $ brand
      1. (I) A distinctive mark or name that identifies a product or
      business entity.

      2. (O) /SET/ The name of a payment card. (See: BCA.)

      Tutorial: Financial institutions and other companies have founded
      payment card brands, protect and advertise the brands, establish
      and enforce rules for use and acceptance of their payment cards,
      and provide networks to interconnect the financial institutions.
      These brands combine the roles of issuer and acquirer in
      interactions with cardholders and merchants. [SET1]

   $ brand certification authority (BCA)
      (O) /SET/ A CA owned by a payment card brand, such as MasterCard,
      Visa, or American Express. [SET2] (See: certification hierarchy,
      SET.)

   $ brand CRL identifier (BCI)
      (O) /SET/ A digitally signed list, issued by a BCA, of the names
      of CAs for which CRLs need to be processed when verifying
      signatures in SET messages. [SET2]

   $ break
      (I) /cryptography/ To successfully perform cryptanalysis and thus
      succeed in decrypting data or performing some other cryptographic
      function, without initially having knowledge of the key that the
      function requires. (See: penetrate, strength, work factor.)

      Usage: This term applies to encrypted data or, more generally, to
      a cryptographic algorithm or cryptographic system. Also, while the
      most common use is to refer to completely breaking an algorithm,
      the term is also used when a method is found that substantially
      reduces the work factor.

   $ Brewer-Nash model
      (N) A security model [BN89] to enforce the Chinese wall policy.
      (Compare: Bell-LaPadula model, Clark-Wilson model.)

      Tutorial: All proprietary information in the set of commercial
      firms F(1), F(2), ..., F(N) is categorized into mutually exclusive
      conflict-of-interest classes I(1), I(2), ..., I(M) that apply
      across all firms. Each firm belongs to exactly one class. The
      Brewer-Nash model has the following mandatory rules:
      -  Brewer-Nash Read Rule: Subject S can read information object O
         from firm F(i) only if either (a) O is from the same firm as
         some object previously read by S *or* (b) O belongs to a class
         I(i) from which S has not previously read any object. (See:
         object, subject.)
      -  Brewer-Nash Write Rule: Subject S can write information object
         O to firm F(i) only if (a) S can read O by the Brewer-Nash Read
         Rule *and* (b) no object can be read by S from a different firm
         F(j), no matter whether F(j) belongs to the same class as F(i)
         or to a different class.

   $ bridge
      (I) A gateway for traffic flowing at OSIRM Layer 2 between two
      networks (usually two LANs). (Compare: bridge CA, router.)

   $ bridge CA
      (I) A PKI consisting of only a CA that cross-certifies with CAs of
      some other PKIs. (See: cross-certification. Compare: bridge.)

      Tutorial: A bridge CA functions as a hub that enables a
      certificate user in any of the PKIs that attach to the bridge, to
      validate certificates issued in the other attached PKIs.

      For example, a bridge CA (BCA)                 CA1
      could cross-certify with four                   ^
      PKIs that have the roots CA1,                   |
      CA2, CA3, and CA4. The cross-                   v
      certificates that the roots            CA2 <-> BCA <-> CA3
      exchange with the BCA enable an                 ^
      end entity EE1 certified under                  |
      under CA1 in PK1 to construct                   v
      a certification path needed to                 CA4
      validate the certificate of
      end entity EE2 under CA2,           CA1 -> BCA -> CA2 -> EE2
      or vice versa.                     CA2 -> BCA -> CA1 -> EE1

   $ British Standard 7799
      (N) Part 1 of the standard is a code of practice for how to secure
      an information system. Part 2 specifies the management framework,
      objectives, and control requirements for information security
      management systems. [BS7799] (See: ISO 17799.)

   $ browser
      (I) A client computer program that can retrieve and display
      information from servers on the World Wide Web. Examples: Netscape
      Navigator and Microsoft Internet Explorer.

   $ brute force
      (I) A cryptanalysis technique or other kind of attack method
      involving an exhaustive procedure that tries a large number of
      possible solutions to the problem. (See: impossible, strength,
      work factor.)

      Tutorial: In some cases, brute force involves trying all of the
      possibilities. For example, for cipher text where the analyst
      already knows the decryption algorithm, a brute-force technique
      for finding matching plain text is to decrypt the message with
      every possible key. In other cases, brute force involves trying a
      large number of possibilities but substantially fewer than all of
      them. For example, given a hash function that produces an N-bit
      hash result, the probability is greater than 1/2 that the analyst
      will find two inputs that have the same hash result after trying
      only 2**(N/2) randomly chosen inputs. (See: birthday attack.)

   $ BS7799
      (N) See: British Standard 7799.

   $ buffer overflow
      (I) Any attack technique that exploits a vulnerability resulting
      from computer software or hardware that does not check for
      exceeding the bounds of a storage area when data is written into a
      sequence of storage locations beginning in that area.

      Tutorial: By causing a normal system operation to write data
      beyond the bounds of a storage area, the attacker seeks to either
      disrupt system operation or cause the system to execute malicious
      software inserted by the attacker.

   $ buffer zone
      (I) A neutral internetwork segment used to connect other segments
      that each operate under a different security policy.

      Tutorial: To connect a private network to the Internet or some
      other relatively public network, one could construct a small,
      separate, isolated LAN and connect it to both the private network
      and the public network; one or both of the connections would
      implement a firewall to limit the traffic that could pass through
      the buffer zone.

   $ bulk encryption
      1. (I) Encryption of multiple channels by aggregating them into a
      single transfer path and then encrypting that path. (See:
      channel.)

      2. (O) "Simultaneous encryption of all channels of a multichannel
      telecommunications link." [C4009] (Compare: bulk keying material.)

      Usage: The use of "simultaneous" in definition 2 could be
      interpreted to mean that multiple channels are encrypted
      separately but at the same time. However, the common meaning of
      the term is that multiple data flows are combined into a single
      stream and then that stream is encrypted as a whole.

   $ bulk key
      (D) In a few published descriptions of hybrid encryption for SSH,
      Windows 2000, and other applications, this term refers to a
      symmetric key that (a) is used to encrypt a relatively large
      amount of data and (b) is itself encrypted with a public key.
      (Compare: bulk keying material, session key.)

      Example: To send a large file to Bob, Alice (a) generates a
      symmetric key and uses it to encrypt the file (i.e., encrypt the
      bulk of the information that is to be sent) and then (b) encrypts
      that symmetric key (the "bulk key") with Bob's public key.

      Deprecated Term: IDOCs SHOULD NOT use this term or definition; the
      term is not well-established and could be confused with the
      established term "bulk keying material". Instead, use "symmetric
      key" and carefully explain how the key is applied.

   $ bulk keying material
      (N) Refers to handling keying material in large quantities, e.g.,
      as a dataset that contains many items of keying material. (See:
      type 0. Compare: bulk key, bulk encryption.)

   $ bump-in-the-stack
      (I) An implementation approach that places a network security
      mechanism inside the system that is to be protected. (Compare:
      bump-in-the-wire.)

      Example: IPsec can be implemented inboard, in the protocol stack
      of an existing system or existing system design, by placing a new
      layer between the existing IP layer and the OSIRM Layer 3 drivers.
      Source code access for the existing stack is not required, but the
      system that contains the stack does need to be modified [R4301].

   $ bump-in-the-wire
      (I) An implementation approach that places a network security
      mechanism outside of the system that is to be protected. (Compare:
      bump-in-the-stack.)

      Example: IPsec can be implemented outboard, in a physically
      separate device, so that the system that receives the IPsec
      protection does not need to be modified at all [R4301]. Military-
      grade link encryption has mainly been implemented as bump-in-the-
      wire devices.

   $ business-case analysis
      (N) An extended form of cost-benefit analysis that considers
      factors beyond financial metrics, including security factors such
      as the requirement for security services, their technical and
      programmatic feasibility, their qualitative benefits, and
      associated risks. (See: risk analysis.)

   $ byte
      (I) A fundamental unit of computer storage; the smallest
      addressable unit in a computer's architecture. Usually holds one
      character of information and, today, usually means eight bits.
      (Compare: octet.)

      Usage: Understood to be larger than a "bit", but smaller than a
      "word". Although "byte" almost always means "octet" today, some
      computer architectures have had bytes in other sizes (e.g., six
      bits, nine bits). Therefore, an STD SHOULD state the number of
      bits in a byte where the term is first used in the STD.

   $ C field
      (D) See: Compartments field.

   $ C1 or C2 computer system
      (O) /TCSEC/ See: Tutorial under "Trusted Computer System
      Evaluation Criteria".

   $ CA
      (I) See: certification authority.

   $ CA certificate
      (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".

   $ CA domain
      (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.)

   $ 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

      by C. (b) UNIX systems sometimes include "ROT13" software that
      implements a Caesar cipher with K=13 (i.e., ROTate by 13).

   $ call back
      (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.

   $ CAM
      (O) See: Certificate Arbitrator Module.

   $ 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. (c) 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.

   $ capability list
      (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:

      access control list, access control matrix, access profile,
      capability token.)

   $ capability token
      (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.)

   $ 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.

   $ CAPI
      (I) See: cryptographic application programming interface.

   $ 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.)

   $ card
      See: cryptographic card, FORTEZZA, payment card, PC card, smart
      card, token.

   $ card backup
      See: token backup.

   $ card copy
      See: token copy.

   $ card restore
      See: token restore.

   $ 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]

   $ 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]

   $ 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]

   $ 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]

   $ category
      (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.)

   $ CAW
      (N) See: certification authority workstation.

   $ CBC
      (N) See: cipher block chaining.

   $ CCA
      (O) See: cardholder certification authority.

   $ CCEP
      (O) See: Commercial COMSEC Endorsement Program.

   $ CCI
      (O) See: Controlled Cryptographic Item.

   $ CCITT
      (N) Acronym for French translation of International Telephone and
      Telegraph Consultative Committee. Now renamed ITU-T.

   $ CCM
      (N) See: Counter with Cipher Block Chaining-Message Authentication
      Code.

   $ 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.

   $ CERT
      (I) See: computer emergency response team.

   $ certificate
      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.

   $ 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.

   $ certificate authority
      (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]).

   $ certificate chain
      (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".

   $ certificate chain validation
      (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.)

   $ certificate creation
      (I) The act or process by which a CA sets the values of a digital
      certificate's data fields and signs it. (See: issue.)

   $ 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.)

   $ certificate extension
      (I) See: extension.

   $ certificate holder
      (D) Synonym for the "subject" of a digital certificate. (Compare:
      certificate owner, 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 be misunderstood as
      referring to a system entity or component, such as a repository,
      that simply has possession of a copy of the certificate.

   $ certificate management
      (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.)

   $ certificate management authority (CMA)
      (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.

   $ certificate owner
      (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.

   $ certificate path
      (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]).

   $ certificate policy
      (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.)

      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.)

   $ 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.

   $ certificate profile
      (I) A specification (e.g., [DoD7, R3280]) of the format and
      semantics 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.)

   $ 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.

   $ certificate rekey
      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

      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 (c) 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.

   $ 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".

   $ certificate request
      (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).

   $ certificate revocation
      (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.

   $ certificate revocation list (CRL)
      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]

   $ certificate revocation tree
      (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.)

   $ certificate serial number
      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 (c) 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]

   $ certificate status authority
      (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.

   $ 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.)

   $ certificate update
      (I) The act or process by which non-key data items bound in an
      existing public-key certificate, especially authorizations granted

      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".)

   $ certificate user
      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.

   $ certificate validation
      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 semantics: Parses the certificate's
         syntax and interprets its semantics, applying rules specified
         for and by its data fields, such as for critical extensions in
         an X.509 certificate.

      -  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.)

   $ 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]

   $ certification authority (CA)
      1. (I) An entity that issues digital certificates (especially
      X.509 certificates) and vouches for the binding between the data
      items in a certificate.

      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).

   $ certification authority workstation (CAW)
      (N) A computer system that enables a CA to issue digital
      certificates and supports other certificate management functions
      as required.

   $ 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".

      -  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".

   $ 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

      relative to a "particular" (i.e., specific) user, not absolutely
      for all users.

   $ 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.

   $ certification practice statement (CPS)
      (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, (c) 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]

   $ 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.

   $ 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 identity of the

      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.

   $ CFB
      (N) See: cipher feedback.

   $ chain
      (D) See: trust chain.

   $ Challenge Handshake Authentication Protocol (CHAP)
      (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.)

   $ challenge-response
      (I) An authentication process that verifies an identity 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.

   $ Challenge-Response Authentication Mechanism (CRAM)
      (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.

   $ channel
      1. (I) An information transfer path within a system. (See: covert
      channel.)

      2. (O) "A subdivision of the physical medium allowing possibly
      shared independent uses of the medium." (RFC 3753)

   $ channel capacity
      (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.

   $ CHAP
      (I) See: Challenge Handshake Authentication Protocol.

   $ checksum
      (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).

   $ Chinese wall policy
      (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

      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.

   $ chosen-ciphertext attack
      (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.

   $ chosen-plaintext attack
      (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.

   $ CIAC
      (O) See: Computer Incident Advisory Capability.

   $ CIK
      (N) See: cryptographic ignition key.

   $ cipher
      (I) A cryptographic algorithm for encryption and decryption.

   $ cipher block chaining (CBC)
      (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.

   $ cipher feedback (CFB)
      (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.

   $ 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]

   $ ciphertext
      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.)

   $ ciphertext auto-key (CTAK)
      (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.

   $ ciphertext-only attack
      (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.)

   $ ciphony
      (O) The process of encrypting audio information.

   $ CIPSO
      (I) See: Common IP Security Option.

   $ CKL
      (I) See: compromised key list.

   $ Clark-Wilson model
      (N) A security model [Clark] to maintain data integrity in the
      commercial world. (Compare: Bell-LaPadula model.)

   $ 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.

   $ Class A1, B3, B2, B1, C2, or C1 computer system
      (O) /TCSEC/ See: Tutorial under "Trusted Computer System
      Evaluation Criteria".

   $ 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.)

      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.)

   $ 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.)

   $ classification level
      (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.)

   $ 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

      against unauthorized disclosure and is marked to indicate its
      classified status." [C4009]

   $ 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.)

   $ clean system
      (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.)

   $ 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.

   $ 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.)

   $ clearance
      See: security clearance.

   $ clearance level
      (I) The security level of information to which a security
      clearance authorizes a person to have access.

   $ 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.)

      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.)

   $ CLEF
      (N) See: commercially licensed evaluation facility.

   $ client
      (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.

   $ client-server system
      (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".

   $ 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.

   $ closed security environment
      (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

      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.)

   $ CMA
      (D) See: certificate management authority.

   $ 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.)

   $ CMCS
      (O) See: COMSEC Material Control System.

   $ CMM
      (N) See: Capability Maturity Model.

   $ CMS
      (I) See: Cryptographic Message Syntax.

   $ code
      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.)

      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 (c) "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.

   $ code book
      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.)

   $ code signing
      (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.

   $ code word
      (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.)

   $ COI
      (I) See: community of interest.

   $ cold start
      (N) /cryptographic module/ A procedure for initially keying
      cryptographic equipment. [C4009]