<?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 RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
  <!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
  <!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>

<rfc category="info" docName="draft-hallambaker-dkim-extensions-01" ipr="full3978">

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
         full title is longer than 39 characters -->

    <title abbrev="DKIM Extensions">DKIM Extensions</title>
    <author fullname="Phillip Hallam-Baker" initials="P. M."
            surname="Hallam-Baker">
      <organization>VeriSign Inc</organization>
      <address>
        <email>pbaker@verisign.com</email>
      </address>
    </author>

    <date day="13" month="July" year="2008" />

    <area>General</area>

    <workgroup>Internet Engineering Task Force</workgroup>

    <keyword>DNS</keyword>
    <keyword>DKIM</keyword>
    <keyword>Mail</keyword>
    <abstract>
      <t>
        Optional extensions for DKIM are described. A DKIM Policy statement is defined for the 
        policy 'this zone never sends mail'. The NULL Key Algorithm is defined to simplify 
        management of large zones where most mail is signed but with important exceptions. The 
        X509 key record extension allows the location from which an X.509v3 certificate for 
        the key specified in the record may be obtained.
      </t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <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="NoMail Policy">

      <t>
        The NOMAIL policy is declared in an SSP record using the tag "NOMAIL".         
      </t>
      <t>
        No parameters are specified for the NOMAIL policy.
      </t>
      <t>
       If specified the NOMAIL policy states that no mail is sent from the domain to 
       which it is attached. All mail that purports to have been sent by that domain
       MUST be considered suspicious.
      </t>
      
    </section>


    <section title="NULL Signature Algorithm">

      <t>
        The NULL Signature algorithm is a DKIM signature algorithm that always produces
	the same signature value regardless of the message contents. 
      </t>
      <t>
        A message signed
        with the NULL signature MUST be treated as if it were unsigned for all purposes
        other than verifying compliance with a DKIM policy. For purposes of policy
        compliance, a message that carries a NULL signature is considered to be 
        compliant if and only if it is consistent with the signing restrictions
        specified in the key record. 
      </t>
      <t>
       A key record that specifies the NULL signature algorithm SHOULD specify 
       usage restricted to specific senders.
      </t>
      
    </section>

    <section title="X509 Certificate Location Extension">

      <t>
        The x509 key record extension specifies a URL from which a certificate
        chain corresponding to the key specified in the key record may be obtained.
      </t>
      <t>
        The key chain is specified as a CMS SignedData structure with no data.
      </t>
      
    </section>
      
    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>
        The ideas in this document arose from extensive discussions with the
        DKIM working group, in particular Hector Santos and others.
      </t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>
        This document requests allocation of a DKIM SSP tag 'NOMAIL'
      </t>

    </section>

    <section anchor="Security" title="Security Considerations">
      <t>
          The NOMAIL policy MAY be employed to perform a denial of service attack.
      </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">
      &RFC2119;


    </references>


  </back>
</rfc>
