[Docs] [txt|pdf|xml] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 RFC 6492

Secure Inter-Domain Routing                                    G. Huston
Internet-Draft                                                R. Loomans
Intended status: Standards Track                             B. Ellacott
Expires: February 8, 2009                                          APNIC
                                                              R. Austein
                                                                     ISC
                                                          August 7, 2008


           A Protocol for Provisioning Resource Certificates
              draft-ietf-sidr-rescerts-provisioning-03.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on February 8, 2009.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   This document defines a framework for certificate management
   interactions between a resource issuer ("Internet Registry" or "IR")
   and a resource recipient ("Internet Service Provider" or "ISP")
   through the specification of a protocol for interaction between the
   two parties.  The protocol supports the transmission of requests from



Huston, et al.          Expires February 8, 2009                [Page 1]

Internet-Draft            Rescert Provisioning               August 2008


   the ISP, and corresponding responses from the IR encompassing the
   actions of certificate issuance, certificate revocation and
   certificate status information reports.  This protocol is intended to
   be limited to the application of resource certificate management and
   is not intended to be used as part of a more general certificate
   management framework.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Protocol Specification . . . . . . . . . . . . . . . . . . . .  4
     3.1.  CMS Profile  . . . . . . . . . . . . . . . . . . . . . . .  5
       3.1.1.  SignedData Content Type  . . . . . . . . . . . . . . .  6
       3.1.2.  ASN.1  . . . . . . . . . . . . . . . . . . . . . . . . 10
     3.2.  Common Message format  . . . . . . . . . . . . . . . . . . 12
     3.3.  Control - Resource Class Query . . . . . . . . . . . . . . 14
       3.3.1.  Resource Class List Query  . . . . . . . . . . . . . . 14
       3.3.2.  Resource Class List Response . . . . . . . . . . . . . 14
     3.4.  CA - Certificate Issuance  . . . . . . . . . . . . . . . . 19
       3.4.1.  Certificate Issuance Request . . . . . . . . . . . . . 19
       3.4.2.  Certificate Issuance Response  . . . . . . . . . . . . 20
     3.5.  Certificate Revocation . . . . . . . . . . . . . . . . . . 21
       3.5.1.  Certificate Revocation Request . . . . . . . . . . . . 21
       3.5.2.  Certificate Revocation Response  . . . . . . . . . . . 22
     3.6.  Request-Not-Performed Response . . . . . . . . . . . . . . 22
   4.  XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 23
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 25
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 26
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 26
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 27
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
   Intellectual Property and Copyright Statements . . . . . . . . . . 29














Huston, et al.          Expires February 8, 2009                [Page 2]

Internet-Draft            Rescert Provisioning               August 2008


1.  Introduction

   This document defines a framework for certificate management
   interactions between a resource issuer ("Internet Registry" or "IR")
   and a resource recipient ("Internet Service Provider" or "ISP")
   through the specification of a protocol for interaction between the
   two parties.  The protocol supports the transmission of requests from
   the ISP, and corresponding responses from the IR encompassing the
   actions of certificate issuance, certificate revocation and
   certificate status information reports.  This protocol is intended to
   be limited to the application of resource certificate management and
   is not intended to be used as part of a more general certificate
   management framework.

1.1.  Terminology

   It is assumed that the reader is familiar with the terms and concepts
   described in "Internet X.509 Public Key Infrastructure Certificate
   and Certificate Revocation List (CRL) Profile" [RFC5280], "X.509
   Extensions for IP Addresses and AS Identifiers" [RFC3779], "Internet
   Protocol" [RFC0791], "Internet Protocol Version 6 (IPv6) Addressing
   Architecture" [RFC4291], "Internet Registry IP Allocation Guidelines"
   [RFC2050], and related regional Internet registry address management
   policy documents.

   Additional terms used in this document are:

   "IR"  an abbreviation of "Internet Registry", using in the context of
      this document as an entity undertaking the role of resource
      issuer.  An IR is a Certificate Authority, and can issue Resource
      Certificates.

   "ISP"  an abbreviation of "Internet Service Provider", using in the
      context of this document as an entity undertaking the role of
      resource recipient who is the subject of a Resource Certificate.
      An ISP may be issued with a CA-enabled certificate, allowing the
      entity to also assume the role of an IR.

   "resource class"  a resource class refers to a collection of
      resources that can be certified in a single resource certificate
      by an issuer.

   "server"  in the context of this client/server protocol
      specification, the IR assumes the role of the "server."







Huston, et al.          Expires February 8, 2009                [Page 3]

Internet-Draft            Rescert Provisioning               August 2008


   "client"  in the context of this client/server protocol
      specification, the ISP assumes the role of the "client."


   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.


2.  Scope

   This Resource PKI (RPKI) certificate provisioning protocol defines a
   basic set of interactions that allow an ISP to request certificate
   issuance, revocation and status information from the IR, and for a IR
   to maintain an issued certificate set that is aligned to the
   allocation records relating to each ISP.  The IR's resource
   allocation database, is the authoritative source of what resource
   allocations the IR may certify for an ISP.

   A resource recipient (ISP) may also undertake the role of a resource
   issuer (IR), such as in the case of a Local Internet Registry (LIR).

   This protocol specification does not encompass:

   o  signing of objects with keys that are certified by resource
      certificates, nor the issuance of end-entity certificates.

   o  the specification of interaction with the IR's resource allocation
      database, nor the specification of a protocol to manage the
      publication repository.

   o  the interactions between client and server that establish
      identities, exchange the keys used in the protection of the
      communications channel between client and server, and the exchange
      of the certificates and validation PKI contexts used in the
      Cryptographic Message Syntax message exchange.



