doc: Add RFC documents

1 files changed, 1795 insertions, 0 deletions

diff --git a/doc/rfc/rfc6492.txt b/doc/rfc/rfc6492.txt
new file mode 100644
index 0000000..f9591e0
--- /dev/null
+++ b/doc/rfc/rfc6492.txt
@@ -0,0 +1,1795 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         G. Huston
+Request for Comments: 6492                                    R. Loomans
+Category: Standards Track                                    B. Ellacott
+ISSN: 2070-1721                                                    APNIC
+                                                              R. Austein
+                                                                     ISC
+                                                           February 2012
+
+
+           A Protocol for Provisioning Resource Certificates
+
+Abstract
+
+   This document defines a framework for certificate management
+   interactions between an Internet Number Resource issuer ("issuer")
+   and an Internet Number Resource recipient ("subject") through the
+   specification of a protocol for interaction between the two parties.
+   The protocol supports the transmission of requests from the subject,
+   and corresponding responses from the issuer encompassing the actions
+   of certificate issuance, certificate revocation, and certificate
+   status information reports.  This protocol is intended to be limited
+   to the application of Internet Number Resource Certificate management
+   and is not intended to be used as part of a more general certificate
+   management framework.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6492.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Huston, et al.               Standards Track                    [Page 1]
+
+RFC 6492                  ResCert Provisioning             February 2012
+
+
+Copyright Notice
+
+   Copyright (c) 2012 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.
+
+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 .............................5
+           3.1.2. CMS Object Validation ..............................10
+           3.1.3. ASN.1 Specification of the CMS Signed Object .......12
+      3.2. Common Message Format .....................................14
+      3.3. Control - Resource Class Query ............................16
+           3.3.1. Resource Class List Query ..........................16
+           3.3.2. Resource Class List Response .......................17
+      3.4. CA - Certificate Issuance .................................21
+           3.4.1. Certificate Issuance Request .......................21
+           3.4.2. Certificate Issuance Response ......................24
+      3.5. Certificate Revocation ....................................24
+           3.5.1. Certificate Revocation Request .....................25
+           3.5.2. Certificate Revocation Response ....................26
+      3.6. Request-Not-Performed Response ............................26
+      3.7. XML Schema ................................................27
+   4. Security Considerations ........................................29
+   5. IANA Considerations ............................................30
+      5.1. application/rpki-updown ...................................30
+   6. Acknowledgements ...............................................30
+   7. References .....................................................31
+      7.1. Normative References ......................................31
+      7.2. Informative References ....................................32
+
+
+
+
+
+
+
+Huston, et al.               Standards Track                    [Page 2]
+
+RFC 6492                  ResCert Provisioning             February 2012
+
+
+1.  Introduction
+
+   This document defines a framework for certificate management
+   interactions between an Internet Number Resource issuer ("issuer")
+   and an Internet Number Resource recipient ("subject") through the
+   specification of a protocol for interaction between the two parties.
+   The protocol supports the transmission of requests from the subject,
+   and corresponding responses from the issuer encompassing the actions
+   of certificate issuance, certificate revocation, and certificate
+   status information reports.  This protocol is intended to be limited
+   to the application of Internet Number Resource certificate management
+   and is not intended to be used as part of a more general certificate
+   management framework.
+
+1.1.  Terminology
+
+   Terms used in this document are:
+
+   "Internet Number Resource"  (or "resource") used in the context of
+      this document to refer to Autonomous System (AS) numbers, IP
+      version 4 addresses, and IP version 6 addresses.
+
+   "issuer"  used in the context of this document as an entity
+      undertaking the role of resource issuer.  An "issuer" is a
+      Certification Authority (CA), and can issue resource certificates.
+
+   "subject"  used in the context of this document as an entity
+      undertaking the role of resource recipient who is the subject of a
+      resource certificate.  A "subject" may be issued with a CA-enabled
+      certificate, allowing the entity to also assume the role of an
+      "issuer".
+
+   "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 issuer assumes the role of the "server".
+
+   "client"  in the context of this client/server protocol
+      specification, the subject 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 [RFC2119].
+
+
+
+
+
+
+Huston, et al.               Standards Track                    [Page 3]
+
+RFC 6492                  ResCert Provisioning             February 2012
+
+
+2.  Scope
+
+   This Resource Public Key Infrastructure (RPKI) certificate
+   provisioning protocol defines a basic set of interactions that allow
+   a subject to request certificate issuance, revocation, and status
+   information from the issuer, and for an issuer to maintain an issued
+   certificate set that is aligned to the allocation records relating to
+   each subject.  The issuer's resource allocation database is the
+   authoritative source of what resource allocations the issuer may
+   certify for a subject.
+
+   A resource recipient (subject) may also undertake the role of a
+   resource issuer (issuer).
+
+   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 issuer'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, or the exchange of the certificates and validation
+      Public Key Infrastructure (PKI) contexts used in the Cryptographic
+      Message Syntax (CMS) [RFC5652] message exchange.
+
+   o  the interactions between client and server that allow respective
+      local CMS signing time values to be reset to mutually recognized
+      values.
+
+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 HTTP [RFC2616] end-to-end connection.  A
+   message exchange commences with the client initiating an HTTP POST
+   with content type of "application/rpki-updown" and the message object
+   as the body.  The server's response is similarly an HTTP response,
+   with the message object carried as the body of the response and with
+   a response content type of "application/rpki-updown".  The content of
+   the POST and the server's response are "well-formed" CMS [RFC5652]
+   objects, encoded using the Distinguished Encoding Rules (DER) for
+
+
+
+Huston, et al.               Standards Track                    [Page 4]
+
+RFC 6492                  ResCert Provisioning             February 2012
+
+
+   ASN.1 [X.509-88], formatted in accordance with the CMS profile
+   specified in the following section.  CMS is used as the signing
+   format to sign the message object.  The CMS message includes an end-
+   entity (EE) certificate that is to be used to validate the CMS
+   digital signature  (see Section 3.1.1.4); the certificate chain that
+   is used to validate the EE certificate MAY be included in the CMS
+   message, and if it is not present it is assumed to have been
+   communicated between the two entities, through mechanisms not defined
+   in this specification.
+
+   The protocol's request/response interaction is assumed to be
+   reliable, in that all requests MUST generate a matching response.
+   The protocol requires sequential operation for each distinct client,
+   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
+   (i.e., multiple concurrent requests with a common sender attribute
+   (see Section 3.2) in the request) MUST be detected by the server and
+   rejected with an error response (i.e., an error code 1101 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 content-type is the signed-data type of id-data, namely
+   id-signedData, OID = 1.2.840.113549.1.7.2.  [RFC5652]
+
+3.1.1.  SignedData Content Type
+
+   According to the CMS standard [RFC5652], signed-data content types
+   are 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
+
+
+
+Huston, et al.               Standards Track                    [Page 5]
+
+RFC 6492                  ResCert Provisioning             February 2012
+
+
+   Additionally, the SignerInfos set MUST contain only a single
+   SignerInfo object.
+
+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 contains the Object Identifiers (OID)s of
+   the digest algorithm(s) used in signing the encapsulated content.
+   This set MUST contain exactly one digest algorithm OID, and the OID
+   MUST be selected from those specified in [RFC6485].
+
+3.1.1.3.  encapContentInfo
+
+   encapContentInfo is the signed content, consisting of a content type
+   identifier and the content itself.  The encapContentInfo represents
+   the payload of the RPKI certificate provisioning protocol.
+
+   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.
+
+      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 an RPKI XML Protocol Object consists of a single
+   protocol message, structured according to a defined XML schema, as
+   defined in subsequent sections of this document.  The eContent field
+   of the CMS object is formally defined using ASN.1 as:
+
+      RPKIXMLProtocolObject ::= OCTET STRING -- XML encoded message
+
+
+
+
+Huston, et al.               Standards Track                    [Page 6]
+
+RFC 6492                  ResCert Provisioning             February 2012
+
+
+3.1.1.4.  certificates
+
+   This field MUST be present and MUST contain the single 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 recognized to attest to the identity of the party that
+   created the CMS object.
+
+   This field MAY contain CA certificates that a relying party MAY use
+   to validate the EE certificate.
+
+3.1.1.5.  crls
+
+   This field MUST be present.  The contents of the field are specified
+   in [RFC5652].  The current Certificate Revocation List (CRL) issued
+   by the same CA that issued the EE certificate of the key pair whose
+   private key value was used to sign the CMS MUST be present in this
+   field.  This field MAY contain CRLs issued by other CAs covering CA
+   certificates included in the certificates field of the CMS object
+   (see Section 3.1.1.4).  This field MUST NOT contain any other CRLs.
+
+3.1.1.6.  SignerInfo
+
+   SignerInfo is defined in CMS as:
+
+   SignerInfo ::= SEQUENCE {
+     version CMSVersion,
+     sid SignerIdentifier,
+     digestAlgorithm DigestAlgorithmIdentifier,
+     signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
+     signatureAlgorithm SignatureAlgorithmIdentifier,
+     signature SignatureValue,
+     unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }
+
+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 }
+
+
+
+
+
+Huston, et al.               Standards Track                    [Page 7]
+
+RFC 6492                  ResCert Provisioning             February 2012
+
+
+   In this profile, the sid MUST be the SubjectKeyIdentifier that
+   appears in the EE certificate carried in the CMS certificates field.
+
+3.1.1.6.3.  digestAlgorithm
+
+   The digestAlgorithm MUST consist of the OID of a digest algorithm
+   that conforms to the RPKI Algorithms and Key Size Profile
+   specification [RFC6485].
+
+3.1.1.6.4.  signedAttrs
+
+   The signedAttrs field is 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 signedAttr element MUST be present and MUST include the content-
+   type and message-digest attributes [RFC5652].  If either the signing-
+   time [RFC5652] attribute or the binary-signing-time attribute
+   [RFC6019], or both attributes, are present, they MUST also be
+   included as the SignedAttributes.  Other signed attributes MUST NOT
+   be included.
+
+   The signedAttr MUST include only a single instance of any particular
+   attribute.  Additionally, even though the syntax allows for a SET OF
+   AttributeValue, in this profile, the attrValues MUST consist of only
+   a single AttributeValue.
+
+3.1.1.6.4.1.  Content-Type Attribute
+
+   The content-type attribute MUST be present.  The attrType OID for the
+   content-type attribute is 1.2.840.113549.1.9.3.
+
+      id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2)
+          us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 }
+
+      ContentType ::= OBJECT IDENTIFIER
+
+
+
+
+
+
+
+Huston, et al.               Standards Track                    [Page 8]
+
+RFC 6492                  ResCert Provisioning             February 2012
+
+
+   The attrValues for the content-type attribute MUST match the
+   eContentType in the EncapsulatedContentInfo.  This OID value is
+   defined as id-ct-xml and has the numerical value of
+   1.2.840.113549.1.9.16.1.28.
+
+3.1.1.6.4.2.  Message-Digest Attribute
+
+   The message-digest attribute MUST be present.  The attrType OID for
+   the message-digest attribute is 1.2.840.113549.1.9.4.
+
+      id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
+          us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 }
+
+      MessageDigest ::= OCTET STRING
+
+   The attrValues for the message-digest attribute contains the output
+   of the digest algorithm applied to the content being signed, as
+   specified in Section 5.4 of [RFC5652].
+
+3.1.1.6.4.3.  Signing-Time Attribute
+
+   The signing-time attribute MAY be present.  The attrType OID for the
+   signing-time attribute is 1.2.840.113549.1.9.5.
+
+      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 specifies the time, based on the local
+   system clock, when the digital signature was applied to the content.
+
+   Guidelines regarding the use of UTCTime and GeneralizedTime in the
+   signing-time attribute can be found in Section 11.3 of [RFC5652].
+
+   Either one of the signing-time attribute or the binary-signing-time
+   attribute, or both attributes, MUST be present.  If both the signing-
+   time and binary-signing-time attributes are present, they MUST both
+   represent the same underlying time value.
+
+
+
+
+
+
+
+
+Huston, et al.               Standards Track                    [Page 9]
+
+RFC 6492                  ResCert Provisioning             February 2012
+
+
+3.1.1.6.4.4.  Binary-Signing-Time Attribute
+
+   The binary-signing-time attribute MAY be present.  The attrType OID
+   for the binary-signing-time attribute is 1.2.840.113549.1.9.16.2.46.
+
+      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 binary-signing-time attribute specifies the time, based on the
+   local system clock, when the digital signature was applied to the
+   content.  The precise definition of the binary-signing-time attribute
+   can be found at [RFC6019].
+
+   Either one of the signing-time or the binary-signing-time attributes,
+   or both attributes, MUST be present.  If both the signing-time and
+   binary-signing-time attributes are present, they MUST both represent
+   the same underlying time value.
+
+3.1.1.6.5.  signatureAlgorithm Attribute
+
+   The signatureAlgorithm MUST conform to the RPKI Algorithms and Key
+   Size Profile specification [RFC6485].
+
+3.1.1.6.6.  signature Attribute
+
+   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.  UnsignedAttributes Attribute
+
+   unsignedAttrs MUST be omitted.
+
+3.1.2.  CMS Object Validation
+
+   Before a recipient of a CMS signed object can use the content of the
+   object, the recipient MUST validate the signed object by verifying
+   that all of the following conditions hold.  A recipient may perform
+   these checks in any order.
+
+
+
+
+Huston, et al.               Standards Track                   [Page 10]
+
+RFC 6492                  ResCert Provisioning             February 2012
+
+
+   1.  The CMS object is well formed, such that the signed object syntax
+       complies with this specification.  In particular, that each of
+       the following is true:
+
+       a.  The content-type of the CMS object is SignedData (OID
+           1.2.840.113549.1.7.2)
+
+       b.  The version of the SignedData object is 3.
+
+       c.  The certificates field in the SignedData object is present
+           and contains one EE certificate, the SubjectKeyIdentifier
+           field of which matches the sid field of the SignerInfo
+           object.
+
+       d.  The crls field in the SignedData object is present.
+
+       e.  The version of the SignerInfo is 3.
+
+       f.  The signedAttrs field in the SignerInfo object is present and
+           contains one each of the content-type attribute (OID
+           1.2.840.113549.1.9.3), the message-digest attribute (OID
+           1.2.840.113549.1.9.4), and either or both of a single
+           instance of the signing-time attribute (OID
+           1.2.840.113549.1.9.5) and the binary-signing-time attribute
+           (OID 1.2.840.113549.1.9.16.2.46), and no other attributes.
+
+       g.  The eContentType in the EncapsulatedContentInfo is an OID
+           that matches the attrValue in the content-type attribute and
+           has the attrValue of id-ct-xml.
+
+       h.  The unsignedAttrs field in the SignerInfo object is omitted.
+
+       i.  If both the signing-time attribute and the binary-signing-
+           time attribute are present, then their values represent the
+           same time.
+
+       j.  The digestAlgorithm in the SignedData and SignerInfo objects
+           conforms to the RPKI Algorithms and Key Size Profile
+           specification [RFC6485].
+
+       k.  The signatureAlgorithm in the SignerInfo object conforms to
+           the RPKI Algorithms and Key Size Profile specification
+           [RFC6485].
+
+       l.  The signed object is DER encoded.
+
+
+
+
+
+
+Huston, et al.               Standards Track                   [Page 11]
+
+RFC 6492                  ResCert Provisioning             February 2012
+
+
+   2.  The public key of the EE certificate (contained within the CMS
+       signed-data object) can be used to successfully verify the
+       signature on the signed object.
+
+   3.  The EE certificate (contained within the CMS signed-data object)
+       is a valid EE certificate.  In particular, there exists a valid
+       certification path from a trust anchor selected by the recipient
+       to this EE certificate.
+
+   4.  At the current time, the EE certificate is not revoked.  This can
+       be determined by confirming that the CRL contained in the crls
+       field of the CMS signed data object is a current valid CRL,
+       issued by the same CA that issued the EE certificate, and the CRL
+       does not list the serial number of the EE certificate.
+
+   5.  The time represented by the signing-time attribute or the binary-
+       signing-time attribute is greater than or equal to the time value
+       passed in previously valid CMS objects that were passed from the
+       same originator to this recipient.  This signing time value MAY
+       lie within the Validity Time of the EE certificate, but the EE
+       certificate SHOULD NOT be considered invalid if this is not the
+       case when all other checks listed here are passed.
+
+3.1.3.  ASN.1 Specification of the CMS Signed Object
+
+   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
+
+      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 }
+
+      RPKIXMLProtocolObject ::= OCTET STRING -- XML encoded message
+
+      id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
+                         us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }
+
+
+
+
+
+
+
+Huston, et al.               Standards Track                   [Page 12]
+
+RFC 6492                  ResCert Provisioning             February 2012
+
+
+      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
+
+      Attribute ::= SEQUENCE {
+      attrType OBJECT IDENTIFIER,
+      attrValues SET OF AttributeValue }
+
+      AttributeValue ::= ANY
+
+      SignatureValue ::= OCTET STRING
+
+      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 }
+
+
+
+
+Huston, et al.               Standards Track                   [Page 13]
+
+RFC 6492                  ResCert Provisioning             February 2012
+
+
+      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 informally described as follows
+   (the RELAX NG compact form schema that formally describes the
+   protocol message objects is contained in Section 3.7):
+
+   ---------------------------------------------------------------
+
+   <?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>
+
+   ---------------------------------------------------------------
+
+   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.
+
+
+
+
+
+
+
+Huston, et al.               Standards Track                   [Page 14]
+
+RFC 6492                  ResCert Provisioning             February 2012
+
+
+   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 error when receiving such
+   a response.
+
+   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 that the CMS is well-formed (see test 1 of Section 3.1.2).
+
+   2.  Check that the XML is well-formed.
+
+   3.  Check that the XML sender and recipient attributes reference a
+       known client and this server's system respectively for a query,
+       and the previously addressed server and this client for a
+       response.
+
+   4.  Verify the digital signature using the public key provided in the
+       certificate carried in the CMS wrapper (see test 2 of Section
+       3.1.2).
+
+   5.  Validate the CMS-provided certificate using the PKI that has been
+       determined by prior arrangement between the client and server
+       (see test 3 of Section 3.1.2).
+
+   6.  Check that the signing time of the CMS is equal to or greater
+       than the signing time provided in the most recent previous
+       message that this recipient has received from this sender (see
+       test 4 of Section 3.1.2).
+
+   7.  Check that the value of the version number of the message is 1.
+
+   These checks SHOULD be applied in the order specified here.
+
+
+
+
+Huston, et al.               Standards Track                   [Page 15]
+
+RFC 6492                  ResCert Provisioning             February 2012
+
+
+   Any errors encountered while checking items 1 through 7 MUST cause a
+   server to generate an "HTTP 400 Bad Request" response to the HTTP
+   POST operation.  An error in step 7 MUST cause the server to generate
+   a "Request-Not-Performed" error response.  Any errors encountered in
+   these tests by a client SHOULD cause the client to generate an error.
+
+   A server MAY perform flow control on the rate of processed requests.
+   Requests not processed due to such a flow control constraint MAY
+   cause the server to generate an "HTTP 503 Service Unavailable"
+   response.  An HTTP 503 response MAY include an HTTP Retry-After:
+   header as a hint to the client.
+
+3.3.  Control - Resource Class Query
+
+   This query is used for a client to query a server for a list of all
+   resources that have been allocated or assigned by the server to the
+   client.  In addition, the server's response will contain a copy of
+   the current certificates issued by the server's CA where this client
+   is the certificate's subject.
+
+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]
+
+    ---------------------------------------------------------------
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Huston, et al.               Standards Track                   [Page 16]
+
+RFC 6492                  ResCert Provisioning             February 2012
+
+
+3.3.2.  Resource Class List Response
+
+   The value of the message "type" element for this response is:
+
+      type="list_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"
+        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, the response MUST contain multiple class elements that
+   correspond 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 MUST 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
+
+
+
+Huston, et al.               Standards Track                   [Page 17]
+
+RFC 6492                  ResCert Provisioning             February 2012
+
+
+   rollover), only the most recent certificate issued with the currently
+   "active" issuer's key is to be listed in the response.
+
+   Each "class" element describes a set of resources that are certified
+   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 [RFC5781].  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 lowest and highest values 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, then the empty AS set is
+      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 the lowest and highest
+      values of the range 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.,
+
+
+
+Huston, et al.               Standards Track                   [Page 18]
+
+RFC 6492                  ResCert Provisioning             February 2012
+
+
+      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 IPv4
+      address set is represented by a null string value ("") for this
+      attribute.
+
+   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 lowest and
+      highest values of the range 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, and conforms to
+      the canonical format of [RFC5952] (e.g.,
+      resource_set_ipv6="2001:db8::/48,2001:db8:2::-2001:db8:5::").  The
+      XML Schema data type is
+      "http://www.w3.org/TR/xmlschema-2/#hexBinary" and the value is
+      case insensitive, with the canonical form being lower case.  If
+      there are no IPv6 addresses in this resource class, the empty IPv6
+      address set is represented by a null string value ("") for this
+      attribute.
+
+   resource_set_notafter:
+      The value of this attribute specifies 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
+      defined in ISO 8601 [ISO.8601:2004], and MUST use UTC time
+      represented as 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 from 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 its value is a directory URI that
+      indicates a repository publication point that the server has made
+      available to the client to use for the client's collection of
+      published products.  This specification does not encompass the
+      protocols that the client may use with the operator of the
+      repository publication point in order to publish objects at this
+      publication point.
+
+
+
+
+Huston, et al.               Standards Track                   [Page 19]
+
+RFC 6492                  ResCert Provisioning             February 2012
+
+
+   [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-expired, non-revoked certificate.  If no current
+      certificate has been issued, then no certificate element is to 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
+      Authority Information Access (AIA) field for the subject to use in
+      subordinate certificates that are issued by the subject.
+      According to the Resource Certificate Profile [RFC6487], 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 [RFC5781].  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
+
+
+
+Huston, et al.               Standards Track                   [Page 20]
+
+RFC 6492                  ResCert Provisioning             February 2012
+
+
+      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.
+
+3.4.  CA - Certificate Issuance
+
+   This query is used by the client to request the server's CA to issue
+   a resource certificate for the resources that have been allocated or
+   assigned to the client.  If the request can be successfully
+   processed, then the server's response includes the issued
+   certificate.
+
+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.
+
+   The req_resource_set attributes are optional in the request.
+
+   If none of the req_resource_set attributes are specified, then the
+   request signifies that the complete set of all resources that match
+   the client's current resource allocation is to be included in the
+   issued certificate.
+
+   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
+
+
+
+
+Huston, et al.               Standards Track                   [Page 21]
+
+RFC 6492                  ResCert Provisioning             February 2012
+
+
+   resource type that match the client's current resource allocation are
+   to be included in the issued certificate.
+
+   If the value of any included req_resource_set attributes is the null
+   value (""), then this indicates that no resources of that resource
+   type are to be included in the issued certificate.
+
+   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.
+
+   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 Base64 encoded DER
+      version of a request formatted using PKCS#10 [RFC2986].  The
+      certificate request is signed using the private key part of the
+      key pair whose public part is the subject key value in the
+      certification request.  The signing algorithm is specified in
+      [RFC6485].  (This signature component is intended to demonstrate
+      proof of possession of the private key.)
+
+   The response to this request is a Certificate Issuance Response if
+   the request can be processed online.  If the request cannot be
+   undertaken immediately, then the server MUST respond with a "Request-
+   Not-Performed" message, using the appropriate error code:
+
+   o  If the resource class is not defined by the server, then the
+      server MUST return error code 1201.
+
+
+
+Huston, et al.               Standards Track                   [Page 22]
+
+RFC 6492                  ResCert Provisioning             February 2012
+
+
+   o  If the client holds no resources in a defined resource class, then
+      the server MUST return error code 1202 and not proceed with the
+      request.
+
+   o  If the certificate request payload is badly formed, then the
+      server MUST return error code 1203.
+
+   o  If the public key used in the certificate request implies that the
+      client is attempting to use identical key pairs for multiple
+      resource classes, then the server MUST respond with a 1204 error
+      code.
+
+   o  If the certificate issuer uses an off-line process to undertake
+      certificate issuance, and the server cannot directly respond to
+      the certificate issuance request with an issued certificate, then
+      the certificate issuer MUST respond to the first instance of this
+      request with an error code 1104 to indicate that the request is
+      being processed asynchronously.  Subsequent repetitions of this
+      request while the off-line actions are being undertaken SHOULD
+      cause a response with error code 1101.  In this context, where
+      off-line processes are invoked for certificate issuance, if the
+      certificate issuer determines in processing the request 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 initiate an off-line certificate issuance
+      request.
+
+   Note that a client, when receiving a 1104 response to a certificate
+   issuance request, MAY periodically resubmit the request, in which
+   case the client MUST receive an error code 1101 response while the
+   request is being processed, and a Certificate Issuance Response when
+   the certificate issuance process has completed.  In such
+   circumstances, a client SHOULD limit the frequency of such repeated
+   requests to no more than 1 request in each 24-hour interval.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Huston, et al.               Standards Track                   [Page 23]
+
+RFC 6492                  ResCert Provisioning             February 2012
+
+
+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>
+
+      ---------------------------------------------------------------
+
+   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
+
+   This request 'retires' a client's key pair by requesting that the
+   server's CA revoke all certificates for this client (i.e., where this
+   client is the subject) that contain the matching public key, within
+   the scope of a named resource class.  Individual certificates cannot
+   be revoked within the scope of this protocol.
+
+
+
+
+
+Huston, et al.               Standards Track                   [Page 24]
+
+RFC 6492                  ResCert Provisioning             February 2012
+
+
+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 directs the server's CA to immediately mark all issued
+   valid certificates issued by this issuer within the named resource
+   class with this client's subject name and the provided 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.  The issuer MUST ensure
+   that all certificates to be revoked were issued with the requesting
+   client as the certificate's subject.
+
+   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].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Huston, et al.               Standards Track                   [Page 25]
+
+RFC 6492                  ResCert Provisioning             February 2012
+
+
+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"
+
+   ---------------------------------------------------------------
+
+      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.
+
+
+
+
+
+
+Huston, et al.               Standards Track                   [Page 26]
+
+RFC 6492                  ResCert Provisioning             February 2012
+
+
+   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 [RFC2616], then the server MAY
+      include a second description element using the highest ranked
+      preferred language of the client.  The en-US description MUST
+      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         unrecognized request type
+         1104         request scheduled for processing
+         1201         request - no such resource class
+         1202         request - no resources allocated in resource class
+         1203         request - badly formed certificate request
+         1204         request - already used key in request
+         1301         revoke - no such resource class
+         1302         revoke - no such key
+         2001         Internal Server Error - Request not performed
+
+3.7.  XML Schema
+
+   The following is a RELAX NG compact form schema describing version 1
+   of this protocol.
+
+      Note: As discussed in [XML], "the namespace name, to serve its
+      intended purpose, SHOULD have the characteristics of uniqueness
+      and persistence.  It is not a goal that it be directly usable for
+      retrieval of a schema (if any exists)".
+
+   default namespace = "http://www.apnic.net/specs/rescerts/up-down/"
+
+   grammar {
+      resource_set_as = xsd:string {  maxLength="512000"
+                                      pattern="[\-,0-9]*" }
+      resource_set_ip4 = xsd:string { maxLength="512000"
+                                      pattern="[\-,/.0-9]*" }
+      resource_set_ip6 = xsd:string { maxLength="512000"
+                                      pattern="[\-,/:0-9a-fA-F]*" }
+
+      class_name = xsd:token { minLength="1" maxLength="1024" }
+      ski = xsd:token { minLength="27" maxLength="1024" }
+
+
+
+Huston, et al.               Standards Track                   [Page 27]
+
+RFC 6492                  ResCert Provisioning             February 2012
+
+
+      label = xsd:token { minLength="1" maxLength="1024" }
+      cert_url = xsd:string { minLength="10" maxLength="4096" }
+      base64_binary = xsd:base64Binary { minLength="4"
+                                         maxLength="512000" }
+
+      start = element message {
+        attribute version { xsd:positiveInteger {
+                                             maxInclusive="1" } },
+        attribute sender { label },
+        attribute recipient { label },
+        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 { class_name },
+        attribute cert_url { cert_url },
+        attribute resource_set_as { resource_set_as },
+        attribute resource_set_ipv4 { resource_set_ip4 },
+        attribute resource_set_ipv6 { resource_set_ip6 },
+        attribute resource_set_notafter { xsd:dateTime },
+        attribute suggested_sia_head { xsd:anyURI { maxLength="1024"
+                                              pattern="rsync://.+"} }?,
+        element certificate {
+          attribute cert_url { cert_url },
+          attribute req_resource_set_as { resource_set_as }?,
+          attribute req_resource_set_ipv4 { resource_set_ip4 }?,
+          attribute req_resource_set_ipv6 { resource_set_ip6 }?,
+          base64_binary
+        }*,
+        element issuer { base64_binary }
+      }
+
+      issue_request = element request {
+        attribute class_name { class_name },
+        attribute req_resource_set_as { resource_set_as }?,
+        attribute req_resource_set_ipv4 { resource_set_ip4 }?,
+        attribute req_resource_set_ipv6 { resource_set_ip6 }?,
+
+
+
+Huston, et al.               Standards Track                   [Page 28]
+
+RFC 6492                  ResCert Provisioning             February 2012
+
+
+        base64_binary
+      }
+      issue_response = class
+
+      revoke_request = revocation
+      revoke_response = revocation
+
+      revocation = element key {
+        attribute class_name { class_name },
+        attribute ski { ski }
+      }
+
+      error_response =
+        element status { xsd:positiveInteger { maxInclusive="9999" } },
+        element description { attribute xml:lang { xsd:language },
+                                  xsd:string { maxLength="1024" } }*
+      }
+
+4.  Security Considerations
+
+   This protocol supports the maintenance of resource certificates that
+   the issuer issues for a subject in certifying resources that have
+   been allocated or assigned by the issuer to the subject [RFC6480].
+   This protocol assumes that the issuer and subject are known to each
+   other and have exchanged credentials so as to support the mutual
+   recognition of the digital signatures used to sign the CMS messages.
+   The mechanisms used to perform the associated credential exchange are
+   not described in this specification.
+
+   The protocol is a minimal query/response protocol that imposes strict
+   serialization on each query/response transaction, reducing the
+   potential for the subject and the issuer to lose synchronization over
+   the issued certificate state.
+
+   Validation of protocol objects (Section 3.1.2) requires that the CMS
+   signing-time value be greater than or equal to the time value passed
+   in the previously valid protocol objects that were passed from the
+   same originator to the same recipient.  If a party inadvertently
+   sends a valid message (protocol object) with a signing time in the
+   future, then subsequent messages from the party in the same
+   client/server context can use signing-time value consistent with this
+   validation constraint, such that the signing times contained in
+   subsequent messages are greater than or equal to the signing-time
+   value of the previous valid message.  (Note that it is not a
+   normative requirement that the signing time be precisely aligned to a
+   time of day clock, thus permitting arbitrarily large clock skew
+   values in the context of this protocol message exchange.)  If the
+   client and server wish to reset the signing time to a mutually agreed
+
+
+
+Huston, et al.               Standards Track                   [Page 29]
+
+RFC 6492                  ResCert Provisioning             February 2012
+
+
+   value, then, (as noted in Section 2) the interactions between the
+   client and the server to achieve this outcome are not encompassed in
+   this protocol.
+
+5.  IANA Considerations
+
+   IANA has registered the following media type:
+
+   application/rpki-updown
+
+5.1.  application/rpki-updown
+
+   Type name:  application
+   Subtype name:  rpki-updown
+   Required parameters:  None
+   Optional parameters:  None
+   Encoding considerations:  binary
+   Security considerations:  Carries an RPKI Provisioning Protocol
+      Message, as defined in this document.
+   Interoperability considerations:  None
+   Published specification:  This document
+   Applications that use this media type:  HTTP [RFC5652]
+   Additional information:
+      Magic number(s):  None
+      File extension(s):
+      Macintosh File Type Code(s):
+   Person & email address to contact for further information:
+      Geoff Huston <gih@apnic.net>
+   Intended usage:  COMMON
+   Restrictions on usage:  Only to be used as an RPKI Provisioning
+      Protocol message object type, as defined in this document.
+   Author:  Geoff Huston <gih@apnic.net>
+   Change controller:  Geoff Huston <gih@apnic.net>
+
+6.  Acknowledgements
+
+   The authors would like to acknowledge the valued contributions from
+   Russ Housley, Steve Kent, Randy Bush, George Michaelson, Robert
+   Kisteleki, Tim Bruijnzeels, and Carsten Bormann in the preparation of
+   the protocol described in this document.
+
+
+
+
+
+
+
+
+
+
+
+Huston, et al.               Standards Track                   [Page 30]
+
+RFC 6492                  ResCert Provisioning             February 2012
+
+
+7.  References
+
+7.1.  Normative References
+
+   [ISO.8601:2004]
+              ISO, "ISO 8601:2004 Representation of dates and Times",
+              2004.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
+              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
+              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
+
+   [RFC2986]  Nystrom, M. and B. Kaliski, "PKCS #10: Certification
+              Request Syntax Specification Version 1.7", RFC 2986,
+              November 2000.
+
+   [RFC3779]  Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
+              Addresses and AS Identifiers", RFC 3779, June 2004.
+
+   [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.
+
+   [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
+              RFC 5652, September 2009.
+
+   [RFC5781]  Weiler, S., Ward, D., and R. Housley, "The rsync URI
+              Scheme", RFC 5781, February 2010.
+
+   [RFC5952]  Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
+              Address Text Representation", RFC 5952, August 2010.
+
+   [RFC6019]  Housley, R., "BinaryTime: An Alternate Format for
+              Representing Date and Time in ASN.1", RFC 6019, September
+              2010.
+
+   [RFC6485]  Huston, G., "The Profile for Algorithms and Key Sizes for
+              Use in the Resource Public Key Infrastructure (RPKI)", RFC
+              6485, February 2012.
+
+
+
+
+
+Huston, et al.               Standards Track                   [Page 31]
+
+RFC 6492                  ResCert Provisioning             February 2012
+
+
+   [X.509-88] CCITT, "Recommendation X.509: The Directory-
+              Authentication Framework", 1988.
+
+7.2.  Informative References
+
+   [RFC6480]  Lepinski, M. and S. Kent, "An Infrastructure to Support
+              Secure Internet Routing", RFC 6480, February 2012.
+
+   [RFC6487]  Huston, G., Michaelson, G., and R. Loomans, "A Profile for
+              X.509 PKIX Resource Certificates", RFC 6487, February
+              2012.
+
+   [XML]      Bray, T., Hollander, D., Layman, A., Tobin, R., and H.
+              Thompson, "Namespaces in XML 1.0 (Third Edition)", World
+              Wide Web Consortium Recommendation REC-xml-names-20091208,
+              December 2009, <http://www.w3.org/TR/2009/REC-xml-
+              names-20091208/>.
+
+Authors' Addresses
+
+   Geoff Huston
+   APNIC
+
+   EMail: gih@apnic.net
+   URI:   http://www.apnic.net
+
+
+   Robert Loomans
+   APNIC
+
+   EMail: robertl@apnic.net
+   URI:   http://www.apnic.net
+
+
+   Byron Ellacott
+   APNIC
+
+   EMail: bje@apnic.net
+   URI:   http://www.apnic.net
+
+
+   Rob Austein
+   Internet Systems Consortium
+
+   EMail: sra@hactrn.net
+
+
+
+
+
+
+Huston, et al.               Standards Track                   [Page 32]
+