<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->

<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC5750 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5750.xml">
<!ENTITY RFC5751 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5751.xml">

]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-kadobayashi-smime-secureops-00" ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
      <title abbrev="S/MIME in Enterprise">Use of S/MIME Encryption Function in Enterprises</title>

<author fullname="Youki Kadobayashi" initials="Y."
       surname="Kadobayashi">
 <organization abbrev="NAIST">Nara Institute of Science and Technology</organization>
 <address>
  <email>youki-k@is.aist-nara.ac.jp</email>
 </address>
</author>

<author fullname="Kazunori Ando" initials="K."
       surname="ANDO">
 <organization abbrev="BBsec">BroadBand Security, Inc.</organization>
 <address>
  <email>ando@bbsec.co.jp</email>
 </address>
</author>

<author initials="K." surname="Kasamatsu"
        fullname="Kohei Kasamatsu">
 <organization abbrev="NTT SOFT">
  NTT Software Corporation
 </organization>
 <address>
  <email>kasamatsu.kohei@po.ntts.co.jp</email>
</address>
</author>


<author initials="S." surname="Kanno"
        fullname="Satoru Kanno">
 <organization abbrev="NTT SOFT">
  NTT Software Corporation
 </organization>
 <address>
  <email>kanno.satoru@po.ntts.co.jp</email>
</address>
</author>


<date/>
   
    <area>Security</area>

    <workgroup>Internet Engineering Task Force</workgroup>

    <keyword>S/MIME</keyword>
    <keyword>Secure Operetion</keyword>


    <abstract>
	  <t>
	  In this document, we provide a method for enterprises to utilize and operate 
	  the use of S/MIME to handle highly confidential information.
      </t>
    </abstract>
  </front>

  <middle>
    
<section title="Introduction">
 <t>
     Use of the S/MIME encryption function within enterprises allows them to handle highly confidential information such as business critical
     information. However, use of encryption, decreases the functionality of anti-virus software and creates the need to manage expired digital
     certificates. In this document, we provide a method for enterprises to utilize and operate the use of S/MIME to handle highly confidential
     information.
 </t>
 <section title="Requirements Language">
 <t>
     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
     and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119">RFC 2119</xref>.
 </t>
 </section>
</section>

<section title="Decrease of anti-virus functionality on the e-mail server">
 <t>
     There is an issue where anti-virus software on e-mail servers may not properly function when encrypted e-mails are received.
     The following issues are also seen when the anti-virus software does not function properly.
 </t>
 <section title="Use of anti-virus function at S/MIME user agent">
  <t>
  Using S/MIME at user agent(MUA), it is highly recommended that the S/MIME decrypted e-mails must be checked 
  by anti-virus function immediately after the decryption.
  </t>
 </section>
 <section title="Use of S/MIME at the Gateway">
 <t>
     Using S/MIME at the Gateway is one way to work around the anti-virus issue. By implementing S/MIME at the Gateway,
     viruses can be detected at the Gateway. By storing and managing keys of senders at the Gateway,
     e-mails can be decrypted and scanned for viruses at the Gateway.
 </t>
 <t>
    
 </t>
 </section>
</section>
   
<section title="Decreased monitoring of highly confidential e-mails that are sent and received">
 <t>
     Monitoring may decrease when sending highly confidential information,
     such as business information to a party outside of the organization.
     This issue differs from the issue where anti-virus functionality decreases,
     and an organization must consider that e-mails must be monitored when sending the e-mail (immediate monitoring)
     and e-mail contents must be monitored every so often after the e-mail has been sent (intermittent monitoring).
 </t>
 <t>
     For immediate monitoring, S/MIME at the Gateway introduced previously (3.1) can be used to maintain confidentiality
     outside of the organization and monitoring in accordance to organizational policies also becomes possible.
     For intermittent monitoring, the following methods where keys are managed or decrypted e-mails are managed can be used.
 </t>


 <section title="Method for managing keys">
    <t>
        When digital certificates are disposed, e-mails that were encrypted using that certificate cannot be decrypted,
        so you can choose to manage and maintain such digital certificates. However, the disclosure of
        a private key for an expired digital certificate contains the same dangers as the disclosure of a private key
        for a valid digital certificate.
        Keys can be managed by sharing keys or delegating management of the keys through the implementation of S/MIME at the Gateway.
    </t>
 </section>
 <section title="Accessing e-mails that have been decrypted">
    <t>
        Since the contents of encrypted e-mails cannot be read if the expired keys are not stored,
        decrypted e-mails can be stored in plaintext if expired keys are not managed and stored.
        In this case, you may be saving highly confidential information in plaintext,
        therefore access to such information must be managed properly.
    </t>
  </section>
</section>
   
<section title="Importance of the management of expired certificates">
    <t>
        In order to be able to use encrypted e-mails into the future, you must store expired digital certificates of the senders.
        Expired digital certificates may be leveraged for impersonation, so storage of these certificates must be done carefully,
        increasing the burden on the recipient.
        To handle this issue, you can use the following technological measure in addition to the methods described in 4.1 and 4.2.
    </t>
    <section title="Use of Dual Key Pairs">
        <t>
            Key pairs that have expired should be disposed of as quickly as possible,
            but key pairs for encryption must be stored for an extended period of time for decryption purposes.
            One can use separate key pairs for encryption and signing.
            This allows a user to not have to change key pairs for encryption when the certificate has expired.
        </t>
    </section>
</section>

    <!-- This PI places the pagebreak correctly (before the section title) in the text output. -->

    <?rfc needLines="8" ?>




<section anchor="Acknowledgements" title="Acknowledgements">
 <t>
    TBD.
 </t>
</section>

    <!-- Possibly a 'Contributors' section ... -->

<section anchor="IANA" title="IANA Considerations">
    <t>This memo includes no request to IANA.</t>
</section>

<section anchor="Privacy" title="Privacy Considerations">
 <t>
     TBD.
 </t>
</section>

<section anchor="Security" title="Security Considerations">
    <t>
        TBD.
    </t>
    
</section>
</middle>

 <!--  *****BACK MATTER ***** -->

<back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->

<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
</references>

<references title="Informative References">
&RFC5750;
&RFC5751;
</references>

</back>


</rfc>