3.  Protocol Specification

   This RPKI certificate provisioning protocol is expressed as a simple
   request/response interaction, where the client passes a request to
   the server, and the server generates a corresponding response.

   The protocol is implemented as an exchange of messages.

   Messages are passed over an HTTPS [RFC2818] transport connection that



Huston, et al.          Expires February 8, 2009                [Page 4]

Internet-Draft            Rescert Provisioning               August 2008


   safeguards against interception and replay attacks.  The HTTPS
   session uses mutually authenticated Transport Layer Security (TLS)
   [RFC4346].  The TLS keys and associated certificate chain used to
   validate TLS transactions is assumed to have been previously
   communicated between the two entities, through mechanisms not defined
   in this protocol specification.  The HTTPS connection will use 2 way
   (mutual) identification.  A message exchange commences with the
   client initiating an HTTP POST with content type of "application/
   x-rpki", with the message object as the body.  The server's response
   will similarly be the body of the response with a content type of
   "application/x-rpki".

   The content of the POST, and the server's response, will be a "well-
   formed" Cryptographic Message Syntax (CMS) [RFC3852] object, encoded
   using the Distinguished Encoding Rules for ASN.1 (DER) [X.509-88],
   formatted in accordance with the CMS profile as specified in the
   following section.  CMS is used as the signing format to sign the
   message object.  The public part of the signing key and the
   associated certificate chain that is used to validate the CMS digital
   signature is assumed to have been communicated between the two
   entities, through mechanisms not defined in this protocol
   specification.  The CMS keys and certificates MAY be the same as
   those used for TLS.

   The protocol's request / response interaction is assumed to be
   reliable, in that all requests will generate a matching response.
   The protocol requires sequential operation, where the server MUST NOT
   accept a client's request unless it has generated and sent a response
   to the client's previous request.  Attempts by the client to initiate
   multiple requests in parallel MUST be detected by the server and
   rejected with an error response.

3.1.  CMS Profile

   The format of the CMS object is:

         ContentInfo ::= SEQUENCE {
           contentType ContentType,
           content [0] EXPLICIT ANY DEFINED BY contentType }

         ContentType ::= OBJECT IDENTIFIER

   The protocol objects are all instances of CMS signed-data objects,
   where the ContentType used is the signed-data type of id-data, namely
   id-signedData, OID = 1.2.840.113549.1.7.2.






Huston, et al.          Expires February 8, 2009                [Page 5]

Internet-Draft            Rescert Provisioning               August 2008


3.1.1.  SignedData Content Type

   According to [RFC3852], signed-data content types shall have the
   ASN.1 type SignedData:

         SignedData ::= SEQUENCE {
           version CMSVersion,
           digestAlgorithms DigestAlgorithmIdentifiers,
           encapContentInfo EncapsulatedContentInfo,
           certificates [0] IMPLICIT CertificateSet OPTIONAL,
           crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
           signerInfos SignerInfos }

         DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier

         SignerInfos ::= SET OF SignerInfo

3.1.1.1.  version

   The version is the syntax version number.  It MUST be 3,
   corresponding to the signerInfo structure having version number 3.

3.1.1.2.  digestAlgorithms

   The digestAlgorithms set MUST include only SHA-256, the OID for which
   is 2.16.840.1.101.3.4.2.1 [RFC4055].  It MUST NOT contain any other
   algorithms.

3.1.1.3.  encapContentInfo

   encapContentInfo is the signed content, consisting of a content type
   identifier and the content itself.

        EncapsulatedContentInfo ::= SEQUENCE {
          eContentType ContentType,
          eContent [0] EXPLICIT OCTET STRING OPTIONAL }

        ContentType ::= OBJECT IDENTIFIER

3.1.1.3.1.  eContentType

   The eContentType for the RPKI Protocol Message object is defined as
   id-ct-xml, and has the numerical value of 1.2.840.113549.1.9.16.1.28.








Huston, et al.          Expires February 8, 2009                [Page 6]

Internet-Draft            Rescert Provisioning               August 2008


         id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
                                   rsadsi(113549) pkcs(1) pkcs9(9) 16 }

         id-ct OBJECT IDENTIFIER ::= { id-smime 1 }

         id-ct-xml OBJECT IDENTIFIER ::= { id-ct 28 }

3.1.1.3.2.  eContent

   The content of a RPKI XML Protocol Object consists of a single
   protocol message, structured according to a define XML schema, as
   defined in subsequent sections of this document.  The eContent field
   of the CMS object is formally defined using ASN.1 as:

             id-ct-xml ::= OCTET STRING -- XML encoded message

3.1.1.4.  certificates

   The certificates field MUST be present, and MUST contain the EE
   certificate of the key pair whose private key value was used to sign
   the CMS.  This MUST NOT be an RPKI certificate, and SHOULD be a
   certificate that is recognised to attest to the identity of the party
   that created the CMS object.

   This field MAY contain other certificates that a relying party may
   use to validate the digital signature of the CMS object.

3.1.1.5.  crls

   This field MUST be present.  The contents of the field are specified
   in [RFC3852].

3.1.1.6.  signerInfo

   SignerInfo is defined under CMS as:

         SignerInfo ::= SEQUENCE {
           version CMSVersion,
           sid SignerIdentifier,
           digestAlgorithm DigestAlgorithmIdentifier,
           signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
           signatureAlgorithm SignatureAlgorithmIdentifier,
           signature SignatureValue,
           unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }







