draft-brown-eppsig.txt

Internet Engineering Task Force                                 G. Brown
Internet-Draft                                            CentralNic Ltd
Intended status: Experimental                         September 23, 2011
Expires: March 26, 2012


    XML Digital Signatures Extension for the Extensible Provisioning
                                Protocol
                           draft-brown-eppsig

Abstract

   This document describes an Extensible Provisioning Protocol (EPP)
   extension mapping for the use of XML Digital Signatures.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on March 26, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.





Brown                    Expires March 26, 2012                 [Page 1]

Internet-Draft        Launch Phase Mapping for EPP        September 2011


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Conventions Used in This Document  . . . . . . . . . . . .  3
   2.  Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Extension Elements . . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  Example Frames . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Use of Signatures  . . . . . . . . . . . . . . . . . . . . . .  7
   5.  Verification of Signatures . . . . . . . . . . . . . . . . . .  7
   6.  Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . . .  8
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   9.  Normative References . . . . . . . . . . . . . . . . . . . . .  9
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10





































Brown                    Expires March 26, 2012                 [Page 2]

Internet-Draft        Launch Phase Mapping for EPP        September 2011


1.  Introduction

   This document describes an extension mapping for version 1.0 of the
   Extensible Provisioning Protocol (EPP) [RFC5730].  This EPP mapping
   provides a mechanism by which digital signatures [RFC3275] may be
   incorporated into EPP frames.

   While EPP provides a number of security features, such as strong
   client-server authentication, it provides no mechanism for non-
   repudiation or authentication of origin.  This extension provides a
   means by which the contents of an EPP frame may be digitally signed,
   preventing future repudiation by the client or server which produced
   them.

1.1.  Conventions Used in This Document

   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 RFC 2119 [RFC2119].

   XML is case sensitive.  Unless stated otherwise, XML specifications
   and examples provided in this document MUST be interpreted in the
   character case presented in order to develop a conforming
   implementation.

   "eppSig-1.0" is used as an abbreviation for
   "urn:centralnic:params:xml:ns:eppSig-1.0".  The XML namespace prefix
   "eppSig" is used, but implementations MUST NOT depend on it and
   instead employ a proper namespace-aware XML parser and serializer to
   interpret and output the XML documents.


2.  Use Cases

   Digital signatures may be useful in a number of scenarios, such as:

   1.  a registry which charges a very high fee for object provisioning,
       where the cost of refunds and chargebacks is sufficiently high
       that it is necessary to deter frivolous registration requests.

   2.  a registry operating at a high level of security, where defence-
       in-depth and the need to provide a full audit trail require
       strong authenticity of provisioning requests.

   3.  future extensions to EPP may permit use of transport protocols
       such as SMTP [RFC5321] or XMPP [RFC6120], which cannot provide
       end-to-end authenticity of frames.




Brown                    Expires March 26, 2012                 [Page 3]

Internet-Draft        Launch Phase Mapping for EPP        September 2011


3.  Extension Elements

   This extension defines a single element, <eppSig:signature>, which
   may appear in the <extension> element of <command> and <result>
   frames.

   The <eppSig:signature> element may contain any element permitted in
   [RFC3275].

3.1.  Example Frames

   Example <command> frame containing an XML digital signature:

   <?xml version="1.0" encoding="utf-8" standalone="no"?>
   <epp
    xmlns="urn:ietf:params:xml:ns:epp-1.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <command>
     <create>
      <domain:create
       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
       <domain:name>example.com</domain:name>
       <domain:period unit="y">2</domain:period>
       <domain:ns>
        <domain:hostObj>ns1.example.com</domain:hostObj>
        <domain:hostObj>ns2.example.com</domain:hostObj>
       </domain:ns>
       <domain:registrant>jd1234</domain:registrant>
       <domain:contact type="admin">sh8013</domain:contact>
       <domain:contact type="tech">sh8013</domain:contact>
       <domain:authInfo>
        <domain:pw>2fooBAR</domain:pw>
       </domain:authInfo>
      </domain:create>
     </create>
     <extension>
      <eppSig:signature
       xmlns:eppSig="urn:centralnic:params:xml:ns:eppSig-1.0">
       <ds:Signature
        xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
         <ds:CanonicalizationMethod
          Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
         <ds:SignatureMethod
          Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
         <ds:Reference>
          <ds:Transforms>
           <ds:Transform



Brown                    Expires March 26, 2012                 [Page 4]

Internet-Draft        Launch Phase Mapping for EPP        September 2011


    Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
          </ds:Transforms>
          <ds:DigestMethod
           Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
          <ds:DigestValue>
           UJEib8S59LmAwI9z1imSEKVn/D4=
          </ds:DigestValue>
         </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>
         iqnL15xs5AoaNxjqtmekYevtCblgZhLAio...
        </ds:SignatureValue>
       </ds:Signature>
      </eppSig:signature>
     </extension>
     <clTRID>ABC-12345</clTRID>
    </command>
   </epp>

   Example <result> frame containing an XML digital signature:































Brown                    Expires March 26, 2012                 [Page 5]

