Implementing Company Classification Policy with the S/MIME Security Label
RFC 3114

Document Type RFC - Informational (May 2002; No errata)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
This information refers to IESG processing after the RFC was initially published:
IESG IESG state RFC 3114 (Informational)
Consensus Boilerplate Unknown
Telechat date
Responsible AD Steven Bellovin
Send notices to <>, <>
Network Working Group                                         W. Nicolls
Request for Comments: 3114                            Forsythe Solutions
Category: Informational                                         May 2002

              Implementing Company Classification Policy
                     with the S/MIME Security Label

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.


   This document discusses how company security policy for data
   classification can be mapped to the S/MIME security label.  Actual
   policies from three companies provide worked examples.

1. Introduction

   Security labels are an optional security service for S/MIME.  A
   security label is a set of security information regarding the
   sensitivity of the content that is protected by S/MIME encapsulation.
   A security label can be included in the signed attributes of any
   SignedData object.  A security label attribute may be included in
   either the inner signature, outer signature, or both.  The syntax and
   processing rules for security labels are described in RFC 2634 [ESS].

   The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT',
   document are to be interpreted as described in RFC 2119 [MUSTSHOULD].

1.1 Information Classification Policies

   Information is an asset, but not all information has the same value
   for a business.  Not all information needs to be protected as
   strongly as other information.

   Research and development plans, marketing strategies and
   manufacturing quality specifications developed and used by a company
   provide competitive advantage.  This type of information needs

Nicolls                      Informational                      [Page 1]
RFC 3114       Implementing Company Classification Policy       May 2002

   stronger protective measures than other information, which if
   disclosed or modified, would cause moderate to severe damage to the

   Other types of information such as internal organization charts,
   employee lists and policies may need little or no protective measures
   based on value the organization places on it.

   A corporate information classification policy defines how its
   information assets are to be protected.  It provides guidance to
   employees on how to classify information assets.  It defines how to
   label and protect an asset based on its classification and state
   (e.g., facsimile, electronic transfer, storage, shipping, etc.).

1.2 Access Control and Security Labels

   "Access control" is a means of enforcing authorizations.  There are a
   variety of access control methods that are based on different types
   of policies and rely on different security mechanisms.

   - Rule based access control is based on policies that can be
     algorithmically expressed.

   - Identity based access control is based on a policy which applies
     explicitly to an individual person or host entity, or to a defined
     group of such entities.  Once identity has been authenticated, if
     the identity is verified to be on the access list, then access is

   - Rank base access control is based on a policy of hierarchical
     positions in an organization.  It is based on who you are in the
     company structure.  A rank-based policy would define what
     information that the position of Partner or Senior Consultant could

   - Role based access control is based on a policy of roles in an
     organization.  It may or may not be hierarchical.  It is based on
     who you are in the company.  The role-based policy would define
     what information that the role of Database Administrator, Network
     Administrator, Mailroom Clerk or Purchaser could access.

   Rule, rank and role-based access control methods can rely on a
   security label as the security mechanism to convey the sensitivity or
   classification of the information.  When processing an S/MIME
   encapsulated message, the sensitivity information in the message's
   security label can be compared with the recipient's authorizations to
   determine if the recipient is allowed to access the protected

Nicolls                      Informational                      [Page 2]
RFC 3114       Implementing Company Classification Policy       May 2002

   An S/MIME security label may be included as a signed attribute in the
Show full document text