Huston, et al.          Expires February 8, 2009                [Page 7]

Internet-Draft            Rescert Provisioning               August 2008


3.1.1.6.1.  version

   The version number MUST be 3, corresponding with the choice of
   SubjectKeyIdentifier for the sid.

3.1.1.6.2.  sid

   The sid is defined as:

         SignerIdentifier ::= CHOICE {
           issuerAndSerialNumber IssuerAndSerialNumber,
           subjectKeyIdentifier [0] SubjectKeyIdentifier }

   In this profile, the sid MUST be a SubjectKeyIdentifier.

3.1.1.6.3.  digestAlgorithm

   The digestAlgorithm MUST be SHA-256, the OID for which is
   2.16.840.1.101.3.4.2.1.  [RFC4055]

3.1.1.6.4.  signedAttrs

   Signed Attributes are defined as:

         SignedAttributes ::= SET SIZE (1..MAX) OF Attribute

         UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute

         Attribute ::= SEQUENCE {
           attrType OBJECT IDENTIFIER,
           attrValues SET OF AttributeValue }

         AttributeValue ::= ANY

   The signer MUST digitally sign a collection of attributes along with
   the content payload.  Each attribute in the collection MUST be DER-
   encoded.  The syntax for attributes is defined in [X.501], and the
   X.500 Directory provides a rich attribute syntax.  A very simple
   subset of this syntax is used extensively in [RFC3852], where
   ATTRIBUTE.Type and ATTRIBUTE.id are the only parts of the ATTRIBUTE
   class that are employed.

   Each of the attributes used with this CMS profile has a single
   attribute value.  Even though the syntax is defined as a SET OF
   AttributeValue, there MUST be exactly one instance of AttributeValue
   present.

   The SignedAttributes syntax within signerInfo is defined as a SET OF



Huston, et al.          Expires February 8, 2009                [Page 8]

Internet-Draft            Rescert Provisioning               August 2008


   Attribute.  The SignedAttributes MUST include only one instance of
   any particular attribute.

   The signer MUST include the content-type, message-digest and signing-
   time signed attributes.  The signer MAY also include the binary-
   signing-time signed attribute.  Other signed attributes that are
   deemed appropriate MAY also be included.  The intent is to allow
   additional signed attributes to be included if a future need is
   identified.  This does not cause an interoperability concern because
   unrecognized signed attributes are ignored at verification.

3.1.1.6.4.1.  Content-Type Attribute

         id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2)
             us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 }

         ContentType ::= OBJECT IDENTIFIER

   A content-type attribute is required to contain the same object
   identifier as the content type contained in the
   EncapsulatedContentInfo.  The signer MUST include a content-type
   attribute containing the appropriate content type.  Section 11.1 of
   [RFC3852] defines the content-type attribute.

3.1.1.6.4.2.  Message-Digest Attribute

         id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
             us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 }

         MessageDigest ::= OCTET STRING

   The signer MUST include a message-digest attribute, having as its
   value the output of a one-way hash function computed on the content
   that is being signed.  Section 11.2 of [RFC3852] defines the message-
   digest attribute.

3.1.1.6.4.3.  Signing-Time Attribute

         id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
             us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 }

         SigningTime ::= Time

         Time ::= CHOICE {
           utcTime UTCTime,
           generalizedTime GeneralizedTime }

   The signing-time attribute MUST be present.



Huston, et al.          Expires February 8, 2009                [Page 9]

Internet-Draft            Rescert Provisioning               August 2008


   The signing-time attribute specifies the time, based on the local
   system clock, when the digital signature was applied to the content.
   Section 11.3 of [RFC3852] defines the content-type attribute.

3.1.1.6.4.4.  Binary-Signing-Time Attribute

         id-aa-binarySigningTime OBJECT IDENTIFIER ::= { iso(1)
             member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
             smime(16) aa(2) 46 }

         BinarySigningTime ::= BinaryTime

         BinaryTime ::= INTEGER (0..MAX)

   The signer MAY include a binary-signing-time attribute, specifying
   the time at which the digital signature was applied to the content.
   If the binary-signing-time is present, the time that is represented
   MUST represent the same time value as the signing-time attribute.
   The binary-signing-time attribute is defined in [RFC4049].

3.1.1.6.5.  signatureAlgorithm

   The signatureAlgorithm MUST be RSA (rsaEncryption), the OID for which
   is 1.2.840.113549.1.1.1.

3.1.1.6.6.  signature

   The signature value is defined as:

             SignatureValue ::= OCTET STRING

   The signature characteristics are defined by the digest and signature
   algorithms.

3.1.1.6.7.  unsignedAttrs

   unsignedAttrs MUST be omitted.

3.1.2.  ASN.1

   The following is the ASN.1 specification of the CMS signed object
   used by the RPKI provisioning protocol.

         ContentInfo ::= SEQUENCE {
           contentType ContentType,
           content [0] EXPLICIT ANY DEFINED BY contentType }

         ContentType ::= OBJECT IDENTIFIER



Huston, et al.          Expires February 8, 2009               [Page 10]