Internet-Draft        Launch Phase Mapping for EPP        September 2011


   <?xml version="1.0" encoding="utf-8" standalone="no"?>
   <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
    <response>
     <result code="1000">
      <msg>Command completed successfully</msg>
     </result>
     <resData>
      <domain:creData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
       <domain:name>example.com</domain:name>
       <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate>
       <domain:exDate>2001-04-03T22:00:00.0Z</domain:exDate>
      </domain:creData>
     </resData>
     <extension>
      <eppSig:signature
       xmlns:eppSig="urn:centralnic:params:xml:ns:eppSig-1.0">
       <ds:Signature
        xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
         <ds:CanonicalizationMethod
          Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
         <ds:SignatureMethod
          Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
         <ds:Reference>
          <ds:Transforms>
           <ds:Transform
    Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
          </ds:Transforms>
          <ds:DigestMethod
           Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
          <ds:DigestValue>
           EEijkGTFZEbgbOnZ/XIR/VSKPAM=
          </ds:DigestValue>
         </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>
         iqnL15xs5AoaNxjqtmekYevtCblgZhLAio...
        </ds:SignatureValue>
       </ds:Signature>
      </eppSig:signature>
     </extension>
     <trID>
      <clTRID>ABC-12345</clTRID>
      <svTRID>54321-XYZ</svTRID>
     </trID>
    </response>
   </epp>




Brown                    Expires March 26, 2012                 [Page 6]

Internet-Draft        Launch Phase Mapping for EPP        September 2011


4.  Use of Signatures

   Servers which support this extension MUST include the extension
   namespace in an <extURI> element in the the <svcExtension> element of
   the <greeting> frame sent to the client at the beginning of a session
   (and in response to a <hello> command).  The server MUST include an
   <eppSig:signature> element, containing a valid XML digital signature,
   in the <extension> element of all <result> frames.

   Clients which support this extension MUST include the extension
   namespace in an <objURI> element in the the <svcs> element of the
   <login> frame sent to the server at the beginning of each session, if
   that server also supports the extension.  The client MUST include an
   <eppSig:signature> element, containing a valid XML digital signature,
   in the <extension> element of all <command> frames.


5.  Verification of Signatures

   If a server which supports this extension receives a signed <command>
   frame from a client, it MUST verify the signature of the frame.  If
   the signature is successfully verified, the server MUST proceed with
   the processing of the <command> frame as normal.  If the signature
   cannot be successfully verified, the server MUST not proceed with the
   processing of the <command> frame, and MUST return a 2200
   authentication error to the client.

   If a client which supports this extension receives a signed <result>
   frame from a server, it MUST verify the signature of the frame.  If
   the signature cannot be successfully verified, the client MAY notify
   the end user of an error, but SHOULD notify an operator or system
   administrator for subsequent investigation.



















Brown                    Expires March 26, 2012                 [Page 7]

Internet-Draft        Launch Phase Mapping for EPP        September 2011


6.  Formal Syntax

   <?xml version="1.0" encoding="UTF-8"?>

   <schema
     targetNamespace="urn:centralnic:params:xml:ns:eppSig-1.0"
     xmlns:eppSig="urn:centralnic:params:xml:ns:eppSig-1.0"
     xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
     xmlns="http://www.w3.org/2001/XMLSchema"
     elementFormDefault="qualified">

     <import namespace="http://www.w3.org/2000/09/xmldsig#" />

     <annotation>
       <documentation>
         Extensible Provisioning Protocol v1.0
         XML digital signature extension schema
       </documentation>
     </annotation>

     <!--
     Child elements found in EPP commands.
     -->
     <element name="signature" type="eppSig:signatureType"/>

     <complexType name="signatureType">
       <sequence>
         <any namespace="http://www.w3.org/2000/09/xmldsig#" />
       </sequence>
     </complexType>
   </schema>


7.  Security Considerations

   XML Digital Signatures use a Public Key Infrastructure.  To verify a
   digital signature, one must use the signer's public key: to ensure
   the authenticity of the signature, this key must be obtained via a
   secure, out-of-band channel.

   Clients and servers which support this extension MUST exchange public
   key information using a facility that provides privacy and integrity
   services to protect against unintended disclosure and modification
   while in transit.  For example, a server might publish its public key
   as a self-signed certificate in a TLSA [DANE] resource record in the
   DNS.  Alternatively, both clients and servers may exchange keys via a
   HTTPS [RFC2818] service which securely authenticates both parties.




Brown                    Expires March 26, 2012                 [Page 8]

Internet-Draft        Launch Phase Mapping for EPP        September 2011


8.  IANA Considerations

   This document uses URNs to describe XML namespaces and XML schemas
   conforming to a registry mechanism described in [RFC3688].  Two URI
   assignments were requested and have been registered by the IANA.

   Registration request for the digital signature namespace:

   URI: urn:centralnic:params:xml:ns:eppSig-1.0

   Registrant Contact: See the "Author's Address" section of this
   document.

   XML: None.  Namespace URIs do not represent an XML specification.

   Registration request for the registry grace period XML schema:

   URI: urn:centralnic:params:xml:ns:eppSig-1.0

   Registrant Contact: See the "Author's Address" section of this
   document.

   XML: See the "Formal Syntax" section of this document.


9.  Normative References

   [DANE]     Hoffman, P. and J. Schlyter, "Using Secure DNS to
              Associate Certificates with Domain Names For TLS",
              September 2011.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

   [RFC3275]  Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup
              Language) XML-Signature Syntax and Processing", RFC 3275,
              March 2002.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              January 2004.

   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              October 2008.

   [RFC5730]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
              STD 69, RFC 5730, August 2009.



Brown                    Expires March 26, 2012                 [Page 9]

Internet-Draft        Launch Phase Mapping for EPP        September 2011


   [RFC6120]  Saint-Andre, P., "Extensible Messaging and Presence
              Protocol (XMPP): Core", RFC 6120, March 2011.


Author's Address

   Gavin Brown
   CentralNic Ltd
   35-39 Mooregate
   London, England  EC2R 6AR
   GB

   Phone: +44 8700 170 900
   Email: gavin.brown@centralnic.com
   URI:   http://www.centralnic.com




































Brown                    Expires March 26, 2012                [Page 10]