Internet-Draft            Rescert Provisioning               August 2008


         id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
                                   rsadsi(113549) pkcs(1) pkcs9(9) 16 }

         id-ct OBJECT IDENTIFIER ::= { id-smime 1 }

         id-ct-xml OBJECT IDENTIFIER ::= { id-ct 28 }

         id-ct-xml ::= OCTET STRING -- XML encoded message

         id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
                            us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }

         SignedData ::= SEQUENCE {
           version CMSVersion,
           digestAlgorithms DigestAlgorithmIdentifiers,
           encapContentInfo EncapsulatedContentInfo,
           certificates [0] IMPLICIT CertificateSet OPTIONAL,
           crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
           signerInfos SignerInfos }

         DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier

         SignerInfos ::= SET OF SignerInfo

         SignerInfo ::= SEQUENCE {
           version CMSVersion,
           sid SignerIdentifier,
           digestAlgorithm DigestAlgorithmIdentifier,
           signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
           signatureAlgorithm SignatureAlgorithmIdentifier,
           signature SignatureValue,
           unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }

         SignerIdentifier ::= CHOICE {
           issuerAndSerialNumber IssuerAndSerialNumber,
           subjectKeyIdentifier [0] SubjectKeyIdentifier }

         SignedAttributes ::= SET SIZE (1..MAX) OF Attribute

         UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute

         Attribute ::= SEQUENCE {
           attrType OBJECT IDENTIFIER,
           attrValues SET OF AttributeValue }

         AttributeValue ::= ANY

         SignatureValue ::= OCTET STRING



Huston, et al.          Expires February 8, 2009               [Page 11]

Internet-Draft            Rescert Provisioning               August 2008


         id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2)
             us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 }

         ContentType ::= OBJECT IDENTIFIER

         id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
             us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 }

         MessageDigest ::= OCTET STRING

         id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
             us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 }

         SigningTime ::= Time

         Time ::= CHOICE {
           utcTime UTCTime,
           generalizedTime GeneralizedTime }

         id-aa-binarySigningTime OBJECT IDENTIFIER ::= { iso(1)
             member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
             smime(16) aa(2) 46 }

         BinarySigningTime ::= BinaryTime

         BinaryTime ::= INTEGER (0..MAX)

3.2.  Common Message format

   The XML template for all messages is as follows:

   ---------------------------------------------------------------

   <?xml version="1.0" encoding="UTF-8"?>
   <message xmlns="http://www.apnic.net/specs/rescerts/up-down/"
            version="1"
            sender="sender name"
            recipient = "recipient name"
            type="message type">

   [payload]

   </message>

   ---------------------------------------------------------------






Huston, et al.          Expires February 8, 2009               [Page 12]

Internet-Draft            Rescert Provisioning               August 2008


   version:
      the value of this attribute is the version of this protocol.  This
      document describes version 1.

   sender:
      the value of this attribute is the agreed name of the message
      sender, as determined between the client and the server by prior
      arrangement.

   recipient:
      the value of this attribute is the agreed name of the message
      recipient, as determined between the client and the server by
      prior arrangement.

   type:
      the possible values of this attribute are "list", "list_response",
      "issue", "issue_response", "revoke", "revoke_response", and
      "error_response".

   Conforming parsers MUST reject any document with a version number
   they do not understand, or with any elements or attributes they do
   not understand.  Servers must generate an error response when
   receiving such a request.  Clients should generate an operator alert
   error when receiving such a response.

   A message in this protocol is a digitally signed object that makes
   use of CMS [RFC3852], and is encoded as DER.  It uses the signed-data
   object contentType OID: 1.2.840.113549.1.7.2.  The attribute "id-
   signingTime" (contentType OID: 1.2.840.113549.1.9.5) MUST be present
   in the CMS object.

   The encapsulated content of the CMS wrapping is an XML document.  The
   remainder of this protocol specification omits this CMS wrapper and
   only discusses the XML document.

   Messages are checked using the following tests:

   1.  Check the integrity of the HTTPS message and validate the TLS
       certificate using the PKI that has been determined by prior
       arrangement between client and server.

   2.  Check that the CMS is well-formed.

   3.  Check that the XML is well-formed.

   4.  Check that the XML sender and recipient attributes reference a
       known client and this server's system respectively.




Huston, et al.          Expires February 8, 2009               [Page 13]

Internet-Draft            Rescert Provisioning               August 2008


   5.  Verify the digital signature using the public key provided in the
       certificate carried in the CMS wrapper.

   6.  Validate the CMS-provided certificate using the PKI that has been
       determined by prior arrangement between client and server.

   7.  Check that the value of the version number of the message is 1.

   The checks should generally be applied in the order specified here.

   Any errors encountered while checking items 1 through 6 would cause
   the server to generate an "HTTP 400 Bad Data" response to the HTTPS
   POST operation.  An error in step 7 would cause the server to
   generate a "Request-Not-Performed" error response.

3.3.  Control - Resource Class Query

3.3.1.  Resource Class List Query

   The value of the message "type" message attribute for this query is:

      type="list"


   ---------------------------------------------------------------

   Payload:

   [No message payload is defined for this query]

   ---------------------------------------------------------------


3.3.2.  Resource Class List Response

   The value of the message "type" element for this response is:

      type="list_response"













Huston, et al.          Expires February 8, 2009               [Page 14]

Internet-Draft            Rescert Provisioning               August 2008


   ---------------------------------------------------------------

   Payload:

    <class class_name="class name"
        cert_url="url"
        resource_set_as="as resource set"
        resource_set_ipv4="ipv4 resource set"
        resource_set_ipv6="ipv6 resource set"
        resource_set_notafter="datetime"
        suggested_sia_head="[directory uri]" >
        <certificate cert_url="url"
            req_resource_set_as="as resource set"
            req_resource_set_ipv4="ipv4 resource set"
            req_resource_set_ipv6="ipv6 resource set" >
        [certificate]
        </certificate>

        ...

        (repeated for each current certificate where the client
         is the certificate's subject)

        <issuer>[issuer's certificate]</issuer>
        </class>

    ...

    (repeated for each of the issuer's resource class where the
     client has been allocated resources)


   ---------------------------------------------------------------


   Where the client has been allocated resources from multiple resource
   classes, then the response will contain multiple class elements,
   corresponding to the complete set of the issuer's resource classes
   where the client holds allocated resources.  Those issuer's resource
   classes where the client holds no allocated resources will not be
   included in the response.

   Where the issuer has issued multiple certificates in a resource class
   signed with different keys (as may occur during a staged issuer-key
   rollover), only the most recent certificate issued with the currently
   "active" issuer's key will be listed in the response.

   Each "class" element describes a set of resources that are certified



Huston, et al.          Expires February 8, 2009               [Page 15]

Internet-Draft            Rescert Provisioning               August 2008


   within the scope of a single certificate, referring to a single
   resource class with a common validation path.

   class_name:
      the value of this attribute is the issuer-assigned name of the
      issuer's Resource Class.

   cert_url:
      in the context of a class element, the value of this attribute is
      a pointer to the issuer's CA certificate (i.e. a reference to the
      immediate superior certificate, being the CA-enabled certificate
      where the issuer is the certificate's subject).  Its value is a
      comma-separated list of URIs, of which at least one MUST be an
      RSYNC URI.  Any comma values within a URI MUST be escaped ("%2C").
      The ordering of the list may be interpreted by the client as a
      relative preference for access methods as expressed by the
      publisher of this certificate.

   resource_set_as:
      in the context of a class element, the value of this attribute is
      the set of AS numbers and AS number ranges that the issuer has
      allocated to the client within the scope of this resource class,
      presented in ASCII as a comma-separated list.  The list elements
      are decimal integer values and ranges of decimal integers
      specified by the low and high value of the range with a hyphen
      delimiter, using the canonical order as described in [RFC3779],
      without leading zeros, and with no white space or punctuation
      other than the comma and the hyphen range designator (e.g.:
      resource_set_as="123,456-789,123456").  If there are no AS numbers
      in this Resource Class the empty set will be represented by a null
      string value ("") for this attribute.

   resource_set_ipv4:
      in the context of a class element, the value of this attribute is
      the set of IPv4 addresses that the issuer has allocated to the
      client within the scope of this resource class.  The value is
      presented in ASCII as a comma-separated list of elements.  Each
      element is either an address prefix using the notation of <dotted
      quad>/mask length, or a range specified as low and high range
      values in dotted quad notation with a hyphen delimiter.  The list
      is presented in canonical order, as described in [RFC3779].  The
      dotted quad notation is without leading zeros, and the list
      contains no white space or punctuation other than the period,
      forward slash, hyphen and comma. (e.g.
      resource_set_ipv4="192.0.2.0/26,192.0.2.66-192.0.2.76") If there
      are no IPv4 addresses in this resource class the empty set will be
      represented by a null string value ("") for this attribute.




Huston, et al.          Expires February 8, 2009               [Page 16]

Internet-Draft            Rescert Provisioning               August 2008


   resource_set_ipv6:
      in the context of a class element, the value of this attribute is
      the set of IPv6 addresses that the issuer has allocated to the
      client within the scope of this resource class.  The value is
      presented in ASCII as a comma-separated list of elements.  Each
      element is either an address prefix using the notation of <hex
      nibble sequence>/mask length, or a range specified as low and high
      range values in hex nibble notation with a hyphen delimiter.
      Trailing zero nibbles are truncated and represented by '::'.  The
      list is presented in canonical order, as described in [RFC3779].
      The hex nibble sequence notation is without leading zeros, and the
      list contains no white space or punctuation other than the colon,
      forward slash, hyphen and comma (e.g. resource_set_ipv6="2001:
      0DB8::/48,2001:0DB8:002::-2001:0DB8:005::").  The XML Schema data
      type is "http://www.w3.org/TR/xmlschema-2/#hexBinary" and value is
      case insensitive, with the canonical form being upper case.  If
      there are no IPv6 addresses in this resource class the empty set
      will be represented by a null string value ("") for this
      attribute.

   resource_set_notafter:
      The value of this attribute specified the date/time that would be
      set in the Validity notAfter field in any new certificate issued
      for this particular client within the scope of this resource
      class, should the client request a new certificate.  The time
      format used for the value of this attribute is specified as ISO
      8601 [ISO.8601:2004], and MUST use UTC time (i.e.  YYYY-MM-
      DDThh:mm:ssZ, e.g. 2007-11-29T04:40:00Z).  If the client's
      certificate has a validity notAfter time that is different to this
      this time then the client SHOULD request a new certificate to be
      issued for this resource class.

   suggested_sia_head:  (OPTIONAL)
      If this field is present then it indicates a publication namespace
      which the server has made available to the client to use for its
      own collection of published products.  Presence of this field does
      not mean that the client has permission from the repository
      operator to lodge under this URI, only that the client has
      permission from the server to lodge under this URI.

   [issuer's certificate]
      value is the Base64 encoding of the DER-encoded issuer's CA
      certificate (the CA-enabled certificate where the issuer is the
      certificate's subject).

   Each certificate element describes the most recently issued current
   certificate where the certificate's subject refers to the client for
   each active client key pair.  A "current" certificate is a non-



Huston, et al.          Expires February 8, 2009               [Page 17]

Internet-Draft            Rescert Provisioning               August 2008


   expired, non-revoked certificate.  If no current certificate has been
   issued, then no certificate element will be included in the response.

   cert_url:
      in the context of a certificate element, this is a pointer to the
      location where the certificate issuer has published this
      certificate.  This field is the issuer's suggestion for the AIA
      field for the subject to use in subordinate certificates that are
      issued by the subject.  According to the Resource Certificate
      Profile [insert ref here] the AIA field is a non-empty (contains a
      minimum of 1 element) list of URI's, one of which MUST be an RSYNC
      URI.  The order of URI's in the AIA field may be interpreted as
      the publisher's relative preference for access methods for this
      certificate.  The cert_url conforms to this AIA specification.
      Its value is a comma-separated list of URIs, one of which MUST be
      an RSYNC URI.  Any comma values within a URI MUST be escaped
      ("%2C").

   req_resource_set_as:
      the set of AS numbers that were specified in the corresponding
      original certificate request that defined the maximal requested
      span of the certified AS number set, following the syntax
      described above.  If this attribute was present in the certificate
      request, then the attribute MUST be present in this response,
      otherwise it MUST NOT be present.

   req_resource_set_ipv4:
      the set of IPv4 addresses that were specified in the corresponding
      original certificate request that defined the maximal requested
      span of the certified IPv4 address set, following the syntax
      described above.  If this attribute was present in the certificate
      request, then the attribute MUST be present in this response,
      otherwise it MUST NOT be present.

   req_resource_set_ipv6:
      the set of IPv6 addresses that were specified in the corresponding
      original certificate request that defined the maximal requested
      span of the certified IPv6 address set, following the syntax
      described above.  If this attribute was present in the certificate
      request, then the attribute MUST be present in this response,
      otherwise it MUST NOT be present.

   [certificate]
      value is the Base64 encoding of the DER-encoded certificate.







Huston, et al.          Expires February 8, 2009               [Page 18]

Internet-Draft            Rescert Provisioning               August 2008


3.4.  CA - Certificate Issuance

3.4.1.  Certificate Issuance Request

   The value of the message "type" element for this request is:

      type="issue"


   ---------------------------------------------------------------

   Payload:

   <request
              class_name="class name"
              req_resource_set_as="as resource set"
              req_resource_set_ipv4="ipv4 resource set"
              req_resource_set_ipv6="ipv6 resource set">
              [Certificate request]
              </request>

   ---------------------------------------------------------------


   The client must use different key pairs for each distinct resource
   class.

   If any of the req_resource_set attributes are specified in the
   request, then any missing req_resource_set attributes are to be
   interpreted as specifying the complete set of the corresponding
   resource type that match the client's current resource allocation.
   If the value of any req_resource_set attributes is the null value
   (""), then this indicates that no resources of that resource type are
   to be certified with this request.

   The requested resource set values are held as a local record by the
   issuer against the resource class and the client's public key.  Any
   subsequent Certificate Issuance Requests that specify the same
   Resource Class and the same client's public key will (re)set the
   issuer's local record of the requested resource sets to the most
   recently specified values.

   class_name:
      value is the server's identifier of a Resource Class.







Huston, et al.          Expires February 8, 2009               [Page 19]

Internet-Draft            Rescert Provisioning               August 2008


   req_resource_set_as:  (OPTIONAL)
      the set of AS numbers that define the maximal requested span of
      the certified AS number set, formatted as per the resource_set_as
      attribute of the Resource Class List Response.

   req_resource_set_ipv4:  (OPTIONAL)
      the set of IPv4 addresses that define the maximal requested span
      of the certified IPv4 address set, formatted as per the
      resource_set_ipv4 attribute of the Resource Class List Response.

   req_resource_set_ipv6:  (OPTIONAL)
      the set of IPv6 addresses that define the maximal requested span
      of the certified IPv6 address set, formatted as per the
      resource_set_ipv6 attribute of the Resource Class List Response.

   [Certificate request]
      value is the certificate request.  This is a Base-64 encoded DER
      version of a request formatted using PKCS#10.

3.4.2.  Certificate Issuance Response

   The value of the message "type" element for this response is:

      type="issue_response"


   ---------------------------------------------------------------

   Payload:


    <class class_name="class name"
           cert_url="url"
           resource_set_as="as resource set"
           resource_set_ipv4="ipv4 resource set"
           resource_set_ipv6="ipv6 resource set" >
            <certificate cert_url="url"
                  req_resource_set_as="as resource set"
                  req_resource_set_ipv4="ipv4 resource set"
                  req_resource_set_ipv6="ipv6 resource set" >
            [certificate]
            </certificate>
            <issuer>[issuer's certificate]</issuer>
          </class>

   ---------------------------------------------------------------





Huston, et al.          Expires February 8, 2009               [Page 20]

Internet-Draft            Rescert Provisioning               August 2008


   If the certificate issuer determines that the issued certificate
   would be identical in all respects to the most recently issued
   certificate for this client, other than the certificate's serial
   number, were the certificate to be issued, the issuer may choose to
   respond with the most recently issued certificate and not issue a new
   certificate for this request.

   The definition of the attributes and syntax of the values is the same
   as the resource class list response, but the response only references
   the (single) named resource class, and the (single) certificate
   issued against the client's public key as provided in the
   corresponding certificate request.

3.5.  Certificate Revocation

3.5.1.  Certificate Revocation Request

   The value of the message "type" element for this request is:

      type="revoke"


   ---------------------------------------------------------------

   Payload:


   <key class_name="class name"
        ski="encoded hash of the subject public key]" />


   ---------------------------------------------------------------


   This command 'retires' a client's key pair by requesting the issuer
   to revoke all certificates for this client that contain the matching
   public key, within the scope of a named Resource Class.  Individual
   issued certificates cannot be revoked within the scope of this
   protocol.

   This command directs the issuer to immediately mark all issued valid
   certificates issued by this issuer within the named Resource Class
   with this client's SKI value to be marked as revoked, causing the
   issued certificates to be withdrawn from the publication repository
   and to be listed in the server's subsequent CRLs within this Resource
   Class.





Huston, et al.          Expires February 8, 2009               [Page 21]

Internet-Draft            Rescert Provisioning               August 2008


   class_name:
      value is the issuer-assigned name of the issuer's Resource Class.

   ski:
      value is the encoded hash of the client's public key that is to be
      revoked.  The algorithm for the encoding is to generate the 160-
      bit SHA-1 hash of the client's public key, as defined in method
      (1) of section 4.2.1.2 of [RFC5280], and encode this value using
      the Base 64 encoding with URL and Filename Safe Alphabet, as
      defined in section 5 of [RFC4648].

3.5.2.  Certificate Revocation Response

   The value of the message "type" element for this response is:

      type="revoke_response"


   ---------------------------------------------------------------

   Payload:


   <key class_name="class name"
        ski="encoded hash of the subject public key" />

   ---------------------------------------------------------------


   class_name:
      value is the issuer-assigned name of the server's Resource Class.

   ski:
      value is the encoded hash of the client's public key that is to be
      revoked.  The algorithm for the encoding is to generate the 160-
      bit SHA-1 hash of the client's public key, as defined in method
      (1) of section 4.2.1.2 of [RFC5280], and encode this value using
      the Base 64 encoding with URL and Filename Safe Alphabet, as
      defined in section 5 of [RFC4648].

3.6.  Request-Not-Performed Response

   The value of the message "type" element for this response is:

      type="error_response"






Huston, et al.          Expires February 8, 2009               [Page 22]

Internet-Draft            Rescert Provisioning               August 2008


   ---------------------------------------------------------------

   Payload:


   <status>[Code]</status>
   <description xml:lang="en-US">[Readable text]</description>

   ---------------------------------------------------------------


   All states where an error response if to be generated, either due to
   detected errors or inconsistencies in the content of the request or
   server-side states that prevent the request being performed, generate
   a Request-Not-Performed response.

   description:
      value is a text field.  This element MAY be present.  It's value
      has no defined meaning within the scope of this protocol, and
      implementations may assume that some form of human-readable text
      may be used here.  If the HTTP request that triggered this error
      response includes an Accept-Language header as defined in section
      14.4 of the HTTP/1.1 specification [insert reference to RFC2616]
      then the server will make a best effort to include a second
      description element using the highest ranked preferred language of
      the client.  The en-US description will always be included if the
      element is present.

   The error code set is:

      Code Value    Description
      1101          already processing request
      1102          version number error
      1103          unrecognised request type
      1201          request - no such resource class
      1202          request - no resources allocated in resource class
      1203          request - badly formed certificate request
      1301          revoke - no such resource class
      1302          revoke - no such key 2000+ Server Error
      2001          Internal Server Error - Request not performed



4.  XML Schema

   The following is a RelaxNG compact form schema describing the IR-ISP
   Protocol, version 1.




Huston, et al.          Expires February 8, 2009               [Page 23]

Internet-Draft            Rescert Provisioning               August 2008


   default namespace = "http://www.apnic.net/specs/rescerts/up-down/"

     grammar {
       start = element message {
         attribute version { xsd:positiveInteger { maxInclusive="1" } },
         attribute sender { xsd:token { maxLength="1024" } },
         attribute recipient { xsd:token { maxLength="1024" } },
         payload
       }

       payload |= attribute type { "list" }, list_request
       payload |= attribute type { "list_response"}, list_response
       payload |= attribute type { "issue" }, issue_request
       payload |= attribute type { "issue_response"}, issue_response
       payload |= attribute type { "revoke" }, revoke_request
       payload |= attribute type { "revoke_response"}, revoke_response
       payload |= attribute type { "error_response"}, error_response

       list_request = empty
       list_response = class*

       class = element class {
         attribute class_name { xsd:token { maxLength="1024" } },
         attribute cert_url { xsd:string { maxLength="4096" } },
         attribute resource_set_as { xsd:string { maxLength="512000"
           pattern="[\-,0-9]*" } },
         attribute resource_set_ipv4 { xsd:string { maxLength="512000"
           pattern="[\-,/.0-9]*" } },
         attribute resource_set_ipv6 { xsd:string { maxLength="512000"
           pattern="[\-,/:0-9a-fA-F]*" } },
         attribute resource_set_notafter { xsd:dateTime },
         attribute suggested_sia_head { xsd:anyURI { maxLength="1024"
           pattern="rsync://.+"} }?,
         element certificate {
           attribute cert_url { xsd:string { maxLength="4096" } },
           attribute req_resource_set_as { xsd:string {
             maxLength="512000" pattern="[\-,0-9]*" } }?,
           attribute req_resource_set_ipv4 { xsd:string {
             maxLength="512000" pattern="[\-,/.0-9]*" } }?,
           attribute req_resource_set_ipv6 { xsd:string {
             maxLength="512000" pattern="[\-,/:0-9a-fA-F]*" } }?,
           xsd:base64Binary { maxLength="512000" }
         }*,
         element issuer { xsd:base64Binary { maxLength="512000" } }
       }

       issue_request = element request {
         attribute class_name { xsd:token { maxLength="1024" } },



Huston, et al.          Expires February 8, 2009               [Page 24]

Internet-Draft            Rescert Provisioning               August 2008


         attribute req_resource_set_as { xsd:string {
           maxLength="512000" pattern="[\-,0-9]*" } }?,
         attribute req_resource_set_ipv4 { xsd:string {
           maxLength="512000" pattern="[\-,/.0-9]*" } }?,
         attribute req_resource_set_ipv6 { xsd:string {
           maxLength="512000" pattern="[\-,/:0-9a-fA-F]*" } }?,
         xsd:base64Binary { maxLength="512000"
         }
       }
       issue_response = class

       revoke_request = revocation

       revoke_response =
         revocation

       revocation = element key { attribute class_name { xsd:token {
         maxLength="1024" } }, attribute ski {
           xsd:token { maxLength="1024" } }
         }

       error_response =
         element status { xsd:positiveInteger {
           maxInclusive="999999999999999" }
         },
         element description { attribute xml:lang { xsd:language },
           xsd:string { maxLength="1024" }
         }?
     }



5.  Security Considerations

   The intent of this protocol is to define a protocol to support the
   maintenance of Resource Certificates that the IR issues for an ISP in
   certifying resources that have been allocated or assigned by the IR
   to the ISP [ID.SIDR-RES-CERTS].  This protocol assumes that the IR
   and ISP are known to each other and have exchanged credentials so as
   to support the operation of a TLS channel with mutual identification.
   The mechanisms used to perform this credential exchange are not
   described in this specification.

   The primary objective of this provisioning protocol is to ensure that
   attempts to disrupt the interaction between client and server are
   identifiable by both parties.  The mechanisms used to support this
   level of integrity of protocol operation include the use of TLS with
   mutual identification, and the use of message objects that are



Huston, et al.          Expires February 8, 2009               [Page 25]

Internet-Draft            Rescert Provisioning               August 2008


   digitally signed and dated using CMS.  This is intended to ensure
   that the communication is resistant to attempts to disrupt the
   communication or to replay earlier communication fragments (man-in-
   the middle disruption and replay attacks).

   The protocol is a minimal query / response protocol, that imposes
   strict serialization on each query / response transaction, reducing
   the potential for the ISP and the IR to lose synchronization over the
   issued certificate state.

   The inner protocol elements explicitly reference the intended sender
   and receiver to present an IR or an ISP attempting to masquerade as
   another party within the secure channel.


6.  IANA Considerations

   [Note to IANA, to be removed prior to publication: there are no IANA
   considerations stated in this version of the document.]


7.  Acknowledgements

   The authors would like to acknowledge the valued contributions from
   Russ Housley, Steve Kent, Randy Bush, George Michaelson, and Robert
   Kisteleki in the preparation of the protocol described in this
   document.


8.  References

8.1.  Normative References

   [ISO.8601:2004]
              ISO, "ISO 8601:2004 Representation of dates and Times",
              2004.

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              September 1981.

   [RFC2050]  Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D., and
              J. Postel, "INTERNET REGISTRY IP ALLOCATION GUIDELINES",
              BCP 12, RFC 2050, November 1996.

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

   [RFC3779]  Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
              Addresses and AS Identifiers", RFC 3779, June 2004.



Huston, et al.          Expires February 8, 2009               [Page 26]

Internet-Draft            Rescert Provisioning               August 2008


   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
              RFC 3852, July 2004.

   [RFC4049]  Housley, R., "BinaryTime: An Alternate Format for
              Representing Date and Time in ASN.1", RFC 4049,
              April 2005.

   [RFC4055]  Schaad, J., Kaliski, B., and R. Housley, "Additional
              Algorithms and Identifiers for RSA Cryptography for use in
              the Internet X.509 Public Key Infrastructure Certificate
              and Certificate Revocation List (CRL) Profile", RFC 4055,
              June 2005.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.1", RFC 4346, April 2006.

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, October 2006.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, May 2008.

   [X.501]    CCITT, "Recommendation X.501: The Directory - Models",
              1988.

   [X.509-88]
              CCITT, "Recommendation X.509: The Directory -
              Authentication Framework", 1988.

8.2.  Informative References

   [ID.SIDR-RES-CERTS]
              Huston, G., Michaelson, G., and R. Loomans, "A Profile for
              X.509 PKIX Resource Certificates", Work in progress:
              Internet Drafts draft-ietf-sidr-res-certs-11.txt,
              August 2008.










Huston, et al.          Expires February 8, 2009               [Page 27]

Internet-Draft            Rescert Provisioning               August 2008


Authors' Addresses

   Geoff Huston
   Asia Pacific Network Information Centre
   33 Park Rd
   Milton, QLD  4064
   Australia

   Email: gih@apnic.net
   URI:   http://www.apnic.net


   Robert Loomans
   Asia Pacific Network Information Centre
   33 Park Rd
   Milton, QLD  4064
   Australia

   Email: robertl@apnic.net
   URI:   http://www.apnic.net


   Byron Ellacott
   Asia Pacific Network Information Centre
   33 Park Rd
   Milton, QLD  4064
   Australia

   Email: bje@apnic.net
   URI:   http://www.apnic.net


   Rob Austein
   Internet Systems Consortium
   950 Charter St
   Redwood City, CA  94063
   USA

   Email: sra@isc.org












Huston, et al.          Expires February 8, 2009               [Page 28]

Internet-Draft            Rescert Provisioning               August 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Huston, et al.          Expires February 8, 2009               [Page 29]